Identifies suspicious commands written to the Windows Run dialog history (RunMRU) by explorer.exe. Adversaries socially engineer users to copy and paste malicious commands for execution, a pattern commonly seen in Fake CAPTCHA (ClickFix) campaigns. Investigate the process tree for a child of explorer.exe that matches the stored command.

Read More

Detects successful Anthropic audit activity where the user agent matches scripting HTTP clients, offensive scanners, or automation libraries (for example curl, python-requests, Go-http-client, axios, nuclei). Browser and first-party Claude clients normally present recognizable browser or product user agents; raw HTTP library agents on successful control-plane or product activity often indicate scripted access, stolen-session reuse, or unauthorized automation. Known benign automation patterns (axios or Go HTTP clients on file upload/delete, trusted device enrollment, and environment creation) are excluded.

Read More

Admin API keys grant programmatic access to organization and compliance APIs outside an interactive browser session. An attacker who creates one after compromise can automate role grants, exports, and logging changes without holding a user session that would time out under SSO. The key also survives password resets and IdP lockout if defenders revoke the interactive account but miss the API credential.

Read More

Admin API keys grant programmatic access to organization and compliance APIs. An attacker can delete legitimate admin API keys to break security monitoring or integrations, or to cover tracks after creating replacement credentials they control. Deletion without a nearby rotation event points more at sabotage than routine key hygiene.

Read More

The organization admin role controls organization settings, integrations, membership, and security configuration in Anthropic Claude for Enterprise. Membership role changes are reported as claude_user_role_updated with anthropic.audit.current_role. An attacker can promote a compromised or newly invited account to org admin to turn initial access into durable control-plane access. From admin, they can disable SSO, mint admin API keys for automation, start data exports, and weaken audit logging. Workspace-scoped role_assignment_granted grants (for example bare admin on a workspace) are out of scope for this rule.

Read More

Claude artifacts can be shared with specific audiences. Making an artifact public exposes its contents to unauthenticated viewers on the internet. An attacker with access to sensitive artifacts can publish them publicly to push intellectual property, credentials embedded in prompts, or other confidential material outside organizational controls.

Read More

Compliance-scoped API keys read organization audit activity and compliance data. Once an attacker has administrative access, creating one gives them programmatic read of chats, files, and membership without an interactive session. This is separate from admin API key creation, which covers organization administration rather than compliance read scopes.

Read More

Compliance API logging feeds the anthropic.audit dataset that Anthropic audit detections run on. An attacker with administrative access can disable it so later role grants, API key creation, exports, and authentication changes stop reaching this data source. This rule detects the disable action itself. Activity that happens after logging stops may not appear in logs-anthropic.audit-*.

Read More

An audit log export archive was accessed, meaning the actor downloaded exported audit activity. Attackers pull audit exports to see what defenders can observe, look for detection gaps, or remove evidence before making other control-plane changes.

Read More

Detects a single authenticated user generating an unusually high number of denied Claude chat access attempts in a 24-hour window. That pattern fits automated chat enumeration or attempts to reach conversations outside the actor's permissions. Unauthenticated shared-link actors lack user.id and are excluded.

Read More

Detects an unusually high number of Claude chat creation events for the same user email within a 24-hour period. Burst chat creation can indicate automated LLM abuse, resource hijacking to burn organizational quotas, or scripted workflows used to stage many parallel conversations for data processing or prompt-injection campaigns.

Read More

Detects an unusually high number of Claude chat deletion events for the same user email within a single calendar day. Mass chat deletion can indicate an attempt to remove conversation history, cover tracks after misuse of Claude, or automated cleanup following data staging or prompt abuse.

Read More

Detects an unusually high number of successful Claude chat snapshot creation events for the same user email within a rolling 24-hour window. Chat snapshots package conversation content into shareable exports; sustained creation volume can indicate staging of organizational chat data for exfiltration via Anthropic's web service or automated bulk export of sensitive prompts and responses.

Read More

Extra usage spend limits cap Anthropic organizational spend beyond included usage. Deleting a spend limit removes that cap and can enable unrestricted API or Claude consumption. An attacker who already has administrative or API access can delete the limit to burn budget, run large automated workloads, or stage resource abuse without the previous guardrail.

Read More

Detects an unusually high volume of Claude file uploads from the same user email and source IP within a rolling 24-hour period. Sustained upload activity can indicate staging of sensitive documents in Claude chats for later retrieval, automated ingestion of data into LLM workflows, or abuse of organizational Claude access to move files into the cloud service.

Read More

Detects successful Anthropic magic link or SSO sign-ins for the same user email from source IP addresses whose query-time geo-locations (via IP_LOCATION) are separated by at least 1,000 km, with implied travel faster than 800 km/h, within a 24-hour window. That pattern can indicate account sharing, VPN or proxy egress mismatches, or an adversary authenticating from a geography far from the legitimate user's baseline.

Read More

Magic link second factor adds an extra authentication step to passwordless sign-in for Anthropic. An attacker with administrative access can turn it off so magic link logins no longer require the second factor, which makes stolen or attacker-controlled mailboxes usable for interactive access. This often shows up alongside SSO weakening when the attacker wants a fallback authentication path outside the corporate IdP.

Read More

Detects at least five failed Anthropic authentication events for the same user email within one hour. Failures are matched by authentication category and failure outcome (for example magic-link or SSO login failures). That pattern fits repeated guessing, stale magic link abuse, or automated login attempts against one account.

Read More

Starting an organization data export only signals intent. Accessing the export archive via its signed URL means the actor actually downloaded chats, projects, user metadata, and configuration. An attacker with administrative access can use this to exfiltrate intellectual property and credentials at scale.

Read More

Organization deletion and bulk delete remove tenant data, projects, and member access in a single administrative action. An attacker can use this to break AI-assisted workflows as an impact technique, to extort the organization, or to destroy evidence after finishing a data export. Once deletion progresses, recovery options shrink and earlier exfiltration activity is harder to reconstruct from the tenant itself.

Read More

Verified organization domains control which email addresses can join or be pulled into an Anthropic tenant. Verifying, claiming, adding, or removing a domain changes the tenant boundary and can pull in attacker-controlled mailboxes or push out legitimate corporate domains. These events are infrequent and affect organization-wide membership trust.

Read More

Organization IP restrictions limit Anthropic administrative access to approved network ranges. Deleting one widens where a compromised admin session or API key can be used. The audit event does not always carry the deleted CIDR or restriction identifier, so treat this as an early signal and pivot to nearby IP restriction create or update events for the same organization.

Read More

Detects a single user performing at least two distinct organization discovery actions within a 10-minute window: listing users, exporting members, or viewing groups. Chaining these read actions maps membership and group structure and commonly precedes targeted role grants, invites, or data collection against high-value accounts.

Read More

Sending an organization user invite creates a path for a new member to join the Anthropic tenant with a chosen role. An adversary who compromises an administrator or admin API key can invite a mailbox they control and accept the invite to gain durable access. Invites may target internal corporate addresses or external domains; this rule does not distinguish them because invite events do not carry verified organization domains for reliable comparison.

Read More

Primary ownership is the highest administrative authority in an Anthropic organization, covering billing, membership, and organization-wide settings. Transferring ownership to an attacker-controlled account can lock out the legitimate administrator from recovery paths that depend on the original owner. Attackers often do this after role escalation so defenders cannot reverse earlier privilege changes through normal administration.

Read More

Detects successful Anthropic audit activity for the same user email from source IP addresses whose query-time geo-locations (via IP_LOCATION) span at least two countries, are separated by at least 500 km, and imply travel faster than 800 km/h within a short (~15-minute) lookback. Unlike login-only impossible travel, this rule covers any successful user-actor activity and can surface session cookie replay or concurrent session reuse when no new authentication events appear.

Read More

SSO routes Anthropic authentication through the corporate identity provider. Disabling SSO, or deactivating or deleting an SSO connection, moves users onto alternate sign-in paths where IdP-enforced MFA, conditional access, and session policies no longer apply. That opens the door to password or magic-link accounts the attacker controls.

Read More

Detects a first-party FOCI tooling client (Azure CLI, PowerShell, VS Code, Graph CLI, Azure AD PowerShell, or Visual Studio) redeeming a device-bound Primary Refresh Token (PRT) for Microsoft Graph, SharePoint/OneDrive, or Exchange Online from an IP that is not among that user and device's Windows Sign-In or WAM addresses. Replay events are limited to compliant or Intune-managed devices: the stolen cookie keeps the workstation deviceid, so compliant-device Conditional Access can succeed off-box.

Read More

Detects bursts of failed GKE API requests from a single user identity within a five-minute window. Repeated authorization failures across multiple actions can indicate credential stuffing, RBAC probing, or reconnaissance with stolen tokens.

Read More

Detects Kubernetes pod exec sessions whose decoded command line references cloud instance metadata endpoints or equivalent hostnames and paths. Workloads that reach the link-local metadata IP, AWS IMDS paths, GCP computeMetadata, Azure IMDS token routes, or encoded variants are often attempting to harvest role credentials, tokens, or instance attributes from the underlying node or hypervisor boundary. That behavior is high risk in multi-tenant and regulated environments because it can expose short-lived cloud credentials to code running inside a container. The rule classifies a coarse cloud target label and whether the string looks like credential retrieval versus lighter reconnaissance.

Read More

Flags exec into a pod when the URL-decoded command payload resembles reverse-shell or bind-shell one-liners invocation patterns. Legitimate debug sessions sometimes use similar building blocks, but together these patterns align with post-exploitation interactive access and command-and-control.

Read More

Detects Kubernetes pod exec sessions whose decoded command line references high-value host or in-cluster paths and material types: mounted service account or platform tokens, kubelet and control-plane configuration areas, host identity stores, root dot-directories for cloud and kubeconfig material, common private-key and keystore extensions, process environment dumps, and configuration filenames suggestive of embedded secrets. The intent is to catch interactive or scripted access that often precedes lateral movement, privilege escalation, or credential theft from the node or workload boundary. A narrow exclusion ignores benign reads of resolv.conf. The query also labels an access_type bucket to speed triage without altering the detection predicates you validated.

Read More

Detects pod or attach exec API calls where the decoded request query implies curl or wget fetching an https URL. Attackers with permission to exec into workloads 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. The rule decodes the audit requestURI, reconstructs a readable command string from repeated command parameters, and applies noise filters for common cluster health and OIDC/JWKS endpoints so benign automation is less likely to alert.

Read More

Identifies access attempts to the LSASS handle, which may indicate an attempt to dump credentials from LSASS memory.

Read More

This rule identifies outbound IPSEC NAT Traversal (NAT-T) traffic to an external destination IP that was not observed during the previous 5 days. IPSEC is a VPN technology that allows one system to talk to another using encrypted tunnels. NAT Traversal encapsulates IPSEC ESP traffic in UDP and, once a NAT device is detected, both peers float to UDP port 4500 for the tunnel data channel. Newly observed external NAT-T peers may indicate unauthorized VPN use or an adversary tunneling command and control or exfiltration traffic over the Internet.

Read More

This rule detects two ALPN-based denial-of-service patterns against TLS servers. The first identifies repeated stalled handshakes advertising the acme-tls/1 ALPN extension with no session established, indicating potential goroutine or worker exhaustion in reverse proxies. The second matches connections where a malformed ALPN extension triggers TLS alerts such as decode_error or illegal_parameter, consistent with zero-length ALPN list exploitation. Both patterns are anomalous outside of scheduled ACME TLS-ALPN-01 certificate validation activity.

Read More

Detects when multiple hosts are using the same agent ID. This could occur in the event of an agent being taken over and used to inject illegitimate documents into an instance as an attempt to spoof events in order to masquerade actual activity to evade detection.

Read More

This rule uses alert data to determine when multiple alerts from different integrations with unique event categories and involving the same destination.ip are triggered. Analysts can use this to prioritize triage and response, as these IP address is more likely to be related to a compromise.

Read More

This rule uses alert data to determine when multiple alerts from different integrations with unique event categories and involving the same source.ip are triggered. Analysts can use this to prioritize triage and response, as these IP addresses are more likely to be related to a compromise.

Read More

This rule uses alert data to determine when multiple alerts from different integrations with unique event categories and involving the same user.name are triggered. Analysts can use this to prioritize triage and response, as these users are more likely to be compromised.

Read More

This rule correlates medium-or-higher severity alerts involving the same host from at least two distinct detection rules mapped to three or more ATT&CK tactics. Analysts can use this to prioritize triage and response, as this combination may indicate host compromise.

Read More

This rule identifies potentially suspicious activity by detecting instances where a single IAM user's temporary session token is accessed from multiple IP addresses within a short time frame. Such behavior may suggest that an adversary has compromised temporary credentials and is utilizing them from various locations. To enhance detection accuracy and minimize false positives, the rule incorporates criteria that evaluate unique IP addresses, user agents, cities, and networks. These additional checks help distinguish between legitimate distributed access patterns and potential credential misuse. Detected activities are classified into different types based on the combination of unique indicators, with each classification assigned a fidelity score reflecting the likelihood of malicious behavior. High fidelity scores are given to patterns most indicative of threats, such as multiple unique IPs, networks, cities, and user agents. Medium and low fidelity scores correspond to less severe patterns, enabling security teams to effectively prioritize alerts.

Read More

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.

Read More

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.

Read More

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.

Read More

Identifies multiple successive failed attempts to use denied model resources within AWS Bedrock. This could indicated attempts to bypass limitations of other approved models, or to force an impact on the environment by incurring exhorbitant costs.

Read More

Identifies multiple validation exeception errors within AWS Bedrock. Validation errors occur when you run the InvokeModel or InvokeModelWithResponseStream APIs on a foundation model that uses an incorrect inference parameter or corresponding value. These errors also occur when you use an inference parameter for one model with a model that doesn't have the same API parameter. This could indicate attempts to bypass limitations of other approved models, or to force an impact on the environment by incurring exhorbitant costs.

Read More

Identifies multiple violations of AWS Bedrock guardrails within a single request, resulting in a block action, increasing the likelihood of malicious intent. Multiple violations implies that a user may be intentionally attempting to cirvumvent security controls, access sensitive information, or possibly exploit a vulnerability in the system.

Read More

Identifies multiple violations of AWS Bedrock guardrails by the same user in the same account over a session. Multiple violations implies that a user may be intentionally attempting to cirvumvent security controls, access sensitive information, or possibly exploit a vulnerability in the system.

Read More

Detects when a Bedrock model is prompted to invoke high-risk tools associated with shell execution, filesystem operations, or process spawning. Adversaries may use compromised AI agent pipelines or manipulated prompts to instruct the model to execute arbitrary system commands, read or write sensitive files, or spawn subprocesses — extending the blast radius of a credential compromise or prompt injection attack.

Read More

Identifies an AWS principal performing a high volume of Amazon Bedrock inference API calls against a single model within a short window. Membership inference attacks require hundreds to thousands of statistically similar queries whose prompts and responses are intentionally content-benign, making guardrail- and content-based rules ineffective. This rule detects the high-frequency single-model probing pattern that precedes membership inference and related exfiltration via the inference API. It is a behavioral / volumetric precursor: it does not observe model confidence scores and a fixed call-count threshold only catches the loud variant, so paced, low-and-slow, or credential-distributed probing will evade it. Definitive membership inference detection requires ML anomaly analysis over per-entity inference-rate and response-distribution baselines.

Read More

Identifies multiple AWS Bedrock executions in a one minute time window without guardrails by the same user in the same account over a session. Multiple consecutive executions implies that a user may be intentionally attempting to bypass security controls, by not routing the requests with the desired guardrail configuration in order to access sensitive information, or possibly exploit a vulnerability in the system.

Read More

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.

Read More

Detects AWS access keys that are used from both GitHub Actions CI/CD infrastructure and non-CI/CD infrastructure. This pattern indicates potential credential theft where an attacker who has stolen AWS credentials configured as GitHub Actions secrets and is using them from their own infrastructure.

Read More

Detects when a single AWS resource is running multiple read-only, discovery API calls in a 10-second window. This behavior could indicate an actor attempting to discover the AWS infrastructure using compromised credentials or a compromised instance. Adversaries may use this information to identify potential targets for further exploitation or to gain a better understanding of the target's infrastructure.

Read More

Identifies the execution of Living Off the Land Binaries (LOLBins) or GTFOBins on EC2 instances via AWS Systems Manager (SSM) SendCommand API. This detection correlates AWS CloudTrail SendCommand events with endpoint process execution by matching SSM command IDs. While AWS redacts command parameters in CloudTrail logs, this correlation technique reveals the actual commands executed on EC2 instances. Adversaries may abuse SSM to execute malicious commands remotely without requiring SSH or RDP access, using legitimate system utilities for data exfiltration, establishing reverse shells, or lateral movement.

Read More

Identifies a short sequence of EC2 management APIs against the same instance that is consistent with modifying instance user data and forcing it to run on the next boot: ModifyInstanceAttribute with user data, followed by stop and start. Adversaries may update userData and cycle instance state so malicious scripts execute as root on Linux or as the system context on Windows. This rule correlates successful StopInstances, StartInstances, and ModifyInstanceAttribute events that reference userData within a five-minute window, grouped by instance, user.name, account, source IP, and user agent. A hit requires exactly three distinct API names in that bucket.

Read More

Detects when an Amazon ECR repository or registry policy is modified to grant public access using a wildcard principal (Principal:"") statement. This rule analyzes SetRepositoryPolicy and PutRegistryPolicy events whose policy document grants an Allow effect to a wildcard ("") principal, indicating that pull (and potentially push) permissions were extended to all identities, including unauthenticated users. A public container registry can expose proprietary images and any secrets baked into their layers, and, if push is allowed, enables supply-chain implantation. Public ECR access is sometimes intentional for image distribution, so the granting principal and the permissions should be validated.

Read More

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-" 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.

Read More

Correlates open detection alerts that share the same long-term IAM access key ID ( prefix AKIA). It fires when the rule AWS Long-Term Access Key First Seen from Source IP (rule_id: 9f8e3c5e-f72e-4e91-93f6-e98a4fae3e4f) has triggered for that key and at least one other open alert for the same key is medium, high, or critical severity. This higher-order rule helps prioritize long-term key novelty when it co-occurs with elevated detections that may indicate post-compromise activity.

Read More

Identifies an IAM user that successfully signs in to the AWS Management Console from two or more distinct countries within a short window. A single user authenticating from multiple geographic locations in a brief period is physically implausible and indicates that the account's credentials or console session are being used from more than one place at once. This is a hallmark of adversary-in-the-middle (AiTM) phishing and session theft, where the legitimate user signs in from their location while the attacker replays the captured session or credentials from their own infrastructure. Because the attacker logs in from a different network, the divergent sign-in geolocations are the detectable signal even when MFA appears satisfied (AiTM relays the live MFA challenge). This is the CloudTrail-native analog of identity-provider impossible-travel sign-in detections.

Read More

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 CreateAccessKey API operation to create new programmatic access keys for another IAM user.

Read More

Detects an AWS IAM user using an existing credential to create a new access key for itself and subsequently using the new key within one hour. This behavior can indicate an adversary converting compromised credentials into an additional long-term credential for persistence. Unlike a standalone self-service key creation alert, requiring subsequent use of the new key reduces noise from unused or abandoned credential-rotation operations.

Read More

Identifies a single principal directly invoking AWS Lambda functions at a high volume within a one-hour window. Adversaries may drive excessive invocations to abuse functions for resource hijacking or cryptomining, to inflate costs in a denial-of-wallet attack, or to enumerate function behavior. This is a volumetric heuristic: the threshold is environment-dependent and high-throughput applications can exceed it, so tune it to the deployment. This rule relies on AWS Lambda data event logging, which is not enabled by default.

Read More

Identifies an AWS Lambda function invoked by a principal whose AWS account differs from the account that owns the function (a cross-account invocation). The caller's account is parsed from the invoking principal's ARN and compared to the function account. Adversaries who have been granted invoke permission on a function from an external account, or who operate from a separate attacker-controlled account, can use cross-account invocation to execute functions or retrieve the data they return. This is the data-plane counterpart to detecting the cross-account grant itself, and relies on AWS Lambda data event logging, which is not enabled by default.

Read More

Detects when credentials issued through AssumeRoleWithWebIdentity for a Kubernetes service account identity are later used for several distinct AWS control-plane actions on the same session access key. Workloads that use EKS IAM Roles for Service Accounts routinely exchange a projected service-account token for short-lived IAM credentials; this rule highlights sessions where that exchange is followed by a spread of sensitive APIs—reconnaissance, secrets and parameter access, IAM changes, or compute creation—beyond what routine pod traffic usually shows. High-volume S3 object reads and writes are excluded from the correlation set to reduce noise from normal data-plane work.

Read More

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.

Read More

Surfaces an AWS identity whose successful API traffic is dominated by a small set of large cloud-provider source AS organization labels, yet also shows a very small share of traffic from other AS organization names—including at least one sensitive control-plane, credential, storage, or model-invocation action on that uncommon network path with recent activity from the uncommon path. The intent is to highlight disproportionate “baseline” cloud egress versus sparse use from rarer networks on the same principal, a shape that can appear when automation or CI credentials are reused or pivoted outside their usual hosted-cloud footprint.

Read More

Identifies use of the S3 CopyObject API where the destination object is encrypted using an AWS KMS key from an external AWS account. This behavior may indicate ransomware-style impact activity where an adversary with access to a misconfigured S3 bucket encrypts objects using a KMS key they control, preventing the bucket owner from decrypting their own data. This technique is a critical early signal of destructive intent or cross-account misuse.

Read More

Identifies when the same AWS principal, from the same source IP, successfully invokes read-only S3 control-plane APIs that reveal bucket posture across many buckets in a short period. This pattern can indicate automated reconnaissance or security scanning, similar to CSPM tools and post-compromise enumeration. The rule excludes AWS service principals, requires programmatic-style sessions (not Management Console credentials), and requires populated resource and identity fields so nulls do not skew cardinality.

Read More

This rule detects when a JavaScript file is uploaded in an S3 static site directory (static/js/) by an IAM user or assumed role. This can indicate suspicious modification of web content hosted on S3, such as injecting malicious scripts into a static website frontend.

Read More

Identifies the first time an IAM principal passes a given execution role (roleArn) to an Amazon SageMaker resource, via CreateNotebookInstance, CreateTrainingJob, CreateProcessingJob, CreateAutoMLJob, or CreatePipeline. These actions require iam:PassRole and attach an IAM role that the created resource then runs as. An adversary holding both SageMaker create permissions and a broad iam:PassRole grant can pass a more privileged role to a resource they control and execute code as that role, escalating privileges. The rule keys on the combination of the calling principal and the passed roleArn, so it surfaces a principal using an execution role it has not used before in the last 7 days; a role whose account differs from the caller's, or that is more privileged than the caller, is especially suspicious.

Read More

Identifies an Amazon SageMaker notebook lifecycle configuration whose OnStart or OnCreate script, after base64 decoding, contains patterns associated with malicious activity such as reverse shells, EC2 instance metadata (IMDS) credential access, or download-and-execute commands. A lifecycle configuration runs as root on the notebook instance, so a script with these patterns is a strong indicator of an attempt to backdoor the notebook, steal the execution role's credentials, or establish persistent code execution. This rule decodes the script in the request and matches high-signal indicators; it is a higher-fidelity companion to the rule that alerts on any lifecycle configuration change.

Read More

Identifies when a single AWS principal makes GetServiceQuota API calls for the EC2 service quota L-1216C47A, across more than 10 AWS regions within a 30-second window. This quota represents the vCPU limit for on-demand EC2 instances. Adversaries commonly enumerate this quota across regions to assess capacity for large-scale instance deployment, including cryptocurrency mining, malware hosting, or command-and-control infrastructure. This behavior may indicate cloud infrastructure discovery using compromised credentials or a compromised workload.

Read More

Detects an SES email identity being verified and subsequently deleted within a 30-minute window, performed by the same AWS identity. Amazon SES requires email addresses and domains to be verified before they can be used as senders. An adversary who obtains SES credentials may verify a domain or address they control, use it to send phishing or spam email, then delete the identity to remove evidence of the sending domain from the account's verified identity list. This verify-use-delete pattern is a recognized attacker technique for SES abuse.

Read More

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.

Read More

Detects an unusually high ratio of 4xx HTTP responses from Azure AD Graph (graph.windows.net) per calling identity in a short window. Post-identity compromise leading to recon often leaves a tail of 403s and 404s as tooling walks endpoints it does not have permission for, asks for object IDs it does not have, or uses an OAuth client that has been pulled off the AAD Graph allow-list. Surges or an unexpected ratio of 4xx responses concentrated on a single (user and ASN) pair are characteristic of automated tooling rather than human or first-party traffic.

Read More

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.

Read More

Detects successful AKS pod exec sessions whose command resembles reverse-shell or bind-shell one-liner patterns, including /dev/tcp, /dev/udp and gawk /inet redirection, interactive invocation of any common shell, the netcat and ncat exec/listener forms, socat command-execution and listener addresses, mkfifo and mknod pipelines, socket idioms across Python, Perl, PHP, Ruby, Lua and Node, and tooling such as gsocket, openssl s_server and xterm. Legitimate debug sessions sometimes use similar building blocks, but together these patterns align with post-exploitation interactive access and command-and-control.

Read More

Identifies excessive secret or key retrieval operations from Azure Key Vault. This rule detects when a user principal retrieves secrets or keys from Azure Key Vault multiple times within a short time frame, which may indicate potential abuse or unauthorized access attempts. The rule focuses on high-frequency retrieval operations that deviate from normal user behavior, suggesting possible credential harvesting or misuse of sensitive information.

Read More

Detects when Azure OpenAI requests result in zero response length, potentially indicating issues in output handling that might lead to security exploits such as data leaks or code execution. This can occur in cases where the API fails to handle outputs correctly under certain input conditions.

Read More

Correlates successful Azure Virtual Machine Run Command operations with endpoint process execution on the same host within minutes. Adversaries abuse Run Command to run scripts remotely as SYSTEM or root while activity logs only record the control-plane action; Elastic Defend process telemetry reveals the on-guest payload.

Read More

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.

Read More

Identifies process execution events where the command line value contains a long sequence of whitespace characters or multiple occurrences of contiguous whitespace. Attackers may attempt to evade signature-based detections by padding their malicious command with unnecessary whitespace characters. These observations should be investigated for malicious behavior.

Read More

This rule correlates alerts from multiple integrations and event categories that involve different user.name values which may represent the same real-world identity. It uses an LLM-based similarity analysis to evaluate whether multiple user identifiers (e.g. naming variations, formats, aliases, or domain differences) likely belong to the same person.

Read More

This rule correlates security alerts with processes exhibiting unusually high CPU utilization on the same host and process ID within a short time window. This behavior may indicate malicious activity such as malware execution, cryptomining, exploit payload execution, or abuse of system resources following initial compromise.

Read More

Detects PowerShell scripts that rebuilds IEX by converting method references to strings (for example, ''.IndexOf.ToString()) and extracting multiple indexed characters (for example, [n,n,n]). Attackers use method-string reconstruction to conceal dynamic execution and bypass static detections and AMSI.

Read More

Detects Elastic Defend alerts (behavior, malicious file, memory signature, shellcode) where the alerted process or its direct parent is a GenAI coding or assistant utility (e.g. Cursor, Claude, Windsurf, Cody, Continue, Aider, OpenClaw, Moltbot, Clawdbot, Codeium, Tabnine, GitHub Copilot). Activity from these tools can indicate prompt injection, malicious skills, or supply-chain abuse; this Higher-Order rule helps prioritize such alerts for triage.

Read More

Detects Elastic Defend alerts (behavior, malicious file, memory signature, shellcode) where the alerted process has a package-manager install context in its ancestry: npm (Node.js), PyPI (pip / Python / uv), or Rust (cargo). Install-time spawn chains are a common path for supply-chain and postinstall abuse; this Higher-Order rule surfaces Defend alerts whose process tree includes such activity for prioritization.

Read More

This rule correlates any Elastic Defend alert with an email security related alert by target user name. This may indicate the successful execution of a phishing attack.

Read More

This rule correlate any Elastic Defend alert with a set of suspicious events from Network security devices like Palo Alto Networks (PANW), Fortinet Fortigate and Suricata by host.ip and source.ip. This may indicate that this host is compromised and triggering multi-datasource alerts.

Read More

Identifies potential abuse of actor tokens in Microsoft Entra ID audit logs. Actor tokens are undocumented backend mechanisms used by Microsoft for service-to-service (S2S) operations, allowing services to perform actions on behalf of users. These tokens appear in logs with the service's display name but the impersonated user's UPN. While some legitimate Microsoft operations use actor tokens, unexpected usage may indicate exploitation of CVE-2025-55241, which allowed unauthorized access to Azure AD Graph API across tenants before being patched by Microsoft.

Read More

Identifies concurrent azure signin events for the same user and from multiple sources, and where one of the authentication event has some suspicious properties often associated to DeviceCode and OAuth phishing. Adversaries may steal Refresh Tokens (RTs) via phishing to bypass multi-factor authentication (MFA) and gain unauthorized access to Azure resources.

Read More

Identifies a Microsoft Entra ID device registration by the same user within 15 minutes of a phishing-resistant, device-bound credential (Windows Hello for Business, FIDO2 security key, or passkey) signing in with no device identifier. In the "borrowing Windows Hello keys" technique, an adversary reuses a WHfB/NGC key or passkey away from its bound device to mint device-agnostic tokens, then uses those tokens to register an attacker-controlled device and obtain a Primary Refresh Token (PRT) for long-lived persistence. Timing is taken from the authentication step on the sign-in, not the sign-in document timestamp, because Entra can emit the sign-in record after the Register device audit event. This chain is distinct from device-code-flow phishing kits.

Read More

Detects when the issuer URL of a federated identity credential is changed on an Entra ID application. Adversaries may modify the issuer to point to an attacker-controlled identity provider, enabling them to authenticate as the application's service principal and gain persistent access to Azure resources. This technique allows bypassing traditional authentication controls by federating trust with a malicious external identity provider.

Read More

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.

Read More

Identifies brute force attempts against Azure Entra multi-factor authentication (MFA) Time-based One-Time Password (TOTP) verification codes. This rule detects high frequency failed TOTP code attempts for a single user in a short time-span with a high number of distinct session IDs. Adversaries may programmatically attemopt to brute-force TOTP codes by generating several sessions and attempt to guess the correct code.

Read More

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.

Read More

Identifies Entra ID device code authentication flows where multiple user agents are observed within the same session. This pattern is indicative of device code phishing, where an attacker's polling client (e.g., Python script) and the victim's browser both appear in the same authentication session. In legitimate device code flows, the user authenticates via browser while the requesting application polls for tokens - when these have distinctly different user agents (e.g., Python Requests vs Chrome), it may indicate the code was phished and redeemed by an attacker.

Read More

Identifies separate OAuth authorization flows in Microsoft Entra ID where the same user principal and session ID are observed across multiple IP addresses within a 5-minute window. These flows involve the Microsoft Authentication Broker (MAB) as the client application and the Device Registration Service (DRS) as the target resource. This pattern is highly indicative of OAuth phishing activity, where an adversary crafts a legitimate Microsoft login URL to trick a user into completing authentication and sharing the resulting authorization code, which is then exchanged for an access and refresh token by the attacker.

Read More

Identifies potential session hijacking or token replay in Microsoft Entra ID. This rule detects cases where a user signs in and subsequently accesses Microsoft Graph from a different IP address using the same session ID. This may indicate a successful OAuth phishing attack, session hijacking, or token replay attack, where an adversary has stolen a session cookie or refresh/access token and is impersonating the user from an alternate host or location.

Read More

Identifies potential brute-force attacks targeting Microsoft 365 user accounts by analyzing failed sign-in patterns in Microsoft Entra ID Sign-In Logs. This detection focuses on a high volume of failed interactive or non-interactive authentication attempts within a short time window, often indicative of password spraying, credential stuffing, or password guessing. Adversaries may use these techniques to gain unauthorized access to Microsoft 365 services such as Exchange Online, SharePoint, or Teams.

Read More

Identifies potential brute-force attacks targeting user accounts by analyzing failed sign-in patterns in Microsoft Entra ID Sign-In Logs. This detection focuses on a high volume of failed interactive or non-interactive authentication attempts within a short time window, often indicative of password spraying, credential stuffing, or password guessing. Adversaries may use these techniques to gain unauthorized access to applications integrated with Entra ID or to compromise valid user accounts.

Read More

This rule leverages ESQL to detect the execution of unusual file transfer utilities on Linux systems. Attackers may use these utilities to exfiltrate data from a compromised system. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert.

Read More

Identifies a newly observed NetFlow, IPFIX, or sFlow exporter IP followed by another detection alert with medium-or-higher severity or an elevated risk score, where that exporter IP is the source of the detected activity in the same data stream namespace. This correlation adds behavioral evidence that can help distinguish routine exporter onboarding from a potentially unauthorized or compromised exporter introduced as part of defense evasion.

Read More

Detects DNS queries to commonly abused remote monitoring and management (RMM) or remote access software domains from processes that are not browsers. Intended to surface RMM clients, scripts, or other non-browser activity contacting these services.

Read More

This rule detects the first observed successful login of a user with the Administrator role to the FortiGate management interface within the last 5 days. First-time administrator logins can indicate newly provisioned accounts, misconfigurations, or unauthorized access using valid credentials and should be reviewed promptly.

Read More

This rule detects successful logins to the FortiGate management interface using the same Administrator account from multiple distinct source IP addresses within an 24-hour period. Administrator logins from multiple locations in a short time window may indicate credential sharing, compromised credentials, or unauthorized access and should be investigated.

Read More

This rule detects the first successful FortiCloud SSO login from a previously unseen source IP address to a FortiGate device within the last 5 days. FortiCloud SSO logins from new source IPs may indicate exploitation of SAML-based authentication bypass vulnerabilities such as CVE-2026-24858, where crafted SAML assertions allow unauthorized access to FortiGate devices registered to other accounts. Environments that regularly use FortiCloud SSO will only alert on new source IPs not seen in the lookback window.

Read More

Detects a single identity listing Google Cloud Secret Manager secrets across many distinct projects in a short window. ListSecrets does not return secret values, but sweeping many projects is a common reconnaissance step before targeted AccessSecretVersion calls. Legitimate workloads typically list secrets within one project or a small set of projects; cross-project bursts from one user and source IP are uncommon outside security tooling or compromise.

Read More

Detects when a GitHub Actions workflow attempts to create or modify workflow files in a protected branch but is blocked due to insufficient permissions. This behavior is indicative of a supply chain attack where a malicious package or compromised CI/CD pipeline attempts to inject persistent backdoor workflows into a repository.

Read More

Detects a high number of repository cloning actions by a single user within a short time frame. Adversaries may clone multiple repositories to exfiltrate sensitive data.

Read More

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".

Read More

Detects creation of a GKE CertificateSigningRequest (CSR) whose decoded subject requests a highly privileged Kubernetes identity in the Common Name (CN), such as system:masters, system:kube-controller-manager, or system:admin. This rule is scoped to identities with cluster-admin-equivalent or control-plane impersonation value. Attackers who can create and approve CSRs can use this technique to clone credentials for powerful identities and obtain durable cluster access. This signal applies to any actor, including compromised node identities that use legitimate kubelet signers but request a privileged CN.

Read More

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.

Read More

Detects a single authenticated GKE identity from one source IP issuing a burst of API calls across many distinct actions and resources with a mix of successful and failed outcomes. That pattern is consistent with automated RBAC permission enumeration rather than steady-state controller traffic. Anonymous probing is covered by a separate rule.

Read More

Adversaries who land credentials in a GKE cluster—or abuse an over-privileged token, often map the environment before exfiltration or privilege escalation. A practical first pass is to learn where workloads run, how the cluster is partitioned, and what RBAC exists at namespace vs cluster scope. Rapid get/list traffic across many distinct API resource kinds that answer those questions (namespaces, workloads, roles, cluster-wide roles) is a common setup and orientation pattern for both interactive attackers and automated recon scripts. This rule highlights that cross-resource burst from a single client fingerprint within a one-minute bucket when both cluster-layout and RBAC resource kinds are touched, so analysts can separate routine automation from potential discovery ahead of follow-on actions.

Read More

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.

Read More

Detects when the same GKE identity creates or modifies a Role or ClusterRole with high-risk permissions (wildcard access, RBAC escalation verbs, or access to secrets / privileged APIs) and also creates or patches a DaemonSet, Deployment, or CronJob within five minutes. This correlation is consistent with RBAC-based privilege escalation followed by payload deployment.

Read More

Detects bursts of Google Workspace device registration events for the same user, where three or more distinct "google_workspace.device.id" values are emitted in a one-minute window. Although "DEVICE_REGISTER_UNREGISTER_EVENT" fires routinely on session/sync registration and is not a true physical device enrollment, legitimate user activity typically produces fewer than three distinct device IDs in a single minute. A high-cardinality burst is the fingerprint behavior of AiTM phishing-kit relays (Tycoon2FA Google variant, EvilGinx phishlets) and stolen-OAuth-token replay tooling, both of which mint a new session attestation per relay or replay attempt.

Read More

Detects successful Google Workspace sign-ins for the same user from two geographically separated locations within a 90-minute window, where the implied travel speed between the two points exceeds what is physically possible (>=800 km/h, faster than modern commercial airliners) and the geographic separation is at least 500 km. This pattern indicates either VPN/proxy use or an adversary signing in to a compromised account from a different location than the legitimate user.

Read More

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.

Read More

Detects a high number of closed pull requests by a single user within a short time frame. Adversaries may close multiple pull requests to disrupt development workflows or hide malicious changes.

Read More

This rule detects a high number of egress network connections from an unusual executable on a Linux system. This could indicate a command and control (C2) communication attempt, a brute force attack via a malware infection, or other malicious activity. ESQL rules have limited fields available in its alert documents. Make sure to review the original documents to aid in the investigation of this alert.

Read More

Detects a high number of force push actions to protected branches by a single user within a short time frame. Adversaries may perform force pushes to overwrite commit history on protected branches, potentially leading to data loss or disruption of development workflows.

Read More

Detects the creation or modification of Kubernetes Roles or ClusterRoles that grant high-risk permissions, such as wildcard access or RBAC escalation verbs (e.g., bind, escalate, impersonate), which may enable privilege escalation or unauthorized access within the cluster.

Read More

Adversaries who land credentials in a cluster—or abuse an over-privileged token—often map the environment before exfiltration or privilege escalation. A practical first pass is to learn where workloads run, how the cluster is partitioned, and what RBAC exists at namespace vs cluster scope. Rapid get/list traffic across distinct API resource kinds that answer those questions (namespaces, workloads, roles, cluster-wide roles) is a common setup and orientation pattern for both interactive attackers and automated recon scripts. It is less typical for steady-state controllers, which usually touch a narrow set of resources repeatedly. This rule highlights that cross-resource burst from a single client fingerprint within a one-minute bucket so analysts can separate routine automation from potential discovery and permission reconnaissance ahead of follow-on actions.

Read More

This rule detects potential endpoint enumeration attempts by an anonymous user. An anonymous user is a user that is not authenticated or authorized to access the Kubernetes API server. By looking for a series of failed API requests, on multiple endpoints, and a limited number of documents, this rule can detect automated permission enumeration attempts. This behavior is uncommon for regular Kubernetes clusters.

Read More

This rule detects potential endpoint enumeration attempts by a single user and source IP address. By looking for a combination of failed/successful API requests across multiple endpoints and a limited number of documents, this rule can detect automated permission enumeration attempts. This behavior is uncommon for regular Kubernetes clusters.

Read More

This rule detects an unusual volume of Kubernetes API get requests against multiple distinct Secret objects from the same client fingerprint (user, source IP, and user agent) within a defined 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 also included, as they may reveal RBAC boundaries, confirm the existence of targeted secrets, or reflect automated probing activity.

Read More

Flags an existing 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. RequestResponse audit and the response body are required so the detection reads the merged role after apply; loopback source IPs are ignored.

Read More

Detects when secrets or configmaps are accessed, created, modified, or deleted in a Kubernetes cluster by the Azure Arc AAD proxy service account. When operations are routed through the Azure Arc Cluster Connect proxy, the Kubernetes audit log records the acting user as system:serviceaccount:azure-arc:azure-arc-kube-aad-proxy-sa with the actual caller identity in the impersonatedUser field. This pattern indicates that someone is accessing the cluster through the Azure ARM API rather than directly via kubectl against the API server. While legitimate for Arc-managed workflows, adversaries with stolen service principal credentials can abuse Arc Cluster Connect to read, exfiltrate, or modify secrets and configmaps while appearing as the Arc proxy service account in K8s audit logs. This rule uses a 5-day new-terms history window keyed on the impersonated identity and alerts the first time that Azure AD principal performs this activity.

Read More

This rule detects source IPs that triggered their first lateral movement alert within the last 10 minutes (i.e., newly observed), while also triggering at least 2 distinct lateral movement detection rules. This surfaces new potentially malicious IPs exhibiting immediate lateral movement behavior.

Read More

This rule detects multiple lateral movement alerts from a user that was observed for the first time in the previous 5 days of alerts history. Analysts can use this high-order detection to prioritize triage and response.

Read More

This rule correlates multiple endpoint security alerts from the same host and uses an LLM to analyze command lines, parent processes, file operations, DNS queries, registry modifications, module loads and MITRE ATT&CK tactics progression to determine if they form a coherent attack chain. The LLM provides a verdict (TP/FP/SUSPICIOUS) with confidence score and summary explanation, helping analysts to prioritize hosts exhibiting corroborated malicious behavior while filtering out benign activity.

Read More

This rule correlates multiple security alerts involving the same user across hosts and data sources, then uses an LLM to analyze whether they indicate account compromise. The LLM evaluates alert patterns, MITRE tactics progression, geographic anomalies, and multi-host activity to provide a verdict and confidence score, helping analysts prioritize users exhibiting indicators of credential theft or unauthorized access.

Read More

Detects non-allowlisted curl activity on Linux, macOS, and Windows hosts and uses an LLM to assess whether the activity is malicious, benign, or requires investigation. The rule parses and normalizes the destination, redacts sensitive command-line values, and aggregates activity by host and destination before invoking the ES|QL COMPLETION command. Only true positive or suspicious verdicts with confidence above 0.7 generate alerts.

Read More

Detects non-allowlisted curl activity on Linux hosts via Auditd Manager or Auditbeat and uses an LLM to assess whether the activity is malicious, benign, or requires investigation. The rule parses and normalizes the destination, redacts sensitive command-line values, and aggregates activity by host and destination before invoking the ES|QL COMPLETION command. Only true positive or suspicious verdicts with confidence above 0.7 generate alerts.

Read More

Detects non-allowlisted wget activity on Linux, macOS, and Windows hosts and uses an LLM to assess whether the activity is malicious, benign, or requires investigation. The rule parses and normalizes the destination, redacts sensitive command-line values, and aggregates activity by host and destination before invoking the ES|QL COMPLETION command. Only true positive or suspicious verdicts with confidence above 0.7 generate alerts.

Read More

Detects non-allowlisted wget activity on Linux hosts via Auditd Manager or Auditbeat and uses an LLM to assess whether the activity is malicious, benign, or requires investigation. The rule parses and normalizes the destination, redacts sensitive command-line values, and aggregates activity by host and destination before invoking the ES|QL COMPLETION command. Only true positive or suspicious verdicts with confidence above 0.7 generate alerts.

Read More

Identifies oversized command lines used by Python, PowerShell, Node.js, or Deno that contain base64 decoding or encoded-command patterns. Adversaries may embed long inline encoded payloads in scripting interpreters to evade inspection and execute malicious content across Windows, macOS, and Linux systems.

Read More

Detects Azure Monitor alert notification emails with financial or billing themed subject lines delivered to organization users. Adversaries abuse Azure Monitor alert rules to deliver callback phishing emails from Microsoft's legitimate azure-noreply@microsoft.com address. Because the emails originate from Microsoft's own infrastructure, they pass SPF, DKIM, and DMARC checks, bypassing email security filters and increasing victim trust. The attacker embeds a fraudulent billing or security lure in the alert rule description, which is rendered in the notification email body. Observed subject patterns include invoice numbers, payment references, and order confirmations.

Read More

Identifies when a Microsoft Exchange inbox rule is created or modified with a name composed only of special characters. Adversaries may use obfuscated inbox rule names to evade detection, hide malicious forwarding or deletion rules, or blend in with benign audit noise. The rule name is parsed from "o365.audit.ObjectId", which encodes the mailbox identity and rule name separated by a backslash.

Read More

Identifies sign-ins on behalf of a principal user to the Microsoft Graph or legacy Azure AD API from multiple IPs using first-party Microsoft applications from the FOCI (Family of Client IDs) group. Developer tools like Azure CLI, VSCode, and Azure PowerShell accessing these resources from multiple IPs are flagged, along with any FOCI application accessing the deprecated Windows Azure Active Directory from multiple IPs. This behavior may indicate an adversary using a phished OAuth authorization code or refresh token, as seen in attacks like ConsentFix where attackers steal localhost OAuth codes and replay them from attacker infrastructure.

Read More

Detects a burst of Microsoft 365 user account lockouts within a short 5-minute window. A high number of IdsLocked login errors across multiple user accounts may indicate brute-force attempts for the same users resulting in lockouts.

Read More

Identifies brute-force authentication activity targeting Microsoft 365 user accounts using failed sign-in patterns that match password spraying, credential stuffing, or password guessing behavior. Adversaries may attempt brute-force authentication with credentials obtained from previous breaches, leaks, marketplaces or guessable passwords.

Read More

Identifies when an excessive number of files are downloaded from OneDrive or SharePoint by an authorized user or application in a short period of time. This may indicate a potential data exfiltration event, especially if the downloads are performed using OAuth authentication which could suggest an OAuth phishing attack such as Device Code Authentication phishing.

Read More

This rule correlate Entra-ID or Microsoft 365 mail successful sign-in events with network security alerts by source address. Adversaries may trigger some network security alerts such as reputation or other anomalies before accessing cloud resources.

Read More

Detects successful Microsoft Entra ID interactive sign-ins for the same user from two geographically separated locations within a 90-minute window, where the implied travel speed between the two points exceeds what is physically possible (>=800 km/h, faster than modern commercial airliners) and the geographic separation is at least 500 km. This pattern indicates either VPN/proxy use or an adversary signing in to a compromised account from a different location than the legitimate user. Non-interactive sign-in categories are excluded because backend token refresh activity routinely egresses through cloud regions unrelated to the user. This activity is often observed from AiTM phishing kits or successful phishing campaigns.

Read More

Detects Microsoft Graph activity from delegated user tokens (public client, client_auth_method 0) where a single user session and source IP rapidly touches multiple high-value Graph paths indicative of reconnaissance. The query classifies requests into categories such as role discovery, cross-tenant relationship queries, mailbox paths, contact harvesting, and organization or licensing metadata. When three or more distinct categories appear within a short burst window, it suggests a broad enumeration playbook rather than normal application traffic.

Read More

Correlates process telemetry for shells and major cloud/Kubernetes CLIs when command lines match token or credential material access patterns (GCP, Azure, AWS, GitHub, kubectl, DigitalOcean, OCI). Flags hosts where multiple cloud targets appear within a five-minute window.

Read More

This rule correlates multiple security alerts associated with the same ATT&CK tactic on a single host within a defined time window. By requiring alerts from multiple distinct detection rules, this detection helps identify hosts exhibiting concentrated malicious behavior, which may indicate an active intrusion or post-compromise activity. The rule is intended to assist analysts in prioritizing triage toward hosts with higher likelihood of compromise rather than signaling a single discrete event.

Read More

This rule uses alert data to determine when multiple different alerts involving the same user are triggered. Analysts can use this to prioritize triage and response, as these users are more likely to be compromised.

Read More

This rule correlates multiple security alerts from a host exhibiting unusually high CPU utilization within a short time window. This behavior may indicate malicious activity such as malware execution, cryptomining, exploit payload execution, or abuse of system resources following initial compromise.

Read More

This rule detects authenticated sessions accessing secret stores across multiple environments from the same source address within a short period of time, including cloud providers (AWS, GCP, Azure) and Kubernetes clusters. Adversaries with access to compromised credentials or session tokens may attempt to retrieve secrets from services such as AWS Secrets Manager, Google Secret Manager, Azure Key Vault, or Kubernetes Secrets in rapid succession to expand their access or exfiltrate sensitive information.

Read More

This rule detects when a specific Okta actor has multiple device token hashes and multiple source IPs for a single Okta session. This may indicate an authenticated session has been hijacked or replayed from a different device and network. Adversaries may steal session cookies or tokens to gain unauthorized access to Okta admin console, applications, tenants, or other resources.

Read More

Identifies two or more distinct DHCP servers sending an OFFER or ACK for the same transaction ID (xid) within a short window, indicating a rogue DHCP server racing the legitimate one to win the client's handshake. This is the rogue-DHCP / adversary-in-the-middle precondition (T1557.003) and is operating-system agnostic, since it keys only on server behavior observed on the wire. Winning the race lets an attacker intercept traffic via a hostile gateway/DNS, bypass a VPN (TunnelVision), or deliver a malformed response that exploits the client's DHCP parser for code execution.

Read More

This rule uses alert data to determine when multiple alerts from Elastic Defend involving the same host are triggered. Analysts can use this to prioritize triage and response, as these hosts are more likely to be compromised.

Read More

Detects multiple Elastic Defend EDR alerts originating from the same process tree, indicating coordinated malicious activity. Analysts can use this to prioritize triage and response, as these hosts are more likely to be compromised.

Read More

This rule uses alert data to determine when multiple external EDR alerts involving the same host are triggered. Analysts can use this to prioritize triage and response, as these hosts are more likely to be compromised.

Read More

Identifies multiple consecutive logon failures from the same source address and within a short time interval. Adversaries will often brute force login attempts across multiple users with a common or known password, in an attempt to gain access to accounts.

Read More

This rule uses alerts data to determine when multiple unique machine learning jobs involving the same influencer field are triggered. Analysts can use this to prioritize triage and response machine learning alerts.

Read More

Detects when a high number of Okta user authentication events are reported for multiple users in a short time frame. Adversaries may attempt to launch a credential stuffing or password spraying attack from the same device by using a list of known usernames and passwords to gain unauthorized access to user accounts.

Read More

Identifies hosts that triggered multiple distinct Elastic Defend behavior rules, while reducing false positives by considering only behavior rules that appear on a single host globally (via INLINE STATS). Hosts with two or more such rare behavior rules are more likely to be compromised and warrant prioritized triage.

Read More

Identifies a Windows host where two or more distinct remote monitoring and management (RMM) or remote-access tool vendors are observed starting processes within the same eight-minute window. Legitimate MSP environments may run multiple tools, but this pattern can also indicate compromise, shadow IT, or attacker staging of redundant access. Processes are mapped to a single vendor label so multiple binaries from the same vendor do not inflate the count.

Read More

Identifies multiple failed SonicWall authentication attempts against several user accounts from one source IP, followed by a successful remote-access login from the same source to the same appliance. This may indicate successful password spraying, credential stuffing, or password guessing.

Read More

This alert identifies assets with an elevated number of vulnerabilities reported by Wiz, potentially indicating weak security posture, missed patching, or active exposure. The rule highlights assets with a high volume of distinct vulnerabilities, the presence of exploitable vulnerabilities, or a combination of multiple severities, helping prioritize assets that pose increased risk.

Read More