sitemapFlight

AD box on HTB.

Enumeration:

Port Scanning:

Nmap:

As always we are going to start with nmap scan:

We are dealing with another AD machine, and this time we have Apache web server running on port 80.

Also if take a look at the clock skew we will see it is too great, so I will use ntpdate to sync the time with the target machine:

And I will add the target host and domain and corresponding IP to the hosts file:

HTTP (80):

Lets start by opening up flight.htb with firefox, and meanwhile run gobuster and ffuf in the background:

Nothing really interesting, only a static web page.

Lets find out what ffuf has found for us:

A lot of false positives, so we will filter on the size:

I will add this subdomain to the hosts file:

Exploitation:

LLMNR Poisoning:

Now lets open it up with firefox as well:

If we take a closer look we will find some buttons which redirect us to index.php?view=pagename.html, Lets test this out:

Usually if you find something similar you can test for multiple vulnerabilities, such as Path Traversal, LFI, RFI, etc.

Also we can confirm the backend language is PHP.

Lets see if we can access internal files:

Indeed we can, how about accessing external resources like our python web server:

Another interesting thing we can test for, that is LLMNR poisoning:

LLMNR poisoning: Where you trick a victim (in this case the service account running this web server), into authenticating or sending their authentication hash to us (we capture it with responder or relay it to do other stuff), by abusing llmnr multicast query functionality.

So I will start responder to listen and capture any NTLM hashes sent to us:

If we take a look at responder again:

Lets save that ntlmv2 hash into a file, and attempt to crack it with hashcat:

Now we have valid domain credentials.

We can now enumerate the shares with netexec, and impacket-smbclient:

Nothing useful.

Also I did not find anything useful in BloodHound data.

Username Enumeration & Password Spray:

circle-info

Always when you acquired a new password, try spraying it on all users, but keep in mind account lockout.

Now it is the time for password spray:

We have another user with the same password.

NTLM Theft:

Check the shares again:

We have WRITE permissions over the Shared share.

What we can do when we have write permissions over a share is to upload a malicious file (exe, ps1, lnk, docx, etc), and wait for any user to see it and run it.

There is a wonderful tool called ntlm_theft written in pyhon could help us in this phase, by creating multiple files that if a user tried to open one of them his ntlmv2 hash will be sent to our listener (responder):

Not all files were accepted to be uploaded, maybe there is some restriction to some files, but one of the files that worked for me was desktop.ini, so lets upload it via smbmap:

And wait again while responder running:

After like a minute we captured a new user's ntlmv2 hash:

I will try to crack it:

Shell as c.bum:

Lets have a look at the shares again:

Now we have WRITE permissions over the Web share which contains the web server files, so we can upload a PHP (The web server backend language as we have seen earlier is PHP) web shell or reverse shell and have an interactive shell on the box:

I will write a simple PHP code:

And upload it:

Lets navigate to the website, and try to open that file from there:

Here we have command execution, lets get our PowerShell cradle ready:

I will start a python web server to host that shell.ps1 file, also start a netcat listener in another terminal:

Now I will upload it to the target system and execute it in memory:

We will see it hangs, because we have a reverse shell:

Post-Exploitation:

Local Enumeration:

After doing some enumeration, we will find inetpub directory which has files for another web server (IIS):

Also if we searched for internal ports:

We will notice that WinRM is running internally which was not exposed in our Nmap scan also strangely port 8000 which seems to be the internal web server.

We do not have write permissions on those folders, but c.bum has:

So lets get a shell as c.bum, we can either do pivoting to get access to winrm port, or get a full interactive shell with RunasCs.exe.

I uploaded RunasCs.exe to the target system, and run it as c.bum user, before that start a new netcat listener in another terminal:

Port Forwarding:

I will upload chisel or ligolo or what ever tunneling tool to perform port forwarding, so we can access that internal port (8000):

Lets have a look at the server again:

So we established port forwarding, with firefox lets open localhost on port 8000:

Now with another shell as c.bum, I will upload (/usr/share/webshells/aspx/cmdasp.aspx) file (since the server running is IIS, and the framework is asp.net):

Navigate to that webshell from within firefox:

We are IIS default application pool user.

Lets get a reverse shell using the same PowerShell cradle above:

Here we have a shell as defaultapppool:

Whoami /all:

We have SeImpersonatePrivilege which allows us to impersonate another user.

And we can abuse it with a variety of tools such as printspoofer or one of the potatos, I will upload and use GodPotato, and we have also to upload netcat:

Start another netcat listener and run GodPotato:

We are system on the domain controller.

Here is the flags:

After I solved that box, and seen some writeups online I found another way we can take advantage of to escalate our privileges, by abusing the privileges of defaultapppool user.

As mentioned in this Microsoft article:

The good news is that application pool identities also use the machine account to access network resources.

So as defaultapppool we can use the machine account to do some stuff, lets confirm this:

And run for example net use //10.10.16.4/share/doesnotexist:

Here we can confirm that, that user uses the machine account to access network resources.

There is a module in Rubeus.exe called tgtdeleg that allows us to abuse the Kerberos GSS-API to retrieve a usable TGT for the current user without needing elevation on the host, so we can grab the machine account TGT, upload Rubeus to the target machine and run it as the defaultapppool user:

Here we got the TGT ticket of the G0 (machine account), we can pass it to Rubeus, or convert it to ccache format for further usage.

I will save it to a file, and decode it from base64, then convert it to ccache with impacket-ticketConverter:

Now we can export that ticket so any tool we tell it to use kerberos, it knows from where it take credentials to perform such a thing:

Domain controller by default has dcsync rights to synchronize its data with other domain controllers if exist.

With impacket-secretsdump and that ticket we can perform dcsync:

Here we have the administrator secrets, and we can authenticate to the target machine with those hashes:

Last updated