Skip Navigation
Get a Demo
 
 
 
 
 
 
 
 
 
Resources Blog Threat detection

Detecting credential access without losing cred

Experts from Red Canary, MITRE, and CrowdStrike share detection and testing guidance to keep credentials out of the wrong hands.

Tess Mishoe
Originally published . Last modified .

Why do adversaries like credentials so much? What can we do to keep their hands off of our credentials? In the latest installment of our Detection Series webinars, we gathered experts from Red Canary as well as some friends from MITRE and CrowdStrike to show you where to look for credential access activity, how to develop detection analytics, and ways to test your visibility. You can watch the full recording here, or check out video highlights below.

What is credential access? Why should I care?

Credential Access (TA0006) consists of techniques for stealing credentials… Techniques used to get credentials include keylogging, credential dumping, or Token Theft. Using legitimate credentials can give adversaries access to systems, make them harder to detect, and provide the opportunity to create more accounts…” – MITRE ATT&CK

Around the world, adversaries use stolen usernames and passwords to access systems. With credentials in hand, an adversary doesn’t need to find a niche vulnerability or dig through a network of systems for open access—they already have the proverbial keys to the kingdom. Whether it be collected via social engineering, a dark web marketplace, or a prior breach, these credentials hold extensive value in their potential to wreak havoc in the wrong hands.

Access brokers make millions (if not billions) per year on selling access. Credentials gained through access brokers also make attacks happen faster; the average time to leverage access gained from an access broker is an hour and 40 minutes, according to CrowdStrike’s Jared Myer.

Credential access can also allow for ease of lateral movement in networks that aren’t properly segmented. Many organizations also lack identity logon event monitoring, which means that suspicious activity can continue unabated.

Whether it’s modern malware, criminals, or espionage groups, nearly every kind of adversary steals credentials.

Red Canary’s Jimmy Astle offers further insight into the “who,” “what,” and “where” of credential access.

 

 

Visibility and collection

Credentials are stored nearly everywhere! It’s part of what makes them so difficult to keep track of. MITRE ATT&CK’s Casey Knerr expands the maze of credentials by telling us, “cloud and on-prem infrastructure are connected.”

In Windows alone, possible targets for adversaries include:

  • Local accounts
  • Domain accounts
  • Active directory databases (NTDS.dit)
  • An Active Directory-integrated system includes cached credentials
  • Kerberos (known as Kerberoasting)
  • Browsers
  • Password managers
  • Windows Credential Manager

 

In Linux/macOS, targets include some of the application-based stores above (browsers and password managers) as well as:

  • Hash dumping (which also requires offline cracking)
  • SSH keys
  • Apache2
  • OpenSSH

 

Cloud-based targets include operating systems deployed into cloud containers, but also include cloud infrastructure:

  • ~/.aws/credentials
  • Cloud metadata API
  • OAuth (exploited through malicious OAuth applications)
  • Hybrid identities:
    • Active directory federation services
    • Pass-through authentication
    • Password hash synchronization

 

These possible targets are all very important to incorporate into detection analytics. Without visibility into the activity surrounding targets, we can’t know if credentials have been stolen or tampered with. Adversaries today give special focus on cloud technologies, as credentials tend to be abundant due to unorganized administration and credential management.

Rachel Schwalk, a Detection Engineer at Red Canary, walks us through examples of where your credentials live in Windows and Linux/MacOS environments, and how adversaries might threaten to steal them.

 

Detection

Now that we know where our data is and why it’s important to protect it, we can talk a little more about detecting and preventing attempts to access credentials. Incorporating the above common targets, we can create detection rules that watch for activity, starting with our most commonly seen techniques (at 60% of events seen): those using LSASS memory.

Windows

Rundll32 Dumping LSASS Memory

Adversaries often leverage Rundll32.exe’s minidump function or comsvcs to empty the memory contents of LSASS into a DMP file. To account for adversaries pulling data using comsvcs.dll or minidump, look for the following:

process == rundll32.exe
&&
command_includes (minidump || comsvcs)

Some adversaries will use tools like procdump, process explorer, or Mimikatz to pull LSASS memory. For these instances, detect on file modification using non-LSASS processes:

file == lsass.dmp $
&&
processes != lsass

Security Account Manager (SAM)

The Security Account Manager (SAM) is a database file that contains local files for the host, including credentials. Windows Registry Tool (reg.exe) can be used to export hives containing credentials for offline access. To find these instances, work from the following pseudo-detector: 

process == reg.exe
&&
command_includes (save ||export) && (sam ||security || system).

 

AD database dumping (NTDS.dit)

While Active Directory dumping isn’t as common as LSASS techniques, it is a prime target. Adversaries use ntdsutil.exe or tools like diskshadow to gain access to the NTDS.dit file. The following detection analytic will find suspicious changes for Windows domains:

process == ntdsutil
&&
file == ntds.dit
||
command_includes (ifm create)
||
command_includes (ntds.dit && copy)

 

Kerberoasting

Kerberoasting involves an adversary acting as a user requesting tickets from a Kerberos server in an attempt to contain an encrypted password. Kerberoasting can be detected using the following:

 

Windows Credential Manager

The Credential Manager stores credentials for signing into websites, applications, and devices. Detecting attempts to access the credential manager via rundll32.exe (whether it be through the Key Manager process or credwiz). Also consider enabling the “Do not allow storage of passwords and credentials for network authentication” setting that will prevent network credentials from being stored by the Credential Manager.

process == rundll32
&&
command_includes == (keymdr.dll && KRShowKeyMgr)
||
child_process == credwiz
&&
file == *.crd

Another possible adversarial tactic is to use the vaultcmd process to list credentials outright.

process == vaultcmd
&&
command_includes (listcmd)

 

Browsers

Many threats can retrieve browser credentials. Browser login data can be accessed at AppData\Local\Google\Chrome\User Data\Default\Login Data—consider monitoring this directory for access and modifications.

 

Linux/macOS

Keychain

The macOS credential management system that stores account names, passwords, private keys, certificates, sensitive application data, payment data, and secure notes is known as Keychain. To detect changes to Keychain, use the following:

process == security
&&
command_includes (dump-keychain)

 

Offline password cracking

Detections for offline password cracking techniques focus on the reading of etc/shadow, which is only readable by the root user by default.

file == etc/shadow || etc/passwd access

The utility unshadow can be used to combine the two files in a format suited for password cracking utilities.

Unsecured credential access

Adversaries may look for unsecured credentials to move laterally and do so by digging in the bash_history file for prior use of credentials and will look for private keys in ~/.ssh. Detections should focus on the following attempted actions:

process == grep
&&
command_includes (etc/fstab) && (cred || password || login)
||
command_includes (~/.ssh)
||
command_includes (~.bash_history)

 

Application

Telegram exfiltration

Information stealers have been observed connecting to the Telegram-shortened URL t.me. Unsigned binaries shouldn’t be connecting to that domain, so monitoring with the following logic should filter out legitimate activity:

process != browsers || telegram application
&&
net_conn == t.me

 

Browser modules

Stealers of Chromium and Mozilla browser data will frequently load in specific modules related to browser data. Search for unsigned processes attempting to load these modules:

process == unsigned
&&
process != browsers
&&
mod_load = (freebl3.dll && sqlite3.dll && mozglue.dll && nss3.dll && softokn3.dll)

 

Directory changes and file modifications

Stealers will often make file modifications in unusual directories (such as AppData\LocalLow). Search for files being created with names like:

  • Passwords.txt
  • \_cookies\google_chrome_new.txt
  • Forms.txt
  • _screen_desktop.jpeg
  • _information.txt
  • screenshot.jpg
  • cookies.txt
  • system_info.txt

 

Cloud

AWS metadata API

To ensure that credentials aren’t being leaked through the AWS API, detect on the webserver (httpd, nginx, apache) spawning a command line containing /meta-data/iam/security-credentials and on credentials intended for specific instances being used by an IP address owned by a different cloud account.

.aws/credentials

Adversaries gaining access to a credentials file are usually going to try to export it, so detect on the use of curl with a command line containing .aws/config. Make sure to filter out any domains that should be able to access the credentials file:

process == curl
&&
command_includes userfile=@/root/.aws/credentials

 

Credential stuffing

While this strategy is not very subtle and can create a lot of logs, adversaries often attempt credential stuffing using purchased credential dumps or past breach data. Detecting on multiple failed logins from a single IP within a short period of time allows for notification on this type of activity.

MFA exhaustion

This attack type is newer and gaining in popularity thanks in part to reporting surrounding the Lapsus$ breach of Uber. MFA exhaustion/fatigue refers to when users are spammed with authentication requests until they eventually accept. This can be monitored via a similar method to credential stuffing, and can be mitigated in much the same way—by putting a limit and monitoring on the amount of unauthenticated push requests that can be made in a defined period of time.

Malicious OAuth applications

Managing least privilege is one of the keys to dealing with malicious OAuth applications. Applications that request excessive or high-value permissions should be alerted. Applications that only a small number of users have been given access to are similarly suspect.

Hybrid identities

Registration of new passthrough authentication (PTA) agents does not occur often and should be monitored. Adversaries that are using Active Directory Federation Services (AD FS) as a vector may load unsigned or otherwise suspicious DLLs into the service or use unusual sign-in IDs, perhaps not requesting a Kerberos ticket when attempting to log in.

The Azure Unified Audit Log and sign-in logs will provide information on logins that may have unusual characteristics, like an abnormal country, IP, or time.

Rachel continues on to discuss ways to leverage optics and IT controls to detect, prevent, and mitigate Credential Access threats.

 

Testing

Using a testing framework to verify detection efficacy is important. We use Atomic Red Team and Invoke-Atomic to create a user-friendly and reproducible testing environment. Atomic tests aim to emulate common adversary tactics to provide insight into how well defended an environment is against those attacks.

Jimmy closes out the webinar with a nod to Atomic Red Team contributions that allow for the testing of Golden SAML.

 

 

The Trainman’s Guide to overlooked entry points in Microsoft Azure

 

Inside the 2024 Threat Detection Report

 

Better know a data source: Files

 

Why adversaries have their heads in the cloud

Subscribe to our blog

 
 
Back to Top