Pass-the-Hash относится к числу тех атак, которые не взламывают ничего в буквальном смысле: не подбирается пароль, не эксплуатируется уязвимость в коде, не обходится проверка подлинности. Вместо этого атакующий использует само доказательство знания пароля - криптографический хеш - в качестве ключа для аутентификации на удалённой системе. Возможность такого сценария не является дефектом конкретной версии Windows, а вытекает из архитектуры старых протоколов сетевой аутентификации, прежде всего NTLM. Защитнику эта механика важна не для воспроизведения атаки, а для правильной расстановки приоритетов: если хеш пароля эквивалентен самим учётным данным, то хранение хешей должно регулироваться так же строго, как хранение паролей в открытом виде, а их чтение из памяти или реестра должно считаться полноценной кражей учётных данных. Статья разбирает устройство NTLM-аутентификации, причины отсутствия соли в NTLM-хеше, отличия от Kerberos, типовые места утечки хешей и системные меры защиты - от Credential Guard и изоляции LSASS до модели ограниченного администрирования и детектирования по журналам событий. Весь материал ориентирован на инженера по защите и не содержит указаний по выполнению атак.
Как NTLM принимает хеш в качестве доказательства знания пароля
Протокол NTLM построен на схеме «запрос-ответ». Когда клиент обращается к серверу, тот формирует случайное значение - серверный вызов. Клиент вычисляет ответ как криптографическую функцию от этого вызова и от хеша пароля пользователя и отправляет ответ серверу. Сервер, знающий тот же хеш, выполняет то же вычисление и сверяет результаты. Пароль при этом по сети не передаётся и на сервере в читаемом виде не хранится - эта часть конструкции корректна.
Проблема в другом: единственным секретом на стороне клиента является именно хеш пароля, а не что-либо производное от него. Отсюда следует архитектурный вывод, лежащий в основе всего класса атак Pass-the-Hash. Сторона, владеющая NTLM-хешем учётной записи, способна сформировать корректный NTLM-ответ на любой серверный вызов без знания самого пароля. Протокол не предъявляет никаких требований к тому, как именно был получен хеш: вычислен ли он из набранного символами пароля или извлечён из памяти чужой системы, - он одинаково пригоден.
Поэтому взаимодействие между хешом и паролем в контексте NTLM асимметрично: переход от пароля к хешу тривиален, а обратный переход невозможен математически, однако тот, кто владеет хешем, функционально владеет и учётной записью в любом месте, где допускается NTLM-аутентификация. Защитник должен мыслить категорией «хеш равен паролю» и строить на этом допущении всю модель угроз: кража хеша из какого-нибудь источника является полноценной компрометацией учётной записи, даже если ни один пользователь не сообщал свой пароль третьим лицам и сложность пароля соответствует политикам.
Почему NTLM-хеш не содержит соли и чем это отличается от Kerberos
Соль - случайное значение, добавляемое к паролю перед хешированием, - заставляет два одинаковых пароля разных учётных записей давать разные хеши и ломает любые предвычисленные таблицы. В схеме Windows-NTLM отсутствует соль: хеш формируется применением устаревшего алгоритма непосредственно к паролю, и результат фиксирован для конкретной пары «пароль + ничего более». Из этого следуют три практических последствия защитного значения.
Первое - полное отсутствие привязки хеша к учётной записи или к конкретному домену: один и тот же пароль на разных машинах и у разных пользователей даёт идентичный хеш, поэтому масштабная утечка одного значения может открывать доступ сразу к нескольким независимым системам. Второе - принципиальная уязвимость к предвычислению: существование гигантских таблиц соответствия «хеш - пароль» делает возможным мгновенное восстановление простых паролей из перехваченного хеша. Третье - подходящесть хеша как ключа протокола: не будучи уникальным для сессии или для сервера, он остаётся валидным до смены пароля, в строгом отличие от короткоживущих сессионных токенов.
Kerberos организован иначе и иллюстрирует архитектурную альтернативу. Аутентификация в Kerberos опирается не на доказательство владения хешем пароля как ключом защиты, а на обмен билетами, которые выдаются центром распределения ключей и однозначно привязаны к конкретному сервису, клиенту и интервалу времени. Клиент предъявляет службе не хеш и не его производную, а специализированный билет, подписанный самим доменом; его подделка требует компрометации центра, а не конечной машины. Билет имеет срок жизни и область действия, а ключ сессии формируется отдельно для каждого диалога. Поэтому движение хеша с одной машины на другую в Kerberos не означает автоматической компрометации: один пароль - много билетов с разной логикой. Защитному проектированию из этого следует простой вывод: сдерживание распространения NTLM и принудительный переход на Kerberos резко уменьшает поверхность типа Pass-the-Hash, поскольку изымает из рассмотрения само доказательство «знание хеша».
Откуда утекают хеши и почему их чтение требует привилегий администратора
Хеши NTLM на современной системе Windows присутствуют в нескольких логически отличающихся хранилищах, и разработчик защиты должен знать каждое из них.
Память процесса LSASS - основной источник. Принимая регистрации пользователей, система формирует в адресном пространстве этого доверенного процесса производные от пароля, необходимые для единого входа на сетевые ресурсы; многие из этих материалов являются по сути NTLM-хешами текущих сессий. Поскольку процесс защищён, доступ к его памяти возможен только с правами локального администратора или системной учётной записи, а это означает: кража хешей из памяти сама по себе доказывает уже достигнутую компрометацию узла. Отсюда правило: механизм Pass-the-Hash не инициирует вторжение, он развивает его, превращая локальный взлом в горизонтальный захват инфраструктуры.
База SAM в реестре содержит хеши локальных учётных записей. В штатном состоянии она сжата и защищена, но её извлечение возможно теми же привилегированными кодами через запрос к реестру или через копию резервной оболочки. Третий источник - кэшированные учётные данные доменных пользователей, позволяющие входить без контроллера домена: само кэширование выполнено многократным хешированием с солью и не даёт готового ключа, но размещает в защищённой ветке реестра материал, пригодный для медленного офлайн-восстановления пароля.
Общая логика защитника такова: все перечисленные хранилища требуют повышенных прав, поэтому укрепление границы «не будь локальным администратором там, где ты работаешь» есть главный барьер. Хранилища недвижимы до тех пор, пока никто не обрёл привилегии; а раз права получены, защита должна срабатывать за их счёт: виртуализация безопасности, минимизация регистраций, регистрация утечек по журналам.
Контур атаки и соответствующие меры изоляции, Credential Guard, WDigest, ограниченное администрирование
Классическая логическая схема Pass-the-Hash предельно проста: сначала злоумышленник получает административный контроль над узлом через любой независимый путь, затем извлекает из памяти или реестра хеш значимого сетевого аккаунта, после чего аутентифицируется с этим хешем на следующей машине и повторяет цикл. Замена пароля на хеш в качестве учётного материала не изменила топологию, она изменила стоимость: не требуется угадывать что-либо и не нужно знать словарь.
Первая инженерная мера - Credential Guard, построенный на виртуализационной изоляции. Используя гипервизор и среду Virtualization-Based Security, Windows выводит хранение производных учётных данных из общей памяти в крошечную изолированную среду, куда нет адресного доступа даже у кода, исполняемого от имени системы в обычном ядре. Дамп памяти LSASS перестаёт приносить работающие ключи, а вычисления единолично делегируются защищённому процессу. В сочетании с контролем целостности кода гипервизора и режимом Credential Guard этот слой превращает кражу хешей в малопродуктивное действие.
Вторая мера - отключение протокола WDigest, который исторически хранил в памяти пароли в обратимо зашифрованном виде ради совместимости; его дезактивация устраняет целый класс утилит восстановления. Третья - модель ограниченного администрирования: локальные административные пароли на каждом компьютере уникальны и автоматически ротируются решением класса LAPS, рабочие места администраторов строго отделены от рядовых, вход с доменными административными аккаунтами на рядовые машины запрещён, а доступ к серверам оформляется через выделенные чистые станции. Указание системным службам работать под управляемыми сервисными учётными записями gMSA, чьи пароли автоматически ротируются и неизвестны людям, исключает хранение осмысленных хешей служб в памяти узлов.
Каждая мера точно соответствует этапу контура: Credential Guard разрушает получение сырья, WDigest закрывает читаемое хранилище, LAPS аннулирует ценность расхищенного локального хеша для соседних машин, чистые станции блокируют попадание доменных хешей в память компрометируемых узлов, gMSA отучает организацию от хешей, которыми можно пользоваться.
Детектирование, события входа третьего типа с NTLM, журналы 4624 и 4672, сетевые сенсоры
Если слои профилактики не остановили атаку, её следует наблюдать, и журналы безопасности дают для этого достаточную опорную информацию. Центральный признак Pass-the-Hash - сетевой вход типа 3 с успешной аутентификацией по NTLM от учётной записи, которая в реальности не должна применять NTLM на этой системе, либо от имени доменного администратора с машины, не входящей в административный контур. Событие 4624 фиксирует факт входа и его тип, парное событие сетевого входа позволяет сопоставить источник, а событие 4672 выделяет присвоение специальных привилегий: комбинация сетевого входа с немедленными особыми правами - классический след горизонтального перемещения.
Полезным триггером служит аномалия протокола: в среде, где Kerberos стандартизован, внезапная NTLM-аутентификация с учёткой повышенных прав - событие само по себе, независимо от его результата. Дополнительную картину дают сетевые архитектурные сенсоры, анализирующие трафик между рабочими станциями: в норме рабочая станция почти никогда не обращается к службе удалённого управления других станций; всплеск соединений «станция - станция» с использованием административных протоколов есть маркер именно латерального движения. Системы класса deception - поддельные учётные записи и приманки - дают практически безложноположительные сигналы: любое использование их хеша по определению свидетельствует о компрометации.
Почему смена пароля важнее аудита доступа и как выстроить стратегию презумпции компрометации
После доказанной или разумно предполагаемой утечки хеша главным действием является не разбор прав доступа, а немедленная смена пароля соответствующей учётной записи, причём дважды для доменных административных аккаунтов с учётом механизма истории ключей Kerberos. Причина лежит в протоколе: аудит и последующее ужесточение прав уменьшают ущерб от уже выполненных действий, но не лишают злоумышленника действующего ключа - скомпрометированный хеш остаётся валидным и после полной корректировки ACL. Ограничение входов, время блокировки и даже отзыв билетов действуют лишь ретроспективно; только обновление секрета аннулирует ключ криптографически и сразу. Из этого строится и порядок реагирования: изоляция узла, принудительный двойной сброс паролей, циклический запрет повторного применения старых значений и только затем - расширенный анализ дозволенного и предотвращённого.
Сама организация защиты должна быть выстроена по стратегии «предполагай компрометацию»: исходным состоянием считается не образцовый периметр, а наличие хотя бы одного контролируемого узла с уже выгруженными хешами. С этого допущения последовательно выводятся все инженерные решения: уникальность локальных секретов через LAPS лишает смысла перенос хеша локального администратора, Credential Guard урезает урожай из памяти, запрет смешивания контуров администрирования исключает попадание доменных ключей в рядовые машины, переход на Kerberos устраняет протокольную возможность использования хеша вместо пароля, журналы 4624 и 4672 с добавлением сетевых сенсоров обещают своевременное обнаружение. Такая модель не делает ставку на недостижимую абсолютную профилактику; она гарантирует, что украденный один раз хеш перестаёт быть универсальным пропуском, превращаясь в локальный и быстро истекающий факт, обрабатываемый плановой процедурой смены учётных данных.
Вывод очевиден: Pass-the-Hash - не проблема паролей, а проблема равнозначности хеша паролю в составе устаревшего протокола. Нейтрализовать его означает не столько «улучшить сложность паролей», сколько исключить хранение пригодных хешей на узлах, обрезать протокол, принимающий хеш, и обеспечить мгновенную аннуляцию утёкшего секрета. Инженер, понявший такую эквивалентность, проектирует довольно устойчивую среду, в которой дважды подуманное допущение о широко распространённой компрометации не означает катастрофы.