Update v8.19.28
editUpdate v8.19.28
editThis section lists all updates associated with version 8.19.28 of the Fleet integration Prebuilt Security Detection Rules.
| Rule | Description | Status | Version |
|---|---|---|---|
AWS Cognito Unauthenticated Identity Pool Credentials Issued |
Identifies AWS CloudTrail data events where an unauthenticated identity successfully retrieves temporary AWS credentials from a Cognito Identity Pool via GetCredentialsForIdentity. Cognito Identity Pools can be configured to allow unauthenticated (guest) access, intended for scenarios like anonymous app analytics, but a pool that grants those anonymous identities meaningful IAM permissions becomes a public, unauthenticated path to real AWS credentials. Adversaries who discover an identity pool ID (often embedded in mobile app binaries, web app JavaScript, or public source repositories) can call GetId followed by GetCredentialsForIdentity with no login token at all to obtain temporary credentials, then use them to access whatever the pool’s unauthenticated role permits. This is a New Terms rule that limits alerting to identity pools that have not been observed issuing credentials to an unauthenticated caller before, since some applications intentionally and continuously use guest access as part of normal operation. |
new |
1 |
AWS CloudTrail Management Events Disabled via PutEventSelectors |
Detects CloudTrail PutEventSelectors calls where the legacy event selectors explicitly set includeManagementEvents to false, disabling capture of all management API calls for that trail. Unlike StopLogging or DeleteTrail — which leave an obvious trace of the trail being stopped or removed entirely — this technique leaves the trail appearing active and healthy in the console while silently blinding defenders to subsequent IAM changes, credential operations, and resource abuse. This technique is documented in Stratus Red Team as aws.defense-evasion.cloudtrail-event-selectors and is a known pre-exfiltration step. |
new |
1 |
Identifies attempts to suppress or blind Amazon GuardDuty without deleting the detector outright. Adversaries with GuardDuty permissions can create or update a trusted IP set (CreateIPSet/UpdateIPSet) so that traffic from listed addresses is never flagged, tamper with the threat intelligence feed used to generate findings (CreateThreatIntelSet/UpdateThreatIntelSet), or soft-disable the detector via UpdateDetector with Enable set to false. All three techniques leave the detector itself intact, evading detections that only look for detector deletion. |
new |
1 |
|
Detects any attempt, successful or denied, for a member account to leave an AWS Organization via the LeaveOrganization API. Leaving an organization immediately strips the account of every Service Control Policy (SCP) guardrail the organization enforces, removes it from centralized CloudTrail aggregation, and eliminates the management account’s ability to audit or control it going forward. An adversary who has gained root or organization-management-capable access in a member account may use this technique to escape organizational security controls and operate unmonitored. Denied attempts are included because a blocked call is just as strong a signal of intent as a successful one, and is often the only trace left when the account’s default permissions correctly prevent the action. |
new |
1 |
|
Detects the closure of an AWS account via the CloseAccount API. This can be called either by the account itself (account.amazonaws.com, self-service closure) or by an AWS Organizations management account against one of its member accounts (organizations.amazonaws.com). Account closure triggers a 90-day grace period during which the account is suspended before permanent termination, and is one of the most destructive and disruptive actions available in AWS. It removes access to all resources and data in the account for the duration of the suspension. An adversary with root-level access in a member account, or management-level access to an organization, may close accounts to destroy evidence, disrupt business operations, or eliminate compute and data resources. A malicious insider could use the same action for sabotage. |
new |
1 |
|
AWS Bedrock API Key Used for Destructive or Anti-Recovery Action |
Identifies an Amazon Bedrock API key (bearer token) being used to perform a destructive or anti-recovery control-plane action, such as deleting a guardrail, deleting a custom or imported model, removing provisioned throughput, or disabling model invocation logging. Bedrock API keys are bearer credentials intended for model invocation (InvokeModel, Converse); using one to delete Bedrock resources or disable logging is inconsistent with that purpose and is characteristic of LLMjacking or sabotage following key theft. Every Bedrock API key call is identifiable in CloudTrail by "additionalEventData.callWithBearerToken" being true. The rule matches regardless of outcome, because a destructive attempt via a bearer token is suspicious even when denied. |
new |
1 |
AWS Potential Cryptomining via ECS Task Definition Deployment |
Identifies a principal that, within a short window, both registers an Amazon ECS task definition using a public / non-ECR container image at a high CPU allocation (8 or 16 vCPU) AND launches ECS workloads (RunTask, StartTask, or CreateService). Registering a public miner image at maximum compute and then launching it is the ECS/Fargate cryptocurrency-mining deployment pattern seen after credential compromise. Requiring both the mining-signature registration and a launch by the same principal confirms an actual deployment rather than a standalone (possibly benign) task-definition registration, which sharply reduces false positives from high-compute workloads that are merely registered. |
new |
1 |
Identifies the first observed occurrence, within the configured New Terms history window, of a regular IAM user successfully signing in to the AWS Management Console without multi-factor authentication. A password alone is a weaker control than password-plus-MFA, and an adversary who has phished, guessed, or otherwise obtained a user’s password can sign in directly if MFA is not enforced for that user. This rule is scoped to standard IAM users only; it excludes the AWS root user (covered by a dedicated rule) and federated/SSO sign-ins (covered by a dedicated rule that also accounts for IdP-side MFA), since MFAUsed: No is expected in both of those cases for reasons unrelated to this gap. |
new |
1 |
|
AWS Bedrock AgentCore Execution Role Used Outside Its Runtime |
Identifies an Amazon Bedrock AgentCore execution role (an AssumedRole identity whose role name begins with "AgentCore-" or contains "BedrockAgentCore") making an AWS API call to a service it has not previously called. AgentCore runtimes normally interact only with Bedrock inference, AgentCore data-plane, and observability services (CloudWatch Logs, X-Ray, CloudWatch metrics), so an execution role suddenly calling STS, EC2, IAM, Secrets Manager, or other services is a strong indicator that the role’s temporary credentials were exfiltrated from the agent’s microVM (for example, via the Code Interpreter instance-metadata-service credential theft) and are being used outside the runtime for reconnaissance, privilege escalation, or lateral movement. Because the stolen credentials are recorded in CloudTrail under the execution role’s own identity, the anomalous service usage, not the identity, is the detectable signal. |
new |
1 |
Identifies an Amazon Bedrock API key phantom user (an IAM user whose name starts with "BedrockAPIKey-") acting as the caller of a non-Bedrock API request, such as IAM, STS, EC2, VPC, or KMS calls. These users are provisioned by AWS to back a Bedrock bearer token and carry the AmazonBedrockLimitedAccess managed policy, which also grants IAM, VPC, and KMS reconnaissance. A phantom user performing activity outside of Bedrock indicates its credentials are being used beyond their intended scope, which is the privilege-escalation path realized: an attacker who created standard IAM access keys for the phantom user is now using them for reconnaissance or lateral movement outside the Bedrock authentication boundary. |
new |
1 |
|
Identifies standard IAM credentials being added to an Amazon Bedrock API key phantom user, whose user name starts with "BedrockAPIKey-": either a long-term access key (CreateAccessKey) or a console password / login profile (CreateLoginProfile, UpdateLoginProfile). When a long-term Bedrock API key is generated through the AWS Console, AWS silently provisions a "BedrockAPIKey-<id>" IAM user with the AmazonBedrockLimitedAccess managed policy. That user is intended only to back a Bedrock bearer token and should never hold standard programmatic keys or interactive console access. Adding either converts a Bedrock-scoped identity into general-purpose IAM credentials that inherit the policy’s Bedrock control-plane and IAM, VPC, and KMS reconnaissance permissions and that persist after the Bedrock API key is revoked. This is the privilege-escalation and persistence pivot documented for Bedrock API key phantom users, and there is no legitimate workflow that produces it. |
new |
1 |
|
AWS Bedrock Model Prompt or Completion Containing Credentials |
Identifies an Amazon Bedrock model invocation whose prompt or completion contains an AWS access key identifier (AKIA long-term or ASIA temporary/STS, followed by 16 characters), an Amazon Bedrock API key (ABSK bearer token), or a PEM private-key block. Credentials in the model input mean an application or user is sending secrets to the model, exposing them to invocation logging, the model provider, and prompt history; credentials in the model output mean the model is emitting secrets, which can result from training-data leakage, poisoned context, or a prompt-injection-driven exfiltration attempt. Either case is a credential-exposure event that warrants immediate rotation of the affected secret. |
new |
1 |
Identifies prompts sent to an Amazon Bedrock AgentCore runtime that contain AWS access key identifiers (AKIA long-term or ASIA temporary/STS), Amazon Bedrock API keys (ABSK bearer tokens), or PEM-encoded private keys. The runtime application logs record the caller-supplied prompt; credentials embedded in a prompt are exposed to the model provider, persisted in observability logs, and may be returned in completions or used by downstream tools. This commonly indicates accidental secret leakage by a user or application, or an attempt to stage credentials for misuse through the agent. Secrets should never be passed to an agent in clear text. |
new |
1 |
|
AWS Bedrock AgentCore Runtime Prompt Targeting Credentials or Instance Metadata |
Identifies prompts sent to an Amazon Bedrock AgentCore runtime that attempt to harvest credentials or coerce the agent into exfiltrating data. The runtime application logs capture the caller-supplied prompt; this rule flags prompts that reference the cloud instance metadata service (169.254.169.254, the ECS task metadata address, or the "latest/meta-data" / "security-credentials" paths), prompts that name AWS access or secret keys directly, and prompt-injection or jailbreak language ("ignore previous instructions", "developer mode", "do anything now") combined with intent to reveal secrets, system prompts, or send data to an external endpoint. Asking an agent to read instance metadata credentials or to exfiltrate secrets is rarely legitimate and indicates an attempt to weaponize the agent for credential theft, even when the model refuses the request. |
new |
1 |
Identifies potential OAuth client ID spoofing in Microsoft Entra ID sign-in logs. Adversaries submit fabricated or non-existent application identifiers (client IDs) in Resource Owner Password Credentials (ROPC) authentication requests to the token endpoint. Because Entra ID validates the submitted credential before rejecting the request on application resolution, the resulting error code acts as a credential- and account-validity oracle while never producing a successful sign-in. By fragmenting attempts across many fictional application identifiers, adversaries evade per-application detections, rate limiting, and application-scoped Conditional Access. This rule detects a ROPC authentication that fails with error code 700016 (application not found in the directory) where no application display name resolves, which is characteristic of a spoofed client ID used for stealthy user enumeration and password spraying. |
new |
1 |
|
Entra ID Conditional Access MFA Bypass with Unusual User, Client and Source ASN |
Identifies the first observed instance of a Microsoft first-party public client application acquiring a Microsoft Graph token using single-factor (password-only) authentication while an MFA Conditional Access grant control went unenforced, for a given user, application, and source autonomous system (ASN). This pattern is associated with the Conditional Access "resource exclusion" bypass: when a tenant’s "all resources" Conditional Access policy contains at least one application exclusion, Entra ID issues tokens for low-privilege baseline scopes (User.Read, openid, profile, email) to any resource, including Microsoft Graph, without enforcing the policy’s grant controls (such as MFA). An adversary holding only a stolen password can therefore obtain a Graph token through a trusted first-party public client (for example, Microsoft Bing Search) and enumerate directory objects, even though the tenant requires MFA. Critically, the overall conditional_access_status is never "failure" for this technique (the sign-in is not blocked); it is reported as "success" or "notApplied" depending on what other policies exist in the tenant, so detections that key on Conditional Access failures will not observe it. The reliable fingerprint is in the per-policy results: a policy whose enforced grant control is MFA reports a result of "notApplied" for this sign-in, meaning the MFA requirement was silently not enforced while the single-factor, password-only sign-in still succeeded. |
new |
1 |
Detects use of the AKS (Azure Kubernetes Service) API server nodes/proxy subresource to reach a node’s Kubelet command-execution endpoints (run, exec, attach, portforward, cri). Unlike benign monitoring that scrapes /metrics and /stats, a request to these endpoints executes commands inside a pod on the node, the core of the kubeletctl and Peirates lateral-movement technique. Even a GET to /exec is command execution because the Kubelet maps the WebSocket upgrade handshake to the RBAC get verb, so nodes/proxy GET is sufficient for remote code execution. |
new |
1 |
|
Detects an AKS (Azure Kubernetes Service) identity establishing an exec session into a pod. Interactive command execution inside a workload via kubectl exec is a common post-compromise technique used to access secrets, run tooling, and expand access from a foothold container. Node, control-plane, and kube-system service account identities are excluded, so workload service accounts and users, the identities an adversary is most likely to abuse, remain in scope. |
new |
1 |
|
Identifies the first time a given VM extension name is created or updated on an Azure virtual machine or VM scale set within the rule’s lookback window. VM extensions run with high privilege on the guest (SYSTEM on Windows, root on Linux) and are a common code-execution and persistence primitive. The extension instance name is attacker-controlled and the Azure activity log records only that name, not the publisher or type, so the control plane cannot reliably identify the extension family (for example CustomScript). This rule therefore takes a type-agnostic ES |
QL new-terms approach: it derives the host and the extension instance name from |
new |
|
1 |
Entra ID User Sign-In via Unusual Legacy Authentication Client |
Detects a successful sign-in by a Member user principal through a legacy authentication client (such as Authenticated SMTP, IMAP4, POP3, Exchange ActiveSync, Exchange Web Services, or other basic-authentication clients) in Microsoft Entra ID, where the user principal has not been seen using a legacy client in the last 7 days. Legacy authentication clients rely on basic authentication, do not support modern authentication or interactive multi-factor authentication, and are frequently abused by adversaries for password spraying and account takeover because they translate into single-factor Resource Owner Password Credentials (ROPC) grants. This is a New Terms rule that surfaces the first occurrence of legacy client authentication for a given user, which is unusual in most modern environments. |
new |
1 |
Detects a non-system identity using the AKS (Azure Kubernetes Service) API server nodes/proxy subresource to reach a node’s Kubelet. Proxying through the API server reaches the Kubelet API to enumerate pods or run commands on nodes, a lateral-movement and privilege-escalation vector (kubeletctl, Peirates). Node, control-plane, and kube-system service account identities that routinely proxy for monitoring are excluded, so remaining matches, including compromised workload service accounts, are surfaced for review. |
new |
|
1 |
Identifies a Microsoft Entra ID identity-compromise chain in which a single user, within a 10-minute window, authenticates to the Device Registration Service through the Microsoft Authentication Broker (MAB) client, registers a device, and then uses the resulting Primary Refresh Token (PRT) to access a resource other than the Device Registration Service. This sequence is the core post-adversary-in-the-middle (AiTM) persistence pattern used by phishing kits such as Tycoon2FA and Kali365: after capturing a victim session, the kit registers an Azure AD-joined device to obtain a device-bound PRT, which survives user-level session revocation and password resets and grants trusted, MFA-free access. Correlating the broker sign-in, the device-registration audit event, and the follow-on PRT sign-in for the same user within a short window is a high-fidelity indicator of active account takeover. |
new |
|
1 |
Detects multiple Microsoft Entra ID device registrations by a single user, where three or more distinct devices are registered within a 15-minute window. A legitimate user enrolling a device produces a single "Register device" event; registering multiple distinct devices in quick succession is uncommon and is the fingerprint behavior of adversary-in-the-middle (AiTM) phishing kits and stolen-token replay tooling (for example Kali365), which mint a new Azure AD-joined device, and therefore a new Primary Refresh Token (PRT), per relay or replay attempt. Each registered device is a separate certificate-bound principal whose PRT survives user-level session revocation and password resets, so multiple registrations on a single low-privilege identity establish device-bound persistence at scale. |
new |
|
1 |
Entra ID Device Registration with Phishing Kit Default OS Build |
Identifies a Microsoft Entra ID device registration where the recorded cloud device operating system build is "10.0.19045.2006" and the device display name follows the default "DESKTOP-" pattern. This is the frozen default device profile observed when adversary-in-the-middle (AiTM) phishing kits such as Tycoon2FA and Kali365 register Azure AD-joined devices after capturing a victim session, in order to acquire a Primary Refresh Token (PRT) and establish persistence. The build is hardcoded by the tooling and it is uncommon for the OS build to match this exact value across an environment of otherwise patched hosts, where a current Windows 10 22H2 device reports a far higher "10.0.19045.<revision>" value. |
new |
1 |
Identifies the first occurrence of a Microsoft Entra ID device, surfaced through the Entra ID Entity Analytics device inventory, whose host name follows the default "DESKTOP-" pattern and whose operating system build is "10.0.19045.2006". This is the frozen default device profile observed when adversary-in-the-middle (AiTM) phishing kits such as Tycoon2FA and Kali365 register Azure AD-joined devices after capturing a victim session, in order to acquire a Primary Refresh Token (PRT) and establish persistence. The build is hardcoded by the tooling and differs from legitimate hosts: a patched Windows 10 22H2 device reports a far higher "10.0.19045.<revision>" value, so a device frozen at ".2006" with a default name is a high-fidelity, though evadable, indicator. |
new |
|
1 |
Detects successful GKE pod exec sessions whose command references Google Cloud instance metadata endpoints, including metadata.google.internal, computeMetadata/v1, or the link-local metadata IP 169.254.169.254. Workloads that reach the GKE metadata service from an exec session are often attempting to harvest short-lived credentials or instance attributes from the node or workload identity boundary. That behavior is high risk because it can expose cloud credentials to code running inside a container. GKE records the command in gcp.audit.labels.command.gke.io/command when an explicit command is passed to exec. |
new |
|
1 |
Detects successful GKE pod exec sessions where the executed command references high-value host or in-cluster paths: mounted service account or platform tokens, kubelet and control-plane configuration areas, host identity stores, root or home credential directories, common private-key and keystore extensions, process environment dumps, and configuration filenames suggestive of embedded secrets. Attackers with pods/exec often use these one-liners to steal credentials before lateral movement or privilege escalation. A narrow exclusion ignores benign resolv.conf reads. GKE records the command in gcp.audit.labels.command.gke.io/command when an explicit command is passed to exec. |
new |
|
1 |
Detects an unusual volume of GKE API get requests against multiple distinct Secret objects from the same client fingerprint (user, source IP, and user agent) within the rule lookback window. This can indicate credential access or in-cluster reconnaissance, where a user or token is used to enumerate and retrieve sensitive data such as service account tokens, registry credentials, TLS material, or application configuration. Failed get requests are included and can signal RBAC probing; system service accounts are excluded only when secret reads succeed, since failed secret access by a service account may indicate compromise or misconfiguration worth investigating. |
new |
|
2 |
Detects creation of a GKE service account token through the TokenRequest API by a non-system identity. TokenRequest allows programmatic minting of short-lived tokens for any service account the caller can create tokens for, without reading a mounted projected token from disk. Attackers with initial cluster access can abuse this API to obtain tokens for more privileged service accounts, pivot via Workload Identity to GCP APIs, or retain access after pod termination. Unlike filesystem token theft, TokenRequest activity is visible only in Kubernetes audit logs as create against the serviceaccounts/token subresource. |
new |
|
1 |
Detects bursts of GKE API requests from an anonymous identity that probe many distinct actions and resources with mostly failed outcomes. This pattern is consistent with unauthenticated permission enumeration against an exposed API server. On GKE GCP audit logs, unauthenticated probes often omit "client.user.email" (null principal) with Unauthorized failures; those events are included alongside "system:anonymous" / "system:unauthenticated". |
new |
|
1 |
Detects create, update, or patch of pods by an unauthenticated anonymous GKE identity. Anonymous pod mutation is a critical misconfiguration signal and a common path for unauthenticated attackers to deploy workloads or maintain access. Includes "system:anonymous" / "system:unauthenticated" and GKE audit rows with a missing principal (seen on unauthenticated Unauthorized/forbidden pod writes). |
new |
|
1 |
Detects denied GKE API create requests from non-control-plane identities. Failed creates can indicate RBAC probing, stolen credentials with insufficient privileges, or attempts to deploy unauthorized workloads. |
new |
|
1 |
Detects the first occurrence of a failed GKE API request from a previously unseen user agent. Adversary tooling often uses non-standard clients; combined with authorization failures this can indicate RBAC probing or exploitation attempts. |
new |
|
1 |
Detects successful GKE pod exec sessions where the executed command implies curl or wget fetching an HTTPS URL. Attackers with pods/exec often run one-liners to stage tooling, pull scripts or binaries, or exfiltrate data over HTTPS—activity that should be rare compared to shells, debuggers, or expected health checks. Common cluster health, localhost, and OIDC/JWKS endpoint patterns are excluded to reduce benign automation noise. GKE records the command in gcp.audit.labels.command.gke.io/command when an explicit command is passed to exec. |
new |
|
1 |
Detects successful GKE pod exec sessions whose command resembles reverse-shell or bind-shell one-liner patterns, including /dev/tcp and /dev/udp redirection, netcat/ncat exec-style flags, socat shell handoff, mkfifo pipelines, and common language socket idioms. Legitimate debug sessions sometimes use similar building blocks, but together these patterns align with post-exploitation interactive access and command-and-control. Common localhost /dev/tcp health-check ports are excluded. GKE records the command in gcp.audit.labels.command.gke.io/command when an explicit command is passed to exec. |
new |
|
1 |
Detects modifications to the CoreDNS or kube-dns ConfigMap in the kube-system namespace on GKE. These ConfigMaps control cluster DNS resolution for all pods. An attacker who modifies the CoreDNS Corefile can redirect internal service DNS names to attacker-controlled IP addresses, enabling man-in-the-middle attacks against the Kubernetes API server, database services, and other internal endpoints. Pods that resolve service names via cluster DNS will transparently connect to the attacker instead of the legitimate service, allowing interception of service account tokens, database credentials, and API traffic. DNS poisoning at the cluster level is particularly dangerous because it affects every pod in every namespace simultaneously and does not require any modification to the victim workloads. CoreDNS configuration changes are rare in normal operations and any unexpected modification should be investigated immediately. |
new |
|
1 |
Detects successful GKE API requests from unauthenticated anonymous identities using an unusual user agent. Attackers may rely on anonymous access for initial cluster access or to avoid attribution. Matches "system:anonymous" / "system:unauthenticated" and GKE audit rows where the principal is missing (common for unauthenticated clients). Common kube-probe health checks (readyz/livez/healthz/version) are excluded. |
new |
|
1 |
Detects when the same non-system GKE identity creates a CertificateSigningRequest (CSR) and then approves that same CSR within five minutes, consistent with self-approval abuse. Attackers who gain CSR create and approval RBAC can submit a certificate request and approve it themselves to obtain a long-lived client certificate without involving cluster operators, a pattern documented in Kubernetes persistence research and adversary emulation. |
new |
|
1 |
Detects creation or approval of a GKE CertificateSigningRequest (CSR) by a non-system identity. This is a breadth baseline rule for human or custom automation CSR activity on GKE. Attackers with cluster access can submit and approve CSRs to obtain long-lived client certificates that survive token revocation and RBAC changes. Use companion rules to evaluate signer choice, requested identity, and self-approval behavior. |
new |
|
1 |
Detects creation or modification of a GKE Service with type NodePort. NodePort exposes a static port on every worker node that hosts matching pods, which widens the cluster’s external attack surface and can bypass load-balancer and firewall controls. Attackers may create NodePort Services to intercept traffic or establish a direct path into the cluster. |
new |
|
1 |
Detects creation of a GKE RoleBinding or ClusterRoleBinding that grants permissions to a ServiceAccount, which may indicate privilege delegation or RBAC misconfiguration leading to elevated access. |
new |
|
1 |
Detects creation or modification of GKE Roles or ClusterRoles that grant high-risk permissions, such as wildcard access or RBAC escalation verbs (bind, escalate, impersonate), which may enable privilege escalation or unauthorized access within the cluster. |
new |
|
1 |
Detects non-system identities using the GKE nodes/proxy API to reach a node’s Kubelet through the API server. The nodes/proxy subresource allows any principal with this permission to call the Kubelet API without direct node network access or Kubelet TLS certificates. Through this path an attacker can list pod specs (including environment secrets), read Kubelet configuration, retrieve container logs, and access running pod metadata on the target node. Monitoring endpoints such as metrics, healthz, and stats/summary are excluded to reduce noise from observability tooling. |
new |
|
1 |
Detects GKE API requests where a caller is impersonating a privileged cluster identity such as system:kube-controller-manager, system:admin, system:anonymous, or a kube-system service account. These identities have broad cluster-wide permissions including unrestricted access to secrets, the ability to create tokens for any service account, schedule pods on any node, and modify RBAC. Impersonating system:kube-controller-manager grants access to secrets across namespaces and service account token minting for lateral movement. |
new |
|
1 |
Detects creation of a GKE CertificateSigningRequest (CSR) that requests the kubernetes.io/kube-apiserver-client signer. This signer issues general API client certificates with few subject restrictions, unlike the restricted kubelet signers used for node certificate rotation. Attackers with CSR permissions use this signer to mint long-lived credentials for privileged identities such as system:kube-controller-manager, enabling persistence and privilege escalation that survives token revocation and RBAC changes. |
new |
|
1 |
Detects allowed updates or patches to the pods/ephemeralcontainers subresource on GKE by a non-system identity. Ephemeral containers are commonly used for debugging (kubectl debug) but can also be abused to inject tooling into a running pod, access mounted secrets, and execute commands in the target pod context. Attackers with sufficient RBAC may use ephemeral containers to escalate privileges, move laterally, or establish persistence without deploying a new workload. |
new |
|
1 |
Flags an existing GKE Role or ClusterRole being changed (patch or update) so the effective rules become cluster-admin-like: wildcard on every API resource and wildcard on every verb. That is usually a deliberate privilege expansion, not a typo. GKE audit logs with response body capture are required so the detection reads the merged role after apply; loopback source IPs are ignored. |
new |
|
1 |
Detects write operations performed by GKE service accounts against RBAC resources (Roles, ClusterRoles, RoleBindings, ClusterRoleBindings). Service accounts typically do not manage RBAC directly; this activity may indicate token abuse or unauthorized privilege escalation. |
new |
|
1 |
Detects a request to attach a built-in kube-controller-manager service account to a pod running in the kube-system namespace on GKE. These service accounts are admin-equivalent and are not normally assigned to arbitrary pods. An attacker who can create pods in kube-system can abuse these tokens for cluster-wide privilege escalation. |
new |
|
1 |
Detects the first occurrence of create or patch activity against sensitive GKE workloads (DaemonSets, Deployments, or CronJobs) from an unusual combination of user agent, source IP, and user identity, which may indicate privilege escalation or unauthorized access within the cluster. |
new |
|
1 |
M365 Identity OAuth ROPC Grant via Legacy Authentication Client |
Identifies a successful login by a user principal through a legacy authenticated client (such as Authenticated SMTP, IMAP, POP, or Exchange ActiveSync) in the Microsoft 365 Unified Audit Log, evidenced by the "BAV2ROPC" user agent. Legacy basic-authentication clients are translated by Entra ID into a Resource Owner Password Credentials (ROPC) grant, a single-factor flow that submits the user’s password directly and bypasses interactive multi-factor authentication. This is commonly abused during password spraying and account takeover. |
new |
1 |
Detects the creation of a PHP file in the WordPress plugin directory, which is a common technique used by attackers to establish persistence on a compromised web server. Attackers may upload a malicious PHP file and call it from a web browser to gain remote access to the server. |
new |
|
1 |
Generates a detection alert for each Microsoft Defender XDR alert written to the configured indices. Microsoft Defender emits multiple update events for the same alert over its lifecycle, all sharing a stable alert identifier. This rule suppresses those update events so that a single, continuous Elastic alert is maintained per Defender alert rather than a new alert per update. Enabling this rule allows you to immediately begin investigating Microsoft Defender XDR alerts in the app. |
new |
|
1 |
Generates a detection alert for each Microsoft Defender XDR incident written to the configured indices. Microsoft Defender emits multiple update events for the same incident as its member alerts and status evolve, all sharing a stable incident identifier. This rule suppresses those update events so that a single, continuous Elastic alert is maintained per Defender incident rather than a new alert per update. Enabling this rule allows you to immediately begin investigating Microsoft Defender XDR incidents in the app. |
new |
|
1 |
Suspicious Child Process via Azure VM CustomScript Extension |
Identifies a suspicious process executing as a descendant of the Azure VM CustomScript extension handler (CustomScriptHandler.exe) on a Windows host. The Azure CustomScript extension runs an attacker-supplied script with high privilege (SYSTEM) via the guest agent, and is a common cloud-to-host code-execution and persistence primitive. Because the extension’s resource name is attacker-controlled and absent from on-host telemetry, this rule anchors on the type-bearing handler binary (Microsoft.Compute.CustomScriptExtension...\CustomScriptHandler.exe) rather than the spoofable extension name, making it resistant to renaming. CustomScript legitimately launches PowerShell and cmd, so the rule fires only when the descendant is an execution-proxy, download, or discovery LOLBin, or PowerShell exhibiting suspicious tradecraft. |
new |
1 |
A POST request to a web application returned a 403 response, which indicates the web application declined to process the request because the action requested was not allowed. |
update |
|
106 |
A request to a web application returned a 405 response, which indicates the web application declined to process the request because the HTTP method is not allowed for the resource. |
update |
|
106 |
Detects GenAI tools connecting to unusual domains on macOS. Adversaries may compromise GenAI tools through prompt injection, malicious MCP servers, or poisoned plugins to establish C2 channels or exfiltrate sensitive data to attacker-controlled infrastructure. AI agents with network access can be manipulated to beacon to external servers, download malicious payloads, or transmit harvested credentials and documents. |
update |
|
6 |
This rule detects Palo Alto Network alerts that are observed for the first time in the previous 5 days of alert history. Analysts can use this to prioritize triage and response. |
update |
|
4 |
Detects Cloudtrail logging suspension via StopLogging API. Stopping CloudTrail eliminates forward audit visibility and is a classic defense evasion step before sensitive changes or data theft. Investigate immediately and determine what occurred during the logging gap. |
update |
|
216 |
Detects successful Amazon EKS UpdateClusterConfig requests that disable control plane logging. Disabling EKS API server and control plane logs can reduce visibility into cluster activity and may indicate defense evasion following compromised AWS credentials or unauthorized administrative access. EKS control plane logging changes are typically rare and should align with approved maintenance or cost optimization workflows. |
update |
|
2 |
Detects attempts to disassociate or manipulate Amazon GuardDuty member accounts within an AWS organization. In multi-account GuardDuty deployments, a delegated administrator account aggregates findings from member accounts. Adversaries may attempt to disassociate member accounts, delete member relationships, stop monitoring members, or delete pending invitations to break this centralized visibility. These actions can be precursors to or alternatives for deleting GuardDuty detectors entirely, allowing attackers to operate undetected in member accounts while the administrator account loses visibility. This rule identifies successful API calls that manipulate GuardDuty member relationships, which are rare in normal operations and warrant immediate investigation. |
update |
|
3 |
Identifies when server access logging is disabled for an Amazon S3 bucket. Server access logs provide a detailed record of requests made to an S3 bucket. When server access logging is disabled for a bucket, it could indicate an adversary’s attempt to impair defenses by disabling logs that contain evidence of malicious activity. |
update |
|
8 |
AWS First Occurrence of STS GetFederationToken Request by User |
Identifies the first occurrence of an AWS Security Token Service (STS) GetFederationToken request made by a user. The GetFederationToken API call allows users to request temporary security credentials to access AWS resources. The maximum expiration period for these tokens is 36 hours and they can be used to create a console signin token even for identities that don’t already have one. Adversaries may use this API to obtain temporary credentials for persistence and to bypass IAM API call limitations by gaining console access. |
update |
8 |
AWS Discovery API Calls from VPN ASN for the First Time by Identity |
Flags the first time a given IAM principal invokes a narrow set of high-signal discovery APIs (credential check, account and IAM enumeration, bucket and compute inventory, logging introspection) from a source IP whose autonomous system number (ASN) matches a curated set commonly associated with consumer VPN brands, VPN-heavy hosting, and provider networks referenced in public reporting on TeamPCP activity (for example 31173 Services AB AS39351 and Oy Crea Nova Hosting Solution Ltd). Broad |
update |
2 |
Identifies the creation of a new AWS CloudShell environment. CloudShell is a browser-based shell that provides command-line access to AWS resources directly from the AWS Management Console. The CreateEnvironment API is called when a user launches CloudShell for the first time or when accessing CloudShell in a new AWS region. Adversaries with console access may use CloudShell to execute commands, install tools, or interact with AWS services without needing local CLI credentials. Monitoring environment creation helps detect unauthorized CloudShell usage from compromised console sessions. |
update |
|
4 |
Identifies when an AWS Systems Manager (SSM) command document is created by a user or role who does not typically perform this action. Adversaries may create SSM command documents to execute commands on managed instances, potentially leading to unauthorized access, command and control, data exfiltration and more. |
update |
|
7 |
Identifies when an AWS DynamoDB table is exported to S3. Adversaries may use the ExportTableToPointInTime operation to collect sensitive information or exfiltrate data from DynamoDB tables. This rule detects unusual user activity by monitoring for the ExportTableToPointInTime action in CloudTrail logs. This is a New Terms rule that only flags when this behavior is observed by a user or role for the first time. |
update |
|
8 |
Identifies an AWS Amazon Machine Image (AMI) being shared with another AWS account. Adversaries with access may share an AMI with an external AWS account as a means of data exfiltration. AMIs can contain secrets, bash histories, code artifacts, and other sensitive data that adversaries may abuse if shared with unauthorized accounts. AMIs can be made publicly available accidentally as well. |
update |
|
8 |
Identifies the export of a DB snapshot or DB cluster data to Amazon S3. Snapshot exports can be used for analytics or migration workflows, but adversaries may abuse them to exfiltrate sensitive data outside of RDS-managed storage. Exporting a snapshot creates a portable copy of the database contents, which, if performed without authorization, can indicate data theft, staging for exfiltration, or operator misconfiguration that exposes regulated information. |
update |
|
214 |
Identifies the creation or modification of an S3 bucket replication configuration that sends data to a bucket in a different AWS account. Cross-account replication can be used legitimately for backup, disaster recovery, and multi-account architectures, but adversaries with write access to an S3 bucket may abuse replication rules to silently exfiltrate large volumes of data to attacker-controlled accounts. This rule detects "PutBucketReplication" events where the configured destination account differs from the source bucket’s account, indicating potential unauthorized cross-account data movement. |
update |
|
9 |
Detects updates to an existing CloudTrail trail via UpdateTrail API which may reduce visibility, change destinations, or weaken integrity (e.g., removing global events, moving the S3 destination, or disabling validation). Adversaries can modify trails to evade detection while maintaining a semblance of logging. Validate any configuration change against approved baselines. |
update |
|
216 |
Detects the deactivation of a Multi-Factor Authentication (MFA) device in AWS Identity and Access Management (IAM). MFA provides critical protection against unauthorized access by requiring a second factor for authentication. Adversaries or compromised administrators may deactivate MFA devices to weaken account protections, disable strong authentication, or prepare for privilege escalation or persistence. This rule monitors successful DeactivateMFADevice API calls, which represent the point at which MFA protection is actually removed. |
update |
|
217 |
Identifies potential ransomware note being uploaded to an AWS S3 bucket. This rule detects the PutObject S3 API call with an object name commonly associated with ransomware notes. The keywords detected here rarely overlap with common file names and have been attributed to ransomware notes with high-confidence. Adversaries with access to a misconfigured S3 bucket may retrieve, delete, and replace objects with ransom notes to extort victims. |
update |
|
13 |
Identifies a high-volume of AWS S3 objects stored in a bucket using using Server-Side Encryption with Customer-Provided Keys (SSE-C). Adversaries with compromised AWS credentials can encrypt objects in an S3 bucket using their own encryption keys, rendering the objects unreadable or recoverable without the key. This can be used as a form of ransomware to extort the bucket owner for the decryption key. This is a Threshold rule that triggers when this behavior is observed multiple times for a specific bucket in a short time-window. |
update |
|
7 |
This rule detects when a JavaScript file is uploaded in an S3 static site directory ( |
update |
|
10 |
Identifies when AWS S3 objects stored in a bucket are encrypted using Server-Side Encryption with Customer-Provided Keys (SSE-C). Adversaries with compromised AWS credentials can encrypt objects in an S3 bucket using their own encryption keys, rendering the objects unreadable or recoverable without the key. This can be used as a form of ransomware to extort the bucket owner for the decryption key. This is a New Terms rule that flags when this behavior is observed for the first time user and target bucket name. |
update |
|
9 |
Identifies successful AWS API calls where the CloudTrail user agent indicates offensive tooling or automated credential verification. This includes the AWS CLI or Boto3 reporting a Kali Linux distribution fingerprint ( |
update |
|
6 |
Identifies the first occurrence of an AWS user or role establishing a session via SSM to an EC2 instance. Adversaries may use AWS Session Manager to establish a session to an EC2 instance to execute commands on the instance. This can be used to gain access to the instance and perform actions such as privilege escalation. |
update |
|
7 |
Identifies when a new SSH public key is uploaded to an AWS EC2 instance using the EC2 Instance Connect service. This action could indicate an adversary attempting to maintain access to the instance. The rule detects the SendSerialConsoleSSHPublicKey or SendSSHPublicKey API actions, which are logged when manually uploading an SSH key to an EC2 instance or serial connection. It is important to know that this API call happens automatically by the EC2 Instance Connect service when a user connects to an EC2 instance using the EC2 Instance Connect service via the CLI or AWS Management Console. |
update |
|
10 |
Identifies when an SNS topic message is published by a rare user in AWS. Adversaries may publish messages to SNS topics for phishing campaigns, data exfiltration, or lateral movement within the AWS environment. SNS topics are used to send notifications and messages to subscribed endpoints such as applications, mobile devices or email addresses, making them a valuable target for adversaries to distribute malicious content or exfiltrate sensitive data. This is a New Terms rule that only flags when this behavior is observed for the first time by a user or role. |
update |
|
7 |
Detects the creation of an AWS Identity and Access Management (IAM) user initiated by an assumed role on an EC2 instance. Assumed roles allow users or services to temporarily adopt different AWS permissions, but the creation of IAM users through these roles, particularly from within EC2 instances, may indicate a compromised instance. Adversaries might exploit such permissions to establish persistence by creating new IAM users under unauthorized conditions. |
update |
|
7 |
Detects when an uncommon user or role creates an OpenID Connect (OIDC) Identity Provider in AWS IAM. OIDC providers enable web identity federation, allowing users authenticated by external identity providers (such as Google, GitHub, or custom OIDC-compliant providers) to assume IAM roles and access AWS resources. Adversaries who have gained administrative access may create rogue OIDC providers to establish persistent, federated access that survives credential rotation. This technique allows attackers to assume roles using tokens from an IdP they control. While OIDC provider creation is benign in some environments, it should still be validated against authorized infrastructure changes. |
update |
|
4 |
Detects the creation of a new AWS IAM Roles Anywhere profile. Roles Anywhere allows workloads or external systems to assume IAM roles from outside AWS by authenticating via trusted certificate authorities (trust anchors). Adversaries who have established persistence through a rogue trust anchor may create or modify profiles to link them with highly privileged roles, enabling long-term external access to the AWS environment. This rule identifies successful "CreateProfile" API calls and helps detect potentially unauthorized or risky external access configurations. |
update |
|
10 |
Detects the creation of a new SAML Identity Provider (IdP) in AWS IAM. SAML providers enable federated authentication between AWS and external identity providers, allowing users to access AWS resources using credentials from the external IdP. Adversaries who have gained administrative access may create rogue SAML providers to establish persistent, federated access to AWS accounts that survives credential rotation. This technique allows attackers to assume roles and access resources by forging SAML assertions from an IdP they control. Creating a SAML provider is a rare administrative action that should be closely monitored and validated against authorized infrastructure changes. |
update |
|
4 |
An adversary with access to a set of compromised credentials may attempt to persist or escalate privileges by creating a new set of credentials for an existing user. This rule looks for use of the IAM |
update |
|
14 |
AWS Lambda Function Policy Updated to Allow Public Invocation |
Identifies when an AWS Lambda function policy is updated to allow public invocation. This rule detects use of the AddPermission API where the Principal is set to "*", enabling any AWS account to invoke the function. Adversaries may abuse this configuration to establish persistence, create a covert execution path, or operate a function as an unauthenticated backdoor. Public invocation is rarely required outside very specific workloads and should be considered high-risk when performed unexpectedly. |
update |
9 |
Identifies the creation or update of an AWS Lambda function URL configured with an authentication type of NONE, which exposes the function to unauthenticated invocation directly from the public internet. Adversaries can use a public function URL to establish a durable, internet-reachable entry point for command and control, data egress, or on-demand execution of attacker-controlled code, bypassing the need for valid AWS credentials to invoke the function. Function URLs with public access should be rare and deliberate, so this configuration warrants review. |
update |
|
2 |
AWS EC2 CreateKeyPair by New Principal from Non-Cloud AS Organization |
Identifies the first time a given IAM principal successfully creates an EC2 key pair when the request is sourced from a network whose autonomous system organization is not attributed to common cloud or hyperscaler providers in your GeoIP data. Adversaries may call CreateKeyPair to stage SSH access material before launching or accessing instances. A new terms baseline on |
update |
2 |
Identifies sensitive AWS IAM operations performed via AWS CloudShell based on the user agent string. CloudShell is a browser-based shell that provides command-line access to AWS resources directly from the AWS Management Console. While convenient for administrators, CloudShell access from compromised console sessions can enable attackers to perform privileged operations without installing tools or using programmatic credentials. This rule detects high-risk actions such as creating IAM users, access keys, roles, or attaching policies when initiated from CloudShell, which may indicate post-compromise credential harvesting or privilege escalation activity. |
update |
|
4 |
An adversary with access to a set of compromised credentials may attempt to persist or escalate privileges by attaching additional permissions to compromised user accounts. This rule looks for use of the IAM AttachUserPolicy API operation to attach the highly permissive AdministratorAccess AWS managed policy to an existing IAM user. |
update |
|
11 |
Identifies when the STS AssumeRoot action is performed by a rare user in AWS. The AssumeRoot action allows users to assume the root member account role, granting elevated but specific permissions based on the task policy specified. Adversaries who have compromised user credentials can use this technique to escalate privileges and gain unauthorized access to AWS resources. This is a New Terms rule that identifies when the STS AssumeRoot action is performed by a user that rarely assumes this role against a specific member account. |
update |
|
9 |
Identifies access to email resources via Microsoft Graph API using an first-party application on behalf of a user principal. This behavior may indicate an adversary using a phished OAuth refresh token or a Primary Refresh Token (PRT) to access email resources. The pattern includes requests to Microsoft Graph API endpoints related to email, such as /me/mailFolders/inbox/messages or /users/{user_id}/messages, using a public client application ID and a user principal object ID. This is a New Terms rule that only signals if the application ID, user principal object ID, and source ASN have not been seen doing this activity historically. |
update |
|
8 |
Identifies secrets, keys, or certificates retrieval operations from Azure Key Vault by a user principal that has not been seen previously doing so in a certain amount of days. Azure Key Vault is a cloud service for securely storing and accessing secrets, keys, and certificates. Unauthorized or excessive retrievals may indicate potential abuse or unauthorized access attempts. |
update |
|
5 |
Detects an Azure AD Graph (graph.windows.net) burst from a user-agent identifying as "aiohttp" (the default HTTP library used by ROADrecon’s "gather" command) where a single calling identity issues many requests in a short window. ROADrecon walks every interesting directory object type via aiohttp, producing a large volume of requests from one user / source IP / UA triple. The combination of "aiohttp" UA with a burst threshold is a structural ROADrecon signature; legitimate first-party Microsoft components do not identify as aiohttp. |
update |
|
2 |
Identifies Azure AD Graph (graph.windows.net) requests originating from user-agent strings associated with offensive tooling, scripting libraries, or generic HTTP clients. First-party Microsoft components calling AAD Graph identify with specific user agents such as "Microsoft Azure Graph Client Library", "Microsoft ADO.NET Data Services", or "Microsoft.OData.Client". Anything outside that recognised set is either a developer prototyping against the legacy API or an enumeration tool walking the directory. |
update |
|
3 |
Identifies potential enumeration activity using AzureHound, SharpHound, or BloodHound across Microsoft cloud services. These tools are often used by red teamers and adversaries to map users, groups, roles, applications, and access relationships within Microsoft Entra ID (Azure AD) and Microsoft 365. |
update |
|
4 |
Identifies potential enumeration or password spraying activity using TeamFiltration tool. TeamFiltration is an open-source enumeration, password spraying and exfiltration tool designed for Entra ID and Microsoft 365. Adversaries are known to use TeamFiltration in-the-wild to enumerate users, groups, and roles, as well as to perform password spraying attacks against Microsoft Entra ID and Microsoft 365 accounts. This rule detects the use of TeamFiltration by monitoring for specific user-agent strings associated with the tool in Azure and Microsoft 365 logs. |
update |
|
4 |
Entra ID Service Principal Federated Credential Authentication by Unusual Client |
Identifies when a service principal authenticates using a federated identity credential for the first time in the historical window. This indicates that Entra ID validated a JWT token potentially against an external OIDC identity provider and issued an access token. While legitimate for CI/CD workflows (GitHub Actions, Azure DevOps), adversaries may abuse this by configuring rogue identity providers (BYOIDP) to authenticate as compromised applications. First-time federated credential usage for a service principal warrants investigation to determine if the external identity provider is legitimate. |
update |
4 |
Identifies an illicit consent grant request on-behalf-of a registered Entra ID application. Adversaries may create and register an application in Microsoft Entra ID for the purpose of requesting user consent to access resources. This is accomplished by tricking a user into granting consent to the application, typically via a pre-made phishing URL. This establishes an OAuth grant that allows the malicious client applocation to access resources on-behalf-of the user. |
update |
|
221 |
Entra ID Microsoft Authentication Broker Sign-In to Unusual Resource |
Detects successful Microsoft Entra ID sign-ins where the client application is the Microsoft Authentication Broker (MAB) and the requested resource identifier is outside a short list of commonly observed first-party targets. Attackers abuse the broker in phishing and token broker flows to obtain tokens for unexpected APIs or enterprise applications. The exclusion list covers legacy Azure Active Directory, Microsoft Graph, Device Registration Service, Microsoft Intune Enrollment, extend or tune exclusions for your tenant after baselining broker traffic. |
update |
2 |
Detects unusual resource owner password credential (ROPC) login attempts by a user principal in Microsoft Entra ID. ROPC is a legacy authentication flow that allows applications to obtain tokens by directly providing user credentials. This method is less secure and can be exploited by adversaries to gain access to user accounts without requiring multi-factor authentication (MFA), especially during enumeration or password spraying. This is a New Terms rule that identifies when user principals are involved in ROPC login attempts, not seen before in the last 10 days, indicating potential abuse or unusual activity. |
update |
|
5 |
Identifies a modification to a conditional access policy (CAP) in Microsoft Entra ID. Adversaries may modify existing CAPs to loosen access controls and maintain persistence in the environment with a compromised identity or entity. |
update |
|
111 |
Identifies modifications to OAuth application redirect URIs (ReplyUrls) in Entra ID. Adding an attacker-controlled redirect URI to an existing trusted application allows interception of OAuth authorization codes when users authenticate through that application’s normal login flow, enabling token theft without requiring a new application registration or consent event. |
update |
|
2 |
Entra ID Device Registration with ROADtools Default OS Build |
Identifies a Microsoft Entra ID device registration where the recorded cloud device operating system build is "10.0.19041.928" and the device display name follows the default "DESKTOP-" pattern. This combination is the default device profile that ROADtools (roadtx) uses when registering a device, and it is uncommon for the OS build to match the hardcoded value across an environment of otherwise patched hosts. Adversaries register rogue devices in Entra ID to acquire a Primary Refresh Token (PRT), establish persistence, and obtain trusted, programmatic access to the tenant. Because the OS build is a tool default, this is a high-fidelity but evadable indicator; baseline approved provisioning tooling and device naming conventions before relying on it. |
update |
2 |
Entra ID Device with ROADtools Default OS Build (Entity Analytics) |
Identifies the first occurrence of a Microsoft Entra ID device, surfaced through the Entra ID Entity Analytics device inventory, whose host name follows the default "DESKTOP-" pattern and whose operating system build is |
update |
2 |
Identifies an Identity and Access Management (IAM) custom role creation in Google Cloud Platform (GCP). Custom roles are user-defined, and allow for the bundling of one or more supported permissions to meet specific needs. Custom roles will not be updated automatically and could lead to privilege creep if not carefully scrutinized. |
update |
|
110 |
Detects creation or modification of a GKE ClusterRoleBinding that grants the cluster-admin ClusterRole, providing unrestricted cluster access and enabling rapid privilege escalation or persistence. |
update |
|
2 |
Identifies when a new key is created for a service account in Google Cloud Platform (GCP). A service account is a special type of account used by an application or a virtual machine (VM) instance, not a person. Applications use service accounts to make authorized API calls, authorized as either the service account itself, or as G Suite or Cloud Identity users through domain-wide delegation. If private keys are not tracked and managed properly, they can present a security risk. An adversary may create a new key for a service account in order to attempt to abuse the permissions assigned to that account and evade detection. |
update |
|
110 |
Google Workspace Gmail Routing or Forwarding Rule Created or Modified |
Detects when a Gmail routing, mail-forwarding, or custom mail-host setting is created or modified in Google Workspace. Adversaries with administrative access can add Routing rules (also deliver to / change envelope recipient), recipient address map forwarding, or mail hosts and outbound gateways to copy or redirect sensitive email for collection. |
update |
112 |
Detects when an administrator disables multi-factor authentication enforcement or removes the ability for users to enroll in 2-step verification across a Google Workspace organization or organizational unit. Adversaries with administrative access may weaken tenant-wide authentication requirements to enable password-only sign-ins, facilitate credential abuse at scale, and reduce friction for follow-on account takeover across the domain. |
update |
|
214 |
Detects when a previously suspended user’s account is renewed in Google Workspace. An adversary may renew a suspended user account to maintain access to the Google Workspace organization with a valid account. |
update |
|
10 |
Detects when an administrator adds a Google Workspace Marketplace application to the domain. Adversaries with administrative access may register a malicious OAuth application to establish long-lived API access to mail, drive, and other Workspace data, maintaining persistence and enabling collection without relying on a single user password alone. |
update |
|
212 |
Detects when a Google Workspace user disables 2-step verification (2SV) on their account. An adversary with access to a compromised account may remove 2SV to eliminate the second authentication factor, leaving password-only access and making future sign-ins easier to abuse, relay, or maintain without triggering MFA challenges. |
update |
|
113 |
Google Workspace API Access Granted via Domain-Wide Delegation |
Detects when a super administrator authorizes domain-wide delegation (DWD) API client access for a Google Cloud service account or OAuth client. DWD lets an application impersonate users and access Workspace APIs across the tenant. Adversaries with admin access may register or authorize a malicious client with broad scopes to maintain API-based persistence and access mail, drive, and directory data without relying on a single user’s password alone. |
update |
213 |
Detects when a custom admin role or its privileges are modified in Google Workspace. Adversaries may add or expand privileges on an existing role to elevate access for assigned users or groups without creating a new role or directly assigning a well-known admin role. Because privilege changes take effect for all principals assigned the role, modifying role permissions can silently expand access across multiple accounts. |
update |
|
212 |
Detects when multi-factor authentication (MFA) is disabled for a Google Workspace organization. An adversary may attempt to modify a password policy in order to weaken an organization’s security controls. |
update |
|
212 |
Identifies file downloads or access from OneDrive or SharePoint using PowerShell-based user agents. Adversaries may use native PowerShell cmdlets like Invoke-WebRequest or Invoke-RestMethod with Microsoft Graph API to exfiltrate data after compromising OAuth tokens via device code phishing or other credential theft techniques. This rule detects both direct PowerShell access and PnP PowerShell module usage for file operations. FileAccessed events are included to detect adversaries reading file content via API and saving locally, bypassing traditional download methods. Normal users access SharePoint/OneDrive via browsers or sync clients, making PowerShell-based file access inherently suspicious. |
update |
|
5 |
Identifies when a user creates a new inbox rule in Microsoft 365 that deletes or moves emails containing suspicious keywords. Adversaries who have compromised accounts often create inbox rules to hide alerts, security notifications, or other sensitive messages by automatically deleting them or moving them to obscure folders. Common destinations include Deleted Items, Junk Email, RSS Feeds, and RSS Subscriptions. This is a New Terms rule that triggers only when the user principal name and associated source IP address have not been observed performing this activity in the past 14 days. |
update |
|
6 |
M365 Identity OAuth Illicit Consent Grant by Rare Client and User |
Identifies an Microsoft 365 illicit consent grant request on-behalf-of a registered Entra ID application. Adversaries may create and register an application in Microsoft Entra ID for the purpose of requesting user consent to access resources in Microsoft 365. This is accomplished by tricking a user into granting consent to the application, typically via a pre-made phishing URL. This establishes an OAuth grant that allows the malicious client applocation to access resources in Microsoft 365 on-behalf-of the user. |
update |
9 |
M365 Identity OAuth Phishing via First-Party Microsoft Application |
Detects potentially suspicious OAuth authorization activity in Microsoft 365 where first-party Microsoft applications from the FOCI (Family of Client IDs) group request access to Microsoft Graph or legacy Azure AD resources. Developer tools like Azure CLI, Visual Studio Code, and Azure PowerShell accessing these resources are flagged, as they are commonly abused in phishing campaigns like ConsentFix. Additionally, any FOCI family application accessing the deprecated Windows Azure Active Directory resource is flagged since this API is rarely used legitimately and attackers target it for stealth. First-party apps are trusted by default in all tenants and cannot be blocked, making them ideal for OAuth phishing attacks. |
update |
6 |
This rule detects shell executions via Elastic Endpoint. Elastic Endpoint has a built-in response action console that can be used to execute shell commands on compromised systems. |
update |
|
2 |
File Creation in World-Writable Directory by Unusual Process |
This rule detects the creation of files in world-writable directories by an unusual process. Attackers may attempt to hide their activities by creating files in world-writable directories, which are commonly used for temporary file storage. This behavior is often associated with lateral movement and can be an indicator of an attacker attempting to move laterally within a network. |
update |
3 |
This rule detects when a payload is downloaded by an interpreter, and piped to an interpreter. Attackers may use this technique to download and execute payloads for various malicious purposes, such as establishing persistence or exfiltrating data. |
update |
|
2 |
This rule monitors for the execution of the xdg-open process that is typically used to open documents and URLs in the user’s preferred desktop application. Attackers may use this command to trick users into opening malicious documents or URLs to gain access to the target system. |
update |
|
2 |
Identifies suspicious child processes executed via a web server, which may suggest a vulnerability and remote shell access. Attackers may exploit a vulnerability in a web application to execute commands via a web server, or place a backdoor file that can be abused to gain code execution as a mechanism for persistence. |
update |
|
117 |
Identifies suspicious command executions via a web server, which may suggest a vulnerability and remote shell access. Attackers may exploit a vulnerability in a web application to execute commands via a web server, or place a backdoor file that can be abused to gain code execution as a mechanism for persistence. |
update |
|
3 |
This rule leverages the "new_terms" rule type to detect unusual child process executions originating from web server processes on Linux systems. Attackers may exploit web servers to maintain persistence on a compromised system, often resulting in atypical child process executions. As child process spawns from web server parent processes are common, the "new_terms" rule type approach helps identify deviations from normal behavior. |
update |
|
3 |
This rule leverages the "new_terms" rule type to detect unusual command executions originating from web server processes on Linux systems. Attackers may exploit web servers to maintain persistence on a compromised system, often resulting in atypical command executions. As command execution from web server parent processes is common, the "new_terms" rule type approach helps to identify deviations from normal behavior. |
update |
|
6 |
Potential Root Effective Shell from Non-Standard Path via Auditd |
Identifies process execution events where the effective user is root while the real user is not, the process arguments include the privileged shell flag commonly associated with setuid-capable shells, and the executable path is outside standard system binary directories. That combination is consistent with abuse of setuid shells or similar helpers copied or linked into writable locations, a pattern used to regain a root context after local exploitation. |
update |
2 |
Detects nsenter executions that target PID with a namespace target flag, a pattern commonly used to attach to the host init namespace from a container or session and run with host context. |
update |
|
2 |
Detects chroot execution on Linux when the process appears to run in a container-oriented context: the process title matches runc init, the entry leader is a container workload, or the parent process is runc. Chroot from inside a container can pivot to an alternate root filesystem and is a common step in container breakout attempts when combined with sensitive host mounts. |
update |
|
2 |
Detects suspicious creation of the nsswitch.conf file, outside of the regular /etc/nsswitch.conf path, consistent with attempts to exploit CVE-2025-32463 (the "sudo chroot" privilege escalation), where an attacker tricks sudo into using attacker-controlled NSS files or libraries to gain root. |
update |
|
4 |
Detects suspicious use of sudo’s --chroot / -R option consistent with attempts to exploit CVE-2025-32463 (the "sudo chroot" privilege escalation), where an attacker tricks sudo into using attacker-controlled NSS files or libraries to gain root. |
update |
|
4 |
Deprecated - Potential CVE-2025-41244 vmtoolsd LPE Exploitation Attempt |
This rule looks for processes that behave like an attacker trying to exploit a known vulnerability in VMware tools (CVE-2025-41244). The vulnerable behavior involves the VMware tools service or its discovery scripts executing other programs to probe their version strings. An attacker can place a malicious program in a writable location (for example /tmp) and have the tools execute it with elevated privileges, resulting in local privilege escalation. The rule flags launches where vmtoolsd or the service discovery scripts start other child processes. |
update |
4 |
Detects potential privilege escalation under the root effective user when the real user and parent user are not root, indicative of the execution of binaries with SUID or SGID bits set. |
update |
|
2 |
Identifies instances where a process is executed with user/group ID 0 (root), and a real user/group ID that is not 0. This is indicative of a process that has been granted SUID/SGID permissions, allowing it to run with elevated privileges. Attackers may leverage a misconfiguration for exploitation in order to escalate their privileges to root, or establish a backdoor for persistence. |
update |
|
113 |
Potential Privilege Escalation via SUID/SGID Proxy Execution |
Detects potential privilege escalation via SUID/SGID proxy execution on Linux systems. Attackers may exploit binaries with the SUID/SGID bit set to execute commands with elevated privileges. This rule identifies instances where a process is executed with root privileges (user ID 0 or group ID 0) while the real user or group ID is non-root, indicating potential misuse of SUID/SGID binaries. |
update |
4 |
Identifies the creation of a sudo binary located at /usr/bin/sudo. Attackers may hijack the default sudo binary and replace it with a custom binary or script that can read the user’s password in clear text to escalate privileges or enable persistence onto the system every time the sudo binary is executed. |
update |
|
113 |
Detects execution of SUID binaries that may be used for privilege escalation under the root effective user when the real user and parent user are not root, combined with minimal argument counts and suspicious parent context (interpreters, short shell -c invocations, or parents running from user-writable paths) to indicate potential misuse of SUID binaries for privilege escalation. |
update |
|
3 |
Identifies instances where a process (granted CAP_SETUID and/or CAP_SETGID capabilities) is executed, after which the user’s access is elevated to UID/GID 0 (root). In Linux, the CAP_SETUID and CAP_SETGID capabilities allow a process to change its UID and GID, respectively, providing control over user and group identity management. Attackers may leverage a misconfiguration for exploitation in order to escalate their privileges to root. |
update |
|
11 |
Identifies suspicious usage of unshare to manipulate system namespaces. Unshare can be utilized to escalate privileges or escape container security boundaries. Threat actors have utilized this binary to allow themselves to escape to the host and access other resources or escalate privileges. |
update |
|
117 |
This rule detects network events that may indicate the use of Telnet traffic. Telnet is commonly used by system administrators to remotely control older or embedded systems using the command line shell. It should almost never be directly exposed to the Internet, as it is frequently targeted and exploited by threat actors as an initial access or backdoor vector. As a plain-text protocol, it may also expose usernames and passwords to anyone capable of observing the traffic. |
update |
|
116 |
Cobalt Strike is a threat emulation platform commonly modified and used by adversaries to conduct network attack and exploitation campaigns. This rule detects a network activity algorithm leveraged by Cobalt Strike implant beacons for command and control. |
update |
|
111 |
This rule detects a known command and control pattern in network events. The FIN7 threat group is known to use this command and control technique, while maintaining persistence in their target’s network. |
update |
|
112 |
Halfbaked is a malware family used to establish persistence in a contested network. This rule detects a network activity algorithm leveraged by Halfbaked implant beacons for command and control. |
update |
|
109 |
Potential cPanel WHM CRLF Authentication Bypass (CVE-2026-41940) |
Identifies the network signature of CVE-2026-41940, a pre-auth root-level authentication bypass in cPanel and WebHost Manager (WHM) caused by a CRLF injection in the session writer. The exploit-inherent shape on the wire is a "GET /" request to a cPanel/WHM admin port (typically TCP/2087, 2086, 2083, 2082, 2095, 2096) carrying an "Authorization: Basic" header whose base64-decoded value contains CRLF-injected session fields, which causes cpsrvd to respond with a 3xx redirect whose "Location" header leaks a "/cpsessNNNNNNNNNN" token granting the attacker a privileged session. This is the network-layer equivalent of the cPanel "access_log" artifact identified by Unfold and watchTowr as the first bulletproof detection for this CVE: a "GET /" recorded with "auth_method=b" (HTTP Basic). Legitimate access to "GET /" on a WHM admin port returns 200 with the login screen and never includes HTTP Basic credentials, so this combination is not produced by normal use. |
update |
3 |
Identifies Elasticsearch nodes that do not have Transport Layer Security (TLS), and/or lack authentication, and are accepting inbound network connections over the default Elasticsearch port. |
update |
|
109 |
Identifies suspicious file rename operation by the virtual System process. This may indicate a remote ransomware attack via the SMB protocol. |
update |
|
9 |
Identifies the creation of a file with a name similar to ransomware note files by the Windows System process (PID 4). This may indicate a remote ransomware attack via the SMB protocol. |
update |