Гид по NTLM Relay. Захватываем NTLM-аутентификацию для Relay-атаки

Теория

NTLM — это про­токол про­вер­ки под­линнос­ти в сетях Windows NT. На самом деле он переко­чевал и в дру­гие домены, нап­ример ALD или FreeIPA. Что­бы не закапы­вать­ся глу­боко в теорию, пос­тара­юсь объ­яснить прин­цип его работы на прос­той схе­ме.

1. Кли­ент ини­циирует про­цесс про­хож­дения аутен­тифика­ции спе­циаль­ным сооб­щени­ем.
2. Сер­вер отправ­ляет некото­рое слу­чай­ное зна­чение кли­енту.
3. Кли­ент шиф­рует слу­чай­ное зна­чение сво­им сек­ретом и отправ­ляет на про­вер­ку сер­веру.

В прос­том слу­чае все понят­но: есть кли­ент, есть сер­вер, кли­ент про­ходит аутен­тифика­цию по про­токо­лу NTLM. Добавим остро­ты в нашу схе­му: теперь у нас появ­ляет­ся некий ата­кующий.

Из схе­мы мы понима­ем, что ата­кующий на сво­ей рабочей стан­ции сра­зу раз­ворачи­вает и сер­вер, и кли­ент для вза­имо­дей­ствия по про­токо­лу NTLM. Для улуч­шения вос­при­ятия пояс­ним, что про­исхо­дит на схе­ме.

1. Кли­ент (жер­тва) отправ­ляет сооб­щение о начале NTLM-аутен­тифика­ции — NEGOTIATE. Ата­кующий перех­ватыва­ет это сооб­щение с помощью сво­его сер­вера.
2. Ата­кующий отправ­ляет со сво­его кли­ента сооб­щение о начале NTLM-аутен­тифика­ции — NEGOTIATE на целевой сер­вер.
3. С целево­го сер­вера ата­кующе­му при­ходит сооб­щение со слу­чай­ным зна­чени­ем — CHALLENGE.
4. Ата­кующий отправ­ляет сооб­щение с таким же CHALLENGE, как на треть­ем шаге, жер­тве.
5. Жер­тва шиф­рует CHALLENGE сво­им NTLM-хешем и отправ­ляет сер­веру.
6. Ата­кующий перех­ватыва­ет ответ жер­твы и пересы­лает его сер­веру. Ата­кующий успешно про­ходит аутен­тифика­цию на целевом сер­вере.

Схе­ма в целом понят­на, но при про­веде­нии ата­ки быва­ют нюан­сы, про которые нуж­но знать. Во‑пер­вых, NTLM не сущес­тву­ет в ваку­уме, ее исполь­зуют раз­личные про­токо­лы, такие как SMB, LDAP или RPC. Во‑вто­рых, при про­хож­дении аутен­тифика­ции могут исполь­зовать­ся раз­ные хеши: NetNTLMv1 и NetNTLMv2. Эти хеши име­ют свои осо­бен­ности, от которых может зависеть резуль­тат про­веде­ния ата­ки.

Су­щес­тву­ет две вер­сии про­токо­ла: NTLMv1 и NTLMv2. В NTLMv1 исполь­зует­ся хеш NetNTLMv1, и он без­надеж­но уста­рел:

• Из слу­чай­нос­тей там толь­ко CHALLENGE, который при­сыла­ет сер­вер. Зна­чит, при под­делке сер­вера мож­но под­делать и CHALLENGE и, соот­ветс­твен­но, под­готовить радуж­ные таб­лицы.
• Так­же сущес­тву­ют методы вос­ста­нов­ления из хеша NetNTLMv1 хеша NT. Под­робнее об этом мож­но почитать на сай­те Crack.SH.
• От­сутс­тву­ет про­вер­ка целос­тнос­ти сооб­щения (MIC — message integrity code), которая защища­ет от Relay-атак с одно­го про­токо­ла на дру­гой.

Как мож­но догадать­ся, в NTLMv2 исполь­зует­ся хеш NetNTLMv2. В нем раз­работ­чики пос­тарались решить все проб­лемы про­токо­ла NTLMv1. Дей­стви­тель­но, мож­но ска­зать, что обра­тить этот хеш за разум­ное вре­мя хотя бы до NT пока не пред­став­ляет­ся воз­можным. Под­готовить радуж­ные таб­лицы не получит­ся, потому что к CHALLENGE добави­лась мет­ка вре­мени. А вот с Relay-ата­ками не все так однознач­но, но об этом мы погово­рим в дру­гой раз.

В этой статье будут рас­смот­рены некото­рые вари­анты зах­вата NTLM-аутен­тифика­ции для реали­зации Relay-атак. В сле­дующей мы обсу­дим непос­редс­твен­но Relay-ата­ки.

Са­мое прос­тое, что мож­но сде­лать с получен­ным NetNTLM-хешем любой вер­сии, — это подоб­рать пароль по сло­варю. Нап­ример, так:

Захват с Responder

Один из самых прос­тых спо­собов получить NTLM-аутен­тифика­цию — спу­финг с помощью Responder (этот инс­тру­мент мож­но най­ти в Kali).

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

Зах­ват хеша с Responder выг­лядит при­мер­но сле­дующим обра­зом.

Этот фор­мат при­годен для бру­та с помощью hashcat. Все зах­вачен­ные хеши Responder скла­дыва­ет в базу SQLite, рас­положен­ную по пути /usr/share/responder/Responder.db. Открыть базу мож­но сле­дующей коман­дой:

Файл кон­фигура­ции Responder находит­ся здесь: /etc/responder/Responder.conf. Эта информа­ция может при­годить­ся, если надо будет вык­лючить или вклю­чить опре­делен­ный сер­вер. На скри­не ниже изоб­ражен файл кон­фигура­ций Responder.conf.

Responder незаме­ним для реали­зации спу­финг‑атак в сетях на осно­ве Windows. Пред­посыл­кой для выпол­нения ата­ки типа NetBIOS Spoofing слу­жит наличие в сети широко­веща­тель­ного тра­фика типа NBNS, LLMNR и mDNS. Тра­фик в сети мож­но прос­лушивать с помощью Wireshark, при­меняя филь­тр NBNS.

Вмес­то визу­аль­ного ана­лиза тра­фика можем прос­то запус­тить Responder в режиме ана­лиза сле­дующей коман­дой:

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

Спу­финг‑ата­ки для зах­вата аутен­тифика­ции мож­но выпол­нять сле­дующей коман­дой:

Ес­ли ата­ка уда­лась, перехо­дим к сле­дующим шагам.

Захват NTLM-аутентификации для Relay-атак

Для выпол­нения Relay-атак удоб­нее все­го исполь­зовать ntlmrelayx из пакета impacket. В этом инс­тру­мен­те реали­зова­ны час­то встре­чающиеся про­токо­лы, с которых мож­но зах­ватить NTLM-аутен­тифика­цию. Вооб­ще, ntlmrelayx име­ет кли­ент‑сер­верную модель, и в этой статье мы как раз обсу­дим все RelayServers, реали­зован­ные в нем, и даже добавим новый, которо­го еще нет в основной вет­ке.

SMB (445/TCP)

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

1. Про­вес­ти coerce-ата­ку (при­нуж­дение к аутен­тифика­ции):
   • ано­ним­но — с помощью PetitPotam (CVE-2021-36942);
   • с учет­ной записью.
2. Исполь­зовать ярлы­ки на шарах с дос­тупом на запись:
   • ано­ним­но;
   • с учет­ной записью.
3. Стриг­герить вруч­ную.
4. Про­вес­ти MITM-ата­ку.

Coerce-атаки

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

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

При­мер исполь­зования Coercer.py показан на рисун­ке ниже.

В резуль­тате при­нуж­дения мы получа­ем NTLM-аутен­тифика­цию.

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

Ярлыки

Тех­ники с ярлычка­ми доволь­но ста­рые и дей­ствен­ные, называ­ются они slinky и scuffy. Если в сети при­сутс­тву­ют пап­ки, откры­тые на запись, обя­затель­но нуж­но положить в них ярлычки, которые будут ссы­лать­ся на IP-адрес ата­кующе­го. Как толь­ко поль­зователь откро­ет сетевую пап­ку с нашим ярлы­ком, нам при­летит NTLM-аутен­тифика­ция на SMB. Реали­зовать ата­ку мож­но нес­коль­кими спо­соба­ми:

• при помощи ути­литы PyLnk 3 (есть в Kali);
• при помощи CrackMapExec (тоже есть в Kali);
• вруч­ную.

Для экспе­римен­та выберем тре­тий вари­ант и будем исполь­зовать тех­нику, которая нем­ного отли­чает­ся от slinky и scuffy. Содер­жимое фай­ла с рас­ширени­ем .url будет при­мер­но сле­дующим:

По­ложи­ли ярлык в сетевую пап­ку, переш­ли в нее и получи­ли NTLM-аутен­тифика­цию, как показа­но на сле­дующих рисун­ках.

Пе­рехо­дим в сетевую пап­ку, где рас­положен ярлык.

Сра­зу же при­лета­ет NTLM-аутен­тифика­ция.

В при­мере хеш зах­вачен с помощью Responder, на прак­тике же мож­но запус­тить ntlmrelayx и выпол­нить Relay-ата­ку.

Триггерим вручную