На пентесте финтех-компании в прошлом году мы получили initial access за четыре часа - без единого эксплойта. Публичный дамп Exploit.In (593 миллиона пар email
assword, по данным Have I Been Pwned), фильтрация по домену заказчика, нормализация, прогон через OpenBullet 2 по корпоративному OWA - 23 учётки валидные. У семи не было MFA. Credential stuffing атаки - не взлом и не эксплуатация CVE, а масштабированное переиспользование чужих паролей. И оно до сих пор даёт initial access быстрее любого сканера уязвимостей.Бизнес-логика: место credential stuffing в kill chain
Credential stuffing атаки и password spraying атака - два подхода к одной задаче: получить валидные учётные данные для initial access. В MITRE ATT&CK обе техники живут под T1110 (Brute Force): credential stuffing - T1110.004, password spraying - T1110.003. Обе относятся к тактике Credential Access, но дальше пути расходятся.Полная цепочка: утечка базы паролей -> нормализация дампа -> автоматизированная проверка на целевых сервисах -> account takeover атака -> lateral movement или exfiltration. По данным Okta State of Secure Identity Report (2023), около 24% попыток аутентификации на крупных identity-платформах - credential stuffing. Microsoft оценивает, что MFA остановила бы 99,9% автоматизированных атак на учётные записи (Alex Weinert, 2019). Современные целевые техники (AiTM, MFA fatigue) снижают эту цифру, но MFA отсутствует на значительной части корпоративных порталов, особенно внутренних.
Для атакующего это экономически выгодная операция: combo list бесплатен или стоит копейки, инструменты open source, а конверсия даже в 0,1% на базе из миллиона записей даёт тысячу скомпрометированных аккаунтов. OWASP относит слабую защиту аутентификации к A07:2021 - Identification and Authentication Failures, явно включая credential stuffing как квалифицирующий признак.
Credential stuffing vs password spraying атака: когда что применять
Путаница между этими техниками - стандартная проблема даже у опытных пентестеров. Разница принципиальная, и от неё зависит выбор инструментов, скорость атаки и методы evasion.| Критерий | Credential stuffing | Password spraying |
|---|---|---|
| Входные данные | Реальные пары loginassword из утечек | Список логинов + 3-5 популярных паролей |
| Предположение | Пользователь переиспользует пароль | Пользователь выбрал слабый пароль |
| Скорость | Высокая (тысячи попыток/мин) | Низкая (low-and-slow, 1 пароль за цикл) |
| Шум в логах | Множество failed logins с разных IP | 1-2 failed login на аккаунт, пауза |
| Срабатывание lockout | Нет (1 попытка на аккаунт) | Нет (ниже порога блокировки) |
| Kill chain position | Initial access через внешний web-портал | Initial access через AD/SSO/VPN |
| Контекст | Внешний пентест, web-приложения | Внутренний пентест, AD-среда, Microsoft 365 |
| MITRE ATT&CK | T1110.004 | T1110.003 |
[Применимо: внешний пентест] Credential stuffing работает против веб-приложений с формой логина - e-commerce, SaaS-порталы, OWA, корпоративные VPN. Атаки с использованием утёкших паролей эффективны именно потому, что пользователи ставят один пароль на десяток сервисов. Банально, но работает раз за разом.
[Применимо: внутренний пентест, AD-среда] Password spraying - техника для корпоративных сред с доменной аутентификацией. Список доменных пользователей (через
GetADUsers.py, Kerbrute или LDAP-запросы), затем прогон паролей вида Company2024!, Winter2025!, Welcome1. В 2024 году наблюдается тренд комбинирования password spraying с MFA fatigue и кражей session token. Группа Midnight Blizzard использовала password spraying для компрометации тестового аккаунта Microsoft, затем через OAuth-permissions получила доступ к почте security и legal-команд (MSRC blog, январь 2024). Один тестовый аккаунт без MFA - и вся переписка юристов утекла.Пайплайн атаки с использованием утёкших паролей
Получение и нормализация дампов
Первый шаг - получение combo list. Источники: публичные дампы (Exploit.In - 593 млн записей), агрегированные базы на теневых форумах, Dehashed и аналоги для поиска по корпоративным email-доменам. Have I Been Pwned позволяет проверить, есть ли данные по конкретному домену, без раскрытия самих паролей.Сырой дамп непригоден для атаки. Там мусор, дубли и битые строки. Типичный пайплайн нормализации:
- Фильтрация по целевому домену (
grepпо@company.com) - Дедупликация - один email может встречаться в десятках утечек с разными паролями, все варианты сохраняются
- Очистка от мусора: битые строки, хеши вместо plaintext, невалидные форматы
- Формирование combo-файла в формате
email:password- один аккаунт может дать 3-5 паролей из разных утечек базы паролей
Инструменты для credential stuffing и автоматизация
Автоматизация атак на авторизацию строится на специализированных credential checker'ах и классических брутфорсерах. Каждый занимает своё место в пайплайне.| Инструмент | Тип | Применение | Ограничения | Статус |
|---|---|---|---|---|
| OpenBullet 2 | Credential checker | Web-формы, API, custom конфиги | Требует написания конфигов под каждый target | Активный, open source, .NET |
| SilverBullet | Credential checker | Web-формы, GUI-ориентированный | Меньше community-конфигов | Активный |
| Sentry MBA | Credential checker | Web-формы с anti-bot bypass | Legacy, хуже работает с современными CAPTCHA | Не обновляется |
| Hydra | Брутфорсер | SSH, FTP, HTTP-forms, SMB | Нет встроенной proxy-ротации, шумный | Активный, open source |
| Kerbrute | Password sprayer | Kerberos pre-auth в AD | Только Kerberos, только internal | Активный, open source, Go |
Для credential stuffing через веб-формы основной рабочий инструмент - OpenBullet 2. Он позволяет создавать конфигурации (configs) под конкретный login-endpoint: определить маркеры успешного/неуспешного входа, настроить proxy-ротацию и задержки. Написание конфига - отдельное ремесло: нужно разобраться в потоке авторизации, найти CSRF-токены, правильно парсить ответы. Инцидент Roku в 2024 году (576 000 аккаунтов во второй волне, по данным Roku Security Notice) - типичный пример credential stuffing атаки; конкретный toolset публично не раскрыт, но механика стандартная.
Sentry MBA когда-то был королём credential stuffing'а, но сейчас это скорее музейный экспонат - с современными CAPTCHA и bot detection он справляется плохо.
Для password spraying в AD стандартная связка: Kerbrute для энумерации валидных пользователей через Kerberos pre-auth, затем
DomainPasswordSpray.ps1 для прогона паролей. Согласно Atomic Red Team (тесты T1110.003), типовые сценарии включают Password Spray через DomainPasswordSpray-модуль PowerShell и spray через LDAP against domain controller (NTLM или Kerberos).Что происходит после account takeover
Account takeover - не конечная цель, а точка входа. Дальше всё зависит от контекста.Внешний веб-портал: извлечение персональных данных, привязанных платёжных карт, API-ключей. В e-commerce - оформление заказов на чужие деньги, в корпоративном OWA - доступ к почте и вложениям для дальнейшей разведки.
Корпоративный SSO/VPN: lateral movement через VPN-туннель, доступ к внутренним ресурсам, privilege escalation. Скомпрометированный аккаунт с правами на Citrix/RDP - прямой путь к domain admin.
Microsoft 365: persistence через Federated SSO, доступ к SharePoint, OneDrive, Teams. Кейс Midnight Blizzard показателен: после password spraying они получили доступ через OAuth-permissions - классический пример того, как брутфорс учётных данных превращается в persistence без единого exploit'а (MSRC blog, январь 2024).
Evasion: обход защиты от перебора паролей
Rate limiting, account lockout, IP blocking - стандартные меры, которые не работают против грамотно настроенной credential stuffing атаки. Вот почему.
Proxy rotation. OpenBullet 2 и Sentry MBA умеют работать с residential proxy-пулами из коробки. Согласно OWASP, даже при высокообъёмных атаках per-IP request volume остаётся низким, потому что запросы распределяются через тысячи уникальных IP. Блокировка по IP бесполезна. OWASP рекомендует учитывать классификацию IP (residential vs hosting) и геолокацию - запросы с hosting-провайдеров можно маршрутизировать через CAPTCHA.
Low-and-slow. Вместо тысяч запросов в минуту - 2-3 попытки с рандомизированными задержками. Для WAF и rate limiter это выглядит как обычный пользовательский трафик. Брутфорс аутентификации в таком режиме занимает дни, но остаётся невидимым для пороговых детекторов. Терпение - главное оружие.
Fingerprint rotation. Современные инструменты рандомизируют User-Agent, TLS fingerprint (JA3/JA4), разрешение экрана и другие параметры device fingerprinting. OWASP предупреждает: client-side defenses могут быть подменены или обойдены, нужны дополнительные слои защиты.
CAPTCHA bypass. Сервисы решения CAPTCHA обрабатывают reCAPTCHA v2 за 10-30 секунд при стоимости ~$2-3 за тысячу решений. OWASP рекомендует мониторить CAPTCHA solve rates: аномально высокий процент решений указывает на автоматизированный bypass.
Когда evasion НЕ работает:
- Adaptive MFA с risk-based triggers (login из нового гео, нового устройства, с proxy-IP) - останавливает атаку даже при валидных credentials
- Behavioral analytics на уровне WAF (Cloudflare Bot Management, Akamai Bot Manager) - детектирует паттерны ботов даже при ротации fingerprints
- FIDO2/WebAuthn - невозможно обойти через credential stuffing в принципе, hardware token не реплицируется. Точка.
Детектирование атак на аутентификацию в SIEM
Требования к окружению
- SIEM: Splunk Enterprise 9.x+ или Elastic Security 8.x+ (ELK Stack)
- Источники логов: Windows Security Event Log (Event ID 4625, 4624, 4771), web-server access logs, WAF logs
- Для AD-среды: аудит Kerberos pre-auth failures (Event ID 4771) обязателен - без него password spraying невидим
- Sigma-конвертер:
sigma-cliилиpySigmaдля трансляции правил в формат целевого SIEM
Sigma-правила и запросы для Splunk и Elastic
В репозитории SigmaHQ есть 8 правил для детектирования password spraying (тегattack.t1110.003). Ключевые: win_security_susp_failed_logons_single_source_ntlm.yml (множественные NTLM-failures с одного источника), win_security_susp_failed_remote_logons_single_source.yml (failed remote logons с одного IP), win_security_susp_failed_logons_explicit_credentials.yml (failed logons с explicit credentials).Базовый паттерн password spraying для Splunk - один источник, много целей:
Код:
index=wineventlog EventCode=4625
| eval LogonType=coalesce(Logon_Type, LogonType)
| where LogonType IN (3,8,10)
| stats count dc(TargetUserName) as unique_users by SourceNetworkAddress
| where count > 20 AND unique_users > 5
| sort -count
Код:
index=web_logs uri="/api/login" status=401
| bin _time span=5m
| stats count dc(src_ip) as unique_ips by _time
| where unique_ips > 50 AND count > 200D3FEND и вендор-специфика детектирования
Для T1110.003 MITRE D3FEND рекомендует пять defensive countermeasures:| D3FEND ID | Техника | Что мониторить |
|---|---|---|
| D3-CCSA | Credential Compromise Scope Analysis | Скомпрометированные credentials |
| D3-AEM | Application Exception Monitoring | Application logs (login failures) |
| D3-OPM | Operational Process Monitoring | Event Log (4625, 4771) |
| D3-UGLPA | User Geolocation Logon Pattern Analysis | Network Traffic (geo anomalies) |
| D3-PMAD | Protocol Metadata Anomaly Detection | Network Traffic (protocol anomalies) |
На практике D3-UGLPA (геолокационный анализ) даёт кучу false positives при VPN и remote-сотрудниках - замучаетесь разгребать. D3-PMAD эффективнее: детектирует аномальные TLS fingerprints и нестандартные HTTP-заголовки, характерные для автоматизированных инструментов.
Splunk Enterprise Security. Стандартный correlation search
Brute Force Access Behavior Detected работает через порог failed logins, но обходится low-and-slow техникой. Рекомендация: добавить правило с корреляцией по src_ip + user_agent + geo_country для выявления аномальных сочетаний.Elastic Security 8.x+. Встроенное ML-правило
Spike in Failed Logon Events детектирует credential stuffing через anomaly detection. Для password spraying - EQL-правило Multiple Logon Failure from the Same Source Address. Ограничение: без winlogbeat на контроллере домена password spraying через Kerberos pre-auth остаётся невидимым. Поставили Elastic, но не настроили winlogbeat на DC - считайте, что password spraying для вас не существует.CrowdStrike Falcon. Identity Protection модуль детектирует password spraying на уровне AD, включая Kerberos-атаки. Ограничение: только в лицензии Falcon Identity Threat Protection, не входит в базовую поставку.
Защита от credential stuffing: что реально работает
Согласно OWASP Credential Stuffing Prevention Cheat Sheet и рекомендациям Canadian Centre for Cyber Security (ITSP.30.035), эффективная защита строится послойно:
За последние полгода credential stuffing атаки перестают работать на крупных порталах с Cloudflare/Akamai Bot Management, но остаются убийственно эффективными на внутренних корпоративных порталах - OWA, Citrix Gateway, кастомные HR-системы - где WAF либо отсутствует, либо настроен на пропуск трафика из "доверенных" сетей. Пентест-проекты раз за разом показывают одно и то же: периметр укрепляется, а внутренние сервисы аутентификации живут с конфигурацией пятилетней давности.
Когда говорят "защита от перебора паролей", обычно подразумевают lockout после N попыток. Это не работает ни против credential stuffing (одна попытка на аккаунт), ни против password spraying (попытки ниже порога блокировки). Реальная защита - visibility: знать, какие аккаунты утекли, видеть аномалии в login patterns, реагировать до того, как атакующий найдёт валидную пару. Команды, которые внедрили мониторинг HIBP + velocity-based alerting в SIEM, сокращают время реакции с дней до минут. Те, кто полагается на account lockout, узнают о компрометации из тикета пользователя "почему у меня в почте чужие письма".
Отдельная история - password spraying в Active Directory. Типичная настройка по Microsoft Security Baseline / CIS Benchmark: 5 неудачных попыток -> lockout на 30 минут (в Default Domain Policy threshold по умолчанию = 0, lockout отключён). Атакующий с Kerbrute делает 4 попытки на аккаунт с паузой в 35 минут и проходит под радаром. Единственный способ поймать это - мониторинг Kerberos pre-auth failures (Event ID 4771) с корреляцией по времени и количеству уникальных аккаунтов.
А Event ID 4771 по умолчанию не включён в большинстве доменов.
Получается парадокс: одна из самых распространённых атак на AD-аутентификацию невидима в стандартной конфигурации логирования. Пока security-команда не включит Advanced Audit Policy для аккаунт-логонов, password spraying будет проходить незамеченным - вне зависимости от того, какой SIEM стоит за логами. Никакой Splunk не поможет, если в него не приходят нужные события. Проверьте прямо сейчас:
auditpol /get /subcategory:"Kerberos Authentication Service" на вашем DC. Если результат - No Auditing - у вас та же проблема.
Последнее редактирование модератором:
