В этой статье я покажу нес­коль­ко атак на Active Directory, пореко­мен­дую ути­литы для экс­плу­ата­ции и рас­ска­жу об инди­като­рах, на которые нуж­но обра­щать вни­мание при рас­сле­дова­нии инци­ден­тов. А упражнять­ся будем на лабора­тор­ных работах Sherlocks с пло­щад­ки Hack The Box.

Почему стоит уделить особое внимание именно атакам на Active Directory?

Ин­фраструк­тура мно­гих ком­паний пос­тро­ена на осно­ве служ­бы катало­гов Active Directory. Даже с уче­том того, что сеть может содер­жать неболь­шое количес­тво хос­тов, сер­веров, сер­висов и служб, за дос­таточ­но корот­кий про­межу­ток вре­мени в сис­теме про­исхо­дят тысячи событий, из‑за чего ста­новит­ся зат­рудни­тель­но ана­лизи­ровать компь­ютер­ные инци­ден­ты.

По­мимо это­го, в интерне­те мож­но най­ти мно­жес­тво матери­алов по реали­зации как прос­тых, так и прод­винутых атак на AD. Поэто­му любой скрипт‑кид­ди, воору­жив­шись парой ути­лит, может рис­кнуть и поп­робовать свои силы в хакин­ге, что уж говорить про серь­езных кибер­прес­тупни­ков.

Все это спо­собс­тву­ет тому, что ребятам из блю‑тима важ­но обла­дать зна­ниями в сфе­ре безопас­ности инфраструк­туры и уметь быс­тро реаги­ровать на подоб­ные инци­ден­ты, а так­же находить ошиб­ки в кон­фигура­ции AD.

1. Kerberoasting

Пе­ред тем как мы прис­тупим к раз­бору пер­вой лабора­тор­ной работы, нач­нем с неболь­шого экскур­са в теорию, что­бы знать вра­га в лицо.

Про­токол Kerberos в Active Directory исполь­зует­ся для аутен­тифика­ции поль­зовате­лей и пре­дос­тавле­ния дос­тупа к служ­бам. Ког­да поль­зователь пыта­ется получить дос­туп к ресур­су, который управля­ется име­нем субъ­екта‑служ­бы (SPN), при исполь­зовании Kerberos кон­трол­лер домена соз­дает сер­висный билет (ST) и шиф­рует его с исполь­зовани­ем хеша пароля SPN. Пос­ле это­го веб‑сер­вер рас­шифро­выва­ет и под­твержда­ет под­линность ST.

Од­нако, если зап­рос на получе­ние сер­висно­го билета исхо­дит от самого кон­трол­лера домена, про­вер­ка того, име­ет ли поль­зователь необ­ходимые пра­ва для дос­тупа к пре­дос­тавля­емым SPN ресур­сам, не выпол­няет­ся.

Те­перь о самом инте­рес­ном: зло­умыш­ленни­ки, зная кон­крет­ную служ­бу (или SPN), которую они намере­ны ата­ковать, могут отпра­вить зап­рос на ST с кон­трол­лера домена и получить обратно ST, зашиф­рован­ный хешем пароля соот­ветс­тву­юще­го SPN.

Час­то для про­веде­ния ата­ки Kerberoasting исполь­зуют ути­литу GetUserSPNs из ком­плек­та дос­таточ­но мощ­ного инс­тру­мен­та ауди­та Impacket. Таким обра­зом, зло­умыш­ленник получа­ет хеш SPN, который он может проб­рутить в авто­ном­ном режиме и зав­ладеть паролем учет­ки в откры­том виде. Если корот­ко, то в этом и зак­люча­ется вся суть опи­сан­ной ата­ки. В рам­ках MITRE ATT&CK Kerberoasting она отно­сит­ся к под­техни­ке T1558.003.

Campfire-1

Итак, чита­ем опи­сание лабора­тор­ной работы Campfire-1, ска­чива­ем архив, рас­паковы­ваем его и видим, что нам пре­дос­тавле­ны prefetch-фай­лы машины жер­твы, жур­налы событий рабочей стан­ции и кон­трол­лера домена.

Нач­нем поиск игол­ки в сто­ге сена с прос­мотра событий с кодом 4769 в жур­нале безопас­ности на кон­трол­лере домена. Этот код обоз­нача­ет зап­рос билета служ­бы Kerberos.

Да­же в сред­ней по раз­меру инфраструк­туре Active Directory такие зап­росы могут про­исхо­дить боль­ше тысячи раз за пару минут, поэто­му отфиль­тру­ем средс­тво прос­мотра событий по ID 4769, что зна­читель­но упростит наш поиск.

Те­перь нам пред­сто­ит отсе­ять обыч­ные опе­рации AD от подоз­ритель­ных. Для это­го рас­смот­рим фор­му события попод­робнее.

Здесь мы видим, что учет­ная запись DC01$ зап­росила сер­висный билет для сер­виса, наз­ванно­го DC01$. В Windows име­на, закан­чива­ющиеся сим­волом дол­лара ($), обыч­но явля­ются учет­ными запися­ми служб и машин­ными учет­ными запися­ми. Ана­логич­но служ­ба DC01$ свя­зана с этой учет­ной записью служ­бы.

Все это отно­сит­ся к стан­дар­тным опе­раци­ям AD. Ниже мы можем уви­деть параметр под наз­вани­ем «Тип шиф­рования билета» со зна­чени­ем 0x12, что экви­вален­тно AES256-CTS-HMAC-SHA1-96. В легитим­ных слу­чаях исполь­зования опе­раций с билета­ми Kerberos тип шиф­рования будет 0x12 или 0x11.

Ес­ли мы уви­дим тип шиф­рования 0x17, что соот­ветс­тву­ет потоко­вому шиф­ру RC4, это будет поводом глуб­же изу­чить ситу­ацию: зло­умыш­ленник может зап­росить билет с таким типом шиф­рования, потому что это поз­волит ему взло­мать пароль, зат­ратив мень­ше уси­лий.

info

Все основные инс­тру­мен­ты с откры­тым исходным кодом, такие как Impacket и Rubeus, зап­рашива­ют билеты с типом шиф­рования RC4.

За­пом­ним иден­тифика­торы, которые помогут быс­тро отсле­дить необ­ходимое событие с подоз­рени­ем на Kerberoasting, поэто­му обра­щаем вни­мание на сле­дующие важ­ные момен­ты.

  1. Учет­ные записи, которые не явля­ются учет­ной записью служ­бы или машины (и не закан­чива­ются сим­волом $). Сле­дова­тель­но, под подоз­рени­ем любая стан­дар­тная учет­ная запись домена поль­зовате­ля (эта учет­ная запись была ском­про­мети­рова­на, и с ее помощью зло­умыш­ленник совер­шил ата­ку).

  2. Наз­вания служб, которые не закан­чива­ются сим­волом $.

  3. Тип шиф­рования билета 0x17, что соот­ветс­тву­ет шиф­рованию RC4, которое поз­волит зло­умыш­ленни­кам лег­ко взло­мать хеш.

С помощью перечис­ленных кри­тери­ев лег­ко находим нуж­ное событие.

Вид­но, что учет­ная запись домена alonzo.spire зап­росила билет для служ­бы MSSQLService с типом шиф­рования 0x17 с компь­юте­ра, име­юще­го IP-адрес 172.17.79.129. Запом­ним эти инди­като­ры ком­про­мета­ции, пос­коль­ку даль­нейший ана­лиз будет осно­вывать­ся на пос­тро­ении тай­млай­на от это­го события с исполь­зовани­ем IP-адре­са и име­ни учет­ной записи.

Поп­робу­ем разоб­рать­ся с тем, какие дей­ствия про­исхо­дили от име­ни учет­ки alonzo.spire. Для это­го откро­ем жур­нал событий PowerShell. Дата и вре­мя ранее най­ден­ного нами события Kerberoasting — 2024-05-21 03:18:09 (и да, не забыва­ем перево­дить вре­мя в UTC). В жур­нале событий PowerShell на хос­те ищем подоз­ритель­ную активность при­мер­но в это же вре­мя.

По­доз­ревая, что вре­донос­ные дей­ствия были совер­шены с исполь­зовани­ем powershell.exe, отфиль­тру­ем события по ID 4104 (в этих событи­ях мож­но будет уви­деть тело выпол­няемо­го скрип­та).

И дей­стви­тель­но, находим подоз­ритель­ное событие с бай­пасом выпол­нения сце­нария PowerShell бук­валь­но за пару минут до совер­шения ата­ки.

Та­кое дей­ствие поз­воля­ет выпол­нять сце­нарии в сеан­се PowerShell. Из даль­нейше­го ана­лиза событий вид­но, что все они были частью одно­го сце­нария.

Об­наруже­ны доказа­тель­ства злов­реднос­ти сце­нария PowerView.ps1, который исполь­зовал­ся для совер­шения дей­ствий на эта­пе пос­тэкс­плу­ата­ции.

Приш­ло вре­мя про­ана­лизи­ровать фай­лы пред­варитель­ной заг­рузки. Для это­го вос­поль­зуем­ся ути­литой PECmd Эри­ка Цим­мерма­на. Пре­обра­зуем prefetch-фай­лы в .csv:

PECmd.exe -d "путь/к/папке/с/файлами/предварительной/загрузки" --csv . --csvf наш_ксв_файл.csv

Для более удоб­ного ана­лиза с помощью Timeline Explorer откры­ваем .csv и филь­тру­ем дату инци­ден­та по пос­ледне­му запус­ку.

Со­пос­тавив вре­мен­ные мет­ки событий, находим, что в инте­ресу­ющий нас про­межу­ток вре­мени запус­кался RUBEUS.EXE — инс­тру­мент, исполь­зуемый при пен­тесте и ата­ках на AD.

Меры предотвращения

Что­бы пре­дот­вра­тить такие ата­ки, важ­но исполь­зовать длин­ные и слож­ные пароли для учет­ных записей служб. Это зна­читель­но замед­лит взлом хешей.

Для при­виле­гиро­ван­ных служб рас­смот­ри воз­можность при­менять управля­емые груп­пы сер­висных учет­ных записей (GMSA), что­бы гаран­тировать исполь­зование длин­ных, слож­ных паролей, которые час­то меня­ются.

Ре­али­зация управле­ния при­виле­гиро­ван­ным дос­тупом (PAM) так­же поможет огра­ничить воз­дей­ствие при­виле­гиро­ван­ных учет­ных дан­ных и умень­шить повер­хность ата­ки для Kerberoasting, одновре­мен­но обес­печивая монито­ринг всех изме­нений раз­решений для групп безопас­ности.

2. AS-REP Roasting

А теперь еще нем­ного теории, что­бы понять, что это за зверь такой — AS-REP Roasting. Зап­рос сер­вера аутен­тифика­ции (AS-REQ) обыч­но называ­ют пред­варитель­ной аутен­тифика­цией Kerberos. Пер­вое, что про­исхо­дит во вре­мя аутен­тифика­ции внут­ри Kerberos, — это зап­рос аутен­тифика­ции к кон­трол­леру домена, что­бы мож­но было про­верить юзе­ра, пыта­юще­гося прой­ти аутен­тифика­цию.

Ког­да сис­тема убе­дит­ся, что кли­ент про­шел авто­риза­цию, она отпра­вит ему ответ от сер­вера аутен­тифика­ции (AS-REP), содер­жащий сеан­совый ключ и про­пус­кной билет (TGT). Этот сеан­совый ключ зашиф­рован с помощью хеша пароля поль­зовате­ля, так что толь­ко он может его рас­шифро­вать и исполь­зовать сно­ва.

А теперь об инте­рес­ном. Если поль­зовате­ли в домене нас­тро­ены про­пус­кать про­цесс пред­варитель­ной аутен­тифика­ции, то зло­умыш­ленни­ки могут отправ­лять зап­рос AS (AS-REQ) от име­ни этих поль­зовате­лей, потому что AS-REP содер­жит сеан­совые клю­чи, зашиф­рован­ные их пароль­ными хешами. В резуль­тате зло­умыш­ленник может получить хеш пароля любого юзе­ра в сис­теме. Да, инте­рес­но, зачем же отклю­чать про­цесс пред­варитель­ной аутен­тифика­ции? На деле адми­ны иног­да вык­люча­ют эту фун­кцию на вре­мя выпол­нения отла­доч­ных работ или тес­тов, а потом поп­росту забыва­ют вклю­чить ее обратно.

За­дачу взлом­щикам очень силь­но упро­щает ути­лита GetNPUsers из набора инс­тру­мен­тов Impacket. Затем хакеры могут начать брут­форсить пароли, что­бы рас­шифро­вать сеан­совый ключ. В слу­чае успе­ха ата­кующий узна­ет пароль поль­зовате­ля.

Спе­циалис­ты по информа­цион­ной безопас­ности час­то называ­ют этот зашиф­рован­ный сеан­совый ключ хешем, но он на самом деле таковым не явля­ется. Одна­ко такие инс­тру­мен­ты, как Hashcat и John the Ripper, могут очень быс­тро под­бирать пароли к подоб­ному «хешу». AS-REP Roasting сопос­тавлен с под­техни­кой T1558.004 в рам­ках MITRE ATT&CK.

Campfire-2

Пой­дем раз­бирать­ся с тем, как же это все детек­тить, на при­мере лабора­тор­ной работы Campfire-2. Выпол­няем стан­дар­тные про­цеду­ры: кача­ем архив, рас­паковы­ваем его и видим, что перед нами файл жур­нала событий Security.evtx (если что, этот файл взят с кон­трол­лера домена).

Так же как и в пре­дыду­щей лабора­тор­ной, пра­виль­ная работа с филь­тра­ми и понима­ние того, на что нуж­но обра­тить вни­мание, поможет нам сок­ратить вре­мя иссле­дова­ния и реаги­рова­ния на угро­зу.

Пер­вое, что мы сра­зу же начина­ем ана­лизи­ровать, — события с ID 4768. Это иден­тифика­тор события, записы­ваемый в жур­налах безопас­ности на кон­трол­лере домена каж­дый раз, ког­да зап­рашива­ется билет про­вер­ки под­линнос­ти Kerberos.

Рас­смот­рим под­робнее фор­му одно­го из событий.

В нашем слу­чае отоб­ража­ется обыч­ное событие зап­роса билета аутен­тифика­ции поль­зовате­лем Administrator у уни­вер­саль­ной служ­бы AD — krbtgt.

Уже тра­дици­онно обра­щаем вни­мание на исполь­зование опре­делен­ного типа шиф­рования. Если мы уви­дим тип шиф­рования 0x17, который пред­став­ляет собой RC4, то это будет под­сказ­кой — такой тип поз­воля­ет зло­умыш­ленни­кам быс­трее рас­шифро­вать пароль.

Сок­раща­ем количес­тво тре­бующих рас­сле­дова­ния событий — отбра­сыва­ем все име­на служб, кро­ме krbtgt. Это свя­зано с тем, что во вре­мя ата­ки зло­умыш­ленник получа­ет билет аутен­тифика­ции — точ­но так же, как это сде­лала бы закон­ная учет­ка поль­зовате­ля, а krbtgt — это стан­дар­тная служ­ба AD, которая обра­баты­вает поток аутен­тифика­ции в Active Directory.

По­каза­телем того, что хакер успешно про­вел ата­ку AS-REP (неваж­но, уда­лось ему взло­мать хеш или нет), слу­жит зна­чение типа пред­варитель­ной про­вер­ки под­линнос­ти в резуль­тиру­ющих жур­налах.

Пе­редо­вой спо­соб поис­ка угроз для этой ата­ки — прос­то най­ти тип пред­варитель­ной аутен­тифика­ции = 0, озна­чающей, что она отклю­чена. Таким обра­зом мы убе­рем боль­шую часть бес­полез­ных событий в жур­налах, оста­вив для ана­лиза более деталь­ные резуль­таты.

Да­вай еще раз перечис­лим все необ­ходимое для успешно­го детек­та. Изна­чаль­но мы отсле­жива­ем все события 4768, но берем во вни­мание те, где:

  1. Тип пред­варитель­ной про­вер­ки под­линнос­ти равен 0, то есть аутен­тифика­ция отклю­чена. Это важ­ное усло­вие, которое необ­ходимо выпол­нить, пос­коль­ку без это­го ата­ка невоз­можна.

  2. Имя служ­бы — krbtgt, пос­коль­ку толь­ко krbtgt может выпол­нять про­цес­сы аутен­тифика­ции в AD.

  3. Тип шиф­рования билета — 0x17, соот­ветс­тву­ющий шиф­рованию RC4, что поз­волит зло­умыш­ленни­кам лег­ко взло­мать хеш.

Ос­новыва­ясь на этих филь­трах, быс­тро находим инте­ресу­ющее нас событие.

Ста­новит­ся ясно, что юзер arthur.kyle был ском­про­мети­рован, одна­ко сущес­тву­ет еще одна взло­ман­ная учет­ка, от лица которой выпол­нялась ата­ка.

У нас есть IP-адрес машины, с которой пос­тупил зап­рос, поэто­му будем искать события билетов служ­бы Kerberos, так как каж­дая учет­ная запись поль­зовате­ля домена зап­рашива­ет их либо во вре­мя вхо­да в сис­тему (при аутен­тифика­ции), либо при обыч­ном исполь­зовании домена.

От­филь­тру­ем жур­нал по ID 4769 (зап­рос билета служ­бы Kerberos) и рас­смот­рим события, про­исхо­див­шие во вре­мя вре­донос­ной активнос­ти.

Че­рез минуту пос­ле обна­ружен­ного AS-REP Roasting про­исхо­дит событие с учет­ки happy.grunwald с того же IP-адре­са 172.17.79.129.

Ка­залось бы, это обыч­ный ивент и здесь нет ничего подоз­ритель­ного. Но, учи­тывая, что вход в сис­тему под юзе­ром happy.grunwald выпол­нялся во вре­мя ата­ки AS-REP Roasting и исхо­дил с той же машины, мож­но пред­положить, что и эта учет­ка была ском­про­мети­рова­на. Этот факт однознач­но рас­ширя­ет мас­штаб все­го инци­ден­та.

К сожале­нию, лабора­тор­ная работа не пре­дос­тавля­ет нам допол­нитель­ные арте­фак­ты, поэто­му никак не удас­тся рас­сле­довать эту кибера­таку пол­ностью.

info

Ата­ка AS-REP Roasting воз­можна толь­ко при наличии спис­ка поль­зовате­лей (то есть если ты получил его из нулево­го сеан­са SMB). Но если ты прос­то исполь­зуешь инс­тру­мент вро­де GetNPUsers.py или Rubeus, тебе пот­ребу­ется активная учет­ная запись поль­зовате­ля для зап­роса спис­ка юзе­ров (все это про­исхо­дит в фоновом режиме при запус­ке ата­ки). Это озна­чает, что ата­ка может быть выпол­нена без какой‑либо аутен­тифика­ции, если зло­умыш­ленник каким‑либо обра­зом заполу­чил спи­сок поль­зовате­лей (к при­меру, перебо­ром уче­ток с помощью Kerbrute).

Меры предотвращения

Всег­да внед­ряй надеж­ную полити­ку паролей с исполь­зовани­ем слож­ных паролей, которые регуляр­но меня­ются. Если есть воз­можность, то повысь безопас­ность, вклю­чив 2FA для аутен­тифици­рован­ных сер­висов.

Что­бы пре­дот­вра­тить ата­ки AS-REP Roasting, край­не важ­но убе­дить­ся, что пред­варитель­ная аутен­тифика­ция вклю­чена для каж­дой учет­ной записи.

3. LLMNR Poisoning

Рань­ше в сетях Windows исполь­зовал­ся про­токол Network Basic Input/Output System (NetBIOS) для выпол­нения опе­раций через сеть. Важ­ной частью это­го про­токо­ла был NetBIOS Name Service (NBT-NS), отве­чав­ший за регис­тра­цию и раз­решение имен. LLMNR (Link-Local Multicast Name Resolution) — это пря­мой пре­емник NBT-NS. Он выпол­няет ту же фун­кцию, что и его пред­шес­твен­ник, — раз­решение имен хос­тов в той же локаль­ной сети.

LLMNR поз­воля­ет раз­решать как адре­са IPv4, так и IPv6 без необ­ходимос­ти наличия DNS-сер­вера в локаль­ной сети. Если зап­рос к DNS-сер­веру не выпол­няет­ся (нап­ример, если DNS-сер­вер недос­тупен), отправ­ляет­ся LLMNR-зап­рос по локаль­ной сети.

Суть в том, что LLMNR не тре­бует аутен­тифика­ции, поэто­му любой компь­ютер в локал­ке может выпол­нить зап­рос LLMNR. Если кто‑то прос­лушива­ет локаль­ную сеть, он может отве­чать на эти зап­росы, пред­став­ляя устрой­ство сво­им IP-адре­сом и перенап­равляя тра­фик. Все это может при­вес­ти к потен­циаль­но опас­ному поведе­нию и ата­кам, таким как LLMNR Poisoning.

info

Responder — популяр­ный инс­тру­мент, вхо­дящий в пакет ути­лит Kali Linux, для про­веде­ния атак с отравле­нием LLMNR.

Ес­ли в сети про­исхо­дит событие LLMNR и зло­умыш­ленник его прос­лушива­ет, то он может получить кон­фиден­циаль­ную информа­цию о жер­тве, такую ​​как IP-адрес, имя поль­зовате­ля и хеш пароля. Затем хакеры могут попытать­ся взло­мать получен­ный хеш и получить пароль в откры­том виде либо передать этот хеш для аутен­тифика­ции в опре­делен­ной служ­бе. LLMNR/NBT-NS Poisoning и SMB Relay сопос­тавле­ны с под­техни­кой T1557.001 в MITRE ATT&CK.

Noxious

Опи­сание лабора­тор­ной работы Noxious сра­зу спой­лерит, что мы будем иметь дело с LLMNR-отравле­нием. Для работы нам пре­дос­тавля­ют файл с дам­пом тра­фика.

От­кры­ваем .pcap и филь­тру­ем его по LLMNR-тра­фику, что­бы уви­деть, какие хос­ты учас­тво­вали во вза­имо­дей­стви­ях, а так­же отме­тить исполь­зуемые IP-адре­са.

info

LLMNR по умол­чанию работа­ет на пор­те UDP 5355. Поэто­му филь­тр будет выг­лядеть так: udp.port == 5355.

В самом начале отфиль­тро­ван­ного тра­фика вид­но, что хост 172.17.79.136 выпол­нил DNS-зап­рос DCC01, а дру­гой хост 172.17.79.135 отве­тил на этот зап­рос.

Пред­ста­вим (а поз­же и докажем), что зап­рос DCC01 — опе­чат­ка в обра­щении к DC01, это мог­ло при­вес­ти к сбою в работе DNS-сер­вера и исполь­зованию про­токо­ла LLMNR, зап­рос которо­го перех­ватил зло­умыш­ленник.

Сле­дует убе­дить­ся в том, что 172.17.79.135 — IP-адрес зло­умыш­ленни­ка. Для это­го про­верим DHCP-тра­фик с соот­ветс­тву­ющим филь­тром dhcp. Находим DHCP-зап­рос меж­ду подоз­рева­емым IP и DHCP-сер­вером. Мы видим имя хос­та машины, которая арен­довала IP-адрес 172.17.79.135.

До­кажем кра­жу учет­ных дан­ных, про­ана­лизи­ровав SMB-тра­фик с филь­тром smb2.

Здесь мы видим нес­коль­ко NTLM-аутен­тифика­ций юзе­ра john.deacon, иду­щих друг за дру­гом за корот­кий про­межу­ток вре­мени. Пос­мотрим, какие име­на у вза­имо­дей­ству­ющих хос­тов.

Пе­рей­ди в раз­дел «Прос­мотр → Раз­решение имен» и вклю­чи «Раз­решение сетевых адре­сов». Теперь будут отоб­ражать­ся име­на хос­тов.

Мы пом­ним, что DCC01 не реаль­ный хост. Имя хос­та Kali в сети интер­пре­тиро­валось в SMB-тра­фике, поэто­му компь­ютер жер­твы Wkstn002, чьи дан­ные были укра­дены, дума­ет, что машина Kali — это хост DCC01.

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

Да­вай рас­смот­рим про­цесс получе­ния пароля из ском­про­мети­рован­ного хеша.

Вни­матель­но изу­чим тра­фик с филь­тром ntlmssp и пой­мем, что здесь при­сутс­тву­ет NTLM Relay. Аутен­тифика­ция NTLM выпол­няет­ся вза­имо­дей­стви­ем из трех пакетов:

У хеша NTLMv2 есть опре­делен­ная фор­ма, которая выг­лядит так:

User::Domain:ServerChallenge:NTProofStr:NTLMv2Response

За­пол­ним ее дан­ными из пакетов аутен­тифика­ции:

Под­став­ляем най­ден­ное в фор­му и получа­ем:

john.deacon::FORELA:601019d191f054f1:
c0cc803a6d9fb5a9082253a04dbd4cd4:
010100000000000080e4d59406c6da01cc3dcfc0de9b5f2600000000020008004e
0042004600590001001e00570049004e002d00360036004100530035004c003100
470052005700540004003400570049004e002d00360036004100530035004c0031
0047005200570054002e004e004200460059002e004c004f00430041004c000300
14004e004200460059002e004c004f00430041004c00050014004e004200460059
002e004c004f00430041004c000700080080e4d59406c6da010600040002000000
0800300030000000000000000000000000200000eb2ecbc5200a40b89ad5831abf
821f4f20a2c7f352283a35600377e1f294f1c90a00100000000000000000000000
0000000000000900140063006900660073002f0044004300430030003100000000
0000000000

Ос­тает­ся толь­ко сбру­тить получен­ный хеш, исполь­зуя Hashcat или John the Ripper, и узнать пароль от учет­ной записи.

Меры предотвращения

Ес­ли исполь­зование LLMNR/NBT-NS не тре­бует­ся в тво­ей сре­де, луч­ше все­го пол­ностью отклю­чить эти про­токо­лы в целях безопас­ности.

Но если по каким‑то при­чинам твоя орга­низа­ция не может отклю­чить LLMNR/NBT-NS, рас­смот­ри воз­можность исполь­зования сис­тем сетево­го кон­тро­ля дос­тупа (NAC) и уста­нов­ки слож­ных паролей для миними­зации рис­ка их взло­ма.

Выводы

В статье мы рас­смот­рели работу базовых атак на Active Directory, ути­литы, исполь­зуемые в этих ата­ках, а так­же необ­ходимые маяч­ки, помога­ющие быс­тро обна­ружить подоб­ные инци­ден­ты и отре­аги­ровать на них.