Kerberoasting, обяснено за защитници

Kerberoasting позволява на обикновен домейн потребител да получи Kerberos билети за служебни акаунти и да опита офлайн възстановяване на паролите им. Ако паролата е слаба, а акаунтът има високи права, последствията могат да бъдат сериозни. Обясняваме механизма и мерките, които ограничават този риск.

Механизмът

Kerberos service tickets могат да предоставят материал за офлайн отгатване на парола, когато условията го позволяват. Протоколно допустима заявка може да бъде записана и открита: при подходящ одит домейн контролерите записват TGS заявки в събитие 4769. Самото получаване на ticket материал не възстановява паролата и не доказва достъп до услугата.

Защо е толкова ефективно

• Малки начални права могат да са достатъчни. Обичайна удостоверена идентичност може да заявява tickets за много SPN според directory достъпа, KDC политиката и конфигурацията. Това не означава възстановяване на всяка служебна парола или контрол над домейна.
• Офлайн отгатване. След получаване на подходящ ticket материал предположенията могат да се проверяват офлайн без account-lockout събитие за всяко. Получаването на tickets и другата активност все още могат да създават мрежова и одитна телеметрия.
• Служебните акаунти са стари и с прекомерни права. Паролите им често се задават веднъж, преди години, никога не се подменят, а акаунтът често е член на мощна група. При действителни ангажименти сме намирали служебни акаунти с права на домейн администратор, чиито пароли не са били сменяни повече от десетилетие.

Как да накарате Kerberoasting да се провали

• Дълги, случайни пароли. Случайна парола от 25+ символа е на практика неразбиваема офлайн. За служебните акаунти използвайте служебни акаунти, управлявани от група (gMSA), които се грижат за това автоматично.
• Минимални необходими права. Служебен акаунт с разбита парола не бива да е домейн администратор. Премахнете служебните акаунти от привилегированите групи.
• Силно шифроване. Уверете се, че акаунтите не се връщат към RC4 за билетите; изисквайте AES.
• Търсете модела. Един единствен акаунт, който заявява билети за услуги за много SPN в кратък период, е силен сигнал — следете за него.

Kerberoasting е проблем на силата на паролите, облечен в костюм на протокол. Поправете паролите — в идеалния случай като премахнете хората от процеса чрез gMSA — и техниката тихо спира да се изплаща.

AS-REP roasting: сходна атака с по-малко следи

Kerberoasting изисква акаунт като опорна точка, за да бъдат заявени билети. AS-REP roasting изисква още по-малко. За всеки акаунт с изключено предварително удостоверяване на Kerberos може да бъде заявен материал, подлежащ на офлайн разбиване без никакво удостоверяване — напълно неудостоверен нападател в мрежата може да го събере. Рутинно намираме десетки такива акаунти, обикновено остарели или служебни идентичности, при които някой е изключил предварителното удостоверяване преди години, за да поправи проблем със съвместимостта, и никога не го е включил обратно. Изисквайте предварително удостоверяване за всеки акаунт и търсете малкото, при които е изключено.

Откриване на Kerberoasting

Kerberoasting е тих по замисъл, затова трябва да го търсите умишлено. Сигналите са конкретни: един акаунт, който заявява билети за услуги за много различни SPN в кратък период, или билети, заявени със слабото RC4 шифроване. Известявайте и за двете. Няма да получите блокиране или скок в неуспешните влизания, които да ви подскажат — самата заявка е законна — така че откриването трябва да бъде изградено, а не предположено.

Как се откриват SPN и защо търсенето изглежда обикновено

Всеки акаунт в домейна, който изпълнява услуга, обявява име на принципал на услугата, за да могат клиентите да намерят правилния билет за заявяване. Тези имена живеят в атрибут на директорията, който всеки удостоверен акаунт има право да чете. Това право не е неправилна конфигурация; така е проектиран да работи Kerberos. Работната станция трябва да разреши SPN за база данни или уеб услуга, преди да може да се удостовери към нея, така че директорията трябва да отговаря на SPN запитвания от обикновени потребители цял ден.

Неудобното последствие за защитниците е, че изброяването на акаунти със SPN е почти неразличимо от законното разглеждане на директорията. Едно запитване, което връща всеки потребителски акаунт, носещ SPN, произвежда точно краткия списък, който нападателят иска: служебните акаунти, управлявани ръчно, чиито пароли е най-вероятно да са слаби и статични. Тъй като прочитането е разрешено и незабележително, стъпката на изброяване рядко генерира полезно известие сама по себе си. Сигналът, който си заслужава да бъде преследван, не е търсенето, а това, което идва след него.

RC4 срещу AES билети и икономиката на разбиването

Типът шифроване на билета за услуга определя колко скъпа е офлайн атаката. Остарелите RC4 билети се извеждат от NT хеш без добавена сол на паролата на акаунта, така че машина за разбиване може да изпробва огромен брой кандидат-пароли в секунда срещу тях. AES билетите използват итеративно извеждане на ключ с добавена сол, което е умишлено по-бавно за изчисляване, намалявайки скоростта на предположенията на нападателя с порядъци. Паролата не се е променила; променила се е само цената на всяко предположение.

Затова нападателите ще се опитват да получат RC4 билети дори в среда, която поддържа AES. Клиентът може да заяви кои типове шифроване е склонен да приеме, и ако акаунтът и домейнът все още позволяват RC4, KDC може да издаде по-слабия билет. Понижаването на билета до RC4 превръща парола, която би издържала разбиване при AES, в такава, която може да падне за часове.

Управлявани служебни акаунти: gMSA и dMSA в дълбочина

Структурната поправка за служебния акаунт, управляван ръчно и подлежащ на „изпичане“, е човек изобщо да не знае паролата. Служебен акаунт, управляван от група (gMSA), има парола, генерирана и подменяна автоматично от домейна, обикновено по кратък цикъл, с ключ, който е дълъг, случаен и никога не е изписван. Билет за gMSA все още е шифрован с ключа на акаунта, така че билет все още може да бъде заявен — но паролата зад него не е дума, избрана от човек, така че офлайн разбиването вече не е икономично. Достъпът до самата парола е ограничен до конкретните хостове, разрешени да я извлекат.

Управляван служебен профил намалява зависимостта от статични пароли, избирани от хора. gMSA паролите се генерират и сменят от Windows и се извличат от разрешени хостове; компрометиран такъв хост или прекомерни права за извличане все още могат да доведат до злоупотреба. dMSA има различен модел, обвързан с устройство, и собствени изисквания за внедряване. Нито един от двата подхода не гарантира, че credentials не могат да бъдат откраднати или използвани неправомерно; защитете хостовете, правата за извличане и правата на услугата.

Рискове при делегиране и използване на SPN примамки

SPN имат още по-голямо значение, когато стоят върху акаунт, доверен за делегиране. Разбиването на служебен акаунт, който може да се представя за други потребители нататък, превръща една офлайн победа в широк обхват, така че акаунтите, доверени за делегиране, са целите с най-висока стойност за „изпичане“ и изискват най-силните пароли и най-стегнатия обхват.

Защитниците могат и да обърнат механизма. SPN примамка е подвеждащ акаунт, който носи име на услуга, но не изпълнява никаква услуга и не се използва от никого. Нито един законен клиент няма каквато и да е причина да заявява неговия билет, така че заявка за билет за услуга за този акаунт почти със сигурност е разузнаване. Това е рядко откриване, което произвежда чист сигнал с висока увереност и съвсем малко шум.