Elastic rules: 16

[rule]
description = """
Identifies API calls from memory regions unexpectedly marked as inaccessible. This may indicate an attempt to hide
injected code from memory scanners.
"""
id = "2f4afc62-e9df-4654-b0c1-67ce380a1131"
license = "Elastic License v2"
name = "API Call from Inaccessible Memory Page"
os_list = ["windows"]
version = "1.0.3"

query = '''
api where
 process.Ext.api.name in ("VirtualProtect", "VirtualAlloc", "SetThreadContext", "MapViewOfFile", "MapViewOfFile2") and
 (process.thread.Ext.call_stack_final_user_module.name == "Unbacked" or
  process.thread.Ext.call_stack_final_user_module.allocation_private_bytes >= 100000) and
 _arraysearch(process.thread.Ext.call_stack, $entry,
              $entry.symbol_info == "Unbacked" and $entry.callsite_trailing_bytes like ("NOACCESS*", "GUARD*"))
'''

min_endpoint_version = "8.18.0"
optional_actions = []
[[actions]]
action = "kill_process"
field = "process.entity_id"
state = 0
tree = true

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1564"
name = "Hide Artifacts"
reference = "https://attack.mitre.org/techniques/T1564/"

[[threat.technique]]
id = "T1620"
name = "Reflective Code Loading"
reference = "https://attack.mitre.org/techniques/T1620/"


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

[internal]
min_endpoint_version = "8.18.0"

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

[rule]
author = ["Elastic"]
description = """
An adversary with access to a set of compromised credentials may attempt to persist or escalate privileges by attaching
additional permissions to user groups the compromised user account belongs to. This rule looks for use of the IAM
AttachGroupPolicy API operation to attach the highly permissive AdministratorAccess AWS managed policy to an existing
IAM user group.
"""
false_positives = [
    """
    While this can be normal behavior, it should be investigated to ensure validity. Verify whether the user identity
    should be using the IAM `AttachGroupPolicy` API operation to attach the `AdministratorAccess` policy to the user
    group.
    """,
]
from = "now-6m"
index = ["filebeat-*", "logs-aws.cloudtrail-*"]
language = "eql"
license = "Elastic License v2"
name = "AWS IAM AdministratorAccess Policy Attached to Group"
note = """## Triage and analysis

### Investigating AWS IAM AdministratorAccess Policy Attached to Group

The AWS-managed `AdministratorAccess` policy grants full administrative privileges across all AWS services.  
When attached to a group, all group members inherit this access, often unintentionally broadening the blast radius of a compromise.  
Adversaries can exploit `iam:AttachGroupPolicy` permissions to escalate privileges or establish persistence by attaching this policy to an existing user group.

#### Possible investigation steps

- **Identify the affected group and calling principal.**  
  Review `aws.cloudtrail.user_identity.arn` (caller) and `aws.cloudtrail.request_parameters.groupName` (target group).  
  Validate whether this aligns with legitimate change management or automation workflows.  

- **Review group membership.**  
  Enumerate current members using `aws iam get-group`.  
  Determine whether unauthorized users could have gained administrative access as a result.  

- **Inspect CloudTrail details.**  
  Check `source.ip`, `user_agent.original`, and `source.geo` fields for anomalies.  
  Compare with historical operations by the same principal.  

- **Correlate related IAM activity.**  
  Search for adjacent events such as `AddUserToGroup`, `CreateUser`, or `AttachUserPolicy`.  
  These may indicate chained privilege escalation.  

- **Assess propagation of privileges.**  
  If the group has many members or is linked to cross-account roles, the impact may extend beyond a single user.  
  Document all affected identities for containment.  

### False positive analysis

- **Intentional access updates.**  
  Policy attachment may occur during legitimate administrative provisioning. Confirm via ticketing systems.  
- **Automation or compliance tasks.**  
  Some environments use centralized scripts to attach AdministratorAccess temporarily. Validate through automation logs.  

### Response and remediation

**Immediate containment**
- Detach the policy from the affected group (`aws iam detach-group-policy`).  
- Review and limit group membership. Temporarily remove non-essential users or disable access for impacted accounts.  
- Rotate credentials for users who inherited admin privileges from the attachment.  
- Enable MFA on all impacted accounts.  

**Evidence preservation**
- Export the triggering `AttachGroupPolicy` event and related CloudTrail entries ±30 minutes from the alert.  
- Preserve AWS Config and GuardDuty records to support forensic analysis.  

**Scoping and investigation**
- Review additional IAM operations from the same caller (`CreateAccessKey`, `AttachRolePolicy`, `UpdateAssumeRolePolicy`).  
- Identify whether new groups or roles were created shortly before or after the event.  
- Check for subsequent API activity by newly privileged users (for example, S3, EC2, or IAM modifications).  

**Recovery and hardening**
- Reinforce least privilege, avoid assigning `AdministratorAccess` to groups.  
- Use role-based access control with scoped permissions.   
- Enable CloudTrail, GuardDuty, and Security Hub across all regions.  
- Implement SCPs at the organization level to restrict direct `AdministratorAccess` attachments.  

### Additional information
- **[AWS IR Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/blob/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks/): response steps related to IAM policy modification and unauthorized privilege escalation..  
- **[AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework/): for containment, analysis, and recovery guidance.
- **AWS Documentation:** [AdministratorAccess Policy](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html#jf_administrator).
"""
references = [
    "https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachGroupPolicy.html",
    "https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AdministratorAccess.html",
    "https://hackingthe.cloud/aws/exploitation/iam_privilege_escalation/",
]
risk_score = 47
rule_id = "df919b5e-a0f6-4fd8-8598-e3ce79299e3b"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Data Source: AWS",
    "Data Source: Amazon Web Services",
    "Data Source: AWS IAM",
    "Use Case: Identity and Access Audit",
    "Tactic: Privilege Escalation",
    "Tactic: Persistence",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
iam where data_stream.dataset == "aws.cloudtrail"
   and event.provider == "iam.amazonaws.com"
   and event.action == "AttachGroupPolicy"
   and event.outcome == "success"
   and stringContains(aws.cloudtrail.request_parameters, "policyArn=arn:aws:iam::aws:policy/AdministratorAccess")
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1098"
name = "Account Manipulation"
reference = "https://attack.mitre.org/techniques/T1098/"
[[rule.threat.technique.subtechnique]]
id = "T1098.003"
name = "Additional Cloud Roles"
reference = "https://attack.mitre.org/techniques/T1098/003/"



[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 = "T1098"
name = "Account Manipulation"
reference = "https://attack.mitre.org/techniques/T1098/"
[[rule.threat.technique.subtechnique]]
id = "T1098.003"
name = "Additional Cloud Roles"
reference = "https://attack.mitre.org/techniques/T1098/003/"



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

[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",
    "group.name",
    "event.outcome",
    "cloud.account.id",
    "cloud.region",
    "aws.cloudtrail.request_parameters",
]

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

[rule]
author = ["Elastic"]
description = """
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.
"""
false_positives = [
    """
    Global employees on VPNs, split DNS or proxy paths that change AS labels, regional carrier rebrands, or mobile
    hotspots can produce a small non-cloud AS share on the same IAM user as hyperscaler- or SaaS-classified traffic.
    Corporate travel, emergency break-glass from a home ISP, and multi-region runners may also widen AS diversity without
    malice. Tune thresholds, add account or principal allowlists, or narrow the sensitive-action list after baseline review.
    """,
]
from = "now-7d"
interval = "1h"
language = "esql"
license = "Elastic License v2"
name = "AWS Rare Source AS Organization Activity"
note = """## Triage and analysis

### Investigating AWS Rare Source AS Organization Activity After High Cloud-Provider Volume

The rule aggregates roughly seven days of successful CloudTrail per `user.name` and `aws.cloudtrail.user_identity.type`.
It expects a **high count** of events whose GeoIP AS organization matches a short allowlist of large cloud/SaaS providers,
**at least one** event from a different AS organization, a **low ratio** of uncommon-network events to all events, few
**distinct** uncommon AS labels, and **recent** uncommon-network timestamps. It further requires at least one
**sensitive** API from an uncommon network (see query `event.action` list).

#### Possible investigation steps

- Compare `Esql.src_asn_values` to `Esql.user_agent_values` and map each `source.ip` (from raw CloudTrail) to expected
  admin paths, pipelines, or offices.
- Pivot on `user.name` and `aws.cloudtrail.user_identity.access_key_id` (from underlying events) for IAM, STS, S3, and
  Secrets Manager activity around `Esql.most_recent_low_asn_day`.
- Confirm whether the identity is meant for automation only; if so, rare human ISP ASNs warrant higher scrutiny.
- Review `Esql.untrusted_suspicious_actions` for the mix of discovery versus privilege-changing APIs.

### False positive analysis

- **Threshold sensitivity**: Raise `Esql.trusted_cloud_event_count` or Lower `Esql.rare_asn_ratio` and `Esql.untrusted_event_count` if legitimate rare-ASN
  noise persists.
- **MongoDB / other allowlist labels**: Extend `is_trusted_cloud` if your approved automation consistently appears under
  another legal-entity string.

### Response and remediation

- If abuse is plausible: rotate credentials for the principal, enforce OIDC or short-lived keys for automation, and
  tighten IAM and data-plane permissions.

### Additional information

- [CloudTrail user identity](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-user-identity.html)
"""
references = [
    "https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference.html",
]
risk_score = 73
rule_id = "d1b37c0b-4f8b-4cfb-9a1d-639bf8c028b7"
severity = "high"
tags = [
    "Domain: Cloud",
    "Data Source: AWS",
    "Data Source: Amazon Web Services",
    "Data Source: AWS CloudTrail",
    "Use Case: Threat Detection",
    "Tactic: Initial Access",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "esql"

query = '''
FROM logs-aws.cloudtrail-*
| WHERE event.dataset == "aws.cloudtrail"
  AND event.outcome == "success"
  AND source.as.organization.name IS NOT NULL
  AND user.name IS NOT NULL

| EVAL is_trusted_cloud = CASE(
    source.as.organization.name LIKE "Amazon*" OR
    source.as.organization.name == "Google LLC" OR
    source.as.organization.name == "Microsoft Corporation" OR
	source.as.organization.name == "MongoDB, Inc.",
    true, false
  )

| EVAL is_suspicious_action = CASE(
    event.action IN (
      "GetCallerIdentity", "GetAccountSummary", "ListAccountAliases",
      "GetSecretValue", "ListSecrets", "DescribeSecret",
      "GetParameter", "GetParameters", "GetParametersByPath",
      "AssumeRole", "AssumeRoleWithWebIdentity", "AssumeRoleWithSAML",
      "AttachUserPolicy", "AttachRolePolicy",
      "PutUserPolicy", "PutRolePolicy",
      "CreateAccessKey", "UpdateAccessKey",
      "CreateUser", "CreateLoginProfile",
      "UpdateLoginProfile", "AddUserToGroup",
      "GetObject", "ListBuckets", "ListObjects", "ListObjectsV2",
      "InvokeModel", "InvokeModelWithResponseStream", "Converse"
    ), true, false
  )

// Single aggregation — full event count preserved for ratio logic
// suspicious action tracking is additive on top
| STATS
    Esql.total_events_all_asns = COUNT(*),
    Esql.count_distinct_asns = COUNT_DISTINCT(source.as.organization.name),
    Esql.src_asn_values = VALUES(source.as.organization.name),
	Esql.user_agent_values = VALUES(user_agent.original),
	Esql.related_users = VALUES(user.changes.name),
	Esql.source_ip_values = VALUES(source.address),
    Esql.has_trusted_cloud_asn = MAX(is_trusted_cloud),
    Esql.trusted_cloud_event_count = SUM(CASE(is_trusted_cloud == true, 1, 0)),
    Esql.untrusted_event_count = SUM(CASE(is_trusted_cloud == false, 1, 0)),
    // Suspicious action visibility from untrusted ASNs — informational only, not a filter
    Esql.untrusted_suspicious_count  = SUM(CASE(
        is_trusted_cloud == false AND is_suspicious_action == true, 1, 0
      )),
    Esql.untrusted_suspicious_actions = VALUES(CASE(
        is_trusted_cloud == false AND is_suspicious_action == true,
        event.action, null
      )),
    Esql.most_recent_low_asn_day   = MAX(CASE(
        is_trusted_cloud == false, @timestamp, null
      ))
    BY user.name, aws.cloudtrail.user_identity.type

| EVAL Esql.rare_asn_ratio = TO_DOUBLE(Esql.untrusted_event_count) / TO_DOUBLE(Esql.total_events_all_asns), 
       Esql.unique_action_from_untrusted_asn = MV_COUNT(Esql.untrusted_suspicious_actions)

// Detection thresholds — unchanged, full event counts drive the logic
| WHERE Esql.has_trusted_cloud_asn == true
  AND Esql.untrusted_event_count >= 1
  AND Esql.trusted_cloud_event_count >= 100
  AND Esql.rare_asn_ratio <= 0.01
  AND Esql.unique_action_from_untrusted_asn >= 2 
  AND Esql.count_distinct_asns <= 5
  AND Esql.most_recent_low_asn_day >= NOW() - 1 hour

| KEEP user.name,
       aws.cloudtrail.user_identity.type,
       Esql.*
'''

[rule.investigation_fields]
field_names = [
    "user.name",
    "aws.cloudtrail.user_identity.type",
    "Esql.*"
]



[[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/"

[metadata]
creation_date = "2024/11/24"
integration = ["aws"]
maturity = "production"
updated_date = "2026/07/08"

[rule]
author = ["Elastic"]
description = """
Identifies when the STS AssumeRoot action is performed by a rare user in AWS. The AssumeRoot action allows users to
assume the root member account role, granting elevated but specific permissions based on the task policy specified.
Adversaries who have compromised user credentials can use this technique to
escalate privileges and gain unauthorized access to AWS resources. This is a New Terms rule that identifies
when the STS AssumeRoot action is performed by a user that rarely assumes this role against a specific member account.
"""
false_positives = [
    "AWS administrators or automated processes might regularly assume root for legitimate administrative purposes.",
    "AWS services might assume root to access AWS resources as part of their standard operations.",
    "Automated workflows might assume root to perform periodic administrative tasks.",
]
from = "now-6m"
index = ["filebeat-*", "logs-aws.cloudtrail-*"]
language = "kuery"
license = "Elastic License v2"
name = "AWS STS AssumeRoot by Rare User and Member Account"
note = """
## Triage and analysis

### Investigating AWS STS AssumeRoot by Rare User and Member Account

AWS STS `AssumeRoot` issues temporary credentials that grant elevated access into a member account, constrained by the
task policy and target policy attached to the request. In normal operations, only a small set of platform, security, or
automation roles should ever need to perform `AssumeRoot`, and typically only against a predictable set of member
accounts.

This rule is a New Terms rule that detects when a previously unseen combination of calling principal (`aws.cloudtrail.user_identity.arn`) and target member account (`aws.cloudtrail.resources.account_id`) successfully invokes `AssumeRoot`. Activity that matches this pattern may indicate privilege escalation, lateral movement into a new account, abuse of cross-account access paths, or misuse of administrative workflows.

#### Possible investigation steps

- **Identify the actor and target context**
  - Review `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.access_key_id` to determine:
    - Whether the caller is an IAM user, federated user, or role.
    - Whether this identity is normally used for organization-level administration or automation.
  - Inspect `aws.cloudtrail.resources.account_id` and `aws.cloudtrail.recipient_account_id` to identify the affected member account.
  - Check `source.address`, `source.geo.*`, and `user_agent.original` to understand where and how the call was made (console, CLI, SDK, automation runner, VPN, corporate IP, etc.).

- **Understand session, policy, and target details**
  - Examine `aws.cloudtrail.request_parameters` for:
    - `taskPolicyArn` – which predefined task policy was requested and what category of operations it enables (e.g., investigation, remediation, read-only, or broad admin).
    - `targetPrincipal` and/or related target fields – which member account principal is being accessed.
    - Any duration or configuration parameters (such as `durationSeconds`) that indicate unusually long-lived sessions.
  - In `aws.cloudtrail.response_elements`, review:
    - `credentials.accessKeyId` and `credentials.expiration` to confirm that credentials were successfully issued and how long they are valid.
    - Any additional response fields that indicate session constraints or failures (if present).

- **Correlate follow-on activity from the assumed root session**
  - Use the temporary access key from `aws.cloudtrail.response_elements.credentials.accessKeyId` to pivot in CloudTrail:
    - Search for subsequent events where `aws.cloudtrail.user_identity.access_key_id` matches that key.
    - Look for high-impact actions such as:
      - IAM changes (`iam:CreateUser`, `iam:AttachRolePolicy`, `iam:PutRolePolicy`, `iam:UpdateAssumeRolePolicy`).
      - Guardrail changes (CloudTrail, Security Hub, Config, GuardDuty configuration or detector changes).
      - Data-impacting actions (S3 bucket policy changes, RDS/RDS snapshot operations, EFS/RDS delete, secrets reads).
  - Correlate with any prior events for the calling identity:
    - STS calls that created the session used to invoke `AssumeRoot` (e.g., `AssumeRole`, SSO/identity provider activity).
    - Recent IAM policy updates that broadened its ability to perform cross-account administration.

- **Assess timing and operational alignment**
  - Use `@timestamp`, `cloud.region`, and your change calendar to determine:
    - Whether the event occurred during a documented maintenance window or deployment.
    - Whether the region and account align with the caller’s normal operational scope.
  - Compare with other events in the same time window:
    - Organization-level changes, new account creation, or migration work.
    - Other sensitive operations from the same `source.ip` or principal.

- **Validate with owners**
  - Confirm with:
    - Cloud/infra platform teams that normally operate organization-level admin roles.
    - Security/IR teams if they were running an investigation workflow that legitimately uses `AssumeRoot`.
  - Check whether the use of `AssumeRoot` is documented in CI/CD or automation designs that might have just expanded to this account, explaining the New Terms trigger.

### False positive analysis

- **Legitimate administrative cross-account access**
  - Platform, security, or central operations teams may use `AssumeRoot` as part of sanctioned workflows for:
    - New account onboarding.
    - Centralized remediation or investigation.
    - Complex deployment or migration tasks.
  - If this is the first time a specific engineer or automation role is onboarded to a given member account, the rule will fire once because it is a New Terms rule. Validate and, if appropriate, document this as expected behavior.

- **Automation and scheduled workflows**
  - CI/CD pipelines, organization-wide maintenance jobs, or incident response automation may use `AssumeRoot`:
    - Identify automation roles and service principals that legitimately call `AssumeRoot`.
    - Tune with rule exceptions based on `aws.cloudtrail.user_identity.arn`, `user_agent.original`, or specific `taskPolicyArn` values used only by trusted workflows.

If a pattern emerges where specific roles regularly and legitimately assume root into a consistent set of accounts, consider documenting those identities and, if appropriate, creating narrow exceptions — while preserving coverage for new, unexpected combinations.

### Response and remediation

- **Contain potentially unauthorized sessions**
  - If the activity appears suspicious or unapproved:
    - Invalidate the credentials issued by `AssumeRoot` (where supported) or constrain their impact by immediately tightening IAM, SCPs, or network controls in the affected member account.
    - Rotate or revoke long-lived access keys associated with the calling principal.
    - Temporarily restrict permissions on roles allowed to call `AssumeRoot` until the investigation is complete.

- **Investigate scope and impact**
  - Using CloudTrail:
    - Enumerate all actions performed with the `AssumeRoot` session access key and identify:
      - Privilege changes (IAM users, roles, policies, permission boundaries, SCPs).
      - Changes to logging and security controls (CloudTrail, GuardDuty, Security Hub, Config, firewall/WAF rules).
      - Data-impacting operations on high-value services (S3, RDS, DynamoDB, Secrets Manager, KMS).
    - Check if similar `AssumeRoot` activity has occurred recently from the same `source.ip`, principal, or member account.
  - Engage application, data, and platform owners for the impacted account(s) to:
    - Assess potential data exposure, integrity issues, or downtime.
    - Determine whether any actions conflict with intended change plans.

- **Hardening and preventive controls**
  - Restrict and monitor `AssumeRoot` usage:
    - Limit which IAM roles and identities can call `sts:AssumeRoot`, using IAM conditions (e.g., `aws:PrincipalArn`, `aws:PrincipalOrgID`, `aws:RequestedRegion`).
    - Where possible, require strong authentication on the initiating principal (MFA, federated SSO, device posture).
  - Add guardrails and observability:
    - Use AWS Config, Security Hub, and/or AWS Organizations SCPs to:
      - Detect or constrain highly privileged cross-account actions.
      - Ensure logging and monitoring services cannot be disabled or modified by assumed sessions without additional friction.
    - Ensure `AssumeRoot` activity is included in your SIEM dashboards and investigation playbooks.

- **Post-incident improvements**
  - If activity is confirmed malicious or unsafe:
    - Rotate credentials for all involved principals and review recent STS session usage for anomalies.
    - Update internal runbooks to clearly define when `AssumeRoot` is allowed, who can perform it, and how it should be documented.
    - Refine this rule’s exceptions or tagging strategy so that legitimate, recurring workflows are well-understood, while preserving high-fidelity visibility into new or unexpected `AssumeRoot` behavior.

### Additional information

- **[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://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoot.html"]
risk_score = 73
rule_id = "962a71ae-aac9-11ef-9348-f661ea17fbce"
severity = "high"
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",
]
timestamp_override = "event.ingested"
type = "new_terms"

query = '''
data_stream.dataset: "aws.cloudtrail"
    and event.provider: "sts.amazonaws.com"
    and event.action: "AssumeRoot"
    and event.outcome: "success"
'''


[[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.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 = "T1098"
name = "Account Manipulation"
reference = "https://attack.mitre.org/techniques/T1098/"

[[rule.threat.technique.subtechnique]]
id = "T1098.003"
name = "Additional Cloud Roles"
reference = "https://attack.mitre.org/techniques/T1098/003/"

[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",
    "aws.cloudtrail.resources.account_id",
    "aws.cloudtrail.resources.type",
    "event.action",
    "event.outcome",
    "cloud.account.id",
    "cloud.region",
    "aws.cloudtrail.request_parameters",
    "aws.cloudtrail.response_elements"
]

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

[metadata]
creation_date = "2025/09/15"
integration = ["azure"]
maturity = "production"
updated_date = "2026/08/26"

[rule]
author = ["Elastic"]
description = """
Identifies when a user is assigned a built-in administrator role in Azure RBAC (Role-Based Access Control). These roles
provide significant privileges and can be abused by attackers for lateral movement, persistence, or privilege
escalation. The privileged built-in administrator roles include Owner, Contributor, User Access Administrator, Azure
File Sync Administrator, Reservations Administrator, and Role Based Access Control Administrator.
"""
from = "now-9m"
index = ["filebeat-*", "logs-azure.activitylogs-*"]
language = "kuery"
license = "Elastic License v2"
name = "Azure RBAC Built-In Administrator Roles Assigned"
note = """## Triage and analysis

### Investigating Azure RBAC Built-In Administrator Roles Assigned

This rule identifies when a user is assigned a built-in administrator role in Azure RBAC (Role-Based Access Control). These roles provide significant privileges and can be abused by attackers for lateral movement, persistence, or privilege escalation. The privileged built-in administrator roles include Owner, Contributor, User Access Administrator, Azure File Sync Administrator, Reservations Administrator, and Role Based Access Control Administrator. Assignment can be done via the Azure portal, Azure CLI, PowerShell, or through API calls. Monitoring these assignments helps detect potential unauthorized privilege escalations.

#### Privileged Built-In Administrator Roles
- Contributor: b24988ac-6180-42a0-ab88-20f7382dd24c
- Owner: 8e3af657-a8ff-443c-a75c-2fe8c4bcb635
- Azure File Sync Administrator: 92b92042-07d9-4307-87f7-36a593fc5850
- Reservations Administrator: a8889054-8d42-49c9-bc1c-52486c10e7cd
- Role Based Access Control Administrator: f58310d9-a9f6-439a-9e8d-f62e7b41a168
- User Access Administrator: 18d7d88d-d35e-4fb5-a5c3-7773c20a72d9

### Possible investigation steps

- Identify the user who assigned the role and examine their recent activity for any suspicious actions.
- Review the source IP address and location associated with the role assignment event to assess if it aligns with expected user behavior or if it indicates potential unauthorized access.
- Check the history of role assignments for the user who was assigned the role to determine if this is a recurring pattern or a one-time event.
    - Additionally, identify the lifetime of the targeted user account to determine if it is a newly created account or an existing one.
- Determine if the user assigning the role historically has the necessary permissions to assign such roles and has done so in the past.
- Investigate any recent changes or activities performed by the newly assigned administrator to identify any suspicious actions or configurations that may have been altered.
- Correlate with other logs, such as Microsoft Entra ID sign-in logs, to identify any unusual access patterns or behaviors for the user.

### False positive analysis

- Legitimate administrators may assign built-in administrator roles during routine operations, maintenance or as required for onboarding new staff.
- Azure Kubernetes Service control-plane operations may assign the Contributor role to service principals. Assignments initiated by the Microsoft-owned AzureContainerService application are excluded.
- Repeated writes for the same role assignment ID by the same initiating principal are suppressed for one hour.
- Review internal tickets, change logs, or admin activity dashboards for approved operations.

### Response and remediation

- If administrative assignment was not authorized:
  - Immediately remove the built-in administrator role from the account.
  - Disable or lock the account and begin credential rotation.
  - Audit activity performed by the account after elevation, especially changes to role assignments and resource access.
- If suspicious:
  - Notify the user and confirm whether they performed the action.
  - Check for any automation or scripts that could be exploiting unused elevated access paths.
  - Review conditional access and PIM (Privileged Identity Management) configurations to limit elevation without approval.
- Strengthen posture:
  - Require MFA and approval for all privilege escalation actions.
  - Consider enabling JIT (Just-in-Time) access with expiration.
"""
references = [
    "https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles",
    "https://orca.security/resources/research-pod/azure-identity-access-management-iam-active-directory-ad/",
    "https://www.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/",
]
risk_score = 73
rule_id = "1a1046f4-9257-11f0-9a42-f661ea17fbce"
severity = "high"
tags = [
    "Domain: Cloud",
    "Domain: Identity",
    "Data Source: Azure",
    "Data Source: Azure Activity Logs",
    "Platform: Azure",
    "Rule Type: Custom Query (KQL)",
    "Use Case: Identity and Access Audit",
    "Tactic: Privilege Escalation",
    "Tactic: Persistence",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset: azure.activitylogs and
    event.action: "MICROSOFT.AUTHORIZATION/ROLEASSIGNMENTS/WRITE" and
    azure.activitylogs.properties.requestbody.properties.roleDefinitionId:
    (
      *18d7d88d-d35e-4fb5-a5c3-7773c20a72d9* or
      *f58310d9-a9f6-439a-9e8d-f62e7b41a168* or
      *b24988ac-6180-42a0-ab88-20f7382dd24c* or
      *8e3af657-a8ff-443c-a75c-2fe8c4bcb635* or
      *92b92042-07d9-4307-87f7-36a593fc5850* or
      *a8889054-8d42-49c9-bc1c-52486c10e7cd*
    ) and not (
        azure.activitylogs.identity.claims.appid: "7319c514-987d-4e9b-ac3d-d38c4f427f4c" and
        azure.activitylogs.identity.authorization.evidence.role: "Service Owner role" and
        azure.activitylogs.identity.authorization.evidence.principal_type: "ServicePrincipal" and
        azure.activitylogs.properties.requestbody.properties.roleDefinitionId: *b24988ac-6180-42a0-ab88-20f7382dd24c*
    )
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1098"
name = "Account Manipulation"
reference = "https://attack.mitre.org/techniques/T1098/"
[[rule.threat.technique.subtechnique]]
id = "T1098.003"
name = "Additional Cloud Roles"
reference = "https://attack.mitre.org/techniques/T1098/003/"



[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 = "T1098"
name = "Account Manipulation"
reference = "https://attack.mitre.org/techniques/T1098/"
[[rule.threat.technique.subtechnique]]
id = "T1098.003"
name = "Additional Cloud Roles"
reference = "https://attack.mitre.org/techniques/T1098/003/"



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

[rule.alert_suppression]
group_by = [
    "azure.activitylogs.identity.authorization.evidence.role_assignment_id",
    "azure.activitylogs.identity.authorization.evidence.principal_id",
]
missing_fields_strategy = "doNotSuppress"

[rule.alert_suppression.duration]
unit = "h"
value = 1

[metadata]
creation_date = "2025/06/13"
integration = ["azure"]
maturity = "production"
updated_date = "2026/04/10"

[rule]
author = ["Elastic"]
description = """
Detects a sequence of events in Microsoft Entra ID indicative of suspicious cloud-based device registration via automated
tooling like ROADtools or similar frameworks. This behavior involves adding a device via the Device Registration Service,
followed by the assignment of registered users and owners — a pattern consistent with techniques used to establish persistence or
acquire a Primary Refresh Token (PRT). ROADtools and similar tooling leave distinct telemetry signatures such as the
`Microsoft.OData.Client` user agent. These sequences are uncommon in typical user behavior and may reflect abuse of device
trust for session hijacking or silent token replay.
"""
from = "now-30m"
interval = "15m"
index = ["filebeat-*", "logs-azure.auditlogs-*"]
language = "eql"
license = "Elastic License v2"
name = "Entra ID Unusual Cloud Device Registration"
note = """## Triage and analysis

### Investigating Entra ID Unusual Cloud Device Registration

This rule detects a sequence of Microsoft Entra ID audit events consistent with cloud device registration abuse via ROADtools or similar automation frameworks. The activity includes three correlated events:

1. Add device operation from the Device Registration Service using suspicious user-agents (`Dsreg/*`, `DeviceRegistrationClient`, or `Microsoft.OData.Client/*`).
2. Addition of a registered user with an `enterprise registration` URN.
3. Assignment of a registered owner to the device.

This pattern has been observed in OAuth phishing and PRT abuse campaigns where adversaries silently register a cloud device to obtain persistent, trusted access.

### Possible investigation steps

- Identify the user principal associated with the device registration.
- Review the `azure.auditlogs.identity` field to confirm the Device Registration Service initiated the request.
- Check the user-agent in `azure.auditlogs.properties.additional_details.value`. Known attack tooling signatures include:
  - `Dsreg/10.0 (Windows X.X.X)` - ROADtools Windows device registration
  - `DeviceRegistrationClient` - ROADtools MacOS/Android device registration
  - `Microsoft.OData.Client/*` - .NET-based tools or Graph SDK
- Examine the OS version in the modified properties to identify potentially suspicious or outdated versions.
- Verify the URN in the new value field (`urn:ms-drs:enterpriseregistration.windows.net`) is not being misused.
- Use `azure.correlation_id` to pivot across all three steps of the registration flow.
- Pivot to `azure.signinlogs` to detect follow-on activity using the new device, such as sign-ins involving refresh or primary refresh tokens.
- Look for signs of persistence or lateral movement enabled by the newly registered device.
- Identify the registered device name by reviewing `azure.auditlogs.properties.target_resources.0.display_name` and confirm it's expected for the user or organization.
- Use the correlation ID `azure.correlation_id` to pivot into registered user events from Entra ID audit logs and check `azure.auditlogs.properties.target_resources.0.user_principal_name` to identify the user associated with the device registration.
- Review any activity for this user from Entra ID sign-in logs, where the incoming token type is a `primaryRefreshToken`.

### False positive analysis

- Some MDM, autopilot provisioning flows, or third-party device management tools may generate similar sequences. Validate against known provisioning tools, expected rollout windows, and device inventory.
- Investigate whether the device name, OS version, and registration details align with normal IT workflows.
- Check if the user-agent corresponds to legitimate automation or tooling used by your organization.

### Response and remediation

- If confirmed malicious, remove the registered device from Entra ID.
- Revoke refresh tokens and primary refresh tokens associated with the user and device.
- Disable the user account and initiate password reset and identity verification procedures.
- Review audit logs and sign-in activity for additional indicators of persistence or access from the rogue device.
- Tighten conditional access policies to restrict device registration and enforce compliance or hybrid join requirements.
"""
references = [
    "https://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/",
    "https://github.com/dirkjanm/ROADtools",
    "https://dirkjanm.io/introducing-roadtools-token-exchange-roadtx/"
]
risk_score = 47
rule_id = "90efea04-5675-11f0-8f80-f661ea17fbcd"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Domain: Identity",
    "Data Source: Azure",
    "Data Source: Microsoft Entra ID",
    "Data Source: Microsoft Entra ID Audit Logs",
    "Use Case: Identity and Access Audit",
    "Tactic: Persistence",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
sequence by azure.correlation_id with maxspan=5m
[any where data_stream.dataset == "azure.auditlogs" and
    azure.auditlogs.identity == "Device Registration Service" and
    azure.auditlogs.operation_name == "Add device" and
    (
        azure.auditlogs.properties.additional_details.value like "Microsoft.OData.Client/*" or
        azure.auditlogs.properties.additional_details.value like "Dsreg/*" or
        azure.auditlogs.properties.additional_details.value == "DeviceRegistrationClient"
    ) and
    `azure.auditlogs.properties.target_resources.0.modified_properties.1.display_name` == "CloudAccountEnabled" and
    `azure.auditlogs.properties.target_resources.0.modified_properties.1.new_value` == "[true]"]
[any where data_stream.dataset == "azure.auditlogs" and
    azure.auditlogs.operation_name == "Add registered users to device" and
    `azure.auditlogs.properties.target_resources.0.modified_properties.2.new_value` like "*urn:ms-drs:enterpriseregistration.windows.net*"]
[any where data_stream.dataset == "azure.auditlogs" and
    azure.auditlogs.operation_name == "Add registered owner to device"]
'''


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

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

[[rule.threat.technique.subtechnique]]
id = "T1098.005"
name = "Device Registration"
reference = "https://attack.mitre.org/techniques/T1098/005/"

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

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

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

[[rule.threat.technique.subtechnique]]
id = "T1098.005"
name = "Device Registration"
reference = "https://attack.mitre.org/techniques/T1098/005/"

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

[rule]
description = """
Detects the use of the AuthorizationExecuteWithPrivileges function to provide the user a password prompt via an unsigned
or untrusted application. Threat actors have recently used this in order to trick users into providing their malicious
application with higher privileges.
"""
id = "559fc9c7-f2fd-4fd9-af07-df8b7408e0b8"
license = "Elastic License v2"
name = "ExecuteWithPrivileges Prompt via Unsigned or Untrusted Application"
os_list = ["macos"]
reference = ["https://securelist.com/new-macos-backdoor-crypto-stealer/111778/"]
version = "1.0.3"

query = '''
process where event.type == "start" and event.action == "exec" and process.name == "security_authtrampoline" and
 process.args like ("/Applications/*", "/Volumes/*") and process.args like "auth*" and
 (process.parent.code_signature.exists == false or process.parent.code_signature.trusted == false) and 
 process.Ext.effective_parent.executable like ("/Applications/*", "/Volumes/*")
'''

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

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

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1548"
name = "Abuse Elevation Control Mechanism"
reference = "https://attack.mitre.org/techniques/T1548/"
[[threat.technique.subtechnique]]
id = "T1548.004"
name = "Elevated Execution with Prompt"
reference = "https://attack.mitre.org/techniques/T1548/004/"



[threat.tactic]
id = "TA0004"
name = "Privilege Escalation"
reference = "https://attack.mitre.org/tactics/TA0004/"
[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1548"
name = "Abuse Elevation Control Mechanism"
reference = "https://attack.mitre.org/techniques/T1548/"
[[threat.technique.subtechnique]]
id = "T1548.004"
name = "Elevated Execution with Prompt"
reference = "https://attack.mitre.org/techniques/T1548/004/"



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

[internal]
min_endpoint_version = "8.10.2"

[rule]
description = """
Detects the execution of a binary, from a volume mount, that has been self-signed using the native Codesign tool. The
specific code sign identifier scheme generated by this process matches on almost all North Korean payloads as they have
used this method to sign their malware like AppleJeus, for example, and most recently the 3CX supply chain 2nd stage
malware payload.
"""
id = "ac494288-08e1-4597-9a04-3526144de479"
license = "Elastic License v2"
name = "Execution of Self-Signed Binary from Volume Mount"
os_list = ["macos"]
version = "1.0.4"

query = '''
process where event.type == "start" and event.action == "exec" and 
 process.code_signature.signing_id regex~ """[A-Za-z0-9\_\s]{2,}\-[a-z0-9]{40}""" and
 process.code_signature.trusted == false and 
 process.args_count <= 2 and 
 process.executable like "/Volumes/*"
'''

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

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

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1059"
name = "Command and Scripting Interpreter"
reference = "https://attack.mitre.org/techniques/T1059/"
[[threat.technique.subtechnique]]
id = "T1059.004"
name = "Unix Shell"
reference = "https://attack.mitre.org/techniques/T1059/004/"



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

[internal]
min_endpoint_version = "8.5.0"

[metadata]
creation_date = "2026/06/30"
integration = ["gcp"]
maturity = "production"
updated_date = "2026/06/30"

[rule]
author = ["Elastic"]
description = """
Detects successful GKE audit events where a pod is created with allowPrivilegeEscalation enabled. This weakens
container isolation and can help an attacker escalate toward host access. Standalone pods are included; workloads owned
by ReplicaSet, DaemonSet, or StatefulSet controllers are excluded.
"""
false_positives = [
    """
    Debug or break-glass pods may enable privilege escalation intentionally. Exclude trusted namespaces, users, or
    deployment patterns after baselining.
    """,
]
index = ["logs-gcp.audit-*"]
language = "kuery"
license = "Elastic License v2"
name = "GKE Privileged Pod Created"
note = """## Triage and analysis

### Investigating GKE Privileged Pod Created

Review `user.email`, `orchestrator.resource.name`, `orchestrator.namespace`, and the pod spec in `gcp.audit.request`.
Confirm whether allowPrivilegeEscalation is required for the workload.

### Investigation steps

- Identify the actor and source (`user.email`, `source.ip`, `user_agent.original`).
- Inspect container images and securityContext in the audit request payload.
- Correlate with RBAC changes, secret access, or exec activity from the same identity.

### False positives

- One-off admin debugging pods; tune by user or namespace when documented.

## Setup

The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule."""
references = [
    "https://cloud.google.com/kubernetes-engine/docs/how-to/audit-logging",
    "https://kubernetes.io/docs/tasks/configure-pod-container/security-context/",
]
risk_score = 47
rule_id = "a7b984e4-16ff-405b-80be-31a94a03e929"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Domain: Kubernetes",
    "Data Source: GCP",
    "Data Source: Google Cloud Platform",
    "Use Case: Threat Detection",
    "Tactic: Privilege Escalation",
    "Tactic: Execution",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:gcp.audit and event.action:"io.k8s.core.v1.pods.create" and event.outcome:success and
gcp.audit.request.spec.containers.securityContext.allowPrivilegeEscalation:true and
not gcp.audit.request.metadata.ownerReferences.kind:("ReplicaSet" or "DaemonSet" or "StatefulSet")
'''

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

[[rule.threat.technique]]
id = "T1611"
name = "Escape to Host"
reference = "https://attack.mitre.org/techniques/T1611/"

[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 = "T1610"
name = "Deploy Container"
reference = "https://attack.mitre.org/techniques/T1610/"

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

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

[rule]
author = ["Elastic"]
description = """
This rule detects kernel unpacking activity through several built-in Linux utilities. Attackers may use these utilities
to unpack kernel images and modules to search for vulnerabilities or to modify the kernel.
"""
from = "now-9m"
index = ["logs-endpoint.events.process*"]
language = "eql"
license = "Elastic License v2"
name = "Kernel Unpacking Activity"
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 Kernel Unpacking Activity

Kernel unpacking involves using utilities to extract or inspect kernel images and modules, often for legitimate maintenance or updates. However, adversaries exploit this to identify vulnerabilities or alter the kernel for malicious purposes. The detection rule identifies suspicious unpacking by monitoring specific Linux utilities and command patterns, excluding benign processes like system updates, to flag potential threats.

### Possible investigation steps

- Review the process details to identify the specific utility used for unpacking, such as "file", "unlzma", "gunzip", etc., and verify if the usage aligns with typical system maintenance activities.
- Examine the parent process name and arguments, especially those involving "/boot/*", to determine if the unpacking activity is part of a legitimate system operation or an unauthorized action.
- Check the user account associated with the process to assess if the activity was initiated by a legitimate user or an unauthorized entity.
- Investigate the timing of the event to see if it coincides with scheduled maintenance or updates, which might explain the unpacking activity.
- Look for any related alerts or logs that might indicate further suspicious behavior, such as attempts to modify kernel modules or other system files following the unpacking activity.
- Cross-reference the event with recent system updates or patches to rule out false positives related to legitimate system operations.

### False positive analysis

- System updates and maintenance activities can trigger this rule when legitimate processes unpack kernel images. To manage this, exclude processes initiated by known update utilities like "mkinitramfs" from triggering alerts.
- Custom scripts or administrative tasks that involve unpacking kernel images for legitimate purposes may also cause false positives. Identify and whitelist these scripts or processes by their specific command patterns or parent process names.
- Backup or recovery operations that involve accessing or unpacking kernel files might be flagged. Review these operations and exclude them by specifying the responsible process names or arguments in the detection rule.
- Automated security tools that scan or analyze kernel images for compliance or vulnerability assessments can be mistaken for malicious activity. Exclude these tools by adding their process names to the exception list.

### Response and remediation

- Isolate the affected system from the network to prevent potential lateral movement or further exploitation by the adversary.
- Terminate any suspicious processes identified by the detection rule, especially those involving the unpacking of kernel images or modules.
- Conduct a thorough review of the system's kernel and module integrity using trusted tools to ensure no unauthorized modifications have been made.
- Restore the system from a known good backup if any unauthorized changes to the kernel or system files are detected.
- Update the system's kernel and all related packages to the latest versions to mitigate any known vulnerabilities that could be exploited.
- Monitor the system for any recurring suspicious activity, focusing on the use of utilities and command patterns identified in the detection rule.
- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network."""
references = ["https://www.elastic.co/security-labs/declawing-pumakit"]
risk_score = 47
rule_id = "4f725dc5-ae44-46c1-9ac5-99f6f7a70d8a"
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 = "medium"
tags = [
    "Domain: Endpoint",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Discovery",
    "Tactic: Defense Evasion",
    "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.parent.args like "/boot/*" or process.args like "/boot/*") and (
  (process.name in ("file", "unlzma", "gunzip", "unxz", "bunzip2", "unzstd", "unzip", "tar")) or
  (process.name == "grep" and process.args == "ELF") or
  (process.name in ("lzop", "lz4") and process.args in ("-d", "--decode"))
) and
not (
  process.parent.name == "mkinitramfs" or
  process.parent.executable like (
    "/usr/lib/needrestart/vmlinuz-get-version", "/usr/libexec/platform-python*", "/tmp/newroot/usr/libexec/platform-python*",
    "/usr/bin/kdumpctl", "/usr/bin/stap-report", "/usr/sbin/nv-update-initrd"
  ) or
  process.parent.command_line like "*ansible*" or
  process.parent.args == "/usr/bin/kdumpctl"
)
'''

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

[[rule.threat.technique]]
id = "T1082"
name = "System Information Discovery"
reference = "https://attack.mitre.org/techniques/T1082/"

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

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

[[rule.threat.technique]]
id = "T1014"
name = "Rootkit"
reference = "https://attack.mitre.org/techniques/T1014/"

[[rule.threat.technique]]
id = "T1140"
name = "Deobfuscate/Decode Files or Information"
reference = "https://attack.mitre.org/techniques/T1140/"

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

[metadata]
creation_date = "2026/04/27"
integration = ["kubernetes"]
maturity = "production"
updated_date = "2026/04/27"

[rule]
author = ["Elastic"]
description = """
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.
"""
false_positives = [
    """
    Platform installers, GitOps controllers, and emergency break-glass roles sometimes ship or widen wildcard
    ClusterRoles; correlate with change records and narrow by user or service account when baselined.
    """,
]
from = "now-9m"
interval = "5m"
language = "esql"
license = "Elastic License v2"
name = "Kubernetes RBAC Wildcard Elevation on Existing Role"
note = """## Triage and analysis

### Investigating Kubernetes RBAC Wildcard Elevation on Existing Role

Someone patched or updated a Role or ClusterRole so the stored rules grant star verbs and star resources—near
cluster-admin breadth on that scope. Confirm the actor (user, group, impersonation), client, and non-loopback source
IP; then see who can bind that role.

### Possible investigation steps

- Diff the role YAML before and after; list RoleBindings and ClusterRoleBindings that reference it and which subjects
  gained the widened access.
- In the same window, check secret reads, exec, and further RBAC changes from the same identity.

### False positive analysis

- Approved GitOps or vendor upgrades sometimes widen a known ClusterRole; allowlist stable automation when documented.

### Response and remediation

- Revert the role, drop unexpected bindings, rotate credentials for the actor, and block future wildcard RBAC outside
  governed pipelines (policy-as-code, PR-only RBAC).
"""
references = [
    "https://attack.mitre.org/techniques/T1098/006/",
    "https://kubernetes.io/docs/reference/access-authn-authz/rbac/",
]
risk_score = 73
rule_id = "c8f4a2e1-9b3d-4c7e-8f2a-1d0e5b6c7a89"
severity = "high"
tags = [
    "Data Source: Kubernetes",
    "Domain: Kubernetes",
    "Use Case: Threat Detection",
    "Tactic: Privilege Escalation",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "esql"
query = '''
from logs-kubernetes.audit_logs-* metadata _id, _index, _version
| where
  kubernetes.audit.objectRef.resource in ("roles", "clusterroles") and
  kubernetes.audit.verb in ("update", "patch") and
  `kubernetes.audit.annotations.authorization_k8s_io/decision` == "allow" and
  kubernetes.audit.level == "RequestResponse" and
  kubernetes.audit.stage == "ResponseComplete" and
  kubernetes.audit.sourceIPs is not null and
  not kubernetes.audit.sourceIPs in ("::1", "127.0.0.1") and
  KQL(""" kubernetes.audit.responseObject.rules.verbs:"*" and kubernetes.audit.responseObject.rules.resources:"*" """)
| keep user.name, user_agent.original, event.action, source.ip, kubernetes.audit.verb, kubernetes.audit.objectRef.resource, kubernetes.audit.objectRef.name, kubernetes.audit.requestURI, kubernetes.audit.user.username, kubernetes.audit.user.groups, `kubernetes.audit.annotations.authorization_k8s_io/decision`, event.original, _id, _version, _index, data_stream.namespace
'''

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

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

[[rule.threat.technique.subtechnique]]
id = "T1098.006"
name = "Additional Container Cluster Roles"
reference = "https://attack.mitre.org/techniques/T1098/006/"

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

[rule]
description = """
This rule detects when a process creates a memory file descriptor using the memfd_create syscall followed by loading a
loadable kernel module (LKM) via a fork. This activity indicates an active attempt to load a kernel module and should be
considered highly abnormal or suspicious. This activity can occur when the modprobe userland utility is invoked, or when
the underlying init_module/finit_module syscalls are used, to load a kernel module via a command and control channel.
"""
id = "76fac24d-7736-4aed-bcd0-feed2286385d"
license = "Elastic License v2"
name = "Loadable Kernel Module Load via Forked Memory File Descriptor"
os_list = ["linux"]
version = "1.0.4"

query = '''
sequence with maxspan=5s
  [process where event.action == "memfd_create" and
  not (
    (
      process.executable == "/opt/eset/efs/sbin/startd" and
      process.command_line == "/opt/eset/efs/sbin/startd" and
      process.parent.executable == "/usr/lib/systemd/systemd"
    ) or
    (
      process.executable == "/usr/lib/systemd/systemd" and
      process.command_line == "/sbin/init" and
      process.Ext.memfd.name == "memfd:system-environment-generators" and
      process.parent.executable == "/usr/bin/runc"
    ) or
    (
      process.executable like "/usr/libexec/platform-python3*" and
      process.parent.executable == "/usr/lib/systemd/systemd" and
      process.Ext.memfd.name == "memfd:libffi"
    ) or
    (process.parent.executable like "/snap/lxd/*/sbin/lxd" and process.command_line == "/sbin/modprobe -b zfs")
  )] by process.entity_id
  [process where event.action == "load_module"] by process.parent.entity_id
'''

min_endpoint_version = "9.1.4"
optional_actions = []
[[actions]]
action = "kill_process"
field = "process.entity_id"
state = 0
tree = true

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

[[actions]]
action = "kill_process"
field = "process.parent.entity_id"
state = 0
tree = true

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

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1106"
name = "Native API"
reference = "https://attack.mitre.org/techniques/T1106/"


[threat.tactic]
id = "TA0002"
name = "Execution"
reference = "https://attack.mitre.org/tactics/TA0002/"
[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1547"
name = "Boot or Logon Autostart Execution"
reference = "https://attack.mitre.org/techniques/T1547/"
[[threat.technique.subtechnique]]
id = "T1547.006"
name = "Kernel Modules and Extensions"
reference = "https://attack.mitre.org/techniques/T1547/006/"



[threat.tactic]
id = "TA0003"
name = "Persistence"
reference = "https://attack.mitre.org/tactics/TA0003/"
[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1014"
name = "Rootkit"
reference = "https://attack.mitre.org/techniques/T1014/"

[[threat.technique]]
id = "T1055"
name = "Process Injection"
reference = "https://attack.mitre.org/techniques/T1055/"
[[threat.technique.subtechnique]]
id = "T1055.009"
name = "Proc Memory"
reference = "https://attack.mitre.org/techniques/T1055/009/"


[[threat.technique]]
id = "T1620"
name = "Reflective Code Loading"
reference = "https://attack.mitre.org/techniques/T1620/"


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

[internal]
min_endpoint_version = "9.1.4"

[rule]
description = """
Identifies the execution of the built-in MSBuild utility with a suspicious count of command line arguments (less than
three). Adversaries may use MSBuild to proxy the execution of malicious code via a trusted Windows utility.
"""
id = "6518cdaf-e6cd-4cf9-a51e-043117c3dbeb"
license = "Elastic License v2"
name = "MSBuild with Unusual Arguments"
os_list = ["windows"]
reference = ["https://lolbas-project.github.io/lolbas/Binaries/Msbuild/"]
version = "1.0.29"

query = '''
process where event.action == "start" and
 process.pe.original_file_name == "MSBuild.exe" and process.args_count == 2 and
  /* FP - expected developers msbuild installation directories */

 not process.executable : ("?:\\Program Files (x86)\\Microsoft Visual Studio\\*",
                           "?:\\Program Files\\Microsoft Visual Studio\\*",
                           "?:\\Program Files (x86)\\MSBuild\\*",
                           "?:\\Program Files\\MSBuild\\*") and
 not process.command_line : ("* /*", "* .\\*", "*.proj*", "*.sln*") and
  /* FP - Third Party Programs except MS Office */

 not (process.parent.executable : ("?:\\Program Files (x86)\\*.exe", "?:\\Program Files\\*.exe") and
       not process.parent.name : 
                          ("winword.exe",
                           "excel.exe",
                           "outlook.exe",
                           "powerpnt.exe",
                           "eqnedt32.exe",
                           "fltldr.exe",
                           "mspub.exe",
                           "msaccess.exe"))
'''

min_endpoint_version = "7.15.0"
[[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 = "T1127"
name = "Trusted Developer Utilities Proxy Execution"
reference = "https://attack.mitre.org/techniques/T1127/"
[[threat.technique.subtechnique]]
id = "T1127.001"
name = "MSBuild"
reference = "https://attack.mitre.org/techniques/T1127/001/"



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

[internal]
min_endpoint_version = "7.15.0"

[metadata]
bypass_bbr_timing = true
creation_date = "2023/08/09"
integration = ["endpoint"]
maturity = "production"
updated_date = "2024/05/05"

[rule]
author = ["Elastic"]
building_block_type = "default"
description = """
Identifies instances of VLC-related DLLs which are not signed by the original developer. Attackers may name their
payload as legitimate applications to blend into the environment, or embedding its malicious code within legitimate
applications to deceive machine learning algorithms by incorporating authentic and benign code.
"""
from = "now-9m"
index = ["logs-endpoint.events.library-*"]
language = "eql"
license = "Elastic License v2"
name = "Potential Masquerading as VLC DLL"
risk_score = 21
rule_id = "4494c14f-5ff8-4ed2-8e99-bf816a1642fc"
severity = "low"
tags = [
    "Domain: Endpoint",
    "Data Source: Elastic Defend",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Defense Evasion",
    "Tactic: Persistence",
    "Rule Type: BBR",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
library where host.os.type == "windows" and event.action == "load" and
  dll.name : ("libvlc.dll", "libvlccore.dll", "axvlc.dll") and
  not (
    dll.code_signature.subject_name : ("VideoLAN", "716F2E5E-A03A-486B-BC67-9B18474B9D51")
    and dll.code_signature.trusted == true
  )
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1036"
name = "Masquerading"
reference = "https://attack.mitre.org/techniques/T1036/"
[[rule.threat.technique.subtechnique]]
id = "T1036.001"
name = "Invalid Code Signature"
reference = "https://attack.mitre.org/techniques/T1036/001/"

[[rule.threat.technique.subtechnique]]
id = "T1036.005"
name = "Match Legitimate Resource Name or Location"
reference = "https://attack.mitre.org/techniques/T1036/005/"



[rule.threat.tactic]
id = "TA0005"
name = "Defense Evasion"
reference = "https://attack.mitre.org/tactics/TA0005/"
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1554"
name = "Compromise Host Software Binary"
reference = "https://attack.mitre.org/techniques/T1554/"


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

[rule]
description = """
Identifies access attempt to the Windows Passwords Vault via Powershell. Adversaries may acquire credentials from Vault
files.
"""
id = "57bc4c03-7ed9-409e-971a-a0a03ea99ea0"
license = "Elastic License v2"
name = "PowerShell Script with Passwords Vault Access Capability"
os_list = ["windows"]
version = "1.0.5"

query = '''
api where process.Ext.api.name == "AmsiScanBuffer" and
 (process.name in~ ("powershell.exe") or process.Ext.api.parameters.app_name == "PowerShell") and
  process.Ext.api.parameters.buffer : "*Credentials.PasswordVault*" and process.Ext.api.parameters.buffer : ("*.RetrievePassword*", "*.RetrieveAll*") and
  not process.Ext.api.parameters.content_name : ("?:\\Program Files (x86)\\*", "?:\\Program Files\\*") and
  not (process.parent.executable : ("C:\\Program Files\\WindowsApps\\KeeperSecurityInc.KeeperPasswordManager_*\\app\\keeperpasswordmanager.exe", "C:\\Users\\*\\Downloads\\keeperimport*.exe") and
       process.command_line : "C:\\WINDOWS\\system32\\windowspowershell\\v1.0\\powershell.exe \"[Windows.Security.Credentials.PasswordVault,Windows.Security.Credentials,ContentType=WindowsRuntime];(new-object Windows.Security.Credentials.PasswordVault).RetrieveAll() | % { $_.RetrievePassword(); $_ }\"")
'''

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

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

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1059"
name = "Command and Scripting Interpreter"
reference = "https://attack.mitre.org/techniques/T1059/"
[[threat.technique.subtechnique]]
id = "T1059.001"
name = "PowerShell"
reference = "https://attack.mitre.org/techniques/T1059/001/"



[threat.tactic]
id = "TA0002"
name = "Execution"
reference = "https://attack.mitre.org/tactics/TA0002/"
[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1555"
name = "Credentials from Password Stores"
reference = "https://attack.mitre.org/techniques/T1555/"
[[threat.technique.subtechnique]]
id = "T1555.004"
name = "Windows Credential Manager"
reference = "https://attack.mitre.org/techniques/T1555/004/"



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

[internal]
min_endpoint_version = "8.16.0"

[rule]
description = """
Detects an outbound network connection by a Python script that was executed and deleted from disk. A recent DPRK initial
access campaign that resulted in the theft of $1.5 billion dollars used a Python application that self deletes and
continues operating in memory.
"""
id = "fdaa3c78-6df7-4c87-be78-1acadecc908a"
license = "Elastic License v2"
name = "Self-Deleted Python Script Outbound Network Connection"
os_list = ["macos"]
reference = [
    "https://unit42.paloaltonetworks.com/slow-pisces-new-custom-malware/",
    "https://slowmist.medium.com/cryptocurrency-apt-intelligence-unveiling-lazarus-groups-intrusion-techniques-a1a6efda7d34",
]
version = "1.0.5"

query = '''
sequence by process.entity_id with maxspan=15s
[process where event.type == "start" and event.action == "exec" and process.name like~ "python*" and process.args_count == 2] as event0
[file where event.action == "deletion" and file.extension in ("py", "pyc") and process.name like~ "python*" and
  stringcontains~(event0.process.command_line, file.path)] 
[network where event.type == "start" and
   not cidrmatch(destination.ip, 
       "240.0.0.0/4", "233.252.0.0/24", "224.0.0.0/4", "198.19.0.0/16", "192.18.0.0/15", 
       "192.0.0.0/24", "10.0.0.0/8", "127.0.0.0/8", "169.254.0.0/16", "172.16.0.0/12", 
       "192.0.2.0/24", "192.31.196.0/24", "192.52.193.0/24", "192.168.0.0/16", "192.88.99.0/24", 
       "100.64.0.0/10", "192.175.48.0/24", "198.18.0.0/15", "198.51.100.0/24", "203.0.113.0/24",
       "::1", "FE80::/10", "FF00::/8")]
'''

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

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

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1059"
name = "Command and Scripting Interpreter"
reference = "https://attack.mitre.org/techniques/T1059/"
[[threat.technique.subtechnique]]
id = "T1059.006"
name = "Python"
reference = "https://attack.mitre.org/techniques/T1059/006/"



[threat.tactic]
id = "TA0002"
name = "Execution"
reference = "https://attack.mitre.org/tactics/TA0002/"
[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1070"
name = "Indicator Removal"
reference = "https://attack.mitre.org/techniques/T1070/"
[[threat.technique.subtechnique]]
id = "T1070.004"
name = "File Deletion"
reference = "https://attack.mitre.org/techniques/T1070/004/"



[threat.tactic]
id = "TA0005"
name = "Defense Evasion"
reference = "https://attack.mitre.org/tactics/TA0005/"
[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1105"
name = "Ingress Tool Transfer"
reference = "https://attack.mitre.org/techniques/T1105/"


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

[internal]
min_endpoint_version = "8.16.0"