Понедельник, 9:15. Первый день assumed breach в компании с действующим сертификатом ISO 27001, SOC из пяти аналитиков и ИБ-стратегией на 120 страниц. К 11:30 BloodHound показал путь до Domain Admin через сервисный аккаунт
svc_backup - пароль Summer2021!, не менялся три года. К 13:00 - полный контроль над Active Directory. Политика управления привилегированным доступом у этой компании занимала 47 страниц и была согласована CISO кварталом ранее.Assumed breach моделирует сценарий, в котором атакующий уже внутри - через фишинг, скомпрометированную подрядную учётку или инсайдера. SOC должен обнаруживать такую активность вне зависимости от вектора проникновения. В этом проекте - не обнаружил.
Формальная безопасность vs реальная защита: где ломается security maturity model
Типичная оценка зрелости ИБ выглядит так: компания берёт фреймворк (NIST CSF v2.0, OWASP SAMM, собственную шкалу 0-4), заполняет опросник, получает тепловую карту по доменам - Identify, Protect, Detect, Respond, Recover. Уровень зрелости процессов безопасности фиксируется в отчёте, CISO планирует бюджет, совет директоров кивает. Все довольны.
Проблема не в фреймворках. Проблема в механизме верификации. NIST SP 800-53 требует задокументированных политик по каждому семейству контролей - AC-1 (Access Control), AU-1 (Audit), IR-1 (Incident Response). Все три контроля предполагают не только разработку документов, но и процедуры их исполнения. Между "политика написана" и "политика исполняется" - пропасть, которую видно только при пентесте корпоративной сети.
По оценке Liverton Security, формулировка "No issues detected" в отчёте сканера создаёт ложное чувство защищённости. Compliance удовлетворяет аудитора, но не доказывает, что контроли выдержат реальную атаку. Аудит безопасности по чеклисту и имитация атак на инфраструктуру - два принципиально разных процесса. Первый проверяет, что написано. Второй - что работает.
Финансовые последствия разрыва между политикой и практикой ИБ стали конкретнее. С введением оборотных штрафов за повторные утечки персональных данных (КоАП РФ, ст. 13.11 в ред. ФЗ №420-ФЗ от 30.11.2024) стоимость расхождения между заявленной и реальной зрелостью измеряется десятками миллионов рублей. Сверху - расходы на incident response, уведомление регулятора (ч. 3.1 ст. 21 ФЗ-152 в ред. ФЗ-266 от 14.07.2022 обязывает направить первичное уведомление в РКН в течение 24 часов, результаты внутреннего расследования - в течение 72 часов) и репутационные потери.
Провалы ИБ-стратегии, которые вскрывает внутренний пентест
Пять паттернов, которые встречаются в каждом втором assumed breach-проекте. Каждый маппится на конкретные TTPs по MITRE ATT&CK и занимает своё место в kill chain атаки.
Привилегированные аккаунты без контроля жизненного цикла
[Применимо: внутренний пентест, assumed breach / grey box - выданы учётные данные рядового пользователя]Место в kill chain: credential access -> privilege escalation -> lateral movement.
Сценарий стандартный. Получаем доменную учётку рядового сотрудника, запускаем BloodHound, собираем граф AD. Картина повторяется из проекта в проект: сервисные аккаунты с правами Domain Admin или Enterprise Admin, созданные под конкретную задачу (бэкап, мониторинг, интеграция с 1С) и забытые. Пароли статичные, часто словарные.
Это Valid Accounts (T1078, Initial Access / Persistence / Privilege Escalation / Defense Evasion) в комбинации с Unsecured Credentials (T1552, Credential Access). Атакующему не нужен эксплойт - он использует легитимный аккаунт. Для сравнения: вектор из смежного сегмента может потребовать эксплуатации уязвимости вроде CVE-2026-8037 в Progress LoadMaster (CVSS 9.6, AV:A - атака из смежной сети, CWE-77 - OS Command Injection в API; см. advisory Progress), но внутри периметра всё проще - достаточно запроса к AD.
Заявлено в стратегии: "Все привилегированные учётные записи проходят ежеквартальный аудит, пароли меняются раз в 90 дней." По факту:
svc_backup - Domain Admin, пароль не менялся 1100 дней, последний интерактивный логон - 2022 год.Detection-сигнал, которого не было: логон сервисного аккаунта с рабочей станции пользователя вместо выделенного сервера. В MaxPatrol SIEM, KUMA или Elastic Security 8.x это одно правило корреляции - event ID 4624, LogonType 10 или 3, source host не входит в whitelist серверов для этого аккаунта. Одно правило. Его не было.
SIEM есть - detection нет
[Применимо: внутренний пентест, оценка эффективности ИБ мониторинга]Место в kill chain: все этапы - проверяем, на каком SOC заметит активность атакующего.
Компания вложила десятки миллионов рублей в SIEM. Лицензии активны, логи собираются, дашборды горят на экранах SOC. При аудите безопасности выясняется: из 200+ преднастроенных правил корреляции активны 12. Из этих 12 - половина генерирует столько алертов, что аналитики перестали на них реагировать. Alert fatigue в чистом виде.
Запускаешь сканирование внутренних подсетей
nmap -sV - Network Service Discovery (T1046, Discovery) - сотни хостов проходят без единого алерта. Дампишь LSASS через rundll32.exe C:\Windows\System32\comsvcs.dll MiniDump <lsass_PID> C:\temp\out.dmp full (в 2025 году детектируется Defender/EDR по поведению, но тут EDR молчит) - OS Credential Dumping: LSASS Memory (T1003.001, Credential Access), плюс Signed Binary Proxy Execution: Rundll32 (T1218.011, Defense Evasion) - тишина.NIST CSF v2.0, категория DE.AE-01, требует установленного baseline сетевых операций и ожидаемых потоков данных. Без baseline любой алерт - шум, и аналитик его игнорирует.
Для MaxPatrol SIEM и KUMA есть готовые контент-паки с правилами под типовые ATT&CK-техники. Для Elastic Security - встроенные detection rules с маппингом. Проблема не в отсутствии инструментов, а в том, что их никто не калибровал под конкретную инфраструктуру. Правило без настроенного baseline - генератор шума, не detection.
Бэкапы, которые не восстанавливаются
[Применимо: assumed breach, проверка устойчивости к ransomware, деструктивный сценарий]Место в kill chain: impact - оцениваем, выживет ли компания после деструктивного воздействия.
На дебрифинге CISO уверенно заявляет: "Даже если зашифруете всё - у нас есть бэкапы. RPO - 4 часа, RTO - 8." Просим показать последний тест восстановления. Пауза. Оказывается, тестовое восстановление проводили один раз - при внедрении системы два года назад. С тех пор инфраструктура выросла, добавились новые базы данных, а бэкап-агент на трёх серверах перестал работать после обновления ОС. Никто не заметил.
NIST SP 800-53, контроль CP-1 (Contingency Planning), требует не просто наличия плана восстановления, но и процедур его регулярной проверки.
В одном из проектов резервные копии AD (ntds.dit) хранились на том же контроллере домена, который мы скомпрометировали. Атакующий получил и продуктив, и бэкапы одним действием. Изоляция бэкап-инфраструктуры от основного домена - контроль, который декларируется в большинстве ИБ-стратегий и регулярно не реализован на практике.
Сегментация сети существует только на схеме
[Применимо: внутренний пентест, lateral movement, grey box]Место в kill chain: lateral movement -> persistence.
Официально - VLAN'ы, ACL'ы, DMZ, микросегментация. На деле - от рабочей станции бухгалтера видны все подсети, включая серверы баз данных и контроллеры домена. Remote Services (T1021, Lateral Movement) работают без ограничений: RDP, SMB, WinRM - всё открыто между сегментами. Красивая схема сети в Visio, а на практике - плоская сеть.
По данным Liverton Security, endpoint'ы с Windows Server 2003 (end of support с 2015 года) до сих пор встречаются в инфраструктурах и доступны по RDP без jump host и MFA. CISA и FBI в совместном advisory указывали на exposed RDP как основной enabler ransomware-атак. NIST SP 800-207 (Zero Trust) требует, чтобы ни один ресурс не считался доверенным на основании сетевой локации.
Запускаешь
crackmapexec smb 10.0.0.0/8 --gen-relay-list targets.txt - список хостов без SMB Signing часто исчисляется сотнями. NTLM relay возможен из любой точки сети. Сегментация? Какая сегментация.Пароли в скриптах и GPO
[Применимо: внутренний пентест, credential access, legacy-инфраструктура]Место в kill chain: credential access -> privilege escalation.
Group Policy Preferences с паролями в
cpassword - уязвимость, закрытая Microsoft ещё в 2014 году (MS14-025). На пентестах в 2025 году мы до сих пор находим скрипты в SYSVOL с захардкоженными паролями, PowerShell-автоматизации с $password = "P@ssw0rd123" в открытом виде, .xml-файлы с учётными данными для scheduled tasks. 2014 год. Одиннадцать лет прошло.Brute Force (T1110, Credential Access) часто не требуется - Unsecured Credentials (T1552) лежат в общедоступных шарах. Одна команда - и список захардкоженных паролей готов. TrustedSec описывают аналогичную картину: vulnerability scanning подменяет полноценный пентест, и такие "низкотехнологичные" находки остаются невидимыми для автоматических сканеров. Сканер не ищет пароли в скриптах - он проверяет CVE.
Detection-чеклист: правила корреляции для SOC
Минимальный набор правил, которые должны срабатывать при типичном assumed breach-сценарии. Если больше половины отсутствует - оценка зрелости ИБ вашей компании не отражает реальность.| TTP (ATT&CK) | Что ловить | Источник событий | Логика правила |
|---|---|---|---|
| T1078 Valid Accounts | Логон сервисного аккаунта с нетипичного хоста | Windows Security Log (4624) | Account IN svc_list AND SourceHost NOT IN svc_whitelist |
| T1003 Credential Dumping | Доступ к процессу LSASS | Sysmon (EventID 10), EDR | TargetImage = lsass.exe AND GrantedAccess IN (0x1010, 0x1410, 0x1438, 0x143a, 0x1FFFFF) AND SourceImage NOT IN av_edr_whitelist |
| T1046 Network Discovery | Сканирование портов с рабочей станции | NetFlow, Firewall | Source = workstation AND unique_dst_ports > 50 за 5 мин |
| T1021 Remote Services | RDP не через bastion | Windows Security (4624, LogonType 10) | SourceHost NOT IN bastion_list |
| T1110 Brute Force | Password spraying | Windows Security (4625) | 1 source, >10 аккаунтов, <30 мин |
| T1552 Unsecured Creds | Массовый доступ к SYSVOL | File Audit (4663) | ObjectName contains SYSVOL AND unique_files > 20 |
| T1562.001 Disable or Modify Tools | Остановка EDR-агента | EDR heartbeat, System Log (7036) | ServiceName IN [csfalconservice, kavfsslp, SentinelAgent] AND Action = Stop |
Вендор-специфика: для CrowdStrike Falcon - отслеживайте пропадание heartbeat хоста в консоли Falcon. Для Kaspersky Endpoint Security - event "Protection component disabled" в KSC. Для Elastic Agent - отсутствие документов от агента за 5+ минут при обычно стабильном потоке. Каждое правило требует калибровки под конкретную среду: whitelist'ы, baseline активности, пороги. Без калибровки - это не detection, а генератор шума.
Чеклист для gap analysis: что проверять после пентеста корпоративной сети
Готовый список для включения в отчёт или использования как scope аудита безопасности:Результат - не "список уязвимостей", а gap analysis информационной безопасности: расхождение между заявленным уровнем зрелости и реальным. Каждый пункт маппится на контроль NIST SP 800-53 и функцию NIST CSF v2.0.
Оценка зрелости ИБ в её нынешнем виде - упражнение для аудиторов, не для защитников. Компания заполняет опросник, получает тепловую карту, планирует бюджет - и через полгода на пентесте выясняется, что ни один контроль не работает так, как описан в стратегии. За последние три года я провёл больше двух десятков assumed breach-проектов. В каждом находился сервисный аккаунт с правами домен-админа. В каждом SIEM пропускал сканирование подсетей. В каждом втором бэкапы не тестировались на восстановление. И это компании с бюджетом на ИБ в десятки миллионов рублей, с CISO в C-suite и формально зрелыми процессами. Проблема не в NIST CSF и не в OWASP SAMM - фреймворки дают адекватную структуру. Проблема в том, что оценку зрелости проводят те же люди, которые строили процессы. Red team и assumed breach - единственный способ получить честную картину, потому что у пентестера нет мотивации завышать результат. Если ваш SOC ни разу не ловил пентестера в первые четыре часа работы - на codeby.net коллеги ведут тред по assumed breach postmortem'ам с разбором, какие detection-правила сработали и какие нет, с конфигурациями под конкретные SIEM.
Последнее редактирование модератором:
