Elastic rules: 34

[rule]
description = """
This rule detects the modification of registry settings that control how files are visualized to the user via Explorer.
Some malwares will modify those entries to hide malware related files.
"""
id = "4f7b1362-1299-4ce7-8e02-03b74dad4eb1"
license = "Elastic License v2"
name = "Attempt to Hide Files via Registry Modification"
os_list = ["windows"]
version = "1.0.6"

query = '''
registry where event.action == "modification" and process.executable != null and
 registry.key like "S-*\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Advanced" and
 (
  (registry.value == "HideFileExt" and registry.data.strings == "1") or
  (registry.value == "Hidden" and registry.data.strings == "2") or
  (registry.value == "ShowSuperHidden" and registry.data.strings == "0")
  ) and
  not process.executable :
                ("C:\\Windows\\system32\\svchost.exe",
                 "C:\\Windows\\explorer.exe",
                 "C:\\Windows\\regedit.exe",
                 "C:\\Windows\\System32\\runonce.exe",
                 "C:\\Windows\\System32\\ShellAppRuntime.exe",
                 "C:\\Windows\\ImmersiveControlPanel\\SystemSettings.exe",
                 "C:\\Windows\\System32\\SystemPropertiesPerformance.exe",
                 "C:\\Windows\\System32\\SystemPropertiesAdvanced.exe",
                 "C:\\Windows\\System32\\SystemPropertiesComputerName.exe",
                 "C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe",
                 "C:\\Program Files\\KEYENCE\\IM Editor2\\IMController.exe",
                 "C:\\Program Files\\Streamline3\\1.7.1.2\\pxsvc.exe", 
                 "C:\\Windows\\System32\\reg.exe", 
                 "C:\\Windows\\System32\\regsvr32.exe",
                 "C:\\$WINDOWS.~BT\\Sources\\SetupPlatform.exe",
                 "C:\\ADP SmartCompliance PowerTool\\Compliance.exe",
                 "D:\\USMT\\X64\\loadstate.exe",
                 "C:\\Program Files\\*.exe", 
                 "C:\\Program Files (x86)\\*.exe") and
not (process.code_signature.subject_name : ("Cyberdigm. Corp.", "CYBERDIGM CO., LTD.", "Electronic Arts, Inc.") and process.code_signature.trusted == true)
'''

min_endpoint_version = "8.4.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 = "T1112"
name = "Modify Registry"
reference = "https://attack.mitre.org/techniques/T1112/"

[[threat.technique]]
id = "T1564"
name = "Hide Artifacts"
reference = "https://attack.mitre.org/techniques/T1564/"
[[threat.technique.subtechnique]]
id = "T1564.001"
name = "Hidden Files and Directories"
reference = "https://attack.mitre.org/techniques/T1564/001/"



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

[internal]
min_endpoint_version = "8.4.0"

[metadata]
creation_date = "2020/06/10"
integration = ["aws"]
maturity = "production"
updated_date = "2026/04/10"

[rule]
author = ["Elastic"]
description = """
Detects creation of a new AWS CloudTrail trail via CreateTrail API. While legitimate during onboarding or auditing
improvements, adversaries can create trails that write to attacker-controlled destinations, limit regions, or otherwise
subvert monitoring objectives. New trails should be validated for destination ownership, encryption, multi-region
coverage, and organizational scope.
"""
false_positives = [
    """
    Trail creations may be made by a system or network administrator. Verify whether the user identity, user agent,
    and/or hostname should be making changes in your environment. Trail creations by unfamiliar users or hosts should be
    investigated. If known behavior is causing false positives, it can be exempted from the rule.
    """,
]
from = "now-6m"
index = ["filebeat-*", "logs-aws.cloudtrail-*"]
language = "kuery"
license = "Elastic License v2"
name = "AWS CloudTrail Log Created"
note = """## Triage and analysis

### Investigating AWS CloudTrail Log Created

AWS CloudTrail is a service that enables governance, compliance, and operational and risk auditing of your AWS account. It logs API calls and related events, providing visibility into user activity. Adversaries may create new trails to capture sensitive data or cover their tracks. This detection identifies
`CreateTrail` calls so responders can verify destination ownership, encryption, and scope before accepting the change.

#### Possible investigation steps

- **Identify the actor and context**
  - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, `user_agent.original`, `source.ip`.
  - Confirm a related change request exists (onboarding, architecture change).
- **Validate trail configuration**
  - In `aws.cloudtrail.request_parameters`, verify:
    - `S3BucketName`/`CloudWatchLogsLogGroupArn` belong to your org (no external accounts).
    - `IsMultiRegionTrail=true` and `IncludeGlobalServiceEvents=true` (as per your standard).
    - `KmsKeyId` is an approved CMK; log file validation enabled.
- **Correlate activity**
  - Look for `PutEventSelectors`, `PutInsightSelectors`, `StartLogging` following creation.
  - Check for prior enumeration: `DescribeTrails`, `ListBuckets`, `GetEventSelectors`.

### False positive analysis
- **Planned creation**: Onboarding or compliance initiatives often add trails. Validate via ticket and standard template.
- **Automation**: IaC or control-tower pipelines may create trails on account bootstrap.

### Response and remediation
- **If unauthorized**
  - Disable or delete the trail; verify and secure the destination S3/CloudWatch resources.
  - Review the actor’s recent changes and rotate credentials if compromise is suspected.
- **Hardening**
  - Restrict `cloudtrail:CreateTrail` to admin roles.
  - Use AWS Config / Security Hub controls to enforce multi-region, global events, and validated destinations.

### 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/awscloudtrail/latest/APIReference/API_CreateTrail.html",
    "https://awscli.amazonaws.com/v2/documentation/api/latest/reference/cloudtrail/create-trail.html",
]
risk_score = 21
rule_id = "594e0cbf-86cc-45aa-9ff7-ff27db27d3ed"
severity = "low"
tags = [
    "Domain: Cloud",
    "Data Source: AWS",
    "Data Source: Amazon Web Services",
    "Data Source: AWS Cloudtrail",
    "Use Case: Log Auditing",
    "Tactic: Collection",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

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


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

[[rule.threat.technique]]
id = "T1530"
name = "Data from Cloud Storage"
reference = "https://attack.mitre.org/techniques/T1530/"

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

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

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

[[rule.threat.technique.subtechnique]]
id = "T1562.008"
name = "Disable or Modify Cloud Logs"
reference = "https://attack.mitre.org/techniques/T1562/008/"

[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",
    "aws.cloudtrail.response_elements",
]

[metadata]
creation_date = "2026/06/29"
integration = ["aws"]
maturity = "production"
updated_date = "2026/06/29"

[rule]
author = ["Elastic"]
description = """
Detects when an Amazon ECR repository or registry policy is modified to grant public access using a wildcard principal
(Principal:"*") statement. This rule analyzes SetRepositoryPolicy and PutRegistryPolicy events whose policy document grants an Allow effect to a
wildcard ("*") principal, indicating that pull (and potentially push) permissions were
extended to all identities, including unauthenticated users. A public container registry can expose proprietary images
and any secrets baked into their layers, and, if push is allowed, enables supply-chain implantation. Public ECR access
is sometimes intentional for image distribution, so the granting principal and the permissions should be validated.
"""
false_positives = [
    """
    Repositories used to distribute public images may legitimately contain Principal:"*". This rule does not by itself
    determine whether a Deny statement restricts the same access; review the full policy in
    "aws.cloudtrail.request_parameters" and confirm the granted actions (pull-only versus push) and whether public
    exposure is intended.
    """,
]
from = "now-15m"
interval = "10m"
language = "esql"
license = "Elastic License v2"
name = "AWS ECR Repository or Registry Policy Granted Public Access"
note = """## Triage and analysis

### Investigating AWS ECR Repository or Registry Policy Granted Public Access

This rule detects "SetRepositoryPolicy" or "PutRegistryPolicy" calls where the policy document grants an Allow effect to a wildcard ("*") principal, granting access to all identities. A public ECR repository allows anyone to pull its images, exposing proprietary code and any secrets embedded in image layers; if push actions are granted, an adversary can implant a malicious image that downstream ECS, EKS, or Lambda workloads then run.

### Possible investigation steps

- Identify the actor in "aws.cloudtrail.user_identity.arn" and "aws.cloudtrail.user_identity.type", and review "source.ip" and "user_agent.original" for an unexpected origin or tool.
- Extract the policy from "aws.cloudtrail.request_parameters" and identify the granted actions; pull actions (BatchGetImage, GetDownloadUrlForLayer) expose images, while push actions (PutImage, UploadLayerPart) enable implantation.
- Confirm whether a Deny statement restricts the same access, in which case the alert may be a false positive.
- Determine which repository is affected and whether it contains sensitive images, and correlate with subsequent pull or push activity from external principals.

### False positive analysis

- Public image distribution legitimately uses Principal:"*". Confirm the exposure is intended, the actions are pull-only, and the granting principal is approved.

### Response and remediation

- If the exposure is unauthorized, restore a known-good policy or remove the public statement, and review for any external pulls or pushes since the change.
- Rotate or restrict credentials for the principal if compromise is suspected, and restrict "ecr:SetRepositoryPolicy" and "ecr:PutRegistryPolicy" to trusted administrators.
"""
references = [
    "https://docs.aws.amazon.com/AmazonECR/latest/APIReference/API_SetRepositoryPolicy.html",
    "https://docs.aws.amazon.com/AmazonECR/latest/userguide/repository-policies.html",
]
risk_score = 47
rule_id = "699fdfb9-8430-4dcb-b5a9-da67dae64808"
setup = "This rule requires AWS CloudTrail logs ingested via the Elastic AWS integration. See https://docs.elastic.co/integrations/aws/cloudtrail for setup details."
severity = "medium"
tags = [
    "Domain: Cloud",
    "Data Source: AWS",
    "Data Source: Amazon Web Services",
    "Data Source: AWS ECR",
    "Use Case: Threat Detection",
    "Tactic: Exfiltration",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "esql"

query = '''
FROM logs-aws.cloudtrail-* METADATA _id, _version, _index
| WHERE event.provider == "ecr.amazonaws.com"
  AND event.action IN ("SetRepositoryPolicy", "PutRegistryPolicy")
  AND event.outcome == "success"
  AND (aws.cloudtrail.user_identity.type IS NULL OR aws.cloudtrail.user_identity.type != "AWSService")
  AND aws.cloudtrail.request_parameters RLIKE """.*\"Effect\": *\"Allow\".*"""
  AND (aws.cloudtrail.request_parameters RLIKE """.*\"Principal\": *\"\*\".*"""
       OR aws.cloudtrail.request_parameters RLIKE """.*\"Principal\": *\{ *\"AWS\": *\"\*\".*""")
| KEEP _id, _version, _index, @timestamp, aws.*, cloud.*, event.*, source.*, user.*, user_agent.*
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1537"
name = "Transfer Data to Cloud Account"
reference = "https://attack.mitre.org/techniques/T1537/"


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

[rule.investigation_fields]
field_names = [
    "@timestamp",
    "user.name",
    "user_agent.original",
    "source.ip",
    "source.as.number",
    "source.as.organization.name",
    "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",
]

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

[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 compromised user accounts. This rule looks for use of the IAM AttachUserPolicy API operation
to attach the highly permissive AdministratorAccess AWS managed policy to an existing IAM user.
"""
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 `AttachUserPolicy` API operation to attach the `AdministratorAccess` policy to the target
    user.
    """,
]
from = "now-6m"
index = ["filebeat-*", "logs-aws.cloudtrail-*"]
language = "eql"
license = "Elastic License v2"
name = "AWS IAM AdministratorAccess Policy Attached to User"
note = """## Triage and analysis

### Investigating AWS IAM AdministratorAccess Policy Attached to User

The AWS-managed `AdministratorAccess` policy grants full access to all AWS services and resources.  
When attached to a user, it effectively elevates that user to full administrative privileges.  
An adversary with `iam:AttachUserPolicy` permissions can abuse this operation to escalate privileges or maintain persistence.  
This rule detects `AttachUserPolicy` events where the attached policy name is `AdministratorAccess`.

#### Possible investigation steps

- **Validate intent and context.**  
  Identify the calling user (`aws.cloudtrail.user_identity.arn`) and the target IAM user (`aws.cloudtrail.request_parameters.userName`).  
  Confirm whether this was an intentional administrative action, part of provisioning automation, or a potential privilege escalation.  

- **Review CloudTrail event details.**  
  Check `source.ip`, `user_agent.original`, and `source.geo` fields.  
  Compare to historical login or automation behavior. Unrecognized IPs, non-SDK user agents, or new regions may indicate misuse.  

- **Correlate with related IAM activity.**  
  Search CloudTrail for additional IAM events around the same time (`CreateUser`, `CreateAccessKey`, `AttachGroupPolicy`, `PutUserPolicy`, etc.) that could indicate lateral movement or persistence attempts.  

- **Review the target user’s permissions.**  
  Determine if the target user already had elevated privileges or if this represents a meaningful privilege increase.  
  Check for new API calls from the target user post-attachment, especially `CreateAccessKey`, `UpdateAssumeRolePolicy`, or S3 access attempts.  

- **Investigate associated entities.**  
  Look for other alerts tied to the same caller or target within the past 48 hours to identify potential correlated activity.  

### False positive analysis

- **Legitimate administrative change.**  
  Policy attachments may be expected during provisioning or troubleshooting. Validate through change management records.  
- **Authorized automation.**  
  Some CI/CD pipelines or identity automation systems temporarily attach this policy. Review automation logs and intended IAM behavior.  
- **Delegated admin scenarios.**  
  Verify if the calling user or role is part of a delegated IAM administration group.

### Response and remediation

**Immediate containment**
- Detach the policy. Remove the `AdministratorAccess` policy from the affected IAM user immediately (`aws iam detach-user-policy`).  
- Rotate credentials. Rotate passwords and access keys for both the caller and target users.  
- Restrict IAM permissions. Temporarily remove `iam:AttachUserPolicy` privileges from non-administrative roles during scoping.  
- Enable or confirm MFA for affected accounts.  

**Evidence preservation**
- Export related `AttachUserPolicy` CloudTrail events ±30 minutes from the alert to a secure evidence bucket.  
- Preserve GuardDuty findings and AWS Config snapshots for correlation.  

**Scoping and investigation**
- Search CloudTrail for subsequent use of the affected user’s credentials.  
  Look for newly created keys, S3 access, or changes to IAM trust policies.  
- Review other accounts for similar policy attachment attempts from the same user or IP.  

**Recovery and hardening**
- Reinforce least privilege by granting only role-based admin access instead of direct user-level AdministratorAccess.  
- Implement IAM service control policies (SCPs) to prevent attachment of `AdministratorAccess` except for trusted roles.  
- Enable CloudTrail, GuardDuty, and Security Hub across all regions.  
- Regularly audit IAM policy attachments through AWS Config or CloudFormation drift detection.  

### 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).  
- **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/IAM/latest/APIReference/API_AttachUserPolicy.html",
    "https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AdministratorAccess.html",
    "https://hackingthe.cloud/aws/exploitation/iam_privilege_escalation/",
]
risk_score = 73
rule_id = "9aa4be8d-5828-417d-9f54-7cd304571b24"
severity = "high"
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 == "AttachUserPolicy"
   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",
    "user.target.name",
    "event.outcome",
    "cloud.account.id",
    "cloud.region",
    "aws.cloudtrail.request_parameters",
]

[metadata]
creation_date = "2026/06/18"
integration = ["aws"]
maturity = "production"
updated_date = "2026/06/18"

[rule]
author = ["Elastic"]
description = """
Identifies deletion of imported key material from an AWS KMS customer managed key via DeleteImportedKeyMaterial. Keys
created with an external key material origin (BYOK) rely on key material that the customer imports. Deleting that
material immediately makes the key unusable and renders all data encrypted under it inaccessible, with no recovery
window. Unlike ScheduleKeyDeletion, which enforces a pending deletion period of 7 to 30 days, this action takes effect
instantly, making it an attractive primitive for cloud ransomware and data-destruction attacks. Because this operation
only applies to external-origin keys and is rare in normal operations, its use by an unexpected principal warrants
prompt review.
"""
false_positives = [
    """
    Encryption or platform teams that operate keys with imported key material (BYOK/HYOK) may delete and re-import
    material during key rotation, migration, or decommissioning. Verify the principal in
    "aws.cloudtrail.user_identity.arn", confirm the change aligns with a planned key lifecycle activity, and check
    whether material was re-imported shortly after. Known administration roles and automation can be excluded after
    validation.
    """,
]
from = "now-6m"
index = ["logs-aws.cloudtrail-*"]
language = "kuery"
license = "Elastic License v2"
name = "AWS KMS Imported Key Material Deleted"
note = """## Triage and analysis

### Investigating AWS KMS Imported Key Material Deleted

AWS KMS keys can be created with an external key material origin (BYOK), where the customer imports the cryptographic material rather than having KMS generate it. "DeleteImportedKeyMaterial" removes that material, immediately transitioning the key to a "PendingImport" state where it can no longer encrypt or decrypt. All data protected by the key becomes inaccessible until the exact same material is re-imported. Unlike "ScheduleKeyDeletion", there is no pending window, so the impact is instant and, for an adversary who controls and withholds the original material, effectively irreversible.

Because this action only applies to external-origin keys and is uncommon in normal operations, it should be treated as a high-risk, destructive action when performed unexpectedly. Adversaries may delete imported key material to sabotage recovery, destroy data, or hold encrypted resources for ransom.

### Possible investigation steps

- Identify the actor and authentication context in "aws.cloudtrail.user_identity.arn", "aws.cloudtrail.user_identity.access_key_id", and "aws.cloudtrail.user_identity.type", and review "source.ip" and "user_agent.original" to determine whether the action came from an expected network path or automation platform.
- Identify the affected key from "aws.cloudtrail.resources.arn" or the "keyId" in "aws.cloudtrail.request_parameters", and determine which services and data depend on it (S3, EBS, RDS, Secrets Manager, etc.).
- Determine whether the same material was re-imported shortly after ("ImportKeyMaterial") or whether the key was left unusable.
- Correlate with surrounding activity by the same principal, such as KMS key policy changes, scheduled key deletions, S3 or EBS destructive actions, or credential changes that may indicate a broader sabotage or ransom attempt.

### False positive analysis

- Organizations with BYOK/HYOK requirements may delete and re-import key material during planned rotation, migration, or decommissioning. Confirm the change is expected and exclude known administration roles or automation on "aws.cloudtrail.user_identity.arn" after validation.

### Response and remediation

- If the deletion is unauthorized, re-import the original key material if it is securely retained, and restore access to affected services.
- Treat any encrypted data whose key material cannot be re-imported as potentially unrecoverable, and engage incident response and data owners to assess impact.
- Rotate or restrict credentials for the principal if compromise is suspected, and constrain "kms:DeleteImportedKeyMaterial" and "kms:ImportKeyMaterial" to a small set of trusted administrators.
- Use AWS Organizations SCPs to limit who can manage imported key material in production accounts.

### Additional information

- [DeleteImportedKeyMaterial API](https://docs.aws.amazon.com/kms/latest/APIReference/API_DeleteImportedKeyMaterial.html)
- [Importing key material into AWS KMS keys](https://docs.aws.amazon.com/kms/latest/developerguide/importing-keys.html)
"""
references = [
    "https://docs.aws.amazon.com/kms/latest/APIReference/API_DeleteImportedKeyMaterial.html",
    "https://docs.aws.amazon.com/kms/latest/developerguide/importing-keys.html",
]
risk_score = 47
rule_id = "f6fee40d-8a5e-4cc8-9f73-8688419c6d68"
setup = """This rule requires AWS CloudTrail management events for AWS Backup and ingestion via the Elastic AWS CloudTrail integration. See https://docs.elastic.co/integrations/aws/cloudtrail."""
severity = "medium"
tags = [
    "Domain: Cloud",
    "Data Source: AWS",
    "Data Source: Amazon Web Services",
    "Data Source: AWS KMS",
    "Use Case: Threat Detection",
    "Tactic: Impact",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset: "aws.cloudtrail"
    and event.provider: "kms.amazonaws.com"
    and event.action: "DeleteImportedKeyMaterial"
    and event.outcome: "success"
    and not aws.cloudtrail.user_identity.type: "AWSService"
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1485"
name = "Data Destruction"
reference = "https://attack.mitre.org/techniques/T1485/"

[[rule.threat.technique.subtechnique]]
id = "T1485.001"
name = "Lifecycle-Triggered Deletion"
reference = "https://attack.mitre.org/techniques/T1485/001/"

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

[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",
]

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

[rule]
author = ["Elastic"]
description = """
Detects the first occurrence of a user identity accessing AWS Systems Manager (SSM) SecureString parameters using the GetParameter or GetParameters API actions with credentials in the request parameters. This could indicate that the user is accessing sensitive information. This rule detects when a user accesses a SecureString parameter with the withDecryption parameter set to true. This is a New Terms rule that detects the first occurrence of an AWS identity accessing SecureString parameters with decryption.
"""
false_positives = [
    """
    Users may legitimately access AWS Systems Manager (SSM) parameters using the GetParameter, GetParameters, or DescribeParameters API actions with credentials in the request parameters. Ensure that the user has a legitimate reason to access the parameters and that the credentials are secured.
    """,
]
from = "now-6m"
index = ["filebeat-*", "logs-aws.cloudtrail-*"]
language = "kuery"
license = "Elastic License v2"
name = "AWS Systems Manager SecureString Parameter Request with Decryption Flag"
note = """
## Triage and analysis

### Investigating AWS Systems Manager SecureString Parameter Request with Decryption Flag

This rule detects when an AWS resource accesses SecureString parameters within AWS Systems Manager (SSM) with the decryption flag set to true. SecureStrings are encrypted using a KMS key, and accessing these with decryption can indicate attempts to access sensitive data.

Adversaries may target SecureStrings to retrieve sensitive information such as encryption keys, passwords, and other credentials that are stored securely. Accessing these parameters with decryption enabled is particularly concerning because it implies the adversary is attempting to bypass the encryption to obtain plain text values that can be immediately used or exfiltrated. This behavior might be part of a larger attack strategy aimed at escalating privileges or moving laterally within an environment to access protected data or critical infrastructure.

#### Possible Investigation Steps

- **Review the Access Event**: Identify the specific API call (`GetParameter` or `GetParameters`) that triggered the rule. Examine the `request_parameters` for `withDecryption` set to true and the name of the accessed parameter.
- **Verify User Identity and Access Context**: Check the `aws.cloudtrail.user_identity` details to understand who accessed the parameter and their role within the organization. This includes checking the ARN and access key ID to determine if the access was authorized.
    - **User ID**: Review the `user.name` field to identify the specific user or role that initiated the API call. Note that the ARN associated may be an assumed role and may not directly correspond to a human user.
- **Contextualize with User Behavior**: Assess whether the access pattern fits the user’s normal behavior or job responsibilities. Investigate any out-of-pattern activities around the time of the event.
- **Analyze Geographic and IP Context**: Using the `source.ip` and `source.geo` information, verify if the request came from a trusted location or if there are any anomalies that suggest a compromised account.
- **Inspect Related CloudTrail Events**: Look for other related events in CloudTrail to see if there was unusual activity before or after this event, such as unusual login attempts, changes to permissions, or other API calls that could indicate broader unauthorized actions.

### False Positive Analysis

- **Legitimate Administrative Use**: Verify if the decryption of SecureString parameters is a common practice for the user’s role, particularly if used in automation scripts or deployment processes like those involving Terraform or similar tools.
- **Authorized Access**: Ensure that the user or role has a legitimate reason to access the SecureString parameters and that the access is part of their expected job responsibilities.

### Response and Remediation

- **Immediate Verification**: Contact the user or team responsible for the API call to verify their intent and authorization.
- **Review and Revise Permissions**: If the access was unauthorized, review the permissions assigned to the user or role to ensure they align with the principle of least privilege.
- **Audit Parameter Access Policies**: Ensure that policies governing access to SecureString parameters are strict and audit logs are enabled to track access with decryption.
- **Incident Response**: If suspicious activity is confirmed, follow through with your organization's incident response plan to mitigate any potential security issues.
- **Enhanced Monitoring and Alerting**: Strengthen monitoring rules to detect unusual accesses to SecureString parameters, especially those that involve decryption.

### Additional Information

This rule focuses solely on SecureStrings in AWS Systems Manager (SSM) parameters. SecureStrings are encrypted using an AWS Key Management Service (KMS) key. When a user accesses a SecureString parameter, they can specify whether the parameter should be decrypted. If the user specifies that the parameter should be decrypted, the decrypted value is returned in the response.
"""
references = [
    "https://docs.aws.amazon.com/vsts/latest/userguide/systemsmanager-getparameter.html",
    "https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html",
]
risk_score = 47
rule_id = "fd332492-0bc6-11ef-b5be-f661ea17fbcc"
setup = "This rule requires that AWS CloudTrail logs are ingested into the Elastic Stack. Ensure that the AWS integration is properly configured to collect AWS CloudTrail logs. This rule also requires event logging for AWS Systems Manager (SSM) API actions which can be enabled in CloudTrail's data events settings.\n"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Platform: AWS",
    "Data Source: AWS CloudTrail",
    "Service: AWS SSM",
    "Tactic: Credential Access",
    "Rule Type: New Terms",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "new_terms"

query = '''
data_stream.dataset: aws.cloudtrail
    and event.provider: "ssm.amazonaws.com"
    and event.action: (GetParameters or GetParameter)
    and event.outcome: success
    and aws.cloudtrail.flattened.request_parameters.withDecryption: true
    and not source.address: (
        "cloudformation.amazonaws.com" or
        "servicecatalog.amazonaws.com"
    )
    and not user_agent.original: (
      *Fargate* or
      *Terraform*
    )
'''

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

[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1555"
name = "Credentials from Password Stores"
reference = "https://attack.mitre.org/techniques/T1555/"
[[rule.threat.technique.subtechnique]]
id = "T1555.006"
name = "Cloud Secrets Management Stores"
reference = "https://attack.mitre.org/techniques/T1555/006/"



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

[rule.new_terms]
field = "new_terms_fields"
value = ["cloud.account.id", "user.name"]
[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-5d"

[rule]
description = """
Identifies multiple calls to MapViewOfFile to manipulate the same section adddress and with RWX permissions. This may
indicate an attempt to map a malicious private section at the same address of a legit one.
"""
id = "eab94afc-d8c0-41e6-964f-d396cb0cfbe4"
license = "Elastic License v2"
name = "Evasion via Multiple Memory Section Mapping"
os_list = ["windows"]
reference = ["https://github.com/oldboy21/SWAPPALA"]
version = "1.0.5"

query = '''
sequence by process.entity_id, process.Ext.api.parameters.address with maxspan=1m
 [api where process.Ext.api.name in ("MapViewOfFile", "MapViewOfFile2") and process.Ext.api.parameters.protection == "RWX" and
  process.Ext.api.parameters.size >= 10000 and process.executable != null and
  _arraysearch(process.thread.Ext.call_stack_final_user_module.code_signature, $entry, $entry.trusted == false or $entry.exists == false) and
  process.thread.Ext.call_stack_final_user_module.hash.sha256 != "85a6d48587500f6808c119838293e02b700e99035f8fd8dd0b49cc184ce66b6a"]
 [api where process.Ext.api.name in ("MapViewOfFile", "MapViewOfFile2") and process.Ext.api.parameters.protection == "RWX"]
'''

min_endpoint_version = "8.10.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 = "T1055"
name = "Process Injection"
reference = "https://attack.mitre.org/techniques/T1055/"


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

[internal]
min_endpoint_version = "8.10.0"

[metadata]
creation_date = "2020/07/08"
maturity = "production"
promotion = true
updated_date = "2026/01/22"

[rule]
author = ["Elastic"]
description = """
Generates a detection alert for each external alert written to the configured indices. Enabling this rule allows you to
immediately begin investigating external alerts in the app.
"""
from = "now-2m"
index = [
    "apm-*-transaction*",
    "traces-apm*",
    "auditbeat-*",
    "filebeat-*",
    "logs-*",
    "packetbeat-*",
    "winlogbeat-*",
]
interval = "1m"
language = "kuery"
license = "Elastic License v2"
max_signals = 1000
name = "External Alerts"
risk_score = 47
rule_id = "eb079c62-4481-4d6e-9643-3ca499df7aaa"
rule_name_override = "message"
setup = """## Setup

### Additional notes

For information on troubleshooting the maximum alerts warning please refer to this [guide](https://www.elastic.co/guide/en/security/current/alerts-ui-monitor.html#troubleshoot-max-alerts).
"""
severity = "medium"
tags = ["OS: Windows", "Data Source: APM", "OS: macOS", "OS: Linux", "Resources: Investigation Guide"]
timestamp_override = "event.ingested"
type = "query"

query = '''
event.kind:alert and not event.module:(endgame or endpoint or cloud_defend)
'''
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 External Alerts

External alerts are crucial for identifying potential threats across diverse environments like Windows, macOS, and Linux. These alerts are generated from various sources, excluding specific modules like endpoint or cloud defend, to focus on broader threat landscapes. Adversaries may exploit vulnerabilities in these systems to execute unauthorized actions. The 'External Alerts' detection rule filters and highlights such activities by focusing on alert events, enabling analysts to swiftly investigate and mitigate risks.

### Possible investigation steps

- Review the alert details to identify the specific event.kind:alert that triggered the detection, ensuring it is not associated with the excluded modules (endgame, endpoint, or cloud_defend).
- Examine the source and context of the alert by checking the associated tags, such as 'OS: Windows', 'OS: macOS', or 'OS: Linux', to understand the environment affected.
- Gather additional context by correlating the alert with other logs or events from the same time frame or system to identify any related suspicious activities.
- Assess the risk score and severity level to prioritize the investigation and determine the potential impact on the organization.
- Investigate the origin of the alert by identifying the source IP, user account, or process involved, and check for any known vulnerabilities or exploits associated with them.
- Consult threat intelligence sources to determine if the alert corresponds to any known threat actors or campaigns targeting similar environments.

### False positive analysis

- Alerts from benign third-party applications may trigger false positives. Review and identify these applications, then create exceptions to exclude them from future alerts.
- Routine system updates or patches can generate alerts. Monitor update schedules and create exceptions for known update activities to reduce noise.
- Network monitoring tools might produce alerts due to their scanning activities. Verify these tools and exclude their activities if deemed non-threatening.
- Alerts from internal security testing or penetration testing exercises can be mistaken for threats. Coordinate with security teams to whitelist these activities during scheduled tests.
- Certain administrative scripts or automation tasks may trigger alerts. Evaluate these scripts and exclude them if they are part of regular operations and pose no risk.

### Response and remediation

- Isolate affected systems immediately to prevent further unauthorized actions and contain the threat.
- Conduct a thorough review of the alert details to identify any specific vulnerabilities or exploits used by the adversary.
- Apply relevant patches or updates to the affected systems to remediate any identified vulnerabilities.
- Restore systems from a known good backup if unauthorized changes or actions have been detected.
- Monitor network traffic and system logs closely for any signs of further suspicious activity or attempts to exploit similar vulnerabilities.
- Escalate the incident to the appropriate security team or management if the threat appears to be part of a larger attack campaign or if additional resources are needed for remediation.
- Enhance detection capabilities by updating security tools and configurations to better identify similar threats in the future."""


[[rule.risk_score_mapping]]
field = "event.risk_score"
operator = "equals"
value = ""

[[rule.severity_mapping]]
field = "event.severity"
operator = "equals"
severity = "low"
value = "21"

[[rule.severity_mapping]]
field = "event.severity"
operator = "equals"
severity = "medium"
value = "47"

[[rule.severity_mapping]]
field = "event.severity"
operator = "equals"
severity = "high"
value = "73"

[[rule.severity_mapping]]
field = "event.severity"
operator = "equals"
severity = "critical"
value = "99"

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

[rule]
author = ["Elastic"]
building_block_type = "default"
description = """
This rule identifies the execution of commands that can be used to delete files and directories. Adversaries may delete
files and directories on a host system, such as logs, browser history, or malware.
"""
from = "now-119m"
index = ["logs-endpoint.events.process-*"]
interval = "60m"
language = "eql"
license = "Elastic License v2"
name = "File or Directory Deletion Command"
risk_score = 21
rule_id = "5919988c-29e1-4908-83aa-1f087a838f63"
severity = "low"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Defense Evasion",
    "Rule Type: BBR",
    "Data Source: Elastic Defend",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
process where host.os.type == "windows" and event.type == "start" and 
(
  ((process.name : "rundll32.exe" or ?process.pe.original_file_name : "RUNDLL32.EXE") and process.args : "*InetCpl.cpl,Clear*") or 
  ((process.name : "reg.exe" or ?process.pe.original_file_name : "reg.exe") and process.args : "delete") or 
  (
    (process.name : "cmd.exe" or ?process.pe.original_file_name : "Cmd.Exe") and
    process.args : ("*rmdir*", "*rm *", "rm", "*del *", "del", "*erase *", "erase") and
    not process.args : (
          "*\\AppData\\Local\\Microsoft\\OneDrive\\*",
          "*\\AppData\\Local\\Temp\\DockerDesktop\\*",
          "*\\AppData\\Local\\Temp\\Report.*",
          "*\\AppData\\Local\\Temp\\*.PackageExtraction"
    )
  ) or
  ((process.name : "powershell.exe" or ?process.pe.original_file_name : "PowerShell.EXE") and
    process.args : ("*rmdir", "rm", "rd", "*Remove-Item*", "del", "*]::Delete(*"))
) and not user.id : "S-1-5-18"
'''


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

[[rule.threat.technique]]
id = "T1070"
name = "Indicator Removal"
reference = "https://attack.mitre.org/techniques/T1070/"

[[rule.threat.technique.subtechnique]]
id = "T1070.004"
name = "File Deletion"
reference = "https://attack.mitre.org/techniques/T1070/004/"

[[rule.threat.technique]]
id = "T1112"
name = "Modify Registry"
reference = "https://attack.mitre.org/techniques/T1112/"

[[rule.threat.technique]]
id = "T1218"
name = "System Binary Proxy Execution"
reference = "https://attack.mitre.org/techniques/T1218/"

[[rule.threat.technique.subtechnique]]
id = "T1218.011"
name = "Rundll32"
reference = "https://attack.mitre.org/techniques/T1218/011/"

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

[metadata]
creation_date = "2026/02/23"
integration = ["endpoint"]
maturity = "production"
updated_date = "2026/03/24"

[rule]
author = ["Elastic"]
description = """
Detects the first time a Python process spawns a shell on a given host. Malicious Python scripts, compromised
dependencies, or model file deserialization can result in shell spawns that would not occur during normal workflows.
Since legitimate Python processes rarely shell out to interactive shells, a first occurrence of this behavior on a
host is a strong signal of potential compromise.
"""
from = "now-9m"
index = ["logs-endpoint.events.process-*"]
language = "kuery"
license = "Elastic License v2"
name = "First Time Python Spawned a Shell on Host"
note = """## Triage and analysis

### Investigating First Time Python Spawned a Shell on Host

Attackers who achieve Python code execution — whether through malicious scripts, compromised dependencies, or model file deserialization (e.g., pickle/PyTorch `__reduce__`) — often spawn shell processes to perform reconnaissance, credential theft, persistence, or reverse shell activity. Since legitimate Python workflows rarely shell out with `-c`, a first occurrence is highly suspicious.

This rule uses the New Terms rule type to detect the first occurrence of a Python process spawning a shell with the `-c` flag on a given host within a 7-day window. This approach reduces false positives from recurring legitimate Python workflows while surfacing novel, potentially malicious activity.

### Possible investigation steps

- Examine the parent Python process command line to identify the script or command that triggered the shell spawn.
- Determine if the Python process was loading a model file (look for `torch.load`, `pickle.load`), running a standalone script, or executing via a compromised dependency.
- Review the shell command arguments to assess intent (credential access, reverse shell, persistence, reconnaissance).
- Inspect the full process tree to determine if the Python process was launched from an interactive session, a cron job, or an automated pipeline.
- Investigate the origin of any recently downloaded scripts, packages, or model files on the host.
- Correlate with other hosts in the environment to determine if the same behavior is occurring elsewhere, which may indicate a supply chain compromise.

### False positive analysis

- Development environments where Python scripts legitimately shell out for system tasks (e.g., build scripts, CI/CD runners) may trigger this rule on first occurrence. Consider excluding known CI/CD working directories or build automation paths.
- Package installation via pip or conda may spawn shells during post-install scripts. These are excluded by the query filter.
- Jupyter notebooks executing system commands via `!` or `subprocess` may trigger this rule in data science environments.

### Response and remediation

- Investigate the shell command that was executed and assess its impact (credential access, persistence, data exfiltration).
- If a malicious file is confirmed, quarantine it and identify its source (PyPI, Hugging Face, shared drive, email attachment).
- Scan other hosts that may have received the same file.
- Review and rotate any credentials that may have been accessed.
- Consider implementing `weights_only=True` enforcement for PyTorch model loading across the environment.
"""
references = [
    "https://blog.trailofbits.com/2024/06/11/exploiting-ml-models-with-pickle-file-attacks-part-1/",
    "https://github.com/trailofbits/fickling",
    "https://5stars217.github.io/2024-03-04-what-enables-malicious-models/",
]
risk_score = 47
rule_id = "92a36c98-b24a-4bf7-aac7-1eac71fa39cf"
severity = "medium"
tags = [
    "Domain: Endpoint",
    "OS: macOS",
    "Use Case: Threat Detection",
    "Tactic: Execution",
    "Data Source: Elastic Defend",
    "Resources: Investigation Guide",
    "Domain: LLM",
]
timestamp_override = "event.ingested"
type = "new_terms"
query = '''
event.category:process and host.os.type:macos and event.type:start and event.action:exec and
process.parent.name:python* and
process.name:(bash or dash or sh or tcsh or csh or zsh or ksh or fish) and process.args:"-c" and
not process.command_line:(*pip* or *conda* or *brew* or *jupyter*)
'''

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

[[rule.threat.technique]]
id = "T1059"
name = "Command and Scripting Interpreter"
reference = "https://attack.mitre.org/techniques/T1059/"

[[rule.threat.technique.subtechnique]]
id = "T1059.004"
name = "Unix Shell"
reference = "https://attack.mitre.org/techniques/T1059/004/"

[[rule.threat.technique.subtechnique]]
id = "T1059.006"
name = "Python"
reference = "https://attack.mitre.org/techniques/T1059/006/"

[rule.threat.tactic]
id = "TA0002"
name = "Execution"
reference = "https://attack.mitre.org/tactics/TA0002/"
[rule.new_terms]
field = "new_terms_fields"
value = ["host.id", "process.parent.executable"]
[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-7d"

[metadata]
creation_date = "2026/07/10"
integration = ["gcp"]
maturity = "production"
updated_date = "2026/07/10"

[rule]
author = ["Elastic"]
description = """
Detects creation or approval of a GKE CertificateSigningRequest (CSR) by a non-system identity. This is a breadth
baseline rule for human or custom automation CSR activity on GKE. Attackers with cluster access can submit and approve
CSRs to obtain long-lived client certificates that survive token revocation and RBAC changes. Use companion rules to
evaluate signer choice, requested identity, and self-approval behavior.
"""
false_positives = [
    """
    Approved certificate workflows (for example cert-manager, internal PKI rotation, or node bootstrap) may create or
    update CSRs from identities not in the exclusion list if they run under a custom service account. Baseline
    automation that legitimately approves CSRs and tune exclusions for those principals.
    """,
]
from = "now-6m"
index = ["logs-gcp.audit-*"]
language = "kuery"
license = "Elastic License v2"
name = "GKE Client Certificate Signing Request Created or Approved"
note = """## Triage and analysis

### Investigating GKE Client Certificate Signing Request Created or Approved

Identify the actor (`client.user.email`), `source.ip`, and `user_agent.original`. Confirm whether the principal is
expected to create or approve CSRs. Review `event.action`, `gcp.audit.resource_name`, and when audit level captures
request bodies, the CSR spec in `gcp.audit.request` (requested signer, usages, and requested identity / Common Name).

### Extracting the Certificate Common Name

For create events, `gcp.audit.request.spec.request` may hold the base64-encoded PEM certificate signing request.
On GKE this is base64 of the full PEM CSR. Decode and inspect the subject for high-risk Common Names such as
`system:masters`, `system:kube-controller-manager`, and `system:admin`. The companion rule "GKE Certificate Signing
Request Privileged Identity Requested" decodes the CSR body and matches those identities automatically.

```bash
# Full decoded PEM block
echo "<gcp.audit.request.spec.request>" | base64 -d

# Parsed CSR details (subject, key type/size, extensions, signature)
echo "<gcp.audit.request.spec.request>" | base64 -d | openssl req -noout -text

# Subject only
echo "<gcp.audit.request.spec.request>" | base64 -d | openssl req -noout -subject
```

Priority CNs that usually indicate privilege escalation intent:

- `system:masters` (cluster-admin group)
- `system:kube-controller-manager` (broad control-plane-style access, including secrets and token minting)
- `system:kube-scheduler` (scheduling across the cluster)
- `system:kube-proxy` (node/network-adjacent access)
- Any CN that matches an existing ClusterRoleBinding subject name

### Possible investigation steps

- Compare the CSR name and extracted CN against approved PKI or bootstrap processes.
- Determine whether the same identity both created and approved the CSR in a short window (`approval.update`, `update`,
  or `patch`), which matches self-approval abuse.
- Review `gcp.audit.resource_name` and subsequent authentication or API activity from unusual networks.
- Correlate with RBAC changes, secret access, or TokenRequest activity that preceded CSR activity.

### False positive analysis

- Admins testing CSR workflows with kubectl are common in lab clusters. Baseline expected operators and tune exclusions.
- cert-manager or custom PKI automation outside the exclusion list may create or approve CSRs during normal rotation.

### Related rules

- GKE Certificate Signing Request API Client Signer Requested - 1e344fba-a2f7-462b-aaec-d6c8f80d5a28
- GKE Certificate Signing Request Privileged Identity Requested - 4159bec9-76ad-4cdc-a797-4a8572073bbe
- GKE Certificate Signing Request Self-Approved - e155e658-3dcd-4d27-a4e5-1d8da6704b0e

### Response and remediation

- If malicious, deny further approval, delete or deny the CSR per incident policy, revoke or rotate cluster signing
  trust if the CA or signer was abused, and invalidate issued credentials.
- Remove excessive RBAC that allows `certificatesigningrequests` create/update/patch or approval for untrusted
  identities; enforce signer restrictions and approved issuers where supported.

"""
setup = "The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule."
references = [
    "https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/",
    "https://kubernetes.io/docs/concepts/security/rbac-good-practices/",
    "https://stratus-red-team.cloud/attack-techniques/kubernetes/k8s.persistence.create-client-certificate/",
    "https://raesene.github.io/blog/2022/12/21/Kubernetes-persistence-with-Tocan-and-Teisteanas/",
    "https://www.aquasec.com/blog/kubernetes-rbac-privilige-escalation/",
]
risk_score = 47
rule_id = "ec67ab57-945a-4edb-84f8-1d7a51f46544"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Domain: Kubernetes",
    "Data Source: GCP",
    "Data Source: GCP Audit Logs",
    "Data Source: Google Cloud Platform",
    "Use Case: Threat Detection",
    "Tactic: Persistence",
    "Tactic: Privilege Escalation",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:"gcp.audit" and service.name:"k8s.io" and event.outcome:"success" and
event.action:(
  "io.k8s.certificates.v1.certificatesigningrequests.create" or
  "io.k8s.certificates.v1.certificatesigningrequests.approval.update"
) and not client.user.email:(
  "system:gcp-controller-manager" or
  "system:kube-controller-manager" or
  "system:serviceaccount:kube-system:certificate-controller"
) and not (
  event.action:"io.k8s.certificates.v1.certificatesigningrequests.create" and
  client.user.email:(
    "kubelet-bootstrap" or
    "kubelet-nodepool-bootstrap" or
    system\:node\:*
  )
)
'''

[[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 = "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.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.investigation_fields]
field_names = [
    "@timestamp",
    "client.user.email",
    "source.ip",
    "user_agent.original",
    "event.action",
    "event.outcome",
    "gcp.audit.resource_name",
    "gcp.audit.request",
    "gcp.audit.response",
    "data_stream.namespace",
]

[metadata]
creation_date = "2020/11/17"
integration = ["google_workspace"]
maturity = "production"
updated_date = "2026/05/29"

[rule]
author = ["Elastic"]
description = """
Assigning an administrative role to a user or group grants elevated privileges within Google Workspace, including
access to the Google Admin console and the ability to manage domain resources and applications. Adversaries may assign
administrator roles to an existing account or a newly created account/group to establish persistence, facilitate
privilege escalation, and enable follow-on actions across the tenant. In particular, users with Super Admin privileges
can bypass single sign-on (SSO) if it is enabled in Google Workspace.
"""
false_positives = [
    """
    Google Workspace admin role assignments may be modified by system administrators. Verify that the configuration
    change was expected. Exceptions can be added to this rule to filter expected behavior.
    """,
]
from = "now-130m"
index = ["filebeat-*", "logs-google_workspace.admin-*"]
interval = "10m"
language = "kuery"
license = "Elastic License v2"
name = "Google Workspace Admin Role Assigned to a User or Group"
note = """## Triage and analysis

### Investigating Google Workspace Admin Role Assigned to a User or Group

Google Workspace roles allow administrators to assign specific permissions to users or groups. Because these roles can
grant broad administrative control over identity, devices, and security settings, role assignments should follow the
principle of least privilege (PoLP) and be carefully controlled. Threat actors may assign high-privilege roles (for
example, Super Admin or other *_ADMIN_ROLE roles) to establish persistence, expand access, and perform follow-on actions
such as creating OAuth tokens, modifying security controls, changing mail routing, or altering SSO settings. Unexpected
admin privileges can also lead to operational impact if changes are made unintentionally.

This rule identifies when a Google Workspace administrative role is assigned to a user or a group.

### Possible investigation steps

- Identify the initiating (actor) account that performed the change by reviewing `user.email` or `user.name`, and note the `source.ip` and `event.ingested` timestamps.
- Identify the target principal that received the role assignment:
  - For assignments, review `user.target.email` and `user.target.name`.
  - For group assignments, determine which users are members of that group at the time of assignment.
- Identify the role assigned by reviewing `google_workspace.admin.role.name`.
- Determine whether the assignment is expected and authorized:
  - Validate there is an approved change request/ticket and that the actor account is authorized to grant this level of access.
  - If the role is high privilege (for example, Super Admin), treat as urgent until proven benign.
- Scope for additional role assignments by searching for `event.action: ASSIGN_ROLE` over an expanded time window and filtering on:
  - The same `user.email` (actor) to find other role changes performed by the same account.
  - The same `google_workspace.admin.role.name` to identify other principals granted the role.
  - The same target (`user.target.email`) to identify multiple roles granted to the same principal.
- Evaluate whether the target user (or group members) performed suspicious activity after receiving the role:
  - Review the last 48 hours of admin/audit events for security control changes, user or group changes, and Gmail configuration changes.
  - If available, correlate with sign-in events for unusual geolocation, impossible travel, unfamiliar devices, or sign-ins from the `source.ip`.
- Determine whether the target user account was recently created by searching for `event.action: CREATE_USER` and filtering for `user.target.email`.

### False positive analysis

- Verify the role assignment aligns with approved administrative duties, an authorized change window, and the organization’s access governance process.
- Confirm the initiating admin account is legitimate and not performing role assignments from unusual IPs, devices, or locations.
- For group assignments, verify the group is intended for administrative delegation and validate recent membership changes that could expand who effectively received the privilege.

### Response and remediation

- Initiate the incident response process based on triage findings.
- If the assignment is not clearly authorized, remove the role assignment from the user/group and/or place the target account(s) under administrative restriction while the investigation proceeds.
- For suspected compromise of the initiating admin account:
  - Reset credentials, revoke active sessions, enforce MFA re-enrollment, and review delegation/OAuth grants for persistence.
  - Validate recovery email/phone settings and account security posture.
- Review the permissions assigned to the implicated user/group to ensure PoLP is being followed, and consider replacing broad roles with narrower delegated roles where feasible.
- Implement security best practices [outlined](https://support.google.com/a/answer/7587183) by Google.
- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector.
- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).

## Setup

The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.

### Important Information Regarding Google Workspace Event Lag Times
- As per Google's documentation, Google Workspace administrators may observe lag times ranging from minutes up to 3 days between the time of an event's occurrence and the event being visible in the Google Workspace admin/audit logs.
- This rule is configured to run every 10 minutes with a lookback time of 130 minutes.
- To reduce the risk of false negatives, consider reducing the interval that the Google Workspace (formerly G Suite) Filebeat module polls Google's reporting API for new events.
- By default, `var.interval` is set to 2 hours (2h). Consider changing this interval to a lower value, such as 10 minutes (10m).
- See the following references for further information:
  - https://support.google.com/a/answer/7061566
  - https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-google_workspace.html"""
references = [
    "https://support.google.com/a/answer/172176?hl=en",
    "https://www.elastic.co/security-labs/google-workspace-attack-surface-part-one",
    "https://www.elastic.co/security-labs/google-workspace-attack-surface-part-two"
]
risk_score = 73
rule_id = "68994a6c-c7ba-4e82-b476-26a26877adf6"
severity = "high"
tags = [
    "Domain: Cloud",
    "Data Source: Google Workspace",
    "Use Case: Identity and Access Audit",
    "Tactic: Persistence",
    "Tactic: Privilege Escalation",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:"google_workspace.admin" and event.action:"ASSIGN_ROLE"
  and google_workspace.admin.role.name : *_ADMIN_ROLE
'''

[rule.investigation_fields]
field_names = [
    "source.ip",
    "user.name",
    "user.email",
    "event.action",
    "google_workspace.admin.role.name",
    "user.target.name",
    "user.target.email",
]

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

[metadata]
creation_date = "2023/03/21"
integration = ["google_workspace"]
maturity = "production"
updated_date = "2026/06/02"

[rule]
author = ["Elastic"]
description = """
Detects when an anonymous user views, copies, or downloads a private key or credential file from Google Drive via an
anyone-with-the-link share. Adversaries who obtain or create open Drive links can harvest encryption keys and secrets
stored in user drives, then use those materials to decrypt data, authenticate to services, or expand access beyond the
initial compromise.
"""
false_positives = [
    """
    A user may generate a shared access link to encryption key files to share with others. It is unlikely that the
    intended recipient is an external or anonymous user.
    """,
]
from = "now-130m"
index = ["filebeat-*", "logs-google_workspace.drive-*"]
interval = "10m"
language = "eql"
license = "Elastic License v2"
name = "Google Workspace Drive Encryption Key(s) Accessed from Anonymous User"
note = """## Triage and analysis

### Investigating Google Workspace Drive Encryption Key(s) Accessed from Anonymous User

Threat actors and opportunistic scanners frequently abuse Google Drive links set to "Anyone with the link" to access
sensitive files without authenticating. Private keys, keystores, and token files stored in user drives are high-value
targets. Possession of these files can enable decryption of protected data, signing or impersonation, and lateral
movement into systems that trust the exposed material.

This rule uses EQL to detect `view`, `copy`, or `download` activity in `google_workspace.drive` where
`google_workspace.drive.visibility` is `people_with_link`, `source.user.email` is empty (anonymous access), and
`file.extension` matches common key or credential file types.

### Possible investigation steps

- Identify the file accessed by reviewing `file.name` and `google_workspace.drive.file.type`, and note `event.action` (`view`, `copy`, or `download`) and `event.ingested`.
- Identify the file owner by reviewing `google_workspace.drive.file.owner.email` and determine whether that user should store key material in Drive.
- Review `source.user.id` and any available IP or user-agent context in the raw event to characterize the anonymous accessor.
- Confirm sharing posture in Google Drive:
  - Open the file in Drive as an administrator or the owner and review Share settings.
  - Verify whether access is "Anyone with the link" and whether the link was intentionally published or may have been exposed after account compromise.
- Search Kibana for related Drive activity for the same file or owner:
  ```
  data_stream.dataset: "google_workspace.drive" and google_workspace.drive.file.owner.email: "<OWNER_EMAIL>" and file.name: "<FILE_NAME>"
  ```
  - Look for earlier `change_user_access`, `change_document_visibility`, or `rename` events that may indicate when the link was opened.
  - Search for other key-like files owned by the same user with `people_with_link` visibility.
- Determine blast radius — identify which systems, applications, or cloud resources the key protects (VPN, TLS, code signing, service accounts, encrypted archives).
- Contact the file owner and security stakeholders to confirm whether anonymous access was expected (for example, a documented external audit). Treat unexpected access as high priority.

### False positive analysis

- Legitimate use of link-based sharing for key files is rare; validate business justification before closing as benign.
- Automated scanners or DLP tools may touch public links — correlate with known security tooling and owner intent.

### Response and remediation

- Initiate the incident response process based on triage findings.
- Revoke the open link or restrict sharing to specific users; move key material out of broadly link-shared locations.
- If access is unauthorized, rotate or replace the exposed keys and review dependent systems for abuse.
- Review the file owner's account for signs of compromise (unusual logins, OAuth grants, or mass sharing changes).

## Setup

The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.

### Important Information Regarding Google Workspace Event Lag Times
- As per Google's documentation, Google Workspace administrators may observe lag times ranging from minutes up to 3 days between the time of an event's occurrence and the event being visible in the Google Workspace admin/audit logs.
- This rule is configured to run every 10 minutes with a lookback time of 130 minutes.
- To reduce the risk of false negatives, consider reducing the interval that the Google Workspace (formerly G Suite) Filebeat module polls Google's reporting API for new events.
- By default, `var.interval` is set to 2 hours (2h). Consider changing this interval to a lower value, such as 10 minutes (10m).
- See the following references for further information:
  - https://support.google.com/a/answer/7061566
  - https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-google_workspace.html"""
references = [
    "https://support.google.com/drive/answer/2494822",
    "https://www.elastic.co/security-labs/google-workspace-attack-surface-part-one",
    "https://www.elastic.co/security-labs/google-workspace-attack-surface-part-two"
]
risk_score = 73
rule_id = "980b70a0-c820-11ed-8799-f661ea17fbcc"
severity = "high"
tags = [
    "Domain: Cloud",
    "Data Source: Google Workspace",
    "Use Case: Configuration Audit",
    "Tactic: Credential Access",
    "Tactic: Collection",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
file where data_stream.dataset == "google_workspace.drive" and event.action : ("copy", "view", "download") and
    google_workspace.drive.visibility: "people_with_link" and source.user.email == "" and
    file.extension: (
        "token","assig", "pssc", "keystore", "pub", "pgp.asc", "ps1xml", "pem", "gpg.sig", "der", "key",
        "p7r", "p12", "asc", "jks", "p7b", "signature", "gpg", "pgp.sig", "sst", "pgp", "gpgz", "pfx", "crt",
        "p8", "sig", "pkcs7", "jceks", "pkcs8", "psc1", "p7c", "csr", "cer", "spc", "ps2xml")
'''

[rule.investigation_fields]
field_names = [
    "source.user.id",
    "event.action",
    "file.name",
    "google_workspace.drive.file.type",
    "google_workspace.drive.file.owner.email",
]

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

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

[[rule.threat.technique.subtechnique]]
id = "T1552.004"
name = "Private Keys"
reference = "https://attack.mitre.org/techniques/T1552/004/"

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

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

[[rule.threat.technique]]
id = "T1530"
name = "Data from Cloud Storage"
reference = "https://attack.mitre.org/techniques/T1530/"

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

[rule]
description = """
Identifies the use of a signed utility that takes a remote URL as a process argument or no arguments at all followed by
the creation of an executable file in the INetCache Folder. Adversaries may use trusted utilities to download extra
payloads to avoid ingress tool transfer restrictions.
"""
id = "bd4d88c1-466e-4591-9c81-f2d257dbc9db"
license = "Elastic License v2"
name = "Ingress Tool Transfer via INET Cache"
os_list = ["windows"]
reference = [
    "https://attack.mitre.org/techniques/T1105/",
    "https://www.elastic.co/security-labs/unmasking-financial-services-intrusion-ref0657",
]
version = "1.0.7"

query = '''
sequence by process.entity_id with maxspan=1m
 [process where event.action == "start" and not user.id : ("S-1-5-18", "S-1-5-19", "S-1-5-20") and 
  process.code_signature.trusted == true and process.code_signature.subject_name : "Microsoft*" and 
  (process.command_line : "*http*" or (process.executable : "?:\\Windows\\*" and process.args_count <= 1)) and 
  not process.executable : ("?:\\Program Files\\*.exe", "?:\\Program Files (x86)\\*.exe") and
  not (process.name : "rundll32.exe" and process.args : "C:\\Windows\\System32\\rundll32.exe  C:\\Windows\\System32\\LogiLDA.dll,LogiFetch")]
 [file where event.action!= "deletion" and file.path : "?:\\Users\\*\\AppData\\Local\\Microsoft\\Windows\\INetCache\\*" and 
  (file.Ext.header_bytes : "4d5a*" or 
   file.extension : ("exe", "pif", "scr", "dll", "cpl", "bat", "cmd", "hta"))]
'''

min_endpoint_version = "8.0.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 = "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.0.0"

[metadata]
creation_date = "2025/04/30"
integration = ["o365"]
maturity = "production"
updated_date = "2026/04/10"

[rule]
author = ["Elastic"]
description = """
Identifies attempts to register a new device in Microsoft Entra ID after OAuth authentication with authorization code
grant. Adversaries may use OAuth phishing techniques to obtain an OAuth authorization code, which can then be exchanged
for access and refresh tokens. This rule detects a sequence of events where a user principal authenticates via OAuth,
followed by a device registration event, indicating potential misuse of the OAuth flow to establish persistence or
access resources.
"""
from = "now-30m"
index = ["filebeat-*", "logs-o365.audit-*"]
interval = "15m"
language = "eql"
license = "Elastic License v2"
name = "M365 Identity OAuth Flow by User Sign-in to Device Registration"
note = """## Triage and analysis

### Investigating M365 Identity OAuth Flow by User Sign-in to Device Registration

### Possible investigation steps
- Review the two UserLoggedIn logs to confirm that they come from different source.ip values and are associated to the same account.
- Verify all events associated to the source.ip of the the second event in the sequence.
- Investiguate the details of the new device that was added by reviewing the o365.audit.ModifiedProperties.Device_DisplayName.NewValue attribute.
- Investigate the user account associated with the successful sign-in to determine if this activity aligns with expected behavior or if it appears suspicious.
- Review the history of sign-ins for the user to identify any patterns or unusual access times that could suggest unauthorized access.
- Assess the device from which the sign-in was attempted to ensure it is a recognized and authorized device for the user.

### False positive analysis
- Both authentcation events of the sequence are originatng from the same source.ip.
- User using multiple devices and attempted to add a new device post an OAuth code authentication.

### Response and remediation
- Immediately revoke the compromised Primary Refresh Tokens (PRTs) to prevent further unauthorized access. This can be done through the Azure portal by navigating to the user's account and invalidating all active sessions.
- Enforce a password reset for the affected user accounts to ensure that any credentials potentially compromised during the attack are no longer valid.
- Implement additional Conditional Access policies that require device compliance checks and restrict access to trusted locations or devices only, to mitigate the risk of future PRT abuse.
- Conduct a thorough review of the affected accounts' recent activity logs to identify any unauthorized actions or data access that may have occurred during the compromise.
- Escalate the incident to the security operations team for further investigation and to determine if there are any broader implications or additional compromised accounts.
- Enhance monitoring by configuring alerts for unusual sign-in patterns or device code authentication attempts from unexpected locations or devices, to improve early detection of similar threats.
- Coordinate with the incident response team to perform a post-incident analysis and update the incident response plan with lessons learned from this event."""
references = [
    "https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth2-auth-code-flow",
    "https://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/",
]
risk_score = 73
rule_id = "fcd2e4be-6ec4-482f-9222-6245367cd738"
severity = "high"
tags = [
    "Domain: Cloud",
    "Domain: SaaS",
    "Data Source: Microsoft 365",
    "Data Source: Microsoft 365 Audit Logs",
    "Use Case: Identity and Access Audit",
    "Tactic: Credential Access",
    "Resources: Investigation Guide",

]
timestamp_override = "event.ingested"
type = "eql"

query = '''
sequence by related.user with maxspan=30m
[authentication where event.action == "UserLoggedIn" and
 o365.audit.ExtendedProperties.RequestType == "OAuth2:Authorize" and o365.audit.ExtendedProperties.ResultStatusDetail == "Redirect" and
 o365.audit.UserType: ("0", "2", "3", "10")] // victim source.ip
[authentication where event.action == "UserLoggedIn" and
 o365.audit.ExtendedProperties.RequestType == "OAuth2:Token" and o365.audit.ExtendedProperties.ResultStatusDetail == "Success"] // attacker source.ip to convert oauth code to token
[web where data_stream.dataset == "o365.audit" and event.action == "Add registered users to device."] // user.name is captured in related.user
'''


[[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.tactic]
id = "TA0006"
name = "Credential Access"
reference = "https://attack.mitre.org/tactics/TA0006/"

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

[[rule.threat.technique.subtechnique]]
id = "T1566.002"
name = "Spearphishing Link"
reference = "https://attack.mitre.org/techniques/T1566/002/"

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

[metadata]
creation_date = "2026/08/04"
integration = ["system", "windows"]
maturity = "production"
updated_date = "2026/08/10"

[rule]
author = ["Elastic"]
description = """
Identifies a successful RC4-HMAC Kerberos service ticket request for a requester and service pair that has not been
observed during the previous 7 days. A newly observed requester-to-service relationship involving an RC4-encrypted
ticket may indicate Kerberoasting.
"""
false_positives = [
    """
    First-time or infrequent access to legacy services, cross-platform integrations, and inter-domain trust activity may
    legitimately establish a new requester-to-service relationship using RC4 encryption.
    """,
]
from = "now-9m"
index = ["winlogbeat-*", "logs-system.security*", "logs-windows.forwarded*"]
language = "kuery"
license = "Elastic License v2"
name = "Newly Observed RC4 Kerberos Service Ticket Request"
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 Newly Observed RC4 Kerberos Service Ticket Request

This alert flags a successful Windows Kerberos service ticket request that used legacy RC4 encryption for a requester-to-service pairing not seen in the last week. It matters because RC4 tickets are easier for attackers to crack offline, and a new pairing can reveal account targeting rather than normal application behavior. A common pattern is an intruder using a low-privileged domain account to request RC4 tickets for SPN-backed service accounts, then extracting password hashes for Kerberoasting.

### Possible investigation steps

- Validate whether the requester, source host, and service account relationship aligns with a known application change, scheduled task, or newly deployed system, because legitimate first-seen pairings often coincide with onboarding or configuration work.
- Review recent authentication activity for the requester across domain controllers for bursts of service ticket requests to multiple SPNs, especially privileged or human-managed service accounts, which is a strong Kerberoasting pattern.
- Pivot on the requesting host and user for adjacent suspicious behavior such as interactive logons from unusual systems, PowerShell or script execution, remote administration activity, credential dumping alerts, or other Active Directory enumeration in the same timeframe.
- Examine the targeted service account’s privilege level, password age, SPN exposure, delegation settings, and whether it still permits RC4, then prioritize escalation if the account is highly privileged, old, or tied to critical services.
- If the activity is not readily explained, contain the requester and source system as appropriate and rotate the service account credentials while planning to disable RC4 support and enforce stronger Kerberos encryption for affected accounts.

### False positive analysis

- A newly deployed or reconfigured Windows service, scheduled task, or application host can create a first-seen requester-to-service pairing against a legacy SPN that still uses RC4, so verify recent change activity and confirm the requester, source host, and service account match the expected business function.
- An infrequently run maintenance or batch process may legitimately request an RC4 service ticket after more than seven days of inactivity, so confirm the event time aligns with its normal schedule and review adjacent 4769 activity to ensure the account is only accessing its usual limited set of services.

### Response and remediation

- Isolate the requesting host and any other systems used by the compromised account from the network, block remote administration access, and preserve volatile and disk evidence before rebooting or rebuilding them.
- Disable the compromised requester account and the targeted service account, rotate passwords or keys for every exposed SPN-backed service they can access, and force logoff or ticket purge so previously issued Kerberos tickets cannot be reused.
- Remove attacker persistence by reviewing and deleting unauthorized scheduled tasks, services, startup items, WMI event subscriptions, remote access tools, Run key entries, and any newly granted local or domain group memberships tied to the affected identities or hosts.
- Restore affected endpoints and servers to a known-good state by reimaging compromised systems or rolling back unauthorized changes, then verify business applications start cleanly with the newly rotated service credentials.
- Escalate to incident response immediately if the targeted service account is privileged, tied to domain controllers or other Tier 0 systems, or if you also find credential dumping, lateral movement, multiple unusual SPN requests, or forged-ticket activity.
- Harden the environment by disabling RC4 where legacy dependencies permit it, enforcing AES-only Kerberos encryption on service accounts, migrating eligible services to gMSAs, reducing excessive service account privileges and SPNs, and adding detections for unusual service ticket bursts and new requester-to-service relationships.
"""
references = [
    "https://learn.microsoft.com/en-us/windows-server/security/kerberos/detect-remediate-rc4-kerberos",
]
risk_score = 47
rule_id = "57bc9e8d-9054-472c-9752-4aa91dc4cd49"
setup = """## Setup

Audit Kerberos Service Ticket Operations must be enabled to generate the events used by this rule.
Setup instructions: https://ela.st/audit-kerberos-service-ticket-operations
"""
severity = "medium"
tags = [
    "Domain: Identity",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Credential Access",
    "Use Case: Active Directory Monitoring",
    "Data Source: Active Directory",
    "Data Source: Windows Security Event Logs",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "new_terms"

query = '''
host.os.type:windows and event.category:authentication and event.code:4769 and
  winlog.event_data.Status:0x0 and winlog.event_data.TicketEncryptionType:0x17 and
  winlog.event_data.TargetUserName:* and
  winlog.event_data.ServiceName:(* and not (krbtgt or *$)) and
  not (winlog.event_data.TargetUserName:*$@* and source.ip:(127.0.0.0/8 or "::1"))
'''


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

[[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.tactic]
id = "TA0006"
name = "Credential Access"
reference = "https://attack.mitre.org/tactics/TA0006/"

[rule.new_terms]
field = "new_terms_fields"
value = ["winlog.event_data.TargetUserName", "winlog.event_data.ServiceName"]
[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-7d"