Dump Windows password hashes efficiently

link:http://brk.dis9.com/dump-windows-password-hashes-efficiently.html

Slightly modified definition from Wikipedia:

“

The
Security Accounts Manager

(SAM) is a registry file in Windows NT and later versions until the most recent Windows 7.
It stores users’ passwords in a hashed format (in LM hash and NTLM hash)

. Since a hash function is one-way, this provides some measure of security for the storage of the passwords.
Generally, dumping operating system users’ password hashes is a common action following a compromise of a machine: getting access to the password hashes might open the doors to a variety of attacks including, but not limited to, authenticate with the hash over SMB to other systems where passwords are reused, password policy analysis and pattern recognition, password cracking, etc.

Depending on the type of access that you have got to the target, you can retrieve the password hashes from SAM in different ways.
Physical access
Given physical access to the system, typically during a laptop assessment or a successful social engineering engagement, the preferred way to safely dump the password hashes is to power off the machine, enter the BIOS menu at power-on time, review the boot order to allow boot from the optical drive and USB drive before local hard-disk, save the settings and reboot the system with your favourite GNU/Linux live distribution CD or USB stick. Two widely known tools to dump the local users’ hashes from the SAM file, given the Windows file system block file, are bkhive and samdump2:

bkhive

- dumps the syskey bootkey from a Windows system hive.

samdump2

- dumps Windows 2k/NT/XP/Vista password hashes.
These tools are generally included in many GNU/Linux live distributions. If they’re not, make sure to bring a copy of them with you.
Usage:
‘

# bkhive
bkhive 1.1.1 by Objectif Securite

http://www.objectif-securite.ch

original author: [e-mail]
‘

Usage:
bkhive systemhive keyfile
‘

# samdump2
samdump2 1.1.1 by Objectif Securite

http://www.objectif-securite.ch

original author: [e-mail]
‘

Usage:
samdump2 samhive keyfile
Example of retrieving the SAM hashes from a Windows partition /dev/sda1:
‘

# mkdir -p /mnt/sda1
# mount /dev/sda1 /mnt/sda1
# bkhive /mnt/sda1/Windows/System32/config/SYSTEM /tmp/saved-syskey.txt
# samdump2 /mnt/sda1/Windows/System32/config/SAM /tmp/saved-syskey.txt > /tmp/hashes.txt
In the event that you have not got bkhive or samdump2 with you, you can fall-back to copy the SYSTEM and SAM files from /mnt/sda1/Windows/System32/config to your USB stick and import them to any tool that is able to extract the SAM hashes from them:

Cain & Abel

,
creddump

and
mimikatz

are some available tools.
Bypass login prompt
If you are looking into bypassing the login prompt rather than dumping users’ password hashes, some smart people have came up with innovative approaches:
BootRoot is a project presented at Black Hat USA 2005 by researchers Derek Soeder and Ryan Permeh, as an exploration of technology that custom boot sector code can use to subvert the Windows kernel as it loads. The eEye BootRootKit is a boot sector-based NDIS backdoor that demonstrates the implementation of this technology.
SysRQ2 is a bootable CD image that allows a user to open a fully privileged (SYSTEM) command prompt on Windows 2000, Windows XP, and Windows Server 2003 systems by pressing Ctrl+Shift+SysRq at any time after startup. It was first demonstrated at Black Hat USA 2005 by researchers Derek Soeder and Ryan Permeh as an example of applied eEye BootRoot technology. Use the “create CD from ISO image” feature of your preferred CD burning software to create a bootable SysRq CD.
Kon-Boot is an prototype piece of software which allows to change contents of a linux kernel and Windows kernel on the fly (while booting). In the current compilation state it allows to log into a linux system as root user without typing the correct password or to elevate privileges from current user to root. For Windows systems it allows to enter any password protected profile without any knowledge of the password.
Password reset
Alternatively you can boot the machine with the bootdisk live CD or USB stick and use the chntpw utility to reset any Windows local user’s credentials.
Post-exploitation scenario
The typical scenario here is that you have compromised a Windows machine by any means and have got shell access as an administrative user. Firstly, you need to escalate your privileges to SYSTEM user. A simple way is to use Sysinternals’ PsExec utility:
‘

C:\>psexec.exe -i -s cmd.exe
Although, there are several other techniques too, but this is outside of the scope of this post.
Legacy techniques
On Windows NT and Windows 2000 systems you can use

MSbackup

utility part of the MS-DOS subsystem: Backup the system state into a file locally on the machine you have compromised, then using MSbackup again, restore the system state stuff to a local directory without preserving the security. Once complete, you will have the SAM and SYSTEM files. You need about 280Mb for the initial backup – typical for a Windows 2000 with current service packs and hot fixes.
Another solution is to use

regback.exe

part of the Windows 2000 Resource Kit Tools. This is slightly easier as it only dumps the specific files:
‘

C:\>regback.exe C:\backtemp\SAM machine sam
C:\>regback.exe C:\backtemp\SYSTEM machine system
If you cannot get regback.exe to work, on Windows XP and above systems use

regedit.exe

or
reg.exe

. Using reg.exe:
‘

C:\>reg.exe save HKLM\SAM sam
The operation completed successfully
C:\>reg.exe save HKLM\SYSTEM sys
The operation completed successfully
Using regedit.exe:
Execute regedit.exe from Start / Run prompt.
Open up Computer\HKEY_LOCAL_MACHINE and right-click the SAM section and select Export.
Change the Save as type setting to Registry Hive Files and save as SAM.
Same steps with SYSTEM hive.
Lastly, you can also get the SAM and SYSTEM files from

C:\Windows\repair\

. Although this directory contains outdated copies of the original C:\Windows\System32\config\ files so it might not reflect the current users’ credentials.
Volume Shadow Copies technique
This technique is fairly recent and was first illustrated by Tim Tomes. It consists of abusing the Volume Shadow Copies functionality in modern Windows operating systems to access locked system files like C:\Windows\System32\config’s SAM and SYSTEM and others.
You can use the Volume Shadow Copy Management command line interface,

vssown

, to leverage this technique as follows.
List shadow copies:
‘

C:\>cscript vssown.vbs /list
Microsoft (R) Windows Script Host Version 5.8
Copyright (C) Microsoft Corporation. All rights reserved.
‘

SHADOW COPIES
=============
As expected, no shadow copies initially.
Verify the status of the Volume Shadow Service (VSS):
‘

C:\>cscript vssown.vbs /status
Microsoft (R) Windows Script Host Version 5.8
Copyright (C) Microsoft Corporation. All rights reserved.
‘

[*] Stopped
‘

C:\>cscript vssown.vbs /mode
Microsoft (R) Windows Script Host Version 5.8
Copyright (C) Microsoft Corporation. All rights reserved.
‘

[*] VSS service set to ‘Manual’ start mode.
In this case, once we are done, we need to restore it to the initial state (Stopped).
Create a new shadow copy:
‘

C:\>cscript vssown.vbs /create
Microsoft (R) Windows Script Host Version 5.8
Copyright (C) Microsoft Corporation. All rights reserved.
‘

[*] Attempting to create a shadow copy.
Verify that the shadow copy has been created:
‘

C:\>cscript vssown.vbs /list
Microsoft (R) Windows Script Host Version 5.8
Copyright (C) Microsoft Corporation. All rights reserved.
‘

SHADOW COPIES
=============
‘

[*] ID:
{D79A4E73-CCAB-4151-B726-55F6C5C3A853}

[*] Client accessible: True
[*] Count: 1
[*] Device object:
\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1

[*] Differnetial: True
[*] Exposed locally: False
[*] Exposed name:
[*] Exposed remotely: False
[*] Hardware assisted: False
[*] Imported: False
[*] No auto release: True
[*] Not surfaced: False
[*] No writers: True
[*] Originating machine: LAPTOP
[*] Persistent: True
[*] Plex: False
[*] Provider ID: {B5946137-7B9F-4925-AF80-51ABD60B20D5}
[*] Service machine: LAPTOP
[*] Set ID: {018D7854-5A28-42AE-8B10-99138C37112F}
[*] State: 12
[*] Transportable: False
[*] Volume name: \\?\Volume{46f5ef63-8cca-11e0-88ac-806e6f6e6963}\
You need to take note of the Device object value for the next step and the ID for the cleanup step.
Pull the following files from a shadow copy:
‘

C:\>copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\System32\config\SYSTEM .C:\>copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\System32\config\SAM .
You have just copied over SAM and SYSTEM files from the shadow copy to the C:\ root folder.
Cleanup:
‘

C:\>cscript vssown.vbs /delete {D79A4E73-CCAB-4151-B726-55F6C5C3A853}
‘

Microsoft (R) Windows Script Host Version 5.8
Copyright (C) Microsoft Corporation. All rights reserved.
‘

[*] Attempting to delete shadow copy with ID: {D79A4E73-CCAB-4151-B726-55F6C5C3A853}
Eventually, restore to original Stop status:
‘

C:\>cscript vssown.vbs /stop
‘

Microsoft (R) Windows Script Host Version 5.8
Copyright (C) Microsoft Corporation. All rights reserved.
‘

[*] Signal sent to stop the VSS service.
In-memory technique
The concept behind in-memory dump of SAM hashes it to inject a DLL into the LSASS system process or, generally speaking, parsing the memory for specific patterns and inspect these memory pages’ content. The former action can lead to a Blue Screen of Death (BSoD) condition following a crash of the LSASS process therefore this action is not recommended on production environments: prefer registry hive copy (regback.exe and reg.exe/regedit.exe) and Volume Shadow Copies techniques instead. Nevertheless, in some specific instances, the in-memory technique is required.
The most widely known standalone tool to dump SAM hashes is probably

fgdump

, the successor of
pwdump6

, both tools developed by the foofus team. The main advantage of fgdump over pwdump6 is that it works on Windows Vista and later versions. Although, I have seen them both failing under some circumstances. More reliable tools include
pwdump7

from Andres Tarasco and the
gsecdump

from TrueSec. Both work on 32-bit and 64-bit systems across all versions of Windows. Although, the former cannot successfully dump users’ password hashes on domain controllers as it reads the SAM hashes from the registry rather than injecting into LSASS process. Despite not working on 64-bit systems, another popular and reliable tool is
PWDumpX



by Reed Arvin.

The following screen-shot shows the dump of SAM users with gsecdump on a Windows Server 2003 SP2 32-bit:
Dump of local users with gsecdump by code injection into the LSASS process

The Metasploit Framework also has its own

post-exploitation modules

, Meterpreter
built-in command



and dated Meterpreter
script



to dump the SAM hashes. Details on how these pieces of code work within the framework and which techniques they implement can be found on these blog posts by HD Moore.

Needless to say that there are more options and knowledge of which one to use within the target environment is important. In order to facilitate this task, I have listed the relevant tools, their capabilities, where they do work and, most importantly, where they are known to fail on
this spread-sheet



.
Conclusions on Windows Security Account Manager

In the previous post of this series, I briefly explained what the Windows Security Account Manager (SAM) is, how to dump Windows local users’ password hashes from SAM having
physical access

to the target system or
following a remote compromise

of the machine, post-exploitation.
Remotely, there exist three possible techniques: legacy, volume shadow copies and in-memory dump. Lastly, I highlighted the most widely used tools for the in-memory hashes dump and I collected and released them in this spread-sheet along with other tools that I will discuss later.

I want to reiterate the following concept: given file transfer ability between your machine and the target system, always prefer to copy the SAM and SECURITY files over from the target and extract the password hashes offline afterwards.
Although, this safe approach to password hashes dump does not guarantee that you are going to obtain all Windows local accounts’ hashes. If you suspect that this is case, you will have to dump the hashes via in-memory dump and merge the results. Odd, but I have seen this happening quite a few times already and I am still discussing standalone Windows workstations, not part of a Windows domain.
Preferred tools

Personally, my first choice for standalone SAM hashes dump is pwdump7: it works on all Windows version from 2000 on both 32-bit and 64-bit systems. However, this tool does not perform an in-memory dump and could miss out hashes. I always run
gsecdump



along with pwdump7 to cover both techniques across all Windows versions and architecture and carefully launched once at a time do crash the LSASS process.

When I have got a Metasploit Meterpreter shell onto the system, I rely on the post-exploitation module
smart_hashdump



by Carlos Perez, falling back to its predecessor post-exploitation module
hashdump



when it fails.
Active Directory

Definition from Wikipedia:
‘


Active Directory

serves as a central location for network administration and security. It is
responsible for authenticating and authorizing all users and computers within a network of Windows domain type

, assigning and enforcing security policies for all computers in a network [...] when a user logs into a computer that is part of a Windows domain, it is Active Directory that verifies his or her password [...]

This definition comes into play when you have compromised a system part of a Windows domain. In order to quickly extend your control over the whole domain, the goal is to compromise the root domain controller. If you are within a child domain, the final goal is to achieve Enterprise Domain Administrator level access onto the root domain controller of the Windows forest’s parent domain. There are plenty of resources on the Internet discussing domain escalation and this is out of the scope of this post series. A
blog post



that summarizes the best techniques and goes straight to the point is written by pentestmonkey.net. Alternatively, you can pass the local users’ hashes obtained from your entry point machines to
keimpx



and spray them against the domain controllers: if the system administrator reuses the same local Administrator password across all machines, you are in!

Regardless of how you have compromised a domain controller, preferably the root domain controller as it is the first to get updated with changes to user accounts, the important is that you have got an administrator (local or domain) shell onto it.
Database file NTDS.DIT

The goal now is to dump the domain users’ password hashes. These are stored, along with nearly all the information that is accessible in the Active Directory (user objects, groups, membership information, etc), in a binary file,
%SystemRoot%\ntds\NTDS.DIT

.

This file is locked by the system. You can use the volume shadow copies technique illustrated in the previous post to copy it along with the SYSTEM file over to your machine.
Alternatively, use the ntdsutil snapshot facility introduced in Windows Server 2008. It will create a snapshot of the active directory database allowing you to copy ntds.dit and SYSTEM file. This technique is detailed on a Microsoft TechNet article.
Extract hashes from NTDS.DIT

You can use the passcape’s
Windows Password Recovery tool



to extract hashes from ntds.dit.

Alternatively, you can use a couple of tools (ntds_dump_hash.zip) developed by Csaba Barta and documented in his paper titled Research paper about offline hash dump and forensic analysis of ntds.dit. These tools are used to:

Extract

the required data from ntds.dit: esedbdumphash.

Decrypt

the hashes and interpreting other information regarding the user account: dsdump.py, dsdumphistory.py, dsuserinfo.py.

Download and compile the tool:
‘

$ wget http://csababarta.com/downloads/ntds_dump_hash.zip
$ unzip ntds_dump_hash.zip
$ cd libesedb
$ ./configure && make

Use esedbdumphash to extract the datatable from ntds.dit:
‘

$ cd esedbtools
$ ./esedbdumphash -v -t /tmp/output <ntds.dit file>
$ ls -1 /tmp/output.export/
datatable

Use dsdump.py to dump the hashes from the datatable file using the bootkey (SYSKEY) from the SYSTEM hive:
‘

$ cd ../../creddump/
$ chmod +x *.py
$ ./dsuserinfo.py /tmp/output.export/datatable
$ ./dsdump.py <SYSTEM file> /tmp/output.export/datatable –include-locked –include-disabled > domain_hashes.txt

Like standalone machines, you can use the in-memory technique too to dump the domain users’ hashes. The tools are the same and work equally. Just be cautious when injecting into the LSASS process of a domain controller: in the worst case scenario, you will have to reboot an infrastructure-critical server.

I have added these tools and improved the
spread-sheet



.
Updates on January 4, 2012

During December 2011, Csaba Barta has dug some more into NTDS.dit structure and as a result he has developed a new framework called
NTDSXtract



to extract information from database tables extracted with libesedb from ntds.dit file: both tools now support 64-bit derived database files too.
Download and install the latest release of libesedb.
Extract the database tables from ntds.dit:
‘

$ esedbexport -l /tmp/esedbexport.log -t /tmp/ntds.dit <ntds.dit file>
esedbexport 20111210
‘

Opening file.
Exporting table 1 (MSysObjects) out of 12.
Exporting table 2 (MSysObjectsShadow) out of 12.
Exporting table 3 (MSysUnicodeFixupVer2) out of 12.
Exporting table 4 (datatable) out of 12.
Exporting table 5 (hiddentable) out of 12.
Exporting table 6 (link_table) out of 12.
Exporting table 7 (sdpropcounttable) out of 12.
Exporting table 8 (sdproptable) out of 12.
Exporting table 9 (sd_table) out of 12.
Exporting table 10 (MSysDefrag2) out of 12.
Exporting table 11 (quota_table) out of 12.
Exporting table 12 (quota_rebuild_progress_table) out of 12.
Export completed.
‘

$ ls -1 /tmp/ntds.dit.export/
datatable.3
hiddentable.4
link_table.5
[...]
Use NTDSXtract to parse the datatable and extract users’ information, including password hashes and history:
‘

~/NTDSXtract 1.0$ python dsusers.py /tmp/ntds.dit.export/datatable.3 /tmp/ntds.dit.export/link_table.5 –passwordhashes <SYSTEM file> –passwordhistory <SYSTEM file> –certificates –supplcreds <SYSTEM file> –membership > /tmp/ntds.dit.output
Use this small script that I have put together to process the output of NTDSXtract‘s dsusers.py into a “pwdump-alike” penetration tester’s friendly format:
‘

$ python ntdstopwdump.py /tmp/ntds.dit.output
Administrator:500:NO PASSWORD*********************:09b1708f0ea4832b6d87b0ce07d7764b:::
Guest:501:NO PASSWORD*********************:NO PASSWORD*********************:::
[...]
Password history

In the previous two posts of this series, I discussed how to dump Windows local users’ password hashes (SAM) and Windows domain users’ password hashes from domain controllers (ntds.dit).

When the password policy setting is configured to enforce password history, Windows stores a certain number of used passwords before an old password can be reused. The following screenshot shows you where this policy can be set.
Local Security Policy (secpol.msc) / Account Policies / Password Policy / Enforce password history


By default on workstations, this value is set to 0 and on domain controllers it is set to 24. This means that when dumping domain users’ hashes from active directory’s ntds.dit file, there are high chances to dump also the password history allowing you, during the password cracking phase, to recognise patterns used by the target users.

Despite not being current password hashes, pattern identification can lead to further attacks. For instance, ease of guessing passwords used against standalone services at later stages of your post-exploitation. Therefore, never underestimate the added value provided by dumping and cracking the password history.

Many of the tools introduced so far can dump the password history: Cain & Abel, PWDumpX along others.
pwhist



from Toolcrypt is also a valid option.
LSA secrets

LSA secrets is an area in the registry where Windows stores important information. This includes:

Account passwords for services that are set to run by operating system users

as opposed to Local System, Network Service and Local Service.

Password used to logon to Windows if auto-logon is enabled

or, generally, the password of the user logged to the console (DefaultPassword entry).

LSA secrets are stored in registry hive HKEY_LOCAL_MACHINE/Security/Policy/Secrets. Each secret has its own key. The parent key, HKEY_LOCAL_MACHINE/Security/Policy, contains the data necessary for accessing and decoding the secrets.
Dump LSA secrets

As per SAM hashes, the LSA secrets can be accessed by DLL injection into the lsass.exe process or from the registry files.
If you are Administrator and the target system is used in production, I recommend you to choose the safe path and copy off the system the registry files: SYSTEM and SECURITY: you can use the legacy registry hive copy (reg.exe/regedit.exe) or the volume shadow copies technique illustrated in the first post. Cain & Abel can extract LSA secrets from these files.
Alternatively, there are numerous tools that can be used to dump LSA secrets by injecting into lsass.exe process:
gsecdump1″>gsecdump

has proved to be the most reliable for LSA secrets, working across all Windows versions and architectures. On 32-bit architecture, the original
lsadump2



has proved to be good too. Despite my expectations, the two NirSoft tools (LSASecretsDump and LSASecretsView) have failed to dump services’ account passwords, regardless of the architecture.

Regardless of the technique used, the passwords extracted are UTF-16 encoded. This means that they are in
clear-text

as opposed to SAM hashes. You can read a detailed description of the LSA secrets format here by Brendan Dolan-Gavitt.

The following screen-shot shows the output of gsecdump on a Windows Server 2003 machine running IBM DB2 and PostgreSQL. Both database management systems run as Windows local users:
Output of gsecdump.exe -l to dump LSA secrets

Threats posed by LSA secrets

Now, imagine that you have compromised a server part of a Windows domain, you have got a shell as Local System. If you want to extend your control over the network perimeter, one of the viable ways is to verify if any service runs as real operating system users and, if so, extract their clear-text password from LSA secrets.
You can run services.msc from Start / Run and sort the entries by Log On As column to check this quickly. The following screen-shot demonstrates this:
Services running as local users on Windows


Obviously, the built-in sc.exe command can do the same as well as other less known tools.
It is common to identify enterprise software like Veritas Netbackup, Microsoft SQL Server, Microsoft Exchange and others running as real users. More dangerously, sometimes system administrators opt to run services as domain users, if not domain administrators.
This is clearly
wrong and poses a high threat to overall security

of the target Windows domain because, as an attacker, you can dump the LSA secrets and use the clear-text domain administrator password to login to the root domain controller and takeover the Windows network.
Cached domain logon information

Windows machines can be standalone workstations or part of a Windows domain in the role server or workstation.
When a user logs onto a workstation part of a domain, technically he can either log as a local user or a domain user given that he has the credentials.

When logging as a domain user, three information are required: username, password and domain name. The latter is usually provided as a drop-down menu listing all domains that the system is part of.
Given this information, when the domain user logs onto the system, the provided password is hashed and checked over the network against the domain controller’s valid password hash (physically stored within ntds.dit file). This process is handled once again by the lsass.exe process.
LSASS first checks if the domain controller is available. If so, it proceeds with the password hash matching step and, depending on the result, it allows or denies access to the system to the authenticating domain user.

In the event that none of the domain controllers are available, the legitimate domain user would not be able to login onto the system. To avoid this from happening, Microsoft has long ago introduced the
cached domain logon information

mechanism in Windows.

Definition from Microsoft:
‘

All previous
users’ logon information is cached locally so that, in the event that a domain controller is unavailable during subsequent logon attempts, they are able to log on

[...]

Therefore, when the domain controllers are not available, the domain user can still log onto the domain machine. The only caveats being that he has previously successfully logged and that the system is configured to cache the domain logon information. The following screenshot shows you where this policy is set.
Local Security Policy (secpol.msc) / Local Policies / Security Options / Interactive logon: Number of previous logons to cache (in case domain controller is not available)


You can also read the value of this policy in registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\CachedLogonsCount.

By default Windows XP and above are configured to cache 10 or more domain logon information.
Cached domain logon information is stored in registry hives HKEY_LOCAL_MACHINE/Security/CACHE/NL$X with X being a number. These registry hives are accessible by Local System and tools exist to dump them.
Dump cached domain logon information

Like other hashes, these hashes can be accessed by DLL injection into the lsass.exe process or from the registry files.
For offline dump, copy off the system the registry files SYSTEM and SECURITY: you can use the legacy registry hive copy (reg.exe/regedit.exe) or the volume shadow copies technique illustrated in the first post. Cain & Abel,
creddump



by Brendan Dolan-Gavitt and Windows Password Recovery by passcape can extract cached domain logon information from these files.
Alternatively, there are numerous tools that can dump this by DLL injection into lsass.exe process. On 32-bit architecture you can use the original
cachedump



by Arnaud Pilon which proved to be reliable also on recent Windows versions, fgdump or PWDumpX.
Unfortunately though, none of the standalone free tools work on 64-bit architecture. In this case, you can rely on Metasploit Framework own post-exploitation module if you have got a Meterpreter shell onto the target system.

Follows the output of cachedump on a Windows system part of a domain:
‘

C:\>cachedump.exe -v
Service not found. Installing CacheDump Service (C:\cachedump.exe -s)
CacheDump service successfully installed.
Service started.
user:2d9f0b052932ad18b87f315641921cda:lab:lab.internal

Service currently active. Stopping service…
Service successfully removed.
Threats posed by cached domain logon information

Similar scenario to LSA secrets dump: you have compromised a machine part of a Windows domain and have got a shell as Local System. There are no traces of domain users’ credentials from LSA secrets. Another step to extend your control over the domain? Check if the machine is configured to cache domain logon information as explained above. If so, dump them.

Cached domain logon information
cannot be directly used to authenticate to other systems

as opposed to NT and LM password hashes. Nevertheless, you can crack them and use the clear-text password to authenticate to machines part of the relevant domain. I will cover password hashes cracking in depth in another blog post.

Conceptually, caching domain logon information is effective and solves network administrators’ headaches to deal with domain users logons when the domain controllers are under maintenance or unavailable for whatever reason. Although, looking at it with the security lens,
it clearly poses a security threat

.
Logon sessions

Windows stores in memory information about every
current and past successful logon

. These are called logon session. This information includes the
username, the domain or workgroup name and both the LM and NT password hashes

.

Every time a legitimate user logs onto a Windows system, the Local Security Authority (LSA) stores in memory this information. This happens regardless of the logon type: interactive logon to the console or remote logon via Remote Desktop Protocol (RDP).

The image below from Hernan Ochoa illustrates this concept:
Windows NT logon and authentication model


The same information is stored for RunAs processes and services running as specific users. In the latter case, the clear-text password is stored in memory and can be retrieved in LSA secrets anyway.
Exception being network logons, for instance over SMB or HTTP; these do not get stored because the NT/LM hashes never actually reach the server. A challenge-response mechanism is used for authentication.

This sensible information is kept in memory because it is used for Single Sign-On (SSO) purposes.
SSO technology is extensively used in Windows network, particularly within domains. This allows, for instance, a user logged into a certain system of the domain to access remote shares, shared resources like printers and HTTP proxy protected by NTLM authentication without the need to type in his clear-text credentials each time: Windows deals with the authentication for him transparently over the network by providing exactly what is stored in memory: username, domain/workgroup and password hashes.
This authentication mechanism works because nowadays nearly all Windows services accept authentication with NT/LM hashes as an alternative to clear-text password. Exception being Remote Desktop Protocol.
Dump logon sessions

Logon sessions can be dumped given you have an administrative shell onto the target. There exist two techniques to dump logon sessions: code injection into lsass.exe process and reading of LSASS memory.

There are several tools that can dump logon sessions:
msvctl



from TrueSec is a safe choices for Windows XP/2003 and is limited to 32-bit architecture. The updated version of gsecdump can dump logon sessions regardless of Windows version and architecture too. More recent tools include another nice piece of code from TrueSec,
lslsass



: this tool has been designed specifically for Windows Vista onwards and delivers reliable results regardless of the architecture.

The most well known tools to manipulate Windows logon sessions are
Windows Credentials Editor



(WCE) and its predecessor, Pass-The-Hash Toolkit (PTK). Both are the result of thriving research by Hernan Ochoa, currently the founder of Amplia Security. His presentations include:
Pass-The-Hash Toolkit for Windows: Implementation & use presented at Hack In The Box Security Conference in Malaysia on late 2008. Despite being a dated presentation, it offers insight on the history and techniques used in post-exploitation scenarios, specifically focusing on the more generic Pass-the-Hash technique and its implementation in the Pass-The-Hash Toolkit.
WCE Internals presented at RootedCon in Madrid on early 2011. This presentation explains the inner workings of WCE including how Windows store credentials in memory pre and post Windows Vista.
Post-Exploitation with WCE presented on July 2011. Simple and effective high-level presentation with test cases. I recommend you reading this presentation before anything else if you are totally unfamiliar with logon sessions and pass-the-hash technique. Another good read is the tool’s FAQ page.
Between these two tools, I prefer WCE for a number of reasons: it is one single executable, it is safer than all the other tools as it is the only one to implement the reading of LSASS memory technique as an alternative to performing code injection and it works across all Windows versions and on both architectures.
For the purpose of this post, I have set a Windows Server 2003 R2 Service Pack 2 fully patched machine (NetBIOS name: w2k3r2) in the following state:
Local Administrator with a 15-characters long password logged interactively to the console.
Two local users, inquis and foobar, both connected over RDP, respectively using mstsc, the default RDP client on Windows, and rdesktop, a RDP client for Unix/Linux.
A few services, all related to IBM DB2 database management system, running as local administrator, db2admin.

lslsass was deliberately excluded from my tests as it only works on Windows Vista onwards.
All the tested tools were able dump the logon sessions successfully. Follows the output of Windows Credentials Editor:
‘

C:\>wce.exe -l
‘

WCE v1.2 (Windows Credentials Editor) – (c) 2010,2011 Amplia Security – by Hernan Ochoa ([e-mail])
Use -h for help.
‘
Administrator:W2K3R2:00000000000000000000000000000000:237599E85CF684A6785A12ACD2E24E5C
inquis:W2K3R2:0AC9A586623764E16591BB5472A3AD4A:89F411F435A93044E2E8AA4CEDFE0FBA
foobar:W2K3R2:87DCEB9223BE0E08FD8E74C8CEB3053A:33D807D89B36ACDF2FAB42A361DE0B91
db2admin:W2K3R2:3AE6CCCE2A2A253F93E28745B8BF4BA6:35CCBA9168B1D5CA6093B4B7D56C619B

W2K3R2$:WORKGROUP:AAD3B435B51404EEAAD3B435B51404EE:31D6CFE0D16AE931B73C59D7E0C089C0

As you can see, these tools dump logon sessions and display the username, domain/workgroup name and LM/NT hashes very similarly to SAM hashes dump tools output. The main difference is that these tools display the domain/workgroup name as domain users can be logged onto the system too as opposed to the user ID field shown by pwdump-alike tools.

The following screen-shot demonstrates the successful dump too:
Dump of logon sessions with Windows Credentials Editor (WCE) on a Windows Server 2003 R2 machine where the Administrator is logged to the console, two users are logged remotely via RDP and one service is running as local user

I realized during my tests that regardless of the method used to close a session, the logon sessions remain in memory. Take RDP connections, either if you disconnect (clicking on the top right

X

button of your RDP client) or log off from the Start menu, they remain in memory. I have seen this happening on Windows Server 2008 R2 Enterprise Service Pack 1 too. The main difference being that on Windows Vista onwards the logon sessions are erased from memory a few minutes after the user has logged off.
The following screen-shots demonstrate the described behaviour:
Dump of logon sessions following a disconnect via RDP of one user, foobar – his logon session remains in memory

Dump of logon sessions following a forced log off of user’s foobar RDP connection – his logon session remains in memory

db2admin logon session also remains in memory despite the relevant services are stopped.
Threats posed by logon sessions
The scenario here is similar to LSA secrets dump and cached domain logon information: you are Local System on a machine part of one or more Windows domains and you want to takeover the domains. There are no traces of domain users’ credentials from LSA secrets and the machine does not cache domain logon information.
To extend your control over the domain you can dump the logon sessions. If there is a logon session of a domain administrator, it is game over: impersonate that logon session to spawn a command prompt. This technique is also known as

pass-the-hash

or logon session stealing.
The command line would look like:
‘

C:\>wce.exe -s <user>:<domain>:<LM hash>:<NT hash> -c cmd.exe
In the new command prompt window, connect over SMB, for instance with Sysinternals’ PsExec, to the root domain controller to takeover the Windows domain – Windows will use the impersonated NTLM credentials to authenticate against the domain controller and access will likely be granted as you are now, as a matter of facts, the domain administrator.
Alternatively, if there are no domain administrators’ logon sessions, you can still spray the dumped logon sessions’ hashes to others machines of the domain exactly the same way you do to verify password reuse across machines with the local users’ password hashes: in the event that you have dumped domain users’ logon sessions, chances are high that these users are allowed to login to others systems of the network therefore you have an easy way into these.
These systems might be vulnerable to others threats that allow you to takeover the domain from there, so it is definitely worth a try.
Apart from WCE, others tools can also perform pass-the-hash: msvctl and the more recent

RunhAsh

from TrueSec. I have added these tools to the spread-sheet. Feedback is welcome!
Network services authentication credentials

Like LSA secrets, Windows stores
passwords in a reversible format

elsewhere.

When you login to a network resource like a network share, a proxy server behind NTLM authentication, a database management system, a mail server, etc, you can often instruct your client to save the password, typically by simply ticking the box “Remember my password”.

Behind the scenes, Windows stores this information in the Credential Manager – a single sign-on (SSO) solution that exists since Windows XP. These stored credentials are used to authenticate each time the corresponding network resource is accessed by the user without the need to retype the password.

These passwords are encrypted using the DPAPI syubsystem and can be dumped in
clear-text

format.
You can also view, edit and add to this password storage. On Windows Vista onwards the Credential Manager is available under Control Panel\User Accounts and Family Safety\Credential Manager or from Control Panel\User Accounts and Family Safety\User Accounts\\Manage your credentials.

Another storage used by Windows for a similar purpose is the Protected Storage. Applications like Internet Explorer and Outlook Express store the email account password in this storage, where they do not opt to store in the Credential Manager. The passwords stored in the Protected Storage are encrypted using the CryptoAPI functions and the key is derived from the user’s password therefore they can be dumped in
clear-text

format too.
Third-party software like Chrome, RealVNC Client, Thunderbird and others store passwords to websites in their own format. Some tools store them within the registry, some use the Windows API and store them in the Credential Manager or the Protected Storage and others in files. Regardless, all these credentials are stored in a reversible format, publicly documented or not, they can be dumped in

clear-text

like Credential Manager and Protected Storage passwords.
Dump Credential Manager

The methods to interact with the Credential Manager is documented by Microsoft and implemented in a number of tools able to dump these credentials.
NirSoft’s
Network Password Recovery



(netpass) is my first choice. It is one-executable only tool and reliable. Make sure you run the 64-bit version on 64-bit architecture.
Cain & Abel can also dump the Credential Manager efficiently, however it only works locally not remotely so you should better avoid it unless installing new software is permitted onto the target machine.
Passcape’s Network Password Recovery, not to be confused with the namesake tool from NirSoft, also works well, but the trial version only displays the first three characters of the dumped passwords.
Avoid Metasploit own post-exploitation module windows/gather/credentials/enum_cred_store – it has always crashed regardless of the target Windows version.
Dump Protected Storage

NirSoft’s
Protected Storage PassView



(pspv) is my first choice. It is one-executable only tool and reliable.
Another tool to consider is
carrot



, a bundle of other tools (primarily from NirSoft), good to dump Protected Storage credentials.
Avoid fgdump as it fails to dump the protected storage.
Dump third-party software stored credentials
NirSoft has a vast collection of tools to dump third-party software stored credentials. Many of these are bundled in one-executable only tool, carrot.
If you have got a Meterpreter shell onto the target system, Metasploit is handy to dump third-party software stored credentials as it has numerous

post-exploitation modules1″>post-exploitation modules

for this purpose. Some are pretty much reliable, others are in beta and often crash.
Threats posed by n
etwork services authentication credentials

During an internal infrastructure assessment it is likely that you are able to own a workstation before a server.
When this occurs, collecting information about what is the role of the machine within the infrastructure is a crucial step to successfully compromise the overall network. In cases where the machine is an employee’s workstation used daily, chances are very high that he uses it to access his corporate email, internal web sites, corporate proxy and other services. If so, chances are even higher that the user has ticked the “Remember my password” entry, everywhere.
Having access, even as a low-privileged user, to these corporate systems “for free” is priceless and useful in your run to extend your control over the network and demonstrate to the customer how even the average and most insignificant workstation far from the DMZ need to be taken care of systematically.

Often corporate email credentials, network shares passwords and others are reused by users across different services if not the domain user account too so being able to dump the credentials in clear is high value during a penetration test.