Парольная политика: разбор утечек и защита

Понедельник, 9:40 утра. Внутренний пентест для финансовой организации, первый час работы. Запускаю password spraying через CrackMapExec с коротким словарём из 50 паролей - сезонные комбинации, название компании с годом, стандартные "Welcome1!". Через 12 минут - 37 валидных учётных записей. Пароль Company2024! подходил к 14 из них, у трёх оказались права доменного администратора. Вся Active Directory - за 12 минут и один словарь.

По данным Verizon Data Breach Investigations Report 2024, stolen credentials - ведущий вектор в категории Basic Web Application Attacks. А "123456" и "password", согласно NordPass, встречаются в более чем 85% паролей из крупных утечек. Парольная политика, которая работает не на бумаге, а в конфигурации домена - единственный способ исключить такие кейсы системно.

Слабые пароли и утечки данных: разбор реальных инцидентов​

Русскоязычные материалы о парольной политике обычно сводятся к шаблону документа: требования к длине, запрет на стикеры, ответственность сотрудников. Конкретные инциденты с TTPs атакующих не разбирает никто. Три кейса ниже показывают, как именно слабые пароли становятся точкой входа - и какие процессы оказались сломаны. Подробнее - в нашем обзоре атаки на аутентификацию.

SolarWinds: пароль администратора по умолчанию в supply chain​

Пароль solarwinds123 стоял на внутреннем сервере обновлений SolarWinds и попал в публичный репозиторий. Атака была многоступенчатой - это не единственная причина компрометации цепочки поставок - но пароль администратора по умолчанию стал одной из точек входа. Результат: компрометация обновлений Orion, пострадали тысячи организаций, включая государственные структуры.

Классика: управление учетными данными прописано на бумаге, но технически не применяется. Пароль прошёл мимо аудита, потому что на сервере обновлений вообще не действовала доменная политика.

Verkada и Mirai: дефолтные учётные данные​

В 2021 году группа атакующих получила доступ к более чем 150 000 камер видеонаблюдения Verkada. Причина - учётные данные суперадминистратора с полным доступом к камерам клиентов нашлись в открытом доступе. Тот же вектор эксплуатировал ботнет Mirai, массово ломавший IoT-устройства с заводскими admin:admin и root:root. В обоих случаях парольная политика компании попросту не распространялась на IoT-сегмент: устройства разворачивались без смены дефолтных паролей, сервисные учётки не контролировались SIEM.

M&S и Co-op: credential stuffing и слабый процесс сброса паролей​

В недавних атаках на британские ритейлеры Marks & Spencer, Co-op и Harrods злоумышленники пошли через социальную инженерию: имперсонировали сотрудников и убедили IT-хелпдеск сбросить пароли к учётным записям (по данным CyberLab, со ссылкой на rradar). Обошли стандартные процедуры аутентификации, получили доступ к данным клиентов, платёжной информации и логинам. Скомпрометированные учётные данные повторно использовались на нескольких платформах - масштаб утечки вырос кратно.

Проблема не только в слабых паролях, но и в отсутствии строгой верификации при сбросе. Если парольная политика не покрывает процедуру восстановления доступа - она неполная.

Масштаб проблемы в цифрах​

По данным Have I Been Pwned, только в марте 2026 года утечка колумбийского финтеха Addi затронула 34.5 млн записей, включая email-адреса и государственные ID-документы (паролей в этой утечке не было, но скомпрометированные email используются в credential stuffing). Российский онлайн-кинотеатр START потерял данные около 7.46 млн пользователей (утечка 2021 года, публично стала известна в августе 2022-го; 7 455 386 записей по HIBP), в том числе пароли. Каждая подобная утечка - прямое следствие того, что защита учётных записей от взлома не была приоритетом.

TTPs credential-атак и детектирование в SIEM​

Компрометация учетных записей: бизнес-логика​

Зачем атакующему пароли? Мотивация прямая: получить valid credentials для первоначального доступа, закрепиться в инфраструктуре и двигаться латерально. В случае credential stuffing монетизация ещё проще - продажа доступов на даркнете, takeover аккаунтов в финансовых сервисах.

Credential stuffing - автоматическая подстановка пар логин:пароль из утечек в авторизационные формы других сервисов. Расчёт на то, что пользователь тащит один пароль на все платформы. Password spraying - другой подход: один популярный пароль (тот самый Company2024! или Summer2025) прогоняется по всем учёткам домена. Брутфорс атака в чистом виде - перебор всех комбинаций - встречается реже, потому что легко ловится блокировкой. Spraying хитрее: одна-две попытки на учётку, порог блокировки не срабатывает.

По классификации OWASP это A07:2021 (Identification and Authentication Failures) - слабые пароли, credential stuffing, отсутствие MFA.

Инструменты, которые я использую на пентестах для этих техник: Hydra для брутфорса сетевых протоколов, CrackMapExec для password spraying по SMB/WinRM в домене, Kerbrute для AS-REP spraying в Kerberos. Все работают с rockyou.txt и кастомными словарями из утечек.

Detection-чеклист: правила корреляции для SIEM​

Detection credential-атак строится на аномалиях относительно baseline (NIST CSF v2.0, DE.AE-01 - установление базовой линии сетевых операций и ожидаемых потоков данных).

Password spraying - множество неудачных попыток входа к разным учёткам с одного IP за короткий промежуток. Ключевой EventID в Windows Security Log - 4625 (Failed Logon):
Credential stuffing - аномально высокая частота аутентификаций из нетипичных гео-зон или с IP-адресов, ранее замеченных в abuse. Проверка через AbuseIPDB с abuseConfidenceScore > 75 как порог для блокирования. Для веб-приложений - корреляция HTTP 401/403 с частотой выше baseline.

Что мониторить для защиты учётных записей от взлома:

• EventID 4625 (Failed Logon) - группировка по TargetUserName и IpAddress
• EventID 4740 (Account Lockout) - массовые блокировки = индикатор spraying
• EventID 4624 (Successful Logon) с LogonType 10 (Remote) из нетипичных подсетей
• Последовательность: серия 4625 -> единичный 4624 = успешный подбор пароля
• Аутентификация в нехарактерное время (ночные часы для конкретного пользователя)
• Один пользователь, множество источников входа за короткий период - возможный reuse утёкших паролей

Внедрение парольной политики: NIST SP 800-63B и Active Directory​

Требования к сложности пароля: что говорит NIST​

NIST SP 800-63B (Digital Identity Guidelines) радикально пересмотрел подход к паролям. Ключевые рекомендации, которые расходятся с «традиционной» политикой паролей в компании:

• Минимальная длина - не менее 8 символов для пользовательских паролей (NIST SP 800-63B). CIS рекомендует 14+ для аккаунтов без MFA и 8+ с MFA. Длина - главный фактор устойчивости к перебору, важнее состава символов
• Отказ от принудительной ротации - смена пароля только при подтверждённой компрометации, не по календарю. Принудительная смена каждые 90 дней порождает предсказуемые паттерны: Winter2024 -> Spring2024 -> Summer2024
• Отказ от обязательных правил состава - требование "заглавная + строчная + цифра + спецсимвол" ведёт к паролям вида Password1!, формально подходящим под политику, но подбираемым за секунды. NIST указывает, что польза жёстких правил состава ограничена
• Проверка по блок-листу - каждый новый пароль сравнивается со списком скомпрометированных (Have I Been Pwned API), словарём популярных паролей и контекстно-зависимыми значениями (название компании, логин)
• Максимальная длина не менее 64 символов - ограничение максимальной длины пароля, по мнению OWASP, одна из самых вредных практик

В NIST SP 800-53 Rev 5 это покрывается контролями IA-1 (Identification and Authentication Policy) и AC-1 (Access Control Policy), которые требуют документирования политик аутентификации с чёткими ролями и ответственностью. Менеджер паролей корпоративного уровня закрывает проблему запоминания длинных паролей - пользователь помнит один мастер-пароль, остальные генерируются автоматически.

Fine-Grained Password Policy в Active Directory​

Стандартная Default Domain Password Policy применяется ко всему домену одинаково. Fine-Grained Password Policy (FGPP) позволяет задать разные требования к сложности пароля для разных групп: жёстче для администраторов и сервисных учёток, мягче для обычных пользователей с MFA.
Минимальные параметры FGPP для разных типов учётных записей:


Для сервисных учёток критично: запрет интерактивного входа (Deny log on locally), хранение паролей в Vault или секрет-менеджере (не в скриптах и не в GPO Preferences), ротация при смене владельца или компрометации. После каждого развёртывания нового сервера я запускаю PowerShell-скрипт, который проверяет наличие учёток с пустыми или дефолтными паролями. Находит - стабильно.

MFA внедрение: двухфакторная аутентификация​

Двухфакторная аутентификация - контроль, который по оценкам отраслевых отчётов снижает риск credential-атак до 99%. Приоритет внедрения MFA:

1. VPN и удалённый доступ - первый вектор входа в корпоративную сеть
2. Административные учётные записи - Domain Admins, Enterprise Admins
3. Корпоративная почта - точка входа для BEC
4. Системы с критичными данными - CRM, ERP, финансовые приложения

При выборе второго фактора: аппаратные ключи FIDO2 устойчивы к фишингу, TOTP-приложения (Google Authenticator, Microsoft Authenticator) - приемлемый компромисс, SMS-коды - худший вариант из-за уязвимости к SIM-свопу. NIST CSF v2.0 (PR.AA-01) прямо указывает на управление идентификацией и аутентификацией как на обязательный элемент защиты.

Правовой контекст: ФЗ-152 "О персональных данных" обязывает оператора ПДн принимать организационные и технические меры защиты - парольная политика входит в их число. Для субъектов КИИ ФСТЭК проводит проверки выполнения требований безопасности по ФЗ-187 (ст. 14). Штрафы по GDPR достигают 4% годового оборота, PCI DSS (Requirement 8) требует уникальных ID и MFA для удалённого доступа.

Чеклист внедрения парольной политики в компании​

Порядок действий для перехода от бумажной политики к работающей защите:

Чеклист - не разовая акция. Baseline для детекции аномалий нужно пересматривать при каждом изменении инфраструктуры.

Большинство парольных политик, которые я видел на аудитах, написаны "от обязанности" - чтобы был документ для проверки ФСТЭК или для галочки ISO 27001. Технические настройки при этом дефолтные: MinPasswordLength = 7, LockoutThreshold = 0 (блокировки нет), PasswordHistoryCount = 0. Документ есть - защиты нет.

Ещё одна проблема, о которой мало кто говорит вслух: принудительная ротация паролей каждые 90 дней до сих пор работает как де-факто стандарт в большинстве российских организаций, хотя NIST ещё в 2017 году рекомендовал от неё отказаться. Результат - Leto2024! -> Osen2024! -> Zima2025! в каждом домене. Password spraying по сезонным паттернам - первое, что я пробую на пентесте. Срабатывает стабильно.

Парольная политика - не документ. Это набор технических контролей: FGPP в AD, блок-лист на основе утечек, MFA на всех внешних точках входа и правила корреляции в SIEM, которые ловят spraying до того, как атакующий попадёт внутрь. Пока между документом и конфигурацией домена есть разрыв - "solarwinds123" будет повторяться в разных компаниях снова и снова. Если у тебя другой стек детекции - на codeby.net обсуждаем, как адаптировать правила корреляции credential-атак под конкретные SIEM.