APT
Challenging! Did with the help of a writeup.
Gaining Access
Nmap scan:
$ nmap -p- --min-rate 5000 10.129.96.60
Starting Nmap 7.93 ( https://nmap.org ) at 2023-06-22 14:58 +08
Nmap scan report for 10.129.96.60
Host is up (0.0095s latency).
Not shown: 65533 filtered tcp ports (no-response)
PORT STATE SERVICE
80/tcp open http
135/tcp open msrpcThis is supposed to be an AD machine, so seeing such few ports is kinda new.
Port 80
Port 80 has a corporate page of some hosting service company thing:
Most of the text is just placeholder text. I added gigantichosting.com to my /etc/hosts file. Running gobuster and wfuzz for directory and subdomain searches return nothing of interest. I think we'll come back to this later.
Port 135 RPC
The only other lead was this port. impacket-rdcdump can be used to enumerate it:
This would return a bunch of information, 266 endpoints to be specific. From the output, we can see loads of stuff like the processes running and what not. Amongst all of this, there were a lot of UUIDs given out like this:
I wasn't sure what to do with this information. I also could not connect via rpcclient, and there was no credentials I had. I spent quite a bit of time stuck here, and went to research more about RPC and its services.
RPC Reading -> IPv6 Address
Here's a resource that I used to read more about RPC.
Turns out, the ports 135-139 all have different purposes depsite being grouped under the SMB/RPC umbrella. Port 135 itself has specific services that are being used, and each of them sort of have their own 'interface'.
My question was, why is it that the only services picked up by nmap are port 80 and 135? From the output of impacket-rpcdump, there were loads of services in use like dns.exe and what not.
I googled a bit more about RPC and found someone else's pentesting notebook that had a command I did not recognise.
A tool called IOXIDResolver.py was being used.
I took a look at 0xdf's writeup (because I really didn't know what was going on) and found that he used the same tool as well. The trick here is that the 'AD' portion is listening on IPv6 instead of IPv4, and that since RPC was open on IPv4 we can resolve the addresses for the interfaces of services enumerated with rpcdump.
I ran the above script and found a new IP address:
We now have 2 more addresses!
Re-enumeration -> SMB
I ran an nmap IPv6 scan (using -6) and found new ports:
Now this was looking more AD-like. Remember that this is an IPv6 address, so most tools I tried just didn't work. crackmapexec was one of them that worked:
We have access to a backup share using null credentials. smbclient supports IPv6, and we can use that to login and view the files:
The backup.zip is password protected, so we can first zip2john it and then john it.
Interesting. We can use secretsdump.py to get all the hashes out, and there were A LOT. A few thousand to be specific.
There was no way the machine had 2000 users, so we need to first find out which are the valid users.
User Brute -> Hash Brute
We can first use grep to retrieve the users present in the file. Each user's entry ends with :::, which we can use grep to retrieve and then awk to print out the first field.
I also added the following entry to my /etc/hosts file:
Afterwards, we can brute force this using kerbrute as per Hacktricks:
So we do have one valid-user present. The only problem is now we need to find the correct hash for this user, of which there are 2000 hashes...
We can still do roughly the same thing to get the hashes from the dump file, and then use crackmapexec to test the hashes.
The machine has some type of protection in place preventing brute force, since I cannot run two brute force scans back to back (kerbrute and then crackmapexec for example) without it closing my connection and blocking my IP address.
Anyways, we will eventually find the right hash:
PTH Reg Query
We cannot use this hash to evil-winrm in unfortunately, as it seems this user is not part of the Remote Management Group. However, this does not stop us from retrieving tickets as the user. We can use getTGT.py to request for a TGT.
Also, we can use this hash to connect to RPC or view the registry using Impacket tools. Digging around the Impacket suite of tools, we find impacket-reg which can be used to query the registry.
The hardest part was finding the name of the registry to query. Most examples online used HKLM\\SOFTWARE or HKCU\\SOFTWARE. Our target should be the current user registry. It was this article that introduced me to HKU being another name:
This works with reg.py:
Then, we can evil-winrm in:
Privilege Escalation
Finding Defences
I tried to run winpeas.exe, but it seems that AMSI and what not is present on the system:
Windows Defender was also active on this machine because my winpeas.exe was deleted after.
NTLMv1 -> Steal Hash
I enumerated this machine manually because Defender was present. There was a Powershell History file present:
This command basically states that NTLMv1 is enabled on this machine instead of the more secure NTLMv2. This opens up the potential for NTLM stealing.
We just need to somehow use a service run by the Administrator to steal the hashes. Turns out, Windows Defender here can be used:
We now have an NTLMv1 hash! Googling how to crack this leads me to this site:
This would convert it to an NTLM hash that we can pass along, of which we get d167c3238864b12f5f82feae86a7f798. Since this is the machine account APT$, we can perform a DCSync attack on the domain.
Afterwards, we can use this hash to evil-winrm into the machine.
A unique machine that was rather difficult for me. I definitely needed to use a writeup for this one, or I would still be stuck at the RPC part. Rooted!
Last updated