Windows Server 2008 Active Directory
We know local user accounts are stored in SAM file and we have previously demonstrated on PASS THE HASH article how to dump/extract use abuse these password equivalent hashes.
In this article we demonstrate/describe some of the attack techniques to gain access to a windows domain controller the techniques to copy NTDS.dit database using built-in tools “living off the land “ the use of WMI, VSSADMIN , PowerShell. A.KA Microsoft post exploitation framework J
Active directory data is stored in the Ntds.dit ESE database file. Two copies of Ntds.dit present in separate location on a given domain controller %SystmRoot%\NTDS\ Ntds.dit & %SystemRoot%\System32\Ntds.dit .
These are exclusive locked file meaning they cannot be copied simply using click right and copy to the destination will not work as these files have in use with set of permissions attribute on.
This of course doesn’t mean we can’t using Build-in tools VSSADMIN or PowerShell to make a copy of the Ntds.dit file locally and infiltrate to our attacking machine for closer offline analysis and password extraction. But of course we need to gain access to the domain controller with local administrative privilege or domain admin in order be able to copy the AD server crown jewels .
Without further ado let’s get to hacking into breaking windows 2008 active directory
Our attacker IP address is set to 192.168.1.12
Our target is windows 2008 active directory installed 192.168.1.26
We already have an administrative account (Credential theft or MS14-068 Kerberos prive escalation
Windows Built-in tools – Welcome to VSSADMIN .
VSSADMIN is essentially shadow volume copy feature since windows Vista that allows an administrator or “hackers” to take friendly snapshot backups files even when the files are currently in use J J J that’s how I feel when I login to a Domain controller…
You already figured out my next move – Yes I will use VSSADMIN built-in tool to copy NTDS.dit and SYSYEM file from the domain controller save it to the disk for remote exfiltration. You may ask why we need SYSTEM file. Great question, SYSTEM file contains what knows as Boot secret key which used at the windows boot startup for decryption
Quick Scan against domain controller identified port SMB on 445 and Port 88 kerberos authentication protocl .
Figure 1 Port scan identified number of open ports from our attacking machine
Credential theft – We use Rdesktop to login to the remote server 2008 AD.
Figure 2 with administrative access we login to the remote Target windows 2008 server
vssadmin create shadow /for=c: to creaate a light snapshot
Figure 2 vssadmin built-in windows tool to create a fast snapshot
Next we use copy command and copy the ntds.dit file to our \windows\ntds\ntds.dit location
Figure 3 snapshot of ntds.dit now successfully copied to the c:\ drive
We also need a copy of SYSTEM File to decrypt the NTDS.dit objects
Figure 3 SYSTEM file is copied to c:\ location we need that file to decrypt the ntds file
Now that we have a copy of NTDS.dit and SYSTEM file waiting for final exfiltration to our attacking machine for offline decryption
We use Mount -t cifs to connect the target remote machine specefying the username and password and associate /mnt/
Figure 4 C$ is mounted to /mnt drive to copy ntds.dit and SYSTEM file for extraction
We use esetUtil.py to look at certain table and grep particular hashes from the NTDS.dit file
Figure 5 we use esentuil to grep datatable contains hash objects
Next we we use extract datatable from the ntds.dit and pipe it to the output.txt file
Figure 6 Impdump.py we point SYSTEM file and output extract and pipe it to the hashes.txt file
Password equivalent hash extracted from windows active directory server
Figure 7 Windows NTLM password hashes
So there we are , NTLM password hashes for PTH & offline decryption
We got hacked and yes this was sophistictaed attack
Long live pass the hash.
In cryptanalysis and computer security PASS THE HASH is security hacking technique that allows an attacker or researcher to authenticate to a windows remote service or service by using underlying LM LanMan or NTLM of the users password, instead of requiring the associated correct plaintext password as is normally the case .
LM LAN MANAGER /NTLM HASH
Microsoft Windows Operating Systems store hashed user password in SAM Security Account Manager. In order to stop and deter offline password attacks against the database, Microsoft Introduced SYSKEY which will partially encrypts the SAM file. An attacker will not be able to decrypt SAM file without SYSKEY and SYSTEM File.
Microsoft based operating system up to windows 2003 store two separate authentication password hashes; LAN MANAGER (LM) which is based on DES DATA ENCRYPTION STANDARD based on symmetric block key and NTLM NT LAN MANAGER based on MD4 yes Message digest 4 hashing.
LM LAN MANAGER provide little or no security and known to be extremely weak for the following reasons:
Passwords that are longer than seven characters are split into two strings each is hashed separately .The password is converted to upper case before begin hashed. The LM/NTLM hashing system does not include salts making brute force rainbow table attacks possible.
From windows Vista on , Windows operating system by default disables LAN MANAGER LM and uses NTLM which supports all Unicode characters, and does not limit stored passwords to two 7 character but of course NTLM hashes stored in SAM database are not salted.
The SAM database cannot be copied while the operation system is running even though the windows kernel keeps an exclusive file system lock on the file, however PowerShell allow direct interactions with exclusive locked privileged files. There are many other techniques to extract windows password hashes , such as DLL injection against LSASS Local Security Authority Subsystem Service which is core windows authentication package.
After a user logs on to windows operating system, a variety of the account credentials are generated and stored in the LSASS Local Security Authority Subsystem Service, Process in memory. This meant to allow the SSO (Single Sign On) ensuring a user isn’t prompted each time resource or services is requested. The credential data depends on the environment and configurations. This may include Kerberos TGT Ticket Granting Ticket, NTLM password hash, LM password hashes, in some instances if the user password is less than 15 characters, depending OS version and Patches level it might be possible to extract clear-text passwords (WDigest and SSP Authentications)
While it’s you can stop/prevent windows system from creating LM hash in local SAM file however this doesn’t prevent system from generating LM hash in memory. From windows vista and windows server 2008 LM is no longer generated for users unless explicitly enabled by users.
WDigest & Clear-Text Password?
Microsoft introduced Wdigest.dll in the windows XP operating system, the protocol is designed for HTTP Hypertext Transfer Protocol and Simple Authentication Security Layer (SASL) which mean passwords are not encrypted when sent to a server leaving them vulnerable to man in middle attack, at the same time windows stores the password in memory for convenience of the user when they login to their local workstation.
When Microsoft release windows 8.1 they added a security features that mitigated ability of tools like WCE , mimikatz to dump/extract clear text credentials from LSA memory .
In 2014 Microsoft backported those security fixed (http://support.microsoft.com/kb/2871997 for windows operating system prior to 8.1 however because of legacy OS and WDigest is used by many products (IIS) Microsoft left the Wdiget providers enabled which is why it’s still possible to use mimikataz module to obtain clear-text passwords prior to windows 8.1
After you install this security update, you can control how installed WDigest credentials can be saved by using a registry setting. To prevent WDigest credentials from being stored in memory, a Group Policy setting can be applied to the UseLogonCredential registry entry under the following subkey:
If the UseLogonCredential value is set to 0, WDigest will not store credentials in memory.
If the UseLogonCredential value is set to 1, WDigest will store credentials in memory.
Windows 10 enterprise , Security Provider registry doesn’t contain UseLogonCredential entry
Figure 1 Default to windows 10 with no UserLogonCredential entry
We simply force UseLogonCredential entry set to 1 forcing registry to store clear text password in the memory ( NT/Authority credentials required)
Figure 2 creating UseLogonCredential in order to force user credentials stored in clear text.
UseLogonCredential entry created in SP Security Providers registry Under WDiges . The value is set to 1 stores the credentials as clear text in memeory
Figure 3 UseLogonCredential set to 1 which allows an attacker to extract clear text password direcrly from memory
Mimikatz powershell password dump with WDigest set to 1 allows clear text password
Figure 4 WDigest UseLogonCredential set to 1 allowing credential to be extracted
Mimikatz PowerShell password dump with WDigest set to 0 prevents clear-text password extraction
Figure 5 UseLogonCrdential set to 0 prevents user not to store password in memeory
WDigest Provider UserLogonCredential Registry REG_DWORD set to 0X0 mitigate against clear-text password extraction
Figure 6 corroborating UseLogonCredential is not set to 1 to fix the issue
Pass the hash (Local System)
PTH requires local administrators’ privilege that’s because local admin has Debug privilege assigned to it. Below we demonstrate PTH and open two cmd.exe consoles, one as an administrator and the other one as normal user
Cmd.exe run as Administrator has debug Privilege permission
Figure 7 Whoami /all shows administrator as part of Debug priv permission
Authenticated user with no administrator privilge
Figure 8 authenticated none privileged user with no debug privilege
There are different techniques and ways to extract password hashes from local windows operating system. We use Mimikatz for password extractions
Privilege debug is set to ok however the Lsadump::sam failed to work as mimikatz requires to have NT/Authority SYSTEM privilege to extract password hashes from the system
Figure 9 token::whoami shows Zane as normal authenticated user
How do we elevate NT/Authority SYSTEM user in order to have appropriate permissions to access windows secret hives . We use SysInternls tools to elevate permission Local System
psexec -s -i -d cmd.exe
System internal tools to elevate local system
Figure 10 nt authority\System priv
Alternatively we can elevate within the mimikatz request nt authority/system
Figure 11 token::elevate delegation
lsadump:sam to dump NTLM password hash from SAM file
Figure 12 Mimikatz to extract the SAM hash database
sekurlsa::pth /user:Administrator /domain:locahost /ntlm:9cf1735cff285fdcc130125cee
Figure 13 Sekurlsa obtained new cmd.exe prompt with admin token (Mimikatz)
Dumping windows live memory
One of the tools i like to use during security pentest engagement is ProDump a command-line utility who’s primary purpose is monitoring an application for CPU spikes and investigating crash dumps but we obviously we interested to perform the memory dump of the core windows authentication process LSASS.exe in order to do some offline analysis using mimikatzzzz
But first we need to move ProcDump to the target victim workstation?
There are number of techniques to transfer files to the victim target workstation, but my preferred way PowerShell since the target is windows workstation
Basic PowerShell script to copy ProcDump.exe from our attacking machine and rename it on the disk hacker.exe using System.Net.WebClient cmdlet to do clean transfer to our target destination
Figure 14 System.Net.WebClient cmdlet powershell file transfer
Next we attach the ProcDump to the lsass.exe in order to dump extract clear text password hashes.The -accepteula parameter is to accept EULA ,this its necessary to use it other wise you will get stuck in the remote console. We perform the memory dump for offline clear text and password hash extractions
hacker.exe -accepteula -ma lsass.exe
Figure 15 we use ProcDump to dump live memeory .
Next we use mimikatz module to dump the hashes from ProcDump lssas.dmp file which contains the administrator password hashes and clear text passwords.
Figure 16 Password hash dumped from procdump .dmp file
- Use LAPS Local Administrators Password Solutions to mitigate Lateral movements
- Switch off Privilege debug permissions – You don’t need it
- Upgrade to windows 10 with device guard enabled