Многие организации считают, что после внедрения многофакторной аутентификации (MFA) риск компрометации учетных записей существенно снижается. Для облачных сервисов это в целом верно. Однако в средах Windows и Active Directory ситуация сложнее: злоумышленники по‑прежнему ежедневно получают доступ к сетям, используя валидные логины и пароли, без каких‑либо дополнительных факторов.
Почему MFA не закрывает все сценарии аутентификации в Windows
Типичная архитектура сегодня — гибридная: облачный поставщик удостоверений (IdP) вроде Microsoft Entra ID, Okta или Google Workspace защищает SaaS‑приложения и федеративный вход с помощью MFA. Но значительная часть входов в инфраструктуре Windows по‑прежнему проходит через традиционные механизмы аутентификации Active Directory (Kerberos и NTLM), которые не взаимодействуют с облачным IdP и не вызывают MFA‑проверку.
Локальный вход и доменные контроллеры
Когда пользователь входит непосредственно в доменную рабочую станцию или на сервер, проверку его учетных данных выполняет он‑прем AD‑контроллер домена. Если не внедрены Windows Hello for Business, смарт‑карты или иная интегрированная схема MFA, такой вход фактически опирается только на пароль (или его хэш). С точки зрения контроллера домена это обычный запрос аутентификации, и никакие облачные политики MFA на него не распространяются.
В результате, овладев паролем пользователя или NTLM‑хэшем, атакующий может спокойно аутентифицироваться на доменной машине, минуя все облачные механизмы защиты, которые надежно обороняют лишь веб‑приложения и SSO‑порталы.
RDP и VPN: любимые цели атакующих
Удаленный рабочий стол (RDP) и VPN остаются одними из наиболее атакуемых точек входа в Windows‑сети. Даже если RDP не опубликован в интернет, злоумышленники часто добираются до него через lateral movement после первоначального взлома. Прямое RDP‑подключение к серверу обычно опирается на доменные учетные данные и не проходит через облачный IdP, а значит, вход может происходить без MFA.
Чтобы закрыть этот пробел, организации используют решения класса Specops Secure Access, которые позволяют навязать MFA именно на уровне Windows‑логона, RDP и VPN, а также защитить офлайн‑вход с помощью одноразовых кодов. Это делает кражу одного пароля недостаточной для доступа к системе.
Наследие NTLM и атаки pass-the-hash
Несмотря на долгий курс на отказ от NTLM в пользу Kerberos, этот протокол все еще активно используется для совместимости. NTLM остаётся привлекательной целью для атак, поскольку поддерживает технику pass‑the‑hash: злоумышленнику не нужно знать пароль в открытом виде — достаточно перехватить или выгрузить NTLM‑хэш и предъявить его системе.
В таких сценариях MFA бессильна: если система принимает хэш как доказательство подлинности, дополнительный фактор просто не запрашивается. Дополнительный риск в том, что NTLM‑аутентификация зачастую спрятана внутри внутренних сервисов и устаревших приложений, и о её наличии вспоминают только при инцидентах или аудите.
Kerberos и кража билетов в Active Directory
Kerberos — основной протокол аутентификации в AD. Здесь фокус атак смещается с паролей на Kerberos‑билеты. Получив доступ к памяти скомпрометированного хоста или к учетной записи с высокими привилегиями, злоумышленники могут красть или подделывать билеты (включая известные сценарии «золотых» и «серебряных» билетов).
Такие атаки позволяют сохранять долгосрочный доступ и свободно перемещаться по сети, уменьшая потребность в повторном вводе паролей и, соответственно, снижая шанс срабатывания каких‑либо средств обнаружения. Даже смена пароля не всегда решает проблему, если корневая причина компрометации (например, взлом контроллера домена) не устранена.
Локальные администраторы, SMB и сервисные аккаунты
Во многих организациях до сих пор широко используются локальные учетные записи администраторов для поддержки рабочих станций и восстановления доступа. Если пароль локального администратора повторно используется на множестве устройств, достаточно взломать одну машину, чтобы масштабировать доступ на десятки и сотни узлов. Эти логины аутентифицируются локально и полностью обходят MFA и политики условного доступа Entra ID.
Протокол SMB, применяемый для файлового обмена и удаленного администрирования, остается одним из самых надежных каналов lateral movement: обладая валидными учетными данными, атакующие используют административные шары (например, C$) и удаленное выполнение команд для быстрого продвижения по сети. На этом уровне MFA почти никогда не применяется, потому что трафик считается «внутренним».
Отдельную категорию риска составляют сервисные аккаунты, используемые для запуска служб, планировщиков задач и интеграций. Их пароли часто не истекают годами, обладают широкими привилегиями и редко попадают в сферу мониторинга. Для них сложно реализовать MFA, потому что аутентификация автоматизирована, а многие легаси‑системы не поддерживают современные протоколы.
Практические меры защиты Windows-аутентификации
Во‑первых, необходима усиленная политика паролей. Рекомендуется переходить к длинным парольным фразам (от 15 символов), запрещать повторное использование старых паролей и блокировать предсказуемые шаблоны. Важно учитывать, что значительная часть учетных данных уже фигурирует в наборах слитых паролей, доступных злоумышленникам для атак повторного использования (credential stuffing).
Решения вроде Specops Password Policy позволяют реализовать гибкие политики, выходящие за рамки стандартных возможностей Microsoft. Функция Breached Password Protection в таких продуктах автоматически сверяет пароли Active Directory с большой базой ранее скомпрометированных учетных данных (более 5,4 млрд записей) и предупреждает, если пользователь выбирает уже «засвеченный» пароль.
Во‑вторых, целесообразно : провести инвентаризацию мест, где он задействован, ограничить или отключить его там, где это возможно, и ужесточить контроль в оставшихся случаях. Параллельно стоит рассматривать Windows‑аутентификацию как самостоятельную поверхность атаки и внедрять MFA именно на уровне входа в ОС и удаленного доступа — через специализированные решения, такие как Specops Secure Access.
Наконец, критически важно относиться к сервисным и административным учетным записям как к высокорисковым. Их необходимо инвентаризировать, урезать избыточные привилегии, регулярно ротировать пароли, удалять неиспользуемые аккаунты и усиленно мониторить любую активность с их участием.
Организации, которые смотрят на MFA шире, чем просто на защиту облачных приложений, и последовательно укрепляют аутентификацию в Windows — от политики паролей и контроля NTLM до MFA на уровне логона и RDP, — существенно сокращают вероятность успешных атак с использованием учетных данных. Следующий логичный шаг — провести аудит своей AD‑среды, выявить «слепые зоны» в аутентификации и протестировать специализированные инструменты, которые помогают закрыть эти пробелы на практике.
