Elastic rules: 3j

[metadata]
creation_date = "2025/04/16"
integration = ["aws"]
maturity = "production"
min_stack_version = "9.3.0"
min_stack_comments = "Changing min stack to 9.3.0, the latest minimum supported version for 9.X releases."
updated_date = "2026/07/20"

[rule]
author = ["Elastic"]
description = """
Detects sensitive AWS IAM API operations executed using temporary session credentials (access key IDs beginning with
"ASIA"). Temporary credentials are commonly issued through sts:GetSessionToken, sts:AssumeRole, or AWS SSO logins and
are meant for short-term use. It is unusual for legitimate users or automated processes to perform privileged IAM
actions (e.g., creating users, updating policies, or enabling/disabling MFA) with session tokens. This behavior may
indicate credential theft, session hijacking, or the abuse of a privileged role’s temporary credentials.
"""
false_positives = [
    """
    Some CI/CD pipelines or administrative users may use session tokens. Review user context, IP, and timing to
    validate. This rule automatically excludes console login sessions using the aws.cloudtrail.session_credential_from_console
    field, which significantly reduces false positives from legitimate console-based IAM operations.
    """,
]
from = "now-6m"
index = ["logs-aws.cloudtrail-*"]
language = "kuery"
license = "Elastic License v2"
name = "AWS IAM API Calls via Temporary Session Tokens"
note = """## Triage and analysis

### Investigating AWS IAM API Calls via Temporary Session Tokens

Temporary session credentials in AWS (identified by access keys beginning with "ASIA") are typically short-lived tokens 
issued by the AWS Security Token Service (STS). While they are legitimate and often used by developers or automation pipelines, 
their use in direct IAM management or privilege modification is highly unusual and may indicate credential misuse.

Attackers who compromise IAM users, roles, or federated identities can obtain session tokens to blend in with normal operations. 
They may then execute sensitive IAM API actions such as `CreateAccessKey`, `PutUserPolicy`, or `UpdateAssumeRolePolicy` to 
establish persistence, escalate privileges, or disable protections.

### Possible investigation steps

- **Identify the actor**
  - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.type` to determine the originating user or role.
  - This rule automatically filters out console login sessions using `aws.cloudtrail.session_credential_from_console`, so alerts indicate non-console temporary credential usage.
  - Examine `aws.cloudtrail.user_identity.session_context.mfa_authenticated` — absence of MFA may indicate token misuse.

- **Analyze the API context**
  - Review `event.action` and `aws.cloudtrail.request_parameters` for the exact IAM operation performed.
  - Identify whether the action modifies roles, user policies, trust relationships, or credentials.
  - Determine if this session token was associated with prior `sts:GetSessionToken`, `sts:AssumeRole`, or `AWS SSO` events.

- **Evaluate source and behavior**
  - Inspect `source.ip` and `user_agent.original` for unexpected origins or tools.
  - Check if the request came from known infrastructure (e.g., CI/CD nodes, bastion hosts) or an anomalous network.
  - Compare `@timestamp` against normal operating hours or deployment schedules.

- **Correlate related activity**
  - Look for subsequent or preceding activity using the same access key:
    - IAM changes (`CreateUser`, `AttachUserPolicy`, `EnableMFADevice`)
    - STS operations (`AssumeRole`, `GetCallerIdentity`)
    - CloudTrail or GuardDuty configuration changes (possible defense evasion)
  - If applicable, search for multiple users exhibiting similar patterns, a sign of large-scale token misuse.

### False positive analysis

- **Expected automation**
  - Some CI/CD pipelines, monitoring tools, or AWS SDK-based automation may perform IAM operations using temporary credentials.
  - Validate whether the IAM user or assumed role performing these actions belongs to an authorized automation workflow.
- **Administrative operations**
  - Security or DevOps engineers may temporarily use session credentials for maintenance or testing.
  - Cross-reference with recent change tickets or known operations schedules.
- **Federated identity scenarios**
  - Federated logins (via AWS SSO or external IdPs) can also generate temporary "ASIA" credentials. Verify if the source identity 
    aligns with expected roles or groups.
- **Console Login Session**
  - Console login sessions are automatically filtered out by this rule using the `aws.cloudtrail.session_credential_from_console` field.

### Response and remediation

- **Containment**
  - If activity is unauthorized, immediately revoke the temporary session by invalidating the associated IAM credentials.
  - Rotate long-term credentials (access keys, passwords) for the parent IAM user or role.

- **Investigation**
  - Search for all actions linked to the same `access_key_id` to assess potential persistence or lateral movement.
  - Examine the creation of new users, keys, or policies during or shortly after the detected session.

- **Recovery and hardening**
  - Require MFA for all privileged actions using `aws:MultiFactorAuthPresent` conditions.
  - Implement detection coverage for follow-on persistence actions such as:
    - `iam:CreateAccessKey`
    - `iam:PutUserPolicy`
    - `iam:UpdateAssumeRolePolicy`
  - Educate administrative users and developers on secure token handling and the risks of shared credential reuse.

### Additional information

For more information on detecting and mitigating session token abuse:
- **[AWS Security Token Service (STS) Documentation](https://docs.aws.amazon.com/STS/latest/APIReference/Welcome.html)**
- **[AWS IR Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/)** 
- **[AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs)** 
- **Security Best Practices:** [AWS Knowledge Center – Security Best Practices](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/).
"""
references = ["https://www.sygnia.co/blog/sygnia-investigation-bybit-hack/"]
risk_score = 73
rule_id = "c70d9f0d-8cb6-4cfc-85df-a95c1ccf4eab"
severity = "high"
tags = [
    "Domain: Cloud",
    "Data Source: AWS",
    "Data Source: Amazon Web Services",
    "Data Source: AWS CloudTrail",
    "Data Source: AWS IAM",
    "Data Source: AWS STS",
    "Tactic: Persistence",
    "Tactic: Privilege Escalation",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "new_terms"

query = '''
data_stream.dataset: aws.cloudtrail
    and event.provider: ("iam.amazonaws.com")
    and event.outcome: "success"
    and aws.cloudtrail.user_identity.type: "IAMUser"
    and aws.cloudtrail.user_identity.access_key_id: ASIA*
    and source.ip: *
    and not user_agent.original : "AWS Internal"
    and not aws.cloudtrail.session_credential_from_console: true
'''


[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1098"
name = "Account Manipulation"
reference = "https://attack.mitre.org/techniques/T1098/"

[rule.threat.tactic]
id = "TA0003"
name = "Persistence"
reference = "https://attack.mitre.org/tactics/TA0003/"

[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1078"
name = "Valid Accounts"
reference = "https://attack.mitre.org/techniques/T1078/"

[[rule.threat.technique.subtechnique]]
id = "T1078.004"
name = "Cloud Accounts"
reference = "https://attack.mitre.org/techniques/T1078/004/"

[rule.threat.tactic]
id = "TA0005"
name = "Defense Evasion"
reference = "https://attack.mitre.org/tactics/TA0005/"
[rule.investigation_fields]
field_names = [
    "@timestamp",
    "user.name",
    "user_agent.original",
    "source.ip",
    "aws.cloudtrail.user_identity.arn",
    "aws.cloudtrail.user_identity.type",
    "aws.cloudtrail.user_identity.access_key_id",
    "event.action",
    "event.outcome",
    "cloud.account.id",
    "cloud.region",
    "aws.cloudtrail.request_parameters",
]

[rule.new_terms]
field = "new_terms_fields"
value = ["aws.cloudtrail.user_identity.arn"]
[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-7d"

[metadata]
creation_date = "2026/04/08"
integration = ["aws"]
maturity = "production"
updated_date = "2026/08/05"

[rule]
author = ["Elastic"]
description = """
Identifies successful PutKeyPolicy calls on AWS KMS keys. The key policy is a resource-based policy that controls which
principals can use the key for cryptographic operations and administration. Adversaries with "kms:PutKeyPolicy" may add
or broaden principals (including external accounts) to decrypt or exfiltrate data protected by the key, or to preserve
access after other credentials are rotated. This is distinct from disabling or scheduling deletion of the key.
"""
false_positives = [
    """
    Security, platform, and encryption teams legitimately update KMS key policies during onboarding, key rotation, or
    cross-account access design. Review the policy document diff, ticketing, and whether new principals are in-org.
    """,
]
from = "now-6m"
index = ["filebeat-*", "logs-aws.cloudtrail-*"]
language = "kuery"
license = "Elastic License v2"
name = "AWS KMS Key Policy Updated via PutKeyPolicy"
note = """## Triage and analysis

### Investigating AWS KMS Key Policy Updated via PutKeyPolicy

`PutKeyPolicy` replaces the entire key policy for a customer managed KMS key (and is used in limited scenarios for AWS
managed keys). Unexpected changes can grant `kms:Decrypt`, `kms:GenerateDataKey`, or administrative actions to new
identities.

#### Possible investigation steps

- Identify the key from `aws.cloudtrail.resources.arn` or `aws.cloudtrail.request_parameters.keyId`.
- Inspect `policy` in `aws.cloudtrail.request_parameters` (or related fields) for new `Principal`, `AWS`, or
  `kms:CallerAccount` entries and cross-account ARNs.
- Determine which data stores use the key (S3, EBS, RDS, Secrets Manager, etc.) via CMK aliases or CMDB.
- Correlate with `iam:AttachRolePolicy`, `sts:AssumeRole`, or data-plane access from newly added principals.

### False positive analysis

- Planned multi-account encryption patterns; confirm recipient accounts are approved.

### Response and remediation

- If unauthorized: restore a known-good policy from backup or IAM/KMS change history, remove rogue principals, and
  restrict `kms:PutKeyPolicy` to break-glass roles.

### Additional information

- [PutKeyPolicy](https://docs.aws.amazon.com/kms/latest/APIReference/API_PutKeyPolicy.html)
- [KMS key policies](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html)
"""
references = [
    "https://docs.aws.amazon.com/kms/latest/APIReference/API_PutKeyPolicy.html",
    "https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html",
]
risk_score = 47
rule_id = "f6a0b2c3-4d5e-4f7a-8b9c-0d1e2f3a4b5c"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Platform: AWS",
    "Data Source: AWS CloudTrail",
    "Service: AWS KMS",
    "Tactic: Defense Evasion",
    "Tactic: Privilege Escalation",
    "Rule Type: Custom Query (KQL)",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
event.dataset: "aws.cloudtrail"
    and event.provider: "kms.amazonaws.com"
    and event.action: "PutKeyPolicy"
    and event.outcome: "success"
    and not aws.cloudtrail.user_identity.type: "AWSService"
    and not user_agent.original: (*Terraform* or *Pulumi*)
'''

[rule.investigation_fields]
field_names = [
    "@timestamp",
    "user.name",
    "user_agent.original",
    "source.ip",
    "aws.cloudtrail.user_identity.arn",
    "aws.cloudtrail.user_identity.type",
    "aws.cloudtrail.user_identity.access_key_id",
    "aws.cloudtrail.resources.arn",
    "aws.cloudtrail.resources.type",
    "event.action",
    "event.outcome",
    "cloud.account.id",
    "cloud.region",
    "aws.cloudtrail.request_parameters",
    "aws.cloudtrail.response_elements",
]


[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1548"
name = "Abuse Elevation Control Mechanism"
reference = "https://attack.mitre.org/techniques/T1548/"

[[rule.threat.technique.subtechnique]]
id = "T1548.005"
name = "Temporary Elevated Cloud Access"
reference = "https://attack.mitre.org/techniques/T1548/005/"

[rule.threat.tactic]
id = "TA0004"
name = "Privilege Escalation"
reference = "https://attack.mitre.org/tactics/TA0004/"

[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1562"
name = "Impair Defenses"
reference = "https://attack.mitre.org/techniques/T1562/"

[rule.threat.tactic]
id = "TA0005"
name = "Defense Evasion"
reference = "https://attack.mitre.org/tactics/TA0005/"

[metadata]
creation_date = "2024/11/05"
integration = ["aws"]
maturity = "production"
updated_date = "2026/04/10"

[rule]
author = ["Elastic"]
description = """
Identifies when a user or role has assumed a role in AWS Security Token Service (STS). Users can assume a role to obtain
temporary credentials and access AWS resources. Adversaries can use this technique for credential access and privilege
escalation. This is a New Terms rule that identifies when a user assumes a role in AWS Security Token Service (STS)
to obtain temporary credentials and access AWS resources. While often legitimate, adversaries may use this technique for
unauthorized access, privilege escalation, or lateral movement within an AWS environment.
"""
false_positives = [
    """
    AWS administrators or automated processes might regularly assume roles for legitimate administrative purposes.
    Applications integrated with AWS might assume roles to access AWS resources. Automated workflows might assume roles
    to perform periodic tasks such as data backups, updates, or deployments.
    """,
]
from = "now-6m"
index = ["filebeat-*", "logs-aws.cloudtrail-*"]
language = "kuery"
license = "Elastic License v2"
name = "AWS STS Role Assumption by User"
note = """## Triage and analysis

### Investigating AWS STS Role Assumption by User

This rule detects when a user assumes a role in AWS Security Token Service (STS), receiving temporary credentials to access AWS resources. While often used for legitimate purposes, this action can be leveraged by adversaries to obtain unauthorized access, escalate privileges, or move laterally within an AWS environment.

### Possible investigation steps

- **Identify the User and Assumed Role**:
  - **User Identity**: Check `aws.cloudtrail.user_identity.arn` for details about the initiator of the `AssumeRole` action.
  - **Role Assumed**: Review `aws.cloudtrail.resources.arn` to confirm the role assumed and ensure it aligns with the user’s standard permissions.
  - **Session Name**: Note `aws.cloudtrail.flattened.request_parameters.roleSessionName` for context on the purpose of the session.
  - **Expiration Time**: Use `aws.cloudtrail.flattened.response_elements.credentials.expiration` to confirm the credential expiration.

- **Inspect User Agent and Source Information**:
  - **User Agent**: Analyze the `user_agent.original` field to identify if specific tooling or SDKs like AWS CLI, Boto3, or custom agents were used.
  - **Source IP and Geolocation**: Examine `source.ip` and `source.geo` fields to determine the origin of the request, confirming if it aligns with expected locations.

- **Correlate with Related Events**:
  - **Identify Patterns**: Review related CloudTrail events for unusual access patterns, such as resource access or sensitive actions following this `AssumeRole` action.
  - **Filter High-Volume Roles**: If this role or user has a high volume of access, evaluate `roleArn` or `user_agent` values for common patterns and add trusted entities as exceptions.

- **Review the Privileges of the Assumed Role**:
  - **Permissions**: Examine permissions associated with the `roleArn` to assess its access scope.
  - **Authorized Usage**: Confirm if the role is used frequently for administrative purposes and if this aligns with the user’s regular responsibilities.

### False positive analysis

- **Automated Processes and Applications**: Applications or scheduled tasks may assume roles regularly for operational purposes. Validate the consistency of the `user_agent` or `roleArn` with known automated workflows.
- **Standard IAM Policy Usage**: Confirm if the user or application routinely assumes new roles for normal operations by reviewing historical activity.

### Response and remediation

- **Terminate Unauthorized Sessions**: If the role assumption is deemed unauthorized, revoke the session by modifying IAM policies or the permissions associated with the assumed role.
- **Strengthen Monitoring and Alerts**: Implement additional monitoring for specific high-risk roles, especially those with elevated permissions.
- **Regularly Manage Exceptions**: Regularly review high-volume roles and user agent patterns to refine alerts, minimizing noise by adding trusted patterns as exceptions.
- **Incident Response**: If confirmed as malicious, follow incident response protocols for containment, investigation, and remediation.

### Additional information

For more details on managing and securing AWS STS in your environment, refer to the [AWS STS documentation](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html).
"""
references = ["https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html"]
risk_score = 21
rule_id = "288a198e-9b9b-11ef-a0a8-f661ea17fbcd"
severity = "low"
tags = [
    "Domain: Cloud",
    "Data Source: AWS",
    "Data Source: Amazon Web Services",
    "Data Source: AWS STS",
    "Resources: Investigation Guide",
    "Use Case: Identity and Access Audit",
    "Tactic: Privilege Escalation",
    "Tactic: Lateral Movement",
]
timestamp_override = "event.ingested"
type = "new_terms"

query = '''
data_stream.dataset: "aws.cloudtrail"
    and event.provider: "sts.amazonaws.com"
    and event.action: "AssumeRole"
    and event.outcome: "success"
    and aws.cloudtrail.user_identity.type: "IAMUser"
'''


[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1078"
name = "Valid Accounts"
reference = "https://attack.mitre.org/techniques/T1078/"

[[rule.threat.technique.subtechnique]]
id = "T1078.004"
name = "Cloud Accounts"
reference = "https://attack.mitre.org/techniques/T1078/004/"

[[rule.threat.technique]]
id = "T1548"
name = "Abuse Elevation Control Mechanism"
reference = "https://attack.mitre.org/techniques/T1548/"

[rule.threat.tactic]
id = "TA0004"
name = "Privilege Escalation"
reference = "https://attack.mitre.org/tactics/TA0004/"

[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1550"
name = "Use Alternate Authentication Material"
reference = "https://attack.mitre.org/techniques/T1550/"

[[rule.threat.technique.subtechnique]]
id = "T1550.001"
name = "Application Access Token"
reference = "https://attack.mitre.org/techniques/T1550/001/"

[rule.threat.tactic]
id = "TA0008"
name = "Lateral Movement"
reference = "https://attack.mitre.org/tactics/TA0008/"

[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1078"
name = "Valid Accounts"
reference = "https://attack.mitre.org/techniques/T1078/"

[[rule.threat.technique.subtechnique]]
id = "T1078.004"
name = "Cloud Accounts"
reference = "https://attack.mitre.org/techniques/T1078/004/"

[rule.threat.tactic]
id = "TA0005"
name = "Defense Evasion"
reference = "https://attack.mitre.org/tactics/TA0005/"
[rule.investigation_fields]
field_names = [
    "@timestamp",
    "user.name",
    "user_agent.original",
    "source.ip",
    "aws.cloudtrail.user_identity.arn",
    "aws.cloudtrail.user_identity.type",
    "aws.cloudtrail.user_identity.access_key_id",
    "event.action",
    "event.outcome",
    "aws.cloudtrail.resources.arn",
    "aws.cloudtrail.resources.type",
    "aws.cloudtrail.flattened.request_parameters.roleSessionName",
    "aws.cloudtrail.flattened.response_elements.credentials.accessKeyId",
    "cloud.region",
    "cloud.account.id",
    "aws.cloudtrail.request_parameters",
    "aws.cloudtrail.response_elements",
]

[rule.new_terms]
field = "new_terms_fields"
value = ["aws.cloudtrail.user_identity.arn", "aws.cloudtrail.resources.arn"]
[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-5d"

[metadata]
creation_date = "2026/07/09"
integration = ["azure"]
maturity = "production"
updated_date = "2026/07/09"

[rule]
author = ["Elastic"]
description = """
Detects an identity creating a client-authentication CertificateSigningRequest (signer
kubernetes.io/kube-apiserver-client) or approving a CSR on AKS (Azure Kubernetes Service), excluding node bootstrap and
platform controllers. Adversaries submit and self-approve a CSR against the kube-apiserver-client signer to mint a
long-lived client certificate for an arbitrary subject (for example a Common Name in system:masters), giving durable
authenticated access that survives token revocation. Coverage includes workload service accounts
(system:serviceaccount:*), so a compromised in-cluster token forging a certificate is not excluded.
"""
false_positives = [
    """
    Node bootstrap, cert-manager, and platform controllers legitimately create and approve CSRs. Validate the requesting
    identity and the certificate subject, and add exclusions for verified automation.
    """,
]
from = "now-9m"
index = ["logs-azure.platformlogs-*"]
language = "kuery"
license = "Elastic License v2"
name = "Azure AKS Certificate Signing Request Created or Approved"
note = """## Triage and analysis

### Investigating Azure AKS Certificate Signing Request Created or Approved

AKS kube-audit events are carried under the flattened `azure.platformlogs.properties.log.*` subtree and share the ARM
operation `event.action: Microsoft.ContainerService/managedClusters/diagnosticLogs/Read`. A CSR created against the
`kubernetes.io/kube-apiserver-client` signer lets the requester choose the certificate's subject (Common Name and
organization/groups); once approved it mints a client certificate for an arbitrary identity that yields access not tied
to a token. The default `CertificateSubjectRestriction` admission controller blocks requests for the `system:masters`
group, so attackers commonly request a Common Name matching an existing privileged user (or another privileged group)
instead, making the requested subject the key thing to decode. Node and kubelet certificates use the
`kube-apiserver-client-kubelet` and `kubelet-serving` signers (whose subject is constrained to the node) and are out of
scope; cert-manager and application CSRs use their own signers.

### Possible investigation steps

- Identify the requesting identity in `azure.platformlogs.properties.log.user.username` (and its groups in
  `azure.platformlogs.properties.log.user.groups`) and whether it should submit or approve CSRs. A workload service
  account (`system:serviceaccount:<ns>:<sa>`) or `masterclient` (the local cluster-admin cert) is the higher-concern
  case.
- Confirm the signer in `azure.platformlogs.properties.log.requestObject.spec.signerName` and decode the base64 CSR in
  `azure.platformlogs.properties.log.requestObject.spec.request` to read the requested Common Name and organization
  (groups); a subject in `system:masters` or another privileged group is the escalation.
- Determine whether the same or a related identity approved the CSR (`verb:update`/`patch` on the `approval`
  subresource), which indicates self-approval, and inspect `azure.platformlogs.properties.log.userAgent`.
- Evaluate the source in `azure.platformlogs.properties.log.sourceIPs` and pivot on it for follow-on privileged API
  activity using the newly issued certificate.

### False positive analysis

- Node bootstrap (`kube-apiserver-client-kubelet` signer), kubelet-serving CSRs, and cert-manager/application CSRs
  (custom signers) are out of scope by design; the kube-controller-manager `certificate-controller` and the AKS
  `aksService` approver are excluded by identity.
- Manual CSR approval by an administrator, or an operator that legitimately mints client certificates, may surface;
  baseline those identities and exclude the specific validated account rather than re-broadening to all `system:*`,
  which would blind the rule to compromised workload service accounts.

### Response and remediation

- If unauthorized, deny or delete the CSR, revoke the issued certificate, and rotate the cluster CA if a privileged
  certificate was minted.
- Review the RBAC that allowed CSR creation and approval, and audit actions taken with the certificate.
- Collect kube-audit and identity artifacts per incident response procedures.
"""
references = [
    "https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/",
    "https://microsoft.github.io/Threat-Matrix-for-Kubernetes/",
    "https://github.com/inguardians/peirates",
    "https://raesene.github.io/blog/2022/12/21/Kubernetes-persistence-with-Tocan-and-Teisteanas/",
    "https://cloud.google.com/blog/topics/threat-intelligence/escalating-privileges-azure-kubernetes-services",
    "https://www.aquasec.com/blog/kubernetes-rbac-privilige-escalation/",
]
risk_score = 47
rule_id = "3f6c636a-1ca5-410c-bdad-f8b59a1f2b49"
setup = """The Azure Fleet integration collecting AKS diagnostic logs forwarded through Event Hub into the `azure.platformlogs`
data stream is required for this rule. Enable either the `kube-audit` or the `kube-audit-admin` log category (Microsoft
recommends `kube-audit-admin` alone to reduce volume, as it only drops read-only get/list events). CSR create and
approval are mutating operations recorded in both categories with the same `auditID`, so clusters that enable both
categories may generate two alerts per event.
"""
severity = "medium"
tags = [
    "Domain: Cloud",
    "Domain: Kubernetes",
    "Data Source: Azure",
    "Data Source: Azure Platform Logs",
    "Data Source: Kubernetes",
    "Use Case: Threat Detection",
    "Tactic: Credential Access",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:azure.platformlogs and
  event.action:"Microsoft.ContainerService/managedClusters/diagnosticLogs/Read" and
  azure.platformlogs.category:("kube-audit" or "kube-audit-admin") and
  azure.platformlogs.properties.log.stage:"ResponseComplete" and
  azure.platformlogs.properties.log.objectRef.resource:"certificatesigningrequests" and
  azure.platformlogs.properties.log.responseStatus.code: "200" and
  azure.platformlogs.properties.log.requestObject.status.conditions.type: "Approved" and
  (
    (
      azure.platformlogs.properties.log.verb:"create" and
      azure.platformlogs.properties.log.requestObject.spec.signerName:"kubernetes.io/kube-apiserver-client"
    ) or (
      azure.platformlogs.properties.log.verb:("update" or "patch") and
      azure.platformlogs.properties.log.objectRef.subresource:"approval"
    )
  ) and
  not azure.platformlogs.properties.log.user.username:(
    system\:node\:* or system\:bootstrap\:* or "aksService" or "hcpService" or
    "readinessChecker" or system\:serviceaccount\:kube-system\:*
  )
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1649"
name = "Steal or Forge Authentication Certificates"
reference = "https://attack.mitre.org/techniques/T1649/"


[rule.threat.tactic]
id = "TA0006"
name = "Credential Access"
reference = "https://attack.mitre.org/tactics/TA0006/"

[rule.investigation_fields]
field_names = [
    "@timestamp",
    "event.action",
    "azure.platformlogs.category",
    "azure.platformlogs.properties.log.verb",
    "azure.platformlogs.properties.log.user.username",
    "azure.platformlogs.properties.log.user.groups",
    "azure.platformlogs.properties.log.userAgent",
    "azure.platformlogs.properties.log.sourceIPs",
    "azure.platformlogs.properties.log.objectRef.resource",
    "azure.platformlogs.properties.log.objectRef.name",
    "azure.platformlogs.properties.log.objectRef.subresource",
    "azure.platformlogs.properties.log.requestObject.spec.signerName",
    "azure.platformlogs.properties.log.requestObject.spec.request",
    "azure.platformlogs.properties.log.responseStatus.code",
]

[metadata]
bypass_bbr_timing = true
creation_date = "2025/10/13"
integration = ["azure"]
maturity = "production"
updated_date = "2025/10/13"

[rule]
author = ["Elastic"]
building_block_type = "default"
description = """
Identifies the deletion of Azure Recovery Services resources. Azure Recovery Services vaults contain data for copies of
VMs, workloads, servers, and other resources regarding Infrastructure as a Service (IaaS). Adversaries may delete these
recovery services to impact backup capabilities during stable operations or to inhibit disaster recovery services during
ransom-based attacks or operational disruptions.
"""
from = "now-9m"
index = ["logs-azure.activitylogs-*", "filebeat-*"]
language = "kuery"
license = "Elastic License v2"
name = "Azure Recovery Services Resource Deleted"
references = [
    "https://www.microsoft.com/en-us/security/blog/2023/07/25/storm-0501-ransomware-attacks-expanding-to-hybrid-cloud-environments/",
]
risk_score = 47
rule_id = "b8c3e5d0-8a1a-11ef-9b4a-f661ea17fbce"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Domain: Storage",
    "Data Source: Azure",
    "Data Source: Azure Activity Logs",
    "Use Case: Threat Detection",
    "Tactic: Impact",
    "Resources: Investigation Guide",
    "Rule Type: BBR",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
event.dataset:azure.activitylogs and
    azure.activitylogs.operation_name:MICROSOFT.RECOVERYSERVICES/*/DELETE and
    event.outcome:(Success or success)
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1490"
name = "Inhibit System Recovery"
reference = "https://attack.mitre.org/techniques/T1490/"


[rule.threat.tactic]
id = "TA0040"
name = "Impact"
reference = "https://attack.mitre.org/tactics/TA0040/"

[metadata]
creation_date = "2026/06/15"
integration = ["azure"]
maturity = "production"
updated_date = "2026/06/15"

[rule]
author = ["Elastic"]
description = """
Identifies retrieval of Azure VM boot diagnostics data
("MICROSOFT.COMPUTE/VIRTUALMACHINES/RETRIEVEBOOTDIAGNOSTICSDATA/ACTION") by an identity that has not performed this
operation recently. Boot diagnostics expose the VM serial console log and a console screenshot, which frequently contain
plaintext boot-time output such as credentials, tokens, cloud-init/agent secrets, and command history. An adversary with
VM read/contributor rights can retrieve this data over the control plane, without logging into the guest or touching the
network, to harvest credentials.
"""
false_positives = [
    """
    Support engineers, infrastructure-as-code, and VM health automation may legitimately retrieve boot diagnostics
    during troubleshooting. The first occurrence per principal will alert; baseline expected support users, service
    principals, and managed identities and exclude them if the activity is verified as authorized.
    """,
]
from = "now-9m"
index = ["logs-azure.activitylogs-*"]
language = "kuery"
license = "Elastic License v2"
name = "Azure VM Boot Diagnostics Retrieved"
note = """## Triage and analysis

### Investigating Azure VM Boot Diagnostics Retrieved

Retrieving boot diagnostics (`retrieveBootDiagnosticsData/action`) returns SAS URIs to the VM serial console log and a
console screenshot. The serial log often contains plaintext boot output: cloud-init/agent activity, command history, and
sometimes credentials or tokens. The action is a control-plane read requiring only VM read/contributor rights, leaves no
guest footprint, and bypasses NSG/JIT.

### Triage checklist

- Identify the acting principal via `azure.activitylogs.identity.authorization.evidence.principal_id` and
  `...principal_type` (User vs ServicePrincipal) and `azure.activitylogs.identity.claims.appid`. Service principal or
  managed identity retrieval is more suspicious than a known support user.
- Review the source: `source.ip`, `source.as.number`, `source.as.organization.name`, `source.geo.country_name`.
  Retrieval from cloud hosting, VPS, or anonymizing networks is more suspicious than known corporate egress.
- Inspect `azure.resource.id` / `azure.resource.name` to identify the target VM. Was the same principal recently granted
  access to it, or is this their first interaction?
- Did the same principal recently perform reconnaissance, role assignments, Run Command, or extension operations on the
  VM or subscription?

### Possible investigation steps

- Review the principal's Entra ID sign-in logs and RBAC role assignments on the subscription, resource group, and VM.
- Retrieve the boot diagnostics serial log and screenshot from the VM and assess whether they exposed credentials or
  other secrets that now require rotation.
- Pivot on the VM and any credentials observed in the serial log for follow-on access, lateral movement, or persistence.

### Response and remediation

- If unauthorized, rotate any credentials/tokens exposed in the serial log, review RBAC on the affected scope, and revoke
  the principal's access if compromised.
- Collect activity log artifacts per incident procedures.
"""
references = [
    "https://blog.pwnedlabs.io/diving-deep-into-azure-vm-attack-vectors",
    "https://www.microsoft.com/en-us/msrc/blog/2023/08/azure-serial-console-attack-and-defense-part-1",
    "https://learn.microsoft.com/en-us/azure/virtual-machines/boot-diagnostics",
    "https://www.netspi.com/blog/technical-blog/adversary-simulation/7-ways-to-execute-command-on-azure-virtual-machine-virtual-machine-scale-sets/",
]
risk_score = 47
rule_id = "e7509f8f-e70b-4b67-b864-aaa4254b4484"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Domain: Endpoint",
    "Data Source: Azure",
    "Data Source: Azure Activity Logs",
    "Use Case: Threat Detection",
    "Tactic: Credential Access",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:azure.activitylogs and
    event.action:"MICROSOFT.COMPUTE/VIRTUALMACHINES/RETRIEVEBOOTDIAGNOSTICSDATA/ACTION" and
    event.outcome:(success or Success)
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1552"
name = "Unsecured Credentials"
reference = "https://attack.mitre.org/techniques/T1552/"


[rule.threat.tactic]
id = "TA0006"
name = "Credential Access"
reference = "https://attack.mitre.org/tactics/TA0006/"

[rule.investigation_fields]
field_names = [
    "@timestamp",
    "event.outcome",
    "azure.activitylogs.operation_name",
    "azure.activitylogs.identity.authorization.evidence.principal_id",
    "azure.activitylogs.identity.authorization.evidence.principal_type",
    "azure.activitylogs.identity.claims.appid",
    "azure.resource.name",
    "azure.resource.id",
    "source.ip",
    "source.as.number",
    "source.as.organization.name",
    "source.geo.country_name",
    "azure.subscription_id",
    "azure.activitylogs.tenant_id",
]

[metadata]
creation_date = "2025/03/12"
integration = ["endpoint"]
maturity = "production"
updated_date = "2026/03/24"

[rule]
author = ["Elastic"]
description = """
This rule detects when a container management binary is run from inside a container. These binaries are critical
components of many containerized environments, and their presence and execution in unauthorized containers could
indicate compromise or a misconfiguration.
"""
false_positives = [
    """
    There is a potential for false positives if the container is used for legitimate administrative tasks that require
    the use of container management utilities, such as deploying, scaling, or updating containerized applications. It is
    important to investigate any alerts generated by this rule to determine if they are indicative of malicious activity
    or part of legitimate container activity.
    """,
]
from = "now-9m"
index = ["logs-endpoint.events.process*"]
language = "eql"
license = "Elastic License v2"
name = "Container Management Utility Run Inside A Container"
note = """## Triage and analysis

> **Disclaimer**:
> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.

### Investigating Container Management Utility Run Inside A Container

Container management utilities like Docker and Kubectl are essential for orchestrating and managing containerized applications. They facilitate tasks such as deployment, scaling, and networking. However, adversaries can exploit these tools to execute unauthorized commands within containers, potentially leading to system compromise. The detection rule identifies suspicious execution of these utilities within containers, signaling possible misuse or misconfiguration, by monitoring specific process activities and event types.

### Possible investigation steps

- Examine the process name and command line arguments to understand the context of the execution and identify any anomalies or unauthorized commands.
- Check the user and permissions associated with the process to assess if it aligns with expected roles and access levels for container management tasks.
- Investigate the container's creation and deployment history to identify any recent changes or deployments that could explain the presence of the management utility.
- Analyze network activity associated with the container to detect any unusual connections or data transfers that might indicate malicious activity.
- Correlate the event with other security alerts or logs to identify patterns or related incidents that could provide additional context or evidence of compromise.

### False positive analysis

- Routine maintenance tasks within containers can trigger the rule. Exclude known maintenance scripts or processes by adding them to an allowlist if they frequently execute container management utilities.
- Development and testing environments often run container management commands for legitimate purposes. Consider excluding these environments from monitoring or adjust the rule to focus on production environments only.
- Automated deployment tools may execute container management commands as part of their workflow. Identify these tools and create exceptions for their activities to prevent false positives.
- System updates or patches might involve running container management utilities. Monitor update schedules and temporarily adjust the rule to avoid unnecessary alerts during these periods.
- Legitimate administrative actions by authorized personnel can trigger the rule. Implement user-based exceptions for known administrators to reduce false positives while maintaining security oversight.

### Response and remediation

- Immediately isolate the affected container to prevent further unauthorized access or execution of commands. This can be done by stopping the container or disconnecting it from the network.
- Review the container's configuration and access controls to identify any misconfigurations or unauthorized access permissions that may have allowed the execution of container management utilities.
- Conduct a thorough analysis of the container's logs and process activities to determine the extent of the compromise and identify any additional malicious activities or lateral movement attempts.
- Remove any unauthorized or suspicious binaries and scripts from the container to prevent further exploitation.
- Patch and update the container image and underlying host system to address any known vulnerabilities that may have been exploited.
- Implement stricter access controls and monitoring on container management utilities to ensure they are only accessible by authorized users and processes.
- Escalate the incident to the security operations team for further investigation and to assess the need for broader security measures across the container environment."""

risk_score = 21
rule_id = "4b74d3b0-416e-4099-b432-677e1cd098cc"
setup = """## Setup

This rule requires data coming in from Elastic Defend.

### Elastic Defend Integration Setup
Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.

#### Prerequisite Requirements:
- Fleet is required for Elastic Defend.
- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).

#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
- Go to the Kibana home page and click "Add integrations".
- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
- Click "Add Elastic Defend".
- Configure the integration name and optionally add a description.
- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).
- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead.

For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
- Click "Save and Continue".
- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts.
For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
"""
severity = "low"
tags = [
    "Domain: Container",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Execution",
    "Data Source: Elastic Defend",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and
process.entry_leader.entry_meta.type == "container" and process.interactive == true and
process.name in ("dockerd", "kubelet", "kube-proxy", "kubectl", "containerd", "systemd", "crictl") and
not (
  process.parent.executable in ("/sbin/init", "/usr/bin/dockerd", "/usr/bin/runc", "/usr/bin/containerd-shim-runc-v2") or
  process.working_directory == "/aws" or
  process.parent.command_line == "runc init" or
  (process.parent.name == "busybox" and process.name == "kubectl")
)
'''

[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1609"
name = "Container Administration Command"
reference = "https://attack.mitre.org/techniques/T1609/"

[rule.threat.tactic]
id = "TA0002"
name = "Execution"
reference = "https://attack.mitre.org/tactics/TA0002/"

[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1613"
name = "Container and Resource Discovery"
reference = "https://attack.mitre.org/techniques/T1613/"

[rule.threat.tactic]
id = "TA0007"
name = "Discovery"
reference = "https://attack.mitre.org/tactics/TA0007/"

[rule]
description = """
Identifies when a Microsoft Office process creates an executable file (DLL) and the file is subsequently loaded by a
trusted binary. An adversary may deliver a weaponized Office document to their target that writes and loads malicious
modules.
"""
id = "68218637-3940-42cb-b2b7-0610fc1dde56"
license = "Elastic License v2"
name = "DLL Side Loading of a file dropped by Microsoft Office"
os_list = ["windows"]
version = "1.0.21"

query = '''
sequence with maxspan=5m
  [ file where event.action != "deletion" and
      process.name :
          ("WINWORD.EXE",
           "EXCEL.EXE",
           "POWERPNT.EXE",
           "MSACCESS.EXE",
           "MSPUB.EXE") and
      (
        file.extension : ("dll", "cpl", "ocx") or
        // Match Windows PE files by header data (MZ)
        file.Ext.header_bytes : "4d5a*"
      ) ] by file.path
  [ library where
   (dll.code_signature.exists == false or
   (dll.code_signature.trusted == false and not dll.code_signature.status : ("trusted", "errorExpired", "errorCode_endpoint*"))) and
    process.code_signature.trusted == true and
    not process.name : ("WINWORD.EXE", "EXCEL.EXE", "POWERPNT.EXE", "MSACCESS.EXE", "ONENOTE.EXE") and
    not startswith~(dll.name, process.name) and
    not dll.hash.sha256 in ("ac0b2e4ea19c34536a58e6818fe0d37599495a6b3da7e8d3a3444ea0eff9d6e6", "d85639d208dc27961832b15eb42f9861faffca18e0ded8d5697c9bf13b7b598c") and
    not dll.path : "?:\\Windows\\assembly\\NativeImages_*" and
    not (process.executable : "?:\\Windows\\System32\\spoolsv.exe" and user.id : "S-1-5-18") and
    not process.executable : ("?:\\Windows\\SysWOW64\\msiexec.exe", "?:\\Windows\\system32\\msiexec.exe")
    ] by dll.path
'''

min_endpoint_version = "8.4.0"
[[actions]]
action = "kill_process"
field = "process.entity_id"
state = 0

[[actions]]
action = "kill_process"
field = "process.entity_id"
state = 1

[[optional_actions]]
action = "rollback"
field = "process.entity_id"
state = 1

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1566"
name = "Phishing"
reference = "https://attack.mitre.org/techniques/T1566/"
[[threat.technique.subtechnique]]
id = "T1566.001"
name = "Spearphishing Attachment"
reference = "https://attack.mitre.org/techniques/T1566/001/"



[threat.tactic]
id = "TA0001"
name = "Initial Access"
reference = "https://attack.mitre.org/tactics/TA0001/"
[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1574"
name = "Hijack Execution Flow"
reference = "https://attack.mitre.org/techniques/T1574/"
[[threat.technique.subtechnique]]
id = "T1574.001"
name = "DLL"
reference = "https://attack.mitre.org/techniques/T1574/001/"



[threat.tactic]
id = "TA0005"
name = "Defense Evasion"
reference = "https://attack.mitre.org/tactics/TA0005/"

[internal]
min_endpoint_version = "8.4.0"

[rule]
description = """
Identifies DNS queries to known DNS over HTTPS (DoH) Providers by an unusual Microsoft signed binary or files from
suspicious paths. This may indicate abuse of DoH for Command and Control communications.
"""
id = "9371a660-2ee8-4840-820d-8a9754308d53"
license = "Elastic License v2"
name = "DNS Over HTTPS by an Unusual Process"
os_list = ["windows"]
reference = ["https://www.blackhillsinfosec.com/dns-over-https-for-cobalt-strike/"]
version = "1.0.4"

query = '''
sequence by process.entity_id with maxspan=1m
  [process where event.action == "start" and user.id like ("S-1-5-21*", "S-1-12-*") and
   (
    (process.executable : "C:\\Windows\\*.exe" and
     process.code_signature.subject_name in ("Microsoft Windows Publisher", "Microsoft Corporation", "Microsoft Windows") and
     not process.executable : ("C:\\Windows\\Sys?????\\ipconfig.exe",
                               "C:\\Windows\\Sys?????\\nslookup.exe",
                               "C:\\Windows\\Sys?????\\TRACERT.EXE",
                               "C:\\Windows\\Sys?????\\PING.EXE",
                               "C:\\Windows\\System32\\Microsoft-Edge-WebView\\msedgewebview2.exe")) or

     (process.Ext.relative_file_creation_time <= 900 and process.code_signature.status in ("errorBadDigest", "errorUntrustedRoot")) or

     (process.Ext.relative_file_creation_time <= 900 and process.executable : ("C:\\ProgramData\\*", "C:\\Users\\Public\\*", "C:\\Users\\*\\Downloads\\*"))
   )
   ]
  [dns where dns.question.name : ("cloudflare-dns.com", "mozilla.cloudflare-dns.com", "dns.google", "dns.quad9.net", "doh.opendns.com", "ordns.he.net") and
   not (dns.question.name : "dns.google" and
        process.executable : ("C:\\Program Files\\WindowsApps\\Enflick.TextNow-UnlimitedTextCalls_*\\app\\TextNow.exe",
                              "C:\\Program Files (x86)\\Steam\\steamapps\\common\\assettocorsa\\cache\\cef\\Assetto Corsa CEF.exe"))]
'''

min_endpoint_version = "8.4.0"
optional_actions = []
[[actions]]
action = "kill_process"
field = "process.entity_id"
state = 0

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1071"
name = "Application Layer Protocol"
reference = "https://attack.mitre.org/techniques/T1071/"
[[threat.technique.subtechnique]]
id = "T1071.004"
name = "DNS"
reference = "https://attack.mitre.org/techniques/T1071/004/"



[threat.tactic]
id = "TA0011"
name = "Command and Control"
reference = "https://attack.mitre.org/tactics/TA0011/"

[internal]
min_endpoint_version = "8.4.0"

[rule]
description = """
Identifies network connections to commonly abused Top Level Domains followed by the immdiate creation of a Python, Shell
Script, Applescript, or Binary. This may indicate an attempt to establish initial access or command and control by a
malicious payload.
"""
id = "9a3acafe-2ecd-487f-8c1f-1697fe9d33c7"
license = "Elastic License v2"
name = "File Download from Suspicious Top Level Domain"
os_list = ["macos"]
version = "1.0.12"

query = '''
sequence by process.entity_id with maxspan=30s
[network where event.type == "start" and
  destination.domain like~ ("*.team", "*.team.", "*.lol", "*.lol.", "*.app", "*.app.", "*.kr", "*.kr.", "*.ke", "*.ke.", "*.nu", "*.nu.", "*.space", "*.space.", "*.capital", "*.capital.", "*.in", "*.in.", "*.cfd", "*.cfd.", "*.online", "*.online.", 
                            "*.info", "*.info.", "*.top", "*.top.", "*.buzz", "*.buzz.", "*.xyz", "*.xyz.", "*.rest", "*.rest.", "*.ml", "*.ml.", "*.cf", "*.cf.", "*.gq", "*.gq.", "*.ga", "*.ga.", "*.onion", "*.onion.",
                            "*.network", "*.network.", "*.monster", "*.monster.", "*.marketing", "*.marketing.", "*.cyou", "*.cyou.", "*.quest", "*.quest.", "*.cc", "*.cc.", "*.bar", "*.bar.", "*.click", "*.click.", "*.cam", "*.cam.",
                            "*.surf", "*.surf.", "*.tk", "*.tk.", "*.shop", "*.shop.", "*.club", "*.club.", "*.icu", "*.icu.", "*.pw", "*.pw.", "*.ws", "*.ws.", "*.rest", "*.rest.", "*.hair", "*.hair.",
                            "*.mom", "*.mom.", "*.beauty", "*.beauty.", "*.boats", "*.boats.", "*.online", "*.online.", "*.fun", "*.fun.", "*.life", "*.life.", "*.store", "*.store.")]
[file where event.action == "modification" and file.extension in ("py", "sh", "scpt", "pyc") and file.path like ("/Users/Shared/*", "/tmp/*", "/private/tmp/*", "/private/var/tmp/*", "/var/tmp/*", "/private/var/root/*", "/var/root/*") and
  not file.path like~ "/private/var/folders/*" and
  not file.extension in ("so", "dylib")]
'''

min_endpoint_version = "8.16.0"
optional_actions = []
[[actions]]
action = "kill_process"
field = "process.entity_id"
state = 0

[[threat]]
framework = "MITRE ATT&CK"

[threat.tactic]
id = "TA0002"
name = "Execution"
reference = "https://attack.mitre.org/tactics/TA0002/"
[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1071"
name = "Application Layer Protocol"
reference = "https://attack.mitre.org/techniques/T1071/"
[[threat.technique.subtechnique]]
id = "T1071.001"
name = "Web Protocols"
reference = "https://attack.mitre.org/techniques/T1071/001/"



[threat.tactic]
id = "TA0011"
name = "Command and Control"
reference = "https://attack.mitre.org/tactics/TA0011/"

[internal]
min_endpoint_version = "8.16.0"

[metadata]
bypass_bbr_timing = true
creation_date = "2023/10/11"
integration = ["github"]
maturity = "production"
updated_date = "2025/12/24"

[rule]
author = ["Elastic"]
building_block_type = "default"
description = "Detects a new user agent used for a GitHub user not previously seen in the last 14 days.\n"
from = "now-9m"
index = ["logs-github.audit-*"]
language = "kuery"
license = "Elastic License v2"
name = "First Occurrence of User-Agent For a GitHub User"
risk_score = 21
rule_id = "41761cd3-380f-4d4d-89f3-46d6853ee35d"
severity = "low"
tags = [
    "Domain: Cloud",
    "Use Case: Threat Detection",
    "Use Case: UEBA",
    "Tactic: Initial Access",
    "Rule Type: BBR",
    "Data Source: Github",
]
timestamp_override = "event.ingested"
type = "new_terms"

query = '''
event.dataset:"github.audit" and event.category:"configuration" and
github.user_agent:* and user.name:*
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1078"
name = "Valid Accounts"
reference = "https://attack.mitre.org/techniques/T1078/"
[[rule.threat.technique.subtechnique]]
id = "T1078.004"
name = "Cloud Accounts"
reference = "https://attack.mitre.org/techniques/T1078/004/"



[rule.threat.tactic]
id = "TA0001"
name = "Initial Access"
reference = "https://attack.mitre.org/tactics/TA0001/"

[rule.new_terms]
field = "new_terms_fields"
value = ["user.name", "github.user_agent"]
[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-5d"

[metadata]
creation_date = "2026/05/14"
integration = ["google_workspace"]
maturity = "production"
updated_date = "2026/05/14"

[rule]
author = ["Elastic"]
building_block_type = "default"
description = """
Surfaces Google Workspace sign-in events that Google's identity risk engine has flagged as suspicious via the
`is_suspicious` field on the `login` activity record. This is Google's own ML-driven sign-in risk signal. The field is
set by Google server-side based on signals like sign-ins from anonymizer infrastructure, known-malicious IP ranges,
atypical user characteristics, or anomalous device fingerprints. Use this signal as enrichment alongside the other
Workspace sign-in rules rather than as a standalone alert. This rule is a building block. It does not generate
user-facing alerts by default but populates `signal.rule.building_block_type` for correlation rules or analyst pivots.
"""
false_positives = [
    """
    Google's risk engine occasionally flags legitimate sign-ins as suspicious when the user is on a new device, on a VPN
    egress that geo-resolves to a different region, or after extended time away. Validate by checking the user's recent
    sign-in history and confirming with the user.
    """,
]
from = "now-180m"
index = ["filebeat-*", "logs-google_workspace.login*"]
interval = "60m"
language = "kuery"
license = "Elastic License v2"
name = "Google Workspace Login Flagged Suspicious"
note = """## Triage and analysis

### Investigating Google Workspace Login Flagged Suspicious

Google sets `google_workspace.login.is_suspicious: true` when its server-side risk engine identifies a sign-in event as anomalous for the user. Triggers commonly include:

- Sign-in from an anonymizer (Tor exit, public VPN, etc.)
- Sign-in from a known-malicious IP range
- Atypical device fingerprint for the user
- Sign-in from a geography or ASN inconsistent with the user's history

As a building block, this signal is intended for use alongside other detection rules. On its own it is medium-confidence.

### Possible investigation steps

- Inspect `source.ip`, `source.as.organization.name`, `source.geo.country_name`. Classify the network: residential ISP, corporate VPN, hosting provider (high concern), anonymizer (high concern).
- Inspect `google_workspace.login.type`. `google_password` is an interactive sign-in (highest concern). `reauth` is a silent token refresh (lower concern unless paired with other signals).
- Inspect `google_workspace.login.challenge_method`. Whether 2FA was relayed or skipped factors into the kit-vs-traveler determination.
- Pull the user's recent sign-in history. Is this a one-off flag or a sustained pattern from a new network?
- Cross-reference `logs-google_workspace.token` for `event.action: "authorize"` events from the same `user.email` immediately following the suspicious sign-in. An OAuth grant minted seconds after a Google-flagged sign-in is the AiTM kit signature.
- Cross-reference `logs-google_workspace.device` for `DEVICE_REGISTER_UNREGISTER_EVENT` with `account_state: "REGISTERED"` near the same time. New device registration paired with `is_suspicious` is high-fidelity compromise.
- Confirm with the user whether the sign-in was theirs.

### False positive analysis

- Travelers, VPN users, new-device sign-ins, and users returning from leave will all trip Google's risk engine occasionally.
- Building-block signals are not tuned for false-positive minimization at the source; they trade noise for coverage. Combine with other signals before treating as actionable.

### Response and remediation

- This rule does not generate user-facing alerts by default. Use it as enrichment for higher-level correlation rules.
- If a correlation surfaces this signal alongside other indicators (atypical ASN, atypical country, OAuth grant, device registration), follow the response steps in those rules.
"""
references = [
    "https://knowledge.workspace.google.com/admin/security/user-login-attempts-report",
    "https://www.elastic.co/security-labs/google-workspace-attack-surface-part-one",
]
risk_score = 21
rule_id = "93d2c5bf-dac1-4e0f-ab52-16f440782bb8"
setup = """## Setup

### Important Information Regarding Google Workspace Event Lag Times
- Google Workspace Reports API ingestion lag commonly runs in the 30-minute to 3-hour range. This rule's 130-minute lookback gives partial coverage but will miss events delayed beyond that envelope.
- See https://support.google.com/a/answer/7061566 for Google's published guidance on event availability.
- Check your integration's Login lag time to ensure it is configured to meet the needs of this rule.
"""
severity = "low"
tags = [
    "Domain: Cloud",
    "Domain: Identity",
    "Data Source: Google Workspace",
    "Data Source: Google Workspace Audit Logs",
    "Data Source: Google Workspace User Log Events",
    "Use Case: Threat Detection",
    "Use Case: Identity and Access Audit",
    "Tactic: Initial Access",
    "Tactic: Credential Access",
    "Rule Type: BBR",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset: "google_workspace.login" and
    event.provider: "login" and
    google_workspace.login.is_suspicious: true
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1078"
name = "Valid Accounts"
reference = "https://attack.mitre.org/techniques/T1078/"
[[rule.threat.technique.subtechnique]]
id = "T1078.004"
name = "Cloud Accounts"
reference = "https://attack.mitre.org/techniques/T1078/004/"



[rule.threat.tactic]
id = "TA0001"
name = "Initial Access"
reference = "https://attack.mitre.org/tactics/TA0001/"
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1528"
name = "Steal Application Access Token"
reference = "https://attack.mitre.org/techniques/T1528/"

[[rule.threat.technique]]
id = "T1557"
name = "Adversary-in-the-Middle"
reference = "https://attack.mitre.org/techniques/T1557/"


[rule.threat.tactic]
id = "TA0006"
name = "Credential Access"
reference = "https://attack.mitre.org/tactics/TA0006/"

[rule.investigation_fields]
field_names = [
    "@timestamp",
    "user.email",
    "user.name",
    "source.ip",
    "source.as.number",
    "source.as.organization.name",
    "source.geo.country_name",
    "google_workspace.login.type",
    "google_workspace.login.challenge_method",
    "google_workspace.login.is_suspicious",
]

[metadata]
creation_date = "2020/08/14"
integration = ["endpoint"]
maturity = "production"
updated_date = "2026/03/24"

[rule]
author = ["Elastic"]
description = """
Identifies the use of the Kerberos credential cache (kcc) utility to dump locally cached Kerberos tickets. Adversaries
may attempt to dump credential material in the form of tickets that can be leveraged for lateral movement.
"""
from = "now-9m"
index = ["logs-endpoint.events.*"]
language = "eql"
license = "Elastic License v2"
name = "Kerberos Cached Credentials Dumping"
references = [
    "https://github.com/EmpireProject/EmPyre/blob/master/lib/modules/collection/osx/kerberosdump.py",
    "https://opensource.apple.com/source/Heimdal/Heimdal-323.12/kuser/kcc-commands.in.auto.html",
]
risk_score = 73
rule_id = "ad88231f-e2ab-491c-8fc6-64746da26cfe"
setup = """## Setup

This rule requires data coming in from Elastic Defend.

### Elastic Defend Integration Setup
Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.

#### Prerequisite Requirements:
- Fleet is required for Elastic Defend.
- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).

#### The following steps should be executed in order to add the Elastic Defend integration on a macOS System:
- Go to the Kibana home page and click "Add integrations".
- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
- Click "Add Elastic Defend".
- Configure the integration name and optionally add a description.
- Select the type of environment you want to protect, for MacOS it is recommended to select "Traditional Endpoints".
- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).
- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead.
For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/current/agent-policy.html).
- Click "Save and Continue".
- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts.
For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
"""
severity = "high"
tags = [
    "Domain: Endpoint",
    "OS: macOS",
    "Use Case: Threat Detection",
    "Tactic: Credential Access",
    "Data Source: Elastic Defend",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
process where host.os.type == "macos" and event.type in ("start", "process_started") and
  process.name == "kcc" and
  process.args like~ "copy_cred_cache"
'''
note = """## Triage and analysis

> **Disclaimer**:
> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.

### Investigating Kerberos Cached Credentials Dumping

Kerberos is a network authentication protocol designed to provide secure identity verification for users and services. It uses tickets to allow nodes to prove their identity in a secure manner. Adversaries may exploit tools like the Kerberos credential cache utility to extract these tickets, enabling unauthorized access and lateral movement within a network. The detection rule identifies suspicious activity by monitoring for specific processes and arguments on macOS systems, flagging potential credential dumping attempts.

### Possible investigation steps

- Review the alert details to confirm the presence of the process name 'kcc' and the argument 'copy_cred_cache' in the process execution logs on macOS systems.
- Identify the user account associated with the process execution to determine if the activity aligns with expected behavior or if it indicates potential unauthorized access.
- Examine the timeline of the process execution to identify any preceding or subsequent suspicious activities, such as unusual login attempts or lateral movement within the network.
- Check for any other alerts or logs related to the same host or user account to assess if this is part of a broader attack pattern.
- Investigate the source and destination of any network connections made by the process to identify potential data exfiltration or communication with known malicious IP addresses.
- Consult with the user or system owner to verify if the use of the 'kcc' utility was legitimate or if it requires further investigation.

### False positive analysis

- Routine administrative tasks using the kcc utility may trigger the rule. Identify and document these tasks to create exceptions for known benign activities.
- Automated scripts or maintenance processes that involve copying Kerberos credential caches can be mistaken for malicious activity. Review and whitelist these scripts if they are verified as safe.
- Developers or IT personnel testing Kerberos configurations might use the kcc utility in a non-malicious context. Establish a process to log and approve such activities to prevent false alarms.
- Security tools or monitoring solutions that interact with Kerberos tickets for legitimate purposes may inadvertently trigger the rule. Coordinate with security teams to ensure these tools are recognized and excluded from detection.

### Response and remediation

- Immediately isolate the affected macOS system from the network to prevent further unauthorized access or lateral movement.
- Terminate the suspicious process identified as 'kcc' with the argument 'copy_cred_cache' to stop any ongoing credential dumping activity.
- Conduct a thorough review of the system's Kerberos ticket cache to identify any unauthorized access or anomalies, and invalidate any compromised tickets.
- Reset passwords and regenerate Kerberos tickets for any accounts that may have been affected to prevent further unauthorized access.
- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the scope of the breach.
- Implement additional monitoring on the affected system and similar endpoints to detect any recurrence of the credential dumping activity.
- Review and update access controls and Kerberos configurations to enhance security and reduce the risk of similar attacks in the future."""


[[rule.threat]]
framework = "MITRE ATT&CK"

[[rule.threat.technique]]
id = "T1003"
name = "OS Credential Dumping"
reference = "https://attack.mitre.org/techniques/T1003/"

[[rule.threat.technique]]
id = "T1558"
name = "Steal or Forge Kerberos Tickets"
reference = "https://attack.mitre.org/techniques/T1558/"

[[rule.threat.technique.subtechnique]]
id = "T1558.003"
name = "Kerberoasting"
reference = "https://attack.mitre.org/techniques/T1558/003/"

[[rule.threat.technique.subtechnique]]
id = "T1558.005"
name = "Ccache Files"
reference = "https://attack.mitre.org/techniques/T1558/005/"

[rule.threat.tactic]
id = "TA0006"
name = "Credential Access"
reference = "https://attack.mitre.org/tactics/TA0006/"

[rule]
description = """
Identifies attempts to install an application-defined hook procedure to monitor keystroke messages. Adversaries may log
user keystrokes to intercept credentials or other information from the user as the user types them.
"""
id = "7ae180e1-e08f-40c2-82db-f274f688eea2"
license = "Elastic License v2"
name = "Keystroke Messages Hooking via SetWindowsHookEx"
os_list = ["windows"]
reference = [
    "https://attack.mitre.org/techniques/T1056/001/",
    "https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setwindowshookexa",
    "https://www.elastic.co/security-labs/protecting-your-devices-from-information-theft-keylogger-protection",
]
version = "1.0.19"

query = '''
api where process.Ext.api.name == "SetWindowsHookEx" and process.Ext.api.parameters.hook_type == "WH_KEYBOARD_LL" and
 process.Ext.api.parameters.hook_module == "null" and
 process.thread.Ext.call_stack_final_user_module.hash.sha256 != null and not process.code_signature.status : "trusted" and
 process.thread.Ext.call_stack_summary : "?*" and process.executable != null and
 not process.thread.Ext.call_stack_summary :
                               ("*user32.dll|explorer.exe|user32.dll*",
                                "*user32.dll|tabskb.dll|kernel32.dll*",
                                "*user32.dll|taskbar.dll*",
                                "win32u.dll|user32.dll|pilotshubapp.dll",
                                "*win32u.dll|user32.dll|mtb.exe|mfc90u.dll|mtb.exe*",
                                "win32u.dll|user32.dll|powertoy*",
                                "win32u.dll|user32.dll|rdclientax.dl*",
                                "*qt6gui.dll|qt6core.dll*",
                                "win32u.dll|user32.dll|rwsfoundation_x64.dll|ucrtbase.dll|kernel32.dll|ntdll.dll",
                                "win32u.dll|user32.dll|autohotkey*.exe|kernel32.dll|ntdll.dll") and
 not process.thread.Ext.call_stack_final_user_module.hash.sha256 in
                        ("1683394a15b58815a01bbe030dfc1e441a9b0f7f38d18bd5c13d41d573d58f53",
                         "bec3b34c8e9c04a1da28c623fb06cee45739113a38a1eae52d2a3b208c4baa6f",
                         "0d083e72eb0e8cbcec2c347840bff815513eecf29648065163b08c600f6c95ff",
                         "38011e713b4be8577576062754cad03e9899859488932ae4c9c83e5fbb5cb7d2",
                         "b67e006287fba2278f897d242ff58548b7d6b15ac490a91c26318c6f396da195",
                         "feaf9479260db6f41d1e6443d0d80826eeee4905ef97a1cab78c16bc304248a5",
                         "465d3985e1dd8bc69137e2a8c5a4a6ba16b0ff99c647245ca66942750ccc75ef",
                         "549888a9e268dd5ca6544cabc8266148ff0d8728c3aa0f1c68f9f8bcb116e53d") and
 not process.thread.Ext.call_stack_final_user_module.path :
                        ("?:\\Program Files\\*",
                         "?:\\Program Files (x86)\\*",
                         "?:\\windows\\system32\\*",
                         "?:\\windows\\syswow64\\*",
                         "\\Program Files\\*",
                         "\\Program Files (x86)\\*",
                         "\\windows\\system32\\*",
                         "\\windows\\syswow64\\*",
                         "?:\\windows\\explorer.exe",
                         "\\windows\\explorer.exe",
                         "*\\windows\\systemapps\\*",
                         "c:\\windows\\microsoft.net\\framework*\\clr.dll",
                         "*\\windows\\assembly\\*",
                         "?:\\windows\\systemapps\\*.dll",
                         "?:\\Windows\\WinSxS\\*.dll",
                         "?:\\windows\\assembly\\*.dll",
                         "\\windows\\systemapps\\*.dll",
                         "\\Windows\\WinSxS\\*.dll",
                         "\\windows\\assembly\\*.dll",
                         "\\windows\\shellexperiences\\*.dll",
                         "?:\\progra~?\\citrix\\icacli~?\\vdkbhook.dll",
                         "?:\\windows\\shellexperiences\\*.dll",
                         "\\windows\\shellexperiences\\*.dll",
                         "?:\\windows\\jmesoft\\keyhook.dll",
                         "?:\\users\\*\\appdata\\local\\microsoft\\teams\\current\\d3dcompiler_??.dll",
                         "\\device\\mup\\*",
                         "?:\\windows\\immersivecontrolpanel\\systemsettings.dll") and
    not process.thread.Ext.call_stack_final_user_module.name : ("Unknown", "Undetermined") and
    not process.thread.Ext.call_stack_final_user_module.protection_provenance : ("hmpalert.dll", "kernel") and
    not process.executable :
                ("?:\\Program Files\\workspacer\\workspacer.exe",
                 "?:\\Program Files (x86)\\Do It Again\\DoItAgain.exe",
                 "?:\\Program Files (x86)\\HP\\HP LaserJet Pro MFP *\\bin\\HPScan.exe",
                 "?:\\Program Files (x86)\\Avaya\\Avaya IX Workplace\\fTarget\\Avaya.BrowserExtension.exe") and
    not _arraysearch(process.thread.Ext.call_stack_final_user_module.code_signature, $entry, $entry.status : "trusted")
'''

min_endpoint_version = "8.12.0"
reputation = true
[[actions]]
action = "kill_process"
field = "process.entity_id"
state = 0

[[optional_actions]]
action = "rollback"
field = "process.entity_id"
state = 0

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1056"
name = "Input Capture"
reference = "https://attack.mitre.org/techniques/T1056/"
[[threat.technique.subtechnique]]
id = "T1056.001"
name = "Keylogging"
reference = "https://attack.mitre.org/techniques/T1056/001/"



[threat.tactic]
id = "TA0009"
name = "Collection"
reference = "https://attack.mitre.org/tactics/TA0009/"

[internal]
min_endpoint_version = "8.12.0"

[metadata]
creation_date = "2026/05/15"
integration = ["azure"]
maturity = "production"
min_stack_version = "9.4.0"
min_stack_comments = "ES|QL FIRST and LAST aggregation functions are GA in 9.4."
updated_date = "2026/05/15"

[rule]
author = ["Elastic"]
description = """
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.
"""
false_positives = [
    """
    Users on VPN or proxy egress that geo-resolves through a region distant from the user's physical location. Mobile
    clients on cellular carrier networks that peer through regional hubs may geo-resolve to a different region than the
    user's physical location. Corporate AWS Workspaces / VDI deployments where employees interactively sign in from a
    cloud-provider ASN.
    """,
]
from = "now-90m"
interval = "30m"
language = "esql"
license = "Elastic License v2"
name = "Microsoft Entra ID Impossible Travel Sign-in"
note = """## Triage and analysis

### Investigating Microsoft Entra ID Impossible Travel Sign-in

Microsoft Entra ID is accessible globally; legitimate users authenticate from one location at a time. Two successful interactive sign-ins for the same user separated by a distance and time delta implying travel faster than a commercial airliner cannot be the same human physically moving, and indicate either a VPN/proxy egress mismatch or a compromised account being accessed from a separate location by an adversary.

This rule scopes to `SignInLogs` (interactive sign-ins) only; non-interactive token refresh activity is excluded because backend service calls routinely egress through cloud regions unrelated to the user.

### Possible investigation steps

- Identify the user (`azure.signinlogs.properties.user_principal_name`) and the geographic separation observed: `Esql.distance_km`, `Esql.travel_kmh`, `Esql.window_minutes` (bbox path over region centroids), and the set of distinct countries, regions, and cities (`Esql.source_geo_country_name_values`, `Esql.source_geo_region_name_values`, `Esql.source_geo_city_name_values`).
- Cross-check `Esql.honest_distance_km`, `Esql.honest_travel_kmh`, `Esql.honest_window_minutes` -- these measure the real great-circle distance between the user's actual first and last sign-in events with timestamps locked to those same events. When the honest distance is small but the bbox distance is large, the user appeared in an outlier region in the middle of the window (A->B->A pattern -- typical AiTM kit replay). When both agree, it's a clean two-region case.
- Pull all `azure.signinlogs` events with `azure.signinlogs.category: SignInLogs` for the user across the alert window. Sort by `@timestamp` and inspect each `source.ip`, `source.as.organization.name`, `source.geo.country_name`, `user_agent.original`, `azure.signinlogs.properties.device_detail.browser`, and `azure.signinlogs.properties.device_detail.operating_system`.
- Determine which sign-ins are consistent with the user's baseline (corporate VPN egress, home ISP, mobile carrier) and which are not. Pay close attention to UA / browser / OS divergence between the two geographic clusters — adversary sessions almost always show a distinct fingerprint from the legitimate user's.
- For each non-baseline sign-in: check the ASN. Hosting-provider ASNs (Clouvider, Host Telecom, Alibaba, cheap-VPS providers, and AWS/Azure/GCP rented compute) for interactive sign-ins are high-fidelity suspicious because legitimate end users do not typically egress through those networks.
- Inspect `Esql.app_id_values`, `Esql.app_display_name_values`, `Esql.resource_id_values`, and `Esql.resource_display_name_values` for the apps and resources touched from each geo. Microsoft Graph, Azure PowerShell, or Azure Resource Manager access from a non-baseline geo immediately after a baseline sign-in is the post-auth recon signature.
- Cross-reference Entra audit logs (`logs-azure.auditlogs-*`) for `add service principal`, `consent to application`, OAuth consent grants, MFA method registration, or recovery email/phone changes for the same user near the same window. Adversaries routinely add persistence immediately after authentication.
- Confirm with the user whether the sign-ins are theirs (VPN, travel) or unexpected.

### False positive analysis

- Users on VPN or proxy infrastructure egressing through a distant region: validate against the user's known VPN ranges and consider excluding by ASN at the rule-exception layer (not in the base query).
- Mobile carriers that geo-resolve outside the user's home country (cellular providers often peer through regional hubs): validate by user-agent (mobile UA fingerprint) and source ASN (carrier networks).
- AWS Workspaces / VDI / corporate-cloud deployments where employees interactively sign in from a cloud ASN: validate the AS organization name and the tenant's cloud footprint, then except the specific ASN per-tenant rather than blanket-excluding cloud ASNs (which would also suppress adversary sign-ins from rented compute).

### Response and remediation

- If the pattern is unexpected, immediately revoke all refresh tokens for the user (`Revoke-AzureADUserAllRefreshToken` or `Revoke-MgUserSignInSession`) and force re-authentication, then reset the password and clear any recovery methods.
- Investigate any OAuth consent grants minted to the user around the same window — these survive password resets if not explicitly revoked.
- Review Entra audit logs for any newly registered authentication methods (FIDO key, authenticator app, phone number) added near the same window: these are adversary persistence vectors.
- Review device registration events (`Add registered owner to device`, `Add registered users to device`) — adversary device joins establish persistence that survives password rotation if the underlying refresh tokens were not revoked.
- Cross-check Azure activity logs (`logs-azure.activitylogs-*`) for any resource changes by the user from a non-baseline `source.ip` in the same window.
"""
references = ["https://any.run/malware-trends/tycoon/"]
risk_score = 73
rule_id = "bc9f5144-0ead-476e-ba6e-cef295601195"
severity = "high"
tags = [
    "Domain: Cloud",
    "Domain: Identity",
    "Data Source: Azure",
    "Data Source: Microsoft Entra ID",
    "Data Source: Microsoft Entra ID Sign-in Logs",
    "Use Case: Threat Detection",
    "Use Case: Identity and Access Audit",
    "Tactic: Initial Access",
    "Tactic: Credential Access",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "esql"

query = '''
// successful interactive sign-ins with country + region populated.
from logs-azure.signinlogs-*
| where data_stream.dataset == "azure.signinlogs"
    and event.outcome == "success"
    and azure.signinlogs.category == "SignInLogs"
    and azure.signinlogs.properties.user_principal_name is not null
    and source.geo.location is not null
    and source.geo.region_name is not null

| eval Esql.source_geo_lat = st_y(source.geo.location),
       Esql.source_geo_lon = st_x(source.geo.location)

// collapse each (user, country, region) into one centroid + the actual lat/lon
// of the first and last event in that region. FIRST/LAST lock coords to the
// timestamp ordering so we can later build the honest event pair.
| stats
    Esql.region_centroid_lat = avg(Esql.source_geo_lat),
    Esql.region_centroid_lon = avg(Esql.source_geo_lon),
    Esql.region_first_lat    = first(Esql.source_geo_lat, @timestamp),
    Esql.region_first_lon    = first(Esql.source_geo_lon, @timestamp),
    Esql.region_last_lat     = last(Esql.source_geo_lat,  @timestamp),
    Esql.region_last_lon     = last(Esql.source_geo_lon,  @timestamp),
    Esql.region_first_seen   = min(@timestamp),
    Esql.region_last_seen    = max(@timestamp),
    Esql.region_event_count  = count(*),
    Esql.region_city_values   = values(source.geo.city_name),
    Esql.region_asn_values    = values(source.`as`.organization.name),
    Esql.region_ip_values     = values(source.ip),
    Esql.region_ua_values     = values(user_agent.original),
    Esql.region_app_id_values = values(azure.signinlogs.properties.app_id),
    Esql.region_app_display_name_values = values(azure.signinlogs.properties.app_display_name),
    Esql.region_client_app_used_values  = values(azure.signinlogs.properties.client_app_used),
    Esql.region_resource_id_values      = values(azure.signinlogs.properties.resource_id),
    Esql.region_resource_display_name_values = values(azure.signinlogs.properties.resource_display_name),
    Esql.region_browser_values = values(azure.signinlogs.properties.device_detail.browser),
    Esql.region_os_values      = values(azure.signinlogs.properties.device_detail.operating_system)
  by azure.signinlogs.properties.user_principal_name,
     source.geo.country_name,
     source.geo.region_name

// roll up to the user. two parallel measurements:
// bbox: corners over region centroids. catches A->B->A because B is still
// a centroid in the set even when first/last events are in A.
| stats
    Esql.min_lat = min(Esql.region_centroid_lat),
    Esql.max_lat = max(Esql.region_centroid_lat),
    Esql.min_lon = min(Esql.region_centroid_lon),
    Esql.max_lon = max(Esql.region_centroid_lon),
    Esql.honest_first_lat = first(Esql.region_first_lat, Esql.region_first_seen),
    Esql.honest_first_lon = first(Esql.region_first_lon, Esql.region_first_seen),
    Esql.honest_last_lat  = last(Esql.region_last_lat,   Esql.region_last_seen),
    Esql.honest_last_lon  = last(Esql.region_last_lon,   Esql.region_last_seen),
    Esql.timestamp_first_seen = min(Esql.region_first_seen),
    Esql.timestamp_last_seen  = max(Esql.region_first_seen), // first arrival in last region > tighter bbox window
    Esql.honest_last_time     = max(Esql.region_last_seen),  // user's actual last event > honest window
    Esql.region_count  = count_distinct(source.geo.region_name),
    Esql.country_count = count_distinct(source.geo.country_name),
    Esql.event_count   = sum(Esql.region_event_count),
    Esql.source_geo_country_name_values     = values(source.geo.country_name),
    Esql.source_geo_region_name_values      = values(source.geo.region_name),
    Esql.source_geo_city_name_values        = values(Esql.region_city_values),
    Esql.source_as_organization_name_values = values(Esql.region_asn_values),
    Esql.source_ip_values                   = values(Esql.region_ip_values),
    Esql.user_agent_original_values         = values(Esql.region_ua_values),
    Esql.app_id_values                      = values(Esql.region_app_id_values),
    Esql.app_display_name_values            = values(Esql.region_app_display_name_values),
    Esql.client_app_used_values             = values(Esql.region_client_app_used_values),
    Esql.resource_id_values                 = values(Esql.region_resource_id_values),
    Esql.resource_display_name_values       = values(Esql.region_resource_display_name_values),
    Esql.device_detail_browser_values       = values(Esql.region_browser_values),
    Esql.device_detail_operating_system_values = values(Esql.region_os_values)
  by azure.signinlogs.properties.user_principal_name

// need at least 2 regions to have anything to compare. cap at 5 because regions
// are finer-grained than countries (a traveling employee can hit 3-4 in 90m via
// carrier hub bouncing) > bbox drift stays bounded below this.
| where Esql.region_count >= 2 and Esql.region_count <= 5

// bbox path (primary trigger): corners over region centroids.
| eval Esql.p1 = to_geopoint(concat("POINT(", to_string(Esql.min_lon), " ", to_string(Esql.min_lat), ")")),
       Esql.p2 = to_geopoint(concat("POINT(", to_string(Esql.max_lon), " ", to_string(Esql.max_lat), ")"))
| eval Esql.distance_km    = round(st_distance(Esql.p1, Esql.p2) / 1000.0, 0),
       Esql.window_minutes = date_diff("minute", Esql.timestamp_first_seen, Esql.timestamp_last_seen),
       Esql.travel_kmh     = case(Esql.window_minutes > 0,
                                  round(Esql.distance_km * 60.0 / Esql.window_minutes, 0), null)

// honest pair (triage signal): real coords at the user's actual first and last
// events, time locked to those same two events
| eval Esql.honest_p1 = to_geopoint(concat("POINT(", to_string(Esql.honest_first_lon), " ", to_string(Esql.honest_first_lat), ")")),
       Esql.honest_p2 = to_geopoint(concat("POINT(", to_string(Esql.honest_last_lon),  " ", to_string(Esql.honest_last_lat),  ")"))
| eval Esql.honest_distance_km     = round(st_distance(Esql.honest_p1, Esql.honest_p2) / 1000.0, 0),
       Esql.honest_window_minutes  = date_diff("minute", Esql.timestamp_first_seen, Esql.honest_last_time),
       Esql.honest_travel_kmh      = case(Esql.honest_window_minutes > 0,
                                          round(Esql.honest_distance_km * 60.0 / Esql.honest_window_minutes, 0), null)

// 500 km separation + faster than a commercial airliner. bbox is the trigger
// purely as triage signal.
| where Esql.distance_km >= 500 and Esql.travel_kmh >= 800

| keep azure.signinlogs.properties.user_principal_name,
    Esql.source_geo_country_name_values,
    Esql.source_geo_region_name_values,
    Esql.source_geo_city_name_values,
    Esql.source_as_organization_name_values,
    Esql.source_ip_values,
    Esql.user_agent_original_values,
    Esql.app_id_values,
    Esql.app_display_name_values,
    Esql.client_app_used_values,
    Esql.resource_id_values,
    Esql.resource_display_name_values,
    Esql.device_detail_browser_values,
    Esql.device_detail_operating_system_values,
    Esql.country_count,
    Esql.region_count,
    Esql.event_count,
    Esql.timestamp_first_seen,
    Esql.timestamp_last_seen,
    Esql.window_minutes,
    Esql.distance_km,
    Esql.travel_kmh,
    Esql.honest_distance_km,
    Esql.honest_travel_kmh,
    Esql.honest_window_minutes
'''

[rule.alert_suppression]
group_by = ["azure.signinlogs.properties.user_principal_name"]
duration = {value = 30, unit = "m"}
missing_fields_strategy = "suppress"

[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1078"
name = "Valid Accounts"
reference = "https://attack.mitre.org/techniques/T1078/"
[[rule.threat.technique.subtechnique]]
id = "T1078.004"
name = "Cloud Accounts"
reference = "https://attack.mitre.org/techniques/T1078/004/"



[rule.threat.tactic]
id = "TA0001"
name = "Initial Access"
reference = "https://attack.mitre.org/tactics/TA0001/"
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1528"
name = "Steal Application Access Token"
reference = "https://attack.mitre.org/techniques/T1528/"

[[rule.threat.technique]]
id = "T1557"
name = "Adversary-in-the-Middle"
reference = "https://attack.mitre.org/techniques/T1557/"


[rule.threat.tactic]
id = "TA0006"
name = "Credential Access"
reference = "https://attack.mitre.org/tactics/TA0006/"

[rule.investigation_fields]
field_names = ["azure.signinlogs.properties.user_principal_name"]