Breaching Active Directory, part 2

Всем привет!

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

В ней будут рассмотрены такие темы, как злоупотребление возможностями Microsoft Deployment Toolkit и поиск учетных данных в конфигурационных файлах, а также подведен итог.

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

Breaching Active Directory, part 1

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

Продолжим!

Microsoft Deployment Toolkit

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

MDT и SCCM

Microsoft Deployment Toolkit (MDT) — это служба Microsoft, помогающая автоматизировать развертывание операционных систем (ОС) Microsoft. Крупные организации используют эту службу для более эффективного развертывания новых машин в своей среде, поскольку такие хосты можно обслуживать и обновлять централизованно.

Обычно MDT интегрируется с Microsoft System Center Configuration Manager (SCCM), который управляет всеми обновлениями для всех приложений, служб и операционных систем Microsoft. MDT используется для развертывания новых машин. По сути, это позволяет IT-команде предварительно настраивать загрузочные образы и управлять ими. Следовательно, если им нужно настроить новую машину, необходимо просто подключить сетевой кабель к хосту, и все произойдет автоматически. Сотрудники могут вносить различные изменения в загрузочный образ, например предустанавливать программное обеспечение по умолчанию (MS Office, антивирус и т.п.). Использование технологии также может гарантировать, что новая сборка будет обновлена при первом запуске после установки.

SCCM можно рассматривать как "расширение" или "старшего брата" MDT. Что происходит с программным обеспечением после его установки? SCCM помогает осуществлять патч-менеджментом. Это позволяет IT-отделу просматривать доступные обновления для всего программного обеспечения, установленного в организации. Сотрудники также могут протестировать эти исправления в изолированной среде, чтобы убедиться, что они стабильны, прежде чем централизованно развертывать их на всех компьютерах, присоединенных к домену. Это значительно облегчает администрирование инфраструктуры.

Однако все, что обеспечивает централизованное управление инфраструктурой (то есть MDT и SCCM), может стать мишенью для злоумышленников, пытающихся захватить большую часть критически важных функций в системе.

Хотя MDT можно настроить различными способами, в рамках ознакомления мы сосредоточимся исключительно на конфигурации, называемой Preboot Execution Environment (PXE) boot.

PXE Boot

Крупные организации используют PXE Boot, чтобы позволить новым устройствам, подключенным к сети, загружать и устанавливать ОС непосредственно через сетевое соединение. MDT можно использовать для создания, управления и размещения загрузочных образов PXE. Загрузка PXE обычно интегрирована с DHCP, что означает, что если DHCP назначает аренду IP, хосту разрешено запрашивать загрузочный образ PXE и запускать процесс установки сетевой ОС. Поток связи показан на диаграмме ниже:

После выполнения процесса клиент будет использовать TFTP-соединение для загрузки загрузочного образа PXE. Злоумышленник может использовать загрузочный образ PXE для двух разных целей:

Заинжектить вектор повышения привилегий (например, создать учетную запись локального администратора), чтобы получить административный доступ к ОС после завершения загрузки PXE;
Выполнить password scraping attacks, чтобы восстановить учетные данные AD, использованные во время установки.

В данной статье мы сосредоточимся на втором варианте. Мы попытаемся получить учетную запись службы развертывания, связанную со службой MDT, во время установки для password scraping attack. Кроме того, существует также возможность получения других учетных записей AD, используемых для автоматической установки приложений и служб.

Получение загрузочного образа PXE

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

Первая часть информации о предварительной настройке загрузки PXE, которую вы получили бы через DHCP, — это IP-адрес сервера MDT. В нашем случае — это 10.200.80.202.

Вторая часть — это имена файлов BCD. В этих файлах хранится информация, относящаяся к загрузке PXE для различных типов архитектуры. В нашем случае их увидеть несложно, нужно просто подключиться к этому pxeboot.za.tryhackme.com:

Обычно злоумышленнику необходимо использовать TFTP для запроса каждого из этих .bcd файлов, а также перечислить конфигурацию для каждого из них. Однако в интересах экономии времени сосредоточимся на файле BCD для архитектуры x64. Скопируем и сохраним полное имя этого файла.

Теперь мы можем получить загрузочный образ PXE.

Примечание. Я буду использовать SSH-соединение на THMJMP1 для следующих нескольких шагов.

Первый шаг, который нам нужно выполнить, — это использовать TFTP и загрузить файл BCD, чтобы прочитать конфигурацию сервера MDT. TFTP немного сложнее, чем FTP, поскольку мы не cможем перечислить файлы. Вместо этого мы отправляем запрос на файл, а сервер подключается к нам по UDP для его передачи. Следовательно, следует быть точными при указании файлов и путей к файлам. Файлы BCD всегда находятся в каталоге /Tmp/ на сервере MDT. Мы можем инициировать передачу TFTP, используя следующую команду в нашем сеансе SSH:

tftp -i 10.200.80.202 GET "\Tmp\x64{459A15C6-9751-4E9A-8F31-92F9DED4A4B5}.bcd" conf.bcd

Теперь, когда файл BCD получен, используем powerpxe для чтения его содержимого. Powerpxe — это сценарий PowerShell, который автоматически выполняет этот тип атаки. Но можно осуществить всё вручную. Я буду использовать функцию Powerpxe Get-WimFile для восстановления расположения образов загрузки PXE из файла BCD:

На выходе получаем файл \Boot\x64\Images\LiteTouchPE_x64.wim.

Файлы WIM представляют собой загрузочные образы в формате Windows Imaging Format (WIM). Теперь, когда у нас есть расположение загрузочного образа PXE, мы снова можем использовать TFTP для загрузки этого образа:

tftp -i 10.200.80.202 GET "\Boot\x64\Images\LiteTouchPE_x64.wim." pxeboot.wim

Восстановление учетных данных из загрузочного образа PXE

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

Я же сосредоточусь на эксфильтрации учетных данных. Для этого снова использую powerpxe. Однако, существует и другой путь: извлечь образ и искать в нем файл bootstrap.ini, где часто хранятся искомые учетные данные.

svcMDT:PXEBootSecure1@

Powerpxe смог восстановить учетные данные AD. Теперь у нас есть еще один набор учетных данных AD, которые мы можем использовать!

Configuration Files

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

Файлы конфигурации веб-приложений;
Файлы конфигурации службы;
Ключи реестра;
Централизованно развернутые приложения.

Для автоматизации этого процесса можно использовать разные сценарии перечисления, например Seatbelt.

Учетные данные в файлах конфигурации

В этой задаче мы сосредоточимся на восстановлении учетных данных из централизованно развернутого приложения. Обычно таким приложениям требуется метод аутентификации в домене как на этапе установки, так и на этапе работы. Примером такого приложения является McAfee Enterprise Endpoint Security, которое организации могут использовать в качестве средства EDR на хостах. McAfee внедряет учетные данные, используемые во время установки для обратного подключения к оркестратору, в файл с именем ma.db. Этот файл базы данных можно прочитать при наличии локального доступом к хосту, чтобы восстановить связанную учетную запись службы AD .

Для демонстрации я также буду использовать SSH-доступ к THMJMP1.

Файл ma.db хранится в фиксированном месте (C:\ProgramData\McAfee\Agent\DB):

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

Файл представляет собой базу данных SQLite:

SQLite — это быстрая и легкая встраиваемая однофайловая СУБД на языке C, которая не имеет сервера и позволяет хранить всю базу локально на одном устройстве. Для работы SQLite не нужны сторонние библиотеки или службы.

Чтобы её открыть в удобночитаемом виде, можно воспользоваться утилитой sqlitebrowser:

sqlitebrowser ma.db

В баузере выберем вкладку Browse Data и изучим содержимое таблицы AGENT_REPOSITORIES:

Изучим схему таблицы:

Нас интересуют поля DOMAIN, AUTH_USER и AUTH_PASSWD.

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

Нас, естественно, интересует вторая запись:

TryHackMe EPO

za.tryhackme.com

svcAV

jWbTyS7BL1Hj7PkO5Di/QhhYmcGj5cOoZ2OkDTrFXsR/abAFPM9B3Q==

Однако поле AUTH_PASSWD зашифровано. К счастью, McAfee шифрует это поле с помощью известного ключа. Поэтому мы будем использовать следующий старый скрипт python2 для расшифровки пароля:

#!/usr/bin/env python
# Info: 
#  McAfee Sitelist.xml password decryption tool
#  Jerome Nokin (@funoverip) - Feb 2016
#  More info on https://funoverip.net/2016/02/mcafee-sitelist-xml-password-decryption/
#
# Quick howto: 
#  Search for the XML element <Password Encrypted="1">...</Password>,
#  and paste the content as argument.
#
###########################################################################

import sys
import base64
from Crypto.Cipher import DES3
from Crypto.Hash import SHA

# hardcoded XOR key
KEY = "12150F10111C1A060A1F1B1817160519".decode("hex")

def sitelist_xor(xs):
  return ''.join(chr(ord(c) ^ ord(KEY[i%16]))for i, c in enumerate(xs))

def des3_ecb_decrypt(data):
  # hardcoded 3DES key
  key = SHA.new(b'<!@#$%^>').digest() + "\x00\x00\x00\x00"
  # decrypt
  des3 = DES3.new(key, DES3.MODE_ECB, "")
  decrypted = des3.decrypt(data)
  # quick hack to ignore padding
  return decrypted[0:decrypted.find('\x00')] or "<empty>"


if __name__ == "__main__":

  if len(sys.argv) != 2:
    print("Usage:  %s <base64 passwd>" % sys.argv[0])
    print("Example: %s 'jWbTyS7BL1Hj7PkO5Di/QhhYmcGj5cOoZ2OkDTrFXsR/abAFPM9B3Q=='" % sys.argv[0])
    sys.exit(0)

  # read arg
  encrypted_password = base64.b64decode(sys.argv[1]) 
  # decrypt
  password = des3_ecb_decrypt(sitelist_xor(encrypted_password))
  # print out
  print("Crypted password  : %s" % sys.argv[1])
  print("Decrypted password : %s" % password)

  sys.exit(0)

Назовём скрипт mcafee_sitelist_pwd_decrypt.py и исполним его. Из кода выше очевидно, что на вход нуджно предоставить закодированный в base64 пароль. Запустим скрипт:

И получаем пароль от учетной записи:

svcAV:MyStrongPassword!

Примечание. Инструмент, который я здесь использовал, довольно старый. Он использует Python v2 и опирается на старую криптографическую библиотеку. Возможно, что возникнут сложности с его запуском на современных Linux-машинах.

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

Заключение

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

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

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

Осведомленность и обучение пользователей. Самым слабым звеном в цепочке кибербезопасности почти всегда являются пользователи. Обучение пользователей и информирование их о том, что они должны быть осторожны при раскрытии конфиденциальной информации и не доверять подозрительным электронным письмам, уменьшают поверхность атаки.
Ограничение доступа к службам и приложениям, взаимодействующим с AD, из внешней сети. Не все приложения должны быть доступны из Интернета, особенно те, которые поддерживают аутентификацию NTLM и LDAP. Вместо этого эти приложения следует размещать во внутренней сети, к которой можно получить доступ через VPN. VPN, в свою очередь, может поддерживать многофакторную аутентификацию для дополнительной безопасности.
Принудительное управление доступом к сети (NAC, Network Access Control). NAC может предотвратить подключение злоумышленниками недоверенных устройств к сети. Однако для этого потребуется немало усилий, поскольку легитимные устройства должны быть внесены в белый список.
Принудительное подписание SMB. Принудительное подписание SMB делает атаки SMB-Relay невозможными.
Соблюдение принципа наименьших привилегий. В большинстве случаев злоумышленник сможет получить набор учетных данных в AD. Следуя принципу наименьших привилегий, особенно для учетных данных, используемых для служб, можно значительно снизить риск, связанный с компрометацией этих учетных данных.