Введение
Часто при настройке Active Directory системные администраторы не осознают вреда, который приносит разрешение учетной записи локального администратора в системе, назначенной конкретному пользователю. Компании часто классифицируют это как "необходимое зло" с точки зрения того, что облегчение закрытия различных действий, таких как установка нового инструмента в таком крупном предприятии, увеличивает нагрузку на ИТ-команду, поэтому они разрешают пользователям доступ к учетной записи локального администратора. В этой статье мы покажем, как злоумышленник, скомпрометировавший систему с активной учетной записью локального администратора и учетной записью компьютера/машины, добавленной в группу администраторов домена, может использовать это для дампа хэшей в домене, что позволит ему привилегии для контроллера домена и, кроме того, как злоумышленник может использовать учетные записи компьютеров для обеспечения устойчивости.
Методология атаки
Методику можно описать следующими этапами:
- Первоначальная компрометация пользователя с локальной учетной записью администратора
- Использование mimikatz с этим пользователем для дампа NTLM-хэша учетной записи "Harshit", которая находится в группе администраторов домена.
- Проведение атаки PTH для просмотра файлов на контроллере домена
- Добавление новой учетной записи компьютера с правами администратора
- Изменение параметра userAccountControl, чтобы сделать эту новую учетную запись компьютера контроллером домена Active Directory.
- Получение персистентности
У скомпрометированной жертвы есть связанная учетная запись компьютера "Harshit" (также известная как учетная запись компьютера), которая добавлена в группу администраторов домена. У жертвы также есть активная учетная запись локального администратора, которой мы располагаем.
Учетные записи компьютеров и учетные записи пользователей
Подробное руководство по учетным записям пользователей и компьютеров см. в документах Microsoft здесь (https://docs.microsoft.com/en-us/wi...ts#default-local-accounts-in-active-directory ) и здесь (https://docs.microsoft.com/en-us/pr...er-2003/cc759279(v=ws.10)?redirectedfrom=MSDN) .
Учетные записи компьютеров, также известные как учетные записи компьютеров, аналогичны учетным записям пользователей с точки зрения AD. Основное отличие заключается в следующем:
- Пароль учетной записи компьютера генерируется случайным образом и сбрасывается через 30 дней.
- Когда создается учетная запись пользователя, также создается соответствующая учетная запись компьютера.
- Пользователь, если ему предоставлены права, может создавать несколько учетных записей компьютеров. Значение по умолчанию — 10.
Учетные записи компьютеров в основном используются системными администраторами для эффективной классификации лесов и управления ими. Чаще всего используется категоризация групп безопасности с помощью учетных записей компьютеров. Однако это выходит за рамки данной статьи.
Учетные записи машины/компьютера можно определить по символу "$" в конце.
Эскалация домена с помощью Mimikatz
Теперь злоумышленнику удалось скомпрометировать учетную запись с правами локального администратора. После расследования мы обнаружили, что была создана учетная запись компьютера или учетная запись компьютера, которая является частью группы администраторов домена.
net localgroup administrators /domain может перечислить всех администраторов домена, присутствующих в AD. Точно так же в powershell команда net localgroupadmins/domain вызывает администраторов домена. Здесь было обнаружено, что учетная запись "Harshit" принадлежит администраторам домена. Мы можем проверить это, используя net user
net user Harshit
Как видите, в админке домена добавлена учетная запись компьютера "Harshit".
Злоумышленник может использовать доступ локального администратора для запуска mimikatz и создания дампа NTLM-хэша учетной записи компьютера "Harshit".
privilege::debug
sekurlsa::logonPasswords
Как видите, мы получили хэш NTLM для учетной записи компьютера Harshit.
Злоумышленник может использовать этот хэш NTLM для проведения атаки PassTheHash для повышения привилегий до администратора домена.
sekurlsa::pth /user:harshit /domain:ignite.local /ntlm:64fbae31cc352fc26af97cbdef151e03
Это новое окно командной строки, которое открывается, теперь можно использовать для доступа к файловой системе контроллера домена следующим образом.
dir \\dc1.ignite.local\c$\Users\Administrator
Сейчас есть несколько способов полностью скомпрометировать DC. Злоумышленник может загрузить сюда exe и получить обратную оболочку или просто выгрузить файл SAM. Мы не будем сейчас это освещать. Давайте теперь сосредоточимся на том, как мы можем поддерживать персистенс в этом домене, используя учетную запись компьютера.
Персистенс в домене с помощью powermad
Цель состоит в том, чтобы использовать эту недавно полученную командную строку администратора, чтобы добавить новую учетную запись компьютера и сделать ее контроллером домена, чтобы мы могли поддерживать персистенс в домене сейчас.
Немного погуглив, я нашел отличный скрипт powershell, который позволил бы нам добавить учетную запись компьютера/машины под названием powermad( https://github.com/Kevin-Robertson/Powermad). Вы можете использовать powershell и IWR, чтобы ввести это в систему и использовать с помощью открытой командной строки администратора.
Пользователь может создавать учетные записи компьютеров. Значение по умолчанию — 10. Системный администратор может изменить это, чтобы запретить пользователю создавать учетные записи компьютеров.
Win+r -> adsiedit.msc
Открываем редактор интерфейса службы AD. Вы можете выбрать лес и перейти к его свойствам.
Вы можете просмотреть редактор атрибутов (который представляет собой набор объектов, редактируемых через powershell и вручную через графический интерфейс) и увидеть атрибут "ms-DS-MachineAccountQuota". Как видите, значение равно 10, поэтому мой пользователь может без проблем создать 10 учетных записей компьютеров.
Это также можно проверить с помощью powermad. Теперь мы импортируем модуль powermad psm1 и создаем новую учетную запись компьютера с именем "noob".
powershell -ep bypass
Import-Module .\Powermad.psm1
New-MachineAccount -MachineAccount noob -Domain ignite.local -DomainController dc1.ignite.local
Так просто! Добавлена новая учетная запись компьютера
Это можно проверить в AD, выполнив команду get-ADComputer и * в качестве фильтра.
Как видите, noob был добавлен (обратите внимание, что SamAccountName noob$ указывает, что это учетная запись компьютера/машины)
Под AD теперь мы видим, что в группу "Компьютеры домена" добавлен noob.
Атрибут userAccountControl
Точно так же, как у нас есть атрибут MachineAccountQuota, у нас есть еще один атрибут, называемый userAccountControl, который можно просмотреть в диспетчере сервера AD-> инструменты-> пользователи и группы AD-> компьютеры-> noob.
Сначала вам нужно выбрать вид-> дополнительные функции
И тогда вы сможете увидеть редактор атрибутов. Под этим большим списком мы видим, что для параметра userAccountControl установлено значение 4096.
Это значение 4096 является эквивалентом ASCII шестнадцатеричного значения 0x1000, которое классифицирует эту учетную запись машины/компьютера как доверительную учетную запись рабочей станции.
Чтобы сделать эту недавно добавленную учетную запись компьютера/машины noob в качестве администратора домена, нам нужно изменить этот атрибут на 8096 (0x2000 в шестнадцатеричном формате).
Это можно сделать с помощью расширенной подсказки Powershell.
Чтобы просмотреть этот атрибут с помощью powershell, мы можем сделать это:
Get-ADComputer noob -pro name,primarygroupid, useraccountcontrol
Это говорит нам о том, что в настоящее время установлено значение 4096.
Мы можем изменить это значение с помощью команды Set-ADComputer:
Set-ADComputer noob -replace @{“useraccountcontrol” = 8192}
Get-ADComputer noob -pro name, primarygroupid, useraccountcontrol
Теперь вы можете видеть, что эта учетная запись компьютера была добавлена в группу контроллера домена, а значение изменилось на 8192.
Это можно наблюдать и через AD. Обратите внимание, что 0x2000 (шестнадцатеричное число 8192) превратилось из WORKSTATION_TRUST_ACCOUNT в SERVER_TRUST_ACCOUNT.
Мы можем подтвердить, что нуб теперь стал контроллером домена, перейдя на вкладку членства
Кроме того, злоумышленник может выполнить ряд атак теперь, когда эта учетная запись стала контроллером домена и получен персистенс. Злоумышленник может сдампить хэш этой новой учетной записи (атака DCSync) и провести атаки PTH или сгенерировать золотой билет прямо сейчас.
Вывод
Учетные записи машин/компьютеров существуют уже несколько десятков лет, возможно, и все же о последствиях для безопасности широко не сообщается. В этой статье мы попытались распространить информацию об одном таком методе, с помощью которого злоумышленник может выполнить эскалацию домена, а затем сохранить его, используя учетные записи компьютеров. Системные администраторы не должны разрешать пользователям создавать учетные записи компьютеров, чтобы избежать таких угроз. Спасибо за чтение. Надеюсь, вам понравилась статья.
Часто при настройке Active Directory системные администраторы не осознают вреда, который приносит разрешение учетной записи локального администратора в системе, назначенной конкретному пользователю. Компании часто классифицируют это как "необходимое зло" с точки зрения того, что облегчение закрытия различных действий, таких как установка нового инструмента в таком крупном предприятии, увеличивает нагрузку на ИТ-команду, поэтому они разрешают пользователям доступ к учетной записи локального администратора. В этой статье мы покажем, как злоумышленник, скомпрометировавший систему с активной учетной записью локального администратора и учетной записью компьютера/машины, добавленной в группу администраторов домена, может использовать это для дампа хэшей в домене, что позволит ему привилегии для контроллера домена и, кроме того, как злоумышленник может использовать учетные записи компьютеров для обеспечения устойчивости.
Методология атаки
Методику можно описать следующими этапами:
- Первоначальная компрометация пользователя с локальной учетной записью администратора
- Использование mimikatz с этим пользователем для дампа NTLM-хэша учетной записи "Harshit", которая находится в группе администраторов домена.
- Проведение атаки PTH для просмотра файлов на контроллере домена
- Добавление новой учетной записи компьютера с правами администратора
- Изменение параметра userAccountControl, чтобы сделать эту новую учетную запись компьютера контроллером домена Active Directory.
- Получение персистентности
У скомпрометированной жертвы есть связанная учетная запись компьютера "Harshit" (также известная как учетная запись компьютера), которая добавлена в группу администраторов домена. У жертвы также есть активная учетная запись локального администратора, которой мы располагаем.
Учетные записи компьютеров и учетные записи пользователей
Подробное руководство по учетным записям пользователей и компьютеров см. в документах Microsoft здесь (https://docs.microsoft.com/en-us/wi...ts#default-local-accounts-in-active-directory ) и здесь (https://docs.microsoft.com/en-us/pr...er-2003/cc759279(v=ws.10)?redirectedfrom=MSDN) .
Учетные записи компьютеров, также известные как учетные записи компьютеров, аналогичны учетным записям пользователей с точки зрения AD. Основное отличие заключается в следующем:
- Пароль учетной записи компьютера генерируется случайным образом и сбрасывается через 30 дней.
- Когда создается учетная запись пользователя, также создается соответствующая учетная запись компьютера.
- Пользователь, если ему предоставлены права, может создавать несколько учетных записей компьютеров. Значение по умолчанию — 10.
Учетные записи компьютеров в основном используются системными администраторами для эффективной классификации лесов и управления ими. Чаще всего используется категоризация групп безопасности с помощью учетных записей компьютеров. Однако это выходит за рамки данной статьи.
Учетные записи машины/компьютера можно определить по символу "$" в конце.
Эскалация домена с помощью Mimikatz
Теперь злоумышленнику удалось скомпрометировать учетную запись с правами локального администратора. После расследования мы обнаружили, что была создана учетная запись компьютера или учетная запись компьютера, которая является частью группы администраторов домена.
net localgroup administrators /domain может перечислить всех администраторов домена, присутствующих в AD. Точно так же в powershell команда net localgroupadmins/domain вызывает администраторов домена. Здесь было обнаружено, что учетная запись "Harshit" принадлежит администраторам домена. Мы можем проверить это, используя net user
net user Harshit
Как видите, в админке домена добавлена учетная запись компьютера "Harshit".
Злоумышленник может использовать доступ локального администратора для запуска mimikatz и создания дампа NTLM-хэша учетной записи компьютера "Harshit".
privilege::debug
sekurlsa::logonPasswords
Как видите, мы получили хэш NTLM для учетной записи компьютера Harshit.
Злоумышленник может использовать этот хэш NTLM для проведения атаки PassTheHash для повышения привилегий до администратора домена.
sekurlsa::pth /user:harshit /domain:ignite.local /ntlm:64fbae31cc352fc26af97cbdef151e03
Это новое окно командной строки, которое открывается, теперь можно использовать для доступа к файловой системе контроллера домена следующим образом.
dir \\dc1.ignite.local\c$\Users\Administrator
Сейчас есть несколько способов полностью скомпрометировать DC. Злоумышленник может загрузить сюда exe и получить обратную оболочку или просто выгрузить файл SAM. Мы не будем сейчас это освещать. Давайте теперь сосредоточимся на том, как мы можем поддерживать персистенс в этом домене, используя учетную запись компьютера.
Персистенс в домене с помощью powermad
Цель состоит в том, чтобы использовать эту недавно полученную командную строку администратора, чтобы добавить новую учетную запись компьютера и сделать ее контроллером домена, чтобы мы могли поддерживать персистенс в домене сейчас.
Немного погуглив, я нашел отличный скрипт powershell, который позволил бы нам добавить учетную запись компьютера/машины под названием powermad( https://github.com/Kevin-Robertson/Powermad). Вы можете использовать powershell и IWR, чтобы ввести это в систему и использовать с помощью открытой командной строки администратора.
Пользователь может создавать учетные записи компьютеров. Значение по умолчанию — 10. Системный администратор может изменить это, чтобы запретить пользователю создавать учетные записи компьютеров.
Win+r -> adsiedit.msc
Открываем редактор интерфейса службы AD. Вы можете выбрать лес и перейти к его свойствам.
Вы можете просмотреть редактор атрибутов (который представляет собой набор объектов, редактируемых через powershell и вручную через графический интерфейс) и увидеть атрибут "ms-DS-MachineAccountQuota". Как видите, значение равно 10, поэтому мой пользователь может без проблем создать 10 учетных записей компьютеров.
Это также можно проверить с помощью powermad. Теперь мы импортируем модуль powermad psm1 и создаем новую учетную запись компьютера с именем "noob".
powershell -ep bypass
Import-Module .\Powermad.psm1
New-MachineAccount -MachineAccount noob -Domain ignite.local -DomainController dc1.ignite.local
Так просто! Добавлена новая учетная запись компьютера
Это можно проверить в AD, выполнив команду get-ADComputer и * в качестве фильтра.
Как видите, noob был добавлен (обратите внимание, что SamAccountName noob$ указывает, что это учетная запись компьютера/машины)
Под AD теперь мы видим, что в группу "Компьютеры домена" добавлен noob.
Атрибут userAccountControl
Точно так же, как у нас есть атрибут MachineAccountQuota, у нас есть еще один атрибут, называемый userAccountControl, который можно просмотреть в диспетчере сервера AD-> инструменты-> пользователи и группы AD-> компьютеры-> noob.
Сначала вам нужно выбрать вид-> дополнительные функции
И тогда вы сможете увидеть редактор атрибутов. Под этим большим списком мы видим, что для параметра userAccountControl установлено значение 4096.
Это значение 4096 является эквивалентом ASCII шестнадцатеричного значения 0x1000, которое классифицирует эту учетную запись машины/компьютера как доверительную учетную запись рабочей станции.
Чтобы сделать эту недавно добавленную учетную запись компьютера/машины noob в качестве администратора домена, нам нужно изменить этот атрибут на 8096 (0x2000 в шестнадцатеричном формате).
Это можно сделать с помощью расширенной подсказки Powershell.
Чтобы просмотреть этот атрибут с помощью powershell, мы можем сделать это:
Get-ADComputer noob -pro name,primarygroupid, useraccountcontrol
Это говорит нам о том, что в настоящее время установлено значение 4096.
Мы можем изменить это значение с помощью команды Set-ADComputer:
Set-ADComputer noob -replace @{“useraccountcontrol” = 8192}
Get-ADComputer noob -pro name, primarygroupid, useraccountcontrol
Теперь вы можете видеть, что эта учетная запись компьютера была добавлена в группу контроллера домена, а значение изменилось на 8192.
Это можно наблюдать и через AD. Обратите внимание, что 0x2000 (шестнадцатеричное число 8192) превратилось из WORKSTATION_TRUST_ACCOUNT в SERVER_TRUST_ACCOUNT.
Мы можем подтвердить, что нуб теперь стал контроллером домена, перейдя на вкладку членства
Кроме того, злоумышленник может выполнить ряд атак теперь, когда эта учетная запись стала контроллером домена и получен персистенс. Злоумышленник может сдампить хэш этой новой учетной записи (атака DCSync) и провести атаки PTH или сгенерировать золотой билет прямо сейчас.
Вывод
Учетные записи машин/компьютеров существуют уже несколько десятков лет, возможно, и все же о последствиях для безопасности широко не сообщается. В этой статье мы попытались распространить информацию об одном таком методе, с помощью которого злоумышленник может выполнить эскалацию домена, а затем сохранить его, используя учетные записи компьютеров. Системные администраторы не должны разрешать пользователям создавать учетные записи компьютеров, чтобы избежать таких угроз. Спасибо за чтение. Надеюсь, вам понравилась статья.
