Как защитить корпоративную сеть от password spraying: ограничиваем попытки входа и настраиваем мониторинг

Если в вашей компании пользователи используют простые пароли или не меняют их годами, вы думаете, что главная угроза — это подбор. Но хакеры давно перешли к более тихой атаке. Они не ломают один аккаунт тысячами попыток. Они берут один слабый пароль и проверяют его по тысячам учётных записей. Почти без шума. Почти без риска заблокироваться.

Это называется password spraying. И стандартные настройки блокировки аккаунтов здесь не работают — потому что атака растянута во времени, и каждая попытка выглядит как обычная ошибка входа. В этой статье разберём, как реально остановить такие атаки: на уровне настроек блокировки и через мониторинг, который увидит то, что обычная политика паролей пропустит.

Содержание
  1. Почему password spraying обходит обычную защиту
  2. Настройка ограничения попыток входа против spraying
  3. 1. Увеличьте окно времени для подсчёта неудачных попыток Стандартное окно в 15–30 минут не видит password spraying, потому что атака растягивается на дни. Увеличьте хотя бы до 24–48 часов. Что настраивать в Active Directory: Account lockout threshold — количество неудачных попыток до блокировки. Оставьте 3–5, не больше. Account lockout duration — время блокировки. Хотя бы 15–30 минут. В идеале — разблокировка только через администратора, но это создаст дополнительную нагрузку на поддержку. Reset account lockout counter after — это ключевой параметр. Если сейчас он стоит на 15 минут, поставьте 1440 (24 часа) или 2880 (48 часов). Почему так: если блокировать аккаунт после 3 неудачных попыток за последние 24 часа, то злоумышленник, делающий 2 попытки в сутки, всё ещё пройдёт мимо. Но если он ошибётся с ритмом или автоматически увеличит частоту — аккаунт заблокируется, и в мониторинге появится аномалия. 2. Используйте капчу или адаптивную блокировку Для веб-приложений и VPN-шлюзов — обязательная капча после 2–3 неудачных попыток. Для корпоративных порталов можно настроить аналогичную логику: после N неудачных попыток — дополнительный фактор или временная задержка. Это не спасёт от целевых атак на один аккаунт, но делает массовый перебор по всему списку логинов крайне медленным. Увеличение времени между попытками на 2–3 секунды превращает атаку, которая раньше занимала час, в атаку на неделю. 3. Запретите популярные пароли — это критично Password spraying опирается на то, что часть пользователей использует слабые пароли. Если в вашей компании 10 000 человек и хотя бы 0,5% из них используют «Qwerty123» — это 50 скомпрометированных аккаунтов после одной атаки. Что можно сделать: Внедрите фильтр паролей в Active Directory (или используйте Azure AD Password Protection). Он проверяет новый пароль по чёрному списку: запрещённые слова, названия компании, сезонные пароли и их вариации. Включите проверку по базе утёкших паролей — это уже встроено в Azure AD и доступно для on-premise через сторонние решения. Запретите пароли короче 12 символов. Для spraying короткие пароли — подарок: перебор идёт быстрее, списки уязвимых паролей короче. 4. Блокировка по IP-адресам — с осторожностью Блокировать IP-адрес после серии неудачных попыток — логично, но password spraying использует сотни адресов. Если вы настроите жёсткую блокировку, вы можете заблокировать легитимных пользователей, которые выходят через те же прокси или корпоративные NAT. Лучший подход — не жёсткая блокировка, а скоринг: если с одного IP за час приходит более 10 неудачных попыток входа на разные аккаунты — это аномалия. Такой IP можно временно пометить и отправить алерт администратору. Мониторинг: как увидеть атаку, которую не блокирует политика Ограничение попыток — это фундамент. Но без мониторинга вы узнаете об атаке только когда будет поздно. Вот что нужно отслеживать и как это настроить. Ключевые события в логах В Windows-инфраструктуре основной источник — журналы безопасности контроллеров домена. Вот события, которые нужно собирать и анализировать: Код события Что означает Почему важно 4625 Неудачная попытка входа Основа для анализа. Нужно смотреть не на отдельные события, а на паттерны. 4740 Аккаунт заблокирован Если блокировки участились — возможна атака или проблемы с политикой. 4771 Ошибка Kerberos pre-authentication Часто используется в password spraying — атака идёт через Kerberos, а не через обычный вход. 4776 Попытка проверки учётных данных через NTLM Ещё один канал для атак. Если видите массовые 4776 — проверяйте источник. 4648 Вход с явными учётными данными Может указывать на использование скомпрометированных данных после успешного spraying. Важно: собирать эти события нужно не только с контроллеров домена, но и с VPN-серверов, почтовых систем, веб-приложений — везде, где есть аутентификация. На какие паттерны смотреть Отдельное событие 4625 — это просто кто-то забыл пароль. Но если вы видите следующие паттерны — это почти наверняка password spraying: Много неудачных входов с одного IP на разные аккаунты. Нормальный пользователь ошибается только со своим логином. Если с одного адреса за час приходит 20 неудачных попыток на 15 разных логинов — это атака. Рост количества событий 4771 (Kerberos pre-auth) без соответствующего роста 4625. Злоумышленники часто используют Kerberos, потому что он быстрее и реже логируется в стандартных настройках. Неудачные попытки входа на аккаунты, которые обычно не используются. Если в 3 часа ночи кто-то пытается войти на аккаунт сотрудника, который в отпуске — это подозрительно. Географическая аномалия. Входы из стран, где у компании нет офисов, или из IP-адресов, которые раньше не использовались. Сезонные пароли в логах. Если вы видите массовые попытки входа с паролями вида «Summer2024», «January!», «Company123» — это классический spraying. Инструменты для мониторинга Загонять логи в SIEM и писать правила — правильный путь, но не единственный. Вот варианты под разный масштаб: Для небольших компаний (до 500 пользователей): Скрипты PowerShell, которые раз в час анализируют журналы контроллеров домена и отправляют отчёт администратору. Можно найти готовые скрипты на GitHub — они считают количество неудачных входов по IP и аккаунтам. Бесплатные решения вроде Wazuh или Graylog — настраиваются за пару дней, дают базовый мониторинг и алерты. Для средних и крупных компаний: Полноценный SIEM (Splunk, QRadar, Microsoft Sentinel, ELK Stack). Настройте корреляционные правила для описанных выше паттернов. Azure AD Identity Protection — если используете облачную или гибридную инфраструктуру, он автоматически обнаруживает аномалии входа и может блокировать рискованные попытки. Специализированные решения для защиты учётных записей (например, Semperis, Attivo Networks) — они фокусируются именно на атаки на AD и видят то, что обычный SIEM пропустит. Что делать, если атака уже идёт Предположим, мониторинг показал аномалию: за последние сутки количество неудачных попыток входа выросло в 5 раз, основной источник — 15–20 IP-адресов из разных стран. Ваши действия: Не паникуйте и не блокируйте всё подряд. Сначала убедитесь, что это не легитимный сбой (например, пользователи массово забыли пароль после смены политики). Соберите данные: какие IP, какие аккаунты, какие пароли используются, через какой протокол (NTLM, Kerberos, веб-форма). Заблокируйте подозрительные IP на файрволе или VPN-шлюзе. Это не остановит атаку полностью, но замедлит её. Принудительно сбросьте пароли для аккаунтов, на которые пришлись попытки. Особенно для администраторов и привилегированных учётных записей. Проверьте, не было ли успешных входов. Ищите события 4624 (успешный вход) с тех же IP или на те же аккаунты, где были неудачные попытки. Проанализируйте скомпрометированные аккаунты. Что делал пользователь после входа? Были ли попытки доступа к необычным ресурсам, запуск подозрительных процессов? Частые ошибки при защите от password spraying Вот что я регулярно вижу в компаниях, которые думают, что защищены: Полагаться только на сложность паролей. Пользователь может использовать сложный пароль, но если он один и тот же на всех сервисах — утечка с одного сайта даёт доступ к корпоративной сети. Отключать мониторинг из-за «слишком много логов». Да, событий 4625 может быть тысячи в день. Но если вы не анализируете их — вы не видите атаку. Блокировать аккаунты слишком агрессивно. Если порог блокировки — 2 попытки, а окно — 5 минут, вы получите волну блокировок среди легитимных пользователей и усталость от алертов. Администраторы начнут игнорировать уведомления. Забивать на сервисные аккаунты. Учётные записи служб часто имеют простые пароли и никогда не меняются. Идеальная цель для spraying. Не тестировать защиту. Если вы не проводите регулярные пентесты или хотя бы имитацию атаки — вы не знаете, работает ли ваша защита. Как выстроить защиту под вашу ситуацию Не все меры одинаково полезны для всех. Вот как выбрать подход в зависимости от контекста: Если у вас небольшая компания и нет выделенной ИБ-команды: Включите запрет слабых паролей через Azure AD Password Protection или аналог. Настройте сбор событий 4625 и 4771 с контроллеров домена хотя бы в текстовый файл с ежедневным анализом. Включите MFA для всех внешних входов (VPN, почта, облачные сервисы). Запретите пароли короче 12 символов. Если у вас средний бизнес и есть системный администратор: Внедрите SIEM или хотя бы централизованный сбор логов с алертами на аномалии. Настройте блокировку IP после серии неудачных попыток на VPN-шлюзе. Проведите аудит сервисных аккаунтов и смените пароли на длинные случайные. Раз в квартал проводите тестовый password spraying через инструменты вроде SprayKing или MailSniper (с разрешения руководства, разумеется). Если у вас крупная компания и есть ИБ-отдел: Полноценный SIEM с корреляционными правилами для всех описанных паттернов. Azure AD Identity Protection или аналогичное решение для облачной инфраструктуры. Регулярные пентесты с фокусом на атаки на учётные записи. Мониторинг не только контроллеров домена, но и всех систем аутентификации. Автоматизированная реакция на инциденты: блокировка IP, сброс пароля, изоляция аккаунта. Итог: что делать прямо сейчас Password spraying — это не экзотическая атака. Это стандартный приём, который используют и скрипт-кидди, и профессиональные группировки. Если вы ничего не делаете — скорее всего, вас уже проверили. Вот три действия, которые стоит сделать на этой неделе: Проверьте настройки блокировки аккаунтов. Увеличьте окно подсчёта неудачных попыток до 24 часов. Убедитесь, что порог блокировки — 3–5 попыток. Начните собирать и анализировать события 4625 и 4771. Даже простой скрипт, который считает количество неудачных входов по IP за сутки, уже даст вам картину. Включите запрет слабых паролей. Это снимает 80% риска от password spraying, потому что атака опирается именно на популярные пароли. Полная защита — это не одна кнопка или один продукт. Это комбинация правильных настроек, мониторинга и регулярной проверки. Начните с малого, но начните сейчас — пока злоумышленники не нашли ваши слабые места раньше вас.
  4. 2. Используйте капчу или адаптивную блокировку Для веб-приложений и VPN-шлюзов — обязательная капча после 2–3 неудачных попыток. Для корпоративных порталов можно настроить аналогичную логику: после N неудачных попыток — дополнительный фактор или временная задержка. Это не спасёт от целевых атак на один аккаунт, но делает массовый перебор по всему списку логинов крайне медленным. Увеличение времени между попытками на 2–3 секунды превращает атаку, которая раньше занимала час, в атаку на неделю. 3. Запретите популярные пароли — это критично Password spraying опирается на то, что часть пользователей использует слабые пароли. Если в вашей компании 10 000 человек и хотя бы 0,5% из них используют «Qwerty123» — это 50 скомпрометированных аккаунтов после одной атаки. Что можно сделать: Внедрите фильтр паролей в Active Directory (или используйте Azure AD Password Protection). Он проверяет новый пароль по чёрному списку: запрещённые слова, названия компании, сезонные пароли и их вариации. Включите проверку по базе утёкших паролей — это уже встроено в Azure AD и доступно для on-premise через сторонние решения. Запретите пароли короче 12 символов. Для spraying короткие пароли — подарок: перебор идёт быстрее, списки уязвимых паролей короче. 4. Блокировка по IP-адресам — с осторожностью Блокировать IP-адрес после серии неудачных попыток — логично, но password spraying использует сотни адресов. Если вы настроите жёсткую блокировку, вы можете заблокировать легитимных пользователей, которые выходят через те же прокси или корпоративные NAT. Лучший подход — не жёсткая блокировка, а скоринг: если с одного IP за час приходит более 10 неудачных попыток входа на разные аккаунты — это аномалия. Такой IP можно временно пометить и отправить алерт администратору. Мониторинг: как увидеть атаку, которую не блокирует политика Ограничение попыток — это фундамент. Но без мониторинга вы узнаете об атаке только когда будет поздно. Вот что нужно отслеживать и как это настроить. Ключевые события в логах В Windows-инфраструктуре основной источник — журналы безопасности контроллеров домена. Вот события, которые нужно собирать и анализировать: Код события Что означает Почему важно 4625 Неудачная попытка входа Основа для анализа. Нужно смотреть не на отдельные события, а на паттерны. 4740 Аккаунт заблокирован Если блокировки участились — возможна атака или проблемы с политикой. 4771 Ошибка Kerberos pre-authentication Часто используется в password spraying — атака идёт через Kerberos, а не через обычный вход. 4776 Попытка проверки учётных данных через NTLM Ещё один канал для атак. Если видите массовые 4776 — проверяйте источник. 4648 Вход с явными учётными данными Может указывать на использование скомпрометированных данных после успешного spraying. Важно: собирать эти события нужно не только с контроллеров домена, но и с VPN-серверов, почтовых систем, веб-приложений — везде, где есть аутентификация. На какие паттерны смотреть Отдельное событие 4625 — это просто кто-то забыл пароль. Но если вы видите следующие паттерны — это почти наверняка password spraying: Много неудачных входов с одного IP на разные аккаунты. Нормальный пользователь ошибается только со своим логином. Если с одного адреса за час приходит 20 неудачных попыток на 15 разных логинов — это атака. Рост количества событий 4771 (Kerberos pre-auth) без соответствующего роста 4625. Злоумышленники часто используют Kerberos, потому что он быстрее и реже логируется в стандартных настройках. Неудачные попытки входа на аккаунты, которые обычно не используются. Если в 3 часа ночи кто-то пытается войти на аккаунт сотрудника, который в отпуске — это подозрительно. Географическая аномалия. Входы из стран, где у компании нет офисов, или из IP-адресов, которые раньше не использовались. Сезонные пароли в логах. Если вы видите массовые попытки входа с паролями вида «Summer2024», «January!», «Company123» — это классический spraying. Инструменты для мониторинга Загонять логи в SIEM и писать правила — правильный путь, но не единственный. Вот варианты под разный масштаб: Для небольших компаний (до 500 пользователей): Скрипты PowerShell, которые раз в час анализируют журналы контроллеров домена и отправляют отчёт администратору. Можно найти готовые скрипты на GitHub — они считают количество неудачных входов по IP и аккаунтам. Бесплатные решения вроде Wazuh или Graylog — настраиваются за пару дней, дают базовый мониторинг и алерты. Для средних и крупных компаний: Полноценный SIEM (Splunk, QRadar, Microsoft Sentinel, ELK Stack). Настройте корреляционные правила для описанных выше паттернов. Azure AD Identity Protection — если используете облачную или гибридную инфраструктуру, он автоматически обнаруживает аномалии входа и может блокировать рискованные попытки. Специализированные решения для защиты учётных записей (например, Semperis, Attivo Networks) — они фокусируются именно на атаки на AD и видят то, что обычный SIEM пропустит. Что делать, если атака уже идёт Предположим, мониторинг показал аномалию: за последние сутки количество неудачных попыток входа выросло в 5 раз, основной источник — 15–20 IP-адресов из разных стран. Ваши действия: Не паникуйте и не блокируйте всё подряд. Сначала убедитесь, что это не легитимный сбой (например, пользователи массово забыли пароль после смены политики). Соберите данные: какие IP, какие аккаунты, какие пароли используются, через какой протокол (NTLM, Kerberos, веб-форма). Заблокируйте подозрительные IP на файрволе или VPN-шлюзе. Это не остановит атаку полностью, но замедлит её. Принудительно сбросьте пароли для аккаунтов, на которые пришлись попытки. Особенно для администраторов и привилегированных учётных записей. Проверьте, не было ли успешных входов. Ищите события 4624 (успешный вход) с тех же IP или на те же аккаунты, где были неудачные попытки. Проанализируйте скомпрометированные аккаунты. Что делал пользователь после входа? Были ли попытки доступа к необычным ресурсам, запуск подозрительных процессов? Частые ошибки при защите от password spraying Вот что я регулярно вижу в компаниях, которые думают, что защищены: Полагаться только на сложность паролей. Пользователь может использовать сложный пароль, но если он один и тот же на всех сервисах — утечка с одного сайта даёт доступ к корпоративной сети. Отключать мониторинг из-за «слишком много логов». Да, событий 4625 может быть тысячи в день. Но если вы не анализируете их — вы не видите атаку. Блокировать аккаунты слишком агрессивно. Если порог блокировки — 2 попытки, а окно — 5 минут, вы получите волну блокировок среди легитимных пользователей и усталость от алертов. Администраторы начнут игнорировать уведомления. Забивать на сервисные аккаунты. Учётные записи служб часто имеют простые пароли и никогда не меняются. Идеальная цель для spraying. Не тестировать защиту. Если вы не проводите регулярные пентесты или хотя бы имитацию атаки — вы не знаете, работает ли ваша защита. Как выстроить защиту под вашу ситуацию Не все меры одинаково полезны для всех. Вот как выбрать подход в зависимости от контекста: Если у вас небольшая компания и нет выделенной ИБ-команды: Включите запрет слабых паролей через Azure AD Password Protection или аналог. Настройте сбор событий 4625 и 4771 с контроллеров домена хотя бы в текстовый файл с ежедневным анализом. Включите MFA для всех внешних входов (VPN, почта, облачные сервисы). Запретите пароли короче 12 символов. Если у вас средний бизнес и есть системный администратор: Внедрите SIEM или хотя бы централизованный сбор логов с алертами на аномалии. Настройте блокировку IP после серии неудачных попыток на VPN-шлюзе. Проведите аудит сервисных аккаунтов и смените пароли на длинные случайные. Раз в квартал проводите тестовый password spraying через инструменты вроде SprayKing или MailSniper (с разрешения руководства, разумеется). Если у вас крупная компания и есть ИБ-отдел: Полноценный SIEM с корреляционными правилами для всех описанных паттернов. Azure AD Identity Protection или аналогичное решение для облачной инфраструктуры. Регулярные пентесты с фокусом на атаки на учётные записи. Мониторинг не только контроллеров домена, но и всех систем аутентификации. Автоматизированная реакция на инциденты: блокировка IP, сброс пароля, изоляция аккаунта. Итог: что делать прямо сейчас Password spraying — это не экзотическая атака. Это стандартный приём, который используют и скрипт-кидди, и профессиональные группировки. Если вы ничего не делаете — скорее всего, вас уже проверили. Вот три действия, которые стоит сделать на этой неделе: Проверьте настройки блокировки аккаунтов. Увеличьте окно подсчёта неудачных попыток до 24 часов. Убедитесь, что порог блокировки — 3–5 попыток. Начните собирать и анализировать события 4625 и 4771. Даже простой скрипт, который считает количество неудачных входов по IP за сутки, уже даст вам картину. Включите запрет слабых паролей. Это снимает 80% риска от password spraying, потому что атака опирается именно на популярные пароли. Полная защита — это не одна кнопка или один продукт. Это комбинация правильных настроек, мониторинга и регулярной проверки. Начните с малого, но начните сейчас — пока злоумышленники не нашли ваши слабые места раньше вас.
  5. 3. Запретите популярные пароли — это критично Password spraying опирается на то, что часть пользователей использует слабые пароли. Если в вашей компании 10 000 человек и хотя бы 0,5% из них используют «Qwerty123» — это 50 скомпрометированных аккаунтов после одной атаки. Что можно сделать: Внедрите фильтр паролей в Active Directory (или используйте Azure AD Password Protection). Он проверяет новый пароль по чёрному списку: запрещённые слова, названия компании, сезонные пароли и их вариации. Включите проверку по базе утёкших паролей — это уже встроено в Azure AD и доступно для on-premise через сторонние решения. Запретите пароли короче 12 символов. Для spraying короткие пароли — подарок: перебор идёт быстрее, списки уязвимых паролей короче. 4. Блокировка по IP-адресам — с осторожностью Блокировать IP-адрес после серии неудачных попыток — логично, но password spraying использует сотни адресов. Если вы настроите жёсткую блокировку, вы можете заблокировать легитимных пользователей, которые выходят через те же прокси или корпоративные NAT. Лучший подход — не жёсткая блокировка, а скоринг: если с одного IP за час приходит более 10 неудачных попыток входа на разные аккаунты — это аномалия. Такой IP можно временно пометить и отправить алерт администратору. Мониторинг: как увидеть атаку, которую не блокирует политика Ограничение попыток — это фундамент. Но без мониторинга вы узнаете об атаке только когда будет поздно. Вот что нужно отслеживать и как это настроить. Ключевые события в логах В Windows-инфраструктуре основной источник — журналы безопасности контроллеров домена. Вот события, которые нужно собирать и анализировать: Код события Что означает Почему важно 4625 Неудачная попытка входа Основа для анализа. Нужно смотреть не на отдельные события, а на паттерны. 4740 Аккаунт заблокирован Если блокировки участились — возможна атака или проблемы с политикой. 4771 Ошибка Kerberos pre-authentication Часто используется в password spraying — атака идёт через Kerberos, а не через обычный вход. 4776 Попытка проверки учётных данных через NTLM Ещё один канал для атак. Если видите массовые 4776 — проверяйте источник. 4648 Вход с явными учётными данными Может указывать на использование скомпрометированных данных после успешного spraying. Важно: собирать эти события нужно не только с контроллеров домена, но и с VPN-серверов, почтовых систем, веб-приложений — везде, где есть аутентификация. На какие паттерны смотреть Отдельное событие 4625 — это просто кто-то забыл пароль. Но если вы видите следующие паттерны — это почти наверняка password spraying: Много неудачных входов с одного IP на разные аккаунты. Нормальный пользователь ошибается только со своим логином. Если с одного адреса за час приходит 20 неудачных попыток на 15 разных логинов — это атака. Рост количества событий 4771 (Kerberos pre-auth) без соответствующего роста 4625. Злоумышленники часто используют Kerberos, потому что он быстрее и реже логируется в стандартных настройках. Неудачные попытки входа на аккаунты, которые обычно не используются. Если в 3 часа ночи кто-то пытается войти на аккаунт сотрудника, который в отпуске — это подозрительно. Географическая аномалия. Входы из стран, где у компании нет офисов, или из IP-адресов, которые раньше не использовались. Сезонные пароли в логах. Если вы видите массовые попытки входа с паролями вида «Summer2024», «January!», «Company123» — это классический spraying. Инструменты для мониторинга Загонять логи в SIEM и писать правила — правильный путь, но не единственный. Вот варианты под разный масштаб: Для небольших компаний (до 500 пользователей): Скрипты PowerShell, которые раз в час анализируют журналы контроллеров домена и отправляют отчёт администратору. Можно найти готовые скрипты на GitHub — они считают количество неудачных входов по IP и аккаунтам. Бесплатные решения вроде Wazuh или Graylog — настраиваются за пару дней, дают базовый мониторинг и алерты. Для средних и крупных компаний: Полноценный SIEM (Splunk, QRadar, Microsoft Sentinel, ELK Stack). Настройте корреляционные правила для описанных выше паттернов. Azure AD Identity Protection — если используете облачную или гибридную инфраструктуру, он автоматически обнаруживает аномалии входа и может блокировать рискованные попытки. Специализированные решения для защиты учётных записей (например, Semperis, Attivo Networks) — они фокусируются именно на атаки на AD и видят то, что обычный SIEM пропустит. Что делать, если атака уже идёт Предположим, мониторинг показал аномалию: за последние сутки количество неудачных попыток входа выросло в 5 раз, основной источник — 15–20 IP-адресов из разных стран. Ваши действия: Не паникуйте и не блокируйте всё подряд. Сначала убедитесь, что это не легитимный сбой (например, пользователи массово забыли пароль после смены политики). Соберите данные: какие IP, какие аккаунты, какие пароли используются, через какой протокол (NTLM, Kerberos, веб-форма). Заблокируйте подозрительные IP на файрволе или VPN-шлюзе. Это не остановит атаку полностью, но замедлит её. Принудительно сбросьте пароли для аккаунтов, на которые пришлись попытки. Особенно для администраторов и привилегированных учётных записей. Проверьте, не было ли успешных входов. Ищите события 4624 (успешный вход) с тех же IP или на те же аккаунты, где были неудачные попытки. Проанализируйте скомпрометированные аккаунты. Что делал пользователь после входа? Были ли попытки доступа к необычным ресурсам, запуск подозрительных процессов? Частые ошибки при защите от password spraying Вот что я регулярно вижу в компаниях, которые думают, что защищены: Полагаться только на сложность паролей. Пользователь может использовать сложный пароль, но если он один и тот же на всех сервисах — утечка с одного сайта даёт доступ к корпоративной сети. Отключать мониторинг из-за «слишком много логов». Да, событий 4625 может быть тысячи в день. Но если вы не анализируете их — вы не видите атаку. Блокировать аккаунты слишком агрессивно. Если порог блокировки — 2 попытки, а окно — 5 минут, вы получите волну блокировок среди легитимных пользователей и усталость от алертов. Администраторы начнут игнорировать уведомления. Забивать на сервисные аккаунты. Учётные записи служб часто имеют простые пароли и никогда не меняются. Идеальная цель для spraying. Не тестировать защиту. Если вы не проводите регулярные пентесты или хотя бы имитацию атаки — вы не знаете, работает ли ваша защита. Как выстроить защиту под вашу ситуацию Не все меры одинаково полезны для всех. Вот как выбрать подход в зависимости от контекста: Если у вас небольшая компания и нет выделенной ИБ-команды: Включите запрет слабых паролей через Azure AD Password Protection или аналог. Настройте сбор событий 4625 и 4771 с контроллеров домена хотя бы в текстовый файл с ежедневным анализом. Включите MFA для всех внешних входов (VPN, почта, облачные сервисы). Запретите пароли короче 12 символов. Если у вас средний бизнес и есть системный администратор: Внедрите SIEM или хотя бы централизованный сбор логов с алертами на аномалии. Настройте блокировку IP после серии неудачных попыток на VPN-шлюзе. Проведите аудит сервисных аккаунтов и смените пароли на длинные случайные. Раз в квартал проводите тестовый password spraying через инструменты вроде SprayKing или MailSniper (с разрешения руководства, разумеется). Если у вас крупная компания и есть ИБ-отдел: Полноценный SIEM с корреляционными правилами для всех описанных паттернов. Azure AD Identity Protection или аналогичное решение для облачной инфраструктуры. Регулярные пентесты с фокусом на атаки на учётные записи. Мониторинг не только контроллеров домена, но и всех систем аутентификации. Автоматизированная реакция на инциденты: блокировка IP, сброс пароля, изоляция аккаунта. Итог: что делать прямо сейчас Password spraying — это не экзотическая атака. Это стандартный приём, который используют и скрипт-кидди, и профессиональные группировки. Если вы ничего не делаете — скорее всего, вас уже проверили. Вот три действия, которые стоит сделать на этой неделе: Проверьте настройки блокировки аккаунтов. Увеличьте окно подсчёта неудачных попыток до 24 часов. Убедитесь, что порог блокировки — 3–5 попыток. Начните собирать и анализировать события 4625 и 4771. Даже простой скрипт, который считает количество неудачных входов по IP за сутки, уже даст вам картину. Включите запрет слабых паролей. Это снимает 80% риска от password spraying, потому что атака опирается именно на популярные пароли. Полная защита — это не одна кнопка или один продукт. Это комбинация правильных настроек, мониторинга и регулярной проверки. Начните с малого, но начните сейчас — пока злоумышленники не нашли ваши слабые места раньше вас.
  6. 4. Блокировка по IP-адресам — с осторожностью Блокировать IP-адрес после серии неудачных попыток — логично, но password spraying использует сотни адресов. Если вы настроите жёсткую блокировку, вы можете заблокировать легитимных пользователей, которые выходят через те же прокси или корпоративные NAT. Лучший подход — не жёсткая блокировка, а скоринг: если с одного IP за час приходит более 10 неудачных попыток входа на разные аккаунты — это аномалия. Такой IP можно временно пометить и отправить алерт администратору. Мониторинг: как увидеть атаку, которую не блокирует политика Ограничение попыток — это фундамент. Но без мониторинга вы узнаете об атаке только когда будет поздно. Вот что нужно отслеживать и как это настроить. Ключевые события в логах В Windows-инфраструктуре основной источник — журналы безопасности контроллеров домена. Вот события, которые нужно собирать и анализировать: Код события Что означает Почему важно 4625 Неудачная попытка входа Основа для анализа. Нужно смотреть не на отдельные события, а на паттерны. 4740 Аккаунт заблокирован Если блокировки участились — возможна атака или проблемы с политикой. 4771 Ошибка Kerberos pre-authentication Часто используется в password spraying — атака идёт через Kerberos, а не через обычный вход. 4776 Попытка проверки учётных данных через NTLM Ещё один канал для атак. Если видите массовые 4776 — проверяйте источник. 4648 Вход с явными учётными данными Может указывать на использование скомпрометированных данных после успешного spraying. Важно: собирать эти события нужно не только с контроллеров домена, но и с VPN-серверов, почтовых систем, веб-приложений — везде, где есть аутентификация. На какие паттерны смотреть Отдельное событие 4625 — это просто кто-то забыл пароль. Но если вы видите следующие паттерны — это почти наверняка password spraying: Много неудачных входов с одного IP на разные аккаунты. Нормальный пользователь ошибается только со своим логином. Если с одного адреса за час приходит 20 неудачных попыток на 15 разных логинов — это атака. Рост количества событий 4771 (Kerberos pre-auth) без соответствующего роста 4625. Злоумышленники часто используют Kerberos, потому что он быстрее и реже логируется в стандартных настройках. Неудачные попытки входа на аккаунты, которые обычно не используются. Если в 3 часа ночи кто-то пытается войти на аккаунт сотрудника, который в отпуске — это подозрительно. Географическая аномалия. Входы из стран, где у компании нет офисов, или из IP-адресов, которые раньше не использовались. Сезонные пароли в логах. Если вы видите массовые попытки входа с паролями вида «Summer2024», «January!», «Company123» — это классический spraying. Инструменты для мониторинга Загонять логи в SIEM и писать правила — правильный путь, но не единственный. Вот варианты под разный масштаб: Для небольших компаний (до 500 пользователей): Скрипты PowerShell, которые раз в час анализируют журналы контроллеров домена и отправляют отчёт администратору. Можно найти готовые скрипты на GitHub — они считают количество неудачных входов по IP и аккаунтам. Бесплатные решения вроде Wazuh или Graylog — настраиваются за пару дней, дают базовый мониторинг и алерты. Для средних и крупных компаний: Полноценный SIEM (Splunk, QRadar, Microsoft Sentinel, ELK Stack). Настройте корреляционные правила для описанных выше паттернов. Azure AD Identity Protection — если используете облачную или гибридную инфраструктуру, он автоматически обнаруживает аномалии входа и может блокировать рискованные попытки. Специализированные решения для защиты учётных записей (например, Semperis, Attivo Networks) — они фокусируются именно на атаки на AD и видят то, что обычный SIEM пропустит. Что делать, если атака уже идёт Предположим, мониторинг показал аномалию: за последние сутки количество неудачных попыток входа выросло в 5 раз, основной источник — 15–20 IP-адресов из разных стран. Ваши действия: Не паникуйте и не блокируйте всё подряд. Сначала убедитесь, что это не легитимный сбой (например, пользователи массово забыли пароль после смены политики). Соберите данные: какие IP, какие аккаунты, какие пароли используются, через какой протокол (NTLM, Kerberos, веб-форма). Заблокируйте подозрительные IP на файрволе или VPN-шлюзе. Это не остановит атаку полностью, но замедлит её. Принудительно сбросьте пароли для аккаунтов, на которые пришлись попытки. Особенно для администраторов и привилегированных учётных записей. Проверьте, не было ли успешных входов. Ищите события 4624 (успешный вход) с тех же IP или на те же аккаунты, где были неудачные попытки. Проанализируйте скомпрометированные аккаунты. Что делал пользователь после входа? Были ли попытки доступа к необычным ресурсам, запуск подозрительных процессов? Частые ошибки при защите от password spraying Вот что я регулярно вижу в компаниях, которые думают, что защищены: Полагаться только на сложность паролей. Пользователь может использовать сложный пароль, но если он один и тот же на всех сервисах — утечка с одного сайта даёт доступ к корпоративной сети. Отключать мониторинг из-за «слишком много логов». Да, событий 4625 может быть тысячи в день. Но если вы не анализируете их — вы не видите атаку. Блокировать аккаунты слишком агрессивно. Если порог блокировки — 2 попытки, а окно — 5 минут, вы получите волну блокировок среди легитимных пользователей и усталость от алертов. Администраторы начнут игнорировать уведомления. Забивать на сервисные аккаунты. Учётные записи служб часто имеют простые пароли и никогда не меняются. Идеальная цель для spraying. Не тестировать защиту. Если вы не проводите регулярные пентесты или хотя бы имитацию атаки — вы не знаете, работает ли ваша защита. Как выстроить защиту под вашу ситуацию Не все меры одинаково полезны для всех. Вот как выбрать подход в зависимости от контекста: Если у вас небольшая компания и нет выделенной ИБ-команды: Включите запрет слабых паролей через Azure AD Password Protection или аналог. Настройте сбор событий 4625 и 4771 с контроллеров домена хотя бы в текстовый файл с ежедневным анализом. Включите MFA для всех внешних входов (VPN, почта, облачные сервисы). Запретите пароли короче 12 символов. Если у вас средний бизнес и есть системный администратор: Внедрите SIEM или хотя бы централизованный сбор логов с алертами на аномалии. Настройте блокировку IP после серии неудачных попыток на VPN-шлюзе. Проведите аудит сервисных аккаунтов и смените пароли на длинные случайные. Раз в квартал проводите тестовый password spraying через инструменты вроде SprayKing или MailSniper (с разрешения руководства, разумеется). Если у вас крупная компания и есть ИБ-отдел: Полноценный SIEM с корреляционными правилами для всех описанных паттернов. Azure AD Identity Protection или аналогичное решение для облачной инфраструктуры. Регулярные пентесты с фокусом на атаки на учётные записи. Мониторинг не только контроллеров домена, но и всех систем аутентификации. Автоматизированная реакция на инциденты: блокировка IP, сброс пароля, изоляция аккаунта. Итог: что делать прямо сейчас Password spraying — это не экзотическая атака. Это стандартный приём, который используют и скрипт-кидди, и профессиональные группировки. Если вы ничего не делаете — скорее всего, вас уже проверили. Вот три действия, которые стоит сделать на этой неделе: Проверьте настройки блокировки аккаунтов. Увеличьте окно подсчёта неудачных попыток до 24 часов. Убедитесь, что порог блокировки — 3–5 попыток. Начните собирать и анализировать события 4625 и 4771. Даже простой скрипт, который считает количество неудачных входов по IP за сутки, уже даст вам картину. Включите запрет слабых паролей. Это снимает 80% риска от password spraying, потому что атака опирается именно на популярные пароли. Полная защита — это не одна кнопка или один продукт. Это комбинация правильных настроек, мониторинга и регулярной проверки. Начните с малого, но начните сейчас — пока злоумышленники не нашли ваши слабые места раньше вас.
  7. Мониторинг: как увидеть атаку, которую не блокирует политика
  8. Ключевые события в логах В Windows-инфраструктуре основной источник — журналы безопасности контроллеров домена. Вот события, которые нужно собирать и анализировать: Код события Что означает Почему важно 4625 Неудачная попытка входа Основа для анализа. Нужно смотреть не на отдельные события, а на паттерны. 4740 Аккаунт заблокирован Если блокировки участились — возможна атака или проблемы с политикой. 4771 Ошибка Kerberos pre-authentication Часто используется в password spraying — атака идёт через Kerberos, а не через обычный вход. 4776 Попытка проверки учётных данных через NTLM Ещё один канал для атак. Если видите массовые 4776 — проверяйте источник. 4648 Вход с явными учётными данными Может указывать на использование скомпрометированных данных после успешного spraying. Важно: собирать эти события нужно не только с контроллеров домена, но и с VPN-серверов, почтовых систем, веб-приложений — везде, где есть аутентификация. На какие паттерны смотреть Отдельное событие 4625 — это просто кто-то забыл пароль. Но если вы видите следующие паттерны — это почти наверняка password spraying: Много неудачных входов с одного IP на разные аккаунты. Нормальный пользователь ошибается только со своим логином. Если с одного адреса за час приходит 20 неудачных попыток на 15 разных логинов — это атака. Рост количества событий 4771 (Kerberos pre-auth) без соответствующего роста 4625. Злоумышленники часто используют Kerberos, потому что он быстрее и реже логируется в стандартных настройках. Неудачные попытки входа на аккаунты, которые обычно не используются. Если в 3 часа ночи кто-то пытается войти на аккаунт сотрудника, который в отпуске — это подозрительно. Географическая аномалия. Входы из стран, где у компании нет офисов, или из IP-адресов, которые раньше не использовались. Сезонные пароли в логах. Если вы видите массовые попытки входа с паролями вида «Summer2024», «January!», «Company123» — это классический spraying. Инструменты для мониторинга Загонять логи в SIEM и писать правила — правильный путь, но не единственный. Вот варианты под разный масштаб: Для небольших компаний (до 500 пользователей): Скрипты PowerShell, которые раз в час анализируют журналы контроллеров домена и отправляют отчёт администратору. Можно найти готовые скрипты на GitHub — они считают количество неудачных входов по IP и аккаунтам. Бесплатные решения вроде Wazuh или Graylog — настраиваются за пару дней, дают базовый мониторинг и алерты. Для средних и крупных компаний: Полноценный SIEM (Splunk, QRadar, Microsoft Sentinel, ELK Stack). Настройте корреляционные правила для описанных выше паттернов. Azure AD Identity Protection — если используете облачную или гибридную инфраструктуру, он автоматически обнаруживает аномалии входа и может блокировать рискованные попытки. Специализированные решения для защиты учётных записей (например, Semperis, Attivo Networks) — они фокусируются именно на атаки на AD и видят то, что обычный SIEM пропустит. Что делать, если атака уже идёт Предположим, мониторинг показал аномалию: за последние сутки количество неудачных попыток входа выросло в 5 раз, основной источник — 15–20 IP-адресов из разных стран. Ваши действия: Не паникуйте и не блокируйте всё подряд. Сначала убедитесь, что это не легитимный сбой (например, пользователи массово забыли пароль после смены политики). Соберите данные: какие IP, какие аккаунты, какие пароли используются, через какой протокол (NTLM, Kerberos, веб-форма). Заблокируйте подозрительные IP на файрволе или VPN-шлюзе. Это не остановит атаку полностью, но замедлит её. Принудительно сбросьте пароли для аккаунтов, на которые пришлись попытки. Особенно для администраторов и привилегированных учётных записей. Проверьте, не было ли успешных входов. Ищите события 4624 (успешный вход) с тех же IP или на те же аккаунты, где были неудачные попытки. Проанализируйте скомпрометированные аккаунты. Что делал пользователь после входа? Были ли попытки доступа к необычным ресурсам, запуск подозрительных процессов? Частые ошибки при защите от password spraying Вот что я регулярно вижу в компаниях, которые думают, что защищены: Полагаться только на сложность паролей. Пользователь может использовать сложный пароль, но если он один и тот же на всех сервисах — утечка с одного сайта даёт доступ к корпоративной сети. Отключать мониторинг из-за «слишком много логов». Да, событий 4625 может быть тысячи в день. Но если вы не анализируете их — вы не видите атаку. Блокировать аккаунты слишком агрессивно. Если порог блокировки — 2 попытки, а окно — 5 минут, вы получите волну блокировок среди легитимных пользователей и усталость от алертов. Администраторы начнут игнорировать уведомления. Забивать на сервисные аккаунты. Учётные записи служб часто имеют простые пароли и никогда не меняются. Идеальная цель для spraying. Не тестировать защиту. Если вы не проводите регулярные пентесты или хотя бы имитацию атаки — вы не знаете, работает ли ваша защита. Как выстроить защиту под вашу ситуацию Не все меры одинаково полезны для всех. Вот как выбрать подход в зависимости от контекста: Если у вас небольшая компания и нет выделенной ИБ-команды: Включите запрет слабых паролей через Azure AD Password Protection или аналог. Настройте сбор событий 4625 и 4771 с контроллеров домена хотя бы в текстовый файл с ежедневным анализом. Включите MFA для всех внешних входов (VPN, почта, облачные сервисы). Запретите пароли короче 12 символов. Если у вас средний бизнес и есть системный администратор: Внедрите SIEM или хотя бы централизованный сбор логов с алертами на аномалии. Настройте блокировку IP после серии неудачных попыток на VPN-шлюзе. Проведите аудит сервисных аккаунтов и смените пароли на длинные случайные. Раз в квартал проводите тестовый password spraying через инструменты вроде SprayKing или MailSniper (с разрешения руководства, разумеется). Если у вас крупная компания и есть ИБ-отдел: Полноценный SIEM с корреляционными правилами для всех описанных паттернов. Azure AD Identity Protection или аналогичное решение для облачной инфраструктуры. Регулярные пентесты с фокусом на атаки на учётные записи. Мониторинг не только контроллеров домена, но и всех систем аутентификации. Автоматизированная реакция на инциденты: блокировка IP, сброс пароля, изоляция аккаунта. Итог: что делать прямо сейчас Password spraying — это не экзотическая атака. Это стандартный приём, который используют и скрипт-кидди, и профессиональные группировки. Если вы ничего не делаете — скорее всего, вас уже проверили. Вот три действия, которые стоит сделать на этой неделе: Проверьте настройки блокировки аккаунтов. Увеличьте окно подсчёта неудачных попыток до 24 часов. Убедитесь, что порог блокировки — 3–5 попыток. Начните собирать и анализировать события 4625 и 4771. Даже простой скрипт, который считает количество неудачных входов по IP за сутки, уже даст вам картину. Включите запрет слабых паролей. Это снимает 80% риска от password spraying, потому что атака опирается именно на популярные пароли. Полная защита — это не одна кнопка или один продукт. Это комбинация правильных настроек, мониторинга и регулярной проверки. Начните с малого, но начните сейчас — пока злоумышленники не нашли ваши слабые места раньше вас.
  9. На какие паттерны смотреть Отдельное событие 4625 — это просто кто-то забыл пароль. Но если вы видите следующие паттерны — это почти наверняка password spraying: Много неудачных входов с одного IP на разные аккаунты. Нормальный пользователь ошибается только со своим логином. Если с одного адреса за час приходит 20 неудачных попыток на 15 разных логинов — это атака. Рост количества событий 4771 (Kerberos pre-auth) без соответствующего роста 4625. Злоумышленники часто используют Kerberos, потому что он быстрее и реже логируется в стандартных настройках. Неудачные попытки входа на аккаунты, которые обычно не используются. Если в 3 часа ночи кто-то пытается войти на аккаунт сотрудника, который в отпуске — это подозрительно. Географическая аномалия. Входы из стран, где у компании нет офисов, или из IP-адресов, которые раньше не использовались. Сезонные пароли в логах. Если вы видите массовые попытки входа с паролями вида «Summer2024», «January!», «Company123» — это классический spraying. Инструменты для мониторинга Загонять логи в SIEM и писать правила — правильный путь, но не единственный. Вот варианты под разный масштаб: Для небольших компаний (до 500 пользователей): Скрипты PowerShell, которые раз в час анализируют журналы контроллеров домена и отправляют отчёт администратору. Можно найти готовые скрипты на GitHub — они считают количество неудачных входов по IP и аккаунтам. Бесплатные решения вроде Wazuh или Graylog — настраиваются за пару дней, дают базовый мониторинг и алерты. Для средних и крупных компаний: Полноценный SIEM (Splunk, QRadar, Microsoft Sentinel, ELK Stack). Настройте корреляционные правила для описанных выше паттернов. Azure AD Identity Protection — если используете облачную или гибридную инфраструктуру, он автоматически обнаруживает аномалии входа и может блокировать рискованные попытки. Специализированные решения для защиты учётных записей (например, Semperis, Attivo Networks) — они фокусируются именно на атаки на AD и видят то, что обычный SIEM пропустит. Что делать, если атака уже идёт Предположим, мониторинг показал аномалию: за последние сутки количество неудачных попыток входа выросло в 5 раз, основной источник — 15–20 IP-адресов из разных стран. Ваши действия: Не паникуйте и не блокируйте всё подряд. Сначала убедитесь, что это не легитимный сбой (например, пользователи массово забыли пароль после смены политики). Соберите данные: какие IP, какие аккаунты, какие пароли используются, через какой протокол (NTLM, Kerberos, веб-форма). Заблокируйте подозрительные IP на файрволе или VPN-шлюзе. Это не остановит атаку полностью, но замедлит её. Принудительно сбросьте пароли для аккаунтов, на которые пришлись попытки. Особенно для администраторов и привилегированных учётных записей. Проверьте, не было ли успешных входов. Ищите события 4624 (успешный вход) с тех же IP или на те же аккаунты, где были неудачные попытки. Проанализируйте скомпрометированные аккаунты. Что делал пользователь после входа? Были ли попытки доступа к необычным ресурсам, запуск подозрительных процессов? Частые ошибки при защите от password spraying Вот что я регулярно вижу в компаниях, которые думают, что защищены: Полагаться только на сложность паролей. Пользователь может использовать сложный пароль, но если он один и тот же на всех сервисах — утечка с одного сайта даёт доступ к корпоративной сети. Отключать мониторинг из-за «слишком много логов». Да, событий 4625 может быть тысячи в день. Но если вы не анализируете их — вы не видите атаку. Блокировать аккаунты слишком агрессивно. Если порог блокировки — 2 попытки, а окно — 5 минут, вы получите волну блокировок среди легитимных пользователей и усталость от алертов. Администраторы начнут игнорировать уведомления. Забивать на сервисные аккаунты. Учётные записи служб часто имеют простые пароли и никогда не меняются. Идеальная цель для spraying. Не тестировать защиту. Если вы не проводите регулярные пентесты или хотя бы имитацию атаки — вы не знаете, работает ли ваша защита. Как выстроить защиту под вашу ситуацию Не все меры одинаково полезны для всех. Вот как выбрать подход в зависимости от контекста: Если у вас небольшая компания и нет выделенной ИБ-команды: Включите запрет слабых паролей через Azure AD Password Protection или аналог. Настройте сбор событий 4625 и 4771 с контроллеров домена хотя бы в текстовый файл с ежедневным анализом. Включите MFA для всех внешних входов (VPN, почта, облачные сервисы). Запретите пароли короче 12 символов. Если у вас средний бизнес и есть системный администратор: Внедрите SIEM или хотя бы централизованный сбор логов с алертами на аномалии. Настройте блокировку IP после серии неудачных попыток на VPN-шлюзе. Проведите аудит сервисных аккаунтов и смените пароли на длинные случайные. Раз в квартал проводите тестовый password spraying через инструменты вроде SprayKing или MailSniper (с разрешения руководства, разумеется). Если у вас крупная компания и есть ИБ-отдел: Полноценный SIEM с корреляционными правилами для всех описанных паттернов. Azure AD Identity Protection или аналогичное решение для облачной инфраструктуры. Регулярные пентесты с фокусом на атаки на учётные записи. Мониторинг не только контроллеров домена, но и всех систем аутентификации. Автоматизированная реакция на инциденты: блокировка IP, сброс пароля, изоляция аккаунта. Итог: что делать прямо сейчас Password spraying — это не экзотическая атака. Это стандартный приём, который используют и скрипт-кидди, и профессиональные группировки. Если вы ничего не делаете — скорее всего, вас уже проверили. Вот три действия, которые стоит сделать на этой неделе: Проверьте настройки блокировки аккаунтов. Увеличьте окно подсчёта неудачных попыток до 24 часов. Убедитесь, что порог блокировки — 3–5 попыток. Начните собирать и анализировать события 4625 и 4771. Даже простой скрипт, который считает количество неудачных входов по IP за сутки, уже даст вам картину. Включите запрет слабых паролей. Это снимает 80% риска от password spraying, потому что атака опирается именно на популярные пароли. Полная защита — это не одна кнопка или один продукт. Это комбинация правильных настроек, мониторинга и регулярной проверки. Начните с малого, но начните сейчас — пока злоумышленники не нашли ваши слабые места раньше вас.
  10. Инструменты для мониторинга Загонять логи в SIEM и писать правила — правильный путь, но не единственный. Вот варианты под разный масштаб: Для небольших компаний (до 500 пользователей): Скрипты PowerShell, которые раз в час анализируют журналы контроллеров домена и отправляют отчёт администратору. Можно найти готовые скрипты на GitHub — они считают количество неудачных входов по IP и аккаунтам. Бесплатные решения вроде Wazuh или Graylog — настраиваются за пару дней, дают базовый мониторинг и алерты. Для средних и крупных компаний: Полноценный SIEM (Splunk, QRadar, Microsoft Sentinel, ELK Stack). Настройте корреляционные правила для описанных выше паттернов. Azure AD Identity Protection — если используете облачную или гибридную инфраструктуру, он автоматически обнаруживает аномалии входа и может блокировать рискованные попытки. Специализированные решения для защиты учётных записей (например, Semperis, Attivo Networks) — они фокусируются именно на атаки на AD и видят то, что обычный SIEM пропустит. Что делать, если атака уже идёт Предположим, мониторинг показал аномалию: за последние сутки количество неудачных попыток входа выросло в 5 раз, основной источник — 15–20 IP-адресов из разных стран. Ваши действия: Не паникуйте и не блокируйте всё подряд. Сначала убедитесь, что это не легитимный сбой (например, пользователи массово забыли пароль после смены политики). Соберите данные: какие IP, какие аккаунты, какие пароли используются, через какой протокол (NTLM, Kerberos, веб-форма). Заблокируйте подозрительные IP на файрволе или VPN-шлюзе. Это не остановит атаку полностью, но замедлит её. Принудительно сбросьте пароли для аккаунтов, на которые пришлись попытки. Особенно для администраторов и привилегированных учётных записей. Проверьте, не было ли успешных входов. Ищите события 4624 (успешный вход) с тех же IP или на те же аккаунты, где были неудачные попытки. Проанализируйте скомпрометированные аккаунты. Что делал пользователь после входа? Были ли попытки доступа к необычным ресурсам, запуск подозрительных процессов? Частые ошибки при защите от password spraying Вот что я регулярно вижу в компаниях, которые думают, что защищены: Полагаться только на сложность паролей. Пользователь может использовать сложный пароль, но если он один и тот же на всех сервисах — утечка с одного сайта даёт доступ к корпоративной сети. Отключать мониторинг из-за «слишком много логов». Да, событий 4625 может быть тысячи в день. Но если вы не анализируете их — вы не видите атаку. Блокировать аккаунты слишком агрессивно. Если порог блокировки — 2 попытки, а окно — 5 минут, вы получите волну блокировок среди легитимных пользователей и усталость от алертов. Администраторы начнут игнорировать уведомления. Забивать на сервисные аккаунты. Учётные записи служб часто имеют простые пароли и никогда не меняются. Идеальная цель для spraying. Не тестировать защиту. Если вы не проводите регулярные пентесты или хотя бы имитацию атаки — вы не знаете, работает ли ваша защита. Как выстроить защиту под вашу ситуацию Не все меры одинаково полезны для всех. Вот как выбрать подход в зависимости от контекста: Если у вас небольшая компания и нет выделенной ИБ-команды: Включите запрет слабых паролей через Azure AD Password Protection или аналог. Настройте сбор событий 4625 и 4771 с контроллеров домена хотя бы в текстовый файл с ежедневным анализом. Включите MFA для всех внешних входов (VPN, почта, облачные сервисы). Запретите пароли короче 12 символов. Если у вас средний бизнес и есть системный администратор: Внедрите SIEM или хотя бы централизованный сбор логов с алертами на аномалии. Настройте блокировку IP после серии неудачных попыток на VPN-шлюзе. Проведите аудит сервисных аккаунтов и смените пароли на длинные случайные. Раз в квартал проводите тестовый password spraying через инструменты вроде SprayKing или MailSniper (с разрешения руководства, разумеется). Если у вас крупная компания и есть ИБ-отдел: Полноценный SIEM с корреляционными правилами для всех описанных паттернов. Azure AD Identity Protection или аналогичное решение для облачной инфраструктуры. Регулярные пентесты с фокусом на атаки на учётные записи. Мониторинг не только контроллеров домена, но и всех систем аутентификации. Автоматизированная реакция на инциденты: блокировка IP, сброс пароля, изоляция аккаунта. Итог: что делать прямо сейчас Password spraying — это не экзотическая атака. Это стандартный приём, который используют и скрипт-кидди, и профессиональные группировки. Если вы ничего не делаете — скорее всего, вас уже проверили. Вот три действия, которые стоит сделать на этой неделе: Проверьте настройки блокировки аккаунтов. Увеличьте окно подсчёта неудачных попыток до 24 часов. Убедитесь, что порог блокировки — 3–5 попыток. Начните собирать и анализировать события 4625 и 4771. Даже простой скрипт, который считает количество неудачных входов по IP за сутки, уже даст вам картину. Включите запрет слабых паролей. Это снимает 80% риска от password spraying, потому что атака опирается именно на популярные пароли. Полная защита — это не одна кнопка или один продукт. Это комбинация правильных настроек, мониторинга и регулярной проверки. Начните с малого, но начните сейчас — пока злоумышленники не нашли ваши слабые места раньше вас.
  11. Что делать, если атака уже идёт
  12. Частые ошибки при защите от password spraying
  13. Как выстроить защиту под вашу ситуацию
  14. Итог: что делать прямо сейчас

Почему password spraying обходит обычную защиту

Классическая атака брутфорса — это когда злоумышленник берёт один логин и перебирает пароли: сотни или тысячи попыток в минуту. Active Directory или другая система быстро это замечает, счётчик попыток переполняется, аккаунт блокируется. Защита сработала.

Password spraying работает иначе. Злоумышленник берёт список всех логинов компании (а его легко собрать по шаблонам почтовых адресов — ivanov@company.ru, petrov@company.ru и так далее) и потом перебирает по одному паролю в час или даже в сутки для каждого аккаунта. Десятки тысяч попыток, размазанных на дни и недели.

Вот почему стандартная политика «блокировать после 5 неудачных попыток за 15 минут» не помогает:

  • Атака использует 1–2 попытки на каждый аккаунт в день — счётчик не переполняется.
  • Пароли меняются: сегодня «Company2024», завтра «Qwerty123», послзавтра «Summer!» — каждая попытка уникальна.
  • Используются сотни разных IP-адресов (через VPN-сервисы, ботнеты или прокси), и с одного IP приходит пара запросов — нет явного источника для блокировки.
  • Интервал между попытками может составлять часы — не попадает в стандартное окно подсчёта.

Итог: ни одна учётная запись не блокируется автоматически, но через неделю–две атака может найти 10–20 работающих комбинаций «логин-пароль» в вашей сети. Дальше — горизонтальное перемещение, повышение привилегий, утечка данных.

Настройка ограничения попыток входа против spraying

Полностью полагаться на политики блокировки нельзя, но правильные настройки усложняют атаку и создают шум, который можно отследить.

1. Увеличьте окно времени для подсчёта неудачных попыток

Стандартное окно в 15–30 минут не видит password spraying, потому что атака растягивается на дни. Увеличьте хотя бы до 24–48 часов.

Что настраивать в Active Directory:

  • Account lockout threshold — количество неудачных попыток до блокировки. Оставьте 3–5, не больше.
  • Account lockout duration — время блокировки. Хотя бы 15–30 минут. В идеале — разблокировка только через администратора, но это создаст дополнительную нагрузку на поддержку.
  • Reset account lockout counter after — это ключевой параметр. Если сейчас он стоит на 15 минут, поставьте 1440 (24 часа) или 2880 (48 часов).

Почему так: если блокировать аккаунт после 3 неудачных попыток за последние 24 часа, то злоумышленник, делающий 2 попытки в сутки, всё ещё пройдёт мимо. Но если он ошибётся с ритмом или автоматически увеличит частоту — аккаунт заблокируется, и в мониторинге появится аномалия.

2. Используйте капчу или адаптивную блокировку

Для веб-приложений и VPN-шлюзов — обязательная капча после 2–3 неудачных попыток. Для корпоративных порталов можно настроить аналогичную логику: после N неудачных попыток — дополнительный фактор или временная задержка.

Это не спасёт от целевых атак на один аккаунт, но делает массовый перебор по всему списку логинов крайне медленным. Увеличение времени между попытками на 2–3 секунды превращает атаку, которая раньше занимала час, в атаку на неделю.

3. Запретите популярные пароли — это критично

Password spraying опирается на то, что часть пользователей использует слабые пароли. Если в вашей компании 10 000 человек и хотя бы 0,5% из них используют «Qwerty123» — это 50 скомпрометированных аккаунтов после одной атаки.

Что можно сделать:

  • Внедрите фильтр паролей в Active Directory (или используйте Azure AD Password Protection). Он проверяет новый пароль по чёрному списку: запрещённые слова, названия компании, сезонные пароли и их вариации.
  • Включите проверку по базе утёкших паролей — это уже встроено в Azure AD и доступно для on-premise через сторонние решения.
  • Запретите пароли короче 12 символов. Для spraying короткие пароли — подарок: перебор идёт быстрее, списки уязвимых паролей короче.

4. Блокировка по IP-адресам — с осторожностью

Блокировать IP-адрес после серии неудачных попыток — логично, но password spraying использует сотни адресов. Если вы настроите жёсткую блокировку, вы можете заблокировать легитимных пользователей, которые выходят через те же прокси или корпоративные NAT.

Лучший подход — не жёсткая блокировка, а скоринг: если с одного IP за час приходит более 10 неудачных попыток входа на разные аккаунты — это аномалия. Такой IP можно временно пометить и отправить алерт администратору.

Мониторинг: как увидеть атаку, которую не блокирует политика

Ограничение попыток — это фундамент. Но без мониторинга вы узнаете об атаке только когда будет поздно. Вот что нужно отслеживать и как это настроить.

Ключевые события в логах

В Windows-инфраструктуре основной источник — журналы безопасности контроллеров домена. Вот события, которые нужно собирать и анализировать:

Код события Что означает Почему важно
4625 Неудачная попытка входа Основа для анализа. Нужно смотреть не на отдельные события, а на паттерны.
4740 Аккаунт заблокирован Если блокировки участились — возможна атака или проблемы с политикой.
4771 Ошибка Kerberos pre-authentication Часто используется в password spraying — атака идёт через Kerberos, а не через обычный вход.
4776 Попытка проверки учётных данных через NTLM Ещё один канал для атак. Если видите массовые 4776 — проверяйте источник.
4648 Вход с явными учётными данными Может указывать на использование скомпрометированных данных после успешного spraying.

Важно: собирать эти события нужно не только с контроллеров домена, но и с VPN-серверов, почтовых систем, веб-приложений — везде, где есть аутентификация.

На какие паттерны смотреть

Отдельное событие 4625 — это просто кто-то забыл пароль. Но если вы видите следующие паттерны — это почти наверняка password spraying:

  • Много неудачных входов с одного IP на разные аккаунты. Нормальный пользователь ошибается только со своим логином. Если с одного адреса за час приходит 20 неудачных попыток на 15 разных логинов — это атака.
  • Рост количества событий 4771 (Kerberos pre-auth) без соответствующего роста 4625. Злоумышленники часто используют Kerberos, потому что он быстрее и реже логируется в стандартных настройках.
  • Неудачные попытки входа на аккаунты, которые обычно не используются. Если в 3 часа ночи кто-то пытается войти на аккаунт сотрудника, который в отпуске — это подозрительно.
  • Географическая аномалия. Входы из стран, где у компании нет офисов, или из IP-адресов, которые раньше не использовались.
  • Сезонные пароли в логах. Если вы видите массовые попытки входа с паролями вида «Summer2024», «January!», «Company123» — это классический spraying.

Инструменты для мониторинга

Загонять логи в SIEM и писать правила — правильный путь, но не единственный. Вот варианты под разный масштаб:

Для небольших компаний (до 500 пользователей):

  • Скрипты PowerShell, которые раз в час анализируют журналы контроллеров домена и отправляют отчёт администратору. Можно найти готовые скрипты на GitHub — они считают количество неудачных входов по IP и аккаунтам.
  • Бесплатные решения вроде Wazuh или Graylog — настраиваются за пару дней, дают базовый мониторинг и алерты.

Для средних и крупных компаний:

  • Полноценный SIEM (Splunk, QRadar, Microsoft Sentinel, ELK Stack). Настройте корреляционные правила для описанных выше паттернов.
  • Azure AD Identity Protection — если используете облачную или гибридную инфраструктуру, он автоматически обнаруживает аномалии входа и может блокировать рискованные попытки.
  • Специализированные решения для защиты учётных записей (например, Semperis, Attivo Networks) — они фокусируются именно на атаки на AD и видят то, что обычный SIEM пропустит.

Что делать, если атака уже идёт

Предположим, мониторинг показал аномалию: за последние сутки количество неудачных попыток входа выросло в 5 раз, основной источник — 15–20 IP-адресов из разных стран. Ваши действия:

  1. Не паникуйте и не блокируйте всё подряд. Сначала убедитесь, что это не легитимный сбой (например, пользователи массово забыли пароль после смены политики).
  2. Соберите данные: какие IP, какие аккаунты, какие пароли используются, через какой протокол (NTLM, Kerberos, веб-форма).
  3. Заблокируйте подозрительные IP на файрволе или VPN-шлюзе. Это не остановит атаку полностью, но замедлит её.
  4. Принудительно сбросьте пароли для аккаунтов, на которые пришлись попытки. Особенно для администраторов и привилегированных учётных записей.
  5. Проверьте, не было ли успешных входов. Ищите события 4624 (успешный вход) с тех же IP или на те же аккаунты, где были неудачные попытки.
  6. Проанализируйте скомпрометированные аккаунты. Что делал пользователь после входа? Были ли попытки доступа к необычным ресурсам, запуск подозрительных процессов?

Частые ошибки при защите от password spraying

Вот что я регулярно вижу в компаниях, которые думают, что защищены:

  • Полагаться только на сложность паролей. Пользователь может использовать сложный пароль, но если он один и тот же на всех сервисах — утечка с одного сайта даёт доступ к корпоративной сети.
  • Отключать мониторинг из-за «слишком много логов». Да, событий 4625 может быть тысячи в день. Но если вы не анализируете их — вы не видите атаку.
  • Блокировать аккаунты слишком агрессивно. Если порог блокировки — 2 попытки, а окно — 5 минут, вы получите волну блокировок среди легитимных пользователей и усталость от алертов. Администраторы начнут игнорировать уведомления.
  • Забивать на сервисные аккаунты. Учётные записи служб часто имеют простые пароли и никогда не меняются. Идеальная цель для spraying.
  • Не тестировать защиту. Если вы не проводите регулярные пентесты или хотя бы имитацию атаки — вы не знаете, работает ли ваша защита.

Как выстроить защиту под вашу ситуацию

Не все меры одинаково полезны для всех. Вот как выбрать подход в зависимости от контекста:

Если у вас небольшая компания и нет выделенной ИБ-команды:

  • Включите запрет слабых паролей через Azure AD Password Protection или аналог.
  • Настройте сбор событий 4625 и 4771 с контроллеров домена хотя бы в текстовый файл с ежедневным анализом.
  • Включите MFA для всех внешних входов (VPN, почта, облачные сервисы).
  • Запретите пароли короче 12 символов.

Если у вас средний бизнес и есть системный администратор:

  • Внедрите SIEM или хотя бы централизованный сбор логов с алертами на аномалии.
  • Настройте блокировку IP после серии неудачных попыток на VPN-шлюзе.
  • Проведите аудит сервисных аккаунтов и смените пароли на длинные случайные.
  • Раз в квартал проводите тестовый password spraying через инструменты вроде SprayKing или MailSniper (с разрешения руководства, разумеется).

Если у вас крупная компания и есть ИБ-отдел:

  • Полноценный SIEM с корреляционными правилами для всех описанных паттернов.
  • Azure AD Identity Protection или аналогичное решение для облачной инфраструктуры.
  • Регулярные пентесты с фокусом на атаки на учётные записи.
  • Мониторинг не только контроллеров домена, но и всех систем аутентификации.
  • Автоматизированная реакция на инциденты: блокировка IP, сброс пароля, изоляция аккаунта.

Итог: что делать прямо сейчас

Password spraying — это не экзотическая атака. Это стандартный приём, который используют и скрипт-кидди, и профессиональные группировки. Если вы ничего не делаете — скорее всего, вас уже проверили.

Вот три действия, которые стоит сделать на этой неделе:

  1. Проверьте настройки блокировки аккаунтов. Увеличьте окно подсчёта неудачных попыток до 24 часов. Убедитесь, что порог блокировки — 3–5 попыток.
  2. Начните собирать и анализировать события 4625 и 4771. Даже простой скрипт, который считает количество неудачных входов по IP за сутки, уже даст вам картину.
  3. Включите запрет слабых паролей. Это снимает 80% риска от password spraying, потому что атака опирается именно на популярные пароли.

Полная защита — это не одна кнопка или один продукт. Это комбинация правильных настроек, мониторинга и регулярной проверки. Начните с малого, но начните сейчас — пока злоумышленники не нашли ваши слабые места раньше вас.

Оцените статью
PEFile — Безопасность и технологии простым языком