BSides Sofia 2022: AD Reconnaissance Red Team Exercise in Finding Hidden AD Relationships

2:04↗какви трикове трябва да знаете, за да го ползвате, каква стоеност може да излечете от аутпута от този инструмент и съответно ще разгледаме как да го инсталирате,

2:16↗от какво има нужда той и ще разгледаме някои заключения. Първо да ви попитам, активна директория, ползвате ли? Имате ли аккаунт по не в активната директория на организацията или училището, в която сте... Има ли някой, който няма? Ай да така да питам. Дигнете ръка, който няма. А, добре. Сравнително малко сте. Съжалявам, нали, за вас по-трудно ще бъде да приложите тези неща, но за всички останали, които имат дори базов потребителски акаунт, има неща, които може да направите с този акаунт във вашата активна директория и да разгледате какви тайни криятя. Самиято Bloodhound е...

2:57↗А, всъщност изняете. Първо, и аз ще почна с цитат. Изглежда хората от Microsoft са плодовити от гледна точка на цитати, защото моят цитат е, че защитниците на мрежите мислят в списъци, докато атакуващите ги мислят в графи. Тоест, докато за един бут има реважно всичките от петки в чек-листа да са минати, за да си издържи одита, а так и да не го интересува одита, издържан ли е или не издържан, атакера търси път между различните системи в инфраструктурата и се опитва да стигне до съкровището, което му е казано да търси.

3:38↗И всъщност докато този майндсет е налице, докато атакуващите мислят в графия защитниците в списъци,

3:45↗атакуващите печелят. Всъщност човека, който го е казал това нещо, Когато го е казал през 2014 година, е бил шеф на 3-тинтеллиженц центъра на Майкрософта, в момента е вице-президент, така че изглежда разбира за какво става въпрос. И мисля, че можем да му се доверим и ние. Давам ви пример с списъците, с които защитниците боравят. Не очаквам да ги прочетете, не са направени за да се прочетат. Имаме списъци с пачове, с уязвимост и може би сте ги виждали с тези червени, оранжеви, жълти код. кодове, асет списъци, в които се стараете всичките патчове да са приложени и списъци с секьюрити контроли, които някой ви е казал, че трябва да имате, но дали сте ги конфигурирали правилно, не сте винаги сигурни. От своя страна, Bloodhound инструментът, за който ще говорим, има за цел да ви начертая граф. Този граф е абсолютно нечетим, но пак няма за цел да се почете. Но той ви показва

4:47↗пътищата между различни потребители, например в зелено, различни компютери, на които те са логнати,

4:53↗различни organizational unity, т.е. папки в активната директория, в които тези акаунти и компютери се съхраняват и, соответно, Целта на инструмента е да ви покаже всички пътища, не само от първо ниво, т.е. не само кой в коя група членува, и съответно да видите тази група пък какви привилегии има, върху какви системи, от тези системи на кои други системи може да прескочите и така да си начертавате път в инфраструктурата, който да ви заведе до целта, която искате да постигнете. Намесваме термина Derivative Admin, т.е. това е или derivative privileges. Това са всичките привилегии, които може да си намерите по пътя, като постепенно компрометирате следващ аккаунт, следваща машина и така нататък. Самия Bloodhound като инструмент е инструмент, който чертае обектите в активност директория, казахме потребители, групи, компютери и нивата на достъп, който те имат.

5:57↗И ви помага да намерите скрити и понякога неомислени взаимовръзки между тях,

6:04↗които биха могли да представляват проблем по време на един наредите именк асесмент. На практика, тулът може да се използва еднакво добре както от червения ткълщ тим, така и от синя защитаващ тим. Като едните просто гледат откъде да минат, а другите търсят кои вратички да затворят по пътя. Прескачаме една стъпка от

6:27↗стандартния Red Teaming Engagement, стъпката в която Penetration Tester би трябвало да си намери credentialи на потребителите, ако не са му дадени в началото. Това може да стане с... мониторинг на ликове с креденшали, публични, с фишинг кампании, с догадка на някои пароли, после пасворд спрейнг и така нататък. И другата му задача преди да може да започне, работата, която ние описваме в момента, е да влезе вътре в мрежата. Като затова, отново, може да се използва някой изловреден софтуер, доставен по разнообразни начини, може да се пути на някой инсайдър, да сложи имплант, и да даде достъп. Вариантите са разнообразни, но това, което ни трябва, е достъп

7:17↗до домейн контролера и то достъп не който е специален на Remote Desktop, а си говорим за достъп от тип LDAP и SMB RPC достъп, с който ще направим цялата магия по мапинг на потребителите. Колекторите, с които Bloodhound работи, са няколко различни. Този, който е най-пред поръчителен, е SharpHound. Това е компилиран софтвер, т.е. има го наличен като source code, който можете да самия си компилирате, можете да вземете и прекомпилиран executable, можете да ползвате PowerShell с

7:58↗Invoke BloodHound Commandlet, можете ако ползвате за Command & Control PowerShell Empire,

8:05↗Той също има модули вътре в себе си за събиране на тези, на информация за

8:10↗тези взаимовръзки в активната директория. И съответно има и Python скриптове, които могат да свършат същата тази работа. Например, последния, BloodHound.py.

8:22↗Сега, това не е омислено нечитимо. Съжалявам, че не се вижда по-добре, но надявам се поне... точките тук да виждате. Същност тази графика представлява модела на работа на SharpHound и всичките му атрибути. Това е, приймете го като cheat sheet the sharphound. Той има различни колекшн методи, като можете да му кажете, ето тук посредата седия not this и only, май съм притеснен малко и затова трепери, извиняйте.

8:50↗Можете му кажете да се свърже само с домейн контролера и да се опита да направи целия възможен мапинг от там. А може да му кажете и да не докосва домейн контролера и да се опита да се свърже само с компютери в мрежата и да извлече всички атрибути от там. За какво говорим? Говорим за груп полисите най-отгоре. Говорим за домейн тръстове, ако имате форест от няколко домейна в активната директория. Говорим за контейнери, групи, аксес листи. пропъртията на обекти и сервис принципъл неймове. Т.е. това са, грубо казано, сервис акаунти, които би следвало да ползвате, за да работите с някакви сервизи в вашата среда, а не да ползвате нормални дженерик юзерски потребители. Да всъщност виждате, че тази група от неща, тъй като точките, които седят под DC only, свършват до тук, това са атрибутите, които може да съберете в рамките на един домейн контролер и то може да ги

9:48↗съберете с абсолютно непривилигирован аккаунт. Т.е. това са клерите, които може всеки един потребителски аккаунт да направи и да получи обратна информация по LDAP за тях.

10:01↗Извинявайте. Вече нещата, които трябва да съберете от компютрите, примерно кой е локал админ, това е член на локалната админска група, кой има право на RDP достъп, да да викат D-Com, PS Remote, информация за сесии или логон потребители, е информация, която за съжаление не може да се събере толкова естествено и лесно под разбиране, тъй като малко след като Bloodhound и Sharphound са представени официално, в един от следващите апдейти на Windows 10 функционалностите, които туловете използват, за да направят тази част от колекшена, е затворена за нормални потребители и е оставена като възможност само за привилегировани потребители. Т.е. трябва ви локален админ,

10:53↗който да свърши тази форма на колекшен.

11:00↗И всъщност това, което е най-хубавото, което може да направите, може да го стартирате в SharpHound на много места във мрежата, и много пъти. Това няма да обърка Data Collection, който правите, защото на всяко място в мрежата можете да успеете да съберете информация от различни локални компютри и за различни потребители, които са логнати на тях. И съответно след всеки нов сет от креденшали, до които можете да стигнете, можете да повторите упражнението и да съберете още и още информация, която да налете в интерфейса на приложението и да обогатите гледката и изгледа, който имате над активната директория на

11:46↗дали ваша, дали на тези, които таргетирате, зависи от сценария, който разработвате. Анализът, който в последствие може да направите с събраната информация, включва изключително много неща, но това, над което искам да се средоточа и да ви покажа по-конкретно, Lateral movement. Можете да видите шорте степат между различни потребители. Например, успели сте да намерите паролата на някой потребител в някой лиг и искате да видите, например, до CEO-то или до CFO-то в компанията какво ви дели и как може да стигнете по най-краткия път. И можете да видите, сега тук в случая не сечете, но ако това е потребителя с черепчето, до който ви имате креденшали, той може да се окаже член Member of това е от графа Edge, който го свързва с тази група. Групата е IT в домейна, кръстил съм си го сниксин, защото се промъкваме. Тази група е админ на даден компютър, на който компютър, жертвата, която е с мишенка

12:55↗и е даже обозначена с диамант, защото е High Value Target, има сесия. Щом има сесия, има методи, по които Можем да се възползваме от данните от тази сесия, дали ще бъде хеш, дали ще успеем да извлечем кеширани креденшали в plaintext. Вариантите са ни много, но това е само пример за един път от нещо, до което имаме достъп, до нещо, което искаме да таргетираме. Така.

13:26↗Ако това днес може да наречем странично движение, можем да направим и ескалация на привилегиите. Тоест, можем да се опитаме да намерим къде имат сесии домейн админите. Дали случайно някой не следва лоша практика да се логва на нормалната си потребителска машина с домейн админски аккаунт и да бразва в интернет, вместо домейн админски аккаунт да му върши работа само за административните му задачи върху специално определени сервери. И тук имаме друг такъв пример, където където всъщност

13:59↗имаме юзър, който сме компрометирали, който е админ на дадена машина,

14:05↗на която от своя страна има сесия друг потребител, член на домейн админите в домейна. И така можем да достигнем до заветната цел с домейн админи. Друго нещо, което можем да направим с Bloodhound, можем да открием скрити административни акаунти. Скритите административни акаунти са такива, които уж не следват нейминг-конвенцията в компанията, която е зададена. Например, за това, че аккаунта има suffix admin в края на името си.

14:42↗Например, някой си е сложил на нормалния потребител правото да менажира своят собствен компютър, което, примерно, политиката в организацията не позволява. Имаме варианти да намерим Password reuse, по дефолт, SharpHoundMap атрибути на акаунтите, като например PasswordLastSet. И ако имаме презумцията, че един човек с 15 акаунта

15:06↗обикновено като трябва да си ресетне паролата, първо може да следва лошата практика да ползва най-съща парола на всичките си акаунти. И второ, като видим, че два акаунта, които са близки като име, имат сетната парола за последен път, примерно през 5 минути. Това какво ви кара да си мислите? Може би ви кара да си мислите, че паролата е най-съща и ако попнете едната парола, тази парола би могла да ви даде достъп и до админския аккаунт на този потребител.

15:37↗Друго нещо, което ни интересува, можем да открием сервис аккаунти, за които може да се приложи техниката на Kerberhosting. Това е техника, при която използвайки Kerberos протокола за автентикация в домейна, можем да си реклеснем от нашия нормален потребителски акаунт, сервис тикет, с който да поискаме да използваме дадения сервис, предоставен от сервис акаунта. И тук има една уловка, че този сервис тикет,

16:07↗тикет грантинг сервиса, в домейна ни го подписва, т.е. не го подписва, ами го криптира с хеша на паролата на сервис акаунта. И какво правим с този хеш? Ние вече си имаме тикета локално в нашата машина. Знаем, че за да го декриптираме, трябва да познаем хеша на паролата на този сервис акаунт. И съответно това нещо може да си го вземем за домашно, офлайн. Или да си ползваме GPU instance, т.е. копачка, която имаме локално в офиса, или да си найем GPU instance в някой клауд и да си ускорим работата по чупенето на паролите. съвсем случайно може да се окаже, че някой от тези сервис аккаунти много силно се нуждае от domain admin за да работи. Това е любим сценарий. Любим сценарий, но за съжаление е лоша практика.

17:00↗Така. Кво трябва да имате предвид, когато пускате тези тулове?

17:07↗Всеки един опит да пусна SharpHound, директно

17:14↗изтеглен от репозиторито в GitHub на Bloodhound, води до тригъринг на антивирусната система, защото антивирусните или да ги наречем Endpoint Protection софтуерите по-софистикирано имат сигнатури за тази дейност, така че веднага ви хващат. Сега тук идва моята нова голгота от университета. Не ми се компилираше код тогава. Обаче сега вече трябва да го компилирам, ако искам да остана незабелязан. Така че заобикаляте го това нещо с обфускация на кода, който може да свалите от GitHub и съответно компилацията му отново, което поне първоначално, при първото стартиране няма да ви засече, докато

18:02↗се прати за корелация в облак. ново генерирани от вас софтуер и някой разбере всъщност зад какво седи. Втория трик, вече го споменахме, че за да съберете информация за логон потребителите, които имате в... т.е. за това кой активно е логоннат, ви трябват админски права, локал админски права на машините, от които искате да съберете тази информация. Трети проблем е, че сесийната информация, която е така трудно да бъде събрана, всъщност е и много крехка по отношение на времето. В смисъл, че може да съберете обикновено в рамките на 1 до 15 минути, откакто действието за логон се е случило. Тоест, session collection-а, затова е направен да може да работи в цикъл, тоест на определен период от време, вие да го стартирате, или пък ако сте умни, може да го настроите по график, Например, сутрин, когато всички идват на работа или вечер,

19:08↗тоест или следобедната почивка, когато се върщат от обяд и се логват, тогава да се опитате да съберете сесийната информация. И също така, част от графите, които бъдат ха учени на чертае, ще използват тази сесия на информация, но тя е

19:25↗крехка, в смисъл, че аз сега мога да съм направил RDP към някоя машина, обаче да съм си свършил работата, да съм се разкачил от там и вече този път през тази машина, до която теоретично моя акаунт има RDP сесия, няма да е валиден път за компрометиране на домейна. Ако искате да го инсталирате сами,

19:47↗Какво ви е необходимо? Работи за всички големи операционни системи. За Windows, за Linux, за Mac OS. И самото Bloodhound приложение е написано на Java. Не, извиняйте, не е написано на Java. Neo4j е написано на Java. Това е

20:04↗граф база данни, която е специално ориентирана към това да пази мапинги между обекти и начините по които тези обекти са свързани с други.

20:17↗трябва ви Bloodhound Goito и някои от колекторите, които изредихме. Същност не изредихме Azurehound, но ще ви кажа защо след малко. По отношение на технически умения, които ви трябват, като цяло не са големи.

20:34↗Големите технически умения може би ви трябват тогава, когато искате да намерите матчинг версия на питонските библиотеки, ако искате да ползвате Bloodhound Goito,

20:47↗питонския колектор. Защото всъщност всеки от вас, който е писал нещо на Python, може би знае каква болка е това да намерите правилните модули в правилната версия и не говоря за прехода между версия 2 и версия 3 на Python, а говоря за преходи между 3.7, 3.8 и така нататък. Това поне за мен е било проблем. Примерно проблем, проблем, да кажем, в рамките на 2 часа се разрешава, но не е нещо, което... което е приятно, докато го правите. Но хубавата новина е, че веднъж като сетнете всичко, оттам нататък само импортирате данните от колекторите и разглеждате. Няма нищо повече, което да ви е необходимо.

21:31↗Ако решите да ползвате някоя от непредефинираните

21:37↗възможности за мапинг между акаунти, потребители и машини и т.н.,

21:45↗ще ви се наложи да научите един език, който се казва Cypher, който е специфичен специално за Neo4j базите данни, така че не смятам, че е труден. Пак в рамките на част 2 можете да почнете да пишете съвсем адъкват ми коерите. Ако искате да си генерирате с това среда, имате няколко варианта. Първият е да си дигнате в виртуални машини, да

22:16↗да си инсталирате домейн контролер на тях, да си инсталирате мембър сервери и така нататък, да си създадете потребители и така нататък, но това е бавно и изисква ресурс. Затова самите Bloodhound създатели са дали Bloodhound DB Creator Tool-а, който Bloodhound DB Creator Tool е Python Script, който се свързва към Neo4j базата и автоматично за вас прави потребители с някакви връзки по между им.

22:45↗Всъщност това е най-болезнен за подкарване елемент, ако искате да го ползвате, но в една съществуваща среда той дори не ви трябва, ако приемаме, че импортирате данни от реалната ви среда. Имаме допълнителен tool, който се казва Bad Blood,

23:02↗който може да наблъска активната ви директория с семпъл обекти. По дефолт прави 2500 обекта с маппинги между тях. и достатъчно да се инсталирате само един домейн контролер, на който да се наблъскат тези обекти. И оттам нататък стартирате BadBull-ът, което е PowerShell скрипт, с правата на потребител, който може да манипулира активната директория и създавате абсолютно всичко в него, което ви е необходимо. И допълнително може да направите и Active Directory Cloning. Тоест, ако имате реална среда, може да вземете всичките атрибути от тази реална среда, да ги налеете в тестова активна директория и в тях да почнете да чупите. И всъщност, в практика вие не чупите, вие изследвате какви са връзките. Така че нещата са сравнително

23:55↗безопасни за правене. Как ви помага цялото това упражнение? Ами дава ви по-добра видимост над връзките и конфигурациите, които имате в директорията. Може да откриете опасни права или дори може да видите деривативните права, които се получават през членство в различни групи. Примерно потребител е член на една група, но тя членува в друга група, която има ели кваси привилегия. Това се води деривативна привилегия. Можете да откриете кои са скритите администраторски акаунти, можете да видите пасвартриюс и акаунти, чието пароли никога не изтичат. Можете да откриете и съответно можете да подобрите detection и prevention правилата, като например използвате някои от защитите, които са описани тук. Първа защита, употреба на Honeypot аккаунти, такива, които примерно имат админ в името си, ама не са реално админи. Някой, като прочете директорията, ще се хване за тях, най-вероятно ще

25:02↗се опита да намери повече информация за тях и да им кракне паролата. И ако успее, Ако видите successful logon event от той потребител, това означава, че

25:13↗има някой, който не трябва да е във вашата среда и съответно можете да се задействате да го откриете и да му отрежете достъп. Event ID 4769

25:25↗от Windows Event logovете. Това е Event ID, което казва, че Service Ticket е бил издаден, а с този Service Ticket казахме, че може да почнем да правим Kerber hosting. Нормално е да се издават по един-два такива тикета, но ако видите, изведнъж е една система, която избълва доста такива тикети, какъв е шанса тази система едновременно да иска да ползва сервисите давани от всичките сервис акаунти? Не е много голям шанса, така че това е аларма, която може да ви

25:58↗извести, че нещо лошо се случва. Освен това, акаунтите, които имат сервис принципъл неймове, Не трябва да са членове на high-value групите, т.е. не трябва да са domain-админи. Service-account и domain-админи? По възможност не.

26:15↗Можете да елиминирате употребата на слаби криптиращи шифри, чрез групова политика. Говорим за NTLM версия 1. Може да спрете link-local-multicast name-resolution и т.н. Това са все средства, с които атакуващия, който има някакви хешове или

26:34↗се опитва да стигне до такива, може да стигне, мамеки вашите потребители за това да отидат при него. Този процес, който правите с Bloodhound, не би следвало да бъде еднократен, би следвало да бъде повторяван процес, тъй като членствата в групите се менят, не се менят от ден до платно обикновено, но в процес на месец-два някой може да е решил, че иска да стане админ. Без детея. Всъщност списъка от защитите, които виждате, по тях, както ви казах, сме работили заедно с Цвятко. Нали, тъй като той, докато аз си играех да дигам шум, се опитваше да разбере този шум, който аз дигам, как може да го отчете и да го превърне в аларма, върху която някой

27:25↗да действа. И така, в заключение,

27:31↗атакер, който е влязал в нашата мрежа, и вече има достъп до домейн контролера, през, казахме, LDAP или RPC, може да направи мапинг на потребители, групи, груп полиси, обджекти и т.н. в активната директория. Веднъж като знае кои са най-кратките пътища до high-value target-ите, той може да ги използва, но можем да ги използваме и за да защитим тези пътища. Т.е. знаеки кои са те, ние можем да направим мониторинг или защита, като извадим определени групи от други групи, ако имаме такова нестет членство на акаунти и по този начин можем да сме по-подготвени. И на практика всеки един инструмент, който може да ползваме за атака, можем да ползваме и за защита, като видим откъде би минал атакуващия, за да поставим капани на пътя му. Какво следва? Всъщност видяхте в слайдовете си по прокраб на Azure Hound. Може би знаете за Azure активна директория, че вече,

28:34↗всъщност вече от доста време е налична, но това, което трябва да знаете за Azure активната директория като лимитация е, че на практика потребителите от Azure активната директория нямат директно право да управляват елементите, които имате в сабскрипшените в Azure. Например, виртуални машини, ключове и квото друго са сетите, ресурс групи. Тези неща не се не се мапват надолу от Azure Active Directory към субскрипшен. И на практика можем да кажем, че не това, че тенанта съдържа субскрипшена, а по-скоро, че субскрипшена има доверие на тенанта. И на ниво субскрипшен, вие на практика трябва да кажете кой потребител от тенанта, от Azure Active Directory или от хибридната активна директория, може да има права върху субскрипшена по-надолу.

29:31↗Разработват се в момента нови проверки, нови графи, които свързват различните потребители и всъщност различните сервиси в Azure, така че това нещо скоро ще бъде мапнато. До момента вече има еджове в Azure, които може да проследите, но повечето от тях са на ниво субскрипшн.

29:56↗И също така, за да работите с Azure Hound, ви трябва да допълнителни Commandlet, които да се инсталирате, които са AZ за Subscription, така се казва

30:06↗за Azure функциите, и Azure AD за Azure AD атрибутите. И другото нещо, по което девелопърите са обявили, че работят в момента, е интеграция с Active Directory Certificate Services. И целта им е да видят кои от потребителите в активната директория, какви привилегии имат в рамките на Certificate Services, а понякога това да имате сертификат валиден, издаден от Certificate Authority-то вътре в домейна, може да отвори пътя

30:42↗за мисконфигурация по-натрата, как и оттам картинката, че доста мисконфигурации може да се съберат под капака на Certificate Services. Самия tool Bloodhound е Open Source tool, но има и Subscription, Enterprise версия по-точно, която Enterprise версия ви дава много лесно смилаем репорт за това

31:08↗с какви проблеми разполагате в средата си.

31:15↗Но, всъщност от версия 4.1, На Bloodhound, която е текущата, девелоперите са взели решение Open Source версията и Enterprise версията да се слеят като CodeBase, така че на практика няма разлика в Enterprise срещу Open Source.

31:37↗Мисля, че горе долу спях да се вместя в половината част. Имате думата за въпроси.

32:07↗Въпросът е, този продукт има ли отношение към Privilege Access Management, има ли някаква комуникация с него? В случая говорим за User Account Control в Windows.

32:19↗На практика това е нещото, който Privilege Access Management... Дейността да си седминат. Този тул не аудитира дейността на си седминат. Не аудитира кой къде, какви привилегии ползва, а само какви има. По-скоро въпросът тук не е... Няма какво ви казвам, какво ви е въпросът. Не гледаме употребата, гледаме само конфигурация статично. Всъщност единството не е статично нещо с сесиите. Кой, къде, къде сесии има.

32:54↗Но какво прави в рамките на тези сесии, за момента не е обектна проверка.

33:06↗Други въпроси? А,

33:12↗така. Добре.

33:31↗Ами, представявам конкретно този, защото той е популярен, и с голям install base и съответно активна разработка. За CyberArk не съм запознат с дейността му, но знам, че този самият продукт е резултат от подобни продукти, разработвани някога от Microsoft. Същност цитата, с който започнах, за това кой мисли в списъци и кой в графи, идва от човек от Microsoft, който е бил част от разработката на сходен или аналогичен такъв продукт, вътрешен за Microsoft, но той

34:07↗не е видял такава популярност и бял свят, така че всеки от нас да може да си го изтегля и да го пусне. Най-вероятно, в момента не мога да се сетя името на Тула, но не е нещо, което се разработва активно.

34:52↗Има. Има такива опции. Това, което най-често спира...

35:00↗Да, аз не повторих въпроса, извиняйте. Въпросът е какви детекции обикновено вдигат

35:07↗тези тулове и на практика как могат да се заобиколят. Детекциите обикновено са свързани с количеството на заявките, които се изпращат и начина по който тези заявки в последствие се обработват Тоест сигнатурата обхваща най-често това. Тоест в какъв тип структура от данни ги записваш, защо ги записваш така и така нататък. Заобикавлянията на тези детекции са да разнообразиш структурата, в която ги записваш и да направиш рейт лимит

35:43↗над самите заявки.

35:56↗Да. Microsoft дори има цитатия на тая тема. С Amsi Toolset Anti-Mallware Service Interface май беше. Ако потърсиш Amsi Bloodhound, ще видиш какво точно са написали по въпроса

36:15↗за детекцията. Въпрос? А,

36:24↗не. Добре. Някъде другът е въпрос? Добре. Ако нямате въпроси, благодаря ви за вниманието.

36:37↗И се надявам да си поиграете с това, да ви е станало достатъчно.