Система Windows может работать как автономно, так и в составе домена в роли сервера или рабочей станции.
Кэшированный вход в домен
Система Windows может работать как автономно, так и в составе домена в роли сервера или рабочей станции. Когда пользователь заходит на рабочую станцию, являющуюся частью домена, он может войти либо под локальным пользователем, либо под пользователем домена.При входе в домен пользователю необходимо знать следующую информацию: имя пользователя, пароль и доменное имя. Доменное имя, как правило, можно выбрать из выпадающего списка, который содержит название всех доменов, в которые входит система.
После ввода пользователем всей необходимой информации, система хеширует предоставленный пароль и по сети сверяет полученный хеш с хешем, хранящимся на контроллере домена в файле ntds.dit. Процедурой аутентификации руководит процесс lsass.exe.
В первую очередь LSASS проверяет, доступен ли контроллер домена. Если контроллер доступен, то процесс сверяет хеши паролей и, в зависимости от результата, разрешает или запрещает пользователю вход в систему.
Если же ни один контроллер домена недоступен, то легитимному пользователю домена не удастся войти в систему. Чтобы избежать подобных ситуаций, Microsoft задействовала в Windows механизм кэшированного входа в домен.
Microsoft дает такой комментарий о механизме:
В локальный кэш заносятся сведения обо всех предыдущих входах пользователей в систему, что позволяет им при последующих попытках войти в систему в случае отсутствия доступа к контроллеру домена […]
Следовательно, даже если контроллер домена недоступен, доменный пользователь все равно сможет зайти в систему. Требуется только, чтобы выполнилось два уcловия: пользователь удачно входил в систему ранее, и на системе включена политика кэширования входа в домен. На следующем скриншоте показано, где именно конфигурируется политика кэширования:
Локальные параметры безопасности (secpol.msc) / Локальные политики / Параметры безопасности / Интерактивный вход в систему: количество предыдущих подключений к кэшу (в случае отсутствия доступа к контроллеру домена)
(Local Security Policy (secpol.msc) / Local Policies / Security Options / Interactive logon: Number of previous logons to cashe (in case domain controller is unavailable))
Значение параметра политики вы также можете прочесть из ключа реестра HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\CashedLogonCount. По умолчанию на системах Windows XP и выше в кэш заносятся сведения о 10 предыдущих входах. Информация о кэшированных входах хранится в кустах реестра HKEY_LOCAL_MACHINE/Security/CACHE/NL$X, где X – число. Получить доступ к кустам можно либо под пользователем Local System, либо с помощью специальных утилит.
Получение информации о кэшированном входе в домен
Хешированные пароли предыдущих входов в систему можно получить либо из файлов реестра, либо из памяти процесса lsass.exe.Чтобы получить хеши в оффлайн-режиме скопируйте системные файлы SYSTEM и SECURITY из реестра с помощью reg.exe/regedit.exe или посредством службы теневого копирования томов, как описывалось в первой статье. Извлечь информацию о кэшированных входах в домен из полученных файлов SYSTEM и SECURITY можно утилитами Cain & Abel, creddump от Брендана Долана-Гавита (Brendan Dolan-Gavitt) или Windows Password Recovery от passcape.
Также существует множество утилит, которые сольют информацию о кэшированном входе в домен, внедрившись в процесс lsass.exe. На 32-битных архитектурах вы можете воспользоваться fgdump, PWDumpX или cachedump от Арно Пилона (Arnaud Pilon). Последняя утилита стабильно работает и на последних версиях Windows. К сожалению, ни одна из бесплатных утилит не будет работать на 64-разрядных системах. Поэтому в подобных случаях, если на целевой 64-разрядной системе вам удастся запустить Meterpreter, то воспользуйтесь лучше модулем пост-эксплойта из Metasploit Framework.
Ниже показан результат работы cachedump на входящей в домен системе Windows:
C:\>cachedump.exe –v
Service not found. Installing CacheDump Service (C:\cachedump.exe -s)
CacheDump service successfully installed.
Service started.
user:2d9f0b052932ad18b87f315641921cda:lab:lab.internal
Service currently active. Stopping service…
Service successfully removed.
Какие угрозы влечет за собой получение информации из кэшированных входов в домен
Рассмотрим ситуацию, подобную ситуации с получением секретов LSA: допустим, вы скомпрометировали входящую в домен систему и получили доступ к командной строке с правами Local System. Никакой информации об учетных данных доменных пользователей в секретах LSA нет. Что же тогда делать дальше? Проверьте, кэширует ли система информацию о предыдущих входах пользователя в домен, и если да, то слейте кэш.В отличие от NT- и LM-хешей паролей, информацию из кэша нельзя напрямую использовать для аутентификации на других машинах. Хеши паролей можно взломать и получить пароль в незашифрованном виде, чтобы в дальнейшем аутентифицироваться на нужной машине. Более подробно о взломе хешей я расскажу в другой статье.
Сам по себе механизм кэшированного входа в домен достаточно полезен, поскольку он облегчает работу администраторов сети, когда контроллер домена по какой-либо причине недоступен. Но с точки зрения безопасности, такой механизм, безусловно, несет в себе угрозу безопасности.
Описанные в этой статье утилиты я добавил в таблицу. Буду рад вашим отзывам и предложениям!