Кибербезопасность
По данным последних исследований IT, каждые четыре секунды в компьютерную сеть компании попадает вредоносная программа и каждые 32 минуты за пределы организации уходит ценная информация. Утерянные данные могут стать источником манипуляций, поэтому так важно выстроить максимально эффективную защиту. Обеспечить информационную безопасность можно сотнями способов, сочетая разные продукты – антивирусы, межсетевые экраны, SSL-сертификаты, разграничение правд доступа, системы защиты от DDoS-атак. Важнейшей стороной информационной безопасности становится определение угроз, а это невозможно без определения объектов защиты. Только поняв, что и от чего мы защищаем, можно выстроить грамотную оборону. Сейчас актуален переход к облачным решениям, которые дают возможность быстро развёртывать системы безопасности, отдавая их управление поставщикам облачных сервисов. В этом разделе собраны актуальные материалы об информационной безопасности от построения информационной защиты до её оптимизации.
Статья Атаки на SAML аутентификацию: XML Signature Wrapping, Golden SAML и обход федеративного SSO
Перехватил SAMLResponse в Burp, переместил подписанный Assertion в другую ветку DOM, вставил поддельный NameID=admin@company.local — SP пустил как доменного администратора. Подпись валидна. Три правки в XML, ноль взаимодействия с IdP.XML Signature Wrapping: валидатор проверяет одну часть документа, приложение обрабатывает другую. SAML Raider в Burp — восемь вариантов XSW от замены корневого элемента до вложения в Extensions. CVE-2024-45409 ruby-saml (CVSS 10.0) и CVE-2025-47949 samlify (CVSS 9.9) — parser differential: два парсера в одной библиотеке видят разные элементы.
Golden SAML: Token Signing Certificate из ADFS → shimit генерирует валидный Assertion для любого пользователя к любому SP. Ноль событий в IdP. Silver SAML через external signing cert в Entra ID. Decision tree выбора вектора: XSW для initial access, Golden/Silver SAML для lateral movement.
SAML ломают не через криптографию, а через парсеры — fingerprinting библиотеки SP первый...Статья PCI DSS пентест на практике: scope, методология и отличия от стандартного тестирования
Отчёт предыдущей команды QSA заворачивал трижды: нет proof of exploitation, маппинг на CDE отсутствует, segmentation testing подменён выводом Nessus. Тот же объект, другой подход к документированию — принят с первого раза. Разница между «провести пентест» и «провести PCI DSS пентест» целиком в деталях.PCI DSS v4.0 с марта 2024 — единственный действующий стандарт. Requirement 11.4: retesting обязателен с evidence фикса, segmentation testing — отдельный блок каждые полгода для service providers. Kill chain привязан к CDE: lateral movement от non-CDE до cardholder data, а не до Domain Admin. Команды nmap с флагом --reason для доказательства работы firewall-правил.
Шесть компонентов отчёта без которых QSA завернёт: методология, scope с маппингом на CDE, CVSS + proof of exploitation, результаты segmentation testing, evidence ретеста, квалификация тестировщика.
Пентест за 3 000$ который заворачивают, обходится дороже чем за 15 000$ принятый с первого раза.Статья Обход Secure Boot: техники атаки на верификацию загрузчика для пентестеров
Red Team-проект: SYSTEM получен через Kerberoasting, persistence ниже ОС не получается — Secure Boot отклоняет неподписанный загрузчик. Отключить через BIOS? Оставляет следы. Задача другая: обойти верификацию, сохранив видимость штатной работы.CVE-2024-7344 (CVSS 8.2): UEFI-приложение Reloader подписано Microsoft, но использует кастомный PE-загрузчик вместо штатных LoadImage/StartImage. Грузит произвольный бинарь из cloak.dat без проверки подписи — код исполняется в UEFI-контексте до старта ОС. Attack path: admin → монтирование ESP → reloader.efi + cloak.dat → bcdedit → перезагрузка. Secure Boot формально включён, фактически обойден.
GNU/Linux через MOK-ключи: собственный ключ не попадает в dbx-обновления Microsoft. SPI-флеш при физическом доступе для legacy без Boot Guard. Chipsec для fingerprinting: common.secureboot.variables и common.bios_wp.
Между «Secure Boot включён» и «цепочка загрузки верифицирована end-to-end»...Статья Аудит сервисных аккаунтов Active Directory: инвентаризация, Kerberoasting-риски и least privilege
Понедельник, 9:15. Аудит AD банка — «у нас всё под контролем». Через два часа: 847 сервисных аккаунтов, 312 с SPN, 94 в Domain Admins, у 23 пароль не менялся пять лет. Контролировало их ноль человек. Каждый такой аккаунт — готовая мишень для Kerberoasting.Service account sprawl: организация имеет в 10–20 раз больше сервисных аккаунтов, чем пользовательских. У них нет рабочих часов и географических паттернов — поведенческие алерты не срабатывают. PowerShell-запрос для инвентаризации всех SPN с возрастом пароля и членством в Domain Admins. BloodHound Cypher для визуализации путей эскалации.
gMSA как технический ответ на Kerberoasting: 120-символьный автопароль, ротация 30 дней, никто его не знает. Правило корреляции для SIEM: EventID 4769 с TicketEncryptionType 0x17 > 10 запросов за 5 минут. Чеклист из 10 пунктов.
Каждый аудит начинается с «мы точно знаем все свои сервисные аккаунты» — и каждый раз реальное число в 3–5 раз больше.Статья Реверс-инжиниринг прошивок: binwalk, Ghidra и статический анализ firmware для поиска уязвимостей
На аудите IP-камеры binwalk выдал ноль сигнатур — ровная линия энтропии 7.98. Два часа в Ghidra, XOR-декриптор в U-Boot — и стандартный SquashFS с root-паролем в открытом тексте и CGI-скриптом, пробрасывающим HTTP-параметры прямо в system(). Три Critical за одну сессию, ни одного запуска устройства.Workflow от блоба до уязвимостей: file + strings + binwalk -E для определения стратегии, binwalk -e + sasquatch/jefferson для извлечения FS, Ghidra для трассировки system() от HTTP-параметра до вызова без санитизации. Decision tree когда binwalk молчит: сигнатуры не найдены при энтропии >7.9 — искать декриптор в загрузчике.
Три устойчивых класса: захардкоженные credentials (CWE-798), command injection через system() (CWE-78), buffer overflow без stack canaries (CWE-120). Чеклист аудита из 15 пунктов с CWE-идентификаторами.
Автоматизация найдёт strcpy() без проверки — не найдёт логическую ошибку в state machine кастомного протокола.Статья Passkeys и корпоративная безопасность: attack surface FIDO2 глазами пентестера
Организация с Okta, включённый passwordless через FIDO2, всё по best practices — session token администратора получен за сорок минут. Passkeys не помогли: аутентификация прошла штатно, а сессионный cookie уехал на AitM-прокси. Вендоры продают «конец фишинга», реальный attack surface говорит о другом.Domain binding убивает credential phishing — это математика, не маркетинг. Но атака не заканчивается на краже credential. AitM-прокси транслирует запрос на настоящий IdP, пользователь проходит passkey-аутентификацию штатно, session cookie перехватывается. Из шести корпоративных деплоев FIDO2 за полтора года — в пяти из шести перехват сессии работал без модификаций.
Synced passkeys против device-bound: разный attack surface для облачных аккаунтов и физического доступа. Fallback-методы как возврат к классике. Чеклист аудита из десяти пунктов.
Индустрия закрыла phishing-resistant credentials и упустила phishing-resistant sessions.Статья Аудит безопасности Telegram-ботов
Telegram-бот принимает user_id без проверки и возвращает данные любому — IDOR в одну строку. Токен лежит в публичном репозитории — token theft без взлома. Webhook не проверяет источник — любой желающий шлёт «обновления». Безопасность ботов ломают не APT-атаками, а потому что базовые вещи сделаны на скорую руку.Четыре точки атаки: Bot API, Webhook, Mini Apps, user input. Типовые уязвимости: token theft через открытый репозиторий, IDOR через user_id, SQL injection из callback_data, webhook spoofing без secret_token. Защита: env/Vault для токенов, IP whitelist + TLS + secret_token для webhook, initData validation через HMAC-SHA256 для Mini Apps.
DevSecOps-чеклист: bandit и semgrep в CI/CD, secret scanning, security regression tests на pytest. Защита от фишинговых дублёров: уникальное имя, регистрация вариантов с похожими символами.
Безопасность бота — не ритуал после релиза, а часть обычного цикла разработки.Статья Обход защиты BIOS: отключение 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 гайд
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
Понедельник, 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 существуют. Дефолтные настройки...