Elastic rules: 2c

[metadata]
creation_date = "2020/03/25"
integration = ["endpoint", "windows"]
maturity = "production"
min_stack_version = "9.4.0"
min_stack_comments = "Use EA (Entity Analytics) fields"
updated_date = "2026/07/27"

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

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

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

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


[rule]
anomaly_threshold = 50
author = ["Elastic"]
description = """
Identifies unusual parent-child process relationships that can indicate malware execution or persistence mechanisms.
Malicious scripts often call on other applications and processes as part of their exploit payload. For example, when a
malicious Office document runs scripts as part of an exploit payload, Excel or Word may start a script interpreter
process, which, in turn, runs a script that downloads and executes malware. Another common scenario is Outlook running
an unusual process when malware is downloaded in an email. Monitoring and identifying anomalous process relationships is
a method of detecting new and emerging malware that is not yet recognized by anti-virus scanners.
"""
false_positives = [
    """
    Users running scripts in the course of technical support operations of software upgrades could trigger this alert. A
    newly installed program or one that runs rarely as part of a monthly or quarterly workflow could trigger this alert.
    """,
]
from = "now-45m"
interval = "15m"
license = "Elastic License v2"
machine_learning_job_id = ["v3_windows_anomalous_process_creation_ea"]
name = "Anomalous Windows Process Creation"
note = """## Triage and analysis

###  Investigating Anomalous Windows Process Creation

Searching for abnormal Windows processes is a good methodology to find potentially malicious activity within a network. Understanding what is commonly run within an environment and developing baselines for legitimate activity can help uncover potential malware and suspicious behaviors.

This rule uses a machine learning job to detect an anomalous Windows process with an unusual parent-child relationship, which could indicate malware execution or persistence activities on the host machine.

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

#### Possible investigation steps

- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.
  - If the parent process is a legitimate system utility or service, this could be related to software updates or system management. If the parent process is something user-facing like an Office application, this process could be more suspicious.
  - Investigate the process metadata — such as the digital signature, directory, etc. — to obtain more context that can indicate whether the executable is associated with an expected software vendor or package.
- Investigate other alerts associated with the user/host during the past 48 hours.
- Consider the user as identified by the `user.name` field. Is this program part of an expected workflow for the user who ran this program on this host?
- Validate the activity is not related to planned patches, updates, network administrator activity, or legitimate software installations.
- Validate if the activity has a consistent cadence (for example, if it runs monthly or quarterly), as it could be part of a monthly or quarterly business process.
- Examine the arguments and working directory of the process. These may provide indications as to the source of the program or the nature of the tasks it is performing.
- Examine the host for derived artifacts that indicate suspicious activities:
  - Analyze the process executable using a private sandboxed analysis system.
  - Observe and collect information about the following activities in both the sandbox and the alert subject host:
    - Attempts to contact external domains and addresses.
      - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`.
      - Examine the DNS cache for suspicious or anomalous entries.
        - $osquery_0
    - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree.
    - Examine the host services for suspicious or anomalous entries.
      - $osquery_1
      - $osquery_2
      - $osquery_3
  - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc.

### False Positive Analysis

- If this activity is related to new benign software installation activity, consider adding exceptions — preferably with a combination of user and command line conditions.
- Try to understand the context of the execution by thinking about the user, machine, or business purpose. A small number of endpoints, such as servers with unique software, might appear unusual but satisfy a specific business need.

### Related Rules

- Unusual Process For a Windows Host - 6d448b96-c922-4adb-b51c-b767f1ea5b76
- Unusual Windows Path Activity - 445a342e-03fb-42d0-8656-0367eb2dead5
- Unusual Windows Process Calling the Metadata Service - abae61a8-c560-4dbd-acca-1e1438bff36b

### Response and Remediation

- Initiate the incident response process based on the outcome of the triage.
- Isolate the involved hosts to prevent further post-compromise behavior.
- 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.
- 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://www.elastic.co/guide/en/security/current/prebuilt-ml-jobs.html"]
risk_score = 21
rule_id = "0b29cab4-dbbd-4a3f-9e8e-1287c7c11ae5"
setup = """## Setup

This rule requires the installation of associated Machine Learning jobs, as well as data coming in from one of the following integrations:
- Elastic Defend
- Windows

### Anomaly Detection Setup

Once the rule is enabled, the associated Machine Learning job will start automatically. You can view the Machine Learning job linked under the "Definition" panel of the detection rule. If the job does not start due to an error, the issue must be resolved for the job to commence successfully. For more details on setting up anomaly detection jobs, refer to the [helper guide](https://www.elastic.co/guide/en/kibana/current/xpack-ml-anomalies.html).

### 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 to your 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/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).

### Windows Integration Setup
The Windows integration allows you to monitor the Windows OS, services, applications, and more.

#### The following steps should be executed in order to add the Elastic Agent System integration "windows" to your system:
- Go to the Kibana home page and click “Add integrations”.
- In the query bar, search for “Windows” and select the integration to see more details about it.
- Click “Add Windows”.
- Configure the integration name and optionally add a description.
- Review optional and advanced settings accordingly.
- Add the newly installed “windows” to an existing or a new agent policy, and deploy the agent on your system from which windows log files are desirable.
- Click “Save and Continue”.
- For more details on the integration refer to the [helper guide](https://docs.elastic.co/integrations/windows).
"""
severity = "low"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Data Source: Elastic Defend",
    "Data Source: Windows Security Event Logs",
    "Use Case: Threat Detection",
    "Rule Type: ML",
    "Rule Type: Machine Learning",
    "Tactic: Persistence",
    "Resources: Investigation Guide",
]
type = "machine_learning"
[[rule.threat]]
framework = "MITRE ATT&CK"

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

[rule.threat.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]]
id = "T1203"
name = "Exploitation for Client Execution"
reference = "https://attack.mitre.org/techniques/T1203/"

[[rule.threat.technique]]
id = "T1204"
name = "User Execution"
reference = "https://attack.mitre.org/techniques/T1204/"

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

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

[metadata]
creation_date = "2026/06/05"
integration = ["aws"]
maturity = "production"
updated_date = "2026/07/09"

[rule]
author = ["Elastic"]
description = """
Identifies an AWS principal performing a high volume of Amazon Bedrock inference API calls against a single model within
a short window. Membership inference attacks require hundreds to thousands of statistically similar queries whose
prompts and responses are intentionally content-benign, making guardrail- and content-based rules ineffective. This rule
detects the high-frequency single-model probing pattern that precedes membership inference and related exfiltration via
the inference API. It is a behavioral / volumetric precursor: it does not observe model confidence scores and a fixed
call-count threshold only catches the loud variant, so paced, low-and-slow, or credential-distributed probing will evade
it. Definitive membership inference detection requires ML anomaly analysis over per-entity inference-rate and
response-distribution baselines.
"""
false_positives = [
    """
    Automated agents, chat applications, retrieval-augmented generation services, evaluation pipelines, and load tests
    routinely generate high Bedrock inference volume against one model and will exceed any fixed threshold. Validate the
    principal, user agent, source IP, and application context before treating the activity as malicious, and tune the
    threshold to the deployment.
    """,
]
from = "now-60m"
interval = "10m"
language = "esql"
license = "Elastic License v2"
name = "AWS Bedrock High-Frequency Single-Model Inference API Probing"
note = """## Triage and analysis

### Investigating AWS Bedrock High-Frequency Single-Model Inference API Probing

Membership inference compares many samples against a model to infer whether specific records were present in training data. Because prompts and responses often appear benign, the actionable signal is frequently statistical: unusually high inference rates concentrated on one model from a single principal. AWS CloudTrail records the core Bedrock runtime operations (`InvokeModel`, `InvokeModelWithResponseStream`, `Converse`, `ConverseStream`) as management events, which are logged by default, so this probing phase is observable at the API layer even when Bedrock model invocation logging is disabled. CloudTrail does not capture the prompt body, so this rule is purely volumetric.

This rule is tuned to the loud case. Treat it as corroborating signal alongside other Bedrock alerts, not as conclusive membership inference detection.

#### Possible investigation steps

- Identify the principal in `aws.cloudtrail.user_identity.arn` and the targeted model in the extracted `Esql.model_id`.
- Determine whether the call volume exceeds the principal's historical baseline for the same model.
- Review companion Bedrock invocation logs, if enabled, for short prompts, repeated inputs, or low-variance responses that may indicate membership testing.
- Inspect `Esql.source_ip_values`, `Esql.user_agent_original_values`, and recent IAM activity for signs of compromised credentials or unexpected automation.
- Correlate with bulk output-extraction or guardrail alerts that may indicate a broader inference abuse campaign.

### Response and remediation

- Apply Bedrock service quotas and IAM least privilege for inference APIs while investigating.
- Enable model invocation logging for content-level review if not already configured.
- If abuse is confirmed, rotate access keys or disable the compromised principal.
"""
references = [
    "https://atlas.mitre.org/techniques/AML.T0024",
    "https://atlas.mitre.org/techniques/AML.T0024.000",
    "https://docs.aws.amazon.com/bedrock/latest/userguide/logging-using-cloudtrail.html",
    "https://www.elastic.co/security-labs/elastic-advances-llm-security",
]
risk_score = 47
rule_id = "56312ef5-656c-4bf7-ad9a-affed052b102"
setup = """## Setup

This rule requires AWS CloudTrail management events for Amazon Bedrock and ingestion via the AWS
integration (`aws.cloudtrail` data stream). The core Bedrock runtime operations are logged as management
events by default; no Bedrock model invocation logging is required.

"""
severity = "medium"
tags = [
    "Domain: Cloud",
    "Domain: LLM",
    "Data Source: AWS",
    "Data Source: Amazon Web Services",
    "Data Source: AWS CloudTrail",
    "Use Case: Threat Detection",
    "Tactic: Exfiltration",
    "Mitre Atlas: T0024",
    "Mitre Atlas: T0024.000",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "esql"

query = '''
FROM logs-aws.cloudtrail-*
| WHERE event.provider == "bedrock.amazonaws.com"
    AND event.action IN (
      "InvokeModel",
      "Converse",
      "ConverseStream",
      "InvokeModelWithResponseStream"
    )
    AND event.outcome == "success"
    AND aws.cloudtrail.user_identity.arn IS NOT NULL
    AND aws.cloudtrail.request_parameters IS NOT NULL
| GROK aws.cloudtrail.request_parameters """modelId=(?<Esql.model_id>[^,}\]]+)"""
| WHERE Esql.model_id IS NOT NULL
| STATS
    Esql.inference_call_count = COUNT(*),
    Esql.timestamp_min = MIN(@timestamp),
    Esql.timestamp_max = MAX(@timestamp),
    Esql.event_ingested_min = MIN(event.ingested),
    Esql.event_ingested_max = MAX(event.ingested),
    Esql.event_action_values = VALUES(event.action),
    Esql.source_ip_values = VALUES(source.ip),
    Esql.source_as_organization_name_values =
      VALUES(source.as.organization.name),
    Esql.source_geo_country_iso_code_values =
      VALUES(source.geo.country_iso_code),
    Esql.source_geo_city_name_values =
      VALUES(source.geo.city_name),
    Esql.user_name_values = VALUES(user.name),
    Esql.user_agent_original_values = VALUES(user_agent.original),
    Esql.aws_cloudtrail_user_identity_type_values =
      VALUES(aws.cloudtrail.user_identity.type),
    Esql.aws_cloudtrail_user_identity_access_key_id_values =
      VALUES(aws.cloudtrail.user_identity.access_key_id),
    Esql.session_issuer_arn_values =
      VALUES(aws.cloudtrail.user_identity.session_context.session_issuer.arn),
    Esql.cloud_region_values = VALUES(cloud.region),
    Esql.data_stream_namespace_values = VALUES(data_stream.namespace)
  BY aws.cloudtrail.user_identity.arn,
     cloud.account.id,
     Esql.model_id
| WHERE Esql.inference_call_count >= 500
| KEEP
    aws.cloudtrail.user_identity.arn,
    cloud.account.id,
    Esql.*
| sort Esql.inference_call_count desc
'''

[rule.alert_suppression]
group_by = ["aws.cloudtrail.user_identity.arn","cloud.account.id"]
missing_fields_strategy = "suppress"
[rule.alert_suppression.duration]
unit = "m"
value = 60
  
[rule.investigation_fields]
field_names = [
"aws.cloudtrail.user_identity.arn", 
"cloud.account.id", 
"Esql.model_id", 
"Esql.inference_call_count",
"Esql.user_agent_original_values",
"Esql.source_ip_values",
"Esql.user_name_values"
]

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

[rule]
author = ["Elastic"]
description = """
Identifies deletion of the AWS account password policy via DeleteAccountPasswordPolicy. The account password policy
enforces minimum password requirements (length, complexity, rotation, and reuse) for all IAM users in the account.
Deleting it removes those requirements account-wide, weakening authentication and easing follow-on credential-based
attacks. This is an account-level change that legitimately occurs only during deliberate administration, so its deletion
by an unexpected principal warrants review.
"""
false_positives = [
    """
    Identity and platform teams or infrastructure-as-code may delete or replace the account password policy during
    governance changes. Verify the principal in `aws.cloudtrail.user_identity.arn` against approved change records, and
    confirm whether a replacement policy was applied shortly after. Known administration roles and automation can be
    excluded after validation.
    """,
]
from = "now-6m"
index = ["logs-aws.cloudtrail-*"]
language = "kuery"
license = "Elastic License v2"
name = "AWS IAM Account Password Policy Deleted"
note = """## Triage and analysis

### Investigating AWS IAM Account Password Policy Deleted

The account password policy is an account-wide control that sets minimum password length, character complexity, maximum age, and reuse-prevention for all IAM users. `DeleteAccountPasswordPolicy` removes it entirely, reverting the account to no enforced password requirements — which weakens authentication and can facilitate credential attacks or mask weak credentials created later. Because this is a single, account-level, high-impact change, it should be deliberate and rare.

### Possible investigation steps

- Identify the actor in `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`, and `aws.cloudtrail.user_identity.session_context.session_issuer.arn`, and review `source.ip` / `user_agent.original`.
- Determine whether a replacement policy was set shortly after (`UpdateAccountPasswordPolicy`) or whether the account was left with no policy.
- Confirm whether the change aligns with an approved governance change.
- Correlate with recent activity by the same principal, such as creation of IAM users or login profiles, or other defense-evasion actions (CloudTrail/logging changes) that may indicate a broader effort to weaken controls.

### False positive analysis

- Approved governance or infrastructure-as-code may delete/replace the policy. Confirm the change is expected and exclude known administration roles or automation on `aws.cloudtrail.user_identity.arn` after validation.
- Note: AWS GuardDuty also surfaces account password policy changes via `Stealth:IAMUser/PasswordPolicyChange`; correlate if GuardDuty is enabled.

### Response and remediation

- If the deletion is unauthorized, restore an appropriate account password policy (`UpdateAccountPasswordPolicy`) that meets your organization's standards, and review any IAM users or login profiles created while no policy was enforced.
- Rotate or restrict credentials for the principal if compromise is suspected, and constrain `iam:DeleteAccountPasswordPolicy` and `iam:UpdateAccountPasswordPolicy` to a small set of trusted administrators.

"""
references = [
    "https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html",
    "https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteAccountPasswordPolicy.html",
]
risk_score = 47
rule_id = "283f6c2a-9811-4239-9a40-52b066c67f99"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Domain: Identity",
    "Data Source: AWS",
    "Data Source: Amazon Web Services",
    "Data Source: AWS IAM",
    "Use Case: Threat Detection",
    "Tactic: Defense Evasion",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset: "aws.cloudtrail"
    and event.provider: "iam.amazonaws.com"
    and event.action: "DeleteAccountPasswordPolicy"
    and event.outcome: "success"
    and not aws.cloudtrail.user_identity.type: "AWSService"
    and not user_agent.original: (*terraform* or *pulumi* or *ansible*)
    and not aws.cloudtrail.user_identity.arn: (*terraform* or *pulumi* or *ansible*)
    and not source.address: ("cloudformation.amazonaws.com" or "servicecatalog.amazonaws.com")
'''


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

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

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

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

[rule]
author = ["Elastic"]
description = """
Detects the execution of commands or scripts on EC2 instances using AWS Systems Manager (SSM), such as RunShellScript, RunPowerShellScript or custom documents. While legitimate users may employ these commands for management tasks, they can also be exploited by attackers with credentials to establish persistence, install malware, or execute reverse shells for further access to compromised instances. This is a New Terms rule that looks for the first instance of this behavior by a user or role.
"""
false_positives = [
    """
    Verify whether the user identity, user agent, and/or hostname should be making changes in your environment. Suspicious commands from unfamiliar users or hosts should be investigated. If known behavior is causing false positives, it can be exempted from the rule.
    """,
]
from = "now-6m"
interval = "5m"
index = ["filebeat-*", "logs-aws.cloudtrail-*"]
language = "kuery"
license = "Elastic License v2"
name = "AWS SSM `SendCommand` Execution by Rare User"
note = """## Triage and analysis

### Investigating AWS SSM `SendCommand` Execution by Rare User

This rule detects the execution of commands or scripts on EC2 instances using AWS Systems Manager (SSM) by an unexpected or new user. The SSM `SendCommand` action can enable remote command execution, which adversaries may exploit to install backdoors, deploy malware, or interact with compromised instances through reverse shells.

#### Possible Investigation Steps

- **Identify the Target Instance**:
  - **Instance ID**: Review the `aws.cloudtrail.request_parameters` field to identify which EC2 instances were targeted by this command. Confirm if these instances are expected to be managed through SSM.
  - **Document Used**: Check the `aws.cloudtrail.request_parameters` field, which specifies the name of the document or script being executed. Commands such as `RunShellScript` or `RunPowerShellScript` can indicate interactive sessions or script-based interactions.

- **Review User Context**:
  - **User Identity**: Inspect the `aws.cloudtrail.user_identity.arn` field to determine the user or role executing the `SendCommand`. If this user is not typically involved in EC2 or SSM interactions, this could indicate unauthorized access.
  - **Access Patterns**: Validate whether the user typically has permissions to perform `SendCommand` operations on instances and whether the frequency of this action matches expected behavior.

- **Analyze Command Parameters**:
  - **Document Contents**: While the exact command may not be visible in CloudTrail, use logs to determine the purpose of the script, especially if the document name suggests encryption, data transfer, or reverse shell capabilities.
  - **Timing and Context**: Compare this command execution with other recent SSM actions in your environment. A single `SendCommand` event by an unusual user can indicate an early stage of a larger attack.

- **Check User Agent and Source IP**:
  - **User Agent Analysis**: Review the `user_agent.original` field to verify the tool or client used (e.g., `aws-cli`). This can provide insight into whether this action was automated, scripted, or executed manually.
  - **Source IP and Geolocation**: Use `source.ip` and `source.geo` fields to check if the IP address and geolocation align with expected regions for your organization. Unusual IP addresses or locations can indicate external adversaries.

- **Evaluate for Persistence Indicators**:
  - **Command Consistency**: Investigate if this action is part of a recurring pattern, such as repeated command executions across instances, which may suggest an attempt to maintain access.
  - **Permissions**: Ensure that the IAM policies associated with the user limit `SendCommand` actions to necessary use cases. Consider adding alerts for commands executed by users with minimal roles or permissions.

- **Correlate with Other CloudTrail Events**:
  - **Cross-Reference SSM Actions**: Look for other recent SSM actions like `CreateDocument`, `UpdateDocument`, or additional `SendCommand` events that could indicate preparation for further exploitation.
  - **Monitor Data Access or Modification**: Correlate with S3 access patterns, IAM changes, or EC2 modifications in recent events to detect broader malicious activities.

### False Positive Analysis

- **Routine Automation**: SSM `SendCommand` may be used by automation scripts or management tools. Verify if this event aligns with known, routine automated workflows.
- **Maintenance Activity**: Confirm if legitimate administrative activities, such as patching or updates, are expected at this time, which may involve similar commands executed on multiple instances.

### Response and Remediation

- **Limit SSM Permissions**: If unauthorized, immediately revoke `SendCommand` permissions from the user or role to prevent further access.
- **Quarantine Target Instance**: If malicious behavior is confirmed, isolate the affected EC2 instance(s) to limit lateral movement or data exfiltration.
- **Investigate and Contain User Account**: If the action was performed by a compromised account, review recent activity and reset access credentials as necessary.
- **Audit SSM and IAM Configurations**: Periodically review permissions associated with SSM usage and ensure least privilege access principles are in place.

### Additional Information

For further details on managing AWS SSM and security best practices for EC2 instances, refer to the [AWS Systems Manager Documentation](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-plugins.html) and AWS best practices.
"""
references = ["https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-plugins.html"]
risk_score = 21
rule_id = "37b211e8-4e2f-440f-86d8-06cc8f158cfa"
severity = "low"
tags = [
    "Domain: Cloud",
    "Data Source: AWS",
    "Data Source: Amazon Web Services",
    "Data Source: AWS SSM",
    "Data Source: AWS Systems Manager",
    "Use Case: Log Auditing",
    "Use Case: Threat Detection",
    "Tactic: Execution",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "new_terms"

query = '''
data_stream.dataset: "aws.cloudtrail"
    and event.provider: "ssm.amazonaws.com"
    and event.action: "SendCommand"
    and event.outcome: "success"
    and not source.address: (
      "ssm-guiconnect.amazonaws.com" or
      "ssm.amazonaws.com" or
      "inspector2.amazonaws.com"
    )
'''

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

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


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

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

[metadata]
creation_date = "2021/08/12"
integration = ["azure"]
maturity = "production"
updated_date = "2026/04/10"

[rule]
author = ["Austin Songer"]
description = """
Identifies potential full network packet capture in Azure. Packet Capture is an Azure Network Watcher feature that can
be used to inspect network traffic. This feature can potentially be abused to read sensitive data from unencrypted
internal traffic.
"""
false_positives = [
    """
    Full Network Packet Capture may be done by a system or network administrator. Verify whether the user identity, user
    agent, and/or hostname should be making changes in your environment. Full Network Packet Capture from unfamiliar
    users or hosts should be investigated. If known behavior is causing false positives, it can be exempted from the
    rule.
    """,
]
from = "now-9m"
index = ["logs-azure.activitylogs-*", "filebeat-*"]
language = "kuery"
license = "Elastic License v2"
name = "Azure VNet Full Network Packet Capture Enabled"
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 Azure VNet Full Network Packet Capture Enabled

Azure's Packet Capture is a feature of Network Watcher that allows for the inspection of network traffic, useful for diagnosing network issues. However, if misused, it can capture sensitive data from unencrypted traffic, posing a security risk. Adversaries might exploit this to access credentials or other sensitive information. The detection rule identifies suspicious packet capture activities by monitoring specific Azure activity logs for successful operations, helping to flag potential misuse.

### Possible investigation steps

- Review the Azure activity logs to identify the specific user or service principal associated with the packet capture operation by examining the `azure.activitylogs.operation_name` and `event.dataset` fields.
- Check the timestamp of the detected packet capture activity to determine the exact time frame of the event and correlate it with any other suspicious activities or changes in the environment.
- Investigate the source and destination IP addresses involved in the packet capture to understand the scope and potential impact, focusing on any unencrypted traffic that might have been captured.
- Verify the legitimacy of the packet capture request by contacting the user or team responsible for the operation to confirm if it was authorized and necessary for troubleshooting or other legitimate purposes.
- Assess the risk of exposed sensitive data by identifying any critical systems or services that were part of the captured network traffic, especially those handling credentials or personal information.

### False positive analysis

- Routine network diagnostics by authorized personnel can trigger the rule. To manage this, create exceptions for specific user accounts or IP addresses known to perform regular diagnostics.
- Automated network monitoring tools might initiate packet captures as part of their normal operations. Identify these tools and exclude their activities from triggering alerts.
- Scheduled maintenance activities often involve packet captures for performance analysis. Document these schedules and configure the rule to ignore captures during these periods.
- Development and testing environments may frequently use packet capture for debugging purposes. Exclude these environments by filtering based on resource tags or environment identifiers.
- Legitimate security audits may involve packet capture to assess network security. Coordinate with the audit team to whitelist their activities during the audit period.

### Response and remediation

- Immediately isolate the affected network segment to prevent further unauthorized packet capture and potential data exfiltration.
- Revoke any suspicious or unauthorized access to Azure Network Watcher and related resources to prevent further misuse.
- Conduct a thorough review of the captured network traffic logs to identify any sensitive data exposure and assess the potential impact.
- Reset credentials and access tokens for any accounts or services that may have been compromised due to exposed unencrypted traffic.
- Implement network encryption protocols to protect sensitive data in transit and reduce the risk of future packet capture exploitation.
- Escalate the incident to the security operations team for further investigation and to determine if additional security measures are necessary.
- Enhance monitoring and alerting for Azure Network Watcher activities to detect and respond to similar threats more effectively in the future.

## Setup

The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
references = ["https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations"]
risk_score = 47
rule_id = "3ad77ed4-4dcf-4c51-8bfc-e3f7ce316b2f"
severity = "medium"
tags = ["Domain: Cloud", "Data Source: Azure", "Tactic: Credential Access", "Resources: Investigation Guide"]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:azure.activitylogs and azure.activitylogs.operation_name:
    (
        MICROSOFT.NETWORK/*/STARTPACKETCAPTURE/ACTION or
        MICROSOFT.NETWORK/*/VPNCONNECTIONS/STARTPACKETCAPTURE/ACTION or
        MICROSOFT.NETWORK/*/PACKETCAPTURES/WRITE
    ) and
event.outcome:(Success or success)
'''


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

[[rule.threat.technique]]
id = "T1040"
name = "Network Sniffing"
reference = "https://attack.mitre.org/techniques/T1040/"

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

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

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

[rule]
author = ["Elastic"]
description = """
Detects the creation of files related to the configuration of the dynamic linker on Linux systems. The dynamic linker
is a shared library that is used by the Linux kernel to load and execute programs. Attackers may attempt to hijack
the execution flow of a program by modifying the dynamic linker configuration files. This technique is often observed
by userland rootkits that leverage shared objects to maintain persistence on a compromised host.
"""
from = "now-9m"
index = ["logs-endpoint.events.file*"]
language = "eql"
license = "Elastic License v2"
name = "Dynamic Linker Creation"
risk_score = 47
rule_id = "640f79d1-571d-4f96-a9af-1194fc8cf763"
setup = """## Setup

This rule requires data coming in from Elastic Defend.

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

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

#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
- Go to the Kibana home page and click "Add integrations".
- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
- Click "Add Elastic Defend".
- Configure the integration name and optionally add a description.
- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).
- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead.
For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
- Click "Save and Continue".
- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts.
For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
"""
severity = "medium"
tags = [
    "Domain: Endpoint",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Defense Evasion",
    "Tactic: Persistence",
    "Data Source: Elastic Defend",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
file where host.os.type == "linux" and event.action == "creation" and
file.path like ("/etc/ld.so.preload", "/etc/ld.so.conf.d/*", "/etc/ld.so.conf") and
not (
  process.executable in (
    "/bin/dpkg", "/usr/bin/dpkg", "/bin/dockerd", "/usr/bin/dockerd", "/usr/sbin/dockerd", "/bin/microdnf",
    "/usr/bin/microdnf", "/bin/rpm", "/usr/bin/rpm", "/bin/snapd", "/usr/bin/snapd", "/bin/yum", "/usr/bin/yum",
    "/bin/dnf", "/usr/bin/dnf", "/bin/podman", "/usr/bin/podman", "/bin/dnf-automatic", "/usr/bin/dnf-automatic",
    "/bin/pacman", "/usr/bin/pacman", "/usr/bin/dpkg-divert", "/bin/dpkg-divert", "/sbin/apk", "/usr/sbin/apk",
    "/usr/local/sbin/apk", "/usr/bin/apt", "/usr/sbin/pacman", "/bin/podman", "/usr/bin/podman", "/usr/bin/puppet",
    "/bin/puppet", "/opt/puppetlabs/puppet/bin/puppet", "/usr/bin/chef-client", "/bin/chef-client",
    "/bin/autossl_check", "/usr/bin/autossl_check", "/proc/self/exe",  "/usr/bin/pamac-daemon",
    "/bin/pamac-daemon", "/usr/lib/snapd/snapd", "/usr/local/bin/dockerd", "/usr/libexec/platform-python",
    "/usr/lib/snapd/snap-update-ns", "/usr/bin/vmware-config-tools.pl", "./usr/bin/podman", "/bin/nvidia-cdi-hook",
    "/usr/lib/dracut/dracut-install", "./usr/bin/nvidia-cdi-hook", "/.envbuilder/bin/envbuilder", "/usr/bin/buildah",
    "/usr/sbin/dnf", "/usr/bin/pamac", "/sbin/pacman", "/usr/bin/crio", "/usr/sbin/yum-cron"
  ) or
  file.extension in ("swp", "swpx", "swx", "dpkg-remove") or
  file.Ext.original.extension == "dpkg-new" or
  process.executable : (
    "/nix/store/*", "/var/lib/dpkg/*", "/snap/*", "/dev/fd/*", "/usr/lib/virtualbox/*", "/opt/dynatrace/oneagent/*",
    "/usr/libexec/platform-python*"
  ) or
  process.executable == null or
  process.name in (
    "java", "executor", "ssm-agent-worker", "packagekitd", "crio", "dockerd-entrypoint.sh",
    "docker-init", "BootTimeChecker", "dockerd (deleted)", "dockerd"
  ) or
  (process.name == "sed" and file.name : "sed*") or
  (process.name == "perl" and file.name : "e2scrub_all.tmp*") or
  (process.name == "init" and file.name == "ld.wsl.conf") or
  (process.name == "sshd" and file.extension == "dpkg-new")
)
'''
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 Dynamic Linker Creation or Modification

The dynamic linker in Linux systems is crucial for loading shared libraries needed by programs at runtime. Adversaries may exploit this by altering linker configuration files to hijack program execution, enabling persistence or evasion. The detection rule identifies suspicious creation or renaming of these files, excluding benign processes and extensions, to flag potential threats.

### Possible investigation steps

- Review the file path involved in the alert to determine if it matches any of the critical dynamic linker configuration files such as /etc/ld.so.preload, /etc/ld.so.conf.d/*, or /etc/ld.so.conf.
- Identify the process that triggered the alert by examining the process.executable field and verify if it is listed as a benign process in the exclusion list. If not, investigate the legitimacy of the process.
- Check the file extension and file.Ext.original.extension fields to ensure the file is not a temporary or expected system file, such as those with extensions like swp, swpx, swx, or dpkg-new.
- Investigate the process.name field to determine if the process is a known system utility like java, sed, or perl, and assess if its usage in this context is typical or suspicious.
- Gather additional context by reviewing recent system logs and other security alerts to identify any related or preceding suspicious activities that might indicate a broader attack or compromise.

### False positive analysis

- Package management operations can trigger false positives when legitimate package managers like dpkg, rpm, or yum modify linker configuration files. To handle this, ensure these processes are included in the exclusion list to prevent unnecessary alerts.
- System updates or software installations often involve temporary file modifications with extensions like swp or dpkg-new. Exclude these extensions to reduce false positives.
- Automated system management tools such as Puppet or Chef may modify linker files as part of their configuration management tasks. Add these tools to the exclusion list to avoid false alerts.
- Virtualization and containerization platforms like Docker or VMware may alter linker configurations during normal operations. Verify these processes and exclude them if they are part of routine system behavior.
- Custom scripts or applications that use common names like sed or perl might be flagged if they interact with linker files. Review these scripts and consider excluding them if they are verified as safe.

### Response and remediation

- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary.
- Review and restore the original dynamic linker configuration files from a known good backup to ensure the integrity of the system's execution flow.
- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any additional malicious software or scripts.
- Analyze system logs and the process execution history to identify the source of the unauthorized changes and determine if any other systems may be compromised.
- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on the organization.
- Implement additional monitoring on the affected system and similar systems to detect any future attempts to modify dynamic linker configuration files.
- Review and update access controls and permissions to ensure that only authorized personnel have the ability to modify critical system files, reducing the risk of similar incidents in the future."""

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

[metadata]
creation_date = "2026/05/14"
integration = ["azure"]
maturity = "production"
updated_date = "2026/05/14"

[rule]
author = ["Elastic"]
description = """
Detects Microsoft Entra ID sign-ins consistent with Tycoon2FA phishing-as-a-service (PhaaS) adversary-in-the-middle
(AiTM) activity: the Microsoft Authentication Broker requesting tokens for Microsoft Graph or Exchange Online, or the
Office web client application authenticating to itself, combined with Node.js-style user agents (node, axios, undici).
Tycoon 2FA bypasses MFA by relaying authentication and capturing session material, often targeting Microsoft 365 and
Gmail. Baseline legitimate automation and developer tooling before tuning.
"""
false_positives = [
    """
    Legitimate Node.js or undici-based automation, health checks, or internal services that use the Microsoft
    Authentication Broker or the same first-party application IDs against Graph or Exchange may match. Developers using
    axios or undici with delegated flows can also resemble this pattern.
    """,
]
from = "now-9m"
index = ["logs-azure.signinlogs-*"]
language = "kuery"
license = "Elastic License v2"
name = "Entra ID Potential AiTM Sign-In via OfficeHome (Tycoon2FA)"
note = """## Triage and analysis

### Investigating Entra ID Potential AiTM Sign-In via OfficeHome (Tycoon2FA)

Review user.name, azure.signinlogs.properties.user_principal_name, azure.signinlogs.properties.app_id,
azure.signinlogs.properties.resource_id, user_agent.original, source.ip, source.geo fields, and
azure.signinlogs.properties.session_id.

Confirm whether the user intentionally signed in and whether Node.js-style user agents (node, axios, undici) are
expected for Microsoft Authentication Broker or Office web client flows in your environment.

### Possible investigation steps

- Correlate the session with Microsoft Graph activity logs and mailbox audit for follow-on data access.
- Review conditional access outcomes and MFA detail for the same session.
- Hunt for other sign-ins from the same source IP with unusual user agents or rapid OAuth patterns.

### Response and remediation

- If malicious, revoke refresh tokens for the user, reset credentials per policy, and review application consent.
- Block or monitor the source IP and escalate per incident procedures.
"""
references = ["https://any.run/malware-trends/tycoon/"]
risk_score = 73
rule_id = "6e6376c1-a71e-4789-a795-198b05664064"
severity = "high"
tags = [
    "Domain: Cloud",
    "Domain: Identity",
    "Data Source: Azure",
    "Data Source: Microsoft Entra ID",
    "Data Source: Microsoft Entra ID Sign-in Logs",
    "Use Case: Threat Detection",
    "Threat: Tycoon2FA",
    "Tactic: Initial Access",
    "Tactic: Credential Access",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"
query = '''
data_stream.dataset:"azure.signinlogs" and event.category:"authentication" and
event.action:"Sign-in activity" and
(
    (
        azure.signinlogs.properties.app_id:"29d9ed98-a469-4536-ade2-f981bc1d605e" and
        azure.signinlogs.properties.resource_id:(
            "00000002-0000-0ff1-ce00-000000000000" or "00000003-0000-0000-c000-000000000000"
        )
    ) or
    (
        azure.signinlogs.properties.app_id:"4765445b-32c6-49b0-83e6-1d93765276ca" and
        azure.signinlogs.properties.resource_id:"4765445b-32c6-49b0-83e6-1d93765276ca"
    )
) and user_agent.original:(node or axios* or undici)
'''

[rule.investigation_fields]
field_names = [
    "@timestamp",
    "user.name",
    "user_agent.original",
    "source.ip",
    "source.geo.country_name",
    "event.outcome",
    "azure.signinlogs.properties.user_principal_name",
    "azure.signinlogs.properties.session_id",
    "azure.signinlogs.properties.app_display_name",
    "azure.signinlogs.properties.app_id",
    "azure.signinlogs.properties.resource_display_name",
    "azure.signinlogs.properties.resource_id",
    "azure.signinlogs.properties.authentication_protocol",
    "azure.tenant_id",
]

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

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

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

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

[[rule.threat.technique]]
id = "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/"

[metadata]
creation_date = "2025/07/02"
integration = ["azure", "o365"]
maturity = "production"
updated_date = "2026/07/08"

[rule]
author = ["Elastic"]
description = """
Identifies potential enumeration or password spraying activity using TeamFiltration tool. TeamFiltration is an
open-source enumeration, password spraying and exfiltration tool designed for Entra ID and Microsoft 365. Adversaries
are known to use TeamFiltration in-the-wild to enumerate users, groups, and roles, as well as to perform password
spraying attacks against Microsoft Entra ID and Microsoft 365 accounts. This rule detects the use of TeamFiltration by
monitoring for specific user-agent strings associated with the tool in Azure and Microsoft 365 logs.
"""
false_positives = [
    """
    Legitimate administrative or security assessment activities may use these user-agents, especially in environments
    where TeamFiltration is employed for authorized audits. If this is expected behavior, consider adjusting the rule or
    adding exceptions for specific user-agents or IP addresses.
    """,
    """
    Expected red team assessments or penetration tests may utilize TeamFiltration to evaluate the security posture of
    Azure or Microsoft 365 environments. If this is expected behavior, consider adjusting the rule or adding exceptions
    for specific IP addresses, registered applications, JWT tokens, PRTs or user
    """,
]
from = "now-9m"
index = ["filebeat-*", "logs-azure.signinlogs-*", "logs-o365.audit-*"]
language = "kuery"
license = "Elastic License v2"
name = "Entra ID Sign-in TeamFiltration User-Agent Detected"
note = """## Triage and analysis

Identifies potential enumeration or password spraying activity using TeamFiltration tool. TeamFiltration is an open-source enumeration, password spraying and exfiltration tool designed for Entra ID and Microsoft 365. Adversaries are known to use TeamFiltration in-the-wild to enumerate users, groups, and roles, as well as to perform password spraying attacks against Microsoft Entra ID and Microsoft 365 accounts. This rule detects the use of TeamFiltration by monitoring for specific user-agent strings associated with the tool in Azure and Microsoft 365 logs.

The detection is based on TeamFiltration's hardcoded user agent string and/or the use of `Electron` by monitoring multiple log sources, including:

- Azure Graph API Activity Logs
- Microsoft 365 Audit Logs
- Entra ID Sign-in Logs
- Entra ID Audit Logs
- Azure Activity Logs

### Possible investigation steps

- Confirm the tool used via `user_agent.original`.
- Identify the `user.id`, `user.name`, or `azure.signinlogs.properties.user_principal_name` fields to determine which identity executed the API requests or sign-in attempts.
- Review `app_id`, `app_display_name`, or `client_id` to identify the application context (e.g., Azure CLI, Graph Explorer, unauthorized app). TeamFiltration uses a list of FOCI compliant applications to perform enumeration and password spraying. TeamFiltration uses Microsoft Teams client ID `1fec8e78-bce4-4aaf-ab1b-5451cc387264` for enumeration.
- Check `http.request.method`, `http.response.status_code`, and `event.action` for enumeration patterns (many successful GETs in a short period) if Graph API activity logs.
- Investigate correlated sign-ins (`azure.signinlogs`) by the same user, IP, or app immediately preceding the API calls. Was MFA used? Is the location suspicious?
- Review `source.ip` or `client.geo.*` fields to determine the origin of the requests. Flag unexpected IPs or ISPs. Check the for the use of several source addresses originating from Amazon ASNs (e.g., `AS16509`, `AS14618`, `AS14618`) which are commonly used by TeamFiltration as it proxies requests through FireProx and Amazon API Gateway.
- If the event originates in M365 Audit Logs, investigate cross-service activity: Exchange Online, Teams, SharePoint, or role escalations via Unified Audit.

### False positive analysis

- This activity may be benign if performed by red teams, internal security auditors, or known security tools under authorization.

### Response and remediation

- If confirmed malicious:
    - Identify successful sign-in attempts or API calls made by the user or app.
    - Revoke active sessions or tokens associated with the identified user/app.
    - Disable the account or rotate credentials immediately.
    - Review the role assignments (`Directory.Read.All`, `AuditLog.Read.All`, `Directory.AccessAsUser.All`) and remove excessive privileges.
    - Conduct historical analysis to determine how long enumeration has been occurring and what objects were queried.
    - Enable Conditional Access policies to require MFA for API and CLI-based access.
    - Validate audit logging and alerting is enabled across Microsoft Graph, Azure Activity Logs, and M365 workloads.

- If legitimate:
    - Document the source or user (e.g., red team operation, security tool).
    - Add appropriate allowlist conditions for service principal, user, source address or device if policy allows.

"""
references = [
    "https://www.proofpoint.com/us/blog/threat-insight/attackers-unleash-teamfiltration-account-takeover-campaign",
    "https://github.com/Flangvik/TeamFiltration",
]
risk_score = 73
rule_id = "f541ca3a-5752-11f0-b44b-f661ea17fbcd"
severity = "high"
tags = [
    "Domain: Cloud",
    "Data Source: Azure",
    "Data Source: Microsoft 365",
    "Data Source: Microsoft 365 Audit Logs",
    "Data Source: Microsoft Entra ID",
    "Data Source: Microsoft Entra ID Sign-in Logs",
    "Use Case: Identity and Access Audit",
    "Use Case: Threat Detection",
    "Tactic: Discovery",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:("azure.signinlogs" or "o365.audit")
    and ((user_agent.name:"Electron" and user_agent.os.name:"Windows" and user_agent.version:"8.5.1") or
    user_agent.original:"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Teams/1.3.00.30866 Chrome/80.0.3987.165 Electron/8.5.1 Safari/537.36")
'''


[[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.003"
name = "Cloud Groups"
reference = "https://attack.mitre.org/techniques/T1069/003/"


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

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


[[rule.threat.technique]]
id = "T1201"
name = "Password Policy Discovery"
reference = "https://attack.mitre.org/techniques/T1201/"

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

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

[[rule.threat.technique]]
id = "T1673"
name = "Virtual Machine Discovery"
reference = "https://attack.mitre.org/techniques/T1673/"


[rule.threat.tactic]
id = "TA0007"
name = "Discovery"
reference = "https://attack.mitre.org/tactics/TA0007/"
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1110"
name = "Brute Force"
reference = "https://attack.mitre.org/techniques/T1110/"
[[rule.threat.technique.subtechnique]]
id = "T1110.003"
name = "Password Spraying"
reference = "https://attack.mitre.org/techniques/T1110/003/"



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

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

[rule]
author = ["Elastic"]
description = """
Identifies the creation of a Windows script downloaded from the internet followed by the execution of a scripting utility.
Adversaries may use Windows script files for initial access and execution.
"""
from = "now-9m"
index = ["logs-endpoint.events.file-*", "logs-endpoint.events.process-*"]
language = "eql"
license = "Elastic License v2"
name = "Execution of a Downloaded Windows Script"
risk_score = 47
rule_id = "79543b00-28a5-4461-81ac-644c4dc4012f"
severity = "medium"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Execution",
    "Data Source: Elastic Defend",
    "Resources: Investigation Guide"
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
sequence by host.id, user.id with maxspan=3m
[file where host.os.type == "windows" and event.action == "creation" and user.id != "S-1-5-18" and
  process.name : ("chrome.exe", "msedge.exe", "brave.exe", "browser.exe", "dragon.exe", "vivaldi.exe", "explorer.exe", "winrar.exe", "7zFM.exe", "7zG.exe", "Bandizip.exe") and
  file.extension in~ ("js", "jse", "vbs", "vbe", "wsh", "wsf", "sct", "hta", "cmd", "bat", "ps1", "msi") and
  (file.origin_url != null or file.origin_referrer_url != null)]
[process where host.os.type == "windows" and event.type == "start" and
 process.parent.name : ("chrome.exe", "msedge.exe", "brave.exe", "firefox.exe", "browser.exe", "dragon.exe", "vivaldi.exe", "explorer.exe", "winrar.exe", "7zFM.exe", "7zG.exe", "Bandizip.exe") and 
 process.args_count >= 2 and
 (
  process.name in~ ("wscript.exe", "cscript.exe", "mshta.exe") or
  (process.name : "cmd.exe" and process.command_line : ("*.cmd*", "*.bat*", "*.wsf*")) or
  (process.name in~ ("powershell.exe", "pwsh.exe") and process.command_line : "*.ps1*") or 
  (process.name : "msiexec.exe" and process.command_line : "*.msi" and process.args : ("/i*", "-i*"))
  )]
'''

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

note = """## Triage and analysis

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

### Investigating Execution of a downloaded windows script

Windows scripts, often used for legitimate automation tasks, can be exploited by adversaries to execute malicious code. Attackers may download scripts via browsers or file utilities, then execute them using scripting tools like wscript or mshta. The detection rule identifies such threats by monitoring script creation from internet sources and subsequent execution, focusing on unusual parent-child process relationships and script attributes.

### Possible investigation steps

- Review the file creation event to identify the specific script file that was downloaded, noting its name, path, and extension to understand the potential threat.
- Examine the origin URL or referrer URL of the downloaded script to determine the source and assess its legitimacy or potential malicious intent.
- Investigate the parent process, such as chrome.exe or explorer.exe, to understand how the script was downloaded and whether it aligns with typical user behavior.
- Analyze the execution event of the scripting utility (wscript.exe or mshta.exe) to identify the command-line arguments used, which may provide insight into the script's intended actions.
- Check the user account associated with the script execution to determine if the activity is expected for that user or if it indicates a compromised account.
- Correlate the timing of the script creation and execution events to see if they fall within a suspicious timeframe, such as outside of normal working hours.
- Look for any additional related alerts or logs on the host that might indicate further malicious activity or lateral movement following the script execution.

### False positive analysis

- Legitimate script automation tools may trigger this rule if they download and execute scripts from the internet. Users can create exceptions for known safe tools by excluding specific file paths or process names.
- Software updates or installations that download scripts as part of their process might be flagged. To handle this, users can whitelist specific origin URLs or referrer URLs associated with trusted software vendors.
- Internal scripts distributed via corporate intranet sites could be misidentified as threats. Users should consider excluding scripts with known internal origin URLs or specific user IDs associated with IT operations.
- Browser extensions or plugins that automate tasks using scripts may cause false positives. Users can exclude these by identifying and excluding the specific browser process names or file extensions involved.
- Frequent use of file utilities like winrar or 7zFM for legitimate script handling can be excluded by specifying trusted file paths or user IDs that regularly perform these actions.

### Response and remediation

- Isolate the affected system from the network to prevent further execution of potentially malicious scripts and lateral movement.
- Terminate any suspicious processes identified in the alert, such as wscript.exe or mshta.exe, to stop the execution of the downloaded script.
- Quarantine the downloaded script file and any associated files to prevent further execution and facilitate forensic analysis.
- 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 files or remnants.
- Review and analyze the origin URL and referrer URL of the downloaded script to identify potential malicious websites or compromised sources, and block these URLs at the network level.
- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.
- Implement application whitelisting to restrict the execution of unauthorized scripts and scripting utilities, reducing the risk of similar threats in the future."""


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

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

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

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

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

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

[[rule.threat.technique]]
id = "T1204"
name = "User Execution"
reference = "https://attack.mitre.org/techniques/T1204/"

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

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

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

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

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

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

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

[rule]
description = """
This rule detects the execution of curl or wget commands that download files from hosting services. Attackers may use
these services to temporary host malicious files or payloads for later execution.
"""
id = "5c18132a-e279-404e-a8d8-922546d469a7"
license = "Elastic License v2"
name = "File Download from or Upload to Hosting Service"
os_list = ["linux"]
version = "1.0.10"

query = '''
process where event.type == "start" and event.action == "exec" and process.name in ("curl", "wget") and
process.command_line like~ (
  "*pastebin.*", "*ghostbin.*", "*hastebin.*", "*termbin.*", "*dpaste.*", "*controlc.*", "*0bin.net*", "*p.ip.fi*", "*sprunge.us*", "*paste.ee*",
  "*paste.ofcode.org*", "*textbin.net*", "*transfer.sh*", "*anonfiles.*", "*easyupload.io*", "*gofile.io*", "*send.cm*", "*ufile.io*",
  "*pixeldrain.com*", "*bayfiles.*", "*megaupload.*", "*mediafire.*", "*zippyshare.com*", "*dropapk.to*", "*shorturl.at*", "*tinyurl.com*",
  "*bit.ly/*", "*cutt.ly/*", "*is.gd/*", "*rebrand.ly/*", "*adf.ly/*", "*rb.gy/*", "*bashupload.com/*", "*bujang.online/*", "*paste.wakas.org*",
  "*paste.c-net.org*", "*paste.hexaspaces.com*"
) and not (
  process.parent.executable in ("/opt/aws/awsagent/bin/update", "/batch/pac.liste.categorie.sh") or
  process.parent.args == "/usr/local/gg/crowdsec-extract.sh" or
  process.parent.command_line like "*/.claude/shell-snapshots/snapshot-*"
)
'''

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

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

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

[internal]
min_endpoint_version = "7.15.0"

[metadata]
creation_date = "2023/08/23"
integration = ["endpoint", "auditd_manager", "sentinel_one_cloud_funnel"]
maturity = "production"
updated_date = "2025/12/17"

[rule]
author = ["Elastic"]
description = """
Identify activity related where adversaries can add the 'hidden' flag to files to hide them from the user in an attempt
to evade detection. This behavior is often observed in attempts to conceal malicious files or maintain persistence on
a compromised system.
"""
from = "now-9m"
index = [
    "auditbeat-*",
    "endgame-*",
    "logs-auditd_manager.auditd-*",
    "logs-endpoint.events.file*",
    "logs-sentinel_one_cloud_funnel.*",
]
language = "eql"
license = "Elastic License v2"
name = "Hidden Files and Directories via Hidden Flag"
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 Hidden Files and Directories via Hidden Flag

In Unix-like systems, the 'hidden' flag can be set on files to conceal them from standard directory listings, a feature often exploited by adversaries to obscure malicious files. Attackers may use commands like `chflags` to apply this flag, making detection challenging. The detection rule targets file creation events involving `chflags`, helping identify potential misuse by monitoring for suspicious activity on Linux and macOS systems.

### Possible investigation steps

- Review the alert details to confirm the host operating system is Linux, as specified by the query field `host.os.type == "linux"`.
- Examine the process execution details to verify that the `chflags` command was used, as indicated by `process.name == "chflags"`.
- Investigate the file creation event to identify the specific file or directory that had the 'hidden' flag applied, focusing on the `event.type == "creation"` field.
- Check the user account associated with the `chflags` command execution to determine if it aligns with expected user behavior or if it might indicate unauthorized access.
- Analyze recent system logs and user activity on the affected host to identify any other suspicious behavior or anomalies that could suggest malicious intent.
- Correlate this event with other alerts or indicators of compromise on the same host to assess if this is part of a larger attack pattern or isolated incident.

### False positive analysis

- System maintenance scripts may use the chflags command to manage file visibility for legitimate purposes. Review scheduled tasks and scripts to identify benign uses and create exceptions for these processes.
- Backup and recovery operations might employ the hidden flag to protect critical files from accidental deletion. Verify backup software configurations and exclude these operations from triggering alerts.
- Development environments could use hidden files to manage version control or configuration settings. Collaborate with development teams to understand their workflows and whitelist known development-related activities.
- Security tools and utilities may use the hidden flag as part of their normal operation to protect sensitive files. Identify these tools and add them to an exception list to prevent unnecessary alerts.
- User customization scripts might apply the hidden flag to personalize the user environment. Engage with users to document these customizations and exclude them from detection rules.

### Response and remediation

- Immediately isolate the affected system from the network to prevent further malicious activity or lateral movement.
- Terminate any suspicious processes associated with `chflags` to halt any ongoing attempts to hide files.
- Conduct a thorough review of recently created files and directories on the affected system to identify and assess any hidden files for malicious content.
- Restore any critical files that may have been hidden or altered from known good backups to ensure system integrity.
- Implement file integrity monitoring to detect unauthorized changes to file attributes, including the hidden flag, on critical systems.
- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.
- Update and enhance endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats in the future."""
risk_score = 47
rule_id = "5124e65f-df97-4471-8dcb-8e3953b3ea97"
severity = "medium"
tags = [
    "Domain: Endpoint",
    "OS: Linux",
    "OS: macOS",
    "Use Case: Threat Detection",
    "Tactic: Defense Evasion",
    "Data Source: Elastic Defend",
    "Data Source: Elastic Endgame",
    "Data Source: Auditd Manager",
    "Data Source: SentinelOne",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
file where host.os.type == "linux" and event.type == "creation" and process.name == "chflags"
'''

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

[[rule.threat.technique]]
id = "T1564"
name = "Hide Artifacts"
reference = "https://attack.mitre.org/techniques/T1564/"

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

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

[rule]
description = """
Detects Node.js spawning child processes to execute JavaScript files, followed by network connections to raw IP
addresses within one minute. This indicates malicious NPM packages establishing reverse shells in supply chain attacks.
"""
id = "753afa27-34c9-41d9-b61e-373c0182bd4e"
license = "Elastic License v2"
name = "Javascript Reverse Shell via Nodejs"
os_list = ["macos"]
reference = ["https://www.reversinglabs.com/blog/malicious-npm-patch-delivers-reverse-shell"]
version = "1.0.6"

query = '''
sequence by process.entity_id with maxspan=1m
[process where event.type == "start" and event.action == "exec" and process.name == "node" and 
  process.args == "node" and process.args : "*.js" and process.args_count == 2 and
  process.parent.name == "node"]
[network where event.type == "start" and destination.domain == null and
   not destination.port == 53 and
   not cidrmatch(destination.ip, 
       "240.0.0.0/4", "233.252.0.0/24", "224.0.0.0/4", "198.19.0.0/16", "192.18.0.0/15", 
       "192.0.0.0/24", "10.0.0.0/8", "127.0.0.0/8", "169.254.0.0/16", "172.16.0.0/12", 
       "192.0.2.0/24", "192.31.196.0/24", "192.52.193.0/24", "192.168.0.0/16", "192.88.99.0/24", 
       "100.64.0.0/10", "192.175.48.0/24", "198.18.0.0/15", "198.51.100.0/24", "203.0.113.0/24",
       "::1", "FE80::/10", "FF00::/8", "0.0.0.0/32")]
'''

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

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

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1195"
name = "Supply Chain Compromise"
reference = "https://attack.mitre.org/techniques/T1195/"
[[threat.technique.subtechnique]]
id = "T1195.001"
name = "Compromise Software Dependencies and Development Tools"
reference = "https://attack.mitre.org/techniques/T1195/001/"



[threat.tactic]
id = "TA0001"
name = "Initial Access"
reference = "https://attack.mitre.org/tactics/TA0001/"
[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1059"
name = "Command and Scripting Interpreter"
reference = "https://attack.mitre.org/techniques/T1059/"
[[threat.technique.subtechnique]]
id = "T1059.007"
name = "JavaScript"
reference = "https://attack.mitre.org/techniques/T1059/007/"



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

[internal]
min_endpoint_version = "8.16.0"

[metadata]
creation_date = "2022/01/24"
integration = ["system", "windows"]
maturity = "production"
updated_date = "2026/05/04"

[rule]
author = ["Elastic"]
description = """
Identifies the modification of an account's Kerberos pre-authentication options. An adversary with
GenericWrite/GenericAll rights over the account can maliciously modify these settings to perform offline password
cracking attacks such as AS-REP roasting.
"""
from = "now-9m"
index = ["logs-system.security*", "logs-windows.forwarded*", "winlogbeat-*"]
language = "eql"
license = "Elastic License v2"
name = "Kerberos Pre-authentication Disabled for User"
note = """## Triage and analysis

### Investigating Kerberos Pre-authentication Disabled for User

Kerberos pre-authentication is an account protection against offline password cracking. When enabled, a user requesting access to a resource initiates communication with the Domain Controller (DC) by sending an Authentication Server Request (AS-REQ) message with a timestamp that is encrypted with the hash of their password. If and only if the DC is able to successfully decrypt the timestamp with the hash of the user’s password, it will then send an Authentication Server Response (AS-REP) message that contains the Ticket Granting Ticket (TGT) to the user. Part of the AS-REP message is signed with the user’s password. Microsoft's security monitoring [recommendations](https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4738) state that `'Don't Require Preauth' – Enabled` should not be enabled for user accounts because it weakens security for the account’s Kerberos authentication.

AS-REP roasting is an attack against Kerberos for user accounts that do not require pre-authentication, which means that if the target user has pre-authentication disabled, an attacker can request authentication data for it and get a TGT that can be brute-forced offline, similarly to Kerberoasting.

#### Possible investigation steps

- Identify the user account that performed the action and whether it should perform this kind of action.
- Contact the account owner and confirm whether they are aware of this activity.
- Determine if the target account is sensitive or privileged.
- Inspect the account activities for suspicious or abnormal behaviors in the alert timeframe.

### False positive analysis

- Disabling pre-authentication is a bad security practice and should not be allowed in the domain. The security team should map and monitor any potential benign true positives (B-TPs), especially if the target account is privileged.

### Response and remediation

- Initiate the incident response process based on the outcome of the triage.
- Reset the target account's password if there is any risk of TGTs having been retrieved.
- Re-enable the preauthentication option or disable the target account.
- Review the privileges assigned to the involved users to ensure that the least privilege principle is being followed.
- 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.
- 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://harmj0y.medium.com/roasting-as-reps-e6179a65216b",
    "https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4738",
    "https://github.com/atc-project/atomic-threat-coverage/blob/master/Atomic_Threat_Coverage/Logging_Policies/LP_0026_windows_audit_user_account_management.md",
]
risk_score = 47
rule_id = "e514d8cd-ed15-4011-84e2-d15147e059f1"
setup = """## Setup

Audit User Account Management must be enabled to generate the events used by this rule.
Setup instructions: https://ela.st/audit-user-account-management
"""
severity = "medium"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Credential Access",
    "Tactic: Defense Evasion",
    "Tactic: Privilege Escalation",
    "Resources: Investigation Guide",
    "Use Case: Active Directory Monitoring",
    "Data Source: Active Directory",
    "Data Source: Windows Security Event Logs",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
any where host.os.type == "windows" and event.code == "4738" and
  winlog.event_data.NewUACList == "USER_DONT_REQUIRE_PREAUTH"
'''


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

[[rule.threat.technique]]
id = "T1558"
name = "Steal or Forge Kerberos Tickets"
reference = "https://attack.mitre.org/techniques/T1558/"

[[rule.threat.technique.subtechnique]]
id = "T1558.004"
name = "AS-REP Roasting"
reference = "https://attack.mitre.org/techniques/T1558/004/"

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

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

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

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

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

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

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

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

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

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

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

[metadata]
creation_date = "2026/04/22"
integration = ["kubernetes"]
maturity = "production"
updated_date = "2026/05/15"

[rule]
author = ["Elastic"]
description = """
This rule detects an unusual volume of Kubernetes API get requests against multiple distinct Secret objects from the same client 
fingerprint (user, source IP, and user agent) within a defined lookback window. This can indicate credential access or in-cluster
reconnaissance, where a user or token is used to enumerate and retrieve sensitive data such as service account tokens, registry 
credentials, TLS material, or application configuration. Failed get requests are also included, as they may reveal RBAC boundaries, 
confirm the existence of targeted secrets, or reflect automated probing activity.
"""
from = "now-6m"
language = "esql"
license = "Elastic License v2"
name = "Kubernetes Rapid Secret GET Activity Against Multiple Objects"
note = """## Triage and analysis

### Investigating Kubernetes Rapid Secret GET Activity Against Multiple Objects

This rule surfaces clusters of `get` operations on the `secrets` API where the same identity and client path
(`user.name`, `source.ip`, `user_agent.original`) touch several different secret names within the rule lookback window.
**Allowed and denied** outcomes are included: successful reads may indicate harvesting; repeated **forbidden** or
**unauthorized** responses can still signal reconnaissance, RBAC probing, or scripted spray against secret names that
exist in the cluster.

### Investigation steps

- Inspect `Esql.outcome` for a mix of allow vs deny and whether failures cluster on sensitive namespaces.
- Map the identity to RBAC and namespace scope; review `Esql.secrets_names` and `Esql.namespaces` for high-value
  targets (tokens, registry credentials, TLS bundles, application secrets).
- Pivot on the same `source.ip` and user for follow-on API activity (exec, pod create, role changes, broad `list` on secrets).
- Validate against expected automation (CI, GitOps, backup, in-cluster controllers) before treating as malicious.

### False positives

- Startup, Helm, or controllers may legitimately touch many secrets in one window; tune by user, namespace, or IP
  allowlists when baselined.
"""
references = [
    "https://attack.mitre.org/techniques/T1552/007/",
]
risk_score = 73
rule_id = "b4c8e2a1-9f3d-4e7c-a2b1-0d5e6f7a8b9c"
severity = "high"
tags = [
    "Data Source: Kubernetes",
    "Domain: Kubernetes",
    "Use Case: Threat Detection",
    "Tactic: Credential Access",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "esql"
query = '''
from logs-kubernetes.audit_logs-* metadata _id, _index, _version
| where event.dataset == "kubernetes.audit_logs"
    and event.action == "get"
    and kubernetes.audit.objectRef.resource == "secrets"
    and source.ip is not null and user.name is not null 
    and not to_string(source.ip) in ("127.0.0.1", "::1") and 
    not user.name in ("system:kube-controller-manager", "system:kube-scheduler") and 
    not kubernetes.audit.objectRef.name like "sh.helm.release.*" and 
    not kubernetes.audit.user.username in ("system:serviceaccount:flux-system:kustomize-controller", "system:serviceaccount:flux-system:helm-controller", "system:serviceaccount:flux-system:source-controller", "system:serviceaccount:security:trivy-operator")
| stats
    Esql.unique_credentials = count_distinct(kubernetes.audit.objectRef.name),
    Esql.secrets_names = values(kubernetes.audit.objectRef.name),
    Esql.namespaces = values(kubernetes.audit.objectRef.namespace),
    Esql.outcome = values(`kubernetes.audit.annotations.authorization_k8s_io/decision`)
  by user.name, kubernetes.audit.user.username, source.ip, user_agent.original
| where Esql.unique_credentials >= 3
| KEEP user.name, kubernetes.audit.user.username, source.ip, user_agent.original, Esql.*
'''

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

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

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

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