Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
4,308 detections
Filters
Last updated
All Time
Detection languages
2,033
733
398
298
243
Contributors
1,048
740
503
372
239
Categories
20,439
11,829
5,873
5,151
4,864
4,308
Platforms
2,570
792
615
382
319
Products / Services
767
739
659
512
348
MITRE Techniques
2,347
917
847
814
635
CVEs
9
6
6
6
5
IDS Classtypes
81
66
44
14
14
IDS Protocols
136
79
11
7
4
Detects the execution of a browser process with the remote debugging port argument enabled. This technique is used by infostealers like Stealerium and Phantom Stealer to bypass browser security and steal credentials and cookies.
Detects processes accessing sensitive browser files which may indicate credential theft from web browsers.
Detects Salesforce Object Query Language (SOQL) queries that may be attempting to access or exfiltrate sensitive credentials like passwords, API keys, or tokens stored within Salesforce objects. This activity was observed in the UNC6395 campaign where attackers targeted AWS keys, Snowflake tokens, and passwords.
Detects attempts to list or dump macOS Keychain data using the built-in 'security' utility. This activity can be indicative of credential theft attempts by an adversary.
Detects a user accessing the keys for multiple distinct Azure Storage Accounts in a short period. This behavior is associated with the threat actor Storm-0501, who performs this action for credential access prior to data exfiltration.
Detects a sequence of commands on Cisco IOS devices used to capture network traffic, specifically targeting TACACS+ on TCP port 49, and then exfiltrate it. This technique, detailed in a CISA advisory on PRC state-sponsored actors, is used to harvest credentials from network traffic.
Detects the use of the PsLogList utility to dump Windows event logs (security, application, system) or to clear them. This activity can be indicative of account discovery attempts or anti-forensics techniques by adversaries.
This rule detects the execution of 'cmdkey.exe' with the '-l' argument, which is used to list cached credentials on a Windows system. This activity is often associated with reconnaissance for cached credentials by adversaries.
This rule detects the use of 'esentutl.exe' to copy sensitive files containing credential data, such as the Security Account Manager (SAM) database or the NTDS.dit file. It specifically looks for command-line arguments indicative of Volume Shadow Copy operations or direct paths to known sensitive files within the 'config', 'repair', or 'windows\ntds' directories.
The analytic identifies a possible non-common browser process accessing its browser user data profile. This tactic/technique has been observed in various Trojan Stealers, such as SnakeKeylogger, which attempt to gather sensitive browser information and credentials as part of their exfiltration strategy. Detecting this anomaly can serve as a valuable pivot for identifying processes that access lists of browser user data profiles unexpectedly. This detection uses a lookup file `browser_app_list` that maintains a list of well known browser applications and the browser paths that are allowed to access the browser user data profiles.
The following analytic detects non-Chrome processes attempting to access the Chrome extensions file. It leverages Windows Security Event logs, specifically event code 4663, to identify this behavior. This activity is significant because adversaries may exploit this file to extract sensitive information from the Chrome browser, posing a security risk. If confirmed malicious, this could lead to unauthorized access to stored credentials and other sensitive data, potentially compromising the security of the affected system and broader network.
Detects the usage of "cmdkey.exe" with the '-g', '-u', and '-p' command-line arguments to add new generic credentials. This activity can be used by adversaries to store credentials for later use, potentially before connecting to remote services like RDP.
This rule detects the use of 'Rpcping.exe' to force NTLM authentication by sending an RPC test connection to a target server. This technique can be used by attackers to capture NTLM hashes, which can then be cracked offline to obtain user credentials.
Detects the enumeration of loaded modules or DLLs within processes using 'tasklist.exe' with the '-m' flag. This activity is often performed by attackers to identify the Process ID (PID) associated with a specific DLL (e.g., 'rdpcorets.dll') for subsequent actions like dumping process memory to extract credentials.
Detects attempts to enable WDigest credential caching by modifying the 'UseLogonCredential' registry value. This allows plaintext credentials to be stored in memory, which can then be harvested by attackers. The threat group ShadowSilk has been observed using this technique.
Detects when new credentials are added to an Entra ID Service Principal, followed by a successful login from that principal within a short time frame. This pattern is consistent with MURKY PANDA TTPs for lateral movement and persistence in cloud environments.
This KQL query searches the ExposureGraphNodes table in Microsoft Defender XDR or Sentinel to identify user accounts whose credentials have been leaked. It focuses on nodes categorized as "identity" and labeled as "user", then extracts detailed identity-related properties such as: Display name, UPN, email address, Account status (enabled/disabled), Job title, department, phone, address, Source provider (e.g., Azure AD, on-prem AD), Account creation time, and whether the account's credentials have been leaked. The query filters and enriches this data, and presents it in a clean, readable format for hunting or triage.
Detects the execution of 'dscl . authonly' by a script interpreter, a technique used by Odyssey Stealer to validate user passwords obtained from a malicious dialog prompt.
FOCI tokens (Family of Client IDs tokens) are special refresh tokens that allow multiple applications within the same "family" to share authentication tokens. This means that once a user authenticates with one application, they can access other applications in the same family without needing to re-authenticate. For adversaries, these are very interesting tokens to abuse since they can access a normal application (Microsoft Teams for example), and reuse that refresh token to access another application (like Azure CLI).
To detect a suspicious foci token combination, we look for all the logins using foci tokens and group them by Session ID (since these belong to the same session). Then we take the first login where no refresh token was provided, and look at the logins that used refresh tokens as incomming token types within that same session. If the second login application is one that is typically abused by adversaries and the application for the first login is a 'normal' application, we flag the event.
This version is the V2 version for this query in this repo, which also flags when an adversary is using the same application to get new access tokens but with another scope (compared to V1 which does not do this). The v2 version focusses more on RoadTool detection tho, while the v1 detection is more broad.
Some organizations have a high BP hit count on Microsoft Azure CLI. To limit those hits, you have three finetune options to enable in the query:
- Only alert when first and second login has X time between each other (default 90 minutes if enabled)
- Only alert on Microsoft Azure CLI when Global Administrator scope is used in token
- Only alert on Microsoft Azure CLI when Global Administrator scope is used in token and request came from a non-compliant device
To detect a suspicious foci token combination, we look for all the logins using foci tokens and group them by Session ID (since these belong to the same session). Then we take the first login where no refresh token was provided, and look at the logins that used refresh tokens as incomming token types within that same session. If the second login application is one that is typically abused by adversaries and the application for the first login is a 'normal' application, we flag the event.
This version is the V2 version for this query in this repo, which also flags when an adversary is using the same application to get new access tokens but with another scope (compared to V1 which does not do this). The v2 version focusses more on RoadTool detection tho, while the v1 detection is more broad.
Some organizations have a high BP hit count on Microsoft Azure CLI. To limit those hits, you have three finetune options to enable in the query:
- Only alert when first and second login has X time between each other (default 90 minutes if enabled)
- Only alert on Microsoft Azure CLI when Global Administrator scope is used in token
- Only alert on Microsoft Azure CLI when Global Administrator scope is used in token and request came from a non-compliant device
This detection specifically flags credentials being added to the Connect Sync Application in Entra ID, a technique known to have persistance from On-premise AD DS to Entra ID. It tries to look at both certificate, client secret, and federated credentials being added, and tries to remove legitimate renewal processes. Since the legitimate renewal process first adds a new certificate only te remove the old one short after, we by default allow for a maximum of 1 minute between the certificate create and delete events.
FOCI tokens (Family of Client IDs tokens) are special refresh tokens that allow multiple applications within the same "family" to share authentication tokens. This means that once a user authenticates with one application, they can access other applications in the same family without needing to re-authenticate. For adversaries, these are very interesting tokens to abuse since they can access a normal application (Microsoft Teams for example), and reuse that refresh token to access another application (like Azure CLI).
To detect a suspicious foci token combination, we look for all the logins using foci tokens and group them by Session ID (since these belong to the same session). Then we take the first login where no refresh token was provided, and look at the logins that used refresh tokens as incomming token types within that same session. If the second login application is one that is typically abused by adversaries and the application for the first login is a 'normal' application, we flag the event.
We added a second version for this query in this repo, to also flag when an adversary is using the same application to get new access tokens but with another scope. The v2 version focusses more on RoadTool detection tho, while this detection is more broad.
Some organizations have a high BP hit count on Microsoft Azure CLI. To limit those hits, you have three finetune options to enable in the query:
- Only alert when first and second login has X time between each other (default 90 minutes if enabled)
- Only alert on Microsoft Azure CLI when Global Administrator scope is used in token
- Only alert on Microsoft Azure CLI when Global Administrator scope is used in token and request came from a non-compliant device
To detect a suspicious foci token combination, we look for all the logins using foci tokens and group them by Session ID (since these belong to the same session). Then we take the first login where no refresh token was provided, and look at the logins that used refresh tokens as incomming token types within that same session. If the second login application is one that is typically abused by adversaries and the application for the first login is a 'normal' application, we flag the event.
We added a second version for this query in this repo, to also flag when an adversary is using the same application to get new access tokens but with another scope. The v2 version focusses more on RoadTool detection tho, while this detection is more broad.
Some organizations have a high BP hit count on Microsoft Azure CLI. To limit those hits, you have three finetune options to enable in the query:
- Only alert when first and second login has X time between each other (default 90 minutes if enabled)
- Only alert on Microsoft Azure CLI when Global Administrator scope is used in token
- Only alert on Microsoft Azure CLI when Global Administrator scope is used in token and request came from a non-compliant device
Page 169 of 206