Pass The Hash …

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.

Redemption

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.

Windows Authentication

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:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\WDigest

  • 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

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest\

Userlogon_none

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)

2Figure 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

UseLogonCredential_01

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

5

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

6

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

4

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

7

Figure 7 Whoami /all shows administrator as part of Debug priv permission

Authenticated user with no administrator privilge

8

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

9

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

10

Figure 10  nt authority\System priv

Alternatively we can elevate within the mimikatz request nt authority/system

11

Figure 11 token::elevate delegation

lsadump:sam to dump NTLM password hash from SAM file

12

Figure 12 Mimikatz to extract the SAM hash database

sekurlsa::pth /user:Administrator /domain:locahost  /ntlm:9cf1735cff285fdcc130125cee

14

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

16

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

17

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.

18

Figure 16  Password hash dumped from procdump .dmp file

Mitigation

  • 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

 

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s