Elastic rules: 29

[rule]
description = """
This rule detects the `at` utility being launched through `udevadm`. The `at` utility is used to schedule tasks to be
run at a later time. This could be used by an attacker to establish persistence on a system. The `udevadm` utility is
used to manage device events and could be used to trigger the `at` utility to run at a specific time, providing a threat
actor with persistence.
"""
id = "47e5595e-1920-4fdd-9a1c-cf712e1112d1"
license = "Elastic License v2"
name = "At Utility Launched through Udevadm"
os_list = ["linux"]
reference = [
    "https://ch4ik0.github.io/en/posts/leveraging-Linux-udev-for-persistence/",
    "https://www.elastic.co/security-labs/sequel-on-persistence-mechanisms",
]
version = "1.0.4"

query = '''
process where event.type == "start" and event.action == "exec" and process.parent.name == "udevadm" and
process.name == "at"
'''

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

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



[threat.tactic]
id = "TA0002"
name = "Execution"
reference = "https://attack.mitre.org/tactics/TA0002/"
[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1037"
name = "Boot or Logon Initialization Scripts"
reference = "https://attack.mitre.org/techniques/T1037/"


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


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

[internal]
min_endpoint_version = "7.15.0"

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

[rule]
author = ["Elastic"]
description = """
Detects deletion, weakening, or version management of AWS Bedrock guardrails via the DeleteGuardrail, UpdateGuardrail,
DeleteEnforcedGuardrailConfiguration, or PutEnforcedGuardrailConfiguration APIs. Bedrock
guardrails enforce content, topic, word, and sensitive-information policies on model invocations. Deleting a guardrail,
loosening its policies, removing or overwriting the organization-enforced guardrail configuration, or creating a new
version to enforce a weakened configuration allows an adversary to bypass these protections — the cloud control-plane
equivalent of disabling a security tool. This activity should be validated against approved change management and the
responsible identity.
"""
false_positives = [
  """
  Platform or ML engineering teams may legitimately tune, iterate on, or decommission guardrails as part of normal
  development. If this is expected in your environment, the responsible identities can be exempted from the rule.
  """,
]
from = "now-6m"
index = ["logs-aws.cloudtrail-*"]
language = "kuery"
license = "Elastic License v2"
name = "AWS Bedrock Guardrail Deleted or Weakened"
note = """## Triage and analysis

### Investigating AWS Bedrock Guardrail Deleted or Weakened

AWS Bedrock guardrails enforce content, topic, word, and sensitive-information policies on model
invocations. Adversaries who gain access to the Bedrock control plane may delete a guardrail (`DeleteGuardrail`),
loosen its policies (`UpdateGuardrail`), remove or overwrite the organization-enforced guardrail
configuration (`DeleteEnforcedGuardrailConfiguration` / `PutEnforcedGuardrailConfiguration`) to then enforce it on
model deployments. This detection identifies those control-plane changes so responders can confirm
intent before accepting the change.

#### Possible investigation steps

- **Identify the actor and context**
  - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`,
    `aws.cloudtrail.user_identity.access_key_id`, `source.ip`, and `user_agent.original`.
  - Confirm a related change request exists and that the identity is authorized to manage guardrails.
- **Validate the change**
  - For `UpdateGuardrail` / `PutEnforcedGuardrailConfiguration`, inspect
    `aws.cloudtrail.flattened.request_parameters` and `aws.cloudtrail.response_elements` to determine
    which content, topic, word, or sensitive-information policies were removed or weakened.
  - For `DeleteGuardrail` / `DeleteEnforcedGuardrailConfiguration`, identify the targeted guardrail
    or org configuration and whether protected workloads still reference it.
- **Correlate activity**
  - Look for surrounding Bedrock `InvokeModel` / `Converse` activity and other defense-impairing
    actions (e.g., logging or detector changes) from the same identity.
  - Check for prior enumeration such as `ListGuardrails` or `GetGuardrail`.

### Response and remediation

- If unauthorized, restore the guardrail and/or org-enforced configuration to its approved state and
  re-associate it with affected Bedrock workloads.
- Disable the access key in `aws.cloudtrail.user_identity.access_key_id` and review the actor's
  recent activity; rotate credentials if compromise is suspected.
- Restrict `bedrock:DeleteGuardrail`, `bedrock:UpdateGuardrail`, and the enforced-configuration
  permissions to a small set of admin roles, and enforce guardrail state via AWS Config or SCPs.
"""
references = [
    "https://docs.aws.amazon.com/bedrock/latest/APIReference/API_DeleteGuardrail.html",
    "https://docs.aws.amazon.com/bedrock/latest/APIReference/API_UpdateGuardrail.html",
    "https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails.html"
]
risk_score = 47
rule_id = "cdf7b922-909c-440c-8df0-0efe72aa7bea"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Domain: GenAI",
    "Platform: AWS",
    "Data Source: AWS CloudTrail",
    "Service: AWS Bedrock",
    "Tactic: Defense Evasion",
    "Rule Type: Custom Query (KQL)",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset: "aws.cloudtrail"
    and event.provider: "bedrock.amazonaws.com"
    and event.action: (
        "DeleteGuardrail" or
        "UpdateGuardrail" or
        "DeleteEnforcedGuardrailConfiguration" or
        "PutEnforcedGuardrailConfiguration"
    ) and event.outcome: "success"
    and not user_agent.original: (*Terraform*)
'''


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

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

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

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

[rule.investigation_fields]
field_names = [
    "@timestamp",
    "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.provider",
    "event.outcome",
    "cloud.account.id",
    "cloud.region",
    "aws.cloudtrail.request_parameters",
    "aws.cloudtrail.response_elements",
]

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

[rule]
author = ["Elastic"]
description = """
Detects enumeration of Amazon Simple Email Service (SES) resources using long-term IAM access
keys (AKIA* prefix). Long-term access keys are associated with IAM users and are the credential
type most commonly exfiltrated from repositories, configuration files, and environment variables.
An adversary who obtains a long-term key may enumerate SES to discover verified email identities,
sending quotas, and DKIM/MAIL FROM domain configurations as a precursor to phishing or spam
campaigns launched from the compromised account's verified domains.
"""
false_positives = [
    """
    Automated monitoring scripts, infrastructure inventory tools, or CI/CD pipelines that use
    long-term IAM keys to audit SES configuration will trigger this rule. Migrate automation
    to IAM roles with short-lived credentials; long-term keys used for SES management are a
    security anti-pattern regardless of this alert.
    """,
]
from = "now-6m"
index = ["logs-aws.cloudtrail-*"]
language = "kuery"
license = "Elastic License v2"
name = "AWS SES Enumeration via Long-Term Access Key"
note = """## Triage and analysis

### Investigating AWS SES Enumeration via Long-Term Access Key

Amazon SES verified identities (email addresses and domains) are the sending credentials that allow SES to send email on behalf of a domain. Adversaries who exfiltrate long-term IAM keys may enumerate SES to identify available verified domains for phishing, discover DKIM configurations, or check sending limits before launching a bulk email campaign.

Long-term keys (AKIA* prefix) are lower-security than assumed-role credentials: they do not expire and are frequently exposed in source code, .env files, CI/CD configuration, and developer workstations. This makes them the most common compromised credential type in cloud environments.

### Possible investigation steps

- Identify the IAM user behind the long-term key from aws.cloudtrail.user_identity.arn.
- Check whether this access key has been rotated recently (GetAccessKeyLastUsed, ListAccessKeys). Confirm the user who owns the key initiated this activity.
- Review source.ip and source.as.organization.name against known developer or automation infrastructure. API calls from unexpected geographies using a long-term key are high-risk.
- Query CloudTrail for subsequent SES write operations (SendEmail, SendRawEmail, VerifyEmailIdentity, UpdateAccountSendingEnabled) using the same access key.
- Check GitHub, GitLab, and CI/CD logs for any public exposure of this key.

### Response and remediation

- Immediately deactivate the long-term access key (UpdateAccessKey --status Inactive).
- Rotate all credentials associated with the IAM user.
- Review all SES quotas and sending history to determine whether unauthorized email was sent.
- Migrate automation that used this key to IAM roles with short-lived assumed-role credentials.
"""
references = [
    "https://docs.aws.amazon.com/ses/latest/APIReference/API_ListIdentities.html",
    "https://permiso.io/blog/s/aws-ses-pionage-detecting-ses-abuse/",
    "https://stratus-red-team.cloud/attack-techniques/AWS/aws.discovery.ses-enumerate/",
]
risk_score = 21
rule_id = "8d05971b-5858-4b72-b09a-17e3cee0af54"
setup = "The AWS integration must be ingesting management events into `logs-aws.cloudtrail-*`. SES management APIs are logged by default."
severity = "low"
tags = [
    "Domain: Cloud",
    "Platform: AWS",
    "Data Source: AWS CloudTrail",
    "Service: AWS SES",
    "Rule Type: Custom Query (KQL)",
    "Tactic: Discovery",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset: "aws.cloudtrail"
    and event.provider: "ses.amazonaws.com"
    and event.action: (
        "ListIdentities" or
        "GetAccountSendingEnabled" or
        "GetSendQuota" or
        "ListEmailIdentities" or
        "GetEmailIdentity" or
        "DescribeActiveReceiptRuleSet" or
        "ListReceiptRuleSets"
    )
    and event.outcome: "success"
    and aws.cloudtrail.user_identity.access_key_id: AKIA*
'''


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


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

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

[metadata]
creation_date = "2024/03/24"
integration = ["endpoint"]
maturity = "production"
promotion = true
updated_date = "2025/07/02"

[rule]
author = ["Elastic"]
description = """
Generates a detection alert each time an Elastic Defend alert for malicious behavior is received. Enabling this rule
allows you to immediately begin investigating your Endpoint behavior alerts. This rule identifies Elastic Defend
behavior detections only, and does not include prevention alerts.
"""
enabled = false
from = "now-2m"
index = ["logs-endpoint.alerts-*"]
interval = "1m"
language = "kuery"
license = "Elastic License v2"
max_signals = 1000
name = "Behavior - Detected - Elastic Defend"
note = """## Triage and analysis

### Investigating Behavior - Detected - Elastic Defend

Malicious behavior protection is a foundational feature which can be used to protect against all manner of attacks on the endpoint. For example, it provides coverage against phishing such as malicious macros, many malware families based on their activities, privilege escalation attacks such as user account control bypasses (UAC), credential theft, and much more. It works by consuming an unfiltered feed of all events that are captured on the system (process, file, registry, network, dns, etc). These events are processed against a routinely updated set of rules written by Elastic threat experts. From there, malicious behaviors are identified and offending processes are terminated. The protection operates on the event stream asynchronously, but has been designed to be extremely efficient and typically requires just milliseconds (under standard load) to stop malicious activity.

### Possible investigation steps

- Assess whether this activity is prevalent in your environment by looking for similar occurrences across hosts.
- Verify the detailed activity of the process that triggered the alert (process tree, child process, process arguments, network, files, libraries and registry events).
- Verify the activity of the `user.name` associated with the alert (local or remote actity, privileged or standard user).
- Particular attention should be paid to instances where the same process is triggering multiple alerts (more than 2 or 3) within a short period of time.
- Even the the process is signed by a valid certificate, verify the if it's running from the expected location or if it's loading any suspicious libraries or any sign of code injection.

### False positive analysis

- Same alert observed on a high number of hosts with similar details.
- High count of the same alert on a specific host over a long period of time.

### Response and Remediation

- Initiate the incident response process based on the outcome of the triage.
  - If malicious activity is confirmed, perform a broader investigation to identify the scope of the compromise and determine the appropriate remediation steps.
- Implement Elastic Endpoint Security to detect and prevent further post exploitation activities in the environment.
   - Contain the affected system by isolating it from the network to prevent further spread of the attack.
- If the triage identified malware, search the environment for additional compromised hosts.
  - Implement temporary network rules, procedures, and segmentation to contain the malware.
  - Stop suspicious processes.
  - Immediately block the identified indicators of compromise (IoCs).
  - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system.
- Remove and block malicious artifacts identified during triage.
- Restore the affected system to its operational state by applying any necessary patches, updates, or configuration changes.
- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services.
- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.
- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.
- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).
"""
references = [
    "https://github.com/elastic/protections-artifacts/tree/main/behavior",
    "https://docs.elastic.co/en/integrations/endpoint",
]
risk_score = 47
rule_id = "0f615fe4-eaa2-11ee-ae33-f661ea17fbce"
rule_name_override = "message"
setup = """## Setup

### Elastic Defend Alerts
This rule is designed to capture specific alerts generated by Elastic Defend.

To capture all the Elastic Defend alerts, it is recommended to use all of the Elastic Defend feature-specific protection rules:

Behavior - Detected - Elastic Defend (UUID: 0f615fe4-eaa2-11ee-ae33-f661ea17fbce)
Behavior - Prevented - Elastic Defend (UUID: eb804972-ea34-11ee-a417-f661ea17fbce)
Malicious File - Detected - Elastic Defend (UUID: f2c3caa6-ea34-11ee-a417-f661ea17fbce)
Malicious File - Prevented - Elastic Defend (UUID: f87e6122-ea34-11ee-a417-f661ea17fbce)
Memory Threat - Detected - Elastic Defend (UUID: 017de1e4-ea35-11ee-a417-f661ea17fbce)
Memory Threat - Prevented - Elastic Defend (UUID: 06f3a26c-ea35-11ee-a417-f661ea17fbce)
Ransomware - Detected - Elastic Defend (UUID: 0c74cd7e-ea35-11ee-a417-f661ea17fbce)
Ransomware - Prevented - Elastic Defend (UUID: 10f3d520-ea35-11ee-a417-f661ea17fbce)

To avoid generating duplicate alerts, you should enable either all feature-specific protection rules or the Endpoint Security (Elastic Defend) rule (UUID: 9a1a2dae-0b5f-4c3d-8305-a268d404c306).

### 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: Elastic Defend", "Resources: Investigation Guide"]
timestamp_override = "event.ingested"
type = "query"

query = '''
event.kind : alert and event.code : behavior and (event.type : allowed or (event.type: denied and event.outcome: failure))
'''


[[rule.exceptions_list]]
id = "endpoint_list"
list_id = "endpoint_list"
namespace_type = "agnostic"
type = "endpoint"

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

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

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

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

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

[rule]
description = """
Identifies DNS queries to known Dynamic DNS Providers by an unsigned program. Dynamic DNS providers are often misused to
host malware Command and Control servers.
"""
id = "75b80e66-90d0-4ab6-9e6b-976f7d690906"
license = "Elastic License v2"
name = "Connection to Dynamic DNS Provider by an Unsigned Binary"
os_list = ["windows"]
reference = [
    "https://www.elastic.co/security-labs/doing-time-with-the-yipphb-dropper",
    "https://www.elastic.co/security-labs/dissecting-remcos-rat-part-four",
]
version = "1.0.38"

query = '''
sequence by process.entity_id with maxspan=1m
 /* execution of an unsigned PEfollowed by dns request to dynamic dns provider */
  [process where event.action == "start" and user.id like ("S-1-5-21*", "S-1-12-*") and
   not process.code_signature.trusted == true and
   process.executable : ("?:\\Users\\*", "?:\\ProgramData\\*", "?:\\Windows\\Temp\\*", "?:\\Windows\\Tasks\\*") and 
   not process.hash.sha256 : 
              ("6cebce1ed45f77ca971281862cc9c9d0085dbc3504a9f1f9a717496cce51c829", 
               "43bd0fa458004d384a31b9147218be267b978506784dd4da141d46195a3ea4d9", 
               "18886da5d34be1f92ddf333c26f8c3a2b0be4da60a7ac4d795da233cbcd9e3bb",
               "94ab0b5595c2ebcf5d571504bf1b771308a5f6b391fe176bb83b98ac2c00c601",
               "b3246fe53f96b4f348be56555e0cfe5ccb990c666954b915163750d31d824155",
               "fc1ff4c34c9a6b504fb8114efef237abb81d68ae689b9f67f0eccf8e6bb0d1cd",
               "7bef5129132799a256fd6c33065e278c1a0e309e9109470a677abc52382bb46e",
               "e4bc373359eab8f6082bbb18cdb7dc08822b3a60ad28fd03ca41d6062bf1c81a",
               "65ae476e29863e8009897686b24618c972461459e09db7a453e1bdf2bd8747a7",
               "18df70114ee93d482b38a420254859326b2d176b87559574202172f6559c3a24",
               "2fcfb8ee597c419c09bd44ac14d7240247f627eb3eca7c7bac2c72142a3a9a53",
               "1618d40484e1ae2c25bbe0dc62e0b09f9213696cd148c622ee22fc3d6e15b6b1",
               "04ae8047e8b63e4ab09446a6a9b5aca49924af06e6ccd7012a3e12c90d5d615a",
               "d9639f20ab1499f38e74b34845db52b9a6afd223ed92936dbe23bffa9c362251",
               "1a840293a0647f5b600fce82e2aca744ee1cc3c362feb4b2703a9088379b420a",
               "495cbe2043fba338beae6da108c132dbfcaad6442c684380ed1397ef353ff58f",
               "88bbc206daf3de3089814da2f3a892ba0332e799be6bdc3349c35bb8b4e125e1",
               "8351ac57bca5f27998283fcc00c670fa9c9f08395cae5231d150630fa24fca1a",
               "7cd7fab80383e59a328e855b63e23c850eee78300b5f726db38ea0745be0bc5f") and
   not (process.code_signature.subject_name == "MarWinCliente" and process.parent.name == "dfsvc.exe" and
        process.code_signature.status == "errorUntrustedRoot") and
   not process.parent.executable : "C:\\Program Files\\Microsoft Visual Studio\\*.exe" and
   not (process.parent.name : "cmd.exe" and process.parent.command_line : "\"C:\\Windows\\system32\\cmd.exe\" ")
   ]
  [dns where
    dns.question.name :
         (
          "*.no-ip.com",
          "*.no-ip.org",
          "*.no-ip.biz",
          "*.no-ip.info",
          "*.noip.com",
          "*.afraid.org",
          "*.changeip.com",
          "*.ddns.net",
          "*.dyndns.org",
          "*.hopto.org",
          "*.zapto.org",
          "*.servehttp.com",
          "*.sytes.net",
          "*.myftp.biz",
          "*.myftp.org",
          "*.ddnsfree.com",
          "*.duckdns.org",
          "*.000webhostapp.com",
          "*.myddns.me",
          "*.dlinkddns.com",
          "*.chickenkiller.com", 
          "*.thddns.net", 
          "*.linkpc.net", 
          "*.gotdns.ch",
          "*.dynv6.net",
          "*.dns.army",
          "*.dns.navy",
          "*.v6.army",
          "*.v6.navy",
          "*.v6.rocks",
          "*.dyndns-office.com",
          "*.myvnc.com",
          "*.is-certified.com"
         ) and

    /* covered by rule Id dfe28e03-9b0b-47f5-9753-65ed2666663f */
    not dns.question.name : "checkip.dyndns.org"]
'''

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

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

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1071"
name = "Application Layer Protocol"
reference = "https://attack.mitre.org/techniques/T1071/"
[[threat.technique.subtechnique]]
id = "T1071.004"
name = "DNS"
reference = "https://attack.mitre.org/techniques/T1071/004/"



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

[internal]
min_endpoint_version = "7.15.0"

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

[rule]
author = ["Elastic"]
description = """
Identifies sequence of events where a Microsoft Entra ID protection alert is followed by an attempt to register a new device by the same user principal. This behavior may indicate an adversary using a compromised account to register a device, potentially leading to unauthorized access to resources or persistence in the environment.
"""
from = "now-9m"
index = ["logs-azure.identity_protection-*", "logs-azure.auditlogs-*"]
language = "eql"
license = "Elastic License v2"
name = "Entra ID Protection User Alert and Device Registration"
note = """## Triage and analysis

### Investigating Entra ID Protection User Alert and Device Registration

#### Possible investigation steps

- Identify the Risk Detection that triggered the event. A list with descriptions can be found [here](https://docs.microsoft.com/en-us/azure/active-directory/identity-protection/concept-identity-protection-risks#risk-types-and-detection).
- Identify the user account involved and validate whether the suspicious activity is normal for that user.
  - Consider the source IP address and geolocation for the involved user account. Do they look normal?
  - Consider the device used to sign in. Is it registered and compliant?
- Investigate other alerts associated with the user account during the past 48 hours.
- Contact the account owner and confirm whether they are aware of this activity.
- Check if this operation was approved and performed according to the organization's change management policy.
- If you suspect the account has been compromised, scope potentially compromised assets by tracking servers, services, and data accessed by the account in the last 24 hours.

### False positive analysis
- If this rule is noisy in your environment due to expected activity, consider adding exceptions — preferably with a combination of user and device conditions.
- Consider the context of the user account and whether the activity is expected. For example, if the user is a developer or administrator, they may have legitimate reasons for accessing resources from various locations or devices.
- A Microsoft Entra ID Protection alert may be triggered by legitimate activities such as password resets, MFA changes, or device registrations. If the user is known to perform these actions regularly, it may not indicate a compromise.

### Response and remediation

- Initiate the incident response process based on the outcome of the triage.
- Disable or limit the account during the investigation and response.
- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:
    - Identify the account role in the cloud environment.
    - Assess the criticality of affected services and servers.
    - Work with your IT team to identify and minimize the impact on users.
    - Identify if the attacker is moving laterally and compromising other accounts, servers, or services.
    - Identify any regulatory or legal ramifications related to this activity.
- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions.
- Check if unauthorized new users were created, remove unauthorized new accounts, and request password resets for other IAM users.
- Consider enabling multi-factor authentication for users.
- Follow security best practices [outlined](https://docs.microsoft.com/en-us/azure/security/fundamentals/identity-management-best-practices) by Microsoft.
- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector.
- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR)."""
references = [
    "https://docs.microsoft.com/en-us/azure/active-directory/reports-monitoring/reference-azure-monitor-sign-ins-log-schema",
    "https://docs.microsoft.com/en-us/azure/active-directory/identity-protection/overview-identity-protection",
    "https://docs.microsoft.com/en-us/azure/active-directory/identity-protection/howto-identity-protection-investigate-risk",
    "https://docs.microsoft.com/en-us/azure/active-directory/identity-protection/howto-identity-protection-investigate-risk#investigation-framework",
]
risk_score = 73
rule_id = "a6d4e070-b9b9-4294-b028-d9e21ad47413"
severity = "high"
tags = [
    "Domain: Cloud",
    "Data Source: Azure",
    "Data Source: Microsoft Entra ID",
    "Data Source: Microsoft Entra ID Protection Logs",
    "Data Source: Microsoft Entra ID Audit Logs",
    "Use Case: Identity and Access Audit",
    "Resources: Investigation Guide",
    "Tactic: Persistence",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
sequence with maxspan=5m
[any where data_stream.dataset == "azure.identity_protection"] by azure.identityprotection.properties.user_principal_name
[any where data_stream.dataset == "azure.auditlogs" and event.action == "Register device"] by azure.auditlogs.properties.initiated_by.user.userPrincipalName
'''


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

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

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

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

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

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

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

[rule]
author = ["Elastic"]
description = """
Identifies the execution of macOS built-in commands related to account or group enumeration. Adversaries may use account
and group information to orient themselves before deciding how to act.
"""
from = "now-9m"
index = ["logs-endpoint.events.process*"]
language = "eql"
license = "Elastic License v2"
name = "Enumeration of Users or Groups via Built-in Commands"
risk_score = 21
rule_id = "6e9b351e-a531-4bdc-b73e-7034d6eed7ff"
setup = """## Setup

This rule requires data coming in from Elastic Defend.

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

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

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

query = '''
process where host.os.type == "macos" and event.type in ("start", "process_started") and
  (
    process.name in ("ldapsearch", "dsmemberutil") or
    (process.name == "dscl" and
      process.args in ("read", "-read", "list", "-list", "ls", "search", "-search") and
      process.args like ("/Active Directory/*", "/Users*", "/Groups*"))
	) and
  ((process.Ext.effective_parent.executable like "/Volumes/*" or process.parent.executable like "/Volumes/*") or
   (process.Ext.effective_parent.name : ".*" or process.parent.name : ".*") or
   (process.parent.code_signature.trusted == false or process.parent.code_signature.exists == false))
'''
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 Enumeration of Users or Groups via Built-in Commands

Built-in macOS commands like `ldapsearch`, `dsmemberutil`, and `dscl` are essential for managing and querying user and group information. Adversaries exploit these to gather insights into system accounts and groups, aiding in lateral movement or privilege escalation. The detection rule identifies suspicious use of these commands, especially when executed from non-standard parent processes, excluding known legitimate applications, to flag potential misuse.

### Possible investigation steps

- Review the process details to identify the specific command executed, focusing on the process name and arguments, such as "ldapsearch", "dsmemberutil", or "dscl" with specific arguments like "read", "list", or "search".
- Examine the parent process information, including the executable path and name, to determine if the command was launched from a non-standard or suspicious parent process.
- Check the exclusion list of known legitimate applications to ensure the alert was not triggered by a benign process, such as those from QualysCloudAgent, Kaspersky, or ESET.
- Investigate the user account associated with the process execution to determine if it aligns with expected behavior or if it indicates potential compromise or misuse.
- Correlate the event with other logs or alerts to identify any patterns of suspicious activity, such as repeated enumeration attempts or other discovery tactics.
- Assess the system's recent activity for signs of lateral movement or privilege escalation attempts that may follow the enumeration of users or groups.

### False positive analysis

- Security and management tools like QualysCloudAgent, Kaspersky Anti-Virus, and ESET Endpoint Security may trigger false positives due to their legitimate use of built-in commands for system monitoring. To mitigate this, add these applications to the exclusion list in the detection rule.
- Development environments such as Xcode might execute these commands during normal operations. If Xcode is frequently triggering alerts, consider excluding its executable path from the rule.
- VPN and network management applications like NordVPN and Zscaler may use these commands for network configuration and user management. Exclude these applications if they are known to be safe and frequently used in your environment.
- Parallels Desktop and similar virtualization software might access user and group information as part of their functionality. If these applications are trusted, add their executable paths to the exclusion list.
- Regular administrative tasks performed by IT personnel using NoMAD or similar tools can also cause false positives. Ensure these tools are excluded if they are part of routine operations.

### Response and remediation

- Immediately isolate the affected macOS system from the network to prevent potential lateral movement by the adversary.
- Terminate any suspicious processes identified by the detection rule, specifically those involving `ldapsearch`, `dsmemberutil`, or `dscl` commands executed from non-standard parent processes.
- Conduct a thorough review of user and group accounts on the affected system to identify any unauthorized changes or additions, and revert any suspicious modifications.
- Reset passwords for all user accounts on the affected system, prioritizing those with administrative privileges, to mitigate potential unauthorized access.
- Escalate the incident to the security operations team for further investigation and to determine if additional systems have been compromised.
- Implement additional monitoring on the affected system and network to detect any further unauthorized enumeration attempts or related suspicious activities.
- Review and update endpoint security configurations to ensure that legitimate applications are properly whitelisted and that unauthorized applications are blocked from executing enumeration commands."""


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

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

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

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

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

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

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

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

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

[rule]
author = ["Elastic"]
description = """
This rule detects the unpacking of an initramfs image using the "unmkinitramfs" command on Linux systems. The
"unmkinitramfs" command is used to extract the contents of an initramfs image, which is used to boot the system.
Attackers may use "unmkinitramfs" to unpack an initramfs image and modify its contents to include malicious code or
backdoors, allowing them to maintain persistence on the system.
"""
from = "now-9m"
index = [
    "logs-endpoint.events.process*",
    "endgame-*",
    "auditbeat-*",
    "logs-auditd_manager.auditd-*",
    "logs-crowdstrike.fdr*",
    "logs-sentinel_one_cloud_funnel.*",
]
language = "eql"
license = "Elastic License v2"
name = "Initramfs Unpacking via unmkinitramfs"
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 Initramfs Unpacking via unmkinitramfs

Initramfs is a crucial component in Linux boot processes, containing essential drivers and scripts. The `unmkinitramfs` tool extracts its contents, which attackers might exploit to insert malicious code, ensuring persistence. The detection rule identifies the execution of `unmkinitramfs`, flagging potential unauthorized modifications by monitoring process initiation events on Linux systems.

### Possible investigation steps

- Review the process execution details to confirm the presence of the unmkinitramfs command, focusing on the process.name field to ensure it matches "unmkinitramfs".
- Check the user context under which the unmkinitramfs command was executed to determine if it aligns with expected administrative activities or if it was run by an unauthorized user.
- Investigate the parent process of the unmkinitramfs execution to understand how the command was initiated and if it was part of a legitimate script or an unexpected process chain.
- Examine recent system logs and audit logs for any other suspicious activities or anomalies around the time of the unmkinitramfs execution, such as unauthorized access attempts or changes to critical system files.
- Assess the integrity of the initramfs image by comparing it with a known good version, if available, to identify any unauthorized modifications or inclusions of malicious code.

### False positive analysis

- Routine system maintenance or updates may trigger the rule when legitimate processes unpack initramfs for kernel updates. Users can create exceptions for known maintenance scripts or processes that regularly perform these actions.
- Automated backup or recovery solutions might use unmkinitramfs to verify or restore system images. Identify and exclude these processes if they are part of trusted backup operations.
- Developers or system administrators testing or customizing initramfs images for legitimate purposes could trigger the rule. Establish a whitelist for specific user accounts or scripts that are authorized to perform these tasks.
- Security tools or monitoring solutions that analyze initramfs contents for integrity checks might inadvertently trigger the rule. Ensure these tools are recognized and excluded from detection to prevent unnecessary alerts.

### Response and remediation

- Immediately isolate the affected system from the network to prevent potential lateral movement or data exfiltration by the attacker.
- Terminate any suspicious processes related to `unmkinitramfs` to halt any ongoing malicious activity.
- Conduct a thorough review of the initramfs image and its contents to identify and remove any unauthorized modifications or malicious code.
- Restore the initramfs image from a known good backup to ensure system integrity and remove any potential backdoors.
- Monitor the system for any further attempts to execute `unmkinitramfs` and investigate any such occurrences to determine if they are legitimate or part of an ongoing attack.
- Escalate the incident to the security operations team for further analysis and to determine if additional systems may be affected.
- Implement additional logging and monitoring for process execution events on Linux systems to enhance detection capabilities for similar threats in the future."""
risk_score = 21
rule_id = "c5fc788c-7576-4a02-b3d6-d2c016eb85a6"
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",
    "Data Source: Elastic Endgame",
    "Data Source: Elastic Defend",
    "Data Source: Auditd Manager",
    "Data Source: Crowdstrike",
    "Data Source: SentinelOne",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
process where host.os.type == "linux" and event.type == "start" and
event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed") and
process.name == "unmkinitramfs" and not (
  ?process.parent.executable == "/usr/bin/lsinitramfs" or
  ?process.working_directory == "/usr/local/nutanix/ngt/python/bin"
)
'''

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[rule]
author = ["Elastic"]
description = """
Identifies registry modifications related to the Windows Security Support Provider (SSP) configuration. Adversaries may
abuse this to establish persistence in an environment.
"""
from = "now-9m"
index = [
    "winlogbeat-*",
    "logs-endpoint.events.registry-*",
    "logs-windows.sysmon_operational-*",
    "endgame-*",
    "logs-m365_defender.event-*",
    "logs-sentinel_one_cloud_funnel.*",
    "logs-crowdstrike.fdr*",
]
language = "eql"
license = "Elastic License v2"
name = "Installation of Security Support Provider"
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 Installation of Security Support Provider

Security Support Providers (SSPs) in Windows environments facilitate authentication processes. Adversaries may exploit SSPs by modifying registry entries to maintain persistence or evade defenses. The detection rule identifies suspicious changes to specific registry paths associated with SSPs, excluding legitimate processes like msiexec.exe, to flag potential unauthorized modifications indicative of malicious activity.

### Possible investigation steps

- Review the registry change event details to identify the specific registry path that was modified, focusing on paths related to "HKLM\\SYSTEM\\*ControlSet*\\Control\\Lsa\\Security Packages" and "HKLM\\SYSTEM\\*ControlSet*\\Control\\Lsa\\OSConfig\\Security Packages".
- Investigate the process responsible for the registry modification by examining the process executable path, ensuring it is not a legitimate process like "C:\\Windows\\System32\\msiexec.exe" or "C:\\Windows\\SysWOW64\\msiexec.exe".
- Check the historical activity of the identified process to determine if it has been involved in other suspicious activities or registry changes.
- Analyze the user account context under which the process was executed to assess if it aligns with expected behavior or if it indicates potential compromise.
- Correlate the event with other security alerts or logs from data sources such as Elastic Endgame, Elastic Defend, Sysmon, Microsoft Defender XDR, or SentinelOne to gather additional context and identify any related malicious activity.
- Evaluate the potential impact of the registry change on system security and persistence mechanisms, considering the MITRE ATT&CK tactic of Persistence and technique T1547.

### False positive analysis

- Legitimate software installations or updates may trigger registry changes in SSP paths. Users can create exceptions for known software installers or updaters that frequently modify these registry entries.
- System administrators performing routine maintenance or configuration changes might inadvertently cause registry modifications. Document and exclude these activities when they are verified as non-threatening.
- Security software updates, including those from Microsoft or third-party vendors, may alter SSP configurations as part of their normal operation. Monitor and whitelist these updates to prevent false alerts.
- Automated deployment tools or scripts that modify system settings could lead to false positives. Ensure these tools are accounted for and excluded if they are part of regular operations.
- Custom scripts or applications developed in-house that interact with SSP registry paths should be reviewed and excluded if they are deemed safe and necessary for business operations.

### Response and remediation

- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
- Terminate any suspicious processes that are not whitelisted, especially those modifying the registry paths associated with Security Support Providers.
- Restore the modified registry entries to their original state using a known good backup or by manually correcting the entries to remove unauthorized changes.
- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious software or artifacts.
- Review and update access controls and permissions to ensure that only authorized personnel can modify critical registry paths related to Security Support Providers.
- Monitor the affected system and network for any signs of re-infection or further suspicious activity, focusing on registry changes and process executions.
- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised."""
risk_score = 47
rule_id = "e86da94d-e54b-4fb5-b96c-cecff87e8787"
severity = "medium"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Persistence",
    "Tactic: Defense Evasion",
    "Data Source: Elastic Endgame",
    "Data Source: Elastic Defend",
    "Data Source: Sysmon",
    "Data Source: Microsoft Defender XDR",
    "Data Source: SentinelOne",
    "Data Source: Crowdstrike",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
registry where host.os.type == "windows" and event.type == "change" and
  registry.value : "Security Packages" and
  registry.path : (
      "*\\SYSTEM\\*ControlSet*\\Control\\Lsa\\Security Packages",
      "*\\SYSTEM\\*ControlSet*\\Control\\Lsa\\OSConfig\\Security Packages"
  ) and
  not process.executable : (
        "C:\\Windows\\System32\\msiexec.exe",
        "C:\\Windows\\SysWOW64\\msiexec.exe",
        /* Crowdstrike specific exclusion as it uses NT Object paths */
        "\\Device\\HarddiskVolume*\\Windows\\System32\\msiexec.exe",
        "\\Device\\HarddiskVolume*\\Windows\\SysWOW64\\msiexec.exe"
  )
'''

setup = """## Setup

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

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

### Additional data sources

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

- [CrowdStrike](https://ela.st/crowdstrike-integration)
- [Microsoft Defender XDR](https://ela.st/m365-defender)
- [SentinelOne Cloud Funnel](https://ela.st/sentinel-one-cloud-funnel)
- [Sysmon Registry Events](https://ela.st/sysmon-event-reg-setup)
"""


[[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.005"
name = "Security Support Provider"
reference = "https://attack.mitre.org/techniques/T1547/005/"



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


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

[metadata]
creation_date = "2026/04/23"
integration = ["kubernetes"]
maturity = "production"
updated_date = "2026/08/18"

[rule]
author = ["Elastic"]
description = """
Detects Kubernetes pod exec sessions whose decoded command line references high-value host or in-cluster paths and
material types: mounted service account or platform tokens, kubelet and control-plane configuration areas, host
identity stores, root dot-directories for cloud and kubeconfig material, common private-key and keystore extensions,
process environment dumps, and configuration filenames suggestive of embedded secrets. The intent is to catch
interactive or scripted access that often precedes lateral movement, privilege escalation, or credential theft from
the node or workload boundary. A narrow exclusion ignores benign reads of resolv.conf. The query also labels an
access_type bucket to speed triage without altering the detection predicates you validated.
"""
from = "now-6m"
interval = "5m"
language = "esql"
license = "Elastic License v2"
name = "Kubernetes Pod Exec Sensitive File or Credential Path Access"
note = """## Triage and analysis

### Investigating Kubernetes Pod Exec Sensitive File or Credential Path Access

This alert ties Kubernetes audit exec events to reconstructed command text that matches sensitive path and filename
patterns. Use the Esql.access_type field to prioritize: IRSA token paths, default Kubernetes service account tokens,
other mounted secrets, certificates and keystores, Kubernetes static config, kubelet state, host passwd or shadow,
user home credential stores, and proc environ scraping.

### Possible investigation steps

- Identify the Kubernetes user, groups, impersonation, source IP, and user agent for the exec caller.
- Map objectRef namespace, pod, and container to an owning team, image digest, and change history.
- Compare Esql.executed_command against known runbooks; capture follow-on audit activity such as additional execs,
  secret reads at the API layer, or RBAC changes.
- If host-level paths appear, determine whether the workload runs privileged, with hostPath mounts, or on nodes where
  break-glass access is expected.

### False positive analysis

- Diagnostic images and vendor agents sometimes cat resolv.conf or kubeconfig-like paths; the rule excludes resolv.conf
  but other matches may still be legitimate—baseline stable automation identities.
- Training containers that deliberately demonstrate passwd reads can trigger; scope exceptions to those images and
  namespaces.

### Response and remediation

- If malicious, end the exec session, isolate the pod or node, rotate any credentials that could have been read,
  review and tighten pods exec RBAC and admission controls, and inspect for persistence added after the session.
"""
references = [
    "https://attack.mitre.org/techniques/T1552/001/",
    "https://attack.mitre.org/techniques/T1552/007/",
]
risk_score = 73
rule_id = "b2c3d4e5-f6a7-4890-b1c2-d3e4f5a60789"
severity = "high"
tags = [
    "Data Source: Kubernetes",
    "Data Source: Kubernetes API Server Audit Logs",
    "Domain: Kubernetes",
    "Platform: Kubernetes",
    "Use Case: Threat Detection",
    "Tactic: Credential Access",
    "Tactic: Execution",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "esql"
query = '''
from logs-kubernetes.audit_logs-* metadata _id, _index, _version
| WHERE kubernetes.audit.objectRef.subresource == "exec"
  AND kubernetes.audit.requestURI LIKE "*command=*"
| EVAL Esql.decoded_uri = URL_DECODE(kubernetes.audit.requestURI)
| GROK Esql.decoded_uri "%{DATA}/exec\\?%{DATA:raw_commands}&(?:container|stdin|stdout|stderr)=%{GREEDYDATA}"
| EVAL command = REPLACE(raw_commands, "command=", "")
| EVAL command = REPLACE(command, "&", " ")
| EVAL Esql.executed_command = REPLACE(command, "\\+", " ")
| WHERE Esql.executed_command IS NOT NULL 
  AND Esql.executed_command RLIKE """.*(/var/run/secrets/|/etc/kubernetes/|/var/lib/kubelet/|/etc/shadow|/etc/passwd|/etc/sudoers|(/root|/home/[^/]+)/\.(ssh|aws|azure|kube|config/gcloud)|\.p12|\.pem|\.key|\.jks|\.keystore|/etc/.*\.conf.*(password|secret|key|token|credential)|/proc/.*/environ).*"""
  AND NOT Esql.executed_command RLIKE """.*/etc/resolv\.conf.*"""
| EVAL Esql.access_type = CASE(
    Esql.executed_command RLIKE """.*/var/run/secrets/eks\.amazonaws\.com.*""", "AWS_IRSA_TOKEN",
    Esql.executed_command RLIKE """.*/var/run/secrets/azure/tokens/.*""", "AZURE_WORKLOAD_IDENTITY_TOKEN",
    Esql.executed_command RLIKE """.*/var/run/secrets/tokens/gcp-ksa/.*""", "GCP_WORKLOAD_IDENTITY_TOKEN",
    Esql.executed_command RLIKE """.*/var/run/secrets/kubernetes\.io/serviceaccount/token.*""", "K8S_SA_TOKEN",
    Esql.executed_command RLIKE """.*/var/run/secrets/.*""", "MOUNTED_SECRET",
    Esql.executed_command RLIKE """.*\.(p12|pem|key|jks|keystore).*""", "CERTIFICATE_OR_KEY",
    Esql.executed_command RLIKE """.*/etc/kubernetes/.*""", "K8S_CONFIG",
    Esql.executed_command RLIKE """.*/var/lib/kubelet/.*""", "KUBELET_CONFIG",
    Esql.executed_command RLIKE """.*/etc/shadow.*""", "HOST_CREDENTIALS",
    Esql.executed_command RLIKE """.*/etc/passwd.*""", "USER_ENUMERATION",
    Esql.executed_command RLIKE """.*/etc/sudoers.*""", "SUDOERS_ACCESS",
    Esql.executed_command RLIKE """.*(/root|/home/[^/]+)/\.(ssh|aws|azure|kube|config/gcloud).*""", "USER_CREDENTIALS",
    Esql.executed_command RLIKE """.*/proc/.*/environ.*""", "PROCESS_ENV_SECRETS",
    Esql.executed_command RLIKE """.*/etc/.*\.conf.*(password|secret|key|token|credential).*""", "EMBEDDED_CONFIG_SECRET",
    "OTHER_SENSITIVE"
  )
| KEEP Esql.*, user.name, user_agent.original, event.*, source.ip, kubernetes.audit.*, _id, _version, _index, data_stream.namespace
'''

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

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

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

[[rule.threat.technique.subtechnique]]
id = "T1552.007"
name = "Container API"
reference = "https://attack.mitre.org/techniques/T1552/007/"

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

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

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

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

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

[rule]
author = ["Elastic"]
description = """
Identifies the modification of an anti-phishing rule in Microsoft 365. By default, Microsoft 365 includes built-in
features that help protect users from phishing attacks. Anti-phishing rules increase this protection by refining
settings to better detect and prevent attacks.
"""
false_positives = [
    """
    An anti-phishing rule may be deleted by a system or network administrator. Verify that the configuration change was
    expected. Exceptions can be added to this rule to filter expected behavior.
    """,
]
from = "now-9m"
index = ["logs-o365.audit-*", "filebeat-*"]
language = "kuery"
license = "Elastic License v2"
name = "M365 Exchange Anti-Phish Rule Modification"
note = """## Triage and analysis

> **Disclaimer**:
> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.

### Investigating M365 Exchange Anti-Phish Rule Modification

Microsoft 365's anti-phishing rules are crucial for safeguarding users against phishing attacks by enhancing detection and prevention settings. Adversaries may attempt to modify or disable these rules to facilitate phishing campaigns, gaining unauthorized access. The detection rule monitors for successful modifications or disabling of anti-phishing rules, signaling potential malicious activity by tracking specific actions within the Exchange environment.

### Possible investigation steps

- Review the event logs for entries with event.dataset set to o365.audit and event.provider set to Exchange to confirm the context of the alert.
- Check the event.action field for "Remove-AntiPhishRule" or "Disable-AntiPhishRule" to identify the specific action taken on the anti-phishing rule.
- Verify the event.outcome field to ensure the action was successful, indicating a potential security concern.
- Identify the user or account associated with the modification by examining the relevant user fields in the event log.
- Investigate the user's recent activity and access patterns to determine if there are any other suspicious actions or anomalies.
- Assess the impact of the rule modification by reviewing any subsequent phishing attempts or security incidents that may have occurred.
- Consider reverting the changes to the anti-phishing rule and implementing additional security measures if unauthorized access is confirmed.

### False positive analysis

- Administrative changes: Legitimate administrative tasks may involve modifying or disabling anti-phishing rules for testing or configuration purposes. To manage this, create exceptions for known administrative accounts or scheduled maintenance windows.
- Security audits: Regular security audits might require temporary adjustments to anti-phishing rules. Document these activities and exclude them from alerts by correlating with audit logs.
- Third-party integrations: Some third-party security tools may interact with Microsoft 365 settings, triggering rule modifications. Identify these tools and exclude their actions from triggering alerts by using their specific identifiers.
- Policy updates: Organizational policy changes might necessitate updates to anti-phishing rules. Ensure these changes are documented and exclude them from alerts by associating them with approved change management processes.

### Response and remediation

- Immediately isolate the affected user accounts to prevent further unauthorized access and potential spread of phishing attacks.
- Revert any unauthorized changes to the anti-phishing rules by restoring them to their previous configurations using backup or documented settings.
- Conduct a thorough review of recent email logs and user activity to identify any potential phishing emails that may have bypassed the modified rules and take steps to quarantine or delete them.
- Notify the security team and relevant stakeholders about the incident, providing details of the rule modification and any identified phishing attempts.
- Escalate the incident to the incident response team for further investigation and to determine if additional systems or data have been compromised.
- Implement enhanced monitoring and alerting for any further attempts to modify anti-phishing rules, ensuring that similar activities are detected promptly.
- Review and update access controls and permissions for administrative actions within Microsoft 365 to ensure that only authorized personnel can modify security settings.

## Setup

The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
references = [
    "https://docs.microsoft.com/en-us/powershell/module/exchange/remove-antiphishrule?view=exchange-ps",
    "https://docs.microsoft.com/en-us/powershell/module/exchange/disable-antiphishrule?view=exchange-ps",
]
risk_score = 47
rule_id = "97314185-2568-4561-ae81-f3e480e5e695"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Data Source: Microsoft 365",
    "Use Case: Configuration Audit",
    "Tactic: Defense Evasion",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:o365.audit and event.provider:Exchange and event.category:web and event.action:("Remove-AntiPhishRule" or "Disable-AntiPhishRule") and event.outcome:success
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1562"
name = "Impair Defenses"
reference = "https://attack.mitre.org/techniques/T1562/"
[[rule.threat.technique.subtechnique]]
id = "T1562.001"
name = "Disable or Modify Tools"
reference = "https://attack.mitre.org/techniques/T1562/001/"


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

[metadata]
creation_date = "2026/02/25"
integration = ["o365"]
maturity = "production"
updated_date = "2026/04/10"

[rule]
author = ["Elastic"]
description = """
Identifies when an MFA enrollment, registration, or security notification email is deleted or moved to deleted items in
Microsoft 365 Exchange. Adversaries who compromise accounts and register their own MFA device often delete the
notification emails to cover their tracks and prevent the legitimate user from noticing the unauthorized change. This
technique is commonly observed in business email compromise (BEC) and account takeover attacks.
"""
false_positives = [
    "Users legitimately deleting MFA notification emails after reviewing them.",
    "Automated mailbox rules that move security notifications to specific folders.",
    "Email retention policies that automatically delete old notification emails.",
]
from = "now-9m"
index = ["filebeat-*", "logs-o365.audit-*"]
language = "eql"
license = "Elastic License v2"
name = "M365 Exchange MFA Notification Email Deleted or Moved"
note = """## Triage and Analysis

### Investigating M365 Exchange MFA Notification Email Deleted or Moved

This rule detects when emails containing MFA enrollment or security notification keywords are deleted or moved to deleted items. Attackers who gain access to an account and register their own MFA device will often immediately delete the notification email to prevent the legitimate user from detecting the compromise.

#### Possible Investigation Steps

- Identify the user whose mailbox had the email deleted and determine if they recently enrolled a new MFA device.
- Review Azure AD sign-in logs for the user around the time of the deletion for authentication anomalies.
- Check Azure AD audit logs for recent MFA method registrations or changes for this user.
- Review the source IP address and determine if it matches the user's typical access patterns.
- Look for other suspicious mailbox activities from the same session (inbox rules, email forwarding).
- Determine if the user was aware of and initiated the MFA enrollment that generated the notification.

### False Positive Analysis

- Users may legitimately delete MFA notification emails after reviewing and confirming the enrollment.
- Some organizations have mailbox rules that automatically organize or delete notification emails.
- Consider creating exceptions for users who frequently manage MFA enrollments (IT help desk).

### Response and Remediation

- If unauthorized MFA enrollment is confirmed, immediately remove the attacker's MFA method from the account.
- Revoke all active sessions and refresh tokens for the affected user.
- Reset the user's credentials and require reauthentication.
- Review inbox rules for any malicious forwarding or deletion rules.
- Check for data exfiltration or other malicious activities during the compromise window.
- Implement conditional access policies to restrict MFA registration to trusted locations/devices.
"""
references = [
    "https://cloud.google.com/blog/topics/threat-intelligence/expansion-shinyhunters-saas-data-theft"
]
risk_score = 21
rule_id = "c9636a6e-125e-11f1-9cd3-f661ea17fbce"
severity = "low"
tags = [
    "Domain: Cloud",
    "Domain: SaaS",
    "Data Source: Microsoft 365",
    "Data Source: Microsoft 365 Audit Logs",
    "Use Case: Threat Detection",
    "Tactic: Defense Evasion",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
web where data_stream.dataset == "o365.audit" and
    event.provider == "Exchange" and
    event.action in ("SoftDelete", "HardDelete", "MoveToDeletedItems") and
    event.outcome == "success" and
    (
        o365.audit.AffectedItems.Subject like~ (
            /* new + (mfa|multi-|factor|method|device|security) */
            "*new mfa*", "*new multi*", "*new factor*", "*new method*", "*new device*", "*new security*",
            /* 2fa and 2-step */
            "*2fa*", "*2-step*",
            /* mfa + action verbs */
            "*mfa enroll*", "*mfa register*", "*mfa added*", "*mfa change*",
            "*mfa verify*", "*mfa update*", "*mfa activate*", "*mfa configure*", "*mfa setup*",
            /* factor + action verbs */
            "*factor enroll*", "*factor register*", "*factor added*", "*factor change*",
            "*factor verify*", "*factor update*", "*factor activate*", "*factor configure*", "*factor setup*",
            /* method + action verbs */
            "*method enroll*", "*method register*", "*method added*", "*method change*",
            "*method verify*", "*method update*", "*method activate*", "*method configure*", "*method setup*",
            /* device + action verbs */
            "*device enroll*", "*device register*", "*device added*", "*device change*",
            "*device verify*", "*device update*", "*device activate*", "*device configure*", "*device setup*",
            /* security + action verbs */
            "*security enroll*", "*security register*", "*security added*", "*security change*",
            "*security verify*", "*security update*", "*security activate*", "*security configure*", "*security setup*",
            /* Additional security notifications */
            "*authenticator*", "*verification code*", "*security info*", "*security alert*"
        ) and not
        o365.audit.AffectedItems.Subject like~ ("*sign-in*", "*sign in*", "*log-in*", "*log in*", "*logon*")
    )
'''


[[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.008"
name = "Clear Mailbox Data"
reference = "https://attack.mitre.org/techniques/T1070/008/"

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

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

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

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

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

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

[rule]
author = ["Elastic"]
description = """
Detects the manual loading of a Chromium-based browser extension via command line arguments. This activity 
is suspicious and could indicate a threat actor loading a malicious extension to persist or collect browsing 
secrets such as cookies and authentication tokens.
"""
from = "now-9m"
index = ["logs-endpoint.events.process-*"]
language = "eql"
license = "Elastic License v2"
name = "Manual Loading of a Suspicious Chromium Extension"
references = [
    "https://cedowens.medium.com/remotely-dumping-chrome-cookies-revisited-b25343257209",
    "https://github.com/cedowens/Dump-Chrome-Cookies"
]
risk_score = 73
rule_id = "f1f3070e-045c-4e03-ae58-d11d43d2ee51"
severity = "high"
tags = [
    "Domain: Endpoint",
    "OS: macOS",
    "Use Case: Threat Detection",
    "Tactic: Persistence",
    "Tactic: Credential Access",
    "Data Source: Elastic Defend",
    "Resources: Investigation Guide"
]
timestamp_override = "event.ingested"
type = "eql"
note = """## Triage and analysis

> **Disclaimer**:
> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.

### Investigating Manual Loading of a Suspicious Chromium Extension

Chromium-based browsers support loading extensions from local directories using the --load-extension command line flag, bypassing the normal extension store installation process. Threat actors abuse this capability to load malicious extensions that can steal cookies, capture session tokens, intercept form submissions, or inject content into web pages. Unlike store-installed extensions, manually loaded extensions don't undergo security review and can request arbitrary permissions. This detection rule identifies browsers launched with the --load-extension flag from suspicious parent processes.

### Possible investigation steps

- Examine the process.args containing --load-extension to identify the full path of the extension being loaded.
- Navigate to the extension directory and review the manifest.json to understand the permissions requested, including access to cookies, tabs, or web requests.
- Analyze the extension's JavaScript files for malicious functionality such as cookie exfiltration, form interception, or communication with external servers.
- Review the process.parent.executable to understand how the browser was launched with the malicious extension and trace back to the initial execution vector.
- Check for network connections made by the browser process to identify potential data exfiltration endpoints.
- Review browser profile data for evidence of credential theft or session hijacking.
- Search for the same extension path across other systems to identify potential lateral movement or widespread deployment.

### False positive analysis

- Cypress and other automated testing frameworks load extensions for browser automation. These are already excluded in the query.
- ChromeDriver used for Selenium testing loads extensions programmatically. These paths are excluded in the query.
- Developer debugging may require manual extension loading during active development. Verify with development teams if such activities are expected.
- Enterprise browser customization may deploy internal extensions via command line. Review with IT operations to document approved extensions.

### Response and remediation

- Immediately terminate the browser process to stop any ongoing malicious activity such as cookie theft or session hijacking.
- Remove the malicious extension directory from the filesystem to prevent future loading.
- Clear browser session data including cookies, cached credentials, and saved passwords for the affected browser profile.
- Review and revoke any sessions for sensitive web applications that were accessed while the extension was loaded.
- Investigate how the malicious extension was deployed and remediate the initial access vector.
- Block the malicious extension path or hash in endpoint security policies to prevent reloading.
- Reset passwords for web accounts that may have been compromised through the malicious extension.
- Check browser sync settings to ensure the malicious extension doesn't propagate to other devices.
"""
query = '''
process where host.os.type == "macos" and event.action == "exec" and
  process.name in ("Google Chrome", "Brave Browser", "Microsoft Edge") and
  process.args like "--load-extension=/*" and
  not (process.args like "--load-extension=/Users/*/Library/Application Support/Cypress/*" and
       process.parent.executable like ("/Applications/Google Chrome.app/Contents/MacOS/Google Chrome",
                                        "/Users/*/Library/Caches/Cypress/*/Cypress.app/Contents/MacOS/Cypress")) and
  not process.parent.executable like ("/opt/homebrew/Caskroom/chromedriver/*/chromedriver",
                                    "/Applications/Cypress.app/Contents/MacOS/Cypress",
                                    "/usr/local/bin/chromedriver")
'''

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

[[rule.threat.technique]]
id = "T1176"
name = "Software Extensions"
reference = "https://attack.mitre.org/techniques/T1176/"

[[rule.threat.technique.subtechnique]]
id = "T1176.001"
name = "Browser Extensions"
reference = "https://attack.mitre.org/techniques/T1176/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 = "T1539"
name = "Steal Web Session Cookie"
reference = "https://attack.mitre.org/techniques/T1539/"

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

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

[[rule.threat.technique]]
id = "T1185"
name = "Browser Session Hijacking"
reference = "https://attack.mitre.org/techniques/T1185/"

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

[rule]
description = """
Identifies the load of the Microsoft Common Language Runtime DLL CLR.dll from unbacked memory region with suspicious
memory allocation properties. This could be the result of attempts to load an assembly from an already injected process.
"""
id = "ad2c6fcc-89d3-4939-85d9-d7114d6bbf14"
license = "Elastic License v2"
name = "Microsoft Common Language Runtime Loaded from Suspicious Memory"
os_list = ["windows"]
reference = [
    "https://www.elastic.co/security-labs/upping-the-ante-detecting-in-memory-threats-with-kernel-call-stacks",
]
version = "1.0.29"

query = '''
library where dll.name : "clr.dll" and
 process.thread.Ext.call_stack_summary : 
             ("ntdll.dll|wow64.dll|wow64cpu.dll|wow64.dll|ntdll.dll|kernelbase.dll|mscoreei.dll|Unbacked", 
              "ntdll.dll|kernelbase.dll|mscoreei.dll|Unbacked") and
 _arraysearch(process.thread.Ext.call_stack, $entry, $entry.symbol_info : "*mscoreei.dll!CreateInterface*") and
 not (process.executable : "?:\\Program Files\\Dell\\DTP\\DiagnosticsSubAgent\\Dell.TechHub.Diagnostics.SubAgent.exe" and
      process.code_signature.trusted == true and process.code_signature.subject_name : "Dell Inc") and
 not (process.code_signature.trusted == true and 
      process.code_signature.subject_name : ("Azul Systems, Inc.", "JetBrains s.r.o.", "HAYLEM Technologies Inc.", "MicroStrategy, Inc.", "Oracle America, Inc.")) and
 not (process.executable : "C:\\ManageEngine\\ADManager Plus\\jre\\bin\\java.exe" and 
      process.code_signature.subject_name : "Oracle America, Inc." and process.code_signature.trusted == true) and 
 not (process.executable : "?:\\Program Files*\\Amazon Corretto\\jdk*\\bin\\java.exe" and 
      process.code_signature.subject_name : ("Amazon.com Services LLC", "Amazon Services LLC", "Adaptive Protocols, Inc.") and process.code_signature.trusted == true)  and 
 not (process.executable : "?:\\ManageEngine\\PAM360\\jre\\bin\\java.exe" and
      process.code_signature.trusted == true and
      process.code_signature.subject_name : ("Oracle America, Inc.", "Eclipse.org Foundation, Inc.")) and
 not (process.executable : "*\\EL.AudioVideoConversion.Console.exe" and
      process.code_signature.trusted == true and
      process.code_signature.subject_name : "NEXUS / E&L GmbH") and
 not process.executable :
               ("?:\\Program Files\\Microsoft Visual Studio\\*.exe",
                "?:\\Program Files (x86)\\Microsoft Visual Studio\\*.exe",
                "?:\\Program Files (x86)\\PMP\\jre\\bin\\java.exe",
                "?:\\Program Files\\ManageEngine\\PMP\\jre\\bin\\java.exe",
                "?:\\Program Files\\ManageEngine\\PAM360\\jre\\bin\\java.exe",
                "?:\\Program Files (x86)\\Adaptiva\\AdaptivaClient\\bin\\AdaptivaClientService.exe",
                "?:\\Program Files\\Adaptiva\\AdaptivaClient\\bin\\AdaptivaClientService.exe",
                "C:\\Program Files\\Siemens\\teamplay\\bin\\*\\syngo.Cloud.Receiver.Plugin.DicomTagResolver.exe",
                "?:\\Program Files\\Sql Server Extension\\SqlServerExtension.Service.exe",
                "C:\\Program Files\\Siemens\\CloudLink\\*.exe",
                "C:\\Program Files (x86)\\Razer\\Razer Cortex\\RazerCortex.exe",
                "C:\\Program Files\\Guard\\Data Vault Publisher for Citect\\*.exe",
                "C:\\Program Files\\Koios\\Koios DS\\KoiosDS-MVC-App.exe",
                "?:\\Program Files\\Commvault\\ContentStore\\DotNetCore\\dotnet.exe",
                "?:\\Program Files\\Siemens\\ABT Site\\Bin\\Siemens.BASys.ABTSite.exe") and
 not _arraysearch(process.thread.Ext.call_stack, $entry,
                    $entry.callsite_trailing_bytes : ("c5f8774883ec10c5fb1104244883ec104889042449ba00000000000000004*",
                                                      "*488b8d48ffffff48894b104c8b658049894424084c896588c745c0*"))
'''

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

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


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

[internal]
min_endpoint_version = "8.8.0"

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

[rule]
author = ["Elastic"]
description = """
Identifies modification of the dynamic linker preload shared object (ld.so.preload). Adversaries may execute malicious
payloads by hijacking the dynamic linker used to load libraries.
"""
from = "now-9m"
index = ["auditbeat-*", "logs-endpoint.events.*", "endgame-*"]
language = "kuery"
license = "Elastic License v2"
name = "Modification of Dynamic Linker Preload Shared Object"
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 Modification of Dynamic Linker Preload Shared Object

The dynamic linker preload mechanism in Linux, via `/etc/ld.so.preload`, allows preloading of shared libraries, influencing how executables load dependencies. Adversaries exploit this by inserting malicious libraries, hijacking execution flow for privilege escalation. The detection rule monitors changes to this file, excluding benign processes, to identify unauthorized modifications indicative of such abuse.

### Possible investigation steps

- Review the alert details to confirm the file path involved is /etc/ld.so.preload and verify the event action is one of the specified actions: updated, renamed, or file_rename_event.
- Identify the process responsible for the modification by examining the process.name field, ensuring it is not one of the excluded processes (wine or oneagentinstallaction).
- Investigate the process that triggered the alert by gathering additional context such as process ID, command line arguments, and parent process to understand its origin and purpose.
- Check the modification timestamp and correlate it with other system events or logs to identify any suspicious activity or patterns around the time of the modification.
- Analyze the contents of /etc/ld.so.preload to determine if any unauthorized or suspicious libraries have been added, and assess their potential impact on the system.
- Review user accounts and permissions associated with the process to determine if there has been any unauthorized access or privilege escalation attempt.
- If malicious activity is confirmed, isolate the affected system and follow incident response procedures to mitigate the threat and prevent further exploitation.

### False positive analysis

- Legitimate software installations or updates may modify /etc/ld.so.preload. To handle this, monitor the process names associated with these activities and consider adding them to the exclusion list if they are verified as benign.
- System management tools like configuration management software might update /etc/ld.so.preload as part of routine operations. Identify these tools and exclude their process names from the detection rule to prevent false alerts.
- Custom scripts or administrative tasks executed by trusted users could inadvertently trigger the rule. Review these scripts and, if necessary, exclude their process names or user accounts from the detection criteria.
- Security agents or monitoring tools that interact with system files might cause false positives. Verify these tools' activities and exclude their process names if they are known to be safe and necessary for system operations.

### Response and remediation

- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement by the adversary.
- Terminate any suspicious processes that are not part of the baseline or known benign applications, especially those related to the modification of `/etc/ld.so.preload`.
- Restore the `/etc/ld.so.preload` file from a known good backup to ensure no malicious libraries are preloaded.
- Conduct a thorough review of recent system changes and installed packages to identify any unauthorized software or modifications that may have facilitated the attack.
- Escalate the incident to the security operations team for a deeper forensic analysis to determine the scope of the compromise and identify any additional affected systems.
- Implement additional monitoring on the affected system and similar environments to detect any further attempts to modify the dynamic linker preload file.
- Review and enhance access controls and permissions on critical system files like `/etc/ld.so.preload` to prevent unauthorized modifications in the future."""
references = [
    "https://www.anomali.com/blog/rocke-evolves-its-arsenal-with-a-new-malware-family-written-in-golang",
]
risk_score = 47
rule_id = "717f82c2-7741-4f9b-85b8-d06aeb853f4f"
setup = """## Setup

This rule requires data coming in from one of the following integrations:
- Elastic Defend
- Auditbeat

### 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).

### Auditbeat Setup
Auditbeat is a lightweight shipper that you can install on your servers to audit the activities of users and processes on your systems. For example, you can use Auditbeat to collect and centralize audit events from the Linux Audit Framework. You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations.

#### The following steps should be executed in order to add the Auditbeat on a Linux System:
- Elastic provides repositories available for APT and YUM-based distributions. Note that we provide binary packages, but no source packages.
- To install the APT and YUM repositories follow the setup instructions in this [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/setup-repositories.html).
- To run Auditbeat on Docker follow the setup instructions in the [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-docker.html).
- To run Auditbeat on Kubernetes follow the setup instructions in the [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/running-on-kubernetes.html).
- For complete “Setup and Run Auditbeat” information refer to the [helper guide](https://www.elastic.co/guide/en/beats/auditbeat/current/setting-up-and-running.html).
"""
severity = "medium"
tags = [
    "Domain: Endpoint",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Privilege Escalation",
    "Data Source: Elastic Endgame",
    "Data Source: Elastic Defend",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "new_terms"

query = '''
host.os.type:linux and event.category:file and event.action:(file_rename_event or rename or renamed or updated) and
not event.type:deletion and file.path:/etc/ld.so.preload and
process.name:(* and not (oneagentinstallaction or passwd or wine))
'''

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

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

[[rule.threat.technique.subtechnique]]
id = "T1574.006"
name = "Dynamic Linker Hijacking"
reference = "https://attack.mitre.org/techniques/T1574/006/"

[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 = "T1574"
name = "Hijack Execution Flow"
reference = "https://attack.mitre.org/techniques/T1574/"

[[rule.threat.technique.subtechnique]]
id = "T1574.006"
name = "Dynamic Linker Hijacking"
reference = "https://attack.mitre.org/techniques/T1574/006/"

[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 = "T1574"
name = "Hijack Execution Flow"
reference = "https://attack.mitre.org/techniques/T1574/"

[[rule.threat.technique.subtechnique]]
id = "T1574.006"
name = "Dynamic Linker Hijacking"
reference = "https://attack.mitre.org/techniques/T1574/006/"

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

[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-5d"