Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
2,831 detections
Filters
Last updated
All Time
Detection languages
1,374
495
363
281
175
Contributors
848
453
393
252
188
Categories
20,440
11,814
5,871
5,145
4,864
2,831
Platforms
1,448
916
693
670
264
Products / Services
994
700
613
469
216
MITRE Techniques
1,239
911
484
481
388
CVEs
6
5
2
1
1
IDS Classtypes
15
10
6
5
3
IDS Protocols
39
KQL Query
Detects when a transfer lock was removed from a Route 53 domain. It is recommended to refrain from performing this action unless intending to transfer the domain to a different registrar.
Number of VM creations or deployment activities occur in Azure via the azureactivity log.
Detects the use of TruffleHog for AWS credential validation by identifying GetCallerIdentity API calls where the userAgent indicates TruffleHog.
Threat actors leverage TruffleHog to enumerate and validate exposed AWS keys.
Successful exploitation allows threat actors to confirm the validity of compromised AWS credentials, facilitating further unauthorized access and actions within the AWS environment.
Threat actors leverage TruffleHog to enumerate and validate exposed AWS keys.
Successful exploitation allows threat actors to confirm the validity of compromised AWS credentials, facilitating further unauthorized access and actions within the AWS environment.
Detects the use of the EnableRegion command in AWS CloudTrail logs.
While AWS has 30+ regions, some of them are enabled by default, others must be explicitly enabled in each account separately.
There may be situations where security monitoring does not cover some new AWS regions.
Monitoring the EnableRegion command is important for identifying potential persistence mechanisms employed by adversaries, as enabling additional regions can facilitate continued access and operations within an AWS environment.
While AWS has 30+ regions, some of them are enabled by default, others must be explicitly enabled in each account separately.
There may be situations where security monitoring does not cover some new AWS regions.
Monitoring the EnableRegion command is important for identifying potential persistence mechanisms employed by adversaries, as enabling additional regions can facilitate continued access and operations within an AWS environment.
Detects the use of AWS IAM Policy Simulator APIs (SimulatePrincipalPolicy, SimulateCustomPolicy), which can indicate a threat actor is enumerating permissions to find privilege escalation paths.
Detects modification of an AWS IAM role's trust policy to include a principal from an unknown or untrusted AWS account. This is a common persistence technique used by attackers to maintain access to a compromised environment by allowing their external account to assume the role.
This rule identifies statistically unusual or first-time Azure operations performed by a principal (user or service principal). It uses a risk-based alerting model, assigning a higher risk score to operations defined as high-risk. The rule establishes a baseline of normal activity over 30 days and alerts when current activity significantly deviates from this baseline or when an operation is observed for the very first time for a given identity.
The analytic detects the creation or update of a new Azure Automation Runbook within an Azure tenant. It leverages Azure Audit events, specifically the Azure Activity log category, to identify when this operation occurs. This activity is significant because adversaries with privileged access can use Runbooks to maintain persistence, escalate privileges, or execute malicious code. If confirmed malicious, this could lead to unauthorized actions such as creating Global Administrators, executing code on VMs, and compromising the entire Azure environment.
The analytic detects the creation of a new Azure Automation account within an Azure tenant. It leverages Azure Audit events, specifically the Azure Activity log category, to identify when an account is created or updated. This activity is significant because Azure Automation accounts can be used to automate tasks and orchestrate actions across Azure and on-premise environments. If an attacker creates an Automation account with elevated privileges, they could maintain persistence, execute malicious runbooks, and potentially escalate privileges or execute code on virtual machines, posing a significant security risk.
The analytic detects the creation of a new Automation Runbook Webhook within an Azure tenant. It leverages Azure Audit events, specifically the "Create or Update an Azure Automation webhook" operation, to identify this activity. This behavior is significant because Webhooks can trigger Automation Runbooks via unauthenticated URLs exposed to the Internet, posing a security risk. If confirmed malicious, an attacker could use this to execute code, create users, or maintain persistence within the environment, potentially leading to unauthorized access and control over Azure resources.
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 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 data theft activity from Salesforce instances by the threat actor UNC6395, who leveraged compromised OAuth tokens associated with the Salesloft Drift third-party application. The detection is based on suspicious user agents and known malicious IP addresses used by the threat actor, specifically targeting the 'Drift' connected application.
Detects the use of known malicious or suspicious User-Agent strings associated with the UNC6395 data theft campaign targeting Salesforce instances.
The following analytic detects attempts to impair or disable AWS security services by monitoring specific deletion operations across GuardDuty, AWS WAF (classic and v2), CloudWatch, Route 53, and CloudWatch Logs. These actions include deleting detectors, rule groups, IP sets, web ACLs, logging configurations, alarms, and log streams. Adversaries may perform such operations to evade detection or remove visibility from defenders. By explicitly pairing eventName values with their corresponding eventSource services, this detection reduces noise and ensures that only security-related deletions are flagged. It leverages CloudTrail logs to identify specific API calls like "DeleteLogStream" and "DeleteDetector." This activity is significant because it indicates potential efforts to disable security monitoring and evade detection. If confirmed malicious, this could allow attackers to operate undetected, escalate privileges, or exfiltrate data without triggering security alerts, severely compromising the security posture of the AWS environment.
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.
Detects a user self-assigning access to a large number of applications in Okta within a short time frame. This behavior is associated with the threat group UNC3944 (Scattered Spider) for privilege escalation and lateral movement across SaaS applications.
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
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
Detects suspicious activities in Salesforce environments consistent with the TTPs of the ShinyHunters threat group (also tracked as UNC6040/UNC6240). The attack involves social engineering (vishing) to trick users into authorizing malicious OAuth applications that impersonate legitimate tools like 'Salesforce Data Loader'. This rule looks for key indicators such as the installation of unreviewed packages, creation of impersonating connected apps, elevation of permissions to 'full' API access, and large data exports.
Page 110 of 135