В октябре 2024 года Internet Archive пережил серию DDoS-атак. Пока инженеры восстанавливали доступность сервиса, атакующие взломали базу данных - в сеть утекли записи 31 миллиона пользователей. По оценке SOCRadar, DDoS здесь был классической дымовой завесой. И это не единичный случай: по данным NSFOCUS, DDoS-атаки всё чаще используются как smokescreen для прикрытия APT-операций, кражи данных и внедрения вредоносного ПО. SOC-команды, которые бросают все ресурсы на отражение флуда, рискуют пропустить основную угрозу. Причём пропустить не потому, что не умеют - а потому что смотрят не туда.
Бизнес-логика smokescreen DDoS - зачем атакующему шум
DDoS smokescreen атака - не про "положить сайт". Это про когнитивную перегрузку защитников. Атакующий решает конкретную задачу: пока дежурная смена SOC тушит пожар на периметре, параллельный вектор работает внутри сети. Финансовая мотивация прямая - украсть данные, установить бэкдор для последующего ransomware-деплоя, скомпрометировать облачную панель управления.В терминах MITRE ATT&CK схема выглядит так: DDoS-компонент - T1498 (Network Denial of Service) или T1499 (Endpoint Denial of Service), оба под тактикой Impact. Но Impact здесь не цель, а средство. Параллельно идёт настоящая операция: Initial Access через фишинг или эксплуатацию уязвимости, затем Lateral Movement с использованием Valid Accounts (T1078) или Remote Services (T1021), и финальная Exfiltration.
По данным IBM X-Force, атаки с использованием действительных учётных данных выросли на 71% в 2024 году. Именно этот вектор чаще всего идёт параллельно с DDoS, потому что аутентификация под легитимным аккаунтом не генерирует алертов по умолчанию. Атакующий покупает время - а по данным CrowdStrike, среднее время lateral movement после initial access в 2024 году составило 62 минуты, рекордный случай - 51 секунда. За час DDoS-шторма можно пройти от foothold до полной компрометации домена.
По данным Verizon DBIR 2025, 38% утечек данных связаны с кражей учётных данных. Если эти украденные креды используются под прикрытием DDoS, когда SOC перегружен - шансы на обнаружение падают кратно.
DDoS как прикрытие взлома: kill chain от флуда до эксфильтрации
Типовой kill chain smokescreen-атаки
Многовекторная атака DDoS как прикрытие работает в несколько фаз:- Подготовка (дни или недели до атаки). Атакующий уже получил initial access - украденные учётные данные, фишинговый бэкдор, эксплуатируемая уязвимость на периметре. DDoS-ботнет арендуется отдельно. По данным Palo Alto Networks, сервисы DDoS-for-Hire активно используются для атак на критическую инфраструктуру, включая здравоохранение.
- Запуск DDoS (T1498/T1499). Объёмная атака на внешний периметр. Цель - не столько отказ в обслуживании, сколько создание шума в SIEM и загрузка SOC-команды. Вектора: DNS amplification, NTP reflection, HTTP/2 Rapid Reset. По данным NSFOCUS, атака HTTP/2 Rapid Reset достигала 3,98 млрд запросов в секунду. При таких объёмах любая система мониторинга начинает захлёбываться.
- Параллельная операция (минуты после начала DDoS). Используя заранее полученный доступ, атакующий выполняет lateral movement. Пока SOC занят DDoS-инцидентом, на внутренних хостах происходит: аутентификация под легитимными учётными записями, обращение к файловым шарам, выгрузка данных через DNS-туннель или HTTPS на внешний C2.
- Эксфильтрация и закрепление. Данные уходят наружу. Бэкдоры устанавливаются для последующего возврата. DDoS прекращается - SOC фиксирует "успешное отражение", не подозревая, что основная операция уже завершена.
Реальные инциденты: DDoS и кража данных одновременно
Internet Archive (2024). Серия DDoS-атак вывела из строя инфраструктуру. Параллельно атакующие получили доступ к базе данных - утекли записи 31 миллиона пользователей. DDoS маскировка вторжения в чистом виде.Code Spaces (2014). DDoS отвлекающая атака загрузила команду безопасности. Тем временем атакующие получили доступ к панели управления AWS. Были удалены данные, резервные копии и конфигурации кода. Компания прекратила существование. Эксперт Neustar, описавший инцидент, подчеркнул: «Когда вы имеете дело с DDoS-атакой, все силы бросаются на неё. Другие угрозы остаются незамеченными». Собственно, это и есть вся суть smokescreen в одном предложении.
Occupy Central, Гонконг (2014). DDoS мощностью до 500 Гбит/с обрушился на сайты движения. По данным Forbes, за атакой стояли государственные структуры. Пока ресурсы были недоступны, собирались персональные данные сотрудников организации - впоследствии использованные для целевого фишинга. Здесь отвлекающий манёвр в кибербезопасности работал на политические цели, а не на прямую финансовую выгоду.
DDoS как отвлечение SOC: почему команда слепнет
Alert fatigue и приоритизация инцидентов SOC
Шум в SIEM при DDoS - главное оружие атакующего. При объёмной атаке SIEM генерирует сотни алертов в минуту: превышение порогов трафика, срабатывания IDS/IPS, уведомления от балансировщиков, ошибки доступности. Аналитик L1 переключается в режим "тушения пожара" - все ресурсы уходят на восстановление доступности.И вот тут происходит критическая ошибка: события, не связанные с DDoS, откладываются "на потом". Одна аномальная аутентификация на контроллере домена через RDP в 3:17 ночи теряется в потоке 12 000 алертов о сетевом флуде. По данным Mandiant, 57% организаций узнают об инциденте от внешней стороны, а не от собственного SOC - и DDoS-smokescreen этот процент заметно увеличивает.
Телеметрические слепые зоны
При DDoS страдает не только внимание аналитиков - деградирует сама телеметрия:- NetFlow/sFlow-коллекторы перегружаются объёмом данных и переходят на агрессивный сэмплинг (каждый 100-й пакет вместо каждого 10-го), теряя детализацию
- DNS-логирование деградирует, если DNS-серверы сами под атакой - а именно через DNS-туннели часто идёт эксфильтрация
- SIEM упирается в лимит событий в секунду (EPS) - события с внутренних источников дропаются в пользу потока алертов с периметра
- Zeek/Suricata на inline-сенсорах могут пропускать пакеты при перегрузке, создавая пробелы в записи сессий
Обнаружение скрытой атаки за DDoS: практика для SOC-аналитика
Требования к окружению
- SIEM: Splunk Enterprise Security 7.x+ / Elastic Security 8.x+ / MaxPatrol SIEM / KUMA - с настроенным сбором Windows Security EventLog и DNS-логов
- Сетевые сенсоры: Zeek (ранее Bro) или Suricata для записи conn.log, dns.log, ssl.log; NetFlow/sFlow коллектор
- Endpoint: Sysmon (конфиг SwiftOnSecurity или аналог) или EDR (CrowdStrike Falcon, Kaspersky EDR Expert, PT EDR) на критичных серверах
- Данные: Windows Security EventLog (EventCode 4624, 4625, 4768, 4769, 7045), DNS-запросы, NetFlow с внутренних сегментов
Корреляционные правила для параллельных векторов
Ключевой принцип: при любом DDoS-инциденте SOC обязан параллельно мониторить внутреннюю сеть на признаки бокового перемещения и эксфильтрации. Не после DDoS. Не "когда разберёмся с флудом". Параллельно.Пример корреляции для Splunk (адаптируйте под свои индексы и lookup-таблицы):
Код:
index=wineventlog EventCode=4624 LogonType=10
| where _time >= relative_time(now(), "-60m")
| stats count dc(dest) as unique_hosts by src_ip, Account_Name
| where unique_hosts > 3
| join type=inner src_ip
[search index=alerts category="ddos_active"]threat.technique.id: "T1021" и условием активного DDoS в кастомном индексе алертов.Второй критически важный детект - аномальные DNS-запросы во время DDoS, указывающие на DDoS и утечку данных одновременно:
Код:
index=dns sourcetype=bro_dns
| eval qlen=len(query)
| where qlen > 50
| stats count values(query) as queries by src_ip
| where count > 100
| table src_ip count queriesСетевые аномалии, которые видны за шумом DDoS
Даже при деградации телеметрии ряд индикаторов бокового перемещения остаётся доступным:| Индикатор | Где смотреть | Что означает |
|---|---|---|
| Новый SMB-трафик между хостами без истории взаимодействия | Zeek conn.log, NetFlow | Lateral movement (T1021.002) |
| Аутентификация сервисного аккаунта на нетипичном хосте | Windows EventLog 4624/4625 | Использование украденных кредов (T1078) |
| Исходящий HTTPS к новому IP без SNI или с самоподписанным сертификатом | Zeek ssl.log, Suricata | C2-коммуникация |
| Резкий рост upload-трафика с внутреннего хоста | NetFlow | Эксфильтрация |
| DNS-запросы с высокой энтропией к одному домену | Zeek dns.log | DNS-туннелирование |
| Создание новых сервисов на серверах | Windows EventLog 7045, Sysmon EventID 1 | Persistence (T1543) |
Обратите внимание на анализ соотношения входящего и исходящего трафика per host - техника D3-PHDURA (Per Host Download-Upload Ratio Analysis) из фреймворка MITRE D3FEND. В норме большинство рабочих станций скачивают значительно больше, чем отправляют. Резкое изменение этого соотношения во время DDoS - красный флаг, указывающий на эксфильтрацию.
D3FEND-mapping и Sigma: готовые детекты
Для техник T1498 и T1499 MITRE D3FEND определяет пять защитных техник категории Detect, работающих с артефактом Network Traffic:D3-PMAD (Protocol Metadata Anomaly Detection) - обнаружение аномалий в метаданных протоколов. На практике: Zeek генерирует weird.log для нестандартных протокольных событий - в связке с DDoS-алертом это помогает выявить нетипичный трафик, маскирующий C2.
D3-CSPP (Client-server Payload Profiling) - профилирование полезной нагрузки клиент-сервер. Позволяет выделить C2-трафик, маскирующийся под легитимные протоколы.
D3-NTSA (Network Traffic Signature Analysis) - сигнатурный анализ. Suricata с правилами ET Open или собственными сигнатурами на известные C2-фреймворки.
D3-UGLPA (User Geolocation Logon Pattern Analysis) - анализ геолокации аутентификаций. Если во время DDoS появляется логин из нетипичной геозоны - приоритетный алерт.
В репозитории SigmaHQ для T1498 доступно 3 правила, для T1499 - 8. Из практически полезных:
opencanary_ntp_monlist.yml детектит NTP monlist-запросы, характерные для NTP amplification (T1498). Правило proc_creation_win_malware_blackbyte_ransomware.yml привязано к T1498 - BlackByte ransomware известен использованием DDoS как элемента многовекторной атаки. Правила web_nginx_core_dump.yml и web_apache_segfault.yml ловят признаки DoS-воздействия на веб-серверы.Ограничения стандартных подходов к обнаружению скрытой атаки
Ни один из описанных методов не работает универсально. Было бы нечестно этого не сказать. Реальные ограничения:| Подход | Работает когда | Не работает когда |
|---|---|---|
| Корреляция DDoS + auth events в SIEM | EPS в пределах лицензии, внутренние события доходят | EPS превышен, внутренние логи дропаются в очереди |
| DNS-туннель-детект | DNS-логи собираются полноценно | DNS-сервер сам под атакой, логирование деградирует |
| NetFlow-анализ upload ratio (D3-PHDURA) | Коллектор работает без сэмплинга | При DDoS более 10 Gbps коллектор переходит на агрессивный сэмплинг |
| Sigma-правила на endpoint events | Sysmon или EDR установлен и работает | На legacy-хостах без EDR - полная слепая зона |
| Геолокация аутентификаций (D3-UGLPA) | Атакующий заходит с IP из нетипичной геозоны | Атакующий работает через скомпрометированный внутренний хост или VPN |
| Zeek ssl.log для C2-детекта | Трафик идёт через мониторируемый сегмент | C2 через разрешённые облачные сервисы (domain fronting) |
Критически важный момент: если SIEM упирается в EPS-лимит при DDoS - вы теряете именно те события, которые нужны для обнаружения параллельной атаки. Решение - приоритизация источников. Логи аутентификации (Windows Security), DNS-запросы и NetFlow с внутренних сегментов должны иметь более высокий приоритет в очереди, чем потоковые алерты с периметрального IDS.
Реализация зависит от SIEM-вендора:
- Splunk Enterprise Security: приоритизация inputs через
props.confиtransforms.conf, выделение dedicated indexer для auth/DNS источников - Elastic Security 8.x+: data streams с разным ILM policy, hot-warm архитектура с приоритизацией auth-индексов
- MaxPatrol SIEM: приоритизация задач коллекторов, отдельная нормализация для критичных источников
Чеклист дежурного аналитика: реагирование SOC на DDoS
Распечатайте и повесьте рядом с монитором. Применяется в первые 15 минут после начала DDoS-инцидента.Большинство SOC-команд реагируют на DDoS как на единственную угрозу. Вся смена переключается на один дашборд, один поток алертов, одну проблему - и это именно то, на что рассчитывает атакующий. По данным Mandiant, медианное время обнаружения злоумышленника в сети в 2024 году - 11 дней. Во время DDoS это время увеличивается, потому что нормальный процесс threat hunting останавливается.
Я разбирал инцидент, где DDoS на веб-периметр длился 4 часа. Вся смена работала на восстановление доступности. На следующий день при рутинном анализе обнаружился аномальный SMB-трафик между двумя серверами, которые раньше никогда не взаимодействовали - трафик начался через 12 минут после старта DDoS. Атакующий уже был внутри и использовал флуд как прикрытие для бокового перемещения. Нашли поздно - не потому что не было инструментов, а потому что все смотрели в одну точку. Правило "при DDoS выделяй минимум одного аналитика только на внутреннюю телеметрию" - в тот момент в playbook отсутствовало. Теперь не отсутствует.
Проблема не в технологиях. Splunk, Elastic, MaxPatrol - любой из них способен построить корреляцию DDoS-флага с аномалиями во внутренних аутентификациях. Проблема в организации процесса: SOC-команды тренируются отражать DDoS как изолированный инцидент. Табличные учения по smokescreen-сценарию - редкость. Пока каждый DDoS не станет триггером для параллельной проверки внутренней сети, smoke screen кибератака останется одним из самых результативных приёмов. Атакующий выигрывает не за счёт сложных эксплойтов, а за счёт человеческой предсказуемости.
Возьмите чеклист выше и прогоните его на следующем DDoS - даже учебном. Посмотрите, сколько пунктов ваша команда выполнит за 15 минут. Результат может неприятно удивить.
Последнее редактирование модератором:
