Elastic rules: 1a

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

[rule]
author = ["Elastic"]
description = """
Identifies the creation of a group in AWS Identity and Access Management (IAM). Groups specify permissions for multiple
users. Any user in a group automatically has the permissions that are assigned to the group. Adversaries who obtain
credentials with IAM write privileges may create a new group as a foothold for persistence: they can later attach
admin-level policies to the group and quietly add users or roles to inherit those privileges.
"""
false_positives = [
    """
    A group may be created by a system or network administrator. Verify whether the user identity, user agent, and/or
    hostname should be making changes in your environment. Group 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 IAM Group Creation"
note = """## Triage and analysis

### Investigating AWS IAM Group Creation

AWS IAM allows organizations to manage user access and permissions securely. Groups in IAM simplify permission management by allowing multiple users to inherit the same permissions. However, adversaries may exploit this by creating unauthorized groups to gain persistent access. This alert fires on `CreateGroup`. New group creation may indicate attacker staging for persistence, especially if followed by policy attachments or user additions.

#### Possible investigation steps

- **Identify the actor and context**  
  - Check `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.access_key_id` to determine who performed the group creation.  
  - Review `source.ip`, `user_agent.original`, `cloud.account.id`, `cloud.region` for unusual network, client, or region usage.

- **Examine the group details**  
  - From `aws.cloudtrail.response_elements`, extract `groupName` and `path` (e.g., /service/, /dev/).
  - Look for immediate follow-on changes by the same actor within the next 15–30 minutes:
    - AttachGroupPolicy (especially AdministratorAccess or broad s3:*, iam:*).
    - AddUserToGroup (who was added and when?).
  - Use GetGroup to enumerate current group membership and attached policies during triage.

- **Correlate with broader activity**  
  - Look for prior suspicious actions by the same user: `AssumeRole`, `CreateAccessKey`, new IAM user/role.  
  - After group creation, watch for data-access or configuration changes (e.g., S3 policy updates, KMS key policy changes) 

### False positive analysis

- IAM onboarding workflows or DevOps pipelines creating groups for new projects can trigger this alert.  
- Test or sandbox accounts often create and delete groups routinely, validate account context and approval flows.

### Response and remediation:

- **Containment**: 
  - If suspicious, disable further changes by the actor (temporarily remove IAM write privileges or deactivate keys).
  - Place a change freeze on the newly created group (block `AttachGroupPolicy`/`AddUserToGroup` via SCP/permissions boundary until review completes).

- **Investigation and scoping**: 
  - Use `GetGroup`, `ListAttachedGroupPolicies`, `ListUsersInGroup` to enumerate the group’s state and identify any suspicious policies or members. Investigate any attached policies granting broad privileges. 
  - Hunt for same-actor `AttachGroupPolicy`/`AddUserToGroup` events across the last 24–48h.
 
- **Recovery and hardening**: 
  - Delete unauthorized, unused or suspicious groups. remove rogue policies/members.
  - Restrict who can call `iam:CreateGroup`, `iam:AttachGroupPolicy`, and `iam:AddUserToGroup` (least privilege). 

### Additional information
[AWS Security Best Practices](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/)
"""
references = [
    "https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/create-group.html",
    "https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateGroup.html",
]
risk_score = 21
rule_id = "169f3a93-efc7-4df2-94d6-0d9438c310d1"
severity = "low"
tags = [
    "Domain: Cloud",
    "Data Source: AWS",
    "Data Source: Amazon Web Services",
    "Data Source: AWS IAM",
    "Use Case: Identity and Access Audit",
    "Tactic: Persistence",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

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


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1136"
name = "Create Account"
reference = "https://attack.mitre.org/techniques/T1136/"
[[rule.threat.technique.subtechnique]]
id = "T1136.003"
name = "Cloud Account"
reference = "https://attack.mitre.org/techniques/T1136/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",
    "event.outcome",
    "cloud.account.id",
    "cloud.region",
    "aws.cloudtrail.request_parameters",
    "aws.cloudtrail.response_elements",
]

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

[rule]
author = ["Elastic"]
description = """
Identifies a change to an AWS Lambda function resource policy that grants invoke permissions to an AWS account principal.
Using AddPermission, an adversary can authorize a principal in another account to call a function, creating a
cross-account backdoor for execution or for relaying data to attacker-controlled infrastructure without modifying the
function's code. This rule excludes public grants (principal set to "*"), which are covered by a separate rule, and
grants to AWS service principals, which are common for legitimate event triggers.
"""
false_positives = [
    """
    Cross-account invoke permissions are used for legitimate multi-account architectures and partner integrations.
    Verify the granted account in `aws.cloudtrail.request_parameters`, the function, and the `principal` value in
    `aws.cloudtrail.request_parameters` against approved cross-account access. Known partner or internal account ids can
    be excluded after validation. This rule cannot distinguish a grant to the function's own account from an external
    account, so same-account resource-policy grants (uncommon, since same-account invocation normally uses IAM
    identity-based policies) will also alert.
    """,
]
from = "now-6m"
index = ["logs-aws.cloudtrail-*"]
language = "eql"
license = "Elastic License v2"
name = "AWS Lambda Function Policy Updated to Allow Cross-Account Invocation"
note = """## Triage and analysis

### Investigating AWS Lambda Function Policy Updated to Allow Cross-Account Invocation

AWS Lambda resource policies control which principals may invoke a function. `AddPermission` granting `lambda:InvokeFunction` to a principal in another AWS account creates a cross-account invocation path. Adversaries use this to maintain execution access or to relay function output to infrastructure they control, without changing the function code that defenders typically scrutinize.

This rule detects grants of invoke permission to a specific external account, excluding public grants (handled by the related public-invocation rule) and AWS service principals used for normal event triggers.

### Possible investigation steps

- Inspect `aws.cloudtrail.request_parameters` for the `functionName`, the `action` granted, and the `principal` account id receiving access; confirm whether that account is known and trusted.
- Identify the actor in `aws.cloudtrail.user_identity.arn` and `aws.cloudtrail.user_identity.type`, and review `source.ip` and `user_agent.original` to understand how the change was made.
- Determine whether the function processes or has access to sensitive data that the external account could now reach.
- Correlate with other activity by the same principal, including function code or configuration changes and additional policy modifications.
- Verify whether the cross-account grant aligns with an approved integration or change request.

### False positive analysis

- Multi-account architectures and partner integrations legitimately grant cross-account invoke permissions. Confirm the grant is approved and exclude known trusted account ids or service roles on `aws.cloudtrail.user_identity.arn` after validation.

### Response and remediation

- If the grant is unauthorized, remove the statement from the function's resource policy (`RemovePermission`) and review the function's code, configuration, and execution role.
- Determine whether the external account invoked the function while the grant was in place and assess data exposure.
- Rotate or restrict credentials for the principal if compromise is suspected, and constrain `lambda:AddPermission` to a small set of trusted roles.

### Additional information

- [Lambda resource-based policies](https://docs.aws.amazon.com/lambda/latest/dg/access-control-resource-based.html)
- [AddPermission API](https://docs.aws.amazon.com/lambda/latest/api/API_AddPermission.html)
"""
references = [
    "https://docs.aws.amazon.com/lambda/latest/dg/access-control-resource-based.html",
    "https://docs.aws.amazon.com/lambda/latest/api/API_AddPermission.html",
]
risk_score = 73
rule_id = "8f985da6-66e8-4838-a63e-21636eb9adc5"
severity = "high"
tags = [
    "Domain: Cloud",
    "Data Source: AWS",
    "Data Source: Amazon Web Services",
    "Data Source: AWS Lambda",
    "Use Case: Threat Detection",
    "Tactic: Persistence",
    "Tactic: Defense Evasion",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
any where data_stream.dataset == "aws.cloudtrail"
    and event.provider == "lambda.amazonaws.com"
    and event.outcome == "success"
    and event.action : "AddPermission*"
    and stringContains(aws.cloudtrail.request_parameters, "lambda:InvokeFunction")
    and not stringContains(aws.cloudtrail.request_parameters, "principal=\\*")
    and not stringContains(aws.cloudtrail.request_parameters, ".amazonaws.com")
'''


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


[rule.threat.tactic]
id = "TA0003"
name = "Persistence"
reference = "https://attack.mitre.org/tactics/TA0003/"
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1578"
name = "Modify Cloud Compute Infrastructure"
reference = "https://attack.mitre.org/techniques/T1578/"
[[rule.threat.technique.subtechnique]]
id = "T1578.005"
name = "Modify Cloud Compute Configurations"
reference = "https://attack.mitre.org/techniques/T1578/005/"



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

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

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

[rule]
author = ["Elastic"]
description = """
Detects when AWS Security Hub is disabled in a region. Security Hub aggregates security findings from
AWS services (GuardDuty, Inspector, Macie, IAM Access Analyzer) and third-party tools into a single
pane of glass. Disabling it suppresses centralized finding aggregation and compliance checks, removing
visibility into threats across the account. This action is a documented pre-ransomware and
pre-exfiltration defense evasion technique.
"""
false_positives = [
    """
    Legitimate account decommissioning or cost-reduction exercises may disable Security Hub in
    unused regions. Validate with the responsible team via change management records before
    escalating. Disabling in the primary account region or the Security Hub delegated administrator
    account is always high-risk.
    """,
]
from = "now-6m"
index = ["logs-aws.cloudtrail-*"]
language = "kuery"
license = "Elastic License v2"
name = "AWS Security Hub Disabled"
note = """## Triage and analysis

### Investigating AWS Security Hub Disabled

AWS Security Hub aggregates security findings from GuardDuty, Inspector, IAM Access Analyzer, Macie, and partner products. Disabling it is a one-API-call action (DisableSecurityHub) that immediately stops new findings from appearing in the hub and breaks compliance posture checks (CIS, PCI DSS, AWS Foundational Security Best Practices). Threat actors performing pre-ransomware activity commonly disable security services to reduce detection during the exfiltration and encryption phases.

### Possible investigation steps

- Identify the caller in aws.cloudtrail.user_identity.arn and user.name. Determine whether this is a human operator, a CI/CD service role, or an automated account lifecycle script.
- Check source.ip against known office CIDRs, VPN endpoints, and CI/CD runner IPs. A call from an unexpected geography or cloud provider IP is a strong indicator of credential compromise.
- Query CloudTrail for all API calls from this identity in the same time window. Look for co-occurring DeleteDetector or UpdateDetector with enable false (GuardDuty), DisableMacie or UpdateMacieSession with status PAUSED (Macie), DeleteTrail, StopLogging, PutEventSelectors (reducing event selectors), or DeleteFlowLogs calls — a multi-service security teardown is high confidence ransomware/wiperware preparation.
- Determine whether Security Hub was re-enabled shortly after (indicating a momentary operational toggle) or remained disabled.
- Check whether this corresponds to a known change window or approved infrastructure operation.

### False positive analysis

- Regional decommissioning: teams shutting down an AWS region may disable Security Hub as part of account cleanup. Validate against a change management ticket.
- Cost optimization: Security Hub has a cost per finding. Some teams disable it in non-production accounts. If this fires in a dev/test account with known cost controls, correlate with account tags.

### Response and remediation

- If unauthorized, re-enable Security Hub immediately and review all findings that were suppressed during the disabled period using the Security Hub finding history API.
- Revoke active sessions for the calling identity.
- Review other security services (GuardDuty, Macie, Inspector) to confirm they remain enabled.
- Enable AWS Config rule securityhub-enabled to detect future disablement automatically.
- If the caller was a compromised IAM user, rotate all access keys and review all actions in the compromised session.
"""
references = [
    "https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-disable.html",
]
risk_score = 47
rule_id = "c8a2d4f6-1b3e-4a7c-9d5f-8e0b2c6a4d1e"
setup = "The AWS integration must be ingesting management events into `logs-aws.cloudtrail-*`. No additional CloudTrail data event selectors are required — `securityhub:DisableSecurityHub` is a management-plane API logged by default in any CloudTrail trail with management event logging enabled."
severity = "medium"
tags = [
    "Domain: Cloud",
    "Platform: AWS",
    "Data Source: AWS CloudTrail",
    "Service: AWS Security Hub",
    "Rule Type: Custom Query (KQL)",
    "Tactic: Defense Evasion",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

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


[[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.001"
name = "Disable or Modify Tools"
reference = "https://attack.mitre.org/techniques/T1562/001/"


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

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

[metadata]
creation_date = "2020/12/14"
integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
maturity = "production"
updated_date = "2026/05/04"

[rule]
author = ["Elastic"]
description = "A suspicious SolarWinds child process (Cmd.exe or Powershell.exe) was detected."
false_positives = [
    "Trusted SolarWinds child processes. Verify process details such as network connections and file writes.",
]
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 = "Command Execution via SolarWinds Process"
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 Command Execution via SolarWinds Process

SolarWinds is a widely used IT management tool that can be targeted by adversaries to execute unauthorized commands. Attackers may exploit SolarWinds processes to launch command-line interpreters like Cmd.exe or Powershell.exe, potentially leading to system compromise. The detection rule identifies suspicious child processes initiated by specific SolarWinds executables, flagging potential misuse by correlating process start events with known SolarWinds parent processes. This helps in early detection of malicious activities leveraging SolarWinds for command execution.

### Possible investigation steps

- Review the alert details to identify the specific SolarWinds parent process that initiated the suspicious child process (Cmd.exe or Powershell.exe) and note the exact executable name and path.
- Examine the timeline of events around the process start event to identify any preceding or subsequent suspicious activities, such as unusual network connections or file modifications.
- Check the user account associated with the process execution to determine if it aligns with expected behavior or if it indicates potential compromise or misuse.
- Investigate the command line arguments used by the child process to assess if they contain any malicious or unexpected commands.
- Correlate the event with other security logs and alerts from data sources like Microsoft Defender XDR or Sysmon to gather additional context and identify potential patterns of malicious behavior.
- Assess the system's current state for any indicators of compromise, such as unauthorized changes to system configurations or the presence of known malware signatures.

### False positive analysis

- Routine administrative tasks using SolarWinds may trigger the rule when legitimate scripts are executed via Cmd.exe or Powershell.exe. Users can create exceptions for known maintenance scripts or tasks that are regularly scheduled and verified as safe.
- Automated updates or patches initiated by SolarWinds processes might be flagged. To mitigate this, users should whitelist specific update processes or scripts that are part of the regular update cycle.
- Monitoring or diagnostic activities performed by IT staff using SolarWinds tools can result in false positives. Establish a baseline of normal activities and exclude these from alerts by identifying and documenting regular diagnostic commands.
- Custom scripts developed for internal use that leverage SolarWinds processes could be misidentified as threats. Ensure these scripts are reviewed and approved, then add them to an exception list to prevent unnecessary alerts.
- Third-party integrations with SolarWinds that require command execution might be mistakenly flagged. Verify the legitimacy of these integrations and exclude their associated processes from detection rules.

### Response and remediation

- Immediately isolate the affected system from the network to prevent further unauthorized command execution and potential lateral movement.
- Terminate any suspicious child processes such as Cmd.exe or Powershell.exe that were initiated by the identified SolarWinds parent processes.
- Conduct a thorough review of the affected system's logs and configurations to identify any unauthorized changes or additional indicators of compromise.
- Restore the system from a known good backup if any unauthorized changes or malicious activities are confirmed.
- Update and patch the SolarWinds software and any other vulnerable applications on the affected system to mitigate known vulnerabilities.
- Implement application whitelisting to prevent unauthorized execution of command-line interpreters from SolarWinds processes.
- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on the broader network."""
references = [
    "https://www.fireeye.com/blog/threat-research/2020/12/evasive-attacker-leverages-solarwinds-supply-chain-compromises-with-sunburst-backdoor.html",
    "https://github.com/mandiant/sunburst_countermeasures/blob/main/rules/SUNBURST/hxioc/SUNBURST%20SUSPICIOUS%20FILEWRITES%20(METHODOLOGY).ioc",
]
risk_score = 47
rule_id = "d72e33fc-6e91-42ff-ac8b-e573268c5a87"
severity = "medium"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Execution",
    "Tactic: Initial Access",
    "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",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
process where host.os.type == "windows" and event.type == "start" and process.name: ("cmd.exe", "powershell.exe") and
process.parent.name: (
     "ConfigurationWizard*.exe",
     "NetflowDatabaseMaintenance*.exe",
     "NetFlowService*.exe",
     "SolarWinds.Administration*.exe",
     "SolarWinds.Collector.Service*.exe",
     "SolarwindsDiagnostics*.exe"
     )
'''

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


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

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



[rule.threat.tactic]
id = "TA0002"
name = "Execution"
reference = "https://attack.mitre.org/tactics/TA0002/"
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1195"
name = "Supply Chain Compromise"
reference = "https://attack.mitre.org/techniques/T1195/"
[[rule.threat.technique.subtechnique]]
id = "T1195.002"
name = "Compromise Software Supply Chain"
reference = "https://attack.mitre.org/techniques/T1195/002/"



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

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

[rule]
author = ["Elastic"]
description = """
Detects when curl is executed via a shell profile upon login. This indicates a curl command was added to the 
user's shell profile (like .zshrc or .bashrc) and is executed automatically at login, which could be used for 
persistence and payload delivery.
"""
from = "now-9m"
index = ["logs-endpoint.events.process-*"]
language = "eql"
license = "Elastic License v2"
name = "Curl Execution via Shell Profile"
risk_score = 73
rule_id = "afdca1e0-0f8a-4fcf-9e1e-95e09791e3cd"
severity = "high"
tags = [
    "Domain: Endpoint",
    "OS: macOS",
    "Use Case: Threat Detection",
    "Tactic: Persistence",
    "Tactic: Command and Control",
    "Data Source: Elastic Defend",
    "Resources: Investigation Guide"
]
type = "eql"
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 Curl Execution via Shell Profile

Shell profile scripts (.zshrc, .bashrc, .bash_profile, .zprofile) execute automatically when users open new terminal sessions, making them valuable persistence mechanisms. Threat actors inject curl commands into these profiles to download and execute additional payloads each time the user opens a terminal, creating a reliable beacon mechanism that persists across system reboots. This detection rule identifies curl execution with download flags that originates directly from shell profile execution at login.

### Possible investigation steps

- Review the shell profile files (.zshrc, .bashrc, .bash_profile, .zprofile) for the affected user to identify the injected curl command and its destination URL.
- Analyze the process.args to determine the full curl command including output destination (-o, --output) and any other flags used.
- Investigate the destination URL in threat intelligence databases to determine if it is associated with known malicious infrastructure.
- Review the file modification timestamps of the shell profile files to determine when the malicious entry was added.
- Check browser history, email attachments, and download logs to understand how the attacker initially gained access to modify the profile.
- Examine the user.name associated with the modified profile to assess the scope of potential data access.
- Search for downloaded files on the system that may have been retrieved by the curl command and analyze their contents.

### False positive analysis

- Developers may add curl commands to shell profiles for convenience, such as fetching daily updates or checking API endpoints. Verify the URL destination and purpose with the user.
- Some shell customization frameworks and plugins use curl to update themselves on shell startup. Review common frameworks like Oh My Zsh for expected behavior.
- Enterprise tools may configure shell profiles for authentication or environment setup. Confirm with IT operations if such configurations are expected.
- Elastic infrastructure URLs are already excluded in the query to reduce noise from legitimate Elastic tooling.

### Response and remediation

- Remove the malicious curl command from the affected shell profile file immediately.
- Block the destination URL at the network perimeter to prevent payload delivery.
- Search for any files that were downloaded by the curl command and quarantine or remove them.
- Review user credentials and tokens that may have been exposed, as shell sessions often contain sensitive environment variables.
- Investigate how the shell profile was modified to identify the initial access vector.
- Check other user accounts on the system for similar shell profile modifications.
- Reset the user's shell profile from a known-good backup or template if available.
- Monitor for curl execution from shell profiles across the environment to identify additional compromised systems.
"""
query = '''
sequence with maxspan=10s
  [process where host.os.type == "macos" and event.type == "start" and event.action == "exec" and
    process.name in ("bash", "zsh", "sh") and
    process.args in ("-zsh", "-sh", "-bash") and process.args_count == 1 and
    process.parent.name == "login"] by process.entity_id
  [process where host.os.type == "macos" and event.type == "start" and event.action == "exec" and
    process.name in ("curl", "nscurl") and
    process.args in ("-o", "--output", "--download", "-dl", "-dir", "--directory", "-F", "--form") and
    not process.args like ("https://upload.elastic.co*", "https://vault-ci-prod.elastic.dev", "https://artifacts.elastic.co*")] by process.parent.entity_id
'''

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

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

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

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

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

[[rule.threat.technique]]
id = "T1105"
name = "Ingress Tool Transfer"
reference = "https://attack.mitre.org/techniques/T1105/"

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

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

[metadata]
creation_date = "2020/11/20"
integration = ["o365"]
maturity = "production"
updated_date = "2026/04/10"

[rule]
author = ["Elastic"]
description = """
Identifies when a Data Loss Prevention (DLP) policy is removed in Microsoft 365. An adversary may remove a DLP policy to
evade existing DLP monitoring.
"""
false_positives = [
    """
    A DLP policy may be removed by a system or network administrator. Verify that the configuration change was expected.
    Exceptions can be added to this rule to filter expected behavior.
    """,
]
from = "now-9m"
index = ["logs-o365.audit-*", "filebeat-*"]
language = "kuery"
license = "Elastic License v2"
name = "Deprecated - M365 Exchange DLP Policy Deleted"
note = """## Triage and analysis

### Investigating Deprecated - M365 Exchange DLP Policy Deleted

Data Loss Prevention (DLP) in Microsoft 365 Exchange is crucial for safeguarding sensitive information by monitoring and controlling data transfers. Adversaries may exploit this by removing DLP policies to bypass data monitoring, facilitating unauthorized data exfiltration. The detection rule identifies such actions by analyzing audit logs for specific events indicating successful DLP policy removal, thus alerting security teams to potential defense evasion tactics.

### Possible investigation steps

- Review the audit logs for the specific event.action "Remove-DlpPolicy" to identify the user account responsible for the action.
- Check the event.outcome field to confirm the success of the DLP policy removal and gather additional context from related logs.
- Investigate the user account's recent activities in Microsoft 365 to identify any other suspicious actions or anomalies.
- Verify if the removed DLP policy was critical for protecting sensitive data and assess the potential impact of its removal.
- Contact the user or their manager to confirm if the DLP policy removal was authorized and legitimate.
- Examine any recent changes in permissions or roles for the user account to determine if they had the necessary privileges to remove the DLP policy.

### False positive analysis

- Routine administrative changes to DLP policies by authorized personnel can trigger alerts. To manage this, maintain a list of authorized users and correlate their activities with policy changes to verify legitimacy.
- Scheduled updates or maintenance activities might involve temporary removal of DLP policies. Document these activities and create exceptions in the monitoring system for the duration of the maintenance window.
- Automated scripts or third-party tools used for policy management can inadvertently trigger false positives. Ensure these tools are properly documented and their actions are logged to differentiate between legitimate and suspicious activities.
- Changes in organizational policy or compliance requirements may necessitate the removal of certain DLP policies. Keep a record of such changes and adjust the monitoring rules to accommodate these legitimate actions.

### Response and remediation

- Immediately isolate the affected Microsoft 365 account to prevent further unauthorized actions and data exfiltration.
- Review the audit logs to identify any additional unauthorized changes or suspicious activities associated with the account or related accounts.
- Restore the removed DLP policy from a backup or recreate it based on the organization's standard configuration to re-enable data monitoring.
- Conduct a thorough investigation to determine the scope of data exposure and identify any data that may have been exfiltrated during the period the DLP policy was inactive.
- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional containment measures are necessary.
- Implement enhanced monitoring and alerting for similar events, focusing on unauthorized changes to security policies and configurations.
- Review and strengthen access controls and permissions for accounts with the ability to modify DLP policies to prevent unauthorized changes in the future.

## Setup

The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
references = [
    "https://docs.microsoft.com/en-us/powershell/module/exchange/remove-dlppolicy?view=exchange-ps",
    "https://docs.microsoft.com/en-us/microsoft-365/compliance/data-loss-prevention-policies?view=o365-worldwide",
]
risk_score = 47
rule_id = "60f3adec-1df9-4104-9c75-b97d9f078b25"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Data Source: Microsoft 365",
    "Use Case: Configuration Audit",
    "Tactic: Defense Evasion",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:o365.audit and event.provider:Exchange and event.category:web and event.action:"Remove-DlpPolicy" and event.outcome:success
'''


[[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.001"
name = "Disable or Modify Tools"
reference = "https://attack.mitre.org/techniques/T1562/001/"

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

[rule]
description = "Identifies suspicious execution via Distributed Component Object Model service to launch an application via Excel."
id = "e9825fa0-7fc3-468e-84dc-386aa9f92d20"
license = "Elastic License v2"
name = "Execution via DCOM Excel Application"
os_list = ["windows"]
reference = [
    "https://posts.specterops.io/lateral-movement-abuse-the-power-of-dcom-excel-application-3c016d0d9922",
]
version = "1.0.4"

query = '''
process where event.action == "start" and 
 process.parent.name : "excel.exe" and process.parent.args : "-Embedding" and 
 process.name : ("FOXPROW.exe", "SCHDPLUS.exe", "WINPROJ.exe")
'''

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

[[actions]]
action = "kill_process"
field = "process.parent.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/"
[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1021"
name = "Remote Services"
reference = "https://attack.mitre.org/techniques/T1021/"
[[threat.technique.subtechnique]]
id = "T1021.003"
name = "Distributed Component Object Model"
reference = "https://attack.mitre.org/techniques/T1021/003/"



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

[internal]
min_endpoint_version = "8.0.0"

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

[rule]
author = ["Elastic"]
description = """
Identifies execution of the security_authtrampoline process via a scripting interpreter. This occurs when programs use
AuthorizationExecute-WithPrivileges from the Security.framework to run another program with root privileges. It should
not be run by itself, as this is a sign of execution with explicit logon credentials.
"""
from = "now-9m"
index = ["logs-endpoint.events.*"]
language = "eql"
license = "Elastic License v2"
name = "Execution with Explicit Credentials via Scripting"
references = [
    "https://objectivebythesea.com/v2/talks/OBTS_v2_Thomas.pdf",
    "https://www.manpagez.com/man/8/security_authtrampoline/",
]
risk_score = 47
rule_id = "f0eb70e9-71e9-40cd-813f-bf8e8c812cb1"
setup = """## Setup

This rule requires data coming in from Elastic Defend.

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

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

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

query = '''
process where host.os.type == "macos" and event.type in ("start", "process_started") and
 process.name == "security_authtrampoline" and
 process.parent.name like~ ("osascript", "com.apple.automator.runner", "sh", "bash", "dash", "zsh", "python*", "perl*", "php*", "ruby", "pwsh")
'''
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 Execution with Explicit Credentials via Scripting

In macOS environments, the `security_authtrampoline` process is used to execute programs with elevated privileges via scripting interpreters. Adversaries may exploit this by using explicit credentials to run unauthorized scripts, gaining root access. The detection rule identifies such activities by monitoring the initiation of `security_authtrampoline` through common scripting languages, flagging potential privilege escalation attempts.

### Possible investigation steps

- Review the process details to confirm the parent process name matches one of the specified scripting interpreters (e.g., osascript, bash, python) to verify the context of the alert.
- Examine the command line arguments of the security_authtrampoline process to identify the script or program being executed and assess its legitimacy.
- Investigate the user account associated with the process to determine if the credentials used are valid and expected for executing such scripts.
- Check the historical activity of the involved user account and associated processes to identify any patterns of unusual or unauthorized behavior.
- Correlate the alert with other security events or logs from the same host to identify any additional indicators of compromise or related suspicious activities.
- Assess the system for any signs of compromise or unauthorized changes, such as unexpected new files, altered configurations, or additional unauthorized processes running.

### False positive analysis

- Legitimate administrative tasks using scripting languages may trigger this rule. Users should review the context of the script execution to determine if it aligns with expected administrative activities.
- Automated scripts or scheduled tasks that require elevated privileges might be flagged. Consider creating exceptions for known scripts by specifying their hash or path in the monitoring system.
- Development or testing environments where developers frequently use scripting languages to test applications with elevated privileges can cause false positives. Implement a policy to exclude these environments from the rule or adjust the risk score to reflect the lower threat level.
- Security tools or software updates that use scripting interpreters to perform legitimate actions with elevated privileges may be mistakenly identified. Verify the source and purpose of such processes and whitelist them if they are deemed safe.
- User-initiated scripts for personal productivity that require elevated access could be misinterpreted as threats. Educate users on safe scripting practices and establish a process for them to report and document legitimate use cases for exclusion.

### Response and remediation

- Immediately isolate the affected macOS system from the network to prevent further unauthorized access or lateral movement.
- Terminate the `security_authtrampoline` process if it is still running to stop any ongoing unauthorized activities.
- Review and revoke any compromised credentials used in the execution of the unauthorized script to prevent further misuse.
- Conduct a thorough examination of the system for any additional unauthorized scripts or malware that may have been deployed using the compromised credentials.
- Restore the system from a known good backup if any unauthorized changes or persistent threats are detected.
- Implement stricter access controls and monitoring for the use of scripting interpreters and the `security_authtrampoline` process to prevent similar privilege escalation attempts.
- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network."""


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

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

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

[[rule.threat.technique.subtechnique]]
id = "T1548.004"
name = "Elevated Execution with Prompt"
reference = "https://attack.mitre.org/techniques/T1548/004/"

[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 = "T1059"
name = "Command and Scripting Interpreter"
reference = "https://attack.mitre.org/techniques/T1059/"

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

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

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

[metadata]
creation_date = "2026/02/06"
integration = ["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/07/29"

[rule]
author = ["Elastic"]
description = """
This rule detects the download of files from inside a container. The files are downloaded using the "curl" or
"wget" command-line tools. Adversaries may use these tools to download files from the internet to gain access to
sensitive data or communicate with C2 servers.
"""
false_positives = [
    """
    There is a potential for false positives if the files are downloaded for legitimate purposes, such as debugging or
    troubleshooting, or if the files are downloaded from a known benign source. It is important to investigate any
    alerts generated by this rule to determine if they are indicative of malicious activity or part of legitimate
    container activity.
    """,
]
from = "now-6m"
index = ["logs-cloud_defend.process*"]
interval = "5m"
language = "eql"
license = "Elastic License v2"
name = "File Download Detected via Defend for Containers"
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 File Download Detected via Defend for Containers

This rule flags activity inside a Linux container where curl or wget is used to pull content from a URL or IP and immediately write a new file, signaling hands-on retrieval of tools, payloads, or data. It matters because attackers often use on-demand downloads to stage second-phase execution and establish application-layer command-and-control without baking artifacts into images. A common pattern is an operator execing into a running container, fetching a script or binary from paste/CDN infrastructure, then saving it for rapid follow-on execution.

### Possible investigation steps

- Attribute the interactive session to an initiator by correlating the container exec/attach event with Kubernetes audit logs or Docker daemon logs to identify the user/service account, source IP, and access path.  
- Inspect the created file’s full path, size, magic/format, and hash, then retrieve it from the container or node filesystem for static analysis and malware scanning.  
- Pivot on the download destination (domain/IP/URL path) to review outbound connection telemetry, DNS/TLS indicators, and threat reputation, and determine whether the endpoint is expected for this workload.  
- Review subsequent container activity after the download for follow-on actions such as chmod, interpreter execution, new processes, cron modifications, credential access, or lateral movement attempts.  
- Validate whether the container/image and namespace normally permit interactive access and external downloads, and if not, assess for compromised credentials, exposed exec permissions, or a misconfigured runtime policy.

### False positive analysis

- A developer or SRE may exec into a running container for interactive troubleshooting and use curl or wget to fetch a diagnostic script, configuration file, or test payload from an internal HTTP endpoint, resulting in a new file creation event.  
- An operator may interactively run curl or wget to download a patch, certificate bundle, or updated artifact into the container during an emergency fix or recovery workflow, especially in minimal images lacking package managers, which can appear indistinguishable from attacker staging.

### Response and remediation

- Immediately isolate the affected pod/container by applying a deny-all egress policy and, if possible, pausing or cordoning the hosting node to stop additional downloads and outbound C2 traffic.  
- Capture and preserve the downloaded artifact(s) created by curl/wget (path, timestamps, hashes) plus the interactive shell history/command line, then delete the file(s) from the container and revoke any injected tools or scripts.  
- Terminate the interactive session and rotate credentials used to exec/attach (Kubernetes user/service account tokens, kubeconfig, SSH keys) and invalidate any newly created access (added users, API tokens, or modified secrets/config).  
- Redeploy the workload from a known-good image and configuration, then scan the node and cluster for persistence or reuse of the same URL/IP and hashes across other containers, blocking them at egress and proxy/IDS.  
- Escalate to incident response immediately if the downloaded file is executed, connects to an unapproved external host, modifies startup paths (entrypoint/cron), or if the exec user is unknown or high-privileged.  
- Harden by removing exec/attach permissions from non-admin roles, enforcing runtime policies that block interactive curl/wget and restrict outbound traffic to approved destinations, and ensuring images include required tools so ad-hoc downloads are unnecessary."""
references = [
    "https://heilancoos.github.io/research/2025/12/16/kubernetes.html#kubelet-api",
    "https://www.cyberark.com/resources/threat-research-blog/using-kubelet-client-to-attack-the-kubernetes-cluster",
    "https://www.aquasec.com/blog/kubernetes-exposed-exploiting-the-kubelet-api/"
]
risk_score = 47
rule_id = "a8b08d2d-6dfe-453f-87d1-11d5fc3ec746"
severity = "medium"
tags = [
    "Data Source: Elastic Defend for Containers",
    "Domain: Container",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Command and Control",
    "Tactic: Execution",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and (
  (
    (process.name == "curl" or process.args in ("curl", "/bin/curl", "/usr/bin/curl", "/usr/local/bin/curl")) and
    process.args in ("-o", "-O", "--output", "--remote-name", "--remote-name-all", "--output-dir")
  ) or
  (
    (process.name == "wget" or process.args in ("wget", "/bin/wget", "/usr/bin/wget", "/usr/local/bin/wget")) and
    process.args like ("-*O*", "--output-document=*", "--output-file=*")
  )
) 
and container.id like "?*"
'''

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

[[rule.threat.technique]]
id = "T1071"
name = "Application Layer Protocol"
reference = "https://attack.mitre.org/techniques/T1071/"

[[rule.threat.technique.subtechnique]]
id = "T1071.001"
name = "Web Protocols"
reference = "https://attack.mitre.org/techniques/T1071/001/"

[[rule.threat.technique]]
id = "T1105"
name = "Ingress Tool Transfer"
reference = "https://attack.mitre.org/techniques/T1105/"

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

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

[metadata]
creation_date = "2020/09/21"
integration = ["gcp"]
maturity = "production"
updated_date = "2026/04/10"

[rule]
author = ["Elastic"]
description = """
Identifies when the Identity and Access Management (IAM) permissions are modified for a Google Cloud Platform (GCP)
storage bucket. An adversary may modify the permissions on a storage bucket to weaken their target's security controls
or an administrator may inadvertently modify the permissions, which could lead to data exposure or loss.
"""
false_positives = [
    """
    Storage bucket permissions may be modified by system administrators. Verify that the configuration change was
    expected. Exceptions can be added to this rule to filter expected behavior.
    """,
]
index = ["filebeat-*", "logs-gcp*"]
language = "kuery"
license = "Elastic License v2"
name = "GCP Storage Bucket Permissions Modification"
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 GCP Storage Bucket Permissions Modification

Google Cloud Platform (GCP) storage buckets are essential for storing and managing data in the cloud. IAM permissions control access to these buckets, ensuring data security. Adversaries may alter these permissions to bypass security measures, leading to unauthorized data access or exposure. The detection rule identifies successful permission changes, signaling potential misuse or accidental misconfigurations, aiding in timely security audits and responses.

### Possible investigation steps

- Review the event logs for the specific action "storage.setIamPermissions" to identify which IAM permissions were modified and by whom.
- Check the event.outcome field to confirm the success of the permission change and correlate it with any recent access attempts or data access patterns.
- Investigate the identity of the user or service account that performed the permission change to determine if it aligns with expected administrative activities.
- Assess the current IAM policy of the affected storage bucket to understand the new permissions and evaluate any potential security risks or exposure.
- Cross-reference the timing of the permission change with other security events or alerts to identify any suspicious activity or patterns.
- Consult with the bucket owner or relevant stakeholders to verify if the permission change was authorized and necessary for operational purposes.

### False positive analysis

- Routine administrative updates to IAM permissions can trigger alerts. To manage this, create exceptions for known maintenance windows or specific administrative accounts that regularly perform these updates.
- Automated scripts or tools that adjust permissions as part of their normal operation may cause false positives. Identify these scripts and exclude their actions from triggering alerts by using specific service accounts or tags.
- Changes made by trusted third-party services integrated with GCP might be flagged. Review and whitelist these services if they are verified and necessary for business operations.
- Temporary permission changes for troubleshooting or testing purposes can be mistaken for malicious activity. Document and schedule these changes, and exclude them from alerts during the specified timeframes.
- Permissions modified by cloud management platforms or orchestration tools should be reviewed. If these tools are part of standard operations, consider excluding their actions from the detection rule.

### Response and remediation

- Immediately revoke any unauthorized IAM permissions changes by restoring the previous known good configuration for the affected GCP storage bucket.
- Conduct a thorough review of the IAM policy change logs to identify the source and nature of the modification, focusing on the user or service account responsible for the change.
- Isolate the affected storage bucket from external access until the permissions are verified and secured to prevent further unauthorized access.
- Notify the security team and relevant stakeholders about the incident, providing details of the unauthorized changes and the steps taken to mitigate the risk.
- Implement additional monitoring on the affected storage bucket and related IAM policies to detect any further unauthorized changes or suspicious activities.
- Review and update IAM policies to ensure the principle of least privilege is enforced, reducing the risk of similar incidents in the future.
- If the incident is suspected to be part of a larger attack, escalate to incident response teams for a comprehensive investigation and potential involvement of law enforcement if necessary.

## Setup

The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
references = ["https://cloud.google.com/storage/docs/access-control/iam-permissions"]
risk_score = 47
rule_id = "2326d1b2-9acf-4dee-bd21-867ea7378b4d"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Data Source: GCP",
    "Data Source: Google Cloud Platform",
    "Use Case: Identity and Access Audit",
    "Tactic: Defense Evasion",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:gcp.audit and event.action:"storage.setIamPermissions" and event.outcome:success
'''


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

[[rule.threat.technique]]
id = "T1222"
name = "File and Directory Permissions Modification"
reference = "https://attack.mitre.org/techniques/T1222/"

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

[rule]
description = """
Detects the potential in memory load of a JXA script. JXA allows users to control applications and the operating system
using the JavaScript language. Additionally, it can be leveraged in OSAKit from within other macho binaries without
spawning the osascript binary. Malicious payloads will use OSAKit to load JXA (.js) scripts into their process memory
allowing them to execute post exploitation tasks from memory without being detected. When OSAKit is utilized to load JXA
scripts into memory AppleScript, JavaScript and StandardAdditions gets mapped into the process memory.
"""
id = "8cfda3f1-9364-4637-b779-753f6feb7acf"
license = "Elastic License v2"
name = "In-Memory JXA Execution via ScriptingAdditions"
os_list = ["macos"]
reference = ["https://github.com/MythicAgents/apfell", "https://posts.specterops.io/persistent-jxa-66e1c3cd1cf5"]
version = "1.0.27"

query = '''
sequence by process.entity_id with maxspan=10s
[library where event.action == "load" and dll.path == "/System/Library/Components/JavaScript.component/Contents/MacOS/JavaScript" and
  not process.executable like "/usr/bin/osascript"]
[library where event.action == "load" and dll.path == "/System/Library/ScriptingAdditions/StandardAdditions.osax/Contents/MacOS/StandardAdditions"]
'''

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

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


[threat.tactic]
id = "TA0002"
name = "Execution"
reference = "https://attack.mitre.org/tactics/TA0002/"
[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1620"
name = "Reflective Code Loading"
reference = "https://attack.mitre.org/techniques/T1620/"


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

[internal]
min_endpoint_version = "8.11.0"

[metadata]
creation_date = "2025/06/27"
integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel", "auditd_manager", "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"]
description = """
This rule detects the execution of the "kubectl apply" command with a URL argument. This command is often used to
apply configurations or deploy resources in a Kubernetes cluster. Attackers may use this command to deploy malicious
pods or modify existing ones, potentially leading to unauthorized access or data exfiltration.
"""
from = "now-9m"
index = [
    "auditbeat-*",
    "endgame-*",
    "logs-crowdstrike.fdr*",
    "logs-endpoint.events.process*",
    "logs-sentinel_one_cloud_funnel.*",
    "logs-auditd_manager.auditd-*",
    "logs-cloud_defend.process*",
]
language = "eql"
license = "Elastic License v2"
name = "Kubectl Apply Pod from URL"
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 Kubectl Apply Pod from URL

Kubectl is a command-line tool for managing Kubernetes clusters, allowing users to deploy and manage applications. Adversaries may exploit the 'kubectl apply' command with a URL to deploy malicious configurations or pods, potentially compromising the cluster. The detection rule identifies such activities by monitoring for the execution of 'kubectl apply' with URL arguments, flagging potential unauthorized deployments.

### Possible investigation steps

- Review the process execution details to confirm the presence of 'kubectl apply' with a URL argument, ensuring the command matches the query criteria.
- Identify the source IP address or hostname from which the 'kubectl apply' command was executed to determine if it originates from a known or trusted source.
- Check the URL used in the 'kubectl apply' command to assess its legitimacy and whether it points to a trusted or suspicious source.
- Investigate the user account associated with the execution of the command to verify if it has the necessary permissions and if the activity aligns with expected behavior.
- Examine the Kubernetes cluster logs for any recent changes or deployments that correspond with the time of the alert to identify any unauthorized modifications or deployments.
- Cross-reference the alert with other security tools or logs, such as network traffic analysis, to detect any related suspicious activities or data exfiltration attempts.

### False positive analysis

- Routine administrative tasks: Regular use of 'kubectl apply' with URLs for legitimate configuration updates or deployments can trigger alerts. To manage this, create exceptions for known and trusted URLs used by administrators.
- Automated deployment scripts: Continuous integration/continuous deployment (CI/CD) pipelines often use 'kubectl apply' with URLs to automate deployments. Identify and exclude these scripts by their specific process arguments or originating IP addresses.
- Monitoring and logging tools: Some monitoring solutions may use 'kubectl apply' with URLs as part of their normal operations. Review and whitelist these tools by verifying their source and purpose.
- Internal development environments: Developers may frequently use 'kubectl apply' with URLs in test environments. Establish a separate rule set or exceptions for these environments to reduce noise while maintaining security in production clusters.

### Response and remediation

- Immediately isolate the affected Kubernetes cluster to prevent further unauthorized deployments or access. This can be done by restricting network access or disabling external API access temporarily.
- Review the specific pod or configuration deployed using the 'kubectl apply' command with a URL. Identify any malicious or unauthorized changes and remove them from the cluster.
- Conduct a thorough audit of the cluster's current state to identify any other unauthorized deployments or configurations that may have been applied.
- Revoke any compromised credentials or access tokens that may have been used to execute the unauthorized 'kubectl apply' command. Ensure that all access keys and tokens are rotated.
- Escalate the incident to the security operations team for further investigation and to determine the root cause of the breach. This may involve analyzing logs and network traffic to trace the source of the attack.
- Implement network policies and role-based access controls (RBAC) to limit the ability to apply configurations from external URLs, ensuring only trusted sources are allowed.
- Enhance monitoring and alerting for similar activities by integrating with security information and event management (SIEM) systems to detect and respond to future threats promptly.
"""
risk_score = 21
rule_id = "eef9f8b5-48ec-44b5-b8bd-7b9b7d71853c"
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",
    "Domain: Container",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Execution",
    "Data Source: Auditd Manager",
    "Data Source: Elastic Endgame",
    "Data Source: Elastic Defend",
    "Data Source: Crowdstrike",
    "Data Source: SentinelOne",
    "Data Source: Elastic Defend for Containers",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
process where host.os.type == "linux" and event.type == "start" and
event.action in ("exec", "exec_event", "start", "ProcessRollup2", "process_started", "executed") and
process.name == "kubectl" and process.args == "apply" and
process.args like ("http://*", "https://*") and
not process.args like~ ("*download.elastic.co*", "*github.com/kubernetes-sigs/*")
'''

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

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

[[rule.threat.technique]]
id = "T1610"
name = "Deploy Container"
reference = "https://attack.mitre.org/techniques/T1610/"

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

[metadata]
creation_date = "2023/09/14"
integration = ["dga", "endpoint", "network_traffic"]
maturity = "production"
updated_date = "2026/03/24"

[rule]
author = ["Elastic"]
description = """
A supervised machine learning model has identified a DNS question name that used by the SUNBURST malware and is
predicted to be the result of a Domain Generation Algorithm.
"""
from = "now-10m"
index = ["logs-endpoint.events.*", "logs-network_traffic.*"]
language = "kuery"
license = "Elastic License v2"
name = "Machine Learning Detected DGA activity using a known SUNBURST DNS domain"
references = [
    "https://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html",
    "https://docs.elastic.co/en/integrations/dga",
    "https://www.elastic.co/security-labs/detect-domain-generation-algorithm-activity-with-new-kibana-integration",
]
risk_score = 73
rule_id = "bcaa15ce-2d41-44d7-a322-918f9db77766"
setup = """## Setup

The rule requires the Domain Generation Algorithm (DGA) Detection integration assets to be installed, as well as DNS events collected by integrations such as Elastic Defend, Network Packet Capture, or Packetbeat.

### DGA Detection Setup
The DGA Detection integration consists of an ML-based framework to detect DGA activity in DNS events.

#### Prerequisite Requirements:
- Fleet is required for DGA Detection.
- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
- DNS events collected by the [Elastic Defend](https://docs.elastic.co/en/integrations/endpoint), [Network Packet Capture](https://docs.elastic.co/integrations/network_traffic) integration, or [Packetbeat](https://www.elastic.co/guide/en/beats/packetbeat/current/packetbeat-overview.html).
- To install Elastic Defend, refer to the [documentation](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
- To add the Network Packet Capture integration to an Elastic Agent policy, refer to [this](https://www.elastic.co/guide/en/fleet/current/add-integration-to-policy.html) guide.
- To set up and run Packetbeat, follow [this](https://www.elastic.co/guide/en/beats/packetbeat/current/setting-up-and-running.html) guide.

#### The following steps should be executed to install assets associated with the DGA Detection integration:
- Go to the Kibana homepage. Under Management, click Integrations.
- In the query bar, search for Domain Generation Algorithm Detection and select the integration to see more details about it.
- Follow the instructions under the **Installation** section.
- For this rule to work, complete the instructions through **Configure the ingest pipeline**.
"""
severity = "high"
tags = [
    "Domain: Network",
    "Domain: Endpoint",
    "Data Source: Elastic Defend",
    "Use Case: Domain Generation Algorithm Detection",
    "Rule Type: ML",
    "Rule Type: Machine Learning",
    "Tactic: Command and Control",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
ml_is_dga.malicious_prediction:1 and dns.question.registered_domain:avsvmcloud.com
'''
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 Machine Learning Detected DGA activity using a known SUNBURST DNS domain

Domain Generation Algorithms (DGAs) are used by adversaries to dynamically generate domain names for command and control (C2) communication, making it difficult to block malicious domains. The SUNBURST malware utilized such techniques. The detection rule leverages machine learning to identify DNS queries linked to these generated domains, specifically targeting those associated with SUNBURST, by analyzing patterns and predicting malicious activity, thus aiding in early threat detection and mitigation.

### Possible investigation steps

- Review the DNS logs to identify the source IP address associated with the DNS query for avsvmcloud.com to determine the affected host within the network.
- Check historical DNS query logs for the identified host to see if there are additional queries to other suspicious or known malicious domains, indicating further compromise.
- Investigate the network traffic from the identified host around the time of the alert to detect any unusual patterns or connections to external IP addresses that may suggest command and control activity.
- Examine endpoint security logs and alerts for the affected host to identify any signs of SUNBURST malware or other related malicious activity.
- Correlate the alert with other security events in the environment to determine if there are any related incidents or patterns that could indicate a broader attack campaign.
- Assess the risk and impact of the detected activity on the organization and determine if immediate containment or remediation actions are necessary.

### False positive analysis

- Legitimate software updates or network services may occasionally use domain generation algorithms for load balancing or redundancy, leading to false positives. Users should monitor and whitelist these known benign services.
- Internal testing environments or security tools that simulate DGA behavior for research or training purposes might trigger alerts. Exclude these environments by adding them to an exception list.
- Some cloud services might use dynamic DNS techniques that resemble DGA patterns. Identify and document these services, then configure exceptions to prevent unnecessary alerts.
- Frequent legitimate access to avsvmcloud.com by security researchers or analysts could be misclassified. Ensure these activities are logged and reviewed, and create exceptions for known research IPs or user accounts.
- Regularly review and update the exception list to ensure it reflects current network behavior and does not inadvertently allow new threats.

### Response and remediation

- Isolate the affected systems immediately to prevent further communication with the malicious domain avsvmcloud.com and halt potential data exfiltration or lateral movement.
- Conduct a thorough scan of the isolated systems using updated antivirus and anti-malware tools to identify and remove any SUNBURST malware or related malicious files.
- Review and block any outbound traffic to the domain avsvmcloud.com at the network perimeter to prevent future connections from other potentially compromised systems.
- Analyze network logs and DNS query records to identify any other systems that may have communicated with the domain, and apply the same isolation and scanning procedures to those systems.
- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the full scope of the compromise.
- Implement enhanced monitoring and alerting for any DNS queries or network traffic patterns indicative of DGA activity, particularly those resembling SUNBURST characteristics, to detect and respond to similar threats promptly.
- Review and update incident response and recovery plans to incorporate lessons learned from this incident, ensuring faster and more effective responses to future threats."""


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

[[rule.threat.technique]]
id = "T1071"
name = "Application Layer Protocol"
reference = "https://attack.mitre.org/techniques/T1071/"

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

[[rule.threat.technique]]
id = "T1568"
name = "Dynamic Resolution"
reference = "https://attack.mitre.org/techniques/T1568/"

[[rule.threat.technique.subtechnique]]
id = "T1568.002"
name = "Domain Generation Algorithms"
reference = "https://attack.mitre.org/techniques/T1568/002/"

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

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

[transform]
[[transform.osquery]]
label = "Osquery - Retrieve DNS Cache"
query = "SELECT * FROM dns_cache"

[[transform.osquery]]
label = "Osquery - Retrieve All Services"
query = "SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services"

[[transform.osquery]]
label = "Osquery - Retrieve Services Running on User Accounts"
query = """
SELECT description, display_name, name, path, pid, service_type, start_type, status, user_account FROM services WHERE
NOT (user_account LIKE '%LocalSystem' OR user_account LIKE '%LocalService' OR user_account LIKE '%NetworkService' OR
user_account == null)
"""

[[transform.osquery]]
label = "Osquery - Retrieve Service Unsigned Executables with Virustotal Link"
query = """
SELECT concat('https://www.virustotal.com/gui/file/', sha1) AS VtLink, name, description, start_type, status, pid,
services.path FROM services JOIN authenticode ON services.path = authenticode.path OR services.module_path =
authenticode.path JOIN hash ON services.path = hash.path WHERE authenticode.result != 'trusted'
"""


[rule]
author = ["Elastic"]
description = """
Identifies multiple logon failures followed by a successful one from the same source address. Adversaries will often
brute force login attempts across multiple users with a common or known password, in an attempt to gain access to
accounts.
"""
from = "now-9m"
index = ["logs-system.security*", "logs-windows.forwarded*", "winlogbeat-*"]
language = "eql"
license = "Elastic License v2"
name = "Multiple Logon Failure Followed by Logon Success"
note = """## Triage and analysis

### Investigating Multiple Logon Failure Followed by Logon Success

Adversaries with no prior knowledge of legitimate credentials within the system or environment may guess passwords to attempt access to accounts. Without knowledge of the password for an account, an adversary may opt to guess the password using a repetitive or iterative mechanism systematically. More details can be found [here](https://attack.mitre.org/techniques/T1110/001/).

This rule identifies potential password guessing/brute force activity from a single address, followed by a successful logon, indicating that an attacker potentially successfully compromised the account.

> **Note**:
> This investigation guide uses the [Osquery Markdown Plugin](https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html) introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide.

#### Possible investigation steps

- Investigate the logon failure reason code and the targeted user name.
  - Prioritize the investigation if the account is critical or has administrative privileges over the domain.
- Investigate the source IP address of the failed Network Logon attempts.
  - Identify whether these attempts are coming from the internet or are internal.
- Investigate other alerts associated with the involved users and source host during the past 48 hours.
- Identify the source and the target computer and their roles in the IT environment.
- Check whether the involved credentials are used in automation or scheduled tasks.
- If this activity is suspicious, contact the account owner and confirm whether they are aware of it.
- Examine the source host for derived artifacts that indicate compromise:
  - Observe and collect information about the following activities in the alert source host:
    - Attempts to contact external domains and addresses.
      - Examine the DNS cache for suspicious or anomalous entries.
        - $osquery_0
    - Examine the host services for suspicious or anomalous entries.
      - $osquery_1
      - $osquery_2
      - $osquery_3
- Investigate potentially compromised accounts. Analysts can do this by searching for login events (for example, 4624) to the host which is the source of this activity.

### False positive analysis

- Authentication misconfiguration or obsolete credentials.
- Service account password expired.
- Domain trust relationship issues.
- Infrastructure or availability issues.

### Related rules

- Multiple Logon Failure from the same Source Address - 48b6edfc-079d-4907-b43c-baffa243270d

### Response and remediation

- Initiate the incident response process based on the outcome of the triage.
- Isolate the source host to prevent further post-compromise behavior.
- If the asset is exposed to the internet with RDP or other remote services available, take the necessary measures to restrict access to the asset. If not possible, limit the access via the firewall to only the needed IP addresses. Also, ensure the system uses robust authentication mechanisms and is patched regularly.
- 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

Audit Logon must be enabled to generate the events used by this rule.
Setup instructions: https://ela.st/audit-logon
"""

references = ["https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4625"]
risk_score = 47
rule_id = "4e85dc8a-3e41-40d8-bc28-91af7ac6cf60"
severity = "medium"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Credential Access",
    "Resources: Investigation Guide",
    "Data Source: Windows Security Event Logs",
]
type = "eql"

query = '''
sequence by winlog.computer_name, source.ip with maxspan=5s
  [authentication where host.os.type == "windows" and event.action == "logon-failed" and
    /* event 4625 need to be logged */
    winlog.logon.type : "Network" and user.id != null and 
    source.ip != null and source.ip != "127.0.0.1" and source.ip != "::1" and 
    not winlog.event_data.TargetUserSid : "S-1-0-0" and not user.id : "S-1-0-0" and 
    not user.name : ("ANONYMOUS LOGON", "-", "*$") and not user.domain == "NT AUTHORITY" and

    /* noisy failure status codes often associated to authentication misconfiguration */
    not winlog.event_data.Status : ("0xC000015B", "0XC000005E", "0XC0000133", "0XC0000192")] with runs=5
  [authentication where host.os.type == "windows" and event.action == "logged-in" and
    /* event 4624 need to be logged */
    winlog.logon.type : "Network" and
    source.ip != null and source.ip != "127.0.0.1" and source.ip != "::1" and
    not user.name : ("ANONYMOUS LOGON", "-", "*$") and not user.domain == "NT AUTHORITY"]
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1110"
name = "Brute Force"
reference = "https://attack.mitre.org/techniques/T1110/"
[[rule.threat.technique.subtechnique]]
id = "T1110.001"
name = "Password Guessing"
reference = "https://attack.mitre.org/techniques/T1110/001/"

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



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

[rule]
description = """
Identifies the execution of Microsoft Office or Adobe Reader to open a potential decoy document from an untrusted parent
process. An adversary may employ this technique to avoid victim suspicion by displaying a legit document after opening a
malicious executable or script.
"""
id = "5ec7d995-c321-4866-b304-8cc5c4bb6157"
license = "Elastic License v2"
name = "Potential Decoy Document via User Execution"
os_list = ["windows"]
reference = ["https://www.welivesecurity.com/2022/03/23/mustang-panda-hodur-old-tricks-new-korplug-variant/"]
version = "1.0.35"

query = '''
sequence with maxspan=5s
 [process where event.action == "start" and user.id : ("S-1-5-21*", "S-1-12-*") and
  (
    process.parent.name : ("cmd.exe", "wscript.exe", "cscript.exe", "mshta.exe", "powershell.exe") or
    (process.executable : ("?:\\Users\\*", "?:\\ProgramData\\*") and process.code_signature.trusted != true) or
    (process.name : "cmd.exe" and process.working_directory : "?:\\" and not process.working_directory : "C:\\") or 
    (process.name : "cmd.exe" and process.command_line : "*\\Temp\\7ZipSfx*")
  ) and 
  not process.executable :
               ("?:\\Program Files (x86)\\SmartAdvocate\\SADocumentLauncher\\SADocumentLauncher.exe",
                "C:\\Program Files\\Python*\\python.exe",
                "C:\\Program Files\\WindowsApps\\PythonSoftwareFoundation.Python.*.exe",
                "C:\\Program Files (x86)\\Microsoft Office\\root\\Office??\\OUTLOOK.EXE",
                "C:\\Program Files\\Microsoft Office\\root\\Office??\\OUTLOOK.EXE") and
  not process.parent.executable : ("\\Device\\Mup\\*",
                                   "?:\\Program Files\\IBM\\ClientSolutions\\Start_Programs\\Windows_x86-64\\acspcoc.exe",
                                   "C:\\Windows\\Microsoft.NET\\Framework64\\v*\\dfsvc.exe") and
  not process.executable : "?:\\Program Files\\Python??\\python.exe" and
  not (process.name : "rundll32.exe" and process.args : "url.dll,FileProtocolHandler") and
  not process.hash.sha256 in ("204326fdd6483ebce82c889fce539b1782a645b225c0f2e9fc8d71139546f255",
                              "da5612f679d98e07d49360989fd6abe7de157e7024d0b9ef0a3de527026baff2",
                              "e4a98dac4a1df240f71b75dc73ef4a71a27bd83af460cef4136022f66b1f3a4e",
                              "fe5d6e2fe76c098da524c59108a85afa653a3deee23e487f1ef38985407e0ef5",
                              "fbd1cb3e91e17c9318b5e9d64b9458bdbc98c7761af9f175a77b1d9163dac7be",
                              "a58f1415e0fc8560defca9e485b3c90b4d2f69a754adf40b7e565a9b1ba89d8b",
                              "28ed5f6f1b46d0581941a56e6bf4f5de479eafa92e362ee340b4d9f92ea519b9",
                              "e4a98dac4a1df240f71b75dc73ef4a71a27bd83af460cef4136022f66b1f3a4e",
                              "fe5d6e2fe76c098da524c59108a85afa653a3deee23e487f1ef38985407e0ef5") and
  not (process.parent.name : "cmd.exe" and process.parent.args : ("PDF Viewer", "1>NUL", "C:\\Users\\*\\AppData\\Local\\Temp\\*.pdf")) and
  not process.args : "C:\\Users\\*\\AppData\\Local\\Temp\\JetB2\\userReports\\*.PDF"
  ] by process.entity_id
 [process where event.action == "start" and
  (
    /* Word as decoy document */
  (process.name : "WINWORD.EXE" and
   process.args : "/n" and process.args : "/o" and process.args : ("?:\\Users\\*", "?:\\ProgramData\\*")) or

  (process.executable : "?:\\Program Files\\windows nt\\accessories\\wordpad.exe" and process.args_count == 2 and process.args : "*.doc*") or

    /* PDF as decoy document */
   (process.name : "AcroRd32.exe" and process.args_count == 2 and process.args : ("?:\\Users\\*.pdf", "?:\\ProgramData\\*.pdf")) or

   (process.name : ("chrome.exe", "msedge.exe") and process.args : "--single-argument" and process.args : "*.pdf")
  )
   ] by process.parent.entity_id
'''

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 = "T1566"
name = "Phishing"
reference = "https://attack.mitre.org/techniques/T1566/"
[[threat.technique.subtechnique]]
id = "T1566.001"
name = "Spearphishing Attachment"
reference = "https://attack.mitre.org/techniques/T1566/001/"



[threat.tactic]
id = "TA0001"
name = "Initial Access"
reference = "https://attack.mitre.org/tactics/TA0001/"
[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1204"
name = "User Execution"
reference = "https://attack.mitre.org/techniques/T1204/"
[[threat.technique.subtechnique]]
id = "T1204.001"
name = "Malicious Link"
reference = "https://attack.mitre.org/techniques/T1204/001/"

[[threat.technique.subtechnique]]
id = "T1204.002"
name = "Malicious File"
reference = "https://attack.mitre.org/techniques/T1204/002/"



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

[internal]
min_endpoint_version = "7.15.0"

[metadata]
creation_date = "2023/03/07"
integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"]
maturity = "production"
updated_date = "2025/12/18"

[rule]
author = ["Elastic"]
description = """
Identifies the execution of the PRoot utility, an open-source tool for user-space implementation of chroot, mount
--bind, and binfmt_misc. Adversaries can leverage an open-source tool PRoot to expand the scope of their operations to
multiple Linux distributions and simplify their necessary efforts. In a normal threat scenario, the scope of an attack
is limited by the varying configurations of each Linux distribution. With PRoot, it provides an attacker with a
consistent operational environment across different Linux distributions, such as Ubuntu, Fedora, and Alpine. PRoot also
provides emulation capabilities that allow for malware built on other architectures, such as ARM, to be run.The
post-exploitation technique called bring your own filesystem (BYOF), can be used by the threat actors to execute
malicious payload or elevate privileges or perform network scans or orchestrate another attack on the environment.
Although PRoot was originally not developed with malicious intent it can be easily tuned to work for one.
"""
from = "now-9m"
index = [
    "endgame-*",
    "logs-crowdstrike.fdr*",
    "logs-endpoint.events.process*",
    "logs-sentinel_one_cloud_funnel.*",
]
language = "eql"
license = "Elastic License v2"
name = "Potential Defense Evasion via PRoot"
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 Potential Defense Evasion via PRoot

PRoot is a versatile tool that emulates a chroot-like environment, allowing users to run applications across different Linux distributions seamlessly. Adversaries exploit PRoot to create consistent environments for executing malicious payloads, bypassing traditional defenses. The detection rule identifies suspicious PRoot activity by monitoring process executions initiated by PRoot, flagging potential misuse for defense evasion.

### Possible investigation steps

- Review the process tree to identify the parent process of PRoot and any child processes it spawned, focusing on the process.parent.name field to confirm PRoot as the parent.
- Examine the command line arguments used with PRoot to understand the context of its execution and identify any potentially malicious payloads or scripts being executed.
- Check the user account associated with the PRoot process to determine if it aligns with expected usage patterns or if it indicates potential compromise.
- Investigate the network activity associated with the PRoot process to identify any unusual connections or data transfers that could suggest malicious intent.
- Correlate the PRoot activity with other security alerts or logs to identify any related suspicious behavior or indicators of compromise within the same timeframe.

### False positive analysis

- Legitimate use of PRoot for cross-distribution development or testing environments may trigger alerts. Users can create exceptions for known development teams or specific projects that require PRoot for legitimate purposes.
- System administrators using PRoot for system maintenance or migration tasks might be flagged. To mitigate this, document and whitelist these activities by correlating them with scheduled maintenance windows or specific administrator accounts.
- Security researchers or penetration testers employing PRoot for controlled testing scenarios could cause false positives. Establish a process to identify and exclude these activities by verifying the involved personnel and their testing scope.
- Automated scripts or tools that utilize PRoot for non-malicious purposes, such as software compatibility testing, should be reviewed. Implement a tagging system to differentiate these benign activities from potential threats, allowing for easier exclusion in future detections.

### Response and remediation

- Isolate the affected system immediately to prevent further spread of the threat across the network. Disconnect it from the network and any shared resources.
- Terminate any suspicious processes initiated by PRoot to halt any ongoing malicious activities. Use process management tools to identify and kill these processes.
- Conduct a thorough examination of the filesystem for any unauthorized changes or suspicious files that may have been introduced by the adversary using PRoot.
- Restore the system from a known good backup if any malicious modifications are detected, ensuring that the backup is free from compromise.
- Update and patch the affected system to the latest security standards to close any vulnerabilities that may have been exploited.
- Implement enhanced monitoring for PRoot activity across the environment to detect any future unauthorized use. This includes setting up alerts for any process executions with PRoot as the parent process.
- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected."""
references = ["https://proot-me.github.io/"]
risk_score = 73
rule_id = "5c9ec990-37fa-4d5c-abfc-8d432f3dedd0"
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 = "high"
tags = [
    "Domain: Endpoint",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Defense Evasion",
    "Data Source: Elastic Defend",
    "Data Source: Elastic Endgame",
    "Data Source: Crowdstrike",
    "Data Source: SentinelOne",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2") and
process.parent.name == "proot"
'''

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

[[rule.threat.technique]]
id = "T1211"
name = "Exploitation for Defense Evasion"
reference = "https://attack.mitre.org/techniques/T1211/"

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

[metadata]
creation_date = "2025/07/23"
integration = ["network_traffic"]
maturity = "production"
updated_date = "2025/07/23"

[rule]
author = ["Elastic"]
building_block_type = "default"
description = """
Detects potential remote code execution (RCE) attempts targeting IIS web servers running SharePoint via malicious
VIEWSTATE payloads in HTTP POST requests. Attackers may exploit insecure deserialization in the VIEWSTATE parameter to
execute arbitrary code. This rule identifies suspicious requests containing VIEWSTATE data and other indicators of
exploitation, specifically those associated with the Toolshell exploit chain. Toolshell leverages vulnerabilities
(CVE-2025-53770 and CVE-2025-53771) for initial access, enabling adversaries to deploy a webshell, steal machine keys,
sign VIEWSTATE payloads offline, and subsequently send signed payloads to the server to achieve code execution.
"""
from = "now-119m"
interval = "60m"
index = ["logs-network_traffic.http*"]
language = "kuery"
license = "Elastic License v2"
max_signals = 100
name = "Potential VIEWSTATE RCE Attempt on SharePoint/IIS"
references = [
    "https://research.eye.security/sharepoint-under-siege/",
    "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-53771",
    "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-53770",
    "https://msrc.microsoft.com/blog/2025/07/customer-guidance-for-sharepoint-vulnerability-cve-2025-53770/",
]
risk_score = 47
rule_id = "99c9af5a-67cf-11f0-b69e-f661ea17fbcd"
setup = """### Network Traffic Setup

This rule requires network traffic logs to be collected from HTTP endpoints, focusing on IIS web servers and SharePoint sites. Ensure logging captures HTTP request and response details, including headers and request bodies for POST requests. Monitoring VIEWSTATE content is critical for detecting deserialization attacks.
"""
severity = "medium"
tags = [
    "Domain: Network",
    "Tactic: Initial Access",
    "Use Case: Exploit Detection",
    "Data Source: Network Traffic",
    "Data Source: Network Traffic HTTP Logs",
    "Rule Type: BBR"
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset : "network_traffic.http" and
    network.direction: "ingress" and
    http.request.method: "POST" and
    http.request.referrer: *SignOut.aspx and
    http.request.body.content: *__VIEWSTATE=* and
    http.request.body.bytes >= 500 and
    http.response.headers.server: Microsoft-IIS*
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1190"
name = "Exploit Public-Facing Application"
reference = "https://attack.mitre.org/techniques/T1190/"


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

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

[rule]
author = ["Elastic"]
description = """
Identifies instances where GDB (granted the CAP_SYS_PTRACE capability) is executed, after which an outbound network
connection is initiated by UID/GID 0 (root). In Linux, the CAP_SYS_PTRACE capability grants a process the ability to use
the ptrace system call, which is typically used for debugging and allows the process to trace and control other
processes. Attackers may leverage this capability to hook and inject into a process that is running with root
permissions in order to execute shell code and gain a reverse shell with root privileges.
"""
from = "now-9m"
index = ["logs-endpoint.events.network*", "logs-endpoint.events.process*"]
language = "eql"
license = "Elastic License v2"
name = "Root Network Connection via GDB CAP_SYS_PTRACE"
risk_score = 47
rule_id = "28bc620d-b2f7-4132-b372-f77953881d05"
setup = """## Setup


This rule requires data coming in from Elastic Defend.

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

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

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

query = '''
sequence by host.id, process.entry_leader.entity_id with maxspan=30s
  [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and process.name == "gdb" and
   (process.thread.capabilities.effective : "CAP_SYS_PTRACE" or process.thread.capabilities.permitted : "CAP_SYS_PTRACE") and
   user.id != "0"]
  [network where host.os.type == "linux" and event.action == "connection_attempted" and event.type == "start" and
   process.name != null and user.id == "0"]
'''
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 Root Network Connection via GDB CAP_SYS_PTRACE

GDB, a debugger, can be granted the CAP_SYS_PTRACE capability, allowing it to trace and control processes, a feature often exploited by attackers. By injecting code into root processes, adversaries can execute malicious payloads, such as reverse shells. The detection rule identifies suspicious sequences where GDB is used with this capability, followed by a root-initiated network connection, signaling potential privilege escalation or command and control activities.

### Possible investigation steps

- Review the process execution details to confirm the presence of GDB with CAP_SYS_PTRACE capability by examining the process name, capabilities, and user ID fields in the alert.
- Investigate the network connection attempt by analyzing the process name and user ID fields to determine if the connection was initiated by a root process.
- Check the timeline of events to ensure the sequence of GDB execution followed by a network connection attempt occurred within the specified maxspan of 30 seconds.
- Identify the destination IP address and port of the network connection to assess if it is known for malicious activity or associated with command and control servers.
- Examine the host system for any signs of compromise or unauthorized changes, focusing on processes and files that may have been affected by the potential privilege escalation.
- Correlate the alert with other security events or logs from the same host to identify any additional suspicious activities or patterns that may indicate a broader attack.

### False positive analysis

- Development environments may trigger this rule when developers use GDB with CAP_SYS_PTRACE for legitimate debugging purposes. To mitigate, create exceptions for specific user IDs or processes known to be involved in development activities.
- Automated testing frameworks that utilize GDB for testing applications with root privileges can cause false positives. Identify and exclude these processes or testing environments from the rule.
- System maintenance scripts that require debugging of root processes might inadvertently match the rule criteria. Review and whitelist these scripts or the specific time frames they run to prevent unnecessary alerts.
- Security tools that perform legitimate process tracing as part of their monitoring activities could be mistaken for malicious behavior. Ensure these tools are recognized and excluded from the detection rule.
- Custom administrative scripts that use GDB for process management under root privileges should be documented and excluded to avoid false alarms.

### Response and remediation

- Immediately isolate the affected host from the network to prevent further malicious activity and potential lateral movement.
- Terminate any suspicious processes associated with GDB that have been granted the CAP_SYS_PTRACE capability, especially those initiated by non-root users.
- Conduct a thorough review of the affected system's logs to identify any unauthorized changes or additional malicious activities that may have occurred.
- Reset credentials and review permissions for any accounts that may have been compromised, particularly those with elevated privileges.
- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited.
- Implement network monitoring to detect and block any further unauthorized outbound connections from root processes.
- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network."""


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

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

[[rule.threat.technique.subtechnique]]
id = "T1055.008"
name = "Ptrace System Calls"
reference = "https://attack.mitre.org/techniques/T1055/008/"

[[rule.threat.technique]]
id = "T1068"
name = "Exploitation for Privilege Escalation"
reference = "https://attack.mitre.org/techniques/T1068/"

[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 = "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.technique]]
id = "T1071"
name = "Application Layer Protocol"
reference = "https://attack.mitre.org/techniques/T1071/"

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

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

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

[[rule.threat.technique.subtechnique]]
id = "T1055.008"
name = "Ptrace System Calls"
reference = "https://attack.mitre.org/techniques/T1055/008/"

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