TGS Rubeus.exe kerberoast /nowrap
Мы можем видеть, что он отправляет следующий
LDAP запрос(&(samAccountType=805306368)(servicePrincipalName=*)(!samAccountName=krbtgt)(!(UserAccountControl:1.2.840.113556.1.4.803:=2)))
(samAccountType=805306368) - получаем доменных пользователей(servicePrincipalName=*) - получаем все SPN в домене(!samAccountName=krbtgt) - убираем из вывода krbtgt(!(UserAccountControl:1.2.840.113556.1.4.803:=2)) - смотрим, что УЗ не заблокирована.Тут уже начинается детект у многих. Вся проблема в
servicePrincipalNames=*, который SOC ловит, т.к мы получаем список всех SPN. Лучше определить учетные записи с SPN и только потом делать уже запрос Rubeus.exe kerberoast /nowrap /user:svc_chat /spn:HTTP/sus.monkey.local
Многие знают про некий даунгрейд тикета с AES на RC4. По факту, ничего не мешает сервисной учетке поддерживать RC4 и AES128/256 одновременно, поэтому мы можем запросить, запросить тикет не с AES, а с RC4, поэтому и сбрутать креды будет намного легче. В Rubeus с этим помогает флаг
/tgtdeleg. Однако, в идеале тикеты и его содержимое мониторят.Попробуем немного углубиться в содержимое тикета, если конкретнее то в его флаги. Эти 32-битные флаги называют
KDCOptions. Нормальным поведением является, если значение KDCOptions равно 0x40810000, однако при попытке поиграться с тикетами, мы можем заметить другое значение 0x40810010. Если их сравнивать, то можем понять, что нам надо избавиться от Renewable-OK, и с этим уже может помочь тулза Orpheus, которая подправит флаги.Интересным решением для обнаружения атак является использование фейковых УЗ с SPN, данный момент мне подчеркнул один из моих коллег. Обычно стоит обращать внимание на
LastLogon, который может намекнуть на фальшивость УЗ. Ну и наличие высоких привилегий, тоже дает намекBye-bye ✨