Техники атакующих
Техники атак на AD/Windows глазами защитника — Kerberoasting, AS-REP roasting, Pass-the-Hash/Ticket, Golden/Silver ticket, DCSync, злоупотребление делегированием, LLMNR poisoning, C2 и анализ путей атаки. Только обнаружение и защита.
12 вопросов
JuniorТеорияОчень частоГде Windows хранит учётные секреты, и что меняют Credential Guard и защита LSA?
Где Windows хранит учётные секреты, и что меняют Credential Guard и защита LSA?
Windows держит секреты аутентификации в памяти LSASS, а локальные хеши — в кусте SAM, поэтому атакующий с правами админа читает их, а не подбирает. Алертите на нетипичные обращения к LSASS; Credential Guard изолирует секреты, RunAsPPL закрывает доступ.
Типичные ошибки
- ✗Считать, что хранимые хеши бесполезны без подбора открытого пароля
- ✗Думать, что Credential Guard снимает необходимость ограничивать локальных админов
- ✗Упускать, что чтение LSASS требует прав, которыми атакующий уже должен обладать
Уточняющие вопросы
- →Почему Credential Guard не помогает против кейлоггера на том же хосте?
- →Что именно блокирует настройка защиты локального центра безопасности
LSARunAsPPL?
JuniorТеорияОчень частоКакие ошибки конфигурации в Linux ведут к root, и какой харденинг убирает каждую из них?
Какие ошибки конфигурации в Linux ведут к root, и какой харденинг убирает каждую из них?
Обычные пути — неверная конфигурация, а не эксплойты: SUID-бинарники, запускающие произвольные команды, слишком широкие правила sudoers вроде NOPASSWD, и cron-файлы, доступные на запись всем. Лечится аудитом SUID, сужением sudoers и починкой владельцев.
Типичные ошибки
- ✗Считать эскалацию до root проблемой эксплойтов ядра, а не конфигурации
- ✗Выдавать
NOPASSWDредактору или интерпретатору, который умеет породить оболочку - ✗Проверить список SUID один раз и не перепроверять после обновления пакетов
Уточняющие вопросы
- →Почему правило sudoers, разрешающее редактор, фактически равно полному root?
- →Какая телеметрия хоста покажет появление неожиданного процесса от root?
JuniorТеорияЧастоЧто делает трафик управления (C2) обнаружимым, и почему блокировка портов его не останавливает?
Что делает трафик управления (C2) обнаружимым, и почему блокировка портов его не останавливает?
C2 прячется в протоколах, которые вы и так выпускаете наружу, вроде DNS и HTTPS, поэтому блокировка портов его не ловит. Выдаёт поведение: ровные интервалы обращений, одинаково мелкие запросы, редкие долгоживущие адресаты. Ответ — egress-прокси с аутентификацией.
Типичные ошибки
- ✗Ждать, что правило по портам остановит канал поверх разрешённого протокола
- ✗Считать, что шифрование убирает любой наблюдаемый признак из трафика
- ✗Считать DNS инфраструктурным шумом, а не контролируемым путём наружу
Уточняющие вопросы
- →Какие поля лога прокси вы бы взяли за базовую линию, чтобы вскрыть периодические обращения?
- →Почему политика default-deny на исходящие меняет стоимость этой техники для атакующего?
JuniorТеорияЧастоПочему протокол аутентификации NTLM называют устаревшим, и что предотвращают SMB signing и channel binding?
Почему протокол аутентификации NTLM называют устаревшим, и что предотвращают SMB signing и channel binding?
NTLM не аутентифицирует целевой сервер, поэтому ответ, перехваченный на одном хосте, можно предъявить другому, а сам хеш — уже пригодный секрет. SMB signing отвергает ретранслированные сообщения; channel binding привязывает вход к TLS-каналу.
Типичные ошибки
- ✗Считать проблемой NTLM слабое хеширование, а не отсутствие аутентификации цели
- ✗Думать, что SMB signing шифрует трафик, а не подтверждает целостность сообщений
- ✗Полагать, что перехваченный ответ годится только против того сервера, кому он послан
Уточняющие вопросы
- →Почему SMB signing всё ещё оставляет каталожный протокол
LDAPоткрытым для релея? - →Как бы вы собрали инвентарь оставшейся аутентификации NTLM перед её отключением?
MiddleТеорияЧастоКак распыление паролей проявляется в логах Active Directory, и почему политики блокировки недостаточно?
Как распыление паролей проявляется в логах Active Directory, и почему политики блокировки недостаточно?
Распыление перебирает один пароль по многим учёткам, поэтому ни одна не доходит до порога блокировки. Признак горизонтальный: много учёток с отказами от одного источника за короткое окно — отказы преаутентификации Kerberos и входов NTLM. Блокировка ещё и рычаг DoS.
Типичные ошибки
- ✗Искать вертикальный всплеск по одной учётке вместо горизонтального шаблона
- ✗Принимать порог блокировки за детект, а не за грубую реакцию
- ✗Забывать, что агрессивную блокировку саму можно обратить в отказ в обслуживании
Уточняющие вопросы
- →Какое окно корреляции и порог вы бы выбрали для горизонтального правила?
- →Почему устойчивая к фишингу многофакторная аутентификация
MFAменяет здесь исход?
SeniorТеорияИногдаЧто делает возможными AS-REP roasting и подделку Golden/Silver ticket, и чем отвечает ротация krbtgt?
Что делает возможными AS-REP roasting и подделку Golden/Silver ticket, и чем отвечает ротация krbtgt?
AS-REP roasting возможен из-за учёток с флагом, отключающим преаутентификацию Kerberos, — флаг надо найти и снять. Golden и Silver ticket следуют из кражи ключа krbtgt или сервисного, а не из дефекта протокола. Ротируйте krbtgt дважды, но лишь после вытеснения.
Типичные ошибки
- ✗Считать подделку билетов дефектом протокола, а не следствием кражи ключа
- ✗Ротировать
krbtgtодин раз, оставляя ранее подделанные билеты действительными - ✗Ротировать ключи до вытеснения атакующего, из-за чего новые ключи крадут снова
Уточняющие вопросы
- →Почему вторая ротация
krbtgtдолжна ждать завершения репликации? - →Какие учётные записи законно могут нести исключение из преаутентификации?
SeniorТеорияИногдаЧто показывает графовый анализ путей атаки, чего не может показать сканер уязвимостей?
Что показывает графовый анализ путей атаки, чего не может показать сканер уязвимостей?
Сканер перечисляет проблемы по хостам; анализ путей моделирует учётки, сессии, членство в группах и ACL как граф и показывает кратчайшую цепочку от обычного пользователя до администратора домена. Дальше вы режете рёбра, через которые идёт большинство путей.
Типичные ошибки
- ✗Читать граф как список рисков по хостам, а не как модель связей учётных записей
- ✗Пытаться устранить каждый путь вместо общих рёбер, через которые идёт большинство
- ✗Пропускать повторный замер, который доказывает, что починка реально укоротила пути
Уточняющие вопросы
- →Какие рёбра графа обычно оказываются самыми дешёвыми для устранения на практике?
- →Почему админские сессии на обычных рабочих станциях порождают так много путей?
SeniorТеорияИногдаКак обнаружить злоупотребление репликацией DCSync, и почему неограниченное делегирование опасно для домена?
Как обнаружить злоупотребление репликацией DCSync, и почему неограниченное делегирование опасно для домена?
DCSync злоупотребляет правом репликации каталога, поэтому трафик похож на обычную репликацию. Алертите на запросы репликации от источников, не являющихся контроллерами, и проверяйте владельцев права. Неограниченное делегирование кеширует билеты — замените его на RBCD.
Типичные ошибки
- ✗Считать, что трафик репликации нельзя привязать к запрашивающему источнику
- ✗Оставлять без ревизии право репликации, выданное не-контроллерам
- ✗Думать, что неограниченное делегирование безопаснее ограниченного или RBCD
Уточняющие вопросы
- →Какие права в каталоге вы бы проверили первыми при охоте за этой экспозицией?
- →Почему хост с неограниченным делегированием фактически является активом нулевого уровня?
SeniorТеорияИногдаПочему атаку на учётные данные Kerberoasting трудно обнаружить, и как учётки gMSA её убирают?
Почему атаку на учётные данные Kerberoasting трудно обнаружить, и как учётки gMSA её убирают?
Любой доменный пользователь вправе запросить сервисный билет, а перебор идёт офлайн, поэтому алертить позднее не на что. Слабые признаки: запросы билетов с RC4 или одна учётка, спрашивающая много имён сервисов. Решение — учётки gMSA с длинными ротируемыми паролями.
Типичные ошибки
- ✗Ждать шумного алерта от операции, которая является обычным доменным трафиком
- ✗Считать, что офлайн-этап подбора порождает события в вашей сети
- ✗Ротировать пароли сервисных учёток вручную вместо отказа от паролей, заданных людьми
Уточняющие вопросы
- →Почему перевод сервисных учёток с шифрования RC4 меняет экономику для атакующего?
- →Как бы вы собрали список учёток, за которыми закреплено имя сервиса
SPN?
SeniorТеорияИногдаКак отравление резервного разрешения имён LLMNR/NBT-NS перехватывает учётные данные, и что его отключает?
Как отравление резервного разрешения имён LLMNR/NBT-NS перехватывает учётные данные, и что его отключает?
Когда DNS не разрешает имя, Windows откатывается к широковещательному разрешению, и ответить может любой хост сегмента. Жертва аутентифицируется у ответившего и отдаёт NTLM challenge-response, пригодный для офлайн-подбора или релея. Отключите LLMNR и NBT-NS политикой.
Типичные ошибки
- ✗Считать резервный механизм особенностью скорости, а не экспозицией аутентификации
- ✗Полагать, что ответивший перехватывает открытый пароль, а не challenge-response
- ✗Отключать LLMNR, не починив пробелы DNS, которые вызывают откат
Уточняющие вопросы
- →Почему включение SMB signing снижает ущерб, даже пока резервный механизм активен?
- →Какие законные сбои разрешения имён вы ожидаете увидеть после его отключения?
SeniorТеорияИногдаПочему большинство повышений привилегий — это ошибки конфигурации, а не эксплуатация, и что меняют наименьшие привилегии?
Почему большинство повышений привилегий — это ошибки конфигурации, а не эксплуатация, и что меняют наименьшие привилегии?
Эксплойты требуют уязвимой сборки и закрываются патчем; неверно выданные права постоянны и незаметны: локальный админ у всех, широкие группы, сервисные учётки с доменными правами, пароли в скриптах. Наименьшие привилегии убирают само ребро эскалации, а не следят за ним.
Типичные ошибки
- ✗Считать, что эскалация — в основном эксплойты, и потому хватает патчинга
- ✗Вкладываться только в детект, оставляя постоянные права на месте
- ✗Считать наименьшие привилегии бумажной работой, а не снятием пути эскалации
Уточняющие вопросы
- →Как бы вы измерили объём постоянных привилегий в парке перед их сокращением?
- →Что предотвращает многоуровневое администрирование, чего не может харденинг хостов?
SeniorТеорияИногдаКакие пути повышения привилегий в Windows встречаются чаще всего, и какая телеметрия их вскрывает?
Какие пути повышения привилегий в Windows встречаются чаще всего, и какая телеметрия их вскрывает?
В основном это неверная конфигурация: сервисные бинарники со слабыми ACL на путь, службы под SYSTEM, перенастраиваемые обычным пользователем, подмена токена из привилегированного процесса и UAC, принимаемый за границу безопасности. Телеметрия: изменения служб и цепочки процессов.
Типичные ошибки
- ✗Считать эскалацию в Windows задачей патчинга, а не конфигурации
- ✗Принимать UAC за границу безопасности, а не за подсказку ради удобства
- ✗Следить только за входами, игнорируя события создания и изменения служб
Уточняющие вопросы
- →Почему слабый ACL на путь сервисного бинарника даёт ту же власть, что и SYSTEM?
- →Какие связи родитель-потомок вы бы приняли за норму на рабочей станции?
