pivotapi

One of my favourite AD Machines!

Gaining Access

Nmap scan:

$ nmap -p- --min-rate 5000 -Pn 10.129.228.115
Starting Nmap 7.93 ( https://nmap.org ) at 2023-06-20 23:06 +08
Nmap scan report for 10.129.228.115
Host is up (0.012s latency).
Not shown: 65516 filtered tcp ports (no-response)
PORT      STATE SERVICE
21/tcp    open  ftp
53/tcp    open  domain
88/tcp    open  kerberos-sec
135/tcp   open  msrpc
139/tcp   open  netbios-ssn
389/tcp   open  ldap
445/tcp   open  microsoft-ds
464/tcp   open  kpasswd5
593/tcp   open  http-rpc-epmap
636/tcp   open  ldapssl
1433/tcp  open  ms-sql-s
3268/tcp  open  globalcatLDAP
3269/tcp  open  globalcatLDAPssl
9389/tcp  open  adws
49667/tcp open  unknown
49677/tcp open  unknown
49678/tcp open  unknown
49695/tcp open  unknown
49706/tcp open  unknown

FTP -> AS-REP Roast

Whenever there's an FTP port open, we can check for anonymous access, and it works for this machine:

There seems to be PDFs within this folder. I downloaded the README.txt file first.

Alright, we can change to binary mode and then download all of these files to our machine:

I viewed all the PDFs, which didn't include anything useful. Next, we can use exiftool to view the metadata of each file in case there's something like a vulnerable version of PDF reader indicated. Some of them contained username fields:

I put all the usernames into a single file, and also took note of the domain used here. Here are all the users:

The first username might need some permutation, so I included some combinations in my username list. We can then use impacket-GetNPUsers since we have a username list:

This works! The hash can be easily cracked using john.

We now have credentials!

SMB + Bloodhound

I tried to view the shares, but we don't have access to anything special:

We can take a look at the shares anyway. The NETLOGON share contained a HelpDesk file:

Then, we can take a look at these files:

I transferred this to my Windows VM for some reverse engineering.

I also used bloodhound-python to collect information about the domain for me. The first time I ran it, it generated this error:

So we have to add another subdomain to our /etc/hosts file to enumerate properly. Then, we can run the command again:

Afterwards, start neo4j and bloodhound. The names of the box are in Spanish, so take note of that. However, the bloodhound graph showcased nothing of interest for our current user and we have no privileges. When looking at all domain users, we find a svc_mssql user present:

The nmap scan earlier shows that port 1433 is indeed open. Checking this user's group memberships shows that it is part of the WinRM group, which is in turn part of the Remote Administration Group (I think).

The steps are rather clear, we need to somehow reverse engineer that .exe file to gain a shell as the svc_mssql user.

Reverse Engineering

I transferred this over to my Windows VM. Running it seems to do nothing oddly:

I took a look at the logs created using Sysmon, and found some weird commands being executed. Firstly, this thing created a .bat file:

Afterwards, it used it ot do something else:

It also seems that this file is being destroyed by the binary after running. To catch this file, we would have to use a Powershell infinite loop that would keep checking for both directories and the .bat file being created, and then read the output of it.

It was rather difficult to catch this .bat file for some reason, and I took a lot of runs before being able to. I used a simple Powershell loop that reads the file:

Afterwards, I was able to copy the file and view its contents. It's rather long, so I'll truncate it a bit:

Since we have this .bat file, we can simply execute it after using set to change our username temporarily. We can also remove the del commands to preserve the files:

This would create the files that we want (after taking a few minutes). Afterwards, we would get a monta.ps1 and a restart-service.exe file on our machine. Also, it detects this as raare, so make sure to include the needed exclusions from Defender.

Afterwards, we can reverse engineer the restart-service.exe file. Running it just produces this ASCII art:

It doesn't generate any logs of interest in Sysmon, so we have to delve deeper into the processes spawned. In this case, I used API Monitor to do this. When I ran the binary within API monitor, it generated quite a lot of stuff. I disabled the filter to view everything:

I tried searching for 'Password' and found it here!

MS-SQL Access -> PrintSpoof Fail

Now that we have creds for svc_oracle, let's try to access the database as it. However, it appears that this svc_oracle user is not present anywhere within the domain users, and only svc_mssql is.

The password was contained both oracle and 2010. I was stuck here for a long time, and looked at a guide. Turns out we just need to change the password to have mssql instead of oracle and 2020 instead of 2010 (which I felt was an unecessary step for this machine at this point).

Anyways, we can then access the database as the sa user.

Next, we can check whether we have xp_cmdshell access.

We do! I looked around the file system to find some interesting stuff. First, I checked the users:

I cannot access any of these files as my current user, which is quite annoying. The next thing to check would be our privileges, since we are in fact, a service account user. This means that we can potentially have the SeImpersonatePrivilege enabled, which we do!

Because this is enabled, we can use PrintSpoofer.exe to execute commands. Problem is, I am not able to transfer the binary to the machine since it complains that there's no route to my machine. So, we have to use base64 encoded strings to do this.

When googling for MSSQL Shells with upload capabilities, I came across this:

Logocode-snippets/mssql/mssql_shell.py at master · Alamot/code-snippetsGitHub

This shell works after changing the credentials:

Now, we can upload PrintSpoofer.exe to the machine.

However, this just doesn't work for some reason. I think the author must've patched the usage of PrintSpoofer, because in theory it would lead to an automatic root shell.

Port Forward -> WinRM Fail

I noted that it was not possible for me to connect back to my host, probably due to firewall rules blocking inbound WinRM connections. We can read the rules using Get-NetFirewallRules. Again, it's all in Spanish.

In this case, we would have to proxy our traffic using the MSSQL instance somehow. Googling for MSSQL Proxy leads me to this project:

LogoGitHub - blackarrowsec/mssqlproxy: mssqlproxy is a toolkit aimed to perform lateral movement in restricted environments through a compromised Microsoft SQL Server via socket reuseGitHub

We can download the compiled DLLs and modified mssqslclient.py file onto our Kali machine. Then, we can use our UPLOAD shell to upload the reciclador.dll file:

Then we can install the assembly.dll file (which has been renamed).

Then we can runthe same command using -start -reciclador 'C:\Windows\Temp\reciclador.dll.

This would open a listener port on our port 1337, which is supposed to let us conenct via WinRM in, but I kept getting this error when running it.

The connection kept cutting out when I connected via this method, so this again, doesn't work.

Remote Powershell -> Keepass Crack

My last option was to use base64 encoded Powershell commands to run stuff on the machine (at this point I was looking at a writeup). 0xdf used this in his Unintended Methods part of his writeup:

I used his command to get the KeePass database out.

Afterwards, we can crack this database password using keepass2john.

Then we can access the database:

Then, we can finally access the user here:

Privilege Escalation

Back to Bloodhound

Now that we have a new user to play with, we should take a look at the Bloodhound output again. Here, we find that our current user has GenericAll privileges over some other users:

Only the Dr.Zaiuss has a file in C:\Users, so that's the next step. We also find that this user has control over superfume, which in turn is part of the Developers group:

Those are the next obvious steps.

ForceChangePassword

We can upload PowerView.ps1 via scp to the current user's directory, and then run these:

Since dr.zaiuss is not part of the SSH group, we have to port forward via ssh to access that user using evil-winrm.

Then, we can upload PowerView.ps1 and run the same commands with superfume this time. Since superfume is also not part of the SSH group, we can just use evil-winrm again:

Developer RE -> Creds

Within the main C:\ directory, there's a Developers file:

superfume is part of the group, so we can access and read the files within it:

We can take a look at the .cs program:

It appears we have another Reverse Engineering to do. There are some credentials being passed around within this program. In this case, we can grab this binary and transfer it back to our Windows machine for some reverse engineering.

Since they provided the source code in C#, I opened this binary up in dnSpy. In this, we see the completed program with the correct cipher:

We can set a breakpoint at the Console.WriteLine function, which is right after the Decrypt function. Then, within the local variables, we would see this part here:

The array variable contains the decoded password, and we can convert all of this to text.

We can then grab access to the user jari.

ForceChangePassword -> Account Operators

This new user is part of a new group:

Going back to Bloodhound, we see that the new user jari has ForceChangePassword privilege over two other users, with one being a bit more important than the other:

The gibdeon user is part of the Account Operations group (after translation). We can first reset the user's password using the same commands as the other password resets gibdeon user is not part of either SSH or WinRM groups, so we probably use remote Powershell scriptblocks to abuse this.

The Account Operators group has GenericAll privileges over the LAPS READ group, and can also create new non-administrator accounts within the domain (in-built AD privilege).

Since we basically have access to all groups in this domain, we can just add our jari user to both LAPS READ and LAPS ADM.

LAPS Read

First, we have to import a PSCredential object in order to execute commands as gibdeon from our jari shell:

Afterwards, we can add ourselves to the LAPS READ and LAPS ADM groups.

Then, we can read it:

Afterwards, we can simply evil-winrm into the administrador account. Because this box is in Spanish, the name also differs.

The root.txt flag is located within C:\Users\cybervaca\desktop. Doing CRTO and reading about Windows Auth helped a lot for this machine. Rooted!

PreviousMultimasterNextSekhmet

Last updated