Elastic rules: 0r

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

[rule]
author = ["Elastic"]
description = """
Identifies when a user has queried for deprecated Amazon Machine Images (AMIs) in AWS. This may indicate an adversary looking for outdated AMIs that may be vulnerable to exploitation. While deprecated AMIs are not inherently malicious or indicative of a breach, they may be more susceptible to vulnerabilities and should be investigated for potential security risks.
"""
false_positives = [
    "Legitimate use of deprecated AMIs for testing or development purposes.",
    "Automated tools or scripts that query for deprecated AMIs as part of a security assessment.",
    "Misconfigured applications or services that rely on deprecated AMIs for compatibility reasons.",
    "Administrators or developers who are unaware of the deprecation status of AMIs they are using.",
]
from = "now-6m"
interval = "5m"
index = ["filebeat-*", "logs-aws.cloudtrail-*"]
language = "kuery"
license = "Elastic License v2"
name = "AWS EC2 Deprecated AMI Discovery"
note = """## Triage and analysis

### Investigating AWS EC2 Deprecated AMI Discovery

This rule detects when a user queries AWS for deprecated Amazon Machine Images (AMIs). While deprecated AMIs are not inherently malicious, their use can introduce vulnerabilities or misconfigurations. Adversaries may exploit deprecated AMIs in search of outdated or unpatched systems. Investigating these queries can help identify potential risks or misconfigurations.

### Possible investigation steps

**Identify the user**:
   - Review the `aws.cloudtrail.user_identity.arn` field to determine the AWS user or role making the request.
   - Check `aws.cloudtrail.user_identity.type` and `aws.cloudtrail.user_identity.access_key_id` to verify the type of access (e.g., IAM user, role, or federated identity).

**Analyze the source**:
   - Review the `source.ip` field to determine the IP address of the source making the request.
   - Check `source.geo` for the geographic location of the IP address.
   - Analyze the `user_agent.original` field to determine the client or tool used (e.g., AWS CLI, SDK).

**Validate the query context**:
   - Inspect the `aws.cloudtrail.request_parameters` field 
   - Determine if the request is part of legitimate activity, such as:
     - Security assessments or vulnerability scans.
     - Maintenance or testing of legacy systems.
   - Check if the query aligns with recent changes in the AWS environment, such as new configurations or services.

**Correlate with other events**:
   - Investigate additional AWS API calls from the same user or IP address for signs of reconnaissance or exploitation.
   - Review logs for related actions, such as launching instances from deprecated AMIs (`RunInstances` API call).

**Assess security risks**:
   - Evaluate the use of deprecated AMIs within your environment and their associated vulnerabilities.
   - Ensure that deprecated AMIs are not being used in production environments or systems exposed to external threats.

### False positive analysis

- Users may query for deprecated AMIs for testing or compatibility purposes.
- Security or compliance tools might query deprecated AMIs as part of regular assessments.
- Legacy systems may rely on deprecated AMIs for compatibility, leading to legitimate queries.

### Response and remediation

**Immediate actions**:
   - Verify the intent of the user querying for deprecated AMIs.
   - Restrict IAM permissions to prevent unauthorized access to deprecated AMIs.

**Mitigation steps**:
   - Identify and replace deprecated AMIs in use with supported and updated AMIs.
   - Update AWS IAM policies to minimize permissions for querying or using deprecated AMIs.

**Enhance monitoring**:
   - Enable alerts for future queries involving deprecated AMIs or other unusual API activity.
   - Monitor CloudTrail logs for additional reconnaissance or suspicious behavior.

**Security audits**:
   - Conduct a review of all AMIs in use across your environment to identify outdated or deprecated images.
   - Remove any deprecated AMIs from production environments and restrict their usage to isolated testing.

**Add rule exceptions**:
   - Create exceptions for legitimate use cases or automated tools that query for deprecated AMIs.
   - Document and communicate the exceptions to relevant teams to avoid future alerts.

### Additional resources

- [AWS Documentation: AMI Lifecycle Management](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html)
- [AWS Documentation: Deprecated AMIs](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ami-deprecate.html)
"""
references = [
    "https://hackingthe.cloud/aws/exploitation/Misconfigured_Resource-Based_Policies/exploting_public_resources_attack_playbook/",
]
risk_score = 21
rule_id = "264c641e-c202-11ef-993e-f661ea17fbce"
severity = "low"
tags = [
    "Domain: Cloud",
    "Data Source: AWS",
    "Data Source: AWS EC2",
    "Resources: Investigation Guide",
    "Use Case: Threat Detection",
    "Tactic: Discovery",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset: "aws.cloudtrail"
    and event.provider: "ec2.amazonaws.com"
    and event.action: "DescribeImages"
    and event.outcome: "success"
    and aws.cloudtrail.flattened.request_parameters.includeDeprecated: "true"
'''
[rule.investigation_fields]
field_names = [
    "@timestamp",
    "user.name",
    "user_agent.original",
    "source.ip",
    "aws.cloudtrail.user_identity.arn",
    "aws.cloudtrail.user_identity.type",
    "aws.cloudtrail.user_identity.access_key_id",
    "event.action",
    "event.outcome",
    "cloud.account.id",
    "cloud.region",
    "aws.cloudtrail.request_parameters"
]

[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1580"
name = "Cloud Infrastructure Discovery"
reference = "https://attack.mitre.org/techniques/T1580/"


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

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

[rule]
author = ["Elastic"]
description = "Identifies a successful login to the AWS Management Console by the Root user."
false_positives = [
    """
    It's strongly recommended that the root user is not used for everyday tasks, including the administrative ones.
    Verify whether the IP address, location, and/or hostname should be logging in as root in your environment.
    Unfamiliar root logins should be investigated immediately. 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 Management Console Root Login"
note = """## Triage and analysis

### Investigating AWS Management Console Root Login

The AWS root user is the original identity with unrestricted privileges over every resource in the account. Because it bypasses IAM boundaries and carries irreversible privileges, any successful root console login should be treated as a critical security event. AWS explicitly recommends locking away the root credentials and only using them for a small number of account-level administrative tasks (for example, closing an account, modifying support plans, or restoring MFA). See [Tasks that require the root user](https://docs.aws.amazon.com/general/latest/gr/root-vs-iam.html#aws_tasks-that-require-root).

This rule detects a successful AWS Management Console login by the root user (`ConsoleLogin` events with `userIdentity.type: Root` and `event.outcome: Success`).

#### Possible investigation steps

- **Confirm legitimacy.**  
  Contact the designated root credential custodian or account owner to verify whether this login was expected and approved. Root access should only occur under documented change-control conditions.

- **Review contextual event details.**  
  Examine the CloudTrail fields in the alert:
  - `source.ip` – does it match known corporate IPs or expected admin VPNs?  
  - `user_agent.original` – browser or automation?  
  - `geo fields` – consistent with normal operations?  
  - `@timestamp` – within a planned maintenance window?

- **Check for prior or subsequent root activity.**  
  Query CloudTrail for the last 30–90 days for any other root logins or root-initiated API calls. Multiple or recent root logins can indicate credential misuse.

- **Correlate follow-on actions.**  
  Look for risky API calls immediately after the login, such as:
  - `CreateUser`, `CreateAccessKey`, `AttachRolePolicy`, `PutBucketPolicy`, `UpdateAssumeRolePolicy`, `DeleteTrail`, or `StopLogging`.  
  These actions may indicate persistence or cover-up attempts.

- **Cross-account verification.**  
  If the root user is federated through AWS Organizations or linked accounts, confirm no simultaneous logins occurred elsewhere.

### False positive analysis

- **Planned administrative actions.**  
  Some rare maintenance tasks require root credentials (for example, payment method updates). If the login aligns with documented change control and was performed using MFA by the approved owner, the alert can be closed as benign.
- **Third-party managed account scenarios.**  
  Managed service providers may log in as root during onboarding or support activities. Confirm via ticketing or contractual documentation.

### Response and remediation

**Immediate verification and containment**
- If the login was not authorized or cannot be confirmed quickly:  
  - Reset the root password using the AWS Management Console.  
  - Rotate or remove any root access keys (root keys should normally not exist).  
  - Ensure MFA is enabled and enforced on the root account.  
  - Notify your security operations or cloud governance team.

**Evidence preservation**
- Export the alert’s CloudTrail record and all subsequent events for 1 hour after the login.  
  Store them in a restricted, immutable S3 evidence bucket.  
- Retain related GuardDuty findings, AWS Config history, and CloudTrail logs for the same period.

**Scope and investigation**
- Review additional events under the same `source.ip` to detect resource creation, IAM changes, or billing actions.  
- Inspect newly created users, roles, or keys since the login time to identify potential persistence mechanisms.  
- Check for any disabled or deleted CloudTrail trails, Security Hub findings suppression, or logging configuration changes.

**Recovery and hardening**
- Confirm MFA is working and only the authorized owner can access the root credentials.  
- Store root credentials in an offline vault under dual-custody control.  
- Enable organization-wide CloudTrail, GuardDuty, and Security Hub across all regions.  
- Implement policy and automation to alert on any future `userIdentity.type: Root` logins in real time.  
- Conduct a short post-incident review to update root-access procedures and reinforce least-privilege IAM practices.

### Additional information

- **[AWS IR Playbooks](https://github.com/aws-samples/aws-incident-response-playbooks/tree/c151b0dc091755fffd4d662a8f29e2f6794da52c/playbooks):** See “Account Compromise” and “Credential Compromise” playbooks for containment and recovery procedures.  
- **[AWS Customer Playbook Framework](https://github.com/aws-samples/aws-customer-playbook-framework/tree/a8c7b313636b406a375952ac00b2d68e89a991f2/docs):** Reference “Account Access Investigation” for evidence handling and credential rotation steps.  
- **AWS Documentation:** [Tasks that require the root user](https://docs.aws.amazon.com/general/latest/gr/root-vs-iam.html#aws_tasks-that-require-root).  
- **Security Best Practices:** [AWS Knowledge Center – Security Best Practices](https://aws.amazon.com/premiumsupport/knowledge-center/security-best-practices/).  

"""
references = ["https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html"]
risk_score = 47
rule_id = "e2a67480-3b79-403d-96e3-fdd2992c50ef"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Data Source: AWS",
    "Data Source: Amazon Web Services",
    "Data Source: AWS Sign-In",
    "Use Case: Identity and Access Audit",
    "Resources: Investigation Guide",
    "Tactic: Initial Access",
    "Tactic: Privilege Escalation",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:aws.cloudtrail and 
event.provider:signin.amazonaws.com and 
event.action:ConsoleLogin and 
aws.cloudtrail.user_identity.type:Root and 
event.outcome:success
'''

[rule.investigation_fields]
field_names = [
    "@timestamp",
    "user_agent.original",
    "source.ip",
    "aws.cloudtrail.user_identity.arn",
    "aws.cloudtrail.user_identity.type",
    "event.action",
    "event.outcome",
    "aws.cloudtrail.console_login.additional_eventdata.mfa_used",
    "cloud.account.id",
    "cloud.region",
    "aws.cloudtrail.response_elements"
]

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

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

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

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

[rule]
author = ["Elastic"]
description = """
Identifies excessive secret or key retrieval operations from Azure Key Vault. This rule detects when a user principal
retrieves secrets or keys from Azure Key Vault multiple times within a short time frame, which may indicate potential
abuse or unauthorized access attempts. The rule focuses on high-frequency retrieval operations that deviate from normal
user behavior, suggesting possible credential harvesting or misuse of sensitive information.
"""
false_positives = [
    """
    Service accounts or applications that frequently access Azure Key Vault for configuration or operational purposes
    may trigger this rule.
    """,
    """
    Automated scripts or processes that retrieve secrets or keys for legitimate purposes, such as secret rotation or
    application configuration, may also lead to false positives.
    """,
    """
    Security teams performing routine audits or assessments that involve retrieving keys or secrets from Key Vaults may
    trigger this rule if they perform multiple retrievals in a short time frame.
    """,
]
from = "now-9m"
interval = "8m"
language = "esql"
license = "Elastic License v2"
name = "Azure Key Vault Excessive Secret or Key Retrieved"
note = """## Triage and analysis

### Investigating Azure Key Vault Excessive Secret or Key Retrieved

Azure Key Vault is a cloud service that safeguards encryption keys and secrets like certificates, connection strings, and passwords. It is crucial for managing sensitive data in Azure environments. Unauthorized modifications to Key Vaults can lead to data breaches or service disruptions. This rule detects excessive secret or key retrieval operations from Azure Key Vault, which may indicate potential abuse or unauthorized access attempts.

### Possible investigation steps
- Review the `azure.platformlogs.identity.claim.upn` field to identify the user principal making the retrieval requests. This can help determine if the activity is legitimate or suspicious.
- Check the `azure.platformlogs.identity.claim.appid` or `azure.platformlogs.identity.claim.appid_display_name` to identify the application or service making the requests. If the application is not recognized or authorized, it may indicate a potential security incident. It is plausible that the application is a FOCI compliant application, which are commonly abused by adversaries to evade security controls or conditional access policies.
- Analyze the `azure.platformlogs.resource.name` field to determine which Key Vault is being accessed. This can help assess the impact of the retrieval operations and whether they target sensitive resources.
- Review the `event.action` field to confirm the specific actions being performed, such as `KeyGet`, `SecretGet`, or `CertificateGet`. These actions indicate retrieval of keys, secrets, or certificates from the Key Vault.
- Check the `source.ip` or `source.geo.*` fields to identify the source of the retrieval requests. Look for unusual or unexpected IP addresses, especially those associated with known malicious activity or geographic locations that do not align with the user's typical behavior.
- Use the `time_window` field to analyze the frequency of retrieval operations. If multiple retrievals occur within a short time frame (e.g., within a few minutes), it may indicate excessive or suspicious activity.
- Correlate the retrieval operations with other security events or alerts in the environment to identify any patterns or related incidents.
- Triage the user with Entra ID sign-in logs to gather more context about their authentication behavior and any potential anomalies.

### False positive analysis
- Routine administrative tasks or automated scripts may trigger excessive retrievals, especially in environments where Key Vaults are heavily utilized for application configurations or secrets management. If this is expected behavior, consider adjusting the rule or adding exceptions for specific applications or user principals.
- Legitimate applications or services may perform frequent retrievals of keys or secrets for operational purposes, such as configuration updates or secret rotation. If this is expected behavior, consider adjusting the rule or adding exceptions for specific applications or user principals.
- Security teams may perform periodic audits or assessments that involve retrieving keys or secrets from Key Vaults. If this is expected behavior, consider adjusting the rule or adding exceptions for specific user principals or applications.
- Some applications may require frequent access to keys or secrets for normal operation, leading to high retrieval counts. If this is expected behavior, consider adjusting the rule or adding exceptions for specific applications or user principals.

### Response and remediation
- Investigate the user principal making the excessive retrieval requests to determine if they are authorized to access the Key Vault and its contents. If the user is not authorized, take appropriate actions to block their access and prevent further unauthorized retrievals.
- Review the application or service making the requests to ensure it is legitimate and authorized to access the Key Vault. If the application is unauthorized or suspicious, consider blocking it and revoking its permissions to access the Key Vault.
- Assess the impact of the excessive retrieval operations on the Key Vault and its contents. Determine if any sensitive data was accessed or compromised during the retrievals.
- Implement additional monitoring and alerting for the Key Vault to detect any further suspicious activity or unauthorized access attempts.
- Consider implementing stricter access controls or policies for Key Vaults to limit excessive retrievals and ensure that only authorized users and applications can access sensitive keys and secrets.
- Educate users and administrators about the risks associated with excessive retrievals from Key Vaults and encourage them to follow best practices for managing keys and secrets in Azure environments.
"""
references = ["https://www.inversecos.com/2022/05/detection-and-compromise-azure-key.html"]
risk_score = 43
rule_id = "c07f7898-5dc3-11f0-9f27-f661ea17fbcd"
setup = """#### Required Azure Key Vault Diagnostic Logs

To ensure this rule functions correctly, the following diagnostic logs must be enabled for Azure Key Vault:
- AuditEvent: This log captures all read and write operations performed on the Key Vault, including secret, key, and certificate retrievals. These logs should be streamed to the Event Hub used for the Azure integration configuration.
"""
severity = "medium"
tags = [
    "Domain: Cloud",
    "Domain: Storage",
    "Domain: Identity",
    "Data Source: Azure",
    "Data Source: Azure Platform Logs",
    "Data Source: Azure Key Vault",
    "Use Case: Threat Detection",
    "Use Case: Identity and Access Audit",
    "Tactic: Credential Access",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "esql"

query = '''
from logs-azure.platformlogs-* metadata _id, _index

// Filter for Azure Key Vault read operations
| where data_stream.dataset == "azure.platformlogs"
  and event.action in (
    "VaultGet",
    "KeyGet",
    "KeyList",
    "KeyListVersions",
    "KeyGetDeleted",
    "KeyListDeleted",
    "SecretGet",
    "SecretList",
    "SecretListVersions",
    "SecretGetDeleted",
    "SecretListDeleted",
    "CertificateGet",
    "CertificateList",
    "CertificateListVersions",
    "CertificateGetDeleted",
    "CertificateListDeleted",
    "CertificatePolicyGet",
    "CertificateContactsGet",
    "CertificateIssuerGet",
    "CertificateIssuersList"
  )

// Truncate timestamps into 1-minute windows
| eval Esql.time_window_date_trunc = date_trunc(1 minute, @timestamp)

// Aggregate identity, geo, resource, and activity info
| stats
    Esql_priv.azure_platformlogs_identity_claim_upn_values = values(azure.platformlogs.identity.claim.upn),
    Esql.azure_platformlogs_identity_claim_upn_count_distinct = count_distinct(azure.platformlogs.identity.claim.upn),
    Esql.azure_platformlogs_identity_claim_appid_values = values(azure.platformlogs.identity.claim.appid),

    Esql.source_ip_values = values(source.ip),
    Esql.source_geo_city_values = values(source.geo.city_name),
    Esql.source_geo_region_values = values(source.geo.region_name),
    Esql.source_geo_country_values = values(source.geo.country_name),
    Esql.source_as_organization_name_values = values(source.as.organization.name),

    Esql.event_action_values = values(event.action),
    Esql.event_count = count(*),
    Esql.event_action_count_distinct = count_distinct(event.action),
    Esql.azure_resource_name_count_distinct = count_distinct(azure.resource.name),
    Esql.azure_resource_name_values = values(azure.resource.name),
    Esql.azure_platformlogs_result_type_values = values(azure.platformlogs.result_type),
    Esql.cloud_region_values = values(cloud.region),

    Esql.agent_name_values = values(agent.name),
    Esql.azure_subscription_id_values = values(azure.subscription_id),
    Esql.azure_resource_group_values = values(azure.resource.group),
    Esql.azure_resource_id_values = values(azure.resource.id)

by Esql.time_window_date_trunc, azure.platformlogs.identity.claim.upn

// keep relevant fields
| keep
    Esql.time_window_date_trunc,
    Esql_priv.azure_platformlogs_identity_claim_upn_values,
    Esql.azure_platformlogs_identity_claim_upn_count_distinct,
    Esql.azure_platformlogs_identity_claim_appid_values,
    Esql.source_ip_values,
    Esql.source_geo_city_values,
    Esql.source_geo_region_values,
    Esql.source_geo_country_values,
    Esql.source_as_organization_name_values,
    Esql.event_action_values,
    Esql.event_count,
    Esql.event_action_count_distinct,
    Esql.azure_resource_name_count_distinct,
    Esql.azure_resource_name_values,
    Esql.azure_platformlogs_result_type_values,
    Esql.cloud_region_values,
    Esql.agent_name_values,
    Esql.azure_subscription_id_values,
    Esql.azure_resource_group_values,
    Esql.azure_resource_id_values

// Filter for suspiciously high volume of distinct Key Vault reads by a single actor
| where Esql.azure_platformlogs_identity_claim_upn_count_distinct == 1 and Esql.event_count >= 10 and Esql.event_action_count_distinct >= 2

| sort Esql.time_window_date_trunc desc
'''


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

[[rule.threat.technique]]
id = "T1555"
name = "Credentials from Password Stores"
reference = "https://attack.mitre.org/techniques/T1555/"

[[rule.threat.technique.subtechnique]]
id = "T1555.006"
name = "Cloud Secrets Management Stores"
reference = "https://attack.mitre.org/techniques/T1555/006/"

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

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

[[rule.threat.technique]]
id = "T1213"
name = "Data from Information Repositories"
reference = "https://attack.mitre.org/techniques/T1213/"

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

[rule]
description = """
Identifies an untrusted or unsigned process accessing cloud credential and configuration files. Adversaries may attempt
to access these files in order to gain access to sensitive data, laterally move or gain initial access into a cloud
environment.
"""
id = "caf1b0eb-ab71-4474-84cf-d7821ec0c292"
license = "Elastic License v2"
name = "Cloud Credential Files Accessed by Process in Suspicious Directory"
os_list = ["macos"]
version = "1.0.13"

query = '''
file where event.action == "open" and 
 file.path like~ ("/Users/*/.aws/*", "/Users/*/.config/gcloud/credentials.db", "/Users/*/.azure/*") and
 Effective_process.executable != null and
 (Effective_process.executable like~
                                 ("/Users/Shared/*",
                                  "/Users/*/Public/*",
                                  "/private/tmp/*",
                                  "/tmp/*",
                                  "/var/root/*",
                                  "/Library/WebServer/*",
                                  "/Library/Graphics/*",
                                  "/Library/Fonts/*",
                                  "/private/var/root/Library/HTTPStorages/*",
                                  "/private/var/root/Library/*") or
  process.executable like~ ("/Users/Shared/*",
                            "/Users/*/Public/*",
                            "/private/tmp/*",
                            "/tmp/*",
                            "/var/root/*",
                            "/Library/WebServer/*",
                            "/Library/Graphics/*",
                            "/Library/Fonts/*",
                            "/private/var/root/Library/HTTPStorages/*",
                            "/private/var/root/Library/*")) and
 not process.name like~ "python*" and
 not process.executable like ("/opt/homebrew/*", "/usr/local/Cellar/*") and 
 not (process.executable like ("/private/tmp/claude-*/go-build*.test", 
      "/private/tmp/*/.terraform/providers/registry.opentofu.org/hashicorp/aws/*/terraform-provider-aws",
      "/private/tmp/*/.terraform/providers/registry.terraform.io/hashicorp/aws/*/terraform-provider-aws*",
      "/private/tmp/f2-agentcore-*/bin/Debug/net*/f2-agentcore-*") and file.name in ("credentials", "config")) and 
 not Effective_process.executable in ("/Applications/Cursor.app/Contents/MacOS/Cursor")
'''

min_endpoint_version = "8.11.1"
optional_actions = []
[[actions]]
action = "kill_process"
field = "Effective_process.entity_id"
state = 0

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

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



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

[internal]
min_endpoint_version = "8.11.1"

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

[rule]
author = ["Elastic"]
description = """
Detects when the issuer URL of a federated identity credential is changed on an Entra ID application. Adversaries may
modify the issuer to point to an attacker-controlled identity provider, enabling them to authenticate as the
application's service principal and gain persistent access to Azure resources. This technique allows bypassing
traditional authentication controls by federating trust with a malicious external identity provider.
"""
from = "now-9m"
language = "esql"
license = "Elastic License v2"
name = "Entra ID Federated Identity Credential Issuer Modified"
note = """## Triage and analysis

### Investigating Entra ID Federated Identity Credential Issuer Modified

This rule detects when the issuer URL within a federated identity credential is modified on an Entra ID application. Federated identity credentials allow applications to authenticate using tokens from external identity providers (like GitHub Actions, AWS, etc.) without managing secrets. Adversaries can abuse this by changing the issuer to an attacker-controlled identity provider, allowing them to generate valid tokens and authenticate as the application's service principal.

This technique provides persistent access to Azure resources with the application's permissions and bypasses secret-based authentication controls.

### Possible investigation steps

- Review `azure.auditlogs.properties.initiated_by.user.userPrincipalName` and `ipAddress` to identify who made the change and from where.
- Examine the `Esql.external_idp_old_issuer` and `Esql.external_idp_new_issuer` fields to determine if the new issuer is expected or potentially malicious.
- Check if the new issuer domain is controlled by the organization or if it's an external/suspicious domain.
- Review the application's assigned roles and permissions to understand the scope of access gained.
- Use `azure.correlation_id` to pivot to related changes in the same session.
- Check for subsequent Azure sign-in activity using the modified federated credential.
- Investigate if the application has been used to access sensitive resources after the change.

### False positive analysis

- Legitimate migrations from one identity provider to another (e.g., GitHub to GitLab) may trigger this detection.
- DevOps teams may update issuer URLs as part of CI/CD pipeline changes.
- Validate any changes with the application owner or DevOps team before taking action.

### Response and remediation

- If the change is unauthorized, immediately remove or revert the federated identity credential.
- Rotate any secrets or certificates associated with the application.
- Review Azure sign-in logs and audit logs for any unauthorized activity using the application's identity.
- Disable the application or service principal if compromise is confirmed.
- Investigate how the unauthorized change occurred (e.g., compromised admin account, over-privileged service principal).
- Implement conditional access policies and PIM (Privileged Identity Management) to protect application management operations.
"""
references = [
    "https://dirkjanm.io/persisting-with-federated-credentials-entra-apps-managed-identities/",
    "https://learn.microsoft.com/en-us/entra/workload-id/workload-identity-federation",
]
risk_score = 73
rule_id = "498e4094-60e7-11f0-8847-f661ea17fbcd"
setup = """### Microsft Entra ID Audit Logs
This rule requires the Azure integration with Microsoft Entra ID Audit Logs data stream ingesting in your Elastic Stack deployment. For more information, refer to the [Microsoft Entra ID Audit Logs integration documentation](https://www.elastic.co/docs/reference/integrations/azure/adlogs).
"""
severity = "high"
tags = [
    "Domain: Cloud",
    "Domain: Identity",
    "Data Source: Azure",
    "Data Source: Microsoft Entra ID",
    "Data Source: Microsoft Entra ID Audit Logs",
    "Use Case: Identity and Access Audit",
    "Tactic: Persistence",
    "Tactic: Privilege Escalation",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "esql"

query = '''
from logs-azure.auditlogs-* metadata _id, _version, _index
| where event.action == "Update application"
| where `azure.auditlogs.properties.target_resources.0.modified_properties.0.display_name` == "FederatedIdentityCredentials"
| eval Esql.target_resources_old_value_clean = replace(`azure.auditlogs.properties.target_resources.0.modified_properties.0.old_value`, "\\\\", "")
| eval Esql.target_resources_new_value_clean = replace(`azure.auditlogs.properties.target_resources.0.modified_properties.0.new_value`, "\\\\", "")
| dissect Esql.target_resources_old_value_clean "%{}\"Issuer\":\"%{Esql.external_idp_old_issuer}\"%{}"
| dissect Esql.target_resources_new_value_clean "%{}\"Issuer\":\"%{Esql.external_idp_new_issuer}\"%{}"
| where Esql.external_idp_old_issuer is not null and Esql.external_idp_new_issuer is not null
| where Esql.external_idp_old_issuer != Esql.external_idp_new_issuer
| keep @timestamp, Esql.*, azure.*, event.*, cloud.*, related.*, tags, source.*, agent.*, client.*, _id, _version, _index, data_stream.namespace
'''


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

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

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

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

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

[[rule.threat.technique]]
id = "T1484"
name = "Domain or Tenant Policy Modification"
reference = "https://attack.mitre.org/techniques/T1484/"

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

[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 = "T1484"
name = "Domain or Tenant Policy Modification"
reference = "https://attack.mitre.org/techniques/T1484/"

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

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

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

[rule]
author = ["Elastic"]
description = """
Identifies an illicit consent grant request on-behalf-of a registered Entra ID application. Adversaries may create and
register an application in Microsoft Entra ID for the purpose of requesting user consent to access resources. This is
accomplished by tricking a user into granting consent to the application, typically via a pre-made phishing URL. This
establishes an OAuth grant that allows the malicious client applocation to access resources on-behalf-of the user.
"""
from = "now-7d"
interval = "8m"
language = "esql"
license = "Elastic License v2"
name = "Entra ID Illicit Consent Grant via Registered Application"
note = """## Triage and analysis

### Investigating Entra ID Illicit Consent Grant via Registered Application

Adversaries may register a malicious application in Microsoft Entra ID and trick users into granting excessive permissions via OAuth consent. These applications can access sensitive data—such as mail, profiles, or files—on behalf of the user once consent is granted. This is commonly delivered via spearphishing links that prompt users to approve permissions for seemingly legitimate applications.

This rule identifies a new consent grant event based on Azure audit logs where a user or admin granted consent to an application.

This rule uses ES|QL aggregation-based new terms logic with a 7-day history window. It extracts the AppId from the multi-valued additional_details array using MV_EXPAND and UUID regex filtering, then alerts when the user-application pair is first seen within the last 9 minutes. Alerts are suppressed by AppId and user principal name for 6 hours. Each distinct user-application pair therefore produces a single alert, preserving per-victim visibility: an application consented to by multiple users raises one alert per user, so the spread of a consent phishing campaign remains visible in the alert list.

#### Possible investigation steps

- Review `azure.auditlogs.properties.additional_details.value` to identify the AppId and User-Agent values to determine which application was granted access and how the request was initiated. Pivot on the AppId in the Azure portal under Enterprise Applications to investigate further.
- Review `azure.auditlogs.properties.initiated_by.user.userPrincipalName` to identify the user who approved the application. Investigate their recent activity for signs of phishing, account compromise, or anomalous behavior during the timeframe of the consent.
- Review `azure.auditlogs.properties.initiated_by.user.ipAddress` to assess the geographic source of the consent action. Unexpected locations or IP ranges may indicate adversary-controlled infrastructure.
- Review `azure.auditlogs.properties.target_resources.display_name` to evaluate whether the application name is familiar, expected, or potentially spoofing a known service.
- Review `azure.auditlogs.properties.target_resources.modified_properties.display_name` to inspect key indicators of elevated privilege or risk, including:
  - ConsentContext.IsAdminConsent to determine if the application was granted tenant-wide admin access.
  - ConsentContext.OnBehalfOfAll to identify whether the app was granted permissions on behalf of all users in the tenant.
  - ConsentAction.Permissions to evaluate the specific scopes and data access the application requested. Scope combinations such as `offline_access` with `Mail.ReadWrite`, `Files.ReadWrite.All`, or `Chat.Read` are characteristic of mailbox and file exfiltration.
  - ConsentAction.Reason to determine whether Microsoft's own risk heuristics flagged the application. A value of `Risky application detected` means Microsoft scored the app as suspicious at the time consent was granted and should raise the priority of the review. Note this reason is only populated on admin-consent events, and its absence does not clear the application; a flagged app is also not necessarily malicious, since Microsoft's heuristic can flag legitimate apps.
  - TargetId.ServicePrincipalNames to confirm the service principal associated with the granted permissions.
- Review `azure.tenant_id` to confirm the activity originated from your tenant and is not related to a cross-tenant application.
- Review `@timestamp` and `azure.auditlogs.properties.correlation_id` to pivot into related sign-in, token usage, or application activity for further context.

### False positive analysis

- Some applications may request high-privilege scopes for legitimate purposes. Validate whether the application is verified, developed by Microsoft, or approved internally by your organization.
- Review publisher verification, app ownership, and scope alignment with the intended business use case.
- A `ConsentAction.Reason` of `Risky application detected` raises confidence that the consent is worth investigating, but Microsoft's risk heuristic is advisory and can flag legitimate applications (including internal line-of-business apps and newly registered tenant applications). Conversely, the absence of the flag does not make the consent benign, so weigh it alongside the requested scopes, admin-consent context, and the application's home tenant rather than in isolation.

### Response and remediation

- Revoke the application’s OAuth grant using Graph API or PowerShell. Use the Remove-AzureADOAuth2PermissionGrant cmdlet.
- Remove the associated service principal from Azure AD.
- Reset credentials or revoke tokens for affected users.
- Block the application via Conditional Access or Defender for Cloud Apps policies.
- Enable the Admin Consent Workflow in Azure AD to prevent unsanctioned user approvals in the future.
- Report any malicious applications to Microsoft to protect other tenants.
"""
references = [
    "https://www.wiz.io/blog/midnight-blizzard-microsoft-breach-analysis-and-best-practices",
    "https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/detect-and-remediate-illicit-consent-grants?view=o365-worldwide",
    "https://www.cloud-architekt.net/detection-and-mitigation-consent-grant-attacks-azuread/",
    "https://docs.microsoft.com/en-us/defender-cloud-apps/investigate-risky-oauth#how-to-detect-risky-oauth-apps",
]
risk_score = 47
rule_id = "1c6a8c7a-5cb6-4a82-ba27-d5a5b8a40a38"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Domain: Identity",
    "Data Source: Azure",
    "Data Source: Microsoft Entra ID",
    "Data Source: Microsoft Entra ID Audit Logs",
    "Use Case: Identity and Access Audit",
    "Resources: Investigation Guide",
    "Tactic: Initial Access",
    "Tactic: Credential Access",
]
type = "esql"

query = '''
FROM logs-azure.auditlogs-* metadata _id, _version, _index
| WHERE (azure.auditlogs.operation_name == "Consent to application"
    OR event.action == "Consent to application")
  AND event.outcome == "success"

| MV_EXPAND azure.auditlogs.properties.additional_details.value
| WHERE azure.auditlogs.properties.additional_details.value
    RLIKE "[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}"
| RENAME azure.auditlogs.properties.additional_details.value AS Esql.app_id

| STATS
    Esql.timestamp_first_seen = MIN(@timestamp),
    Esql.timestamp_last_seen = MAX(@timestamp),
    Esql.app_display_name_values = VALUES(`azure.auditlogs.properties.target_resources.0.display_name`),
    Esql.service_principal_id_values = VALUES(`azure.auditlogs.properties.target_resources.0.id`),
    Esql.is_admin_consent_values = VALUES(`azure.auditlogs.properties.target_resources.0.modified_properties.0.new_value`),
    Esql.is_app_only_values = VALUES(`azure.auditlogs.properties.target_resources.0.modified_properties.1.new_value`),
    Esql.on_behalf_of_all_values = VALUES(`azure.auditlogs.properties.target_resources.0.modified_properties.2.new_value`),
    Esql.consent_context_tags_values = VALUES(`azure.auditlogs.properties.target_resources.0.modified_properties.3.new_value`),
    Esql.consent_permissions_values = VALUES(`azure.auditlogs.properties.target_resources.0.modified_properties.4.new_value`),
    Esql.consent_reason_values = VALUES(`azure.auditlogs.properties.target_resources.0.modified_properties.5.new_value`),
    Esql.user_id_values = VALUES(azure.auditlogs.properties.initiated_by.user.id),
    Esql.ip_address_values = VALUES(azure.auditlogs.properties.initiated_by.user.ipAddress),
    Esql.tenant_id_values = VALUES(azure.tenant_id),
    Esql.correlation_id_values = VALUES(azure.auditlogs.properties.correlation_id),
    Esql.event_count = COUNT(*)
    BY azure.auditlogs.properties.initiated_by.user.userPrincipalName, Esql.app_id

| WHERE Esql.timestamp_first_seen >= NOW() - 9 minutes
| KEEP Esql.*, azure.*
'''

[rule.alert_suppression]
group_by = ["azure.auditlogs.properties.initiated_by.user.userPrincipalName"]
duration = {value = 6, unit = "h"}
missing_fields_strategy = "suppress"


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

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

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

[[rule.threat.technique]]
id = "T1199"
name = "Trusted Relationship"
reference = "https://attack.mitre.org/techniques/T1199/"

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


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

[rule]
description = """
Identifies attempts to install an application-defined hook procedure to monitor keystroke messages. Adversaries may log
user keystrokes to intercept credentials or other information from the user as the user types them.
"""
id = "a7e3958f-3f07-495a-8b2f-2a1d342c943f"
license = "Elastic License v2"
name = "Keystrokes Input Capture via SetWindowsHookEx"
os_list = ["windows"]
reference = [
    "https://attack.mitre.org/techniques/T1056/001/",
    "https://www.elastic.co/security-labs/protecting-your-devices-from-information-theft-keylogger-protection",
]
version = "1.0.3"

query = '''
sequence by process.entity_id with maxspan=1m
[process where event.action == "start" and
 (process.Ext.relative_file_creation_time <= 900 or process.Ext.relative_file_name_modify_time <= 900) and
 (process.code_signature.trusted == false or process.code_signature.exists == false) and
 not user.id : ("S-1-5-18", "s-1-5-19", "S-1-5-20") and
 not process.hash.sha256 :
               ("fd47875b3f3fb8f3c0ff83c148d94c0794aa4686a0495ed9006b2dbe23feb958",
                "eca768e56ce3ab01984ab0e7e1401515a0a36b7380fed2b175b17a98b2bea6b8")]
[api where
  process.Ext.api.name == "SetWindowsHookEx" and process.Ext.api.parameters.hook_type == "WH_KEYBOARD_LL" and
  process.thread.Ext.call_stack_final_user_module.name == "Unknown" and
  not process.Ext.api.parameters.hook_module :
                     ("?:\\Program Files\\*", "?:\\Program Files (x86)\\*", "?:\\Windows\\*")]
'''

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

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



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

[internal]
min_endpoint_version = "8.10.0"

[metadata]
bypass_bbr_timing = true
creation_date = "2026/02/20"
integration = ["o365"]
maturity = "production"
updated_date = "2026/03/24"

[rule]
author = ["Elastic"]
building_block_type = "default"
description = """
Identifies Microsoft Entra ID (formerly Azure AD) risk detection signals including risky sign-ins, compromised
credentials, impossible travel, and other identity-based anomalies. These events indicate potential credential
compromise, account takeover attempts, or suspicious authentication patterns detected by Microsoft's identity
protection. This building block rule generates security events for correlation, threat hunting, and telemetry
collection to support detection of credential access and initial access attempts.
"""
from = "now-9m"
index = ["logs-o365.audit-*", "filebeat-*"]
language = "kuery"
license = "Elastic License v2"
name = "M365 Entra ID Risk Detection Signal"
references = [
    "https://learn.microsoft.com/en-us/entra/id-protection/concept-identity-protection-risks",
    "https://learn.microsoft.com/en-us/office/office-365-management-api/office-365-management-activity-api-schema#enum-auditlogrecordtype---type-edmint32",
]
risk_score = 21
rule_id = "cccc9be5-d8b0-466e-8a37-617eae57351a"
setup = """### Additional notes

For information on troubleshooting the maximum alerts warning please refer to this [guide](https://www.elastic.co/guide/en/security/current/alerts-ui-monitor.html#troubleshoot-max-alerts).
"""
severity = "low"
tags = [
    "Domain: Cloud",
    "Domain: SaaS",
    "Data Source: Microsoft 365",
    "Data Source: Microsoft 365 Audit Logs",
    "Data Source: Microsoft Entra ID",
    "Data Source: Microsoft Entra ID Protection",
    "Use Case: Threat Detection",
    "Use Case: Identity Threat Detection",
    "Tactic: Credential Access",
    "Tactic: Initial Access",
    "Rule Type: BBR",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
event.dataset:o365.audit and event.code:AadRiskDetection
'''


[[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.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.threat]]
framework = "MITRE ATT&CK"

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

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

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

[metadata]
creation_date = "2026/06/30"
integration = ["m365_defender"]
maturity = "production"
promotion = true
updated_date = "2026/06/30"

[rule]
author = ["Elastic"]
description = """
Generates a detection alert for each Microsoft Defender XDR alert written to the configured indices. Microsoft Defender
emits multiple update events for the same alert over its lifecycle, all sharing a stable alert identifier. This rule
suppresses those update events so that a single, continuous Elastic alert is maintained per Defender alert rather than a
new alert per update. Enabling this rule allows you to immediately begin investigating Microsoft Defender XDR alerts in
the app.
"""
from = "now-2m"
index = ["logs-m365_defender.alert-*"]
interval = "1m"
language = "kuery"
license = "Elastic License v2"
max_signals = 1000
name = "Microsoft Defender XDR Alert External Alerts"
note = """## Triage and analysis

### Investigating Microsoft Defender XDR Alert External Alerts

Microsoft Defender XDR is a unified pre- and post-breach enterprise defense suite that natively coordinates detection, prevention, investigation, and response across endpoints, identities, email, and applications. The alert data stream (`logs-m365_defender.alert-*`) carries pre-correlated alerts already triaged by Defender. This rule promotes each Defender alert into an Elastic detection alert so analysts can investigate without leaving the app.

Microsoft Defender emits several update events for the same alert as its status, classification, and evidence evolve. Every update shares the same stable Defender alert identifier (`m365_defender.alert.id`, which the integration also copies into `event.id`). The rule groups on that identifier so subsequent updates accumulate into the existing Elastic alert rather than creating duplicates.

If you also collect Microsoft Defender alerts through the Microsoft 365 Unified Audit Log (`logs-o365.audit-*`) rather than the native integration data stream, the M365 Defender Alerts Signal (UAL) building block rule (rule_id: 054853f3-2ce0-41f3-a6eb-4a4867f39cdc) generates correlation signals from that source and can be used alongside this promotion rule.

### Possible investigation steps

- Review `m365_defender.alert.title`, `m365_defender.alert.category`, and `m365_defender.alert.threat_display_name` to understand what Defender detected.
- Pivot to the Defender portal using `m365_defender.alert.incident_web_url.original` for the full evidence graph, process tree, and remediation status.
- Examine the evidence fields under `m365_defender.alert.evidence.*` (host, file, process, user account, URL, sender) to scope the impacted entities.
- Check `m365_defender.alert.incident_id` to correlate the alert with its parent Defender incident and any sibling alerts.
- Review `m365_defender.alert.status` and `m365_defender.alert.classification` to see whether Defender has already resolved or classified the alert.

### False positive analysis

- Defender alerts are pre-correlated and tuned by Microsoft, so true false positives are uncommon. When they occur, confirm with the responsible team before excluding.
- Alerts involving known and trusted administrative tools, security assessments, or scheduled automation may be benign. Validate intent before adding an exception.
- Use `m365_defender.alert.classification` and `m365_defender.alert.determination` to filter out activity Defender itself has marked as a false positive.

### Response and remediation

- Isolate affected endpoints or disable affected accounts if malicious behavior is confirmed.
- Use the Defender portal to action native response options (quarantine, automated investigation, account remediation) for the alert.
- Investigate how the threat entered the environment and close any exploited gaps.
- Reset credentials for compromised accounts or escalate to incident response.
- Document the findings and tune the upstream Defender policy or add an Elastic exception as appropriate.
"""
references = ["https://docs.elastic.co/en/integrations/m365_defender"]
risk_score = 47
rule_id = "c2a0e42b-ac3d-468f-82a5-0082066e1b59"
rule_name_override = "m365_defender.alert.title"
setup = """## Setup

### Microsoft Defender XDR Alert Integration
This rule is designed to capture alert events generated by the Microsoft Defender XDR integration and promote them as Elastic detection alerts.

To capture Microsoft Defender XDR alerts, install and configure the Microsoft Defender XDR integration to ingest alert events into the `logs-m365_defender.alert-*` index pattern.

### Alert suppression and the Defender update lifecycle

Microsoft Defender writes multiple update events per alert during its lifecycle, all sharing the same stable identifier (`m365_defender.alert.id`, copied to `event.id`). This rule suppresses on that identifier so updates accumulate into one Elastic alert. Note the following alert suppression semantics:

- Suppression applies going forward from when the suppressing alert is created; it does not retroactively merge alerts created before the rule was enabled.
- Updates are aggregated into the existing alert only while that alert is open and within the suppression window. If an analyst closes the suppressing alert, a later Defender update will open a new Elastic alert.
- The suppression window (default 1 day) is tunable. Size it to your environment's typical Defender alert lifecycle; extending it keeps a single alert open longer but delays new-alert creation for late updates.

### Avoiding duplicate alerts

To avoid double-counting, enable either this alert-level rule or the Microsoft Defender XDR Incident External Alerts rule (incident-level), not both: a Defender incident's child alerts appear in both data streams. Choose incident-level for the least noise (one Elastic alert per Defender incident) or alert-level for finer-grained, per-alert triage.

### Additional notes

For information on troubleshooting the maximum alerts warning please refer to this [guide](https://www.elastic.co/guide/en/security/current/alerts-ui-monitor.html#troubleshoot-max-alerts).
"""
severity = "medium"
tags = [
    "Data Source: Microsoft Defender XDR",
    "Use Case: Threat Detection",
    "Resources: Investigation Guide",
    "Promotion: External Alerts",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
event.kind: alert and data_stream.dataset: m365_defender.alert
'''


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

[[rule.severity_mapping]]
field = "m365_defender.alert.severity"
operator = "equals"
severity = "low"
value = "informational"

[[rule.severity_mapping]]
field = "m365_defender.alert.severity"
operator = "equals"
severity = "low"
value = "low"

[[rule.severity_mapping]]
field = "m365_defender.alert.severity"
operator = "equals"
severity = "medium"
value = "medium"

[[rule.severity_mapping]]
field = "m365_defender.alert.severity"
operator = "equals"
severity = "high"
value = "high"

[rule.alert_suppression]
group_by = ["m365_defender.alert.id", "m365_defender.alert.tenant_id"]
missing_fields_strategy = "doNotSuppress"

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

[metadata]
creation_date = "2025/08/20"
integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "m365_defender"]
maturity = "production"
updated_date = "2026/04/07"

[rule]
author = ["Elastic"]
description = """
Identifies known file and registry traces of the REMCOS Remote Access Trojan, including log files, persistence values, and cleanup artifacts. Adversaries use Remcos to maintain persistent remote access to compromised hosts.
"""
from = "now-9m"
index = [
    "endgame-*",
    "logs-endpoint.events.registry-*",
    "logs-endpoint.events.file-*",
    "logs-m365_defender.event-*",
    "logs-sentinel_one_cloud_funnel.*",
    "logs-windows.sysmon_operational-*",
    "winlogbeat-*",
]
language = "eql"
license = "Elastic License v2"
name = "Potential REMCOS Trojan Execution"
references = [
  "https://any.run/malware-trends/remcos",
  "https://attack.mitre.org/software/S0332/",
  "https://www.elastic.co/security-labs/exploring-the-ref2731-intrusion-set"
]
risk_score = 73
rule_id = "d8b2f85a-cf1c-40fc-acf0-bb5d588a8ea6"
severity = "high"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Command and Control",
    "Resources: Investigation Guide",
    "Data Source: Elastic Endgame",
    "Data Source: Elastic Defend",
    "Data Source: Sysmon",
    "Data Source: SentinelOne",
    "Data Source: Microsoft Defender XDR"
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
any where host.os.type == "windows" and
(
 (event.category == "file" and event.type == "deletion" and file.path like "?:\\Users\\*\\AppData\\Local\\Temp\\TH????.tmp") or

 (event.category == "file" and file.path : "?:\\Users\\*\\AppData\\Roaming\\remcos\\logs.dat") or

 (event.category == "registry" and
  registry.value : ("Remcos", "Rmc-??????", "licence") and
  registry.path : (
      "*\\Windows\\CurrentVersion\\Run\\Remcos",
      "*\\Windows\\CurrentVersion\\Run\\Rmc-??????",
      "*\\SOFTWARE\\Remcos-*\\licence",
      "*\\Software\\Rmc-??????\\licence"
  )
 )
)
'''

note = """## Triage and analysis

### Investigating Potential REMCOS Trojan Execution

#### Possible investigation steps

- Which Remcos-related artifact family matched, and does it indicate install, persistence, or cleanup evidence?
  - Focus: `event.category` plus the matched `file.path`, `registry.path`, `registry.value`, `registry.data.strings`, and whether the trace's user profile or hive scope matches `user.id`.
  - Implication: "logs.dat" indicates active or recent keystroke/clipboard logging; a Run-key or licence registry path indicates persistence is set; a temp-file deletion indicates installer cleanup. The artifact's user profile or hive scope identifies which account is compromised.

- Which process or user touched the Remcos trace, and does that writer fit detonation, remediation, or malware execution?
  - Focus: the recovered writer identity and launch context, especially `process.executable`, `process.code_signature.subject_name`, `process.parent.executable`, and `user.id`.
  - Hint: if the source event lacks process identity, recover the writer via `process.entity_id` or `process.pid` plus a tight time window on the same `host.id`.
  - Implication: if the writer is an unknown binary on a non-lab host, treat it as the Remcos payload or its installer. If the writer is a known sandbox, detonation engine, or IR cleanup tool on a designated lab host, the trace is expected.

- What payload or persistence target do adjacent file and registry events resolve to?
  - Focus: file and registry events on the same `host.id`: `file.path`, `file.Ext.original.path`, `registry.path`, `registry.data.strings`, and any payload or autorun target tied to `process.entity_id`.
  - Implication: a surviving Run-key target, startup copy, or staged binary under `%APPDATA%` or `%TEMP%` confirms the infection has active persistence and the payload is still present. Bounded removal of those artifacts without a surviving payload indicates cleanup is underway but verify that ALL persistence mechanisms are gone, not just the ones visible in the alert.

- Is there active outbound C2 or proxy traffic on this host?
  - Focus: host-scoped network events around the alert time, checking `dns.question.name`, `dns.resolved_ip`, `destination.ip`, `destination.port` for connections to rare public destinations, direct-IP egress, dynamic-DNS infrastructure, or unusual ports consistent with Remcos controller or SOCKS proxy use.
  - Implication: active C2 traffic confirms the infection is live and requires immediate containment; absence of C2 traffic may indicate the payload was already removed or has not yet activated. Missing network telemetry is unresolved, not benign.

- If the local evidence stays suspicious, does this host or user show related alerts that explain precursor compromise or follow-on access?
  - Focus: related alerts for the same `host.id` and `user.id` in the last 48 hours to identify delivery, persistence, credential, command-and-control, or lateral-movement activity.
    - $investigate_0
    - $investigate_1
  - Implication: broaden when the host or user shows delivery, credential theft, or follow-on remote-access alerts after the artifact; keep the case narrower when related activity is absent or resolves to one detonation or remediation workflow.

- Escalate when the artifact, writer, persistence status, C2 activity, or alert scope align with active Remcos execution; close only when all evidence fits a recognized detonation or remediation workflow; if mixed or incomplete, preserve and escalate.

### False positive analysis

- Malware-analysis or detonation hosts can legitimately create Remcos traces. Confirm it when the writer identity, `host.id`, and any network activity all stay inside a known lab or sandbox environment. If lab records are unavailable, require the same writer and `host.id` to recur across prior alerts.
- Incident-response cleanup can remove Remcos artifacts. Confirm it when the writer matches a known cleanup tool, surrounding events show bounded removal, and no new C2 or lateral-movement activity follows.

### Response and remediation

- If confirmed benign, reverse any temporary containment and document the confirmed writer, `host.id`, and artifact family that justified the closure. Create an exception only if that same workflow recurs consistently across prior alerts from this rule.
- If suspicious but unconfirmed, preserve the matched `file.path` or `registry.path`, `registry.data.strings`, recovered `process.entity_id`, writer executable and parent context. Apply the least disruptive reversible containment that matches the findings, starting with outbound restrictions on confirmed destinations and using host isolation only when active command-and-control or lateral movement is still plausible for that asset. Avoid destructive cleanup until scope is clearer.
- If confirmed malicious, use endpoint response to isolate the host after weighing host criticality and record the `process.entity_id`, command line, parent chain, and trace paths. If direct endpoint response is unavailable, escalate with that evidence set to the team that can contain the host and implicated accounts.
- Before eradicating or reimaging, review other hosts and users for the same writer identity, artifact family, or C2 destinations so scoping is complete. For confirmed infections, consider reimaging over manual cleanup -- Remcos can establish multiple persistence mechanisms and manual eradication risks missing one. If reimaging is not feasible, eradicate all identified Remcos artifacts including Run keys, licence-related registry paths, staged binaries, "logs.dat", and linked temp artifacts, then verify no alternate persistence survives.
- Post-incident hardening: review how the payload reached the host, restrict user-writable persistence paths where practical, and retain registry and network telemetry for Remcos-related activity.
"""

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:

- [Microsoft Defender XDR](https://ela.st/m365-defender)
- [SentinelOne Cloud Funnel](https://ela.st/sentinel-one-cloud-funnel)
- [Sysmon Event ID 11 - File Create](https://ela.st/sysmon-event-11-setup)
- [Sysmon Registry Events](https://ela.st/sysmon-event-reg-setup)
- [Sysmon Event ID 23 - File Delete](https://ela.st/sysmon-event-23-setup)
"""

[rule.investigation_fields]
field_names = [
    "@timestamp",
    "event.category",
    "event.type",
    "event.action",
    "host.name",
    "host.id",
    "user.name",
    "user.id",
    "process.name",
    "process.executable",
    "process.entity_id",
    "process.pid",
    "process.code_signature.subject_name",
    "file.path",
    "file.name",
    "registry.path",
    "registry.value",
    "registry.data.strings",
]

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

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

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

[[rule.threat.technique]]
id = "T1219"
name = "Remote Access Tools"
reference = "https://attack.mitre.org/techniques/T1219/"

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

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

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

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

[[rule.threat.technique]]
id = "T1547"
name = "Boot or Logon Autostart Execution"
reference = "https://attack.mitre.org/techniques/T1547/"

[[rule.threat.technique.subtechnique]]
id = "T1547.001"
name = "Registry Run Keys / Startup Folder"
reference = "https://attack.mitre.org/techniques/T1547/001/"

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

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

[rule]
author = ["Elastic"]
description = """
Detects file name patterns generated by the use of Sysinternals SDelete utility to securely delete a file via multiple
file overwrite and rename operations.
"""
from = "now-9m"
index = [
    "winlogbeat-*",
    "logs-endpoint.events.file-*",
    "logs-windows.sysmon_operational-*",
    "endgame-*",
    "logs-m365_defender.event-*",
    "logs-sentinel_one_cloud_funnel.*",
    "logs-crowdstrike.fdr*",
]
language = "eql"
license = "Elastic License v2"
name = "Potential Secure File Deletion via SDelete Utility"
note = """## Triage and analysis

### Investigating Potential Secure File Deletion via SDelete Utility

SDelete is a tool primarily used for securely deleting data from storage devices, making it unrecoverable. Microsoft develops it as part of the Sysinternals Suite. Although commonly used to delete data securely, attackers can abuse it to delete forensic indicators and remove files as a post-action to a destructive action such as ransomware or data theft to hinder recovery efforts.

This rule identifies file name patterns generated by the use of SDelete utility to securely delete a file via multiple file overwrite and rename operations.

#### Possible investigation steps

- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.
- Investigate other alerts associated with the user/host during the past 48 hours.
- Identify the user account that performed the action and whether it should perform this kind of action.
- Examine the command line and identify the files deleted, their importance and whether they could be the target of antiforensics activity.

### False positive analysis

- This is a dual-use tool, meaning its usage is not inherently malicious. Analysts can dismiss the alert if the administrator is aware of the activity, no other suspicious activity was identified, and there are justifications for the execution.

### Response and remediation

- Initiate the incident response process based on the outcome of the triage.
  - Prioritize cases involving critical servers and users.
- Isolate the involved hosts to prevent further post-compromise behavior.
- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services.
- If important data was encrypted, deleted, or modified, activate your data recovery plan.
    - Perform data recovery locally or restore the backups from replicated copies (cloud, other servers, etc.).
- 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.
- Review the privileges assigned to the user to ensure that the least privilege principle is being followed.
- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).
"""

setup = """## Setup

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

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

### Additional data sources

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

- [CrowdStrike](https://ela.st/crowdstrike-integration)
- [Microsoft Defender XDR](https://ela.st/m365-defender)
- [SentinelOne Cloud Funnel](https://ela.st/sentinel-one-cloud-funnel)
- [Sysmon Event ID 11 - File Create](https://ela.st/sysmon-event-11-setup)
"""

risk_score = 21
rule_id = "5aee924b-6ceb-4633-980e-1bde8cdb40c5"
severity = "low"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Defense Evasion",
    "Tactic: Impact",
    "Data Source: Elastic Endgame",
    "Resources: Investigation Guide",
    "Data Source: Elastic Defend",
    "Data Source: Sysmon",
    "Data Source: Microsoft Defender XDR",
    "Data Source: SentinelOne",
    "Data Source: Crowdstrike",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
file where host.os.type == "windows" and event.type == "change" and file.name : "*AAA.AAA"
'''


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



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


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

[rule]
description = """
This rule detects instances where an unprivileged user changes to the shadow group, via a world-/user-writeable process,
potentially indicating the execution of an exploit to read the shadow file.
"""
id = "1d796727-35a3-4d2c-93f0-2a745554b252"
license = "Elastic License v2"
name = "Potential Shadow Read via Unprivileged User"
os_list = ["linux"]
reference = ["https://github.com/0xdeadbeefnetwork/ssh-keysign-pwn"]
version = "1.0.1"

query = '''
process where event.type == "change" and event.action == "gid_change" and
group.name == "shadow" and user.id >= 1000 and process.parent.user.id >= 1000 and process.parent.group.id >= 1000 and
(
  process.parent.executable like (".*", "/tmp/*", "/dev/shm/*", "/var/tmp/*", "/home/*/*", "/run/user/*", "/var/run/user/*") or
  process.executable like (".*", "/tmp/*", "/dev/shm/*", "/var/tmp/*", "/home/*/*", "/run/user/*", "/var/run/user/*")
) and
not (
  process.group_leader.executable in (
    "/usr/sbin/lightdm", "/usr/bin/xfce4-session", "/usr/bin/ksmserver", "/tmp/newroot/usr/bin/xfce4-session"
  ) or
  process.executable in (
    "/tmp/newroot/usr/bin/i3lock", "/tmp/newroot/newroot/newroot/usr/bin/i3lock", "/tmp/newroot/bin/bash"
  )
)
'''

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

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

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1068"
name = "Exploitation for Privilege Escalation"
reference = "https://attack.mitre.org/techniques/T1068/"


[threat.tactic]
id = "TA0004"
name = "Privilege Escalation"
reference = "https://attack.mitre.org/tactics/TA0004/"
[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1003"
name = "OS Credential Dumping"
reference = "https://attack.mitre.org/techniques/T1003/"
[[threat.technique.subtechnique]]
id = "T1003.008"
name = "/etc/passwd and /etc/shadow"
reference = "https://attack.mitre.org/techniques/T1003/008/"



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

[internal]
min_endpoint_version = "8.6.0"

[rule]
description = """
Identifies the use of VMdetect utility to avoid execution on Malware sandboxes and virtual machines. An adversary may
attempt to get detailed information about the operating system and hardware.
"""
id = "75226c55-55b5-47b6-b27a-757b895c3bce"
license = "Elastic License v2"
name = "Potential Virtual Machine Fingerprinting via VMDetect"
os_list = ["windows"]
reference = ["https://github.com/dretax/VMDetect"]
version = "1.0.22"

query = '''
process where event.action == "start" and process.pe.original_file_name == "vmdetect.exe"
'''

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

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

[[threat.technique]]
id = "T1497"
name = "Virtualization/Sandbox Evasion"
reference = "https://attack.mitre.org/techniques/T1497/"
[[threat.technique.subtechnique]]
id = "T1497.001"
name = "System Checks"
reference = "https://attack.mitre.org/techniques/T1497/001/"



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

[internal]
min_endpoint_version = "7.15.0"

[metadata]
creation_date = "2020/02/18"
maturity = "production"
promotion = true
updated_date = "2025/03/21"

[rule]
author = ["Elastic"]
description = """
Elastic Endgame detected Process Injection. Click the Elastic Endgame icon in the event.module column or the link in the
rule.reference column for additional information.
"""
from = "now-2m"
index = ["endgame-*"]
interval = "1m"
language = "kuery"
license = "Elastic License v2"
max_signals = 1000
name = "Process Injection - Detected - Elastic Endgame"
risk_score = 73
rule_id = "80c52164-c82a-402c-9964-852533d58be1"
setup = """## Setup

### Additional notes

For information on troubleshooting the maximum alerts warning please refer to this [guide](https://www.elastic.co/guide/en/security/current/alerts-ui-monitor.html#troubleshoot-max-alerts).
"""
severity = "high"
tags = ["Data Source: Elastic Endgame", "Use Case: Threat Detection", "Tactic: Privilege Escalation", "Resources: Investigation Guide"]
timestamp_override = "event.ingested"
type = "query"

query = '''
event.kind:alert and event.module:endgame and endgame.metadata.type:detection and (event.action:kernel_shellcode_event or endgame.event_subtype_full:kernel_shellcode_event)
'''
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 Process Injection - Detected - Elastic Endgame

Elastic Endgame is a security solution that monitors and detects suspicious activities like process injection, a technique often used by adversaries to execute malicious code within the address space of another process, thereby evading detection. This detection rule identifies such threats by analyzing alerts and specific event actions related to kernel shellcode, indicating potential privilege escalation attempts. By leveraging MITRE ATT&CK frameworks, it effectively flags high-risk activities, aiding analysts in mitigating threats.

### Possible investigation steps

- Review the alert details in the Elastic Endgame console by clicking the Elastic Endgame icon in the event.module column or the link in the rule.reference column to gather more context about the detected process injection.
- Examine the specific event.action and endgame.event_subtype_full fields to confirm the presence of kernel_shellcode_event, which indicates potential malicious activity.
- Analyze the process tree and parent-child relationships of the affected process to identify any unusual or unauthorized processes that may have initiated the injection.
- Check for any recent privilege escalation attempts or suspicious activities associated with the affected process by correlating with other alerts or logs in the system.
- Investigate the source and destination IP addresses, if available, to determine if there is any external communication that could suggest a command and control connection.
- Assess the risk and impact of the detected activity by considering the risk score and severity level, and prioritize response actions accordingly.
- If necessary, isolate the affected system to prevent further malicious activity and begin remediation efforts based on the findings.

### False positive analysis

- Legitimate software updates or patches may trigger process injection alerts. Users can create exceptions for known update processes by identifying their unique process names or hashes.
- Security tools or monitoring software that use process injection for legitimate purposes might be flagged. Users should whitelist these tools by specifying their process identifiers or paths.
- Custom scripts or automation tasks that interact with system processes could be misidentified as threats. Users can exclude these scripts by defining their execution context or command-line arguments.
- Debugging or development activities involving process manipulation might cause false positives. Users should consider excluding these activities during known development periods or within specific environments.
- Virtualization or sandboxing solutions that mimic process injection techniques for isolation purposes may be detected. Users can create exceptions for these solutions by recognizing their specific signatures or behaviors.

### Response and remediation

- Isolate the affected system immediately to prevent further spread of the malicious code. Disconnect it from the network and any shared resources.
- Terminate the malicious process identified by the alert to stop the execution of injected code. Use process management tools to safely end the process.
- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any additional threats or remnants of the attack.
- Review and analyze system logs and the specific event details from the alert to understand the scope of the intrusion and identify any other potentially compromised systems.
- Apply security patches and updates to the operating system and all software applications on the affected system to close any vulnerabilities exploited by the attacker.
- Restore the system from a known good backup taken before the incident occurred, ensuring that the backup is free from any malicious code.
- Report the incident to the appropriate internal security team or external authorities if required, providing them with detailed information about the attack and the steps taken for remediation."""


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


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

[rule]
description = """
Identifies the execution of scripts via HTML applications using Windows utilities rundll32.exe or mshta.exe. Adversaries
may bypass process and/or signature-based defenses by proxying execution of malicious content with signed binaries.
"""
id = "f0630213-c4c4-4898-9514-746395eb9962"
license = "Elastic License v2"
name = "Script Execution via Microsoft HTML Application"
os_list = ["windows"]
version = "1.0.38"

query = '''
process where event.action == "start" and
 (process.name : ("rundll32.exe", "mshta.exe") or
  process.pe.original_file_name in ("MSHTA.EXE", "RUNDLL32.EXE")) and
  (
     (process.command_line :
        (
        "*script*eval(*",
         "*script*GetObject*",
         "*.regread(*",
         "*WScript.Shell*",
         "*.run(*",
         "*).Exec()*",
         "*mshta*http*",
         "*mshtml*RunHTMLApplication*",
         "*mshtml*,#135*",
         "*StrReverse*",
         "*.RegWrite*",
         /* Issue #379 */
         "*window.close(*",
         "* Chr(*"
         )
     /* FPs observed in telemetry */
     and not process.parent.executable :
                  ("?:\\Program Files (x86)\\Citrix\\System32\\wfshell.exe",
                   "?:\\Program Files (x86)\\Microsoft Office\\Office*\\MSACCESS.EXE",
                   "?:\\Program Files\\Quokka.Works GTInstaller\\GTInstaller.exe")
     and not (process.name : "mshta.exe" and process.parent.name : "cscript.exe" and process.parent.command_line : "*GTInstaller.vbs*")
     ) or
    /* Issue #379 */
    (process.pe.original_file_name : "mshta.exe" and
     not process.command_line : ("*.hta*", "*.htm*", "-Embedding") and process.args_count >=2) or

     /* Execution of HTA file downloaded from the internet */
     (process.pe.original_file_name : "mshta.exe" and process.command_line : "*\\Users\\*\\Downloads\\*.hta*") or

     /* Execution of HTA file from archive */
     (process.pe.original_file_name : "mshta.exe" and
      process.args : ("?:\\Users\\*\\Temp\\7z*", "?:\\Users\\*\\Temp\\Rar$*", "?:\\Users\\*\\Temp\\Temp?_*", "?:\\Users\\*\\Temp\\BNZ.*")) or

     /* Execution of HTA file from mounted ISO files */
     (process.pe.original_file_name : "mshta.exe" and
      process.parent.name : ("explorer.exe", "cmd.exe", "powershell.exe") and process.working_directory : "?:\\") or

     /* Webdav */
     (process.name : "mshta.exe" and process.args : "\\\\*@*\\*")
   ) and

  /* FPs */
  not (process.parent.executable : "C:\\Windows\\SysWOW64\\runonce.exe" and
       process.args : "\"& 'C:\\System.sav\\util\\HpseuHostLauncher.ps1'\"\", 0 : window.close)") and
  not (process.name : "mshta.exe" and
       process.args : ("*\\Support\\AzureVirtualDesktop\\ImageSources\\DisableTeamsAutoStart.ps1*",
                       "*C:\\Program Files (x86)\\combit\\*\\ServicePackNotification.ps1*")) and
  not process.command_line :  ("*encodeURIComponent*", "*.Popup*", "*C:\\PROGRA~2*", "*\\Downloads\\download*.hta*", "*Readme_he-IL.hta*", "*cisco-secure-client-win*") and
  not (process.parent.name : "cmd.exe" and process.name : "mshta.exe" and process.args : "D:\\start.hta") and
  not (process.name : "mshta.exe" and process.parent.executable : "C:\\Windows\\SysWOW64\\cmd.exe" and
       process.parent.args : "C:\\HP Universal Print Driver\\*\\Installer\\Install.bat")
'''

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 = "T1218"
name = "System Binary Proxy Execution"
reference = "https://attack.mitre.org/techniques/T1218/"
[[threat.technique.subtechnique]]
id = "T1218.005"
name = "Mshta"
reference = "https://attack.mitre.org/techniques/T1218/005/"

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



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

[internal]
min_endpoint_version = "7.15.0"

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

[rule]
author = ["Elastic"]
description = """
This rule detects connections accepted by a simple HTTP web server in Python and PHP built-in modules. Adversaries may
create simple HTTP web servers to establish persistence on a compromised system by uploading a reverse or command shell
payload to the server web root, allowing them to regain remote access to the system if lost. This event may occur when
an attacker requests the server to execute a command or script via a potential backdoor.
"""
from = "now-9m"
index = ["logs-endpoint.events.process*", "logs-endpoint.events.network*"]
language = "eql"
license = "Elastic License v2"
name = "Simple HTTP Web Server Connection"
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 Simple HTTP Web Server Connection

Simple HTTP servers in Python and PHP are often used for development and testing, providing a quick way to serve web content. However, attackers can exploit these servers to maintain access on compromised Linux systems by deploying backdoors or executing commands remotely. The detection rule identifies suspicious server activity by monitoring for specific process patterns and command-line arguments indicative of these lightweight servers, flagging potential misuse for further investigation.

### Possible investigation steps

- Review the process details, including the process name and command line arguments, to confirm if the server was started using Python or PHP, as indicated by the query fields.
- Check the network connection details associated with the event, such as the source and destination IP addresses and ports, to identify any suspicious or unexpected connections.
- Investigate the user account under which the process was initiated to determine if it aligns with expected behavior or if it indicates potential unauthorized access.
- Examine the system logs and any related events around the time of the alert to identify any additional suspicious activities or anomalies.
- Assess the server's web root directory for any unauthorized files or scripts that could indicate a backdoor or malicious payload.
- Correlate this event with other alerts or indicators of compromise on the system to evaluate if this is part of a larger attack campaign.

### False positive analysis

- Development and testing environments may frequently trigger this rule when developers use Python or PHP's built-in HTTP servers for legitimate purposes. To manage this, consider excluding specific user accounts or IP addresses associated with development activities from the rule.
- Automated scripts or cron jobs that start simple HTTP servers for routine tasks can also generate false positives. Identify these scripts and add their process names or command-line patterns to an exception list.
- Educational or training environments where students are learning web development might cause alerts. In such cases, exclude the network segments or user groups associated with these activities.
- Internal tools or services that rely on lightweight HTTP servers for functionality might be flagged. Review these tools and whitelist their specific process names or command-line arguments to prevent unnecessary alerts.
- Temporary testing servers spun up for short-term projects can be mistaken for malicious activity. Document these instances and apply temporary exceptions during the project duration.

### Response and remediation

- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
- Terminate any suspicious Python or PHP processes identified by the detection rule to stop the potential backdoor or unauthorized server activity.
- Conduct a thorough review of the system's file system, focusing on the web root directory, to identify and remove any unauthorized scripts or payloads that may have been uploaded.
- Change all credentials associated with the compromised system, including SSH keys and passwords, to prevent attackers from regaining access.
- Restore the system from a known good backup if any unauthorized changes or persistent threats are detected that cannot be easily remediated.
- Implement network monitoring to detect any future unauthorized HTTP server activity, focusing on unusual process patterns and command-line arguments.
- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network."""
risk_score = 21
rule_id = "183f3cd2-4cc6-44c0-917c-c5d29ecdcf74"
setup = """## Setup

This rule requires data coming in from Elastic Defend.

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

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

#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
- Go to the Kibana home page and click "Add integrations".
- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
- Click "Add Elastic Defend".
- Configure the integration name and optionally add a description.
- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).
- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead.
For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
- Click "Save and Continue".
- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts.
For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
"""
severity = "low"
tags = [
    "Domain: Endpoint",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Persistence",
    "Tactic: Execution",
    "Tactic: Command and Control",
    "Data Source: Elastic Defend",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
sequence by process.entity_id with maxspan=1m
[process where host.os.type == "linux" and event.type == "start" and 
 (
  (process.name regex~ """php?[0-9]?\.?[0-9]{0,2}""" and process.command_line like "*-S*") or
  (process.name like "python*" and process.command_line like ("*--cgi*", "*CGIHTTPServer*"))
 ) and not process.parent.command_line == "runc init"
]
[network where host.os.type == "linux" and event.type == "start" and event.action == "connection_accepted"]
'''

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

[[rule.threat.technique]]
id = "T1505"
name = "Server Software Component"
reference = "https://attack.mitre.org/techniques/T1505/"

[[rule.threat.technique.subtechnique]]
id = "T1505.003"
name = "Web Shell"
reference = "https://attack.mitre.org/techniques/T1505/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 = "T1059"
name = "Command and Scripting Interpreter"
reference = "https://attack.mitre.org/techniques/T1059/"

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

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

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

[[rule.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.tactic]
id = "TA0011"
name = "Command and Control"
reference = "https://attack.mitre.org/tactics/TA0011/"