Кибербезопасность

По данным последних исследований IT, каждые четыре секунды в компьютерную сеть компании попадает вредоносная программа и каждые 32 минуты за пределы организации уходит ценная информация. Утерянные данные могут стать источником манипуляций, поэтому так важно выстроить максимально эффективную защиту. Обеспечить информационную безопасность можно сотнями способов, сочетая разные продукты – антивирусы, межсетевые экраны, SSL-сертификаты, разграничение правд доступа, системы защиты от DDoS-атак. Важнейшей стороной информационной безопасности становится определение угроз, а это невозможно без определения объектов защиты. Только поняв, что и от чего мы защищаем, можно выстроить грамотную оборону. Сейчас актуален переход к облачным решениям, которые дают возможность быстро развёртывать системы безопасности, отдавая их управление поставщикам облачных сервисов. В этом разделе собраны актуальные материалы об информационной безопасности от построения информационной защиты до её оптимизации.

Статья Обход защиты BIOS: отключение Secure Boot на залоченных прошивках

  • 172
  • 0
Материнская плата ноутбука на антистатическом коврике с программатором CH341A, подключённым к SPI-чипу. Диагностический экран светится в темноте, отображая текст об обходе Secure Boot.


🔒 На red team-проекте достался корпоративный ThinkPad с полностью залоченным BIOS. За три часа с программатором CH341A и UEFITool удалось сбросить пароль и обнаружить в прошивке подписанный Microsoft DXE-драйвер, позволяющий загрузку произвольного кода. Secure Boot формально включён — реальной защиты нет.

CVE-2024-7344 (CVSS 8.2): Microsoft подписал UEFI-приложение с кастомным PE-загрузчиком вместо стандартных LoadImage/StartImage — грузит любой бинарь из cloak.dat, игнорируя Secure Boot. BootHole (CVE-2020-10713): переполнение в GRUB2 при парсинге grub.cfg — подпись валидирует бинарь, но не данные которые он парсит. SMM exploitation в Ring -2 невидим для любого software-based мониторинга.

CHIPSEC для аудита: common.spi_lock [FAILED] = прошивку можно перезаписать программно без вскрытия корпуса. Decision tree выбора вектора по условиям. Чеклист защиты из десяти пунктов.

💡 Secure Boot без Intel Boot Guard + актуального dbx + мониторинга...

Статья Identity-based атаки APT 2026: как группировки уходят от эндпоинтов в облако и почту — Red Team и Detection гайд

  • 207
  • 0
USB-токен безопасности и смартфон с запросом OAuth на матовой чёрной подложке. Бирюзовое свечение, янтарный текст на экране, размытый ноутбук на фоне.


🔐 APT29 вошли в Microsoft через password spraying тестового tenant без MFA. Два месяца читали почту руководства через OAuth-приложение с full_access_as_app к Exchange Online. EDR не выдал ни одного алерта: вся цепочка прошла в identity-плоскости, минуя эндпоинты. 75% вторжений — через valid credentials.

Kill chain identity-атаки: password spray → MFA fatigue → Golden SAML через AD FS token-signing certificate → OAuth Application Access Token → Account Manipulation с client secret к Service Principal. Каждый этап маппирован на MITRE ATT&CK с конкретным detection-сигналом.

KQL-запросы для Sentinel: password spray через корреляцию ResultType + дедупликация UPN, MFA fatigue через join отклонённых push с успешным входом. Sigma-правила из SigmaHQ по T1078.

💡 SOC строил detection вокруг эндпоинтов. APT сместились в плоскость, где этих сигналов просто нет по дизайну — один OAuth grant и месяцы тихого доступа.
EM.

Статья Consent phishing через OAuth: от фишинговой ссылки до контроля над Microsoft 365

  • 226
  • 0
Скелетный ключ с логотипом Microsoft лежит в стальном диалоговом окне с кнопкой подтверждения. Тёплый свет лампы выхватывает детали на фоне глубоких тёмно-бирюзовых теней.


☁️ Понедельник, 10:40 — зарегистрировано OAuth-приложение «HR Document Portal». 11:20 — первый сотрудник нажал «Принять». К полудню читалась переписка CFO и выгружались документы из SharePoint. MFA включена. Conditional Access настроен. Ни один алерт не сработал.

Consent phishing работает на уровне authorization, а не authentication — MFA, passkeys и phishing-resistant authenticators его не останавливают. После выданного consent сброс пароля не отзывает OAuth-токены: доступ живёт до явного revoke — недели и месяцы. Три варианта атаки: классический illicit consent grant, device code phishing через first-party приложения Microsoft, ConsentFix с drag-and-drop authorization code.

KQL-запросы для Sentinel: мониторинг consent grants с Mail.Read/Files.ReadWrite, device code flow с аномальным IP. Чеклист харденинга из девяти пунктов с привязкой к закрываемому вектору.

💡 Проблема не в технологиях — Token Protection и CAE существуют. Дефолтные настройки...

Статья OAuth Device Code Flow атака: от фишинга до persistent-доступа в Azure AD

  • 244
  • 0
Монитор светится в тёмной комнате: страница входа Microsoft с кодом авторизации и терминал с запросом к OAuth API. На столе кружка с кофе и свёрнутый USB-кабель.


☁️ На red team проекте для финтех-компании с P2-лицензиями Entra ID и FIDO2-ключами для C-level — persistent-доступ к почте CFO за 12 минут. Без перебора паролей, без обхода MFA, без единого credential prompt на стороне жертвы. Один device code, введённый пользователем на легитимной странице microsoft.com/devicelogin.

Device Code Flow проектировался для Smart TV и IoT — стал вектором initial access в Azure AD. MFA не спасает: пользователь сам проходит аутентификацию на легитимном портале Microsoft, токены уходят атакующему. Refresh-токен — до 90 дней. FOCI-ротация одного токена даёт доступ ко всему стеку M365: Azure CLI → Office → Teams → Outlook.

Генерация device code не создаёт Sign-In event в логах. KQL-запрос детекции: AuthenticationProtocol == "deviceCode". Ключевой вывод: политика блокировки Device Code Flow не входит в стандартные шаблоны security baseline Microsoft.

💡 Отправьте тестовый запрос на /devicecode с Azure CLI client_id. Если получили...

Статья SSRF против внутреннего админского API: от разведки до эксплуатации и defense in depth

  • 375
  • 0
SSRF-атака на внутренний admin API через уязвимый параметр URL


🔥 SSRF: один URL — и весь внутренний периметр у тебя в руках.

Уверены, что приватная сеть за NAT и фаерволом недосягаема? Сервер сам станет вашим прокси — он сидит внутри доверенного контура и видит то, что скрыто от интернета.

В этом гайде разбираем полный путь атаки: поиск SSRF-векторов и fingerprinting внутренней сети, обход фильтров через DNS rebinding и hex-кодирование IP, протокольный смаглинг по gopher:// и file://, parser differentials, выход на AWS-метаданные и эскалацию до RCE через Redis и PHP-FPM.

💡 Плюс реальная защита: network policies, allow-list, IMDSv2 и egress-мониторинг — для пентестеров и разработчиков, которые хотят играть на опережение.

Статья Атаки на OAuth 2.0: redirect URI manipulation, перехват токенов и authorization code interception на практике

  • 336
  • 2
Стальная стрелка-указатель с изгибом посередине лежит на чёрной ткани. Вдоль стрелки выгравирована надпись с адресом перенаправления, в тёмном фоне светятся янтарные огни.


🔓 На пентесте SaaS-платформы с SSO через Keycloak redirect_uri принимал path traversal: https://app.client.com/callback/../../../evil.com — валидация проверяла только начало строки. Authorization code пришёл на Burp Collaborator через 12 секунд после клика. Полный ATO, ноль алертов в WAF.

Redirect URI manipulation — самый недооценённый вектор OAuth: path traversal, open redirect chain, subdomain takeover через wildcard. Утечка authorization code через Referer-заголовок — analytics-скрипт на callback-странице сливает code в header к Google Analytics, ни один WAF не среагирует. PKCE downgrade если сервер не обязывает code_challenge. CSRF через отсутствие state-валидации.

Decision tree: девять условий — девять техник с инструментами. Где WAF слеп: implicit flow не попадает в серверные логи вообще, fragment URI до сервера не доходит.

💡 PKCE закрывает один сценарий. XSS в origin клиента обходит его полностью — атакующий контролирует оба компонента...

Статья Харденинг UEFI и защита firmware: BIOS-пароли, Secure Boot, TPM и Intel Boot Guard — что реально работает

  • 335
  • 0
Восковая печать тёмно-красного цвета с эмблемой щита расколота надвое чипом SPI Flash. На уцелевшей половине выдавлена надпись о уязвимости Secure Boot.


🔒 BlackLotus продавался за $5 000 как MaaS и обходил Secure Boot на Windows 11 с актуальным OS-патчем — через уязвимый загрузчик, который Microsoft не отозвала из dbx. SPI-программатор стоит полторы тысячи рублей. Firmware-атаки давно перестали быть привилегией спецслужб.

Четыре механизма — четыре уровня честности: BIOS-пароль обходится SOIC-клипсой за 5 минут (security theater). Secure Boot рассыпается при PKfail, CVE-2024-7344 и устаревшем dbx. TPM без remote attestation — дорогая железка, считающая хэши в пустоту. Только Intel Boot Guard в режиме Verified Boot аппаратно останавливает подмену прошивки — программатор за полторы тысячи рублей тут бесполезен.

Команды проверки через CHIPSEC, tpm2-tools, PowerShell. Правила корреляции SIEM: cloak.dat в ESP, Event ID 1796, отклонение PCR без тикета на обновление.

💡 EDR и XDR работают в Ring 0, firmware живёт в Ring -2 — между ними пропасть, в которую проваливается весь detection.

Статья Аппаратный пентест: JTAG, UART и SPI для извлечения прошивок и получения shell

  • 467
  • 2
Экран ЭЛТ-монитора с зелёным терминалом: команды извлечения прошивки, строки binwalk и хардкодированные учётные данные. Свечение фосфора, горизонтальные полосы развёртки, абсолютная тьма вокруг.


🔧 На аудите сетевого оборудования промышленного объекта четыре UART-пада нашлись за двадцать минут после вскрытия корпуса — два давали root shell без аутентификации, третий выплёвывал лог загрузки с паролями в plaintext. Initial access: паяльник и USB-TTL переходник за 300 рублей.

Три интерфейса — три задачи: UART (быстрый recon, shell за 15 минут), SPI flash (полный дамп прошивки через flashrom, обход bus contention), JTAG/SWD (real-time отладка, обход Secure Boot если не fused). Таблица выбора интерфейса под конкретную задачу.

Анализ извлечённого образа через binwalk: U-Boot, SquashFS, /etc/shadow с пустым хешем root, захардкоженные SSH-ключи и сервисные аккаунты. Ограничения: fused JTAG, зашифрованный образ (entropy ~8.0), BGA без тестовых точек.

💡 На каждом третьем аудите IoT первая критическая находка — не XSS в веб-панели, а UART-консоль с root-доступом, которую никто не пытался отключить.

Статья CRLF Injection: от HTTP Response Splitting до захвата сессий — эксплуатация и реальные CVE

  • 386
  • 0
Запечатанный конверт с восковой печатью разрывается по сгибу, обнажая скрытый HTTP-заголовок Set-Cookie внутри. Криминалистическая макросъёмка в десатурированной палитре с красным акцентом на слома...


💉 На bug bounty в финтехе три минуты на обнаружение CRLF injection в эндпоинте редиректа — и два часа на эскалацию до XSS через HTTP response splitting с захватом сессии администратора. Триажер поставил Medium. Два байта \r\n, грамотная цепочка — и совсем другой разговор.

CRLF injection не финальная цель, а точка входа. Голый %0d%0a без цепочки — Low или Informational. С эскалацией до session fixation через Set-Cookie, XSS через двойной CRLF или web cache poisoning через CDN-edge — High. Разбор кодировок и обходов (%250d%250a, bare LF для Node.js, unicode overlong), различия поведения Apache/Nginx/Express.js.

CVE-2023-4767 ManageEngine Desktop Central: CVSS-вектор по компонентам, почему CVSS 6.1 занижает реальный импакт при угоне сессии с доступом ко всем управляемым хостам. Где WAF пропускает injection.

💡 Нашли CRLF — не отправляйте голый PoC. Покажите цепочку до реального импакта.

Статья Reverse engineering мобильного SDK: разбор SilentSDK — RAT внутри легитимной библиотеки

  • 412
  • 0
Экран старого CRT-монитора в темноте показывает декомпилированный Java-код с деревом классов и строками перехваченного соединения. Зелёное свечение фосфора, горизонтальные полосы развёртки, глубока...


📱 CERT Polska описала cifrat — трёхстадийный Android-дроппер: внешний APK → нативная библиотека расшифровывает второй APK под маской Google Play Services → финальный RAT с WebSocket C2, стримом экрана и SOCKS5-туннелем. CyFirma — TaxiSpy с rolling XOR в .rodata нативного слоя. Supply chain через троянизированный SDK.

Полный цикл анализа: манифест (REQUEST_INSTALL_PACKAGES + PACKAGE_ADDED receiver = дроппер), jadx для Java-логики, radare2 для JNI-экспортов нативной библиотеки, восстановление rolling XOR с 32-битным overflow на Python. Frida-хук getServerListNative() — вместо часов реверса ARM-кода получаем расшифрованный C2-адрес за минуту.

MobSF для триажа пропускает многостадийные дропперы — финальный RAT не существует в APK до выполнения. Только комбинация четырёх методов даёт полную картину.

💡 Три шага аудита стороннего SDK занимают час и закрывают основной объём supply chain-угроз. Этот час никто не закладывает в...
🚀 Первый раз на Codeby?
Гайд для новичков: что делать в первые 15 минут, ключевые разделы, правила
Начать здесь →
💼 Вакансии и заказы в ИБ
Pentest, SOC, DevSecOps, bug bounty — работа и проекты от проверенных компаний
Карьера в ИБ →

Статистика форума

Темы
51 979
Сообщения
345 994
Пользователи
149 257
Новый пользователь
Neirotriton141