Elastic rules: 02

[metadata]
creation_date = "2025/09/01"
integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
maturity = "production"
updated_date = "2026/05/04"

[rule]
author = ["Elastic"]
description = """
This rule detects the use of ADExplorer utility. Active Directory Explorer (AD Explorer) is an advanced Active Directory (AD)
viewer and editor. AD Explorer also includes the ability to save snapshots of an AD database for off-line viewing and comparisons.
Adversaries may abuse this utility to perform domain reconnaissance.
"""
from = "now-9m"
index = [
    "endgame-*",
    "logs-crowdstrike.fdr*",
    "logs-endpoint.events.process-*",
    "logs-m365_defender.event-*",
    "logs-sentinel_one_cloud_funnel.*",
    "logs-system.security*",
    "logs-windows.forwarded*",
    "logs-windows.sysmon_operational-*",
    "winlogbeat-*",
]
language = "eql"
license = "Elastic License v2"
name = "Active Directory Discovery using AdExplorer"
note = """## Triage and analysis

### Investigating Active Directory Discovery using AdExplorer

Active Directory Explorer (AD Explorer) is an advanced Active Directory (AD) viewer and editor. AD Explorer also includes the ability to save snapshots of an AD database for off-line viewing and comparisons.

#### Possible investigation steps

- Identify the user account that performed the action and whether it should perform this kind of action.
- Verify any file creation, this may indicate the creation of an AD snapshot.
- Identify when the AdExplorer binary was dropped and by what process reviewing file creation events.
- Contact the account owner and confirm whether they are aware of this activity.
- Investigate other alerts associated with the user/host during the past 48 hours.

### False positive analysis

- This rule has a high chance to produce false positives as it is a legitimate tool used by system administrators.
- If this rule is noisy in your environment due to expected activity, consider adding exceptions — preferably with a combination of user and process path conditions.

### Response and remediation

- Initiate the incident response process based on the outcome of the triage.
- Isolate the involved host to prevent further post-compromise behavior.
- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services.
- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.
- Determine the initial vector abused by the attacker and take action to prevent reinfection through 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 = """## Setup

This rule is designed for data generated by [Elastic Defend](https://www.elastic.co/security/endpoint-security), which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules.

Setup instructions: https://ela.st/install-elastic-defend

### Additional data sources

This rule also supports the following third-party data sources. For setup instructions, refer to the links below:

- [CrowdStrike](https://ela.st/crowdstrike-integration)
- [Microsoft Defender XDR](https://ela.st/m365-defender)
- [SentinelOne Cloud Funnel](https://ela.st/sentinel-one-cloud-funnel)
- [Sysmon Event ID 1 - Process Creation](https://ela.st/sysmon-event-1-setup)
- [Windows Process Creation Logs](https://ela.st/audit-process-creation)
"""

references = ["https://learn.microsoft.com/en-us/sysinternals/downloads/adexplorer"]
risk_score = 21
rule_id = "ff46eb26-0684-4da3-9dd6-21032c9878e1"
severity = "low"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Discovery",
    "Resources: Investigation Guide",
    "Data Source: Elastic Endgame",
    "Data Source: Elastic Defend",
    "Data Source: Windows Security Event Logs",
    "Data Source: Microsoft Defender XDR",
    "Data Source: Sysmon",
    "Data Source: SentinelOne",
    "Data Source: Crowdstrike",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
process where host.os.type == "windows" and event.type == "start" and
  (process.name : "ADExplorer*.exe" or ?process.pe.original_file_name == "AdExp")
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1016"
name = "System Network Configuration Discovery"
reference = "https://attack.mitre.org/techniques/T1016/"

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

[[rule.threat.technique]]
id = "T1069"
name = "Permission Groups Discovery"
reference = "https://attack.mitre.org/techniques/T1069/"
[[rule.threat.technique.subtechnique]]
id = "T1069.002"
name = "Domain Groups"
reference = "https://attack.mitre.org/techniques/T1069/002/"


[[rule.threat.technique]]
id = "T1087"
name = "Account Discovery"
reference = "https://attack.mitre.org/techniques/T1087/"
[[rule.threat.technique.subtechnique]]
id = "T1087.002"
name = "Domain Account"
reference = "https://attack.mitre.org/techniques/T1087/002/"


[[rule.threat.technique]]
id = "T1482"
name = "Domain Trust Discovery"
reference = "https://attack.mitre.org/techniques/T1482/"


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

[metadata]
creation_date = "2025/01/07"
integration = ["aws"]
maturity = "production"
updated_date = "2026/07/08"

[rule]
author = ["Elastic"]
description = """
Identifies when an SNS topic message is published by a rare user in AWS. Adversaries may publish messages to SNS topics
for phishing campaigns, data exfiltration, or lateral movement within the AWS environment. SNS topics are used to send
notifications and messages to subscribed endpoints such as applications, mobile devices or email addresses, making them a
valuable target for adversaries to distribute malicious content or exfiltrate sensitive data. This is a New Terms rule that only flags
when this behavior is observed for the first time by a user or role.
"""
false_positives = [
    """
    New users or roles may legitimately publish messages to SNS topics for authorized purposes. Ensure that the action
    is authorized before taking action.
    """,
]
from = "now-6m"
index = ["filebeat-*", "logs-aws.cloudtrail-*"]
language = "kuery"
license = "Elastic License v2"
name = "AWS SNS Topic Message Publish by Rare User"
note = """## Triage and Analysis

### Investigating AWS SNS Topic Message Publish by Rare User

This rule identifies when a message is published to an SNS topic by a user who has rarely or never published messages before. This activity could indicate adversarial actions, such as using SNS topics for phishing campaigns, data exfiltration, or lateral movement within an AWS environment.

This is a [New Terms](https://www.elastic.co/guide/en/security/current/rules-ui-create.html#create-new-terms-rule) rule that only flags when this behavior is observed for the first time by a user or role.

#### Possible Investigation Steps

- **Identify the Actor and Resource**:
  - **User Identity and Role**: Examine the `aws.cloudtrail.user_identity.arn` to identify the user or role responsible for publishing the SNS message. Verify whether this actor is authorized to publish messages to SNS topics.
  - **Access Key Details**: Review the `aws.cloudtrail.user_identity.access_key_id` to determine the access key used.
  - **SNS Topic ARN**: Analyze `aws.cloudtrail.resources.arn` to confirm whether the SNS topic is critical, sensitive, or used for authorized purposes.

- **Evaluate the Context of the SNS Message**:
  - **Published Message Details**: AWS redacts the message content in CloudTrail logs, but you can view the message ID, subject, and other metadata. Investigate the message details for any indicators of malicious content.
  - **Message Recipients**: Investigate the subscriptions associated with the SNS topic to identify if messages were sent to unauthorized or unexpected recipients.

- **Analyze Source Information**:
  - **Source IP Address**: Examine the `source.ip` field to identify the origin of the activity. Unusual IP addresses or geolocations may indicate unauthorized access.
  - **User Agent**: Review `user_agent.original` to determine the tool or client used for publishing the SNS message. Automated tools or unexpected clients (e.g., `Boto3` from an unknown host) may signify misuse.

- **Review Historical Activity**:
  - **Actor’s Past Behavior**: Identify whether the user has published messages to SNS topics before. Review similar past events for context.
  - **Frequency and Patterns**: Examine the time and frequency of messages published by the same user or to the same SNS topic to detect anomalies.

- **Correlate with Other Events**:
  - **IAM or CloudTrail Events**: Look for events such as `AssumeRole`, `CreateAccessKey`, or other API actions associated with the same user ARN.
  - **Unusual IAM Role Activity**: Determine if the actor has assumed roles or performed administrative tasks atypical for their role.

### False Positive Analysis

- **Routine Operational Use**:
  - Confirm if the publishing activity aligns with standard operational tasks or automation scripts.
  - Validate whether new or rare users were recently granted permissions for publishing messages to SNS topics.

- **Testing or Monitoring Scripts**:
  - Automated testing or monitoring tools may trigger this rule if configured to publish messages to SNS topics.

### Response and Remediation

- **Immediate Action**:
  - If unauthorized activity is confirmed, disable the access key or IAM role associated with the user.
  - Restrict or remove permissions from the SNS topic to prevent further misuse.

- **Review Policies and Subscriptions**:
  - Audit the IAM policies tied to the user and SNS topic to ensure appropriate permissions.
  - Validate the subscriptions of the SNS topic to confirm all endpoints are authorized.

- **Enhance Monitoring and Alerting**:
  - Set up additional logging or alerting for SNS publish actions, especially from rare or unknown users.
  - Monitor for similar actions across other SNS topics within the environment.

- **Conduct a Root Cause Analysis**:
  - Investigate how the user or role gained access to publish messages to the SNS topic.
  - Determine if other AWS resources or services have been affected.

### Additional Information

For more information on SNS topic management and securing AWS resources, refer to:
- [AWS SNS Publish API Documentation](https://docs.aws.amazon.com/sns/latest/api/API_Publish.html)
- [AWS CloudTrail Documentation](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference.html)
"""
references = [
    "https://docs.aws.amazon.com/sns/latest/api/API_Publish.html",
    "https://hackingthe.cloud/aws/exploitation/Misconfigured_Resource-Based_Policies/exploting_public_resources_attack_playbook/",
    "https://permiso.io/blog/s/smishing-attack-on-aws-sms-new-phone-who-dis/",
    "https://www.sentinelone.com/labs/sns-sender-active-campaigns-unleash-messaging-spam-through-the-cloud/",
]
risk_score = 73
rule_id = "2112ecce-cd34-11ef-873f-f661ea17fbcd"
setup = "AWS SNS topic data event types need to be enabled in the CloudTrail trail configuration to capture the Publish action. Ensure that the AWS CloudTrail service is [configured](https://docs.aws.amazon.com/sns/latest/dg/logging-using-cloudtrail.html#cloudtrail-data-events) to log data events for SNS."
severity = "high"
tags = [
    "Domain: Cloud",
    "Data Source: AWS",
    "Data Source: Amazon Web Services",
    "Data Source: AWS SNS",
    "Use Case: Threat Detection",
    "Resources: Investigation Guide",
    "Tactic: Lateral Movement",
    "Tactic: Exfiltration",
    "Tactic: Impact",
]
timestamp_override = "event.ingested"
type = "new_terms"

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

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

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

[[rule.threat.technique]]
id = "T1534"
name = "Internal Spearphishing"
reference = "https://attack.mitre.org/techniques/T1534/"

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

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

[[rule.threat.technique]]
id = "T1567"
name = "Exfiltration Over Web Service"
reference = "https://attack.mitre.org/techniques/T1567/"

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

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

[[rule.threat.technique]]
id = "T1496"
name = "Resource Hijacking"
reference = "https://attack.mitre.org/techniques/T1496/"

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

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

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

[[rule.threat.technique]]
id = "T1102"
name = "Web Service"
reference = "https://attack.mitre.org/techniques/T1102/"

[rule.threat.tactic]
id = "TA0011"
name = "Command and Control"
reference = "https://attack.mitre.org/tactics/TA0011/"
[rule.new_terms]
field = "new_terms_fields"
value = ["cloud.account.id", "user.name", "aws.cloudtrail.resources.arn"]
[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-10d"

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

[rule]
author = ["Elastic"]
description = """
Identifies role chaining activity. Role chaining is when you use one assumed role to assume a second role through the
AWS CLI or API. While this a recognized functionality in AWS, role chaining can be abused for privilege escalation if
the subsequent assumed role provides additional privileges. Role chaining can also be used as a persistence mechanism as
each AssumeRole action results in a refreshed session token with a 1 hour maximum duration. This is a new terms rule that looks for the first occurance of one role (aws.cloudtrail.user_identity.session_context.session_issuer.arn) assuming another (aws.cloudtrail.resources.arn).
"""
false_positives = [
    """
    Role chaining can be used as an access control. Ensure that this behavior is not part of a legitimate operation
    before taking action.
    """,
]
from = "now-6m"
index = ["filebeat-*", "logs-aws.cloudtrail-*"]
language = "kuery"
license = "Elastic License v2"
name = "AWS STS Role Chaining"
note = """
## Triage and analysis

### Investigating AWS STS Role Chaining

Role chaining occurs when a role assumed with temporary credentials (`AssumeRole`) is used to assume another role. While supported by AWS, chaining can increase risk of Privilege escalation, if the second role grants broader permissions; and Persistence, since each chained AssumeRole refreshes the session with up to 1-hour duration. This new terms rule triggers on the first observed combination of one role (`aws.cloudtrail.user_identity.session_context.session_issuer.arn`) assuming another (`aws.cloudtrail.resources.arn`). 

### Possible investigation steps

- **Review Alert Context**: Investigate the alert, focusing on `aws.cloudtrail.user_identity.session_context.session_issuer.arn` (the calling role) and `aws.cloudtrail.resources.arn` (the target role).  

- **Determine scope and intent.** Check `aws.cloudtrail.recipient_account_id` and `aws.cloudtrail.resources.account_id` fields to identify whether the chaining is Intra-account (within the same AWS account) or Cross-account (from another AWS account).  

- **Check role privileges.** Compare policies of the calling and target roles. Determine if chaining increases permissions (for example, access to S3 data, IAM modifications, or admin privileges).  

- **Correlate with other activity.** Look for related alerts or CloudTrail activity within ±30 minutes: policy changes, unusual S3 access, or use of sensitive APIs. Use `aws.cloudtrail.user_identity.arn` to track behavior from the same role session, use `aws.cloudtrail.user_identity.session_context.session_issuer.arn` to track broader behavior from the role itself.

- **Validate legitimacy.** Contact the account or service owner to confirm if the chaining was expected (for example, automation pipelines or federated access flows).  

- **Geography & source.** Review `cloud.region`, `source.address`, and other `geo` fields to assess if the activity originates from expected regions or network ranges.  

### False positive analysis

- **Expected role chaining.** Some organizations use role chaining as part of multi-account access strategies. Maintain an allowlist of known `issuer.arn` - `target.arn` pairs.  
- **Automation and scheduled tasks.** CI/CD systems or monitoring tools may assume roles frequently. Validate by `userAgent` and historical behavior.  
- **Test/dev environments.** Development accounts may generate experimental chaining patterns. Tune rules or exceptions to exclude low-risk accounts.  

### Response and remediation

**Immediate steps**
- **Preserve evidence.** Export triggering CloudTrail events (±30 minutes) into a restricted evidence bucket. Include session context, source IP, and user agent.  
- **Notify owners.** Contact the owners of both roles to validate intent.  

**Containment (if suspicious)**
- **Revoke temporary credentials.** [Revoke Session Permissions](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_revoke-sessions.html) if possible, or attach [AWSDenyALL policy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSDenyAll.html) to the originating role.  
- **Restrict risky roles.** Apply least-privilege policies or temporarily deny `sts:AssumeRole` for suspicious principals.  
- **Enable monitoring.** Ensure CloudTrail and GuardDuty are active in all regions to detect further chaining.  

**Scope and hunt**
- Search for additional AssumeRole activity by the same `issuer.arn` or `resources.arn` across other accounts and regions.  
- Look for privilege escalation attempts (for example, IAM `AttachRolePolicy`, `UpdateAssumeRolePolicy`) or sensitive data access following the chain.  

**Recovery & hardening**
- Apply least privilege to all roles, limiting trust policies to only required principals.  
- Enforce MFA where possible on AssumeRole operations.  
- Periodically review role chaining patterns to validate necessity; remove unused or risky trust relationships.  
- Document and tune new terms exceptions for known, legitimate chains.  

### Additional information
 
- [AWS IR Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/): NIST-aligned templates for evidence, containment, eradication, recovery, post-incident. 
- [AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework/): Practical response steps for account and IAM misuse scenarios
- AWS IAM Best Practices: [AWS docs](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) for reducing risk from temporary credentials.  

## Setup

The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.
"""
references = [
    "https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#id_roles_terms-and-concepts",
    "https://www.uptycs.com/blog/detecting-anomalous-aws-sessions-temporary-credentials",
    "https://hackingthe.cloud/aws/post_exploitation/role-chain-juggling/",
]
risk_score = 47
rule_id = "ba5a0b0c-b477-4729-a3dc-0147c2049cf1"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Data Source: AWS",
    "Data Source: Amazon Web Services",
    "Data Source: AWS STS",
    "Use Case: Threat Detection",
    "Tactic: Persistence",
    "Tactic: Privilege Escalation",
    "Tactic: Lateral Movement",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "new_terms"

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

[rule.investigation_fields]
field_names = [
    "@timestamp",
    "user_agent.original",
    "source.ip",
    "user.name",
    "aws.cloudtrail.user_identity.session_context.session_issuer.arn",
    "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",
    "aws.cloudtrail.recipient_account_id",
    "aws.cloudtrail.resources.account_id",
    "cloud.region",
    "aws.cloudtrail.request_parameters",
    "aws.cloudtrail.response_elements"
]

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

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

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

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

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

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

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

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

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

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

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

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

[rule.threat.tactic]
id = "TA0003"
name = "Persistence"
reference = "https://attack.mitre.org/tactics/TA0003/"
[rule.new_terms]
field = "new_terms_fields"
value = ["aws.cloudtrail.user_identity.session_context.session_issuer.arn", "aws.cloudtrail.resources.arn"]
[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-10d"

[rule]
description = """
Identifies the execution of a binary via the Application Virtualization Utility. Adversaries may bypass process and
signature-based defenses by proxying execution of malicious content with signed, or otherwise trusted, binaries.
"""
id = "1fe0df3c-89fd-498a-ac50-28f21d7b0f28"
license = "Elastic License v2"
name = "Binary Proxy Execution via AppVLP"
os_list = ["windows"]
reference = ["https://lolbas-project.github.io/lolbas/OtherMSBinaries/Appvlp/"]
version = "1.0.6"

query = '''
process where event.action == "start" and process.parent.name : "AppVLP.exe" and
 not process.executable : ("?:\\Program Files\\*", "?:\\Program Files (x86)\\*") and
 not (process.name : "rundll32.exe" and process.args : ("?:\\Program Files\\*", "?:\\Program Files (x86)\\*")) and
 process.hash.sha256 != "de40cd43ec9934769c830bd3d4bc4a5a3fd5ed0535fa8ce4fdb17be3301fc120"
'''

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

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1218"
name = "System Binary Proxy Execution"
reference = "https://attack.mitre.org/techniques/T1218/"


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

[internal]
min_endpoint_version = "7.15.0"

[rule]
description = """
Identifies attempt to disable memory crashdump via registry modification. Malware using kernel mode component may
perform this action to limit exposure in the case of an unexpected system crash.
"""
id = "77ca3fcc-f607-45e0-837e-e4173e4ffc2a"
license = "Elastic License v2"
name = "CrashDump Disabled via Registry Modification"
os_list = ["windows"]
reference = [
    "https://www.elastic.co/security-labs/elastic-protects-against-data-wiper-malware-targeting-ukraine-hermeticwiper",
    "https://docs.microsoft.com/en-us/troubleshoot/windows-server/performance/memory-dump-file-options",
]
version = "1.0.31"

query = '''
registry where registry.value : "CrashDumpEnabled" and registry.data.strings : "0" and
 process.executable != null and
 not (user.id in ("S-1-5-18", "S-1-5-19", "S-1-5-20") and 
      process.executable : ("?:\\Windows\\System32\\svchost.exe", "?:\\Windows\\System32\\msiexec.exe")) and
 not process.executable : (
       "?:\\Windows\\System32\\SystemPropertiesAdvanced.exe",
       /* TBR */
       "?:\\Program Files (x86)\\Citrix\\Workspace Environment Management Agent\\Citrix.Wem.Agent.Service.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 = "T1112"
name = "Modify Registry"
reference = "https://attack.mitre.org/techniques/T1112/"


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

[internal]
min_endpoint_version = "7.15.0"

[rule]
description = """
Cursor disables a crucial security feature: Workspace Trust, which in VS Code helps prevent inadvertently running unsafe
scripts or extensions. This omission poses a risk: attackers could embed malicious configurations like a
.vscode/settings.json pointing to a harmful executable and trigger code execution just by opening a project. This rule
detects the exploitation of this feature.
"""
id = "44e414c9-e072-48ef-9783-ee692619e028"
license = "Elastic License v2"
name = "Cursor Arbitrary Code Execution via PHP"
os_list = ["macos"]
reference = ["https://www.imperva.com/blog/cursors-magic-comes-with-a-catch-missing-trust-setting/"]
version = "1.0.5"

query = '''
process where event.type == "start" and event.action == "exec" and process.parent.code_signature.team_id == "VDXQ22DGB9" and
  (process.name in ("bash", "sh", "zsh", "dash", "csh", "tcsh", "ksh", "tclsh", "fish") or process.name like "tclsh*") and process.args like "/Users/*/.vscode/run" and
  process.args like "/Users/*.php"
'''

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 = "T1195"
name = "Supply Chain Compromise"
reference = "https://attack.mitre.org/techniques/T1195/"
[[threat.technique.subtechnique]]
id = "T1195.001"
name = "Compromise Software Dependencies and Development Tools"
reference = "https://attack.mitre.org/techniques/T1195/001/"



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

[metadata]
creation_date = "2026/08/27"
integration = ["azure"]
maturity = "production"
updated_date = "2026/08/27"

[rule]
author = ["Elastic"]
description = """
Detects a first-party FOCI tooling client (Azure CLI, PowerShell, VS Code, Graph CLI, Azure AD PowerShell, or Visual
Studio) redeeming a device-bound Primary Refresh Token (PRT) for Microsoft Graph, SharePoint/OneDrive, or Exchange
Online from an IP that is not among that user and device's Windows Sign-In or WAM addresses. Replay events are limited
to compliant or Intune-managed devices: the stolen cookie keeps the workstation deviceid, so compliant-device
Conditional Access can succeed off-box.
"""
false_positives = [
    """
    A user running Azure CLI, Azure PowerShell, VS Code, Graph CLI, or Visual Studio on a jump host, Cloud Shell, or VPN
    egress that differs from the workstation's Windows Sign-In IP can match if that activity still presents a compliant
    or managed workstation deviceid. Validate whether the Graph client ran on the enrolled device before treating the
    event as cookie theft.
    """,
    """
    Split-tunnel or dual-homed devices may present different egress IPs for WAM versus Azure CLI. Confirm both IPs
    belong to the same physical device before raising severity.
    """,
    """
    Microsoft Teams, Microsoft Office, OneDrive SyncEngine, Microsoft Authentication Broker, Outlook Mobile, Bing, Azure
    Portal, ADIbizaUX, and Office 365 Management are omitted. The rest of the Secureworks known-foci-clients.csv family
    (Edge, OneDrive, Intune Company Portal, Windows Search, Authenticator, SharePoint, Planner, Power BI, and similar)
    is omitted for the same reason: routine workstation or mobile Graph whose Microsoft 365 egress often differs from
    the Windows Sign-In IP without cookie theft. Hunt those app_ids separately if harvest is already confirmed.
    """,
]
from = "now-24h"
interval = "1h"
language = "esql"
license = "Elastic License v2"
name = "Entra ID Device-Bound PRT Replay via First-Party App from Unusual IP"
note = """## Triage and analysis

### Investigating Entra ID Device-Bound PRT Replay via First-Party App from Unusual IP

Adversaries who steal a WAM PRT SSO cookie (BrowserCore / InteractiveToken harvest) redeem it off-box for Microsoft Graph, SharePoint/OneDrive, or Exchange Online using a first-party FOCI client. PRTremote uses Azure CLI (`04b07795-8ddb-461a-bbee-02f9e1bf7b46`); TokenTactics and AADInternals can use Azure AD PowerShell (`1b730954-1685-4b74-9bfd-dac224a7b894`) or Microsoft Office (`d3590ed6-52b3-4102-aeff-aad2292ab01c`) when refreshing a PRT into a Graph, Outlook, or SharePoint token. This rule keys on CLI / PowerShell / VS Code / Visual Studio, not Teams, Office, OneDrive SyncEngine, Authentication Broker, Outlook Mobile, Bing, or Azure Portal — those clients routinely egress on a different IP than Windows Sign-In. Hunt Office-client PRT separately if harvest is already confirmed. The issued access token carries the *workstation* `deviceid`, so Conditional Access policies that require a compliant device can succeed even though the redeeming IP is not the device. Replay events must be `is_compliant` or `is_managed` so the join tracks a stolen enrolled workstation PRT, not an unmanaged ROADtx device.

This is not ConsentFix / OAuth-code phishing. Those flows show `OAuth2:Authorize` with `Redirect` and often lack a bound compliant device on the Graph token. Do not close this alert by following the first-party OAuth phishing playbook alone.


### Possible investigation steps

- Review `azure.signinlogs.properties.user_principal_name`, `azure.signinlogs.properties.device_detail.device_id`, and `source.ip`. Confirm `incoming_token_type` on the replay events is `primaryRefreshToken` and `device_detail.is_compliant` / `is_managed` are true. `Esql.resource_display_name_values` should be Microsoft Graph, Office 365 SharePoint Online, OneDrive for Business, and/or Office 365 Exchange Online.
- Treat `Esql.source_ip_device_values` as the workstation (Windows Sign-In / `Windows-AzureAD-Authentication-Provider/1.0`) — the device the PRT was bound to, and the likely theft origin. Treat `source.ip` / `Esql.source_ip_replay_values` as Graph / SharePoint / Exchange PRT IPs that are not in that device-session set (the replay actor). On-box FOCI from the workstation IP is excluded from the replay set. The harvest emulation showed workstation public IP versus attacker SNAT — including Azure ASN 8075, so a Microsoft-owned ASN does not clear the alert. The stolen PRT cookie nonce is typically valid for about five minutes; that is the attacker’s redeem window, not this rule’s lookback. The workstation may have signed in hours earlier, so the query correlates 24 hours of Windows Sign-In / WAM IPs with the replay.
- Inspect `Esql.app_display_name_values` and `Esql.user_agent_original_values`. A cookie POST through WAM can show a Trident/MSIE user agent on the Azure CLI client ID; that is the same IE stack legitimate Windows `az login` uses when it brokers through WAM, so it is triage context, not a detection key. TokenTactics Graph refresh commonly presents as Microsoft Office (omitted here). A follow-on `python-requests/*` Graph token from the same session is tooling, not the first-party binary on the workstation.
- Hunt endpoint telemetry for the same user or `device_detail.display_name` as `host.name`: `svchost.exe` (Schedule) → `cmd.exe` → `BrowserCore.exe` with `<` / `>` redirection, or files `formatted_nonce.txt` / `prt_cookie.txt`.
- Intune audit (`create-clientcertificate`) is enrollment context only; it will not fire on the harvest. Use it as optional join on user OID, not as coverage.
- Review Graph, SharePoint, and mailbox activity after the replay for directory, file, or mail enumeration.

### False positive analysis

- Developers who run Azure CLI, Graph CLI, or VS Code from a different egress than Windows Sign-In while WAM still attaches the workstation deviceid. Exception known Cloud Shell / jump-host IPs after confirming the client actually ran there.
- Microsoft Teams, Office, OneDrive SyncEngine, Authentication Broker, Outlook Mobile, Bing, Azure Portal, and Office 365 Management Graph PRT are excluded. Do not treat their absence as a miss; they are omitted because split-tunnel M365 egress is routine.
- First sign-in of a new device can have sparse Windows Sign-In history in the 24-hour window; widen the hunt before responding.
- Hybrid-joined workstations that report both `is_compliant` and `is_managed` as false (no Intune) will not match the replay branch. Hunt those deviceids separately if harvest is already confirmed.

### Response and remediation

- Contact the user to confirm whether they ran the first-party client in `Esql.app_display_name_values` from the replay IP.
- If unauthorized, revoke refresh tokens and primary refresh tokens for the user. The deviceid on the token is often the *legitimate* workstation — do not delete that device as if it were a ROADtx registration until you confirm otherwise.
- Isolate the workstation, hunt for InteractiveToken scheduled tasks and BrowserCore harvest, and treat the admin identity that registered the task as a second compromised principal.
"""
references = [
    "https://www.armadin.com/blog-posts/prtremote-extract-prt-cookies-remotely-with-interactivetoken-scheduled-task",
    "https://github.com/armadin-public/PRTremote",
    "https://github.com/dmcxblue/ANIMO/blob/master/helpers/scripts/GrabTokenAzureAD/PrtExtractor.cs",
    "https://github.com/rvrsh3ll/TokenTactics",
    "https://github.com/Gerenios/AADInternals",
]
risk_score = 73
rule_id = "6a9fdaab-b50f-408d-b4da-54719f256d41"
setup = """The Azure Fleet integration (or Filebeat Azure module) with Microsoft Entra ID sign-in logs is required. Ingest `SignInLogs` and `NonInteractiveUserSignInLogs` into `logs-azure.signinlogs-*` so Windows Sign-In / WAM device activity and FOCI Graph, SharePoint, and Exchange token issuance are both available for the join.

See [Microsoft Entra ID sign-in logs](https://learn.microsoft.com/en-us/entra/identity/monitoring-health/concept-sign-ins) and the [Azure integration](https://docs.elastic.co/integrations/azure).
"""
severity = "high"
tags = [
    "Domain: Cloud",
    "Domain: Identity",
    "Use Case: Threat Detection",
    "Use Case: Identity and Access Audit",
    "Data Source: Azure",
    "Data Source: Microsoft Entra ID",
    "Data Source: Microsoft Entra ID Sign-in Logs",
    "Platform: Entra ID",
    "Tactic: Credential Access",
    "Tactic: Defense Evasion",
    "Tactic: Initial Access",
    "Resources: Investigation Guide",
    "Rule Type: ESQL",
]
timestamp_override = "event.ingested"
type = "esql"

query = '''
from logs-azure.signinlogs-*
// find successful sign-in events where a managed device exists
| where event.dataset == "azure.signinlogs"
    and azure.signinlogs.properties.status.error_code == 0
    and azure.signinlogs.properties.device_detail.device_id is not null

// filter for device sign-in events from Windows Sign-In or WAM (login session)
| eval Esql.is_device_session = azure.signinlogs.properties.app_display_name == "Windows Sign In"
    or user_agent.original == "Windows-AzureAD-Authentication-Provider/1.0"

// filter for tooling FOCI clients that can redeem a PRT (replay)
| eval Esql.is_prt_replay = azure.signinlogs.properties.app_id in (
        "04b07795-8ddb-461a-bbee-02f9e1bf7b46",  // Microsoft Azure CLI
        "1950a258-227b-4e31-a9cf-717495945fc2",  // Microsoft Azure PowerShell
        "aebc6443-996d-45c2-90f0-388ff96faa56",  // Visual Studio Code
        "14d82eec-204b-4c2f-b7e8-296a70dab67e",  // Microsoft Graph Command Line Tools
        "1b730954-1685-4b74-9bfd-dac224a7b894",  // Azure Active Directory PowerShell
        "872cd9fa-d31f-45e0-9eab-6e460a02d1f1"   // Visual Studio
    )

    // target resource are common adversary targets for access
    and azure.signinlogs.properties.resource_id in (
        "00000003-0000-0000-c000-000000000000",  // Microsoft Graph
        "00000003-0000-0ff1-ce00-000000000000",  // Office 365 SharePoint Online
        "6a9b9266-8161-4a7b-913a-a9eda19da220",  // OneDrive for Business
        "00000002-0000-0ff1-ce00-000000000000"   // Office 365 Exchange Online
    )
    and azure.signinlogs.properties.incoming_token_type == "primaryRefreshToken"
    and (
        azure.signinlogs.properties.device_detail.is_compliant == true
        or azure.signinlogs.properties.device_detail.is_managed == true
    )

// device session or PRT replay event have to exist
| where Esql.is_device_session or Esql.is_prt_replay

// aggregate entities for both device session and PRT replay events
// aggregate by user and device
| stats
    Esql.source_ip_device_values = values(source.ip) where Esql.is_device_session,
    Esql.source_ip_replay_values = values(source.ip) where Esql.is_prt_replay,
    Esql.event_count_replay = count(*) where Esql.is_prt_replay,
    Esql.event_count_device_session = count(*) where Esql.is_device_session,
    Esql.user_principal_name_values = values(azure.signinlogs.properties.user_principal_name),
    Esql.app_display_name_values = values(azure.signinlogs.properties.app_display_name) where Esql.is_prt_replay,
    Esql.resource_id_values = values(azure.signinlogs.properties.resource_id) where Esql.is_prt_replay,
    Esql.resource_display_name_values = values(azure.signinlogs.properties.resource_display_name) where Esql.is_prt_replay,
    Esql.device_display_name_values = values(azure.signinlogs.properties.device_detail.display_name),
    Esql.user_agent_original_values = values(user_agent.original) where Esql.is_prt_replay,
    Esql.device_is_compliant_values = values(azure.signinlogs.properties.device_detail.is_compliant) where Esql.is_prt_replay,
    Esql.device_is_managed_values = values(azure.signinlogs.properties.device_detail.is_managed) where Esql.is_prt_replay,
    Esql.authentication_requirement_values = values(azure.signinlogs.properties.authentication_requirement) where Esql.is_prt_replay,
    Esql.conditional_access_status_values = values(azure.signinlogs.properties.conditional_access_status) where Esql.is_prt_replay,
    Esql.earliest_timestamp = min(@timestamp),
    Esql.latest_timestamp = max(@timestamp)
  by azure.signinlogs.properties.user_id, azure.signinlogs.properties.device_detail.device_id

// filter for PRT replay events that have at least one replay IP
| where Esql.event_count_replay > 0
    and Esql.event_count_device_session > 0
    and Esql.source_ip_replay_values is not null
    and Esql.source_ip_device_values is not null

// expand the replay IP list and keep only IPs that are not in the device-session set
| mv_expand Esql.source_ip_replay_values
| where not mv_contains(Esql.source_ip_device_values, Esql.source_ip_replay_values)
| eval Esql.source_ip_replay = Esql.source_ip_replay_values,
       user.id = azure.signinlogs.properties.user_id,
       source.ip = Esql.source_ip_replay_values
| keep
    user.id,
    source.ip,
    azure.signinlogs.properties.user_id,
    azure.signinlogs.properties.device_detail.device_id,
    Esql.*
'''


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

[[rule.threat.technique]]
id = "T1539"
name = "Steal Web Session Cookie"
reference = "https://attack.mitre.org/techniques/T1539/"


[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 = "T1550"
name = "Use Alternate Authentication Material"
reference = "https://attack.mitre.org/techniques/T1550/"
[[rule.threat.technique.subtechnique]]
id = "T1550.001"
name = "Application Access Token"
reference = "https://attack.mitre.org/techniques/T1550/001/"



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



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

[rule.investigation_fields]
field_names = [
    "user.id",
    "source.ip",
    "azure.signinlogs.properties.user_id",
    "azure.signinlogs.properties.device_detail.device_id",
    "Esql.user_principal_name_values",
    "Esql.device_display_name_values",
    "Esql.source_ip_device_values",
    "Esql.source_ip_replay_values",
    "Esql.app_display_name_values",
    "Esql.resource_display_name_values",
    "Esql.user_agent_original_values",
    "Esql.device_is_compliant_values",
    "Esql.device_is_managed_values",
]

[metadata]
bypass_bbr_timing = true
creation_date = "2020/09/04"
integration = ["endpoint"]
maturity = "production"
updated_date = "2024/05/21"

[rule]
author = ["Elastic"]
building_block_type = "default"
description = """
Identifies domains commonly used by adversaries for post-exploitation IP lookups. It is common for adversaries to test
for Internet access and acquire their external IP address after they have gained access to a system. Among others, this
has been observed in campaigns leveraging the information stealer, Trickbot.
"""
false_positives = [
    """
    If the domains listed in this rule are used as part of an authorized workflow, this rule will be triggered by those
    events. Validate that this is expected activity and tune the rule to fit your environment variables.
    """,
]
from = "now-9m"
index = ["logs-endpoint.events.network-*"]
language = "eql"
license = "Elastic License v2"
name = "External IP Lookup from Non-Browser Process"
note = """## Triage and analysis

### Investigating External IP Lookup from Non-Browser Process

After successfully compromising an environment, attackers may try to gain situational awareness to plan their next steps. This can happen by running commands to enumerate network resources, users, connections, files, and installed security software.

This rule looks for connections to known IP lookup services through non-browser processes or non-installed programs. Using only the IP address of the compromised system, attackers can obtain valuable information such as the system's geographic location, the company that owns the IP, whether the system is cloud-hosted, and more.

#### Possible investigation steps

- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.
- Identify the user account that performed the action and whether it should perform this kind of action.
- Contact the account owner and confirm whether they are aware of this activity.
- Investigate other alerts associated with the user/host during the past 48 hours.
- Investigate abnormal behaviors observed by the subject process, such as network connections, registry or file modifications, and any spawned child processes.

### False positive analysis

- Discovery activities are not inherently malicious if they occur in isolation. As long as the analyst did not identify suspicious activity related to the user or host, such alerts can be dismissed.
- If this rule is noisy in your environment due to expected activity, consider adding exceptions — preferably with a combination of user and command line conditions.

### Response and remediation

- Initiate the incident response process based on the outcome of the triage.
- Isolate the involved hosts to prevent further post-compromise behavior.
- Use the data collected through the analysis to investigate other machines affected in the environment.
- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services.
- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.
- 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).
"""
references = [
    "https://community.jisc.ac.uk/blogs/csirt/article/trickbot-analysis-and-mitigation",
    "https://www.cybereason.com/blog/dropping-anchor-from-a-trickbot-infection-to-the-discovery-of-the-anchor-malware",
]
risk_score = 21
rule_id = "1d72d014-e2ab-4707-b056-9b96abe7b511"
severity = "low"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Discovery",
    "Resources: Investigation Guide",
    "Data Source: Elastic Defend",
    "Rule Type: BBR",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
network where host.os.type == "windows" and network.protocol == "dns" and
    process.name != null and user.id not in ("S-1-5-19", "S-1-5-20") and
    event.action == "lookup_requested" and
    /* Add new external IP lookup services here */
    dns.question.name :
    (
        "*api.ipify.org",
        "*freegeoip.app",
        "*checkip.amazonaws.com",
        "*checkip.dyndns.org",
        "*freegeoip.app",
        "*icanhazip.com",
        "*ifconfig.*",
        "*ipecho.net",
        "*ipgeoapi.com",
        "*ipinfo.io",
        "*ip.anysrc.net",
        "*myexternalip.com",
        "*myipaddress.com",
        "*showipaddress.com",
        "*whatismyipaddress.com",
        "*wtfismyip.com",
        "*ipapi.co",
        "*ip-lookup.net",
        "*ipstack.com"
    ) and
    /* Insert noisy false positives here */
    not
    (
      (
        process.executable : (
            "?:\\Program Files\\*.exe",
            "?:\\Program Files (x86)\\*.exe",
            "?:\\Windows\\Prey\\versions\\*\\bin\\node.exe",
            "?:\\Windows\\System32\\WWAHost.exe",
            "?:\\Windows\\System32\\smartscreen.exe",
            "?:\\Windows\\System32\\MicrosoftEdgeCP.exe",
            "?:\\ProgramData\\Microsoft\\Windows Defender\\Platform\\*\\MsMpEng.exe",
            "?:\\Users\\*\\AppData\\Local\\Google\\Chrome\\Application\\chrome.exe",
            "?:\\Users\\*\\AppData\\Local\\Programs\\Fiddler\\Fiddler.exe",
            "?:\\Users\\*\\AppData\\Local\\Programs\\Microsoft VS Code\\Code.exe",
            "?:\\Users\\*\\AppData\\Local\\Microsoft\\OneDrive\\OneDrive.exe"
        ) and process.code_signature.trusted == true
      ) or
      (
        (process.name : "Evernote.exe" and process.code_signature.subject_name : "Evernote Corporation" and process.code_signature.trusted == true) or
        (process.name : "firefox.exe" and process.code_signature.subject_name : "Mozilla Corporation" and process.code_signature.trusted == true) or
        (process.name : "Loom.exe" and process.code_signature.subject_name : "Loom, Inc." and process.code_signature.trusted == true) or
        (process.name : "opera.exe" and process.code_signature.subject_name : "Opera Norway AS" and process.code_signature.trusted == true) or
        (process.name : "brave.exe" and process.code_signature.subject_name : "Brave Software, Inc." and process.code_signature.trusted == true) or
        (process.name : "vivaldi.exe" and process.code_signature.subject_name : "Vivaldi Technologies AS" and process.code_signature.trusted == true)
      )
    )
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1016"
name = "System Network Configuration Discovery"
reference = "https://attack.mitre.org/techniques/T1016/"
[[rule.threat.technique.subtechnique]]
id = "T1016.001"
name = "Internet Connection Discovery"
reference = "https://attack.mitre.org/techniques/T1016/001/"


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


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

[metadata]
creation_date = "2024/07/15"
integration = ["endpoint", "sentinel_one_cloud_funnel", "crowdstrike"]
maturity = "production"
updated_date = "2026/03/24"

[rule]
author = ["Elastic"]
description = """
This rule detects the execution of a potentially malicious process from a Git hook. Git hooks are scripts that Git
executes before or after events such as: commit, push, and receive. An attacker can abuse Git hooks to execute arbitrary
commands on the system and establish persistence.
"""
from = "now-9m"
index = ["logs-endpoint.events.process*", "logs-sentinel_one_cloud_funnel.*", "logs-crowdstrike.fdr*"]
language = "eql"
license = "Elastic License v2"
name = "Git Hook Command Execution"
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 Git Hook Command Execution

Git hooks are scripts that automate tasks by executing before or after Git events like commits or pushes. While useful for developers, adversaries can exploit them to run malicious commands, gaining persistence or evading defenses. The detection rule identifies suspicious processes initiated by Git hooks, focusing on shell executions, to flag potential abuse on Linux systems.

### Possible investigation steps

- Review the alert details to identify the specific Git hook script path and the suspicious process name that was executed, as indicated by the process.args and process.name fields.
- Examine the process tree to understand the parent-child relationship, focusing on the process.parent.name and process.entity_id fields, to determine how the suspicious process was initiated.
- Check the Git repository's history and recent changes to the .git/hooks directory to identify any unauthorized modifications or additions to the hook scripts.
- Investigate the user account associated with the process execution to determine if the activity aligns with their typical behavior or if it indicates potential compromise.
- Analyze the command-line arguments and environment variables of the suspicious process to gather more context on the nature of the executed command.
- Correlate this event with other security alerts or logs from the same host.id to identify any patterns or additional indicators of compromise.
- If possible, isolate the affected system and conduct a deeper forensic analysis to uncover any further malicious activity or persistence mechanisms.

### False positive analysis

- Developers using Git hooks for legitimate automation tasks may trigger this rule. To manage this, identify and document common scripts used in your development environment and create exceptions for these known benign processes.
- Continuous integration and deployment (CI/CD) systems often utilize Git hooks to automate workflows. Review the processes initiated by these systems and exclude them from detection if they are verified as non-malicious.
- Custom scripts executed via Git hooks for project-specific tasks can also cause false positives. Collaborate with development teams to catalog these scripts and adjust the detection rule to exclude them.
- Frequent updates or changes in Git repositories might lead to repeated triggering of the rule. Monitor these activities and, if consistent and verified as safe, consider adding them to an allowlist to reduce noise.

### Response and remediation

- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement.
- Terminate any suspicious processes identified as being executed from Git hooks, especially those involving shell executions.
- Conduct a thorough review of the .git/hooks directory on the affected system to identify and remove any unauthorized or malicious scripts.
- Restore any modified or deleted files from a known good backup to ensure system integrity.
- Implement monitoring for any future modifications to the .git/hooks directory to detect unauthorized changes promptly.
- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.
- Review and update access controls and permissions for Git repositories to limit the ability to modify hooks to trusted users only."""
references = [
    "https://swisskyrepo.github.io/InternalAllTheThings/redteam/persistence/linux-persistence/#backdooring-git",
    "https://www.elastic.co/security-labs/sequel-on-persistence-mechanisms",
]
risk_score = 21
rule_id = "dc61f382-dc0c-4cc0-a845-069f2a071704"
setup = """## Setup

This rule requires data coming in from Elastic Defend.

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

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

#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
- Go to the Kibana home page and click "Add integrations".
- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
- Click "Add Elastic Defend".
- Configure the integration name and optionally add a description.
- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).
- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead.
For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
- Click "Save and Continue".
- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts.
For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
"""
severity = "low"
tags = [
  "Domain: Endpoint",
  "OS: Linux",
  "Use Case: Threat Detection",
  "Tactic: Persistence",
  "Tactic: Execution",
  "Tactic: Defense Evasion",
  "Data Source: Elastic Defend",
  "Data Source: SentinelOne",
  "Resources: Investigation Guide",
  "Data Source: Crowdstrike",
]
type = "eql"
query = '''
sequence by host.id with maxspan=3s
  [process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start", "ProcessRollup2") and
   process.parent.name == "git" and process.args like ".git/hooks/*" and
   process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish")
  ] by process.entity_id
  [process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start", "ProcessRollup2") and
   process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish")] by process.parent.entity_id
'''

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

[[rule.threat.technique]]
id = "T1543"
name = "Create or Modify System Process"
reference = "https://attack.mitre.org/techniques/T1543/"

[[rule.threat.technique]]
id = "T1546"
name = "Event Triggered Execution"
reference = "https://attack.mitre.org/techniques/T1546/"

[[rule.threat.technique]]
id = "T1574"
name = "Hijack Execution Flow"
reference = "https://attack.mitre.org/techniques/T1574/"

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

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

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

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

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

[rule]
author = ["Elastic"]
description = """
Detects successful GKE secret get or list operations where the user agent matches scripting runtimes, minimal HTTP
clients, or offensive-distribution fingerprints rather than typical kubectl or controller traffic.
"""
false_positives = [
    """
    Approved scripts, CI jobs, or penetration tests may use generic HTTP clients. Validate tickets and identity scope
    before treating as compromise.
    """,
]
index = ["logs-gcp.audit-*"]
language = "kuery"
license = "Elastic License v2"
name = "GKE Secret get or list with Suspicious User Agent"
note = """## Triage and analysis

### Investigating GKE Secret get or list with Suspicious User Agent

Review `user.email`, `user_agent.original`, targeted secret resource, and `source.ip`.

### Investigation steps

- Confirm whether the identity should access secrets with this client fingerprint.
- Pivot on source IP for other API bursts, exec, or RBAC changes.

### False positives

- Internal automation using generic libraries; exclude stable service accounts after review.

## Setup

The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule."""
references = [
    "https://attack.mitre.org/techniques/T1552/007/",
]
risk_score = 73
rule_id = "0c04d82f-6def-4659-aa62-ed6355a51f39"
severity = "high"
tags = [
    "Domain: Cloud",
    "Domain: Kubernetes",
    "Data Source: GCP",
    "Data Source: Google Cloud Platform",
    "Use Case: Threat Detection",
    "Tactic: Credential Access",
    "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.core.v1.secrets.list" or "io.k8s.core.v1.secrets.get") and user_agent.original:(
  curl* or python* or Python* or wget* or Go-http* or perl* or java* or node* or php* or *distrib#kali* or *kali-amd64* or
  *kali-arm64* or Bun* or axios* or undici*
)
'''

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

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

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

[rule]
author = ["Elastic"]
description = """
This rule detects the creation of GRUB configuration files on Linux systems. The GRUB configuration file is used to
configure the boot loader, which is responsible for loading the operating system. Attackers may create malicious GRUB
configuration files to execute arbitrary code or escalate privileges during the boot process, which can be leveraged to
maintain persistence on the system.
"""
from = "now-9m"
index = ["logs-endpoint.events.file*", "logs-sentinel_one_cloud_funnel.*", "endgame-*"]
language = "eql"
license = "Elastic License v2"
name = "GRUB Configuration File Creation"
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 GRUB Configuration File Creation

GRUB (Grand Unified Bootloader) is crucial for booting Linux systems, managing the boot process, and loading the OS. Adversaries may exploit GRUB by creating or altering configuration files to execute unauthorized code or gain elevated privileges, ensuring persistence. The detection rule identifies suspicious creation of GRUB files, excluding legitimate processes, to flag potential security threats.

### Possible investigation steps

- Review the file path and name to determine if it matches any known GRUB configuration files, as specified in the query (e.g., "/etc/default/grub", "/boot/grub2/grub.cfg").
- Identify the process that created the file by examining the process.executable field, ensuring it is not one of the excluded legitimate processes.
- Check the timestamp of the file creation event to correlate it with any other suspicious activities or changes in the system around the same time.
- Investigate the user account associated with the process that created the file to determine if it has the necessary permissions and if the activity aligns with the user's typical behavior.
- Analyze the contents of the newly created or modified GRUB configuration file for any unauthorized or suspicious entries that could indicate malicious intent.
- Cross-reference the event with other security logs or alerts to identify any related activities or patterns that could suggest a broader attack or compromise.

### False positive analysis

- System package managers like dpkg, rpm, and yum may trigger false positives when they update or modify GRUB configuration files during routine package installations or updates. To handle this, ensure these processes are included in the exclusion list within the detection rule.
- Automated system management tools such as Puppet, Chef, and Ansible can also cause false positives when they manage GRUB configurations as part of their configuration management tasks. Consider adding these tools to the exclusion list if they are part of your environment.
- Virtualization and containerization tools like Docker, Podman, and VirtualBox might modify GRUB files as part of their operations. Verify these processes and exclude them if they are legitimate in your setup.
- Temporary files created by text editors or system processes, such as those with extensions like swp or swx, can be mistaken for GRUB configuration files. Ensure these extensions are part of the exclusion criteria to prevent unnecessary alerts.
- Custom scripts or administrative tasks that modify GRUB configurations for legitimate reasons should be reviewed and, if deemed safe, added to the exclusion list to avoid repeated false positives.

### Response and remediation

- Immediately isolate the affected system from the network to prevent potential lateral movement or further unauthorized access.
- Review the GRUB configuration files identified in the alert to confirm unauthorized modifications or creations. Restore any altered files from a known good backup if necessary.
- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious code or backdoors that may have been introduced.
- Change all system and user passwords on the affected machine to prevent unauthorized access using potentially compromised credentials.
- Monitor the system for any further suspicious activity, particularly focusing on processes attempting to modify GRUB configuration files.
- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.
- Implement additional logging and monitoring for GRUB configuration changes to enhance detection capabilities and prevent future unauthorized modifications."""
risk_score = 21
rule_id = "ce4a32e5-32aa-47e6-80da-ced6d234387d"
setup = """## Setup
This rule requires data coming in from Elastic Defend.
### Elastic Defend Integration Setup
Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.
#### Prerequisite Requirements:
- Fleet is required for Elastic Defend.
- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
- Go to the Kibana home page and click "Add integrations".
- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
- Click "Add Elastic Defend".
- Configure the integration name and optionally add a description.
- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).
- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead.
For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
- Click "Save and Continue".
- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts.
For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
"""
severity = "low"
tags = [
    "Domain: Endpoint",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Persistence",
    "Tactic: Execution",
    "Tactic: Defense Evasion",
    "Data Source: Elastic Defend",
    "Data Source: SentinelOne",
    "Data Source: Elastic Endgame",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
file where host.os.type == "linux" and event.type == "creation" and process.executable != null and file.path like~ (
  "/etc/default/grub.d/*", "/etc/default/grub", "/etc/grub.d/*",
  "/boot/grub2/grub.cfg", "/boot/grub/grub.cfg", "/boot/efi/EFI/*/grub.cfg",
  "/etc/sysconfig/grub"
) and not (
  /* Too many FPs from Python automation */
  process.name like ("python*", "platform-python*") or
  process.executable in (
    "/bin/dpkg", "/usr/bin/dpkg", "/bin/dockerd", "/usr/bin/dockerd", "/usr/sbin/dockerd", "/bin/microdnf",
    "/usr/bin/microdnf", "/bin/rpm", "/usr/bin/rpm", "/bin/snapd", "/usr/bin/snapd", "/bin/yum", "/usr/bin/yum",
    "/bin/dnf", "/usr/bin/dnf", "/bin/podman", "/usr/bin/podman", "/bin/dnf-automatic", "/usr/bin/dnf-automatic",
    "/bin/pacman", "/usr/bin/pacman", "/usr/bin/dpkg-divert", "/bin/dpkg-divert", "/sbin/apk", "/usr/sbin/apk",
    "/usr/local/sbin/apk", "/usr/bin/apt", "/usr/sbin/pacman", "/bin/podman", "/usr/bin/podman", "/usr/bin/puppet",
    "/bin/puppet", "/opt/puppetlabs/puppet/bin/puppet", "/usr/bin/chef-client", "/bin/chef-client",
    "/bin/autossl_check", "/usr/bin/autossl_check", "/proc/self/exe", "/usr/bin/pamac-daemon",
    "/bin/pamac-daemon", "/usr/lib/snapd/snapd", "/usr/local/bin/dockerd", "/usr/bin/crio", "/usr/sbin/crond",
    "/opt/puppetlabs/puppet/bin/ruby", "/usr/libexec/platform-python", "/kaniko/kaniko-executor",
    "/usr/local/bin/dockerd", "/usr/bin/podman", "/bin/install", "/proc/self/exe", "/usr/lib/systemd/systemd",
    "/usr/sbin/sshd", "/usr/bin/gitlab-runner", "/opt/gitlab/embedded/bin/ruby", "/usr/sbin/gdm", "/usr/bin/install",
    "/usr/local/manageengine/uems_agent/bin/dcregister", "/usr/local/bin/pacman", "./usr/bin/podman", "/usr/bin/dnf5",
    "/usr/sbin/yum-cron"
  ) or
  process.executable like~ (
    "/nix/store/*", "/var/lib/dpkg/*", "/tmp/vmis.*", "/snap/*", "/dev/fd/*", "/usr/lib/virtualbox/*"
  ) or
  file.extension in ("swp", "swpx", "swx", "dpkg-remove") or
  (process.name == "sed" and file.name : "sed*")
)
'''

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

[[rule.threat.technique]]
id = "T1542"
name = "Pre-OS Boot"
reference = "https://attack.mitre.org/techniques/T1542/"

[[rule.threat.technique]]
id = "T1543"
name = "Create or Modify System Process"
reference = "https://attack.mitre.org/techniques/T1543/"

[[rule.threat.technique]]
id = "T1574"
name = "Hijack Execution Flow"
reference = "https://attack.mitre.org/techniques/T1574/"

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

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

[[rule.threat.technique]]
id = "T1542"
name = "Pre-OS Boot"
reference = "https://attack.mitre.org/techniques/T1542/"

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

[metadata]
creation_date = "2020/11/06"
integration = ["endpoint", "windows"]
maturity = "production"
updated_date = "2026/05/03"

[rule]
author = ["Elastic"]
description = """
Identifies the use of Distributed Component Object Model (DCOM) to run commands from a remote host, which are launched
via the MMC20 Application COM Object. This behavior may indicate an attacker abusing a DCOM application to move
laterally.
"""
from = "now-9m"
index = [
    "winlogbeat-*",
    "logs-endpoint.events.process-*",
    "logs-endpoint.events.network-*",
    "logs-windows.sysmon_operational-*",
]
language = "eql"
license = "Elastic License v2"
name = "Incoming DCOM Lateral Movement with MMC"
references = ["https://enigma0x3.net/2017/01/05/lateral-movement-using-the-mmc20-application-com-object/"]
risk_score = 73
rule_id = "51ce96fb-9e52-4dad-b0ba-99b54440fc9a"
severity = "high"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Lateral Movement",
    "Data Source: Elastic Defend",
    "Data Source: Sysmon",
    "Resources: Investigation Guide",
]
type = "eql"

query = '''
sequence by host.id with maxspan=1m
 [network where host.os.type == "windows" and event.type == "start" and process.name : "mmc.exe" and source.port >= 49152 and
  destination.port >= 49152 and source.ip != "127.0.0.1" and source.ip != "::1" and
  network.direction : ("incoming", "ingress") and network.transport == "tcp"
 ] by process.entity_id
 [process where host.os.type == "windows" and event.type == "start" and process.parent.name : "mmc.exe"
 ] by process.parent.entity_id
'''

note = """## Triage and analysis

### Investigating Incoming DCOM Lateral Movement with MMC

#### Possible investigation steps

- Which Timeline source events define the target MMC instance, spawned child, and remote source?
  - Why: this asymmetric sequence links incoming "mmc.exe" network activity to a child process, and the alert may not preserve one reliable process identity.
  - Focus: recover the target MMC network event and child process event, recording target MMC and child `process.entity_id`, `source.ip`, and child `process.command_line`.
  - Implication: escalate if the chain does not resolve to one incoming MMC process spawning one child; lower suspicion only when it fits a recognized MMC administration source and child, then continue to command and network interpretation.
- Does the network event fit remote DCOM or RPC traffic into MMC?
  - Focus: the recovered "mmc.exe" network event: `source.ip`, `source.port`, `destination.port`, `network.direction`, and `network.transport`.
  - Implication: DCOM-style remote execution is supported by incoming TCP from a non-loopback `source.ip` with both ports in the high RPC range; concern rises when the source is a peer workstation, unrelated server, or unknown management origin.
- What did MMC execute through MMC20.Application COM automation?
  - Focus: recovered child `process.executable` and `process.command_line`.
  - Implication: escalate when MMC launches cmd.exe, PowerShell, script hosts, LOLBins, loaders, or download cradles; lower suspicion only when the exact child command is a recognized MMC snap-in helper or management binary and the source context also fits.
- Is the child binary identity consistent with the behavior, without treating signer trust as clearance?
  - Focus: child `process.hash.sha256`, `process.pe.original_file_name`, `process.code_signature.subject_name`, `process.code_signature.trusted`, and entity context.
  - Implication: mismatched PE metadata, user-writable paths, unexpected publishers, or quick follow-on LOLBin execution increases concern; a trusted signer confirms identity only and does not clear remote command execution.
- Does the target-side user and session fit remote administration from the recovered source?
  - Focus: child `user.id`, `user.name`, and `user.domain`, compared with the recovered source and target host.
  - Implication: escalate when the user, service context, or session is unexpected for that target or cannot explain administrative access from the source; lower suspicion when source, identity, and session match a recognized admin or jump-host path.
- Did the MMC-spawned child launch descendants after execution?
  - Focus: same-host process events from the child, checking child-of-child `process.parent.entity_id`. $investigate_2
  - Implication: escalate when the child launches more execution chains; absent descendants keeps the case centered on the recovered remote command, not benign.
- Did the child make DNS or connection activity?
  - Focus: same-host network events, checking DNS `dns.question.name` and connection `destination.ip`. $investigate_3
  - Hint: separate DNS events from connection events and keep the pivot bounded to the alert window. Missing network telemetry is unresolved, not benign.
  - Implication: escalate when the child resolves rare domains or connects to staging or command infrastructure.
- Does the recovered source or child command appear on other hosts after local triage stays suspicious?
  - Focus: same-host alerts for `host.id`. $investigate_0
  - Hint: if the same account is suspicious, compare same-`user.id` alerts for lateral-movement or credential-access patterns across other hosts. $investigate_1
  - Hint: broaden only after local evidence remains suspicious or unresolved; use `source.ip` for spread and a distinctive child `process.command_line` fragment for tool reuse.
  - Implication: expand scope when the same source touches more targets, the same child command appears elsewhere, or same-host alerts show lateral movement or defense evasion; keep the case local when the pattern stays confined and the workflow is otherwise explained.

- Escalate when source identity, incoming high-RPC network shape, child intent, identity/session, or descendant/DNS/destination evidence supports unauthorized MMC20.Application execution; close only when recovered evidence, with external confirmation when telemetry cannot prove intent, binds one exact recognized MMC administration workflow with no contradictory follow-on evidence; mixed or incomplete evidence means preserve and escalate.

### False positive analysis

- Remote MMC, server-management automation, or vendor/internal tooling can legitimately trigger this rule when a management host uses DCOM to drive MMC snap-ins or support commands. Confirm the recovered `source.ip` is a recognized admin, jump, or tooling host; child `process.executable` and `process.command_line` show the exact console/helper action; `user.id` or `user.name` fits that path; child `process.hash.sha256` or `process.code_signature.subject_name` is stable when tooling is involved; and descendant, DNS, and connection evidence stays quiet. If inventory or change records are unavailable, telemetry-only closure still requires current evidence to prove the exact workflow; prior recurrence of the same `source.ip`, child command, and `host.id` pattern is corroboration, not closure by itself.
- Before creating an exception, anchor it on the minimum confirmed workflow pattern: recognized `source.ip`, child `process.executable`, stable `process.command_line`, expected `user.id` or `user.name`, and the relevant `host.id` scope. Avoid exceptions on `process.parent.name` of "mmc.exe" or high RPC ports alone.

### Response and remediation

- If confirmed benign, record the recovered `source.ip`, child `process.executable`, child `process.command_line`, `user.id` or `user.name`, and target `host.id` that established the management workflow, then reverse any temporary containment. Create an exception only if the same pattern recurs consistently across prior alerts.
- If suspicious but unconfirmed, preserve a case export of the Timeline source events, the target MMC and child process instance IDs, child command line, source socket, and DNS/destination indicators before containment or cleanup.
- If suspicious but unconfirmed, apply reversible containment tied to the evidence, such as temporary DCOM/RPC restrictions from the recovered `source.ip` to the target `host.id`; isolate the host only when the child command or follow-on activity indicates payload execution and the host role can tolerate it.
- If confirmed malicious, first preserve the target MMC instance, child command, recovered source, descendant processes, and malicious DNS or destination indicators. Then isolate the target host and contain the recovered source system if it is in response scope; terminate processes or delete artifacts only after preservation and scoping.
- Review other hosts touched by the same recovered `source.ip` or child `process.command_line` pattern before terminating additional processes or removing artifacts so scoping completes before evidence is destroyed.
- Eradicate only scripts, binaries, persistence, or configuration changes identified during the investigation, then remediate the account, source host, or remote administration path that allowed the DCOM execution.
- Post-incident hardening: keep Windows Firewall enabled, disable unnecessary Microsoft Management Console inbound access, restrict DCOM/RPC between workstations, limit remote administrative rights to recognized jump hosts, and record the evidence and control changes for future triage."""

setup = """## Setup

This rule is designed for data generated by [Elastic Defend](https://www.elastic.co/security/endpoint-security), which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules.

Setup instructions: https://ela.st/install-elastic-defend

### Additional data sources

This rule also supports the following third-party data sources. For setup instructions, refer to the links below:

- [Sysmon Event ID 1 - Process Creation](https://ela.st/sysmon-event-1-setup)
- [Sysmon Event ID 3 - Network Connection](https://ela.st/sysmon-event-3-setup)
"""

[rule.investigation_fields]
field_names = [
    "@timestamp",
    "host.id",
    "host.name",
    "user.id",
]

[transform]

[[transform.investigate]]
label = "Alerts associated with the host"
description = ""
providers = [
  [
    { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }
  ]
]
relativeFrom = "now-48h/h"
relativeTo = "now"

[[transform.investigate]]
label = "Alerts associated with the user"
description = ""
providers = [
  [
    { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
    { excluded = false, field = "user.id", queryType = "phrase", value = "{{user.id}}", valueType = "string" }
  ]
]
relativeFrom = "now-48h/h"
relativeTo = "now"

[[transform.investigate]]
label = "Processes spawned by MMC on this host"
description = ""
providers = [
  [
    { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" },
    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
    { excluded = false, field = "process.parent.name", queryType = "phrase", value = "mmc.exe", valueType = "string" }
  ]
]
relativeFrom = "now-1h"
relativeTo = "now"

[[transform.investigate]]
label = "Network events for MMC on this host"
description = ""
providers = [
  [
    { excluded = false, field = "event.category", queryType = "phrase", value = "network", valueType = "string" },
    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
    { excluded = false, field = "process.name", queryType = "phrase", value = "mmc.exe", valueType = "string" }
  ]
]
relativeFrom = "now-1h"
relativeTo = "now"

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

[[rule.threat.technique]]
id = "T1021"
name = "Remote Services"
reference = "https://attack.mitre.org/techniques/T1021/"

[[rule.threat.technique.subtechnique]]
id = "T1021.003"
name = "Distributed Component Object Model"
reference = "https://attack.mitre.org/techniques/T1021/003/"

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

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

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

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

[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 = "T1559"
name = "Inter-Process Communication"
reference = "https://attack.mitre.org/techniques/T1559/"

[[rule.threat.technique.subtechnique]]
id = "T1559.001"
name = "Component Object Model"
reference = "https://attack.mitre.org/techniques/T1559/001/"

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

[metadata]
creation_date = "2025/06/19"
integration = ["endpoint", "auditd_manager", "crowdstrike", "cloud_defend"]
maturity = "production"
min_stack_comments = "Defend for Containers integration was re-introduced in 9.3.0"
min_stack_version = "9.3.0"
updated_date = "2026/03/24"

[rule]
author = ["Elastic"]
building_block_type = "default"
description = """
This rule detects the execution of kubectl commands that are commonly used for workload and cluster
discovery in Kubernetes environments. It looks for process events where kubectl is executed with
arguments that query cluster information, such as namespaces, nodes, pods, deployments, and other
resources. In environments where kubectl is not expected to be used, this could indicate potential
reconnaissance activity by an adversary.
"""
from = "now-119m"
index = ["logs-endpoint.events.*", "endgame-*", "auditbeat-*", "logs-auditd_manager.auditd-*", "logs-crowdstrike.fdr*", "logs-cloud_defend.process*"]
interval = "60m"
language = "eql"
license = "Elastic License v2"
name = "Kubectl Workload and Cluster Discovery"
risk_score = 21
rule_id = "74e5241e-c1a1-4e70-844e-84ee3d73eb7d"
severity = "low"
tags = [
  "Domain: Container",
  "Domain: Endpoint",
  "Domain: Kubernetes",
  "OS: Linux",
  "Use Case: Threat Detection",
  "Tactic: Discovery",
  "Rule Type: BBR",
  "Data Source: Elastic Defend",
  "Data Source: Elastic Endgame",
  "Data Source: Auditd Manager",
  "Data Source: Crowdstrike",
  "Data Source: Elastic Defend for Containers",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
process where host.os.type == "linux" and event.type == "start" and
event.action in ("exec", "exec_event", "executed", "process_started", "ProcessRollup2") and
process.name == "kubectl" and (
  (process.args in ("cluster-info", "api-resources", "api-versions", "version")) or
  (process.args in ("get", "describe") and process.args in (
    "namespaces", "nodes", "pods", "pod", "deployments", "deployment",
    "replicasets", "statefulsets", "daemonsets", "services", "service",
    "ingress", "ingresses", "endpoints", "configmaps", "events", "svc",
    "roles", "rolebindings", "clusterroles", "clusterrolebindings"
    )
  )
)
'''

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

[[rule.threat.technique]]
id = "T1069"
name = "Permission Groups Discovery"
reference = "https://attack.mitre.org/techniques/T1069/"

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

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