Password spraying, или парольное распыление, — это атака, при которой злоумышленник не подбирает пароль к одной учётной записи сотнями вариантов. Он берёт список пользователей и пробует по одному-двум самым частым паролям против многих аккаунтов. Так он обходит обычные lockout-политики: каждая учётная запись получает мало неудачных попыток, блокировки нет, а атака идёт дальше.
Не ставьте защиту от password spraying в один пункт «заблокировать после N попыток». Жёсткая блокировка может создать отказ в обслуживании, а слабая — почти ничего не остановить. Нужны несколько слоёв: лимиты попыток, MFA, ограничение источников, сбор логов и быстрый ответ.
- Сначала найдите все места, куда можно войти
- Ограничение попыток: где ставить и что именно
- Учётная запись: блокировка нужна, но без фанатизма
- Источник входа: rate limit по IP, подсети и ASN
- Пользователь: отдельный лимит на каждый аккаунт
- Доступ: MFA и условный доступ
- Что обязательно собирать в мониторинг
- Правила обнаружения, с которых можно начать
- Что делать, когда правило сработало
- Сценарии выбора: какую схему собрать
- Частые ошибки при защите от password spraying
Сначала найдите все места, куда можно войти
В корпоративной сети password spraying чаще всего идёт не только в Active Directory. Атакуют корпоративную почту, VPN, RDP Gateway, SSO-портал, облачный IdP, веб-приложения, почтовые протоколы и старые сервисы, которые забыли отключить.
Перед настройкой ограничений составьте короткий список:
- где пользователи вводят логин и пароль;
- какие из этих сервисов доступны из интернета;
- где включён MFA, а где вход идёт только по паролю;
- какие логи собираются и куда они попадают;
- какие учётные записи сервисные, админские, старые или бывших сотрудников.
Если вы смотрите только на контроллеры домена, а атака идёт через Outlook Web Access, VPN или облачный SSO, вы увидите не всю картину. Защита начинается с инвентаризации путей входа.
Ограничение попыток: где ставить и что именно
Нормальная защита строится не на одной настройке, а на нескольких уровнях. У каждого уровня своя задача.
Учётная запись: блокировка нужна, но без фанатизма
Классическая lockout-политика в Active Directory полезна, но сама по себе плохо останавливает password spraying. Если злоумышленник делает по две попытки на аккаунт, он может долго проверять список пользователей и не доводить ни один аккаунт до блокировки.
Для AD DS как стартовый ориентир часто используют порог около 10–15 неудачных попыток и длительность блокировки 15–30 минут. Это не универсальная норма, но более безопасная отправная точка, чем блокировка после 3–5 ошибок. Слишком низкий порог легко превратить в инструмент DoS: достаточно несколько раз ошибиться большому числу сотрудников, и служба поддержки утонет в разблокировках.
Если используется облачный IdP, смотрите в сторону smart lockout-подходов: они стараются отличать подозрительные попытки от обычного поведения пользователя. Но и здесь не стоит считать механизм идеальным. Его нужно проверять по реальным логам.
Источник входа: rate limit по IP, подсети и ASN
Ограничивайте не только аккаунты, но и источник. Например, если с одного IP за 10 минут идут десятки или сотни неудачных входов в разные учётные записи, это уже не похоже на обычную ошибку пользователя.
Практичный ориентир для начала: после 20–30 неудачных попыток с одного источника за 10 минут включать задержку, MFA-step-up или временную блокировку на 30–60 минут. Но обязательно учитывайте NAT, прокси, мобильные сети и общие шлюзы. Блокировка большого офисного NAT или публичного облачного диапазона может отрезать легитимных пользователей.
Пользователь: отдельный лимит на каждый аккаунт
Даже если атакующий распыляет попытки по многим аккаунтам, отдельные пользователи всё равно могут получить несколько неудачных входов подряд. Поэтому полезен отдельный лимит на аккаунт: например, после 5–10 неудачных попыток за 10 минут требовать MFA, добавлять задержку или повышать риск входа.
Не раскрывайте, существует ли такой пользователь. Сообщения вроде «неверный пароль» и «пользователь не найден» должны выглядеть одинаково. Иначе атакующий быстро соберёт список реальных аккаунтов.
Доступ: MFA и условный доступ
Если пароль всё-таки подошёл, password spraying превращается в обычную компрометацию. Поэтому MFA и условный доступ — не «дополнительная красота», а часть защиты.
Что стоит сделать в первую очередь:
- включить MFA для всех интерактивных пользователей;
- для администраторов использовать более стойкие методы, например FIDO2-ключи;
- запретить legacy auth, если он не нужен;
- требовать MFA для входов из новых стран, неизвестных устройств или подозрительных сетей;
- защититься от MFA fatigue: number matching, ограничение push-уведомлений, обучение пользователей.
| Контроль | Где ставить | Что даёт | Ограничения | Когда применять |
|---|---|---|---|---|
| Lockout / smart lockout | AD, Entra ID, Okta, другой IdP | Замедляет перебор по одному аккаунту | Агрессивная блокировка удобна для DoS | Почти всегда, но с аккуратными порогами |
| Rate limit по источнику | WAF, VPN, RDP Gateway, IdP, API Gateway | Останавливает массовые попытки с одного места | NAT, прокси и общие сети могут дать ложные срабатывания | Для всех публичных точек входа |
| Лимит на аккаунт | IdP, VPN, почтовый шлюз, веб-приложения | Снижает риск подбора даже при распределённой атаке | Не спасает, если пароль уже известен | Для всех пользовательских входов |
| MFA и conditional access | SSO, IdP, почта, VPN | Обрывает атаку после угаданного пароля | Нужно защищаться от усталости MFA | Для всех пользователей, строго для админов |
| Блокировка legacy auth | Почта, IMAP/POP/SMTP AUTH, старые клиенты | Закрывает пути входа без MFA | Может сломать старые интеграции | Как можно раньше, после инвентаризации |
| Мониторинг и корреляция | SIEM, XDR, облачные логи | Показывает атаку до успешного входа | Требует настройки и регулярной доводки | Обязательно для любой заметной инфраструктуры |
Что обязательно собирать в мониторинг
Для detection нужны не только факты блокировок. Блокировка — это уже поздний сигнал. Нужно видеть все попытки входа: успешные, неуспешные, MFA-запросы, блокировки условным доступом и действия после входа.
Минимальный набор источников:
- IdP / SSO: успешные и неуспешные входы, MFA, conditional access, risky sign-in, смена пароля, регистрация MFA;
- Active Directory: события неудачного входа, Kerberos/NTLM-ошибки, блокировки учётных записей, разблокировки;
- VPN и RDP Gateway: источник, пользователь, результат входа, устройство, геолокация;
- почта и SaaS: входы по legacy auth, новые правила пересылки, OAuth-приложения, согласия пользователю;
- WAF / reverse proxy: HTTP 401/403, auth endpoints, user agent, URI, частота запросов.
Из событий Windows можно ориентироваться на 4625, 4771, 4776 и 4740: неудачный вход, Kerberos pre-auth failure, NTLM validation failure и блокировка учётной записи. В облачных IdP смотрите на коды неудачных входов и причины отказа, например неверный пароль, заблокированный аккаунт, срабатывание conditional access или требование MFA.
В логах желательно нормализовать поля: время, пользователь, источник, приложение, результат, причина отказа, user agent, MFA-результат и session ID. Без user agent и application сложнее отличить реального пользователя от скрипта.
Правила обнаружения, с которых можно начать
Не пытайтесь сразу построить идеальную аналитику. Начните с нескольких правил, которые ловят типичное поведение password spraying.
- Много аккаунтов с одного источника. Например, больше 50 разных пользователей с одного IP за 30 минут или больше 100 за час.
- Много неудачных входов на один аккаунт. Например, больше 10 неудачных попыток за 10 минут, особенно с разных IP.
- Одинаковый user agent по множеству пользователей. Для скриптов это частый признак: один и тот же клиент ходит по десяткам аккаунтов.
- Попытки против спящих или старых учётных записей. Если атака идёт по disabled, dormant или contractor accounts, это хороший индикатор.
- Успешный вход после серии неудач. Самый опасный сценарий: сначала десятки ошибок, потом один успех.
- Новая страна или необычная сеть плюс чувствительное действие. Например, вход из новой страны, затем чтение почты, создание правила пересылки или добавление OAuth-приложения.
- Массовые блокировки. Например, больше 20 lockout-событий за 15 минут — это может быть атака или проблема с сохранёнными старыми паролями.
Пороги нужно настраивать по среде. В одной компании 50 попыток за 30 минут — явный шум, в другой — нормальный пик после сбоя пароля у отдела. Хорошее правило появляется после просмотра реальных логов, а не после копирования чужого SIEM-шаблона.
Что делать, когда правило сработало
Главная ошибка — сразу блокировать всё подряд. Сначала быстро подтвердите картину: один источник, много пользователей, одинаковый user agent, много неудачных входов. Затем действуйте по сценарию.
- Ограничьте источник. Если это явно вредоносный IP, ASN или TOR-выходной узел, добавьте временную блокировку или rate limit. Если источник общий, лучше усилить проверку входа, а не отрезать весь диапазон.
- Проверьте успешные входы. Если после серии ошибок кто-то вошёл успешно, это уже инцидент, а не просто подозрение.
- Для скомпрометированных аккаунтов сбросьте пароль и отзовите сессии. Одного сброса пароля мало: активные refresh tokens, VPN-сессии и cookie могут остаться живыми.
- Проверьте признаки закрепления. Почтовые правила, пересылки, новые OAuth-согласия, добавление в группы, VPN-сессии, RDP-сессии, новые админские действия.
- Добавьте индикаторы в мониторинг. Источник, user agent, URI, ASN, имена учётных записей, по которым шли попытки.
- Сообщите пользователю. Если вход был успешным, пользователю нужно объяснить, что произошло, и попросить не подтверждать неожиданные MFA-запросы.
Сценарии выбора: какую схему собрать
| Ситуация | Что делать в первую очередь | Чего избегать |
|---|---|---|
| Небольшая компания, облачный IdP, нет полноценного SIEM | Включить MFA, smart lockout, запрет legacy auth, базовые алерты по неудачным входам и новым странам | Полностью полагаться только на lockout и не смотреть облачные логи |
| On-prem AD, VPN и RDP доступны извне | Собрать логи DC, VPN и RDP Gateway; настроить lockout 10–15 попыток; ограничить RDP по IP; добавить корреляцию по множеству пользователей | Оставлять RDP открытым для всего интернета и мониторить только lockout |
| Гибридная среда Microsoft | Entra Conditional Access, Smart Lockout, блокировка legacy auth, сбор sign-in logs, Defender/Entra ID Protection или SIEM | Думать, что AD lockout закрывает облачную почту и SaaS |
| Администраторы, финансы, критичные сервисы | Phishing-resistant MFA, отдельные админские учётные записи, запрет входа из обычных сетей, строгий conditional access | Использовать те же правила входа, что и для обычных пользователей |
| Атака идёт с сотен разных IP | Сместить фокус на per-account limits, MFA, risky sign-in, user agent, поведенческую корреляцию | Пытаться решить проблему только IP-блокировками |
Частые ошибки при защите от password spraying
- Блокировка после 3–5 попыток без анализа. Это легко превращает атаку в отказ в обслуживании для сотрудников.
- Мониторинг только lockout-событий. Password spraying как раз старается не доводить аккаунты до блокировки.
- Сбор логов только с AD. Почта, VPN, SSO и SaaS часто дают более ранние признаки атаки.
- Legacy auth остался включённым. Старые протоколы нередко обходят MFA и становятся удобным входом для атаки.
- Блокировка огромных диапазонов облачных провайдеров. Так можно отрезать легитимный трафик и не остановить