June 18, 2020 | By Aviv Mizrahi, Senior Analyst TSOC
Credentials dumping is a process or technique which is used by cybercriminals and bad actors to extract account credentials (username/password) information from an underlying operating system, files, and respective software. It is also listed within MITRE, as one of the techniques within the tactic – Credential Access.
It predominantly supports an adversary to perform lateral movement across an organization’s infrastructure and access business-sensitive information, using the credentials retrieved from conducting credential dumping.
As locating and attaining the right credentials is a vital step for allowing an adversary to move laterally across an environment, it is one of the most crucial activities from an attacker’s standpoint. It is also one of the most used schemes across known APT attack groups – for instance, APT1 and Lazarus group.
We have explained this write-up across 5 key segments:
- Use of Credentials Dumping by Adversaries Groups
- A statistical approach to detecting credential theft
- Types of Windows Credentials that the Windows OS stores
- Mitigation techniques and actionable steps
- Detection techniques – continuous monitoring
We have listed below some of the known adversary groups which leverage credential dumping activity and uses tools to extract the credential information:
- APT28 regularly deploys both publicly available and custom password retrieval tools on victim systems
- To attain the victim’s Active Directory (AD) database and credential dumping, FIN6 has been using Win Credential Editor as well as the PsExec NTDSGRAB module (within Metasploit).
- Another well-known adversary group APT3 for dumping credentials injects itself into the Windows Local Security Authority Subsystem Service (lsass.exe) and gets itself triggered with a “dig” argument. This service is in charge of enforcing the security policy on the Windows workstation. They are also using various tools to pull passwords from respective browsers in a workstation.
- APT33 has used a variety of publicly available tools like LaZagne, Mimikatz, Gpppassword, SniffPass, and ProcDump to dump credentials across its victims.
- APT39 has used multiple tools including Win Credential editor, Procdumo Ncrack, etc. to extract credentials across the workstations.
The number and size of memory-reads from the lsass.exe process related to credential dumping are highly predictable as illustrated in the below graph.
- Security Accounts Manager (SAM) database: It’s a file which is present across all the Windows operating system, consisting of all the accounts created including built-in accounts found on the Windows OS i.e. Windows 7, 8.1 and 10). In SAM, credentials are stored as NT password hash.
- Cached Domain Credentials: Windows OS primarily caches the last 10/25 logon hashes by default –which is essentially configurable via the registry. This enables the users to connect to their workstations when the system is not connected to the domain.
- Local Security Authority Secret (LSA): LSA secrets are located in the registry (Security/Policy/Secrets) which primarily allow windows OS services to execute with user privileges. The services include auto logins, Virtual Private Networks (VPNs), service accounts, etc.
- Local Security Authority Subsystem Service Process (LSASS): When logging into a Windows machine, either locally or in a domain, credentials are stored in the LSASS process in memory. This is primarily used to allow the user to access other resources on the network that they are authorized to access without having to re-authenticate. The stored formats can be plaintext (reversible encryption), NT and LM hash, and Kerberos tickets.
- Credential Store Manager: It is one of the username/password digital vault (password managers) available with Windows (7 and higher) to store windows and web credentials. The details are stored on the Provided.
- Active Directory Domain database (NTDS.DIT): This is used as a data store, storing all the Username/password details for users and associated workstations, across the AD DC in a given domain Environment (%SystemRoot%\NTDS folder).
- Clipboard: As credentials aren’t as smooth to always remember, especially when they have multiple special characters or is alphanumeric, users use password managers such as LastPass, KeePass, etc. In situations, wherein these credentials are copied to the clipboard by the users, an adversary can potentially retrieve them via various tactics.
- Security Support Provider (SSP): SSP is fundamentally an API used by the Windows OS for executing authentications of windows login. It’s a DLL file that provides security packages to other applications. Within Local Security Authority (LSA), SSP DLL stacks itself, assembling itself as a start-up process. Post loading in LSA, it can potentially access all the window’s credentials. The configurations for this file are stored in two different registry keys and you find them in the following locations: HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Security Packages. It can be exploitable while using Mimikatz to gather the credentials in plaintext.
- Applications: Various applications store credentials such as Putty, WinSCP, CoreFTP, FileZilla, VNC, Outlook, etc. They can be exploited and the credentials that they store can be dumped while using Tools such as Powershell Empire, Metasploit FrameWork.
- Wi-Fi Passwords: All the Wi-Fi password with their respective SSID are stored in an XML file. The location of these files is C:\ProgramData\Microsoft\Wlansvc\Profiles\Interfaces\***
- Browser: Browsers generally tend to save username and password within a credential store, in an encrypted manner, nevertheless multiple tactics exist wherein bad actors could potentially extract plaintext credentials from corresponding browsers. The windows systems stored the encrypted credentials for the chrome browser at – AppData\Local\Google\Chrome\User Data\Default\Login Data. It can be exploitable while using Mimikatz to gather the credentials in plaintext or bypassing the encrypted credentials to the Windows API function CryptUnprotectData, which uses the victim’s cached logon credentials as the decryption key.
- DC Replication: Users who are in one of the following admin groups Administrators, Domain Admins, Enterprise Admin groups, or computer accounts on the domain controller can simulate a replication process towards the Domain Controller by abusing the domain controller’s API Interface. During this process, they can run DCSync to pull password data from the Active Directory which may include current and historical hashes of potentially useful accounts such as KRBTGT and Administrators. It can be exploited with the “Lsadump module in Mimikatz”.
We have segregated the mitigation practices into 7 key techniques as follows:
Proper use of passwords
- It is highly recommended to not save passwords in cleartext across your system, files, browser, or any other applications
- Enforce Strict Password Policies (Length and Complexity)
- When possible use dissimilar passwords for every account across applications and web sites
- Use Unique Local Administrator Account Passwords
- Enforce multi-factor authentication (MFA) for all network and cloud accounts
Privileged Identity Management:
- Reduce the number of Domain/Enterprise Admins as per the identified business risks
- Limit administrative privileges and access (adhere to the principle of least privilege)
- Avoid using highly privileged accounts for remote interactive sessions
- Ensure privileged users are part of “Protected Users” Group
- Minimize the groups (& users) with DC admin/logon rights
Systemic technology capability and solutions:
- Keep firewall/defender enabled and up to date rules configured as per the business sanctioned services
- Keep antivirus and anti-malware solutions up to date and configure them to automatically conduct regular scans
- Enable host-based firewalls and restrict internal communications to limit unnecessary lateral movement.
- Disable SMB v1 and similar legacy protocols completely.
- Implement RDP Restricted Admin mode – This ensures that admin credentials are not stored on the target RDP computer – reducing the number of systems the credentials.
- Use the latest version of the operating system and applications.
- Use technology capabilities or tools such as Credential Guard to protect the LSASS process from credentials dumping for windows.
- Use Application Whitelisting with tools such as AppLocker
- Keep your employees/employers aware of the potential threats and business risks against credential dumping
- Recommend employees to manually go to the login page of the portal instead of following a link.
Limit workstation to workstation communication:
- Restrict inbound NetBIOS, SMB traffic using the Windows Firewall
- Separation by VLAN segmentation of workstations
Enable stricter Kerberos security:
- Disable LM & NTLM (force Kerberos)
- Short validity for tickets
- No account delegation
- Perform regular vulnerability scans to identify missing security updates.
- Using EDR Solution to detect an anomaly, credentials dumping, or lateral movement activities.
The following are some of the ways via which potential attacks can be detected via continuous monitoring:
- Monitor for unexpected processes interacting with lsass.exe
- Continuous monitoring across the registry, command-line arguments and endpoint processes for unknown executions of services
- Monitor AV Detections with signatures that indicate Credentials Dumping.
- Monitor Anomaly Behavior.
Hunting for Credentials Dumping by AV Detects
Attack tactics and sophistication are increasing and getting more complex year by year. To identify and remediate such attack patterns, complete visibility is required across the network – inter/intra network communications between stations and running processes across endpoints.
Although the modus operandi of the attacks vary across bad actor groups, the target will always be the workstations and storage where the credentials are stowed.
Thus, in order to monitor these methods, the approach of the attacks must be recognized and adequate controls to mitigate the threats should be created consequently. By recognizing the attacking Adversary Group and identifying their attack phases (at what stage they are currently – Execution, Persistence, etc), the risk of such attacks can be identified and mitigated.
References and Credits:
Stay Safe with TrustNet!