Detections
Explore public detection logic contributed by the community across SIEM and rule languages.
53 detections
Filters
Last updated
All Time
Detection languages
30
8
4
4
4
Contributors
17
7
6
4
4
Categories
38
28
22
11
9
Platforms
40
7
7
5
5
Products / Services
30
9
8
6
5
MITRE Techniques
18,114
15,633
12,576
8,388
6,214
IDS Classtypes
3
IDS Protocols
3
This detection identifies when a Managed Identity (Service Principal) executes a 'RunCommand' on a virtual machine. This activity is a key indicator of lateral movement, where an attacker, having compromised a resource with a Managed Identity, uses that identity's permissions to execute code on another VM.
Detects the use of Azure VM Run Command to execute PowerShell scripts that attempt to retrieve workload identity tokens from the Azure Instance Metadata Service (IMDS) endpoint. This activity could indicate an attacker attempting to steal credentials or escalate privileges within the Azure environment.
Detects the installation or execution of ScreenConnect originating from the Azure Run Command extension context. This indicates potential unauthorized remote access tool deployment.
Detects enumeration of Docker containers and images
This rule detects HTTP traffic directed to 'management.azure.com' with a URI containing 'runCommand'. This pattern indicates an attempt to execute a command on an Azure Virtual Machine using the Azure Run Command feature. This activity is often associated with administrative actions or potential malicious execution on cloud resources.
This rule detects when an AWS Systems Manager (SSM) Run Command is executed on an EC2 instance. It specifically looks for HTTP traffic to 'ssm.amazonaws.com' with the URI containing 'SendCommand'. This indicates an attempt to remotely execute commands on an EC2 instance via AWS SSM.
This rule detects HTTP POST requests to the GCP OS Login API endpoint 'oslogin.googleapis.com'. Such requests could indicate an attempt to execute commands on a Google Cloud instance using the OS Login feature, which is a common method for managing SSH access to instances.
Suspicious Azure VM Extension Deployment
Cortex XDR
This rule detects the deployment of suspicious or potentially malicious extensions on Azure Virtual Machines. These extensions, such as CustomScriptExtension, RunCommandHandler, DSCExtension, AADLoginForWindows, and NetworkWatcherAgent, can be abused by adversaries for various purposes including remote code execution, account manipulation, and network reconnaissance. Monitoring their deployment can help identify unauthorized activity within an Azure environment.
Azure VM RunCommand Activity
Cortex XDR
This rule detects activity related to Azure VM RunCommand, which allows execution of scripts on virtual machines without requiring RDP/SSH access. It specifically looks for 'WRITE', 'ACTION', 'DELETE', and 'READ' operations, filtering for successful or accepted statuses and valid identities. This activity can indicate an attacker executing commands or performing post-execution cleanup.
Detects the PLASMAGRID implant and its modules by their SHA-256 hash values. The implant is the final payload of the Coruna exploit kit, designed to steal cryptocurrency and other financial information from compromised iOS devices.
This rule detects potential lateral movement within Azure by identifying instances where a Managed Identity of one Virtual Machine (VM) is used to execute commands on another VM. It specifically looks for Azure Activity logs where the caller is a Service Principal, the 'InitiatedBy' field (xms_mirid) contains 'resourcegroups', and the operation name indicates a 'runCommand' or a 'Microsoft.Compute' action. This combination suggests that a Managed Identity is being leveraged to perform actions across VMs, which could be indicative of an attacker moving laterally after compromising a VM with an attached Managed Identity.
This detection identifies when a Managed Identity (Service Principal) successfully executes a 'RunCommand' on an Azure virtual machine. This activity is a key indicator of lateral movement, where an attacker, having compromised a resource with a Managed Identity, uses that identity's permissions to execute code on another VM.
Detects potential lateral movement attempts within Azure by a Service Principal (Managed Identity) executing 'runCommand' or other compute operations on virtual machines. This activity could indicate an attacker abusing a compromised Managed Identity to gain access to and control other resources.
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.
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
This might be one of the silliest detections I have created. But since there is a Beacon Object File out there which can be used to directly request Entra ID access tokens from an active beacon on a device using a specific User Agent, we can easily detect this beacon file by flagging the funny user agent and / or scope identifier that is used.
This detection identifies when Microsoft Copilot Studio agents are created in your organization's tenant. This activity is significant as the default behavior in Copilot agent creation is to configure a new service principal with cloud app administrator role.
Copilot agents can be found in the Microsoft Admin Portal https://admin.microsoft.com/Adminportal/Home#/copilot/agents
Copilot agents can be found in the Microsoft Admin Portal https://admin.microsoft.com/Adminportal/Home#/copilot/agents
This detection rule identifies when Microsoft Copilot Studio agent properties are modified in your organization's tenant. This activity is significant as the default behavior in Copilot agent creation is to configure a new service principal with cloud app administrator role.
Copilot agents can be found in the Microsoft Admin Portal https://admin.microsoft.com/Adminportal/Home#/copilot/agents
Copilot agents can be found in the Microsoft Admin Portal https://admin.microsoft.com/Adminportal/Home#/copilot/agents
KQL Query from file: Microsoft Entra Identity Attack Threat Detection
KQL Query from file: Detecting FIDO2 Passkey Abuse
Page 2 of 3