Базовые атаки на AD. Разбираем NTLM Relay и NTDS dumping

NTLM Relay

Windows New Technology LAN Manager (NTLM) — это наз­вание набора про­токо­лов Active Directory, обес­печива­ющих аутен­тифика­цию в сети. Для под­дер­жки обратной сов­мести­мос­ти NTLM исполь­зует­ся пре­иму­щес­твен­но в сис­темах, не под­держи­вающих аутен­тифика­цию Kerberos.

Ког­да зло­умыш­ленник перех­ватыва­ет сетевой тра­фик с помощью ата­ки LLMNR Poisoning, он может так­же попытать­ся рет­ран­сли­ровать перех­вачен­ное сооб­щение для аутен­тифика­ции в той или иной служ­бе от име­ни жер­твы.

Та­кая прод­винутая вер­сия LLMNR-отравле­ния будет называть­ся ата­кой NTLM Relay, она соот­носит­ся с под­техни­кой T1557.001 в MITRE ATT&CK. Воз­можность такой ата­ки обус­ловле­на тем, что сам NTLM не обес­печива­ет безопас­ности сеан­са.

Ути­лита ntlmrelayx из набора Impacket — инс­тру­мент, которым чаще все­го поль­зуют­ся для подоб­ных атак.

Reaper

Ла­бора­тор­ная работа Reaper из раз­дела Sherlocks от Hack The Box поможет на прак­тике разоб­рать инци­дент, свя­зан­ный с этой ата­кой.

В опи­сании лабора­тор­ной рас­ска­зыва­ется о подоз­ритель­ном вхо­де в сис­тему, на который необ­ходимо сроч­но обра­тить вни­мание. Под­робнос­ти зак­люча­ются в том, что IP-адрес и имя исходной рабочей стан­ции не сов­пада­ют.

Для опре­деле­ния рет­ран­сля­ции NTLM в сети понадо­бят­ся жур­налы сетевой телемет­рии и ауди­та вхо­да в сис­тему. Под­ход к обна­руже­нию NTLM Relay дос­таточ­но необы­чен, пос­коль­ку тре­бует сопос­тавле­ния IP-адре­сов с име­нами хос­тов. В круп­ных кор­поратив­ных сре­дах будет тяжело сле­дить за этим, так как спи­сок IP-адре­сов дос­таточ­но боль­шой. Телемет­рия сети в таком слу­чае силь­но упростит опре­деле­ние ском­про­мети­рован­ного хос­та.

Reaper пре­дос­тавля­ет дамп сетево­го тра­фика ком­пании, с его помощью мож­но уста­новить основные конеч­ные точ­ки в виде внут­ренних IP-адре­сов.

Прос­мотрим ста­тис­тику .pcap-фай­ла, опре­делим внут­рикор­поратив­ную сеть и убе­рем из подоз­рева­емых раз­личные широко­веща­тель­ные адре­са и шлю­зы (IP-адре­са, закан­чива­ющиеся на .1, .2 и .255).

По­лучить име­на хос­тов мож­но с исполь­зовани­ем служ­бы имен NetBios и одно­имен­ного филь­тра в Wireshark — nbns.

Сра­зу же наб­люда­ем неболь­шой спи­сок имен хос­тов:

1. FORELA-WKSTN001 для 172.17.79.129.
2. FORELA-WKSTN002 для 172.17.79.136.
3. Не­извес­тное устрой­ство для 172.17.79.135.

До­бавим филь­тр для SMB-тра­фика, вхо­дяще­го и исхо­дяще­го от подоз­ритель­ного хос­та: smb2 and ip.addr == 172.17.79.135. Пока что для нас это машина зло­умыш­ленни­ка, работа­ющая по прин­ципу MITM.

Вид­но, что поль­зователь arthur.kyle учас­тво­вал в про­цес­се аутен­тифика­ции с подоз­ритель­ного IP-адре­са. Так­же мож­но наб­людать IP-адрес Wkstn002. Судя по тра­фику, поль­зователь явля­ется учет­кой как раз это­го хос­та, чьи дан­ные и были укра­дены.

В сле­дующем потоке пакетов мож­но заметить, что аутен­тифика­ция учет­ной записи поль­зовате­ля arthur.kyle осу­щест­вля­ется с двух раз­ных компь­юте­ров (один — легитим­ный, вто­рой — MITM).

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

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

От­метим нес­коль­ко инди­като­ров того, что ата­ка NTLM Relay была про­веде­на успешно:

• иден­тифика­тор безопас­ности: NULL SID;
• LogonGUID име­ет зна­чение NULL;
• не­сов­падение в име­ни рабочей стан­ции и IP-адре­се источни­ка (на исходной рабочей стан­ции ука­зано WKSTN002, а в качес­тве IP-адре­са видим 172.17.79.135);
• про­цесс вхо­да: NtLmSsp.

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

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

По воз­можнос­ти необ­ходимо отклю­чить аутен­тифика­цию NTLM и исполь­зовать более надеж­ные про­токо­лы, такие как Kerberos. Что­бы исклю­чить перех­ват аутен­тифика­ции через NTLM, во всем домене необ­ходимо при­нуди­тель­но исполь­зовать под­пись SMB. Такая под­пись защища­ет сооб­щения, переда­ваемые меж­ду кли­ентом и сер­вером во вре­мя свя­зи NTLM, пре­дот­вра­щая перех­ват сооб­щений про­вер­ки под­линнос­ти.

NTDS dumping

Хра­нили­ще информа­ции о доменах в служ­бе катало­гов Active Directory реали­зова­но в фай­ле NTDS.dit, который рас­положен по умол­чанию в дирек­тории %SystemRoot%\ntds\ на кон­трол­лере домена. Этот файл содер­жит важ­ные дан­ные о домене, вклю­чая хеши паролей поль­зовате­лей, что дела­ет его прив­лекатель­ной целью для атак.

Что­бы получить дос­туп к фай­лу NTDS.dit, зло­умыш­ленни­ку необ­ходимо обла­дать адми­нис­тра­тив­ными пра­вами в сис­теме. Если он получит дос­туп к кон­трол­леру домена, то смо­жет извлечь файл NTDS.dit вмес­те с дан­ными из клю­ча реес­тра HKEY_LOCAL_MACHINE\SYSTEM, содер­жащего все необ­ходимые све­дения для дешиф­ровки дан­ных NTDS.dit.