☑️Windows Local Passwords

Attacking SAM

With access to a non-domain joined Windows system, we may benefit from attempting to quickly dump the files associated with the SAM database to transfer them to our attack host and start cracking hashes offline.

Copying SAM Registry Hives

There are three registry hives that we can copy if we have local admin access on the target; each will have a specific purpose when we get to dumping and cracking the hashes. Here is a brief description of each in the table below:

Registry Hive
Description

hklm\sam

Contains the hashes associated with local account passwords. We will need the hashes so we can crack them and get the user account passwords in cleartext.

hklm\system

Contains the system bootkey, which is used to encrypt the SAM database. We will need the bootkey to decrypt the SAM database.

hklm\security

Contains cached credentials for domain accounts. We may benefit from having this on a domain-joined Windows target.

We can create backups of these hives using the reg.exe utility.

C:\WINDOWS\system32> reg.exe save hklm\sam C:\sam.save

The operation completed successfully.

C:\WINDOWS\system32> reg.exe save hklm\system C:\system.save

The operation completed successfully.

C:\WINDOWS\system32> reg.exe save hklm\security C:\security.save

The operation completed successfully.

Technically we will only need hklm\sam & hklm\system, but hklm\security can also be helpful to save as it can contain hashes associated with cached domain user account credentials present on domain-joined hosts.

We can then transfer them to our attack machine using smbclient.py.

1. Smbclient.py to get the hives

The smb2support option will ensure that newer versions of SMB are supported. If we do not use this flag, there will be errors when connecting from the Windows target to the share hosted on our attack host. Newer versions of Windows do not support SMBv1 by default because of the numerous severe vulnerabilites and publicly available exploits.

Once we have the share running on our attack host, we can use the move command on the Windows target to move the hive copies to the share.

2. Secretdump.py to dump the hashes

Using secretsdump.py is a simple process. All we must do is run secretsdump.py using Python, then specify each hive file we retrieved from the target host.

The first step secretsdump executes is targeting the system bootkey before proceeding to dump the LOCAL SAM hashes. It cannot dump those hashes without the boot key because that boot key is used to encrypt & decrypt the SAM database. We will also notice the format Dumping local SAM hashes (uid:rid:lmhash:nthash).

3. Using hashcat to crack the hashes

Lets say using mode 1000 to crack the NT hashes.

Note: Keep in mind that this is a well-known technique, so admins may have safeguards to prevent and detect it. We can see some of these ways documented within the MITRE attack framework.

Remote Dumping

LSA Secret Dumping

With access to credentials with local admin privileges, it is also possible for us to target LSA Secrets over the network. This could allow us to extract credentials from a running service, scheduled task, or application that uses LSA secrets to store passwords.

SAM Secret Dumping

Attacking LSASS

LSASS is a critical service that plays a central role in credential management and the authentication processes in all Windows operating systems. LSASS stores credentials that have active logon sessions on Windows systems.

Upon initial logon, LSASS will:

Dumping LSASS Process Memory

Using Task Manager

If we have a GUI based connection then:

Open Task Manager > Select the Processes tab > Find & right click the Local Security Authority Process > Select Create dump file

A file called lsass.DMP is created and saved in:

Rundll32.exe & Comsvcs.dll Method

This is useful if we dont have GUI based access but we have a shell in Windows. We can use rundll32.exe to dump the memory but first we need to determine the PID for lsass.exe.

On PowerShell:

With an elevated PowerShell session, we can issue the following command to create the dump file:

With this command, we are running rundll32.exe to call an exported function of comsvcs.dll which also calls the MiniDumpWriteDump (MiniDump) function to dump the LSASS process memory to a specified directory (C:\lsass.dmp).

Note: Recall that most modern AV tools recognize this as malicious and prevent the command from executing. In these cases, we will need to consider ways to bypass or disable the AV tool we are facing.

Using Pypykatz to Extract Credentials

Once we have the dump files in our attack machine we can use a powerful tool called pypykatz to extract credentials. Pypykatz is similar to mimikatz but written entirely in Python.

The command initiates the use of pypykatz to parse the secrets hidden in the LSASS process memory dump. We use lsa in the command because LSASS is a subsystem of local security authority, then we specify the data source as a minidump file, proceeded by the path to the dump file (/home/peter/Documents/lsass.dmp) stored on our attack host. Pypykatz parses the dump file and outputs the findings:

Lets take a more detailed look at some of the useful information in the output.

MSV

MSV is an authentication package in Windows that LSA calls on to validate logon attempts against the SAM database.

WDIGEST

WDIGEST is an older authentication protocol enabled by default in Windows XP - Windows 8 and Windows Server 2003 - Windows Server 2012. LSASS caches credentials used by WDIGEST in clear-text. This means if we find ourselves targeting a Windows system with WDIGEST enabled, we will most likely see a password in clear-text. Modern Windows operating systems have WDIGEST disabled by default. Additionally, it is essential to note that Microsoft released a security update for systems affected by this issue with WDIGEST. We can study the details of that security update here.

Kerberos

Kerberos is a network authentication protocol used by Active Directory in Windows Domain environments. Domain user accounts are granted tickets upon authentication with Active Directory. This ticket is used to allow the user to access shared resources on the network that they have been granted access to without needing to type their credentials each time. LSASS caches passwords, ekeys, tickets, and pins associated with Kerberos. It is possible to extract these from LSASS process memory and use them to access other systems joined to the same domain.

DPAPI

The Data Protection Application Programming Interface or DPAPI is a set of APIs in Windows operating systems used to encrypt and decrypt DPAPI data blobs on a per-user basis for Windows OS features and various third-party applications. Here are just a few examples of applications that use DPAPI and what they use it for:

Applications
Use of DPAPI

Internet Explorer

Password form auto-completion data (username and password for saved sites).

Google Chrome

Password form auto-completion data (username and password for saved sites).

Outlook

Passwords for email accounts.

Remote Desktop Connection

Saved credentials for connections to remote machines.

Credential Manager

Saved credentials for accessing shared resources, joining Wireless networks, VPNs and more.

Mimikatz and Pypykatz can extract the DPAPI masterkey for the logged-on user whose data is present in LSASS process memory. This masterkey can then be used to decrypt the secrets associated with each of the applications using DPAPI and result in the capturing of credentials for various accounts.

Finally, we can use hashcat with mode 1000 to crack the NT hashes:

Attacking AD & NTDS.dit

For that first we need to have a foothold into the internal network!

Once a Windows system is joined to a domain, it will no longer default to referencing the SAM database to validate logon requests.

This does not mean the SAM database can no longer be used. Someone looking to log on using a local account in the SAM database can still do so by specifying the hostname of the device proceeded by the Username (Example: WS01/nameofuser) or with direct access to the device then typing ./ at the logon UI in the Username field.

Note: We can also study NTDS attacks by keeping track of this technique

Dictionary Attacks against AD accounts

Many organizations follow a naming convention when creating employee usernames. Here are some common conventions to consider:

Username Convention
Practical Example for Jane Jill Doe

firstinitiallastname

jdoe

firstinitialmiddleinitiallastname

jjdoe

firstnamelastname

janedoe

firstname.lastname

jane.doe

lastname.firstname

doe.jane

nickname

doedoehacksstuff

Often, an email address's structure will give us the employee's username (structure: username@domain). For example, from the email address [email protected], we see that jdoe is the username.

A tip from MrB3n: We can often find the email structure by Googling the domain name, i.e., “@inlanefreight.com” and get some valid emails. From there, we can use a script to scrape various social media sites and mashup potential valid usernames. Some organizations try to obfuscate their usernames to prevent spraying, so they may alias their username like a907 (or something similar) back to joe.smith. That way, email messages can get through, but the actual internal username isn’t disclosed, making password spraying harder. Sometimes you can use google dorks to search for “inlanefreight.com filetype:pdf” and find some valid usernames in the PDF properties if they were generated using a graphics editor. From there, you may be able to discern the username structure and potentially write a small script to create many possible combinations and then spray to see if any come back valid.

If we do not know the naming convention of the organization we can include many naming conventions in our custom username list.

We can manually create our list(s) or use an automated list generator such as the Ruby-based tool Username Anarchy to convert a list of real names into common username formats.

Then we can run it against the list of real names and it will generate a username list.

Using automated tools can save us time when crafting lists. Still, we will benefit from spending as much time as we can attempting to discover the naming convention an organization is using with usernames because this will reduce the need for us to guess the naming convention.

Using CrackMapExec

Once we have our list(s) prepared or discover the naming convention and some employee names, we can launch our attack against the target domain controller using a tool such as CrackMapExec. We can use it in conjunction with the SMB protocol to send logon requests to the target Domain Controller. Here is the command to do so:

It is better to know the password policy so that we dont lock out the account we are attacking.

Detection

Event ID 4776 is logged whenever a domain controller (DC) attempts to validate the credentials of an account using NTLM over Kerberos.

Capturing NTDS.dit

NT Directory Services (NTDS) is the directory service used with AD to find & organize network resources. NTDS.dit file is stored at %systemroot%/ntds on the domain controllers in a forest. The .dit stands for directory information tree.

This is the primary database file associated with AD and stores all domain usernames, password hashes, and other critical schema information. If this file can be captured, we could potentially compromise every account on the domain similar to the technique of attacking SAM.

First, lets connect to the target DC with the credentials we got:

Evil-WinRM connects to a target using the Windows Remote Management service combined with the PowerShell Remoting Protocol to establish a PowerShell session with the target.

Checking local group membership

Once we log in we can check what privileges our user has by checking the local group membership.

We are looking to see if the account has local admin rights.

To make a copy of the NTDS.dit file, we need local admin (Administrators group) or Domain Admin (Domain Admins group) (or equivalent) rights.

Checking domain privileges

We also will want to check what domain privileges we have.

This account has both Administrators and Domain Administrator rights which means we can do just about anything we want, including making a copy of the NTDS.dit file.

Creating Shadow Copy of C:

We can use vssadmin to create a Volume Shadow Copy (VSS) of the C: drive or whatever volume the admin chose when initially installing AD. It is very likely that NTDS will be stored on C: as that is the default location selected at install, but it is possible to change the location. We use VSS for this because it is designed to make copies of volumes that may be read & written to actively without needing to bring a particular application or system down.

VSS is used by many different backup & disaster recovery software to perform operations.

Copying NTDS.dit from the VSS

We can then copy the NTDS.dit file from the volume shadow copy of C: onto another location on the drive to prepare to move NTDS.dit to our attack host.

Transferring NTDS.dit to Attack Host

Now cmd.exe /c move can be used to move the file from the target DC to the share on our attack host.

A Faster Method: Using cme to Capture NTDS.dit

Alternatively, we may benefit from using CrackMapExec to accomplish the same steps shown above, all with one command. This command allows us to utilize VSS to quickly capture and dump the contents of the NTDS.dit file conveniently within our terminal session.

Cracking hashes with Hashcat

Pass-the-Hash considerations

What if we are unsuccessful in cracking a hash?

We can still use hashes to attempt to authenticate with a system using a type of attack called Pass-the-Hash (PtH). A PtH attack takes advantage of the NTLM authentication protocol to authenticate a user using a password hash. Instead of username:clear-text password as the format for login, we can instead use username:password hash. Here is an example of how this would work:

Credentials Hunting

Once we get access to a machine lets say IT admins WIndows 10 workstation, we will significantly benefit from incorporating credentials hunting into our approach.

We can ask ourselves:

What might an IT admin be doing on a day-to-day basis & which of those tasks may require credentials?

Search terms

Lets start with using searching tools and terms:

Passwords
Passphrases
Keys

Username

User account

Creds

Users

Passkeys

Passphrases

configuration

dbcredential

dbpassword

pwd

Login

Credentials

Lazagne.exe

We can also take advantage of third-party tools like Lazagne to quickly discover credentials that web browsers or other installed applications may insecurely store. It would be beneficial to keep a standalone copy of Lazagne on our attack host so we can quickly transfer it over to the target.

We can run Lazagne on the target machine:

We can see all the software supported by Lazagne in their Github.

Findstr

We can also use findstr to search from patterns across many types of files. Keeping in mind common key terms, we can use variations of this command to discover credentials on a Windows target:

Here are some other places we should keep in mind when credential hunting:

  • Passwords in Group Policy in the SYSVOL share

  • Passwords in scripts in the SYSVOL share

  • Password in scripts on IT shares

  • Passwords in web.config files on dev machines and IT shares

  • unattend.xml

  • Passwords in the AD user or computer description fields

  • KeePass databases --> pull hash, crack and get loads of access.

  • Found on user systems and shares

  • Files such as pass.txt, passwords.docx, passwords.xlsx found on user systems, shares, Sharepoint

Last updated