Elastic rules: 11

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

[rule]
author = ["Elastic"]
description = """
Detects attempts to modify an Okta application. An adversary may attempt to modify, deactivate, or delete an Okta
application in order to weaken an organization's security controls or disrupt their business operations.
"""
false_positives = [
    """
    Consider adding exceptions to this rule to filter false positives if your organization's Okta applications are
    regularly modified and the behavior is expected.
    """,
]
index = ["filebeat-*", "logs-okta*"]
language = "kuery"
license = "Elastic License v2"
name = "Attempt to Modify an Okta Application"
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 Attempt to Modify an Okta Application

Okta is a widely used identity management service that helps organizations manage user access to applications securely. Adversaries may target Okta applications to alter, deactivate, or delete them, aiming to compromise security controls or disrupt operations. The detection rule monitors system events for application lifecycle updates, flagging unauthorized modification attempts to preempt potential security breaches.

### Possible investigation steps

- Review the event logs for entries with event.dataset:okta.system and event.action:application.lifecycle.update to identify the specific application and user involved in the modification attempt.
- Verify the user's role and permissions within Okta to determine if they have legitimate access to modify the application.
- Check for any recent changes in user permissions or roles that might explain the modification attempt.
- Investigate the history of the application in question to see if there have been any previous unauthorized modification attempts or related security incidents.
- Correlate the event timestamp with other security logs and alerts to identify any concurrent suspicious activities or patterns that might indicate a broader attack.

### False positive analysis

- Routine administrative updates to Okta applications by authorized personnel can trigger alerts. To manage this, create exceptions for specific user accounts or roles known to perform regular maintenance.
- Scheduled application updates or maintenance activities may be flagged. Document these activities and adjust the monitoring schedule to avoid unnecessary alerts during these periods.
- Integration or testing environments often undergo frequent changes. Exclude these environments from monitoring or adjust the rule to focus on production environments only.
- Automated scripts or tools used for application management might generate false positives. Identify these tools and whitelist their actions to prevent unnecessary alerts.
- Changes made by third-party vendors or partners with legitimate access can be mistaken for unauthorized attempts. Ensure these entities are properly documented and their actions are accounted for in the monitoring setup.

### Response and remediation

- Immediately isolate the affected Okta application to prevent further unauthorized modifications. This can be done by temporarily disabling the application or restricting access to it.
- Review and revoke any unauthorized changes made to the application settings. Restore the application to its last known good configuration using backup or audit logs.
- Conduct a thorough audit of recent access logs to identify any unauthorized users or suspicious activities related to the application lifecycle updates.
- Escalate the incident to the security operations team for further investigation and to determine if there are any broader security implications or related incidents.
- Implement additional monitoring on the affected application and similar applications to detect any further unauthorized modification attempts.
- Review and update access controls and permissions for Okta applications to ensure that only authorized personnel have the ability to modify application settings.
- Communicate with relevant stakeholders, including IT and security teams, to inform them of the incident and any changes made to the application settings as part of the remediation process.

## Setup

The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
references = [
    "https://help.okta.com/en/prod/Content/Topics/Apps/Apps_Apps.htm",
    "https://developer.okta.com/docs/reference/api/system-log/",
    "https://developer.okta.com/docs/reference/api/event-types/",
    "https://www.elastic.co/security-labs/testing-okta-visibility-and-detection-dorothy",
    "https://www.elastic.co/security-labs/monitoring-okta-threats-with-elastic-security",
    "https://www.elastic.co/security-labs/starter-guide-to-understanding-okta",
]
risk_score = 21
rule_id = "c74fd275-ab2c-4d49-8890-e2943fa65c09"
severity = "low"
tags = [
    "Use Case: Identity and Access Audit",
    "Data Source: Okta",
    "Tactic: Impact",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:okta.system and event.action:application.lifecycle.update
'''


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

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

[metadata]
creation_date = "2024/05/02"
integration = ["aws_bedrock"]
maturity = "production"
updated_date = "2025/09/25"

[rule]
author = ["Elastic"]
description = """
Identifies multiple violations of AWS Bedrock guardrails by the same user in the same account over a session. Multiple
violations implies that a user may be intentionally attempting to cirvumvent security controls, access sensitive
information, or possibly exploit a vulnerability in the system.
"""
false_positives = ["Legitimate misunderstanding by users or overly strict policies"]
from = "now-60m"
interval = "10m"
language = "esql"
license = "Elastic License v2"
name = "AWS Bedrock Guardrails Detected Multiple Violations by a Single User Over a Session"
note = """## Triage and analysis

### Investigating AWS Bedrock Guardrails Detected Multiple Violations by a Single User Over a Session

Amazon Bedrock Guardrail is a set of features within Amazon Bedrock designed to help businesses apply robust safety and privacy controls to their generative AI applications.

It enables users to set guidelines and filters that manage content quality, relevancy, and adherence to responsible AI practices.

Through Guardrail, organizations can define "denied topics" to prevent the model from generating content on specific, undesired subjects,
and they can establish thresholds for harmful content categories, including hate speech, violence, or offensive language.

#### Possible investigation steps

- Identify the user account that caused multiple policy violations over a session and whether it should perform this kind of action.
- Investigate the user activity that might indicate a potential brute force attack.
- Investigate other alerts associated with the user account during the past 48 hours.
- Consider the time of day. If the user is a human (not a program or script), did the activity take place during a normal time of day?
- Examine the account's prompts and responses in the last 24 hours.
- If you suspect the account has been compromised, scope potentially compromised assets by tracking Amazon Bedrock model access, prompts generated, and responses to the prompts by the account in the last 24 hours.

### False positive analysis

- Verify the user account that caused multiple policy violations by a single user over session, is not testing any new model deployments or updated compliance policies in Amazon Bedrock guardrails.

### 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.
    - Identify if the attacker is moving laterally and compromising other Amazon Bedrock Services.
    - Identify any regulatory or legal ramifications related to this activity.
- Review the permissions assigned to the implicated user group or role behind these requests to ensure they are authorized and expected to access bedrock and ensure that the least privilege principle is being followed.
- 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.aws.amazon.com/bedrock/latest/userguide/guardrails-components.html",
    "https://atlas.mitre.org/techniques/AML.T0051",
    "https://atlas.mitre.org/techniques/AML.T0054",
    "https://www.elastic.co/security-labs/elastic-advances-llm-security",
]
risk_score = 47
rule_id = "0cd2f3e6-41da-40e6-b28b-466f688f00a6"
setup = """## Setup

This rule requires that guardrails are configured in AWS Bedrock. For more information, see the AWS Bedrock documentation:

https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-create.html
"""
severity = "medium"
tags = [
    "Domain: LLM",
    "Data Source: AWS Bedrock",
    "Data Source: AWS S3",
    "Resources: Investigation Guide",
    "Use Case: Policy Violation",
    "Mitre Atlas: T0051",
    "Mitre Atlas: T0054",
]
timestamp_override = "event.ingested"
type = "esql"

query = '''
from logs-aws_bedrock.invocation-*

// Filter for compliance violations detected
| where gen_ai.compliance.violation_detected

// keep relevant ECS + model fields
| keep
  user.id,
  gen_ai.request.model.id,
  cloud.account.id

// count violations by user, model, and account
| stats
    Esql.ml_violations_count = count(*)
  by
    user.id,
    gen_ai.request.model.id,
    cloud.account.id

// Filter for repeated violations
| where Esql.ml_violations_count > 1

// sort descending by violation volume
| sort Esql.ml_violations_count desc
'''

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

[rule]
author = ["Elastic"]
description = """
This rule detects the use of system search utilities like grep and find to search for AWS credentials inside a
container. Unauthorized access to these sensitive files could lead to further compromise of the container environment or
facilitate a container breakout to the underlying cloud environment.
"""
from = "now-9m"
index = ["logs-endpoint.events.process*"]
language = "eql"
license = "Elastic License v2"
name = "AWS Credentials Searched For Inside A Container"
references = ["https://sysdig.com/blog/threat-detection-aws-cloud-containers/"]
risk_score = 73
rule_id = "5749282b-7524-4c9d-af9a-e2b3e814e5d4"
setup = """## Setup

This rule requires data coming in from Elastic Defend.

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

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

#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
- Go to the Kibana home page and click "Add integrations".
- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
- Click "Add Elastic Defend".
- Configure the integration name and optionally add a description.
- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).
- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead.

For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
- Click "Save and Continue".
- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts.
For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
"""
severity = "high"
tags = [
    "Domain: Container",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Credential Access",
    "Data Source: Elastic Defend",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and
process.entry_leader.entry_meta.type == "container" and
process.name in ("grep", "egrep", "fgrep", "find", "locate", "mlocate", "cat", "sed", "awk") and
process.command_line like~ (
  "*aws_access_key_id*", "*aws_secret_access_key*", "*aws_session_token*", "*accesskeyid*", "*secretaccesskey*",
  "*access_key*", "*.aws/credentials*"
)
'''
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 AWS Credentials Searched For Inside A Container

Containers often house applications that interact with AWS services, necessitating the storage of AWS credentials. Adversaries may exploit this by using search utilities to locate these credentials, potentially leading to unauthorized access. The detection rule identifies suspicious use of search tools within containers, flagging attempts to locate AWS credentials by monitoring specific process names and arguments, thus helping to prevent credential theft and subsequent attacks.

### Possible investigation steps

- Review the process details to identify the specific search utility used (e.g., grep, find) and the arguments passed, focusing on those related to AWS credentials such as aws_access_key_id or aws_secret_access_key.
- Check the user context under which the suspicious process was executed to assess whether it aligns with expected behavior for that user or role within the container.
- Investigate the source of the container image to ensure it is from a trusted repository and has not been tampered with, which could indicate a supply chain compromise.
- Analyze recent activity logs for the container to identify any other suspicious behavior or anomalies that might correlate with the search for AWS credentials, such as unexpected network connections or file modifications.
- Review access logs for AWS services to detect any unauthorized or unusual access patterns that might suggest the use of compromised credentials.

### False positive analysis

- Routine maintenance scripts or automated processes may use search utilities to verify the presence of AWS credentials for legitimate configuration checks. To handle this, identify and whitelist these specific scripts or processes by their unique identifiers or execution paths.
- Developers or system administrators might manually search for AWS credentials during debugging or configuration tasks. Implement a policy to log and review these activities, and consider excluding known user accounts or roles from triggering alerts during specific time windows or in designated environments.
- Security audits or compliance checks often involve searching for sensitive information, including AWS credentials, to ensure proper security measures are in place. Coordinate with audit teams to schedule these activities and temporarily suppress alerts during these periods, or exclude specific audit tools from detection.
- Continuous integration and deployment (CI/CD) pipelines might include steps that search for AWS credentials to validate environment configurations. Identify these pipelines and exclude their associated processes or container environments from triggering alerts, ensuring that only authorized CI/CD tools are used.

### Response and remediation

- Immediately isolate the affected container to prevent further unauthorized access or data exfiltration. This can be done by stopping the container or disconnecting it from the network.
- Revoke any AWS credentials that were potentially exposed or accessed. This includes rotating keys and updating any services or applications that rely on these credentials.
- Conduct a thorough review of the container's file system to identify any unauthorized changes or additional malicious files that may have been introduced.
- Implement stricter access controls and monitoring on AWS credentials within containers, ensuring they are stored securely and accessed only by authorized processes.
- Escalate the incident to the cloud security team to assess the potential impact on the broader cloud environment and determine if further investigation or response is needed.
- Enhance logging and monitoring for similar activities across other containers and cloud environments to detect and respond to future attempts promptly.
- Review and update container security policies to include best practices for credential management and access control, reducing the risk of similar incidents."""

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

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

[[rule.threat.technique]]
id = "T1005"
name = "Data from Local System"
reference = "https://attack.mitre.org/techniques/T1005/"

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

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

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

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

[rule]
description = """
Detects the execution of the screen binary to execute a command or commands via a shell. Threat actors have used this
technique via interactive sessions to execute commands on the host and avoid standard detections.
"""
id = "232c03d2-ff5d-4ec5-88b5-5926dc491e91"
license = "Elastic License v2"
name = "Command Execution via Screen Session"
os_list = ["macos"]
version = "1.0.6"

query = '''
process where event.type == "start" and event.action == "exec" and 
 process.name == "screen" and
 process.args in ("/bin/bash", "/usr/bin/bash", "/bin/sh", "/usr/bin/sh", "/bin/zsh", "/usr/bin/zsh", "bash", "sh", "zsh") and
 process.args == "-c" and
 not process.Ext.effective_parent.executable == "/Applications/kitty.app/Contents/MacOS/kitty"
'''

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



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

[internal]
min_endpoint_version = "8.7.0"

[rule]
description = """
Identifies the load of a library from a WebDav Share. Adversaries may abuse this method to evade dropping malicious
files to victim file system.
"""
id = "7ae54ce7-e1c9-4cbc-8e59-0350e80e9530"
license = "Elastic License v2"
name = "DLL Loaded from WebDav Share"
os_list = ["windows"]
version = "1.0.9"

query = '''
library where dll.path : "\\Device\\Mup\\*\\DavWWWRoot\\*" and 
 process.executable != null and not startswith~(dll.name, process.name) and 
 not process.executable : "\\Device\\Mup\\*\\DavWWWRoot\\*" and 
 not dll.path : "\\Device\\Mup\\*.sharepoint.com@SSL\\DavWWWRoot\\*"
'''

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

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

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1204"
name = "User Execution"
reference = "https://attack.mitre.org/techniques/T1204/"
[[threat.technique.subtechnique]]
id = "T1204.002"
name = "Malicious File"
reference = "https://attack.mitre.org/techniques/T1204/002/"



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

[internal]
min_endpoint_version = "8.4.0"

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

[rule]
author = ["Elastic"]
description = """
Identifies concurrent azure signin events for the same user and from multiple sources, and where one of the
authentication event has some suspicious properties often associated to DeviceCode and OAuth phishing. Adversaries may
steal Refresh Tokens (RTs) via phishing to bypass multi-factor authentication (MFA) and gain unauthorized access to
Azure resources.
"""
false_positives = [
    """
    Users authenticating from multiple devices and using the deviceCode protocol or the Visual Studio Code client.
    """,
]
from = "now-60m"
language = "esql"
license = "Elastic License v2"
name = "Entra ID Concurrent Sign-in with Suspicious Properties"
note = """## Triage and analysis

### Investigating Entra ID Concurrent Sign-in with Suspicious Properties

### Possible investigation steps

- Review the sign-in logs to assess the context and reputation of the source.ip address.
- Investigate the user account associated with the successful sign-in to determine if the activity aligns with expected behavior or if it appears suspicious.
- Check for any recent changes or anomalies in the user's account settings or permissions that could indicate compromise.
- Review the history of sign-ins for the user to identify any patterns or unusual access times that could suggest unauthorized access.
- Assess the device from which the sign-in was attempted to ensure it is a recognized and authorized device for the user.

### Response and remediation

- Immediately revoke the compromised Primary Refresh Tokens (PRTs) to prevent further unauthorized access. This can be done through the Azure portal by navigating to the user's account and invalidating all active sessions.
- Enforce a password reset for the affected user accounts to ensure that any credentials potentially compromised during the attack are no longer valid.
- Implement additional Conditional Access policies that require device compliance checks and restrict access to trusted locations or devices only, to mitigate the risk of future PRT abuse.
- Conduct a thorough review of the affected accounts' recent activity logs to identify any unauthorized actions or data access that may have occurred during the compromise.
- Escalate the incident to the security operations team for further investigation and to determine if there are any broader implications or additional compromised accounts.
- Enhance monitoring by configuring alerts for unusual sign-in patterns or device code authentication attempts from unexpected locations or devices, to improve early detection of similar threats.
- Coordinate with the incident response team to perform a post-incident analysis and update the incident response plan with lessons learned from this event."""
references = [
    "https://learn.microsoft.com/en-us/entra/identity/",
    "https://learn.microsoft.com/en-us/entra/identity/monitoring-health/concept-sign-ins",
    "https://docs.microsoft.com/en-us/azure/active-directory/reports-monitoring/reference-azure-monitor-sign-ins-log-schema",
    "https://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/",
]
risk_score = 73
rule_id = "e3bd85e9-7aff-46eb-b60e-20dfc9020d98"
setup = """#### Required Azure Entra Sign-In Logs
This rule requires the Azure logs integration be enabled and configured to collect all logs, including sign-in logs from Entra. In Entra, sign-in logs must be enabled and streaming to the Event Hub used for the Azure logs integration.
"""
severity = "high"
tags = [
    "Domain: Cloud",
    "Domain: SaaS",
    "Data Source: Azure",
    "Data Source: Entra ID",
    "Data Source: Entra ID Sign-in",
    "Use Case: Identity and Access Audit",
    "Use Case: Threat Detection",
    "Tactic: Credential Access",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "esql"

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

// Scheduled to run every hour, reviewing events from past hour
| where
  @timestamp > now() - 1 hours
  and data_stream.dataset == "azure.signinlogs"
  and source.ip is not null
  and azure.signinlogs.identity is not null
  and to_lower(event.outcome) == "success"

// keep relevant raw fields
| keep
  @timestamp,
  azure.signinlogs.identity,
  source.ip,
  azure.signinlogs.properties.authentication_requirement,
  azure.signinlogs.properties.app_id,
  azure.signinlogs.properties.resource_display_name,
  azure.signinlogs.properties.authentication_protocol,
  azure.signinlogs.properties.app_display_name

// case classifications for identity usage
| eval
      Esql.azure_signinlogs_properties_authentication_device_code_case = case(
      azure.signinlogs.properties.authentication_protocol == "deviceCode"
      and azure.signinlogs.properties.authentication_requirement != "multiFactorAuthentication",
      azure.signinlogs.identity,
      null),

    Esql.azure_signinlogs_auth_visual_studio_case = case(
      azure.signinlogs.properties.app_id == "aebc6443-996d-45c2-90f0-388ff96faa56"
      and azure.signinlogs.properties.resource_display_name == "Microsoft Graph",
      azure.signinlogs.identity,
      null),

    Esql.azure_signinlogs_auth_other_case = case(
      azure.signinlogs.properties.authentication_protocol != "deviceCode"
      and azure.signinlogs.properties.app_id != "aebc6443-996d-45c2-90f0-388ff96faa56",
      azure.signinlogs.identity,
      null)

// Aggregate metrics by user identity
| stats
    Esql.event_count = count(*),
    Esql.azure_signinlogs_properties_authentication_device_code_case_count_distinct = count_distinct(Esql.azure_signinlogs_properties_authentication_device_code_case),
    Esql.azure_signinlogs_properties_auth_visual_studio_count_distinct = count_distinct(Esql.azure_signinlogs_auth_visual_studio_case),
    Esql.azure_signinlogs_properties_auth_other_count_distinct = count_distinct(Esql.azure_signinlogs_auth_other_case),
    Esql.azure_signinlogs_properties_source_ip_count_distinct = count_distinct(source.ip),
    Esql.azure_signinlogs_properties_source_ip_values = values(source.ip),
    Esql.azure_signinlogs_properties_client_app_values = values(azure.signinlogs.properties.app_display_name),
    Esql.azure_signinlogs_properties_resource_display_name_values = values(azure.signinlogs.properties.resource_display_name),
    Esql.azure_signinlogs_properties_auth_requirement_values = values(azure.signinlogs.properties.authentication_requirement)
  by azure.signinlogs.identity

// Detect multiple unique IPs for one user with signs of deviceCode or VSC OAuth usage
| where
  Esql.azure_signinlogs_properties_source_ip_count_distinct >= 2
  and (
    Esql.azure_signinlogs_properties_authentication_device_code_case_count_distinct > 0
    or Esql.azure_signinlogs_properties_auth_visual_studio_count_distinct > 0
  )
'''


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

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

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

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

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

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

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

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

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

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

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

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

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

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

[rule]
author = ["Elastic"]
description = """
Identifies a Logging sink deletion in Google Cloud Platform (GCP). Every time a log entry arrives, Logging compares the
log entry to the sinks in that resource. Each sink whose filter matches the log entry writes a copy of the log entry to
the sink's export destination. An adversary may delete a Logging sink to evade detection.
"""
false_positives = [
    """
    Logging sink deletions may be done by a system or network administrator. Verify whether the user email, resource
    name, and/or hostname should be making changes in your environment. Logging sink deletions by unfamiliar users or
    hosts should be investigated. If known behavior is causing false positives, it can be exempted from the rule.
    """,
]
index = ["filebeat-*", "logs-gcp*"]
language = "kuery"
license = "Elastic License v2"
name = "GCP Logging Sink Deletion"
note = """## Triage and analysis

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

### Investigating GCP Logging Sink Deletion

In GCP, logging sinks are crucial for exporting log entries to designated destinations for analysis and storage. Adversaries may delete these sinks to prevent logs from being exported, thereby evading detection. The detection rule identifies successful deletion events by monitoring specific audit logs, helping security teams quickly respond to potential defense evasion tactics.

### Possible investigation steps

- Review the audit logs for the specific event.action: google.logging.v*.ConfigServiceV*.DeleteSink to identify the user or service account responsible for the deletion.
- Check the event.dataset:gcp.audit logs for any preceding or subsequent suspicious activities by the same user or service account, which might indicate a pattern of malicious behavior.
- Investigate the event.outcome:success to confirm the deletion was successful and determine the impact on log monitoring and export capabilities.
- Assess the context and timing of the deletion event to see if it coincides with other security alerts or incidents, which might suggest a coordinated attack.
- Verify the permissions and roles assigned to the user or service account involved in the deletion to ensure they align with the principle of least privilege and identify any potential misconfigurations.

### False positive analysis

- Routine maintenance or configuration changes by authorized personnel can trigger false positives. To manage this, create exceptions for known maintenance windows or specific user accounts responsible for these tasks.
- Automated scripts or tools used for managing logging configurations might inadvertently delete sinks as part of their operation. Identify these scripts and exclude their actions from triggering alerts by using specific identifiers or service accounts.
- Changes in project ownership or restructuring within the organization can lead to legitimate sink deletions. Document these organizational changes and adjust the monitoring rules to account for them, ensuring that alerts are only generated for unexpected deletions.
- Test environments often undergo frequent changes, including sink deletions, which can result in false positives. Implement separate monitoring rules or exceptions for test environments to reduce noise in alerting.

### Response and remediation

- Immediately revoke access to the affected GCP project for any suspicious or unauthorized users identified in the audit logs to prevent further malicious activity.
- Restore the deleted logging sink by recreating it with the original configuration to ensure that log entries are once again exported to the designated destination.
- Conduct a thorough review of recent log entries and audit logs to identify any other unauthorized changes or suspicious activities that may have occurred around the time of the sink deletion.
- Implement additional monitoring and alerting for any future attempts to delete logging sinks, focusing on the specific event action and outcome fields used in the detection query.
- Escalate the incident to the security operations team for further investigation and to determine if the sink deletion is part of a larger attack campaign.
- Review and update access controls and permissions for logging sink management to ensure that only authorized personnel have the ability to modify or delete sinks.
- Consider enabling additional security features such as VPC Service Controls or Organization Policy constraints to provide an extra layer of protection against unauthorized modifications to logging configurations.

## Setup

The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
references = ["https://cloud.google.com/logging/docs/export"]
risk_score = 47
rule_id = "51859fa0-d86b-4214-bf48-ebb30ed91305"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Data Source: GCP",
    "Data Source: Google Cloud Platform",
    "Use Case: Log Auditing",
    "Tactic: Defense Evasion",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:gcp.audit and event.action:google.logging.v*.ConfigServiceV*.DeleteSink 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.008"
name = "Disable or Modify Cloud Logs"
reference = "https://attack.mitre.org/techniques/T1562/008/"

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

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

[rule]
author = ["Elastic"]
description = """
Identifies the creation of a subscription in Google Cloud Platform (GCP). In GCP, the publisher-subscriber relationship
(Pub/Sub) is an asynchronous messaging service that decouples event-producing and event-processing services. A
subscription is a named resource representing the stream of messages to be delivered to the subscribing application.
"""
false_positives = [
    """
    Subscription creations may be done by a system or network administrator. Verify whether the user email, resource
    name, and/or hostname should be making changes in your environment. Subscription creations by unfamiliar users or
    hosts should be investigated. If known behavior is causing false positives, it can be exempted from the rule.
    """,
]
index = ["filebeat-*", "logs-gcp*"]
language = "kuery"
license = "Elastic License v2"
name = "GCP Pub/Sub Subscription Creation"
note = """## Triage and analysis

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

### Investigating GCP Pub/Sub Subscription Creation

Google Cloud Pub/Sub is a messaging service that enables asynchronous communication between applications by decoupling event producers and consumers. Adversaries might exploit this by creating unauthorized subscriptions to intercept or exfiltrate sensitive data streams. The detection rule monitors audit logs for successful subscription creation events, helping identify potential misuse by flagging unexpected or suspicious activity.

### Possible investigation steps

- Review the audit log entry associated with the alert to identify the user or service account responsible for the subscription creation by examining the `event.dataset` and `event.action` fields.
- Verify the legitimacy of the subscription by checking the associated project and topic details to ensure they align with expected configurations and business needs.
- Investigate the history of the user or service account involved in the subscription creation to identify any unusual or unauthorized activities, focusing on recent changes or access patterns.
- Assess the permissions and roles assigned to the user or service account to determine if they have the necessary privileges for subscription creation and whether these permissions are appropriate.
- Consult with relevant stakeholders or application owners to confirm whether the subscription creation was authorized and necessary for operational purposes.

### False positive analysis

- Routine subscription creation by automated deployment tools or scripts can trigger false positives. Identify and whitelist these tools by excluding their service accounts from the detection rule.
- Development and testing environments often create and delete subscriptions frequently. Exclude these environments by filtering out specific project IDs associated with non-production use.
- Scheduled maintenance or updates might involve creating new subscriptions temporarily. Coordinate with the operations team to understand regular maintenance schedules and adjust the rule to ignore these activities during known maintenance windows.
- Internal monitoring or logging services that create subscriptions for legitimate data collection purposes can be excluded by identifying their specific patterns or naming conventions and adding them to an exception list.

### Response and remediation

- Immediately review the audit logs to confirm the unauthorized subscription creation and identify the source, including the user or service account responsible for the action.
- Revoke access for the identified user or service account to prevent further unauthorized actions. Ensure that the principle of least privilege is enforced.
- Delete the unauthorized subscription to stop any potential data interception or exfiltration.
- Conduct a thorough review of all existing subscriptions to ensure no other unauthorized subscriptions exist.
- Notify the security team and relevant stakeholders about the incident for awareness and further investigation.
- Implement additional monitoring and alerting for subscription creation events to detect similar activities in the future.
- If applicable, report the incident to Google Cloud support for further assistance and to understand if there are any broader implications or vulnerabilities.

## Setup

The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
references = ["https://cloud.google.com/pubsub/docs/overview"]
risk_score = 21
rule_id = "d62b64a8-a7c9-43e5-aee3-15a725a794e7"
severity = "low"
tags = [
    "Domain: Cloud",
    "Data Source: GCP",
    "Data Source: Google Cloud Platform",
    "Use Case: Log Auditing",
    "Tactic: Collection",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:gcp.audit and event.action:google.pubsub.v*.Subscriber.CreateSubscription and event.outcome:success
'''


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

[[rule.threat.technique]]
id = "T1119"
name = "Automated Collection"
reference = "https://attack.mitre.org/techniques/T1119/"

[[rule.threat.technique]]
id = "T1530"
name = "Data from Cloud Storage"
reference = "https://attack.mitre.org/techniques/T1530/"

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

[metadata]
creation_date = "2026/07/15"
integration = ["gcp"]
maturity = "production"
updated_date = "2026/07/15"

[rule]
author = ["Elastic"]
description = """
Detects successful GKE pod exec sessions where the executed command references high-value host or in-cluster paths:
mounted service account or platform tokens, kubelet and control-plane configuration areas, host identity stores, root
or home credential directories, common private-key and keystore extensions, process environment dumps, and configuration
filenames suggestive of embedded secrets. Attackers with pods/exec often use these one-liners to steal credentials
before lateral movement or privilege escalation. A narrow exclusion ignores benign resolv.conf reads. GKE records the
command in gcp.audit.labels.command.gke.io/command when an explicit command is passed to exec.
"""
false_positives = [
    """
    Break-glass debugging or vendor diagnostics may cat credential-adjacent paths. Baseline approved operators and
    automation identities, then expand client.user.email exclusions as needed.
    """,
]
from = "now-6m"
index = ["logs-gcp.audit-*"]
language = "kuery"
license = "Elastic License v2"
name = "GKE Pod Exec Sensitive File or Credential Path Access"
note = """## Triage and analysis

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

This alert fires when a successful pods/exec API call includes a command matching sensitive path or filename
patterns. Review `gcp.audit.labels.command.gke.io/command` for the reconstructed command string.

### Possible investigation steps

- Identify the actor (`client.user.email`), source IP, and user agent for the exec caller.
- Map `gcp.audit.resource_name` (namespace/pod) to a workload owner, image, and change history.
- Correlate adjacent activity from the same identity: secret reads, TokenRequest, RBAC writes, or additional execs.
- If host-level paths appear, determine whether the workload is privileged, uses hostPath, or runs on break-glass nodes.

### False positive analysis

- Diagnostic images and vendor agents sometimes read kubeconfig-like or credential paths; baseline stable automation.
- Training containers that deliberately demonstrate passwd reads can trigger; scope exceptions to those namespaces.

### Response and remediation

- If malicious, end the exec session, isolate the pod or node, rotate credentials that could have been read, and
  tighten pods/exec RBAC and admission controls.
"""
setup = "The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule."
references = [
    "https://stratus-red-team.cloud/attack-techniques/kubernetes/k8s.credential-access.steal-serviceaccount-token/",
]
risk_score = 73
rule_id = "0fc705f5-544e-4786-8acc-c73cd74e77cf"
severity = "high"
tags = [
    "Domain: Cloud",
    "Domain: Kubernetes",
    "Data Source: GCP",
    "Data Source: GCP Audit Logs",
    "Data Source: Google Cloud Platform",
    "Use Case: Threat Detection",
    "Tactic: Credential Access",
    "Tactic: Execution",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:gcp.audit and service.name:"k8s.io" and event.outcome:success and
event.type:start and
event.action:("io.k8s.core.v1.pods.exec.create" or "io.k8s.core.v1.pods.exec.get") and
gcp.audit.labels.command.gke.io/command:(
  (
    *.jks* or *.key* or *.keystore* or *.p12* or *.pem* or
    */etc/kubernetes/* or */etc/passwd* or */etc/shadow* or */etc/sudoers* or
    */home/*/.aws* or */home/*/.azure* or */home/*/.config/gcloud* or */home/*/.kube* or */home/*/.ssh* or
    */proc/*/environ* or
    */root/.aws* or */root/.azure* or */root/.config/gcloud* or */root/.kube* or */root/.ssh* or
    */var/lib/kubelet/* or */var/run/secrets/* or
    */etc/*.conf* and (*credential* or *key* or *password* or *secret* or *token*)
  ) and not */etc/resolv.conf*
)
'''

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

[rule.investigation_fields]
field_names = [
    "@timestamp",
    "client.user.email",
    "source.ip",
    "user_agent.original",
    "event.action",
    "event.outcome",
    "event.type",
    "gcp.audit.labels.command.gke.io/command",
    "gcp.audit.resource_name",
    "data_stream.namespace",
]

[metadata]
creation_date = "2025/12/01"
integration = ["aws", "gcp", "azure", "kubernetes"]
maturity = "production"
updated_date = "2026/04/10"

[rule]
author = ["Elastic"]
description = """
This rule detects authenticated sessions accessing secret stores across multiple environments from the same source
address within a short period of time, including cloud providers (AWS, GCP, Azure) and Kubernetes clusters.
Adversaries with access to compromised credentials or session tokens may attempt to retrieve secrets from services such
as AWS Secrets Manager, Google Secret Manager, Azure Key Vault, or Kubernetes Secrets in rapid succession to expand
their access or exfiltrate sensitive information.
"""
from = "now-9m"
interval = "5m"
language = "esql"
license = "Elastic License v2"
name = "Multiple Cloud Secrets Accessed by Source Address"
note = """## Triage and analysis

### Multiple Cloud Secrets Accessed by Source Address

This alert identifies a single source IP address accessing secret-management APIs across **multiple cloud providers**
(e.g., AWS Secrets Manager, Google Secret Manager, Azure Key Vault) within a short timeframe.
This behavior is strongly associated with **credential theft, session hijacking, or token replay**, where an adversary
uses stolen authenticated sessions to harvest secrets across cloud environments.

Unexpected cross-cloud secret retrieval is uncommon and typically indicates automation misuse or malicious activity.

### Possible investigation steps

- Validate the principal
  - Identify the user, service account, workload identity, or application making the requests.
  - Confirm whether this identity is expected to operate across more than one cloud provider.
- Review related activity
  - Look for additional alerts involving the same identity, source IP, or token over the last 24–48 hours.
  - Identify whether the source IP has been observed performing unusual authentication, privilege escalation,
    or reconnaissance.
- Check application or service context
  - Determine whether any workload legitimately pulls secrets from multiple cloud providers.
  - Review deployment pipelines or integration layers that might legitimately bridge AWS, Azure, and GCP.
- Analyze user agent and invocation patterns
  - Compare `user_agent.original` or equivalent fields against expected SDKs or automation tools.
  - Suspicious indicators include CLI tools, unknown libraries, browser user agents, or custom scripts.
- Inspect IP reputation and origin
  - Determine whether the source IP corresponds to a managed workload (EC2, GCE, Azure VM) or an unexpected host.
  - Validate that the associated instance or host is under your control and behaving normally.
- Review IAM permissions and accessed secrets
  - Check the policies attached to the identity.
  - Verify whether the accessed secrets are sensitive, unused, or unrelated to the identity’s purpose.
- Assess potential compromise scope
  - If compromise is suspected, enumerate other assets accessed by the same identity in the last 24 hours.
  - Look for lateral movement, privilege escalation, or abnormal API usage.
- Review Kubernetes activity
  - Identify the Kubernetes user, service account, or workload performing the secret access.
  - Determine whether the access originated from a pod, node, or external client.
  - Validate whether the identity is expected to access secrets in the affected namespaces.
  - Investigate whether the activity corresponds to application behavior or manual/API access.

### False positive analysis

- Validate whether the source IP is associated with a legitimate multi-cloud orchestration tool, automation pipeline,
  or shared CI/CD system.
- Confirm that the identity is authorized to access secrets across multiple cloud services.
- If activity is expected, consider adding exceptions that pair account identity, source IP, and expected user agent
  to reduce noise.
- Determine whether the source IP is associated with Kubernetes nodes, controllers, or internal workloads
  that legitimately retrieve secrets alongside cloud provider integrations.

### Response and remediation

- Initiate incident response** if the activity is unauthorized or suspicious.
- Restrict or disable** the affected credentials or service accounts.
- Rotate all accessed secrets** and review other secrets the identity can access.
- Analyze systems** that may have leaked credentials, such as compromised hosts or exposed tokens.
- Harden identity security:
  - Enforce MFA for users where applicable.
  - Reduce permissions to least privilege.
  - Review trust relationships, workload identities, and cross-cloud integrations.
- Search for persistence mechanisms** such as newly created keys, roles, or service accounts.
- If Kubernetes access is involved:
  - Rotate Kubernetes secrets and service account tokens.
  - Review RBAC permissions and restrict secret access to least privilege.
  - Inspect affected pods or nodes for compromise.
- Improve monitoring and audit visibility** by ensuring logging is enabled across all cloud environments.
- Determine root cause** (phishing, malware, token replay, exposed credential, etc.) and close the vector to prevent recurrence.
"""
references = [
    "https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_GetSecretValue.html",
    "https://docs.cloud.google.com/secret-manager/docs/samples/secretmanager-access-secret-version",
    "https://learn.microsoft.com/en-us/azure/key-vault/secrets/about-secrets",
    "https://www.wiz.io/blog/shai-hulud-2-0-ongoing-supply-chain-attack",
]
risk_score = 73
rule_id = "472b4944-d810-43cf-83dc-7d080ae1b8dd"
setup = """
This multi-datasource rule relies on additional configurations from each hyperscaler.

- GCP Audit: [Enable DATA_READ for the Secret Manager API service](https://docs.cloud.google.com/logging/docs/audit/configure-data-access)
- Azure: [Enable Diagnostic Logging for the Key Vault Service](https://learn.microsoft.com/en-us/azure/key-vault/general/howto-logging?tabs=azure-cli)
- AWS: Secrets Manager read access is automatically logged by CloudTrail.
"""
severity = "high"
tags = [
    "Domain: Cloud",
    "Domain: IAM",
    "Domain: Storage",
    "Data Source: AWS",
    "Data Source: Amazon Web Services",
    "Data Source: AWS Secrets Manager",
    "Data Source: Azure",
    "Data Source: Azure Activity Logs",
    "Data Source: GCP",
    "Data Source: Google Cloud Platform",
    "Data Source: Kubernetes",
    "Tactic: Credential Access",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "esql"

query = '''
FROM logs-azure.platformlogs-*, logs-aws.cloudtrail-*, logs-gcp.audit-*, logs-kubernetes.audit_logs-* METADATA _id, _version, _index 
| WHERE 
  ( 
    /* AWS Secrets Manager */ 
    (data_stream.dataset == "aws.cloudtrail" AND event.action == "GetSecretValue") OR 
    
    // Azure Key Vault (platform logs)
    (data_stream.dataset == "azure.platformlogs" AND event.action IN ("SecretGet", "KeyGet")) or 
    
    /* Google Secret Manager */ 
    (data_stream.dataset IN ("googlecloud.audit", "gcp.audit") AND 
     event.action IN ("google.cloud.secretmanager.v1.SecretManagerService.AccessSecretVersion", "google.cloud.secretmanager.v1.SecretManagerService.GetSecretRequest")) OR 

    /* Kubernetes Secrets */
    (data_stream.dataset == "kubernetes.audit_logs" AND kubernetes.audit.objectRef.resource == "secrets" AND kubernetes.audit.verb IN ("get", "list"))

   ) AND source.ip IS NOT NULL

// Cloud vendor label based on dataset
| EVAL Esql.cloud_vendor = CASE(
    data_stream.dataset == "aws.cloudtrail", "aws",
    data_stream.dataset == "azure.platformlogs", "azure",
    data_stream.dataset IN ("googlecloud.audit","gcp.audit"), "gcp",
    data_stream.dataset == "kubernetes.audit_logs", "k8s",
    "unknown"
  )
// Vendor+tenant label, e.g. aws:123456789012, azure:tenant, gcp:project
| EVAL Esql.tenant_label = CASE(
    Esql.cloud_vendor == "aws", CONCAT("aws:", cloud.account.id),
    Esql.cloud_vendor == "azure", CONCAT("azure:", cloud.account.id),
    Esql.cloud_vendor == "gcp", CONCAT("gcp:", cloud.account.id),
    Esql.cloud_vendor == "k8s", CONCAT("k8s:", orchestrator.cluster.name),
    "unknown"
  )
| WHERE Esql.cloud_vendor != "unknown"
| STATS
    // Core counts
    Esql.events_count = COUNT(*),
    Esql.vendor_count_distinct = COUNT_DISTINCT(Esql.cloud_vendor),
    // Action & data source context
    Esql.event_action_values = VALUES(event.action),
    Esql.data_source_values = VALUES(data_stream.dataset),
    // Cloud vendor + tenant context
    Esql.cloud_vendor_values = VALUES(Esql.cloud_vendor),
    Esql.tenant_label_values = VALUES(Esql.tenant_label),
    // Hyperscaler-specific IDs
    Esql.aws_account_id_values = VALUES(CASE(Esql.cloud_vendor == "aws", cloud.account.id, "unknown")),
    Esql.azure_tenant_id_values = VALUES(CASE(Esql.cloud_vendor == "azure", cloud.account.id, "unknown")),
    Esql.gcp_project_id_values = VALUES(CASE(Esql.cloud_vendor == "gcp", cloud.account.id, "unknown")),
    // Generic cloud metadata
    Esql.cloud_region_values = VALUES(cloud.region),
    Esql.k8s_namespace_values = VALUES(kubernetes.audit.objectRef.namespace),
    // Namespace values
    Esql.data_stream_namespace_values = VALUES(data_stream.namespace), 
    Esql_priv.user_name_values = VALUES(user.name)
  BY source.ip
// Require multi-vendor cred-access from same source IP
| WHERE Esql.vendor_count_distinct >= 2
| SORT Esql.events_count DESC
| KEEP Esql.*, Esql_priv.*, source.ip
'''



[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1555"
name = "Credentials from Password Stores"
reference = "https://attack.mitre.org/techniques/T1555/"
[[rule.threat.technique.subtechnique]]
id = "T1555.006"
name = "Cloud Secrets Management Stores"
reference = "https://attack.mitre.org/techniques/T1555/006/"



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

[metadata]
creation_date = "2026/07/30"
integration = ["network_traffic"]
maturity = "production"
updated_date = "2026/07/30"

[rule]
author = ["Elastic"]
description = """
Identifies MySQL statements that create a user-defined function backed by a shared library. Adversaries with sufficient
database privileges can place a malicious library in the MySQL plugin directory and register it with "CREATE FUNCTION
... SONAME", establishing a database-resident primitive for operating-system command execution.
"""
false_positives = [
    """
    Database administrators may install approved native MySQL user-defined functions during planned maintenance.
    Validate the function and library names, the client address, the maintenance window, and whether the shared library
    was supplied through an approved software deployment process.
    """,
]
from = "now-9m"
index = ["logs-network_traffic.mysql-*"]
language = "eql"
license = "Elastic License v2"
name = "MySQL User-Defined Function Injection"
note = """## Triage and analysis

### Investigating MySQL User-Defined Function Injection

MySQL can load native user-defined functions from shared libraries. Attackers who obtain the `FILE` privilege and write access to the plugin directory can write a malicious `.so` or `.dll`, register it with `CREATE FUNCTION ... SONAME`, and invoke operating-system commands as the MySQL service account.

### Possible investigation steps

- Review `client.ip`, `server.ip`, `network.community_id`, `network_traffic.mysql.query`, `network_traffic.mysql.path`, and any response error fields.
- Extract the function and library names and verify whether they belong to an approved MySQL extension.
- Search prior queries on the same connection for `INTO DUMPFILE`, `INTO OUTFILE`, `LOAD_FILE`, plugin-directory discovery, or hexadecimal payload construction.
- On the database host, inspect the MySQL plugin directory for newly created `.so`, `.dll`, or other unexpected files.
- Correlate with child processes spawned by `mysqld` and with outbound connections from the database host.

### False positive analysis

- Approved native UDF installation is uncommon but legitimate. Confirm the package source and change record.
- Do not exclude all DBA clients permanently; a compromised DBA workstation can perform the same operation.

### Response and remediation

- Terminate unauthorized database sessions and isolate the database host if command execution is suspected.
- Remove the malicious function and library only after preserving evidence.
- Rotate database credentials, review grants containing `FILE`, and restrict writes to the plugin directory.
"""
references = [
    "https://legalhackers.com/advisories/MySQL-Exploit-Remote-Root-Code-Execution-Privesc-CVE-2016-6662.html",
    "https://attack.mitre.org/techniques/T1505/001/",
]
risk_score = 73
rule_id = "c375532d-069d-41e0-af70-8ca032eb58f5"
setup = """## Setup

This rule requires the Elastic Network Packet Capture integration with the MySQL protocol analyzer enabled and
cleartext visibility into MySQL query traffic. TLS-encrypted sessions and incomplete or asymmetric capture can hide
query text. Use MySQL audit logs and endpoint telemetry for authoritative user attribution and proof of library
creation or command execution.
"""
severity = "high"
tags = [
    "Domain: Network",
    "Use Case: Network Security Monitoring",
    "Use Case: Threat Detection",
    "Tactic: Persistence",
    "Data Source: Network Packet Capture",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
any where data_stream.dataset == "network_traffic.mysql" and
    network_traffic.mysql.query like~ "*create*function*soname*"
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1505"
name = "Server Software Component"
reference = "https://attack.mitre.org/techniques/T1505/"
[[rule.threat.technique.subtechnique]]
id = "T1505.001"
name = "SQL Stored Procedures"
reference = "https://attack.mitre.org/techniques/T1505/001/"



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

[rule]
description = """
Identifies attempt to perform DLL hijacking using System32 executables or others in non-user-writable folders by
spoofing the the directory from which the application is loaded to an arbitrary user-specified one.
"""
id = "4c0b962c-b46c-4ac3-9f20-a1cf44ec8fdc"
license = "Elastic License v2"
name = "Potential DLL Hijack via Directory Spoofing"
os_list = ["windows"]
reference = ["https://github.com/Octoberfest7/DropSpawn_BOF"]
version = "1.0.5"

query = '''
sequence by process.entity_id with maxspan=1m
 [process where event.action == "start" and
  _arraysearch(process.parent.thread.Ext.call_stack, $entry, $entry.symbol_info: "*RtlCreateUserProcessEx*") and 
  process.parent.thread.Ext.call_stack_summary : "ntdll.dll*" and 
  not process.parent.thread.Ext.call_stack_summary : ("*kernel32*", "*kernelbase*", "ntdll.dll|smss.exe|ntdll.dll") and 
  not _arraysearch(process.parent.thread.Ext.call_stack, $entry, $entry.symbol_info: "*RtlCloneUserProcess*")]
 [library where not dll.code_signature.status : "trusted" and not startswith~(dll.name, process.name) and 
  process.thread.Ext.call_stack_summary : "ntdll.dll|kernel32.dll|ntdll.dll" and 
  not _arraysearch(process.thread.Ext.call_stack, $entry, $entry.symbol_info: ("*LdrLoadDll*", "*LoadLibrary*")) and 
  not dll.path : 
          ("?:\\Windows\\System32\\*", 
           "?:\\Windows\\SysWOW64\\*", 
           "?:\\Windows\\WinSxS\\*", 
           "?:\\Windows\\assembly\\*", 
           "?:\\Windows\\assembly\\NativeImages_v*", 
           "?:\\Windows\\SoftwareDistribution\\Download\\*", 
           "?:\\Program Files\\*", 
           "?:\\Program Files (x86)\\*") and 
  /* DLL not loaded from the process.executable current directory */
	not endswith~(substring(dll.path, 0, length(dll.path) - (length(dll.name) + 1)), substring(process.executable, 0, length(process.executable) - (length(process.name) + 1)))]
'''

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

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

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1574"
name = "Hijack Execution Flow"
reference = "https://attack.mitre.org/techniques/T1574/"
[[threat.technique.subtechnique]]
id = "T1574.001"
name = "DLL"
reference = "https://attack.mitre.org/techniques/T1574/001/"



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

[internal]
min_endpoint_version = "8.8.0"

[rule]
description = """
Identifies attempts to create a DLL file to a known desktop application dependencies folder such as Slack, Teams or
OneDrive and by an unusual process. This may indicate an attempt to load a malicious module via DLL search order
hijacking.
"""
id = "ddc4fa22-4675-44c0-a813-e786e638d7e0"
license = "Elastic License v2"
name = "Potential Initial Access via DLL Search Order Hijacking"
os_list = ["windows"]
reference = [
    "https://posts.specterops.io/automating-dll-hijack-discovery-81c4295904b0",
    "https://www.elastic.co/security-labs/Hunting-for-Suspicious-Windows-Libraries-for-Execution-and-Evasion",
]
version = "1.0.32"

query = '''
file where event.action != "deletion" and
 file.extension : "dll" and
 file.path :
        ("?:\\Users\\*\\AppData\\*\\Microsoft\\OneDrive\\*.dll",
         "?:\\Users\\*\\AppData\\*\\Microsoft OneDrive\\*.dll",
         "?:\\Users\\*\\AppData\\*\\Microsoft\\Teams\\*.dll",
         "?:\\Users\\*\\AppData\\Local\\slack\\app-*\\*.dll",
         "?:\\Users\\*\\AppData\\Local\\Programs\\Microsoft VS Code\\*",
         "?:\\Users\\*\\AppData\\Local\\*\\Well Known Domains\\*\\well_known_domains.dll",
         "?:\\Users\\*\\AppData\\Local\\*\\Domain Actions\\*\\domain_actions.dll") and
 process.name : ("winword.exe", "excel.exe", "powerpnt.exe", "MSACCESS.EXE", "MSPUB.EXE", "fltldr.exe", "cmd.exe",
                 "certutil.exe", "mshta.exe", "cscript.exe", "wscript.exe", "curl.exe", "powershell.exe", "pwsh.exe",
                 "mstsc.exe", "explorer.exe", "dllhost.exe", "xcopy.exe", "expand.exe") and
 not file.path : ("?:\\Users\\*\\AppData\\Local\\Microsoft\\OneDrive\\*\\*.dll",
                  "?:\\Users\\*\\AppData\\Local\\Microsoft\\Teams\\current\\resources\\meeting-addin\\*",
                  "?:\\Users\\*\\Teams\\current\\*")
'''

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

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

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1566"
name = "Phishing"
reference = "https://attack.mitre.org/techniques/T1566/"
[[threat.technique.subtechnique]]
id = "T1566.001"
name = "Spearphishing Attachment"
reference = "https://attack.mitre.org/techniques/T1566/001/"



[threat.tactic]
id = "TA0001"
name = "Initial Access"
reference = "https://attack.mitre.org/tactics/TA0001/"
[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1574"
name = "Hijack Execution Flow"
reference = "https://attack.mitre.org/techniques/T1574/"
[[threat.technique.subtechnique]]
id = "T1574.001"
name = "DLL"
reference = "https://attack.mitre.org/techniques/T1574/001/"



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

[internal]
min_endpoint_version = "7.15.0"

[metadata]
creation_date = "2026/09/07"
integration = ["endpoint"]
maturity = "production"
min_stack_version = "9.3.0"
min_stack_comments = "The file.Ext.* fields for file events were introduced in 9.3.0, and are required for this rule to function."
updated_date = "2026/09/07"

[rule]
author = ["Elastic"]
description = """
This rule detects when a web server process creates a file with a file extension that does not
match the file content based on the file header bytes. This is a common technique used by attackers
to bypass security measures and to hide the true nature of the file.
"""
from = "now-9m"
index = ["logs-endpoint.events.file*"]
language = "eql"
license = "Elastic License v2"
name = "Potential Polyglot Bypass File Created by Web Server"
note = """## Triage and analysis

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

### Investigating Potential Polyglot Bypass File Created by Web Server

This rule identifies Linux web server processes creating files with script or executable extensions whose header bytes indicate a different format, which may expose an upload-validation bypass or concealed malicious payload. An attacker could upload a JPEG/PHP polyglot named `avatar.php`, pass image-type validation using valid JPEG header bytes, and later execute appended PHP code as a web shell.

### Possible investigation steps

- Preserve the file and record its path, owner, permissions, timestamps, hash, and web-accessibility before quarantining it for static analysis.
- Compare the declared extension, detected file type, and full contents to identify appended server-side code, embedded executables, obfuscation, or multiple valid file formats.
- Correlate the creation time with reverse-proxy, web access, application, authentication, and upload logs to identify the source IP, account, request URI, user agent, and response status.
- Review related process activity and network connections for execution of the file, shell or interpreter launches, persistence changes, credential access, or outbound command-and-control traffic.
- Determine whether the application legitimately creates this file type and, if malicious or unexplained, isolate the host, block the artifact and source indicators, remove exposed files, and remediate the upload-validation weakness.

### False positive analysis

- A legitimate upload or media-processing workflow may save an image, document, or RIFF file with a script-like extension because of application naming logic, so verify the originating request, expected application behavior, and absence of appended executable code.
- A deployment, testing, or packaging process running under a web server account may create a valid ELF or archive-derived artifact with a monitored extension, so confirm the change against authorized deployment records and validate the file hash, contents, path, and owner.

### Response and remediation

- Isolate the affected web server and any systems contacted by the malicious file while preserving the polyglot artifact, relevant logs, and volatile evidence.
- Quarantine the file, block its hash and associated source addresses, and remove related web shells, dropped payloads, unauthorized accounts, and altered application files.
- Eliminate persistence from cron jobs, systemd units, startup scripts, SSH `authorized_keys`, web server modules, application plugins, and writable web-root directories.
- Rebuild the server from a known-good image, restore validated application content and configuration, patch exploited components, and rotate credentials or secrets accessible to the web server account.
- Escalate immediately to incident response and expand scoping if the file executed, spawned a shell or interpreter, initiated outbound connections, accessed credentials, or enabled lateral movement.
- Prevent recurrence by validating complete file content rather than extensions or headers, renaming uploads, storing them outside executable web paths, disabling script execution in upload directories, and enforcing least-privilege permissions.
"""
risk_score = 73
rule_id = "82f6fa8d-ea35-4329-b334-f1a557dc58c7"
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).

Elastic Defend integration does not collect advanced file information (such as the different file.Ext.* fields) by default.
In order to capture this behavior, this rule requires a specific configuration option set within the advanced settings of the Elastic Defend integration.
 #### To set up advanced file information capture for an Elastic Agent policy:
- Go to “Security → Manage → Policies”.
- Select an “Elastic Agent policy”.
- Click “Show advanced settings”.
- Scroll down or search for “linux.advanced.events.populate_file_data”.
- For this rule the linux.advanced.events.populate_file_data variable should be set to "true".
- Click “Save”.
After saving the integration change, the Elastic Agents running this policy will be updated and the rule will function properly.
"""
severity = "high"
tags = [
    "Domain: Endpoint",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Use Case: Vulnerability",
    "Tactic: Persistence",
    "Tactic: Initial Access",
    "Tactic: Lateral Movement",
    "Data Source: Elastic Defend",
    "Rule Type: Event Correlation (EQL)",
    "Resources: Investigation Guide"
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
file where host.os.type == "linux" and event.action != "deletion" and
(
  process.name in (
    "nginx", "apache2", "httpd", "caddy", "lighttpd", "httpd.worker", "httpd-worker", "httpd-prefork",
    "php-cgi", "php-fcgi", "php-cgi.cagefs", "frankenphp", "lshttpd", "litespeed", "openlitespeed",
    "fcgiwrap", "uwsgi", "daphne", "uvicorn", "hypercorn", "granian", "waitress-serve", "flask", "puma",
    "unicorn", "unicorn_rails", "thin", "rackup", "mongrel_rails", "starman", "plackup", "twiggy",
    "hypnotoad", "starlet", "unitd", "unitd-debug", "java", "node", "nodejs"
  ) or
  process.name like (
    "php-fpm*", "lsphp*", "gunicorn*", "*.cgi", "*.fcgi", "mono*", "xsp*", "mod-mono-server*",
    "fastcgi-mono-server*", "python*", "ruby*", "perl*", "lua*"
  )
) and
file.extension in~ ( 
  "php", "phtml", "pht", "php3", "php4", "php5", "php7", "phar",
  "asp", "aspx", "ashx", "asmx", "ascx", "cshtml",
  "jsp", "jspx", "jsx", "jspf", "tag", "tagx", "war", "ear",
  "js", "mjs", "cjs", "ts", "mts", "cts", "tsx",
  "razor",
  "py", "wsgi", "cgi", "fcgi", "pyc",
  "erb", "ru",
  "psgi",
  "lua", "luac",
  "sh", "elf"
) and
file.Ext.header_bytes like (
  "ffd8ff*",                // JPEG / JPG
  "89504e470d0a1a0a*",      // PNG 
  "47494638*",              // GIF (GIF87a / GIF89a)
  "00000100*",              // ICO
  "00000200*",              // CUR
  "424d*",                  // BMP
  "49492a00*",              // TIFF (little endian)
  "4d4d002a*",              // TIFF (big endian)
  "52494646*",              // RIFF container (WEBP/AVI/etc)
  "255044462d*",            // PDF
  "7f454c46*"               // ELF
)
'''

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

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

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

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

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

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

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

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

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

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

[metadata]
creation_date = "2022/09/01"
integration = ["endpoint"]
maturity = "production"
updated_date = "2025/12/23"

[rule]
author = ["Elastic"]
description = """
Identifies access to the /etc/shadow file via the commandline using standard system utilities. After elevating
privileges to root, threat actors may attempt to read or dump this file in order to gain valid credentials. They may
utilize these to move laterally undetected and access additional resources.
"""
from = "now-9m"
index = ["logs-endpoint.events.*", "endgame-*"]
language = "kuery"
license = "Elastic License v2"
name = "Potential Shadow File Read via Command Line Utilities"
note = """## Triage and analysis

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

### Investigating Potential Shadow File Read via Command Line Utilities

In Linux environments, the `/etc/shadow` file stores hashed passwords, making it a prime target for attackers seeking credential access. Adversaries with elevated privileges may exploit command-line utilities to read this file, aiming to extract credentials for lateral movement. The detection rule identifies suspicious access attempts by monitoring process activities related to the file, excluding legitimate operations, thus highlighting potential unauthorized access attempts.

### Possible investigation steps

- Review the process details to identify the executable and arguments used, focusing on the process.args field to confirm access attempts to /etc/shadow.
- Check the process.parent.name field to determine the parent process and assess if it is associated with known legitimate activities or suspicious behavior.
- Investigate the user context under which the process was executed to verify if the user had legitimate reasons to access the /etc/shadow file.
- Examine the host's recent activity logs for any privilege escalation events that might have preceded the access attempt, indicating potential unauthorized privilege elevation.
- Correlate the event with other alerts or logs from the same host to identify patterns or sequences of actions that suggest lateral movement or further credential access attempts.
- Assess the environment for any recent changes or deployments that might explain the access attempt, such as updates or configuration changes involving user management.

### False positive analysis

- System maintenance tasks may trigger alerts when legitimate processes like chown or chmod access the /etc/shadow file. To handle these, consider excluding these specific processes when they are executed by trusted system administrators during scheduled maintenance.
- Containerized environments might generate false positives if processes within containers access the /etc/shadow file. Exclude paths such as /var/lib/docker/* or /run/containerd/* to reduce noise from container operations.
- Security tools like wazuh-modulesd or custom scripts (e.g., gen_passwd_sets) that legitimately interact with the /etc/shadow file for monitoring or compliance checks can be excluded by adding them to the process.parent.name exclusion list.
- Automated scripts or cron jobs that perform routine checks or updates on system files, including /etc/shadow, should be reviewed and, if deemed safe, excluded from triggering alerts by specifying their process names or paths in the exclusion criteria.

### Response and remediation

- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement.
- Terminate any suspicious processes identified in the alert that are attempting to access the /etc/shadow file.
- Conduct a thorough review of user accounts and privileges on the affected system to identify any unauthorized privilege escalations or account creations.
- Change all passwords for accounts on the affected system, especially those with elevated privileges, to mitigate the risk of credential compromise.
- Review and update access controls and permissions for sensitive files like /etc/shadow to ensure they are restricted to only necessary users and processes.
- Monitor for any further attempts to access the /etc/shadow file across the network, using enhanced logging and alerting mechanisms to detect similar threats.
- Escalate the incident to the security operations team for further investigation and to determine if additional systems have been compromised."""
references = ["https://www.cyberciti.biz/faq/unix-linux-password-cracking-john-the-ripper/"]
risk_score = 47
rule_id = "9a3a3689-8ed1-4cdb-83fb-9506db54c61f"
setup = """## Setup

This rule requires data coming in from Elastic Defend.

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

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

#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
- Go to the Kibana home page and click "Add integrations".
- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
- Click "Add Elastic Defend".
- Configure the integration name and optionally add a description.
- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).
- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead.
For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
- Click "Save and Continue".
- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts.
For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
"""
severity = "medium"
tags = [
    "Domain: Endpoint",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Privilege Escalation",
    "Tactic: Credential Access",
    "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 : "process" and event.action : ("exec" or "exec_event") and
(
  process.args : "/etc/shadow" or
  (process.working_directory: "/etc" and process.args: "shadow")
) and not (
  (process.executable : ("/bin/chown" or "/usr/bin/chown") and process.args : "root:shadow") or
  (process.executable : ("/bin/chmod" or "/usr/bin/chmod") and process.args : "640") or
  process.executable:(
    /vz/* or /var/lib/docker/* or /run/containerd/* or /tmp/.criu* or /tmp/newroot/* or
    "/etc/cron.daily/passwd" or "/usr/sbin/lynis" or "/usr/bin/rkhunter" or
    "/usr/local/hestia/bin/v-check-user-password" or "/usr/sbin/setroubleshootd" or
    "/usr/lib/tiger/scripts/check_passwdformat"
  ) or
  process.parent.name:(gen_passwd_sets or scc_* or wazuh-modulesd)
)
'''

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

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

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

[[rule.threat.technique]]
id = "T1003"
name = "OS Credential Dumping"
reference = "https://attack.mitre.org/techniques/T1003/"

[[rule.threat.technique.subtechnique]]
id = "T1003.008"
name = "/etc/passwd and /etc/shadow"
reference = "https://attack.mitre.org/techniques/T1003/008/"

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

[rule.new_terms]
field = "new_terms_fields"
value = ["process.executable"]

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