Elastic rules: 0v

[rule]
description = """
Detects Windows Memory API calls by a process with a fake parent process identity set to Windows Explorer often to blend
in with user interactive activity.
"""
id = "e62f022c-88e2-403f-9f83-f76a91dd2203"
license = "Elastic License v2"
name = "API Call from a Process with a Spoofed Parent"
os_list = ["windows"]
version = "1.0.10"

query = '''
sequence by process.entity_id
 [process where event.action == "start" and process.parent.name : "explorer.exe" and process.parent.Ext.real.pid > 0 and 
  process.parent.thread.Ext.call_stack_summary : "?*" and process.executable != null and
  not _arraysearch(process.parent.thread.Ext.call_stack, $entry,
                   $entry.symbol_info : ("*advapi32.dll!CreateProcessAsUser*", "*advapi32.dll+0x*",
                    "C:\\Program Files (x86)\\ManageEngine\\UEMS_Agent\\appctrl\\bin\\Privilager.exe*")) and
  not (process.executable : ("?:\\Program Files\\*.exe", "?:\\Program Files (x86)\\*.exe") and
       process.code_signature.trusted == true and not process.code_signature.subject_name : "Microsoft*") and 
  not process.parent.thread.Ext.call_stack_summary : 
                                      ("*|rpcrt4.dll|*", 
                                       "*faultrep.dll|wersvc.dll*", 
                                       "*windows.storage.dll|shell32.dll*", 
                                       "*systemsettingsviewmodel.desktop.dll*")]
 [api where process.Ext.api.name : ("WriteProcessMemory", "VirtualProtect*", "VirtualAlloc*", "MapViewOfFile*") and
  _arraysearch(process.thread.Ext.call_stack_final_user_module.code_signature, $entry, $entry.trusted == false or $entry.exists == false) and
  not process.thread.Ext.call_stack_final_user_module.protection_provenance like ("Kernel", "Kernel|*") and
  not process.thread.Ext.call_stack_final_user_module.name in ("Kernel", "Unknown", "Undetermined", "sophosed.dll", "hmpalert.dll") and
  not process.thread.Ext.call_stack_final_user_module.hash.sha256 in
                                         ("d1e1d111eff2d7d3e60e5ed47d1919a43fe5a44e45f75d4a33f7a6cbc39a4aac",
                                          "3afe14049a0baabf0519d5502d465abc6050d5a0f4a4fdb3bca22ab419c33f2a",
                                          "cfcaf06eaa34d603ff3a89dd0ddfe4b17c0ee7ad8fa4534634d24e1692a5e352",
                                          "eb278baed0f9c422e9abb6bd947d7934086ea73080575ecb2ef4a7306ca5b037",
                                          "d807a7b13f948f60bc9c299f2b6976bf3988532adc02df5ed4f44538f13f4275",
                                          "8c5350999da9836037c67fd08bfb4e261d6e288a79c6b4fc3c8e3bd3d1f4171e",
                                          "108bddeccbd09a4621d7702e53442c236a2623cb03b653ed89a1fa26007388ca",
                                          "2319da9f696d1589aa7f7a0d9b8d9e87d103f13a86817b275789d3787f2cbf77",
                                          "b4e1daaee72eb9ea621918eaa4293a50bcf9c4d71fb545325b7dcd8b0e858f34",
                                          "38011e713b4be8577576062754cad03e9899859488932ae4c9c83e5fbb5cb7d2",
                                          "4328398412fdc6eadf57c4e659a45a34716cbccea0f4c025ef7fcd6e27d8ca48")]
 until [process where event.action:"end"]
'''

min_endpoint_version = "8.14.2"
[[actions]]
action = "kill_process"
field = "process.entity_id"
state = 1
tree = true

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

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

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

[[threat.technique]]
id = "T1134"
name = "Access Token Manipulation"
reference = "https://attack.mitre.org/techniques/T1134/"
[[threat.technique.subtechnique]]
id = "T1134.004"
name = "Parent PID Spoofing"
reference = "https://attack.mitre.org/techniques/T1134/004/"



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

[internal]
min_endpoint_version = "8.14.2"

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

[rule]
author = ["Elastic"]
description = """
Detects attempts to deactivate an Okta policy. An adversary may attempt to deactivate an Okta policy in order to weaken
an organization's security controls. For example, an adversary may attempt to deactivate an Okta multi-factor
authentication (MFA) policy in order to weaken the authentication requirements for user accounts.
"""
false_positives = [
    """
    If the behavior of deactivating Okta policies is expected, consider adding exceptions to this rule to filter false
    positives.
    """,
]
index = ["filebeat-*", "logs-okta*"]
language = "kuery"
license = "Elastic License v2"
name = "Attempt to Deactivate an Okta Policy"
note = """## Triage and analysis

### Investigating Attempt to Deactivate an Okta Policy

Okta policies define rules to manage user access to resources. Policies such as multi-factor authentication (MFA) are critical for enforcing strong security measures. Deactivation of an Okta policy could potentially weaken the security posture, allowing for unauthorized access or facilitating other malicious activities.

This rule is designed to detect attempts to deactivate an Okta policy, which could be indicative of an adversary's attempt to weaken an organization's security controls. For example, disabling an MFA policy could lower the security of user authentication processes.

#### Possible investigation steps:

- Identify the actor related to the alert by reviewing `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, or `okta.actor.display_name` fields in the alert.
- Review the `okta.client.user_agent.raw_user_agent` field to understand the device and software used by the actor.
- Examine the `okta.outcome.reason` field for additional context around the deactivation attempt.
- Check the `okta.outcome.result` field to confirm the policy deactivation attempt.
- Check if there are multiple policy deactivation attempts from the same actor or IP address (`okta.client.ip`).
- Check for successful logins immediately following the policy deactivation attempt.
- Verify whether the actor's activity aligns with typical behavior or if any unusual activity took place around the time of the deactivation attempt.

### False positive analysis:

- Check if there were issues with the Okta system at the time of the deactivation attempt. This could indicate a system error rather than a genuine threat activity.
- Check the geographical location (`okta.request.ip_chain.geographical_context`) and time of the deactivation attempt. If these match the actor's normal behavior, it might be a false positive.
- Verify the actor's administrative rights to ensure they are correctly configured.

### Response and remediation:

- If unauthorized policy deactivation is confirmed, initiate the incident response process.
- Immediately lock the affected actor account and require a password change.
- Consider resetting MFA tokens for the actor and require re-enrollment.
- Check if the compromised account was used to access or alter any sensitive data or systems.
- If a specific deactivation technique was used, ensure your systems are patched or configured to prevent such techniques.
- Assess the criticality of affected services and servers.
- Work with your IT team to minimize the impact on users and maintain business continuity.
- If multiple accounts are affected, consider a broader reset or audit of MFA tokens.
- Implement security best practices [outlined](https://www.okta.com/blog/2019/10/9-admin-best-practices-to-keep-your-org-secure/) by Okta.
- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).

## Setup

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/Security/Security_Policies.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 = "b719a170-3bdb-4141-b0e3-13e3cf627bfe"
severity = "low"
tags = [
    "Use Case: Identity and Access Audit",
    "Data Source: Okta",
    "Tactic: Defense Evasion",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:okta.system and event.action:policy.lifecycle.deactivate
'''


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

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

[[rule.threat.technique.subtechnique]]
id = "T1556.006"
name = "Multi-Factor Authentication"
reference = "https://attack.mitre.org/techniques/T1556/006/"

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

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

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

[rule]
description = """
Identifies DNS queries to known Dynamic DNS Providers by a signed Microsoft binary execution proxy. Dynamic DNS
providers are often misused to host malware Command and Control servers.
"""
id = "fb6939a2-1b54-428c-92a2-3a831585af2a"
license = "Elastic License v2"
name = "Connection to Dynamic DNS Provider by a Signed Binary Proxy"
os_list = ["windows"]
version = "1.0.35"

query = '''
sequence by process.entity_id with maxspan=5m
  [process where event.action == "start" and user.id like ("S-1-5-21*", "S-1-12-*") and
    (
     process.name : ("wscript.exe", "cscript.exe", "regsvr32.exe", "mshta.exe", "rundll32.exe", "vbc.exe",
                     "powershell.exe", "pwsh.exe", "msbuild.exe", "wmic.exe", "cmstp.exe", "RegAsm.exe",
                     "installutil.exe","RegSvcs.exe", "msxsl.exe", "xwizard.exe", "csc.exe", "msiexec.exe",
                     "scp.exe", "ssh.exe") or
     process.executable : ("?:\\Program Files\\Java\\jre*\\bin\\javaw.exe",
                           "?:\\Program Files (x86)\\Java\\jre*\\bin\\javaw.exe") or

     (process.executable : "?:\\Windows\\Microsoft.NET\\*.exe" and not (process.name:"dfsvc.exe" and process.parent.name : "rundll32.exe"))
     )
  ]
  [dns where
    dns.question.name :
         (
          "*.no-ip.com",
          "*.no-ip.org",
          "*.no-ip.biz",
          "*.no-ip.info",
          "*.noip.com",
          "*.afraid.org",
          "*.changeip.com",
          "*.ddns.net",
          "*.dyndns.org",
          "*.hopto.org",
          "*.zapto.org",
          "*.servehttp.com",
          "*.sytes.net",
          "*.myftp.biz",
          "*.myftp.org",
          "*.ddnsfree.com",
          "*.duckdns.org",
          "*.000webhostapp.com",
          "*.myddns.me",
          "*.dlinkddns.com",
          "*.chickenkiller.com",
          "*.thddns.net",
          "*.linkpc.net",
          "*.gotdns.ch",
          "*.dynv6.net",
          "*.dns.army",
          "*.dns.navy",
          "*.v6.army",
          "*.v6.navy",
          "*.v6.rocks",
          "*.dyndns-office.com",
          "*.myvnc.com",
          "*.is-certified.com"
         ) and

     /* covered by rule Id 51894221-7657-4b56-9406-e080e19ad159 */
    not dns.question.name : "checkip.dyndns.org" and
    not dns.question.name : ("www.duckdns.org")
  ]
'''

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

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

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1218"
name = "System Binary Proxy Execution"
reference = "https://attack.mitre.org/techniques/T1218/"


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



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

[internal]
min_endpoint_version = "7.15.0"

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

[rule]
author = ["Elastic"]
description = """
This rule detects the use of the "curl" command-line tool with SOCKS proxy options, launched from an unusual parent
process. Attackers may use "curl" to establish a SOCKS proxy connection to bypass network restrictions and exfiltrate
data or communicate with C2 servers.
"""
from = "now-9m"
index = ["logs-endpoint.events.process*"]
language = "eql"
license = "Elastic License v2"
name = "Curl SOCKS Proxy Activity from Unusual Parent"
risk_score = 47
rule_id = "734239fe-eda8-48c0-bca8-9e3dafd81a88"
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 environment variable logging 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 environment variable 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.capture_env_vars”.
- Enter the names of environment variables you want to capture, separated by commas.
- For this rule the linux.advanced.capture_env_vars variable should be set to "HTTP_PROXY,HTTPS_PROXY,ALL_PROXY".
- Click “Save”.
After saving the integration change, the Elastic Agents running this policy will be updated and the rule will function properly.
For more information on capturing environment variables refer to the [helper guide](https://www.elastic.co/guide/en/security/current/environment-variable-capture.html).
"""
severity = "medium"
tags = [
    "Domain: Endpoint",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Command and Control",
    "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.name == "curl" and (
  process.parent.executable like (
    "/dev/shm/*", "/tmp/*", "/var/tmp/*", "/var/run/*", "/root/*", "/boot/*", "/var/www/*", "/opt/.*",
    "/home/*"
  ) or
  process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") or
  process.parent.name like ".*"
) and (
  process.args like ("--socks5-hostname", "--proxy", "--preproxy", "socks5*") or
  process.args == "-x" or
  process.env_vars like~ ("http_proxy=socks5h://*", "HTTPS_PROXY=socks5h://*", "ALL_PROXY=socks5h://*")
) and not (
  process.parent.args == "/opt/rudder/share/commands/agent-run" or
  process.args == "http://localhost:8080/rudder/api/status"
)
'''
note = """## Triage and analysis

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

### Investigating Curl SOCKS Proxy Activity from Unusual Parent

Curl is a versatile command-line tool used for transferring data with URLs, often employed for legitimate data retrieval. However, adversaries can exploit its SOCKS proxy capabilities to bypass network restrictions, facilitating covert data exfiltration or communication with command and control servers. The detection rule identifies suspicious curl executions initiated by atypical parent processes, such as those from temporary directories or shell environments, combined with SOCKS proxy arguments, indicating potential misuse.

### Possible investigation steps

- Review the parent process details to understand the context of the curl execution, focusing on unusual directories like /dev/shm, /tmp, or shell environments such as bash or zsh.
- Examine the command-line arguments used with curl, specifically looking for SOCKS proxy options like --socks5-hostname or -x, to determine the intent and destination of the network request.
- Investigate the environment variables set for the process, such as http_proxy or HTTPS_PROXY, to identify any proxy configurations that might indicate an attempt to bypass network restrictions.
- Check the user account associated with the process execution to determine if it aligns with expected behavior or if it might be compromised.
- Analyze network logs to trace the destination IP addresses or domains contacted via the SOCKS proxy to assess if they are known malicious or suspicious entities.
- Correlate this activity with other alerts or logs from the same host to identify any patterns or additional indicators of compromise.

### False positive analysis

- Development environments may frequently use curl with SOCKS proxy options for legitimate testing purposes. To manage this, consider excluding specific development directories or user accounts from the rule.
- Automated scripts or cron jobs running from shell environments might use curl with SOCKS proxies for routine data retrieval. Identify these scripts and exclude their parent processes or specific arguments from triggering the rule.
- System administrators might use curl with SOCKS proxies for network diagnostics or maintenance tasks. Document these activities and create exceptions for known administrative accounts or specific command patterns.
- Web applications hosted in directories like /var/www/html may use curl for backend operations involving SOCKS proxies. Review these applications and whitelist their specific processes or arguments if they are verified as non-threatening.
- Temporary directories such as /tmp or /dev/shm might be used by legitimate software for transient operations involving curl. Monitor these occurrences and exclude known benign software from the rule.

### Response and remediation

- Immediately isolate the affected host from the network to prevent further data exfiltration or communication with command and control servers.
- Terminate any suspicious curl processes identified by the detection rule to halt potential malicious activity.
- Conduct a forensic analysis of the affected system to identify any additional indicators of compromise, such as unauthorized file modifications or additional malicious processes.
- Review and clean up any unauthorized or suspicious files in temporary directories or other unusual locations, such as /dev/shm, /tmp, or /var/tmp, to remove potential threats.
- Reset credentials and review access logs for any accounts that may have been compromised or used in conjunction with the detected activity.
- Implement network monitoring to detect and block any further attempts to use SOCKS proxy connections from unauthorized sources.
- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if broader organizational impacts exist."""

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

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

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

[[rule.threat.technique]]
id = "T1572"
name = "Protocol Tunneling"
reference = "https://attack.mitre.org/techniques/T1572/"

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

[metadata]
creation_date = "2025/05/08"
integration = ["azure"]
maturity = "production"
updated_date = "2026/05/21"

[rule]
author = ["Elastic"]
description = """
Identifies potential session hijacking or token replay in Microsoft Entra ID. This rule detects cases where a user signs
in and subsequently accesses Microsoft Graph from a different IP address using the same session ID. This may indicate a
successful OAuth phishing attack, session hijacking, or token replay attack, where an adversary has stolen a session
cookie or refresh/access token and is impersonating the user from an alternate host or location.
"""
false_positives = [
    """
    This pattern may occur during legitimate device switching or roaming between networks (e.g., corporate to mobile).
    Developers or power users leveraging multiple environments may also trigger this detection if session persistence
    spans IP ranges. Still, this behavior is rare and warrants investigation when rapid IP switching and Graph access
    are involved.
    """,
]
from = "now-31m"
interval = "30m"
language = "esql"
license = "Elastic License v2"
name = "Entra ID OAuth User Impersonation to Microsoft Graph"
note = """## Triage and analysis

### Investigating Entra ID OAuth User Impersonation to Microsoft Graph

Identifies potential phishing, session hijacking or token replay in Microsoft Entra ID. This rule detects cases where a user signs in and subsequently accesses Microsoft Graph from a different IP address using the same session ID and client application. This may indicate a successful OAuth phishing attack, session hijacking, or token replay attack, where an adversary has stolen a session cookie or refresh/access token and is impersonating the user from an alternate host or location.

This rule uses ESQL aggregations and thus has dynamically generated fields. Correlation of the values in the alert document may need to be
performed to the original sign-in and Graph events for further context.

### Possible investigation steps

- This rule relies on an aggregation-based ESQL query, therefore the alert document will contain dynamically generated fields.
    - To pivot into the original events, it is recommended to use the values captured to filter in timeline or discovery for the original sign-in and Graph events.
- Review the session ID and user ID to identify the user account involved in the suspicious activity.
- Check the source addresses involved in the sign-in and Graph access to determine if they are known or expected locations for the user.
    - The sign-in source addresses should be two, one for the initial phishing sign-in and the other when exchanging the auth code for a token by the adversary.
    - The Graph API source address should identify the IP address used by the adversary to access Microsoft Graph.
- Review the user agent strings for the sign-in and Graph access events to identify any anomalies or indicators of compromise.
- Analyze the Graph permission scopes to identify what resources were accessed and whether they align with the user's expected behavior.
- Check the timestamp difference between the sign-in and Graph access events to determine if they occurred within a reasonable time frame that would suggest successful phishing to token issuance and then Graph access.
- Identify the original sign-in event to investigation if conditional access policies were applied, such as requiring multi-factor authentication or blocking access from risky locations. In phishing scenarios, these policies likely were applied as the victim user would have been prompted to authenticate.

### False positive analysis
- This pattern may occur during legitimate device switching or roaming between networks (e.g., corporate to mobile).
- Developers or power users leveraging multiple environments may also trigger this detection if session persistence spans IP ranges. Still, this behavior is rare and warrants investigation when rapid IP switching and Graph access are involved.

### Response and remediation

- If confirmed malicious, revoke all refresh/access tokens for the user principal.
- Block the source IP(s) involved in the Graph access.
- Notify the user and reset credentials.
- Review session control policies and conditional access enforcement.
- Monitor for follow-on activity, such as lateral movement or privilege escalation.
- Review conditional access policies to ensure they are enforced correctly.
"""
references = [
    "https://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/",
    "https://github.com/dirkjanm/ROADtools",
    "https://attack.mitre.org/techniques/T1078/004/",
    "https://pushsecurity.com/blog/consentfix",
]
risk_score = 47
rule_id = "0d3d2254-2b4a-11f0-a019-f661ea17fbcc"
setup = """#### Required Microsoft Entra ID Sign-In and Graph Activity Logs
This rule requires the Microsoft Entra ID Sign-In Logs and Microsoft Graph Activity Logs integration to be enabled and configured to collect audit and activity logs via Azure Event Hub.
"""
severity = "medium"
tags = [
    "Domain: Cloud",
    "Domain: Identity",
    "Domain: API",
    "Data Source: Azure",
    "Data Source: Microsoft Entra ID",
    "Data Source: Microsoft Entra ID Sign-In Logs",
    "Data Source: Microsoft Graph",
    "Data Source: Microsoft Graph Activity Logs",
    "Use Case: Identity and Access Audit",
    "Use Case: Threat Detection",
    "Resources: Investigation Guide",
    "Tactic: Defense Evasion",
    "Tactic: Initial Access",
]
timestamp_override = "event.ingested"
type = "esql"

query = '''
from logs-azure.signinlogs-*, logs-azure.graphactivitylogs-* metadata _id, _version, _index
| where
    (data_stream.dataset == "azure.signinlogs"
     and source.`as`.organization.name != "MICROSOFT-CORP-MSN-AS-BLOCK"
     and azure.signinlogs.properties.session_id is not null)
    or
    (data_stream.dataset == "azure.graphactivitylogs"
     and source.`as`.organization.name != "MICROSOFT-CORP-MSN-AS-BLOCK"
     and azure.graphactivitylogs.properties.c_sid is not null)

| eval
    Esql.azure_signinlogs_properties_session_id_coalesce = coalesce(azure.signinlogs.properties.session_id, azure.graphactivitylogs.properties.c_sid),
    Esql.azure_signinlogs_properties_user_id_coalesce = coalesce(azure.signinlogs.properties.user_id, azure.graphactivitylogs.properties.user_principal_object_id),
    Esql.azure_signinlogs_properties_app_id_coalesce = coalesce(azure.signinlogs.properties.app_id, azure.graphactivitylogs.properties.app_id),
    Esql.source_ip = source.ip,
    Esql.@timestamp = @timestamp,
    Esql.event_type_case = case(
        data_stream.dataset == "azure.signinlogs", "signin",
        data_stream.dataset == "azure.graphactivitylogs", "graph",
        "other"
    ),
    Esql.signin_source_asn = case(data_stream.dataset == "azure.signinlogs", source.`as`.organization.name),
    Esql.graph_source_asn = case(data_stream.dataset == "azure.graphactivitylogs", source.`as`.organization.name)

| where Esql.azure_signinlogs_properties_app_id_coalesce not in (
    "4354e225-50c9-4423-9ece-2d5afd904870",  // Augmentation Loop
    "cc15fd57-2c6c-4117-a88c-83b1d56b4bbe",  // Microsoft Teams Services
    "ecd6b820-32c2-49b6-98a6-444530e5a77a",  // Microsoft Edge [Community Contributed]
    "e8be65d6-d430-4289-a665-51bf2a194bda",  // Microsoft 365 App Catalog Services
    "ab9b8c07-8f02-4f72-87fa-80105867a763",  // OneDrive SyncEngine
    "394866fc-eedb-4f01-8536-3ff84b16be2a",  // Microsoft People Cards Service
    "66a88757-258c-4c72-893c-3e8bed4d6899",  // Office 365 Search Service
    "9ea1ad79-fdb6-4f9a-8bc3-2b70f96e34c7",  // Bing
    "d7b530a4-7680-4c23-a8bf-c52c121d2e87",  // Microsoft Edge Enterprise New Tab Page [Community Contributed]
    "6f7e0f60-9401-4f5b-98e2-cf15bd5fd5e3",  // Microsoft Application Command Service [Community Contributed]
    "52c2e0b5-c7b6-4d11-a89c-21e42bcec444",  // Graph Files Manager
    "27922004-5251-4030-b22d-91ecd9a37ea4",  // Outlook Mobile
    "bb893c22-978d-4cd4-a6f7-bb6cc0d6e6ce",  // Olympus [Community Contributed]
    "26a7ee05-5602-4d76-a7ba-eae8b7b67941",  // Windows Search
    "00000007-0000-0000-c000-000000000000",  // Dataverse
    "6bc3b958-689b-49f5-9006-36d165f30e00",  // Teams CMD Services Artifacts
    "0ec893e0-5785-4de6-99da-4ed124e5296c",  // Office UWP PWA [Community Contributed]
    "fc108d3f-543d-4374-bbff-c7c51f651fe5",  // Zoom
    "01fc33a7-78ba-4d2f-a4b7-768e336e890e",  // MS PIM
    "7ab7862c-4c57-491e-8a45-d52a7e023983"   // Power Automate / Logic Apps Graph Connector
    ) and Esql.signin_source_asn IS NOT NULL and Esql.graph_source_asn IS NOT NULL

| keep
    Esql.azure_signinlogs_properties_session_id_coalesce,
    Esql.source_ip,
    Esql.@timestamp,
    Esql.event_type_case,
    Esql.azure_signinlogs_properties_user_id_coalesce,
    Esql.azure_signinlogs_properties_app_id_coalesce,
    Esql.signin_source_asn,
    Esql.graph_source_asn,
    source.`as`.organization.name,
    user_agent.original,
    url.original,
    azure.graphactivitylogs.properties.scopes,
    azure.signinlogs.properties.user_principal_name

| stats
    Esql.azure_signinlogs_properties_user_id_coalesce_values = values(Esql.azure_signinlogs_properties_user_id_coalesce),
    Esql.azure_signinlogs_properties_session_id_coalesce_values = values(Esql.azure_signinlogs_properties_session_id_coalesce),
    Esql_priv.azure_signinlogs_properties_user_principal_name_values = values(azure.signinlogs.properties.user_principal_name),
    Esql.source_ip_values = values(Esql.source_ip),
    Esql.source_ip_count_distinct = count_distinct(Esql.source_ip),
    Esql.source_as_organization_name_values = values(source.`as`.organization.name),
    Esql.source_as_organization_name_count_distinct = count_distinct(source.`as`.organization.name),
    Esql.signin_source_asn_values = values(Esql.signin_source_asn),
    Esql.signin_source_asn_count_distinct = count_distinct(Esql.signin_source_asn),
    Esql.graph_source_asn_values = values(Esql.graph_source_asn),
    Esql.graph_source_asn_count_distinct = count_distinct(Esql.graph_source_asn),
    Esql.user_agent_original_values = values(user_agent.original),
    Esql.azure_signinlogs_properties_app_id_coalesce_values = values(Esql.azure_signinlogs_properties_app_id_coalesce),
    Esql.azure_signinlogs_properties_app_id_coalesce_count_distinct = count_distinct(Esql.azure_signinlogs_properties_app_id_coalesce),
    Esql.event_type_case_values = values(Esql.event_type_case),
    Esql.event_type_case_count_distinct = count_distinct(Esql.event_type_case),
    Esql.signin_time_min = min(case(Esql.event_type_case == "signin", Esql.@timestamp)),
    Esql.graph_time_min = min(case(Esql.event_type_case == "graph", Esql.@timestamp)),
    Esql.url_original_values = values(url.original),
    Esql.azure_graphactivitylogs_properties_scopes_values = values(azure.graphactivitylogs.properties.scopes),
    Esql.event_count = count()
  by
    Esql.azure_signinlogs_properties_session_id_coalesce,
    Esql.azure_signinlogs_properties_app_id_coalesce,
    Esql.azure_signinlogs_properties_user_id_coalesce

| eval
    Esql.event_signin_to_graph_delay_minutes_date_diff = date_diff("minutes", Esql.signin_time_min, Esql.graph_time_min),
    Esql.event_signin_to_graph_delay_days_date_diff = date_diff("days", Esql.signin_time_min, Esql.graph_time_min)

| where
    Esql.event_type_case_count_distinct > 1 and
    Esql.source_ip_count_distinct > 1 and
    Esql.source_as_organization_name_count_distinct > 1 and
    Esql.azure_signinlogs_properties_app_id_coalesce_count_distinct == 1 and
    Esql.signin_time_min is not null and
    Esql.graph_time_min is not null and
    Esql.event_signin_to_graph_delay_minutes_date_diff > 0 and
    Esql.event_signin_to_graph_delay_days_date_diff == 0 and
    (Esql.signin_source_asn_count_distinct + Esql.graph_source_asn_count_distinct) == Esql.source_as_organization_name_count_distinct
'''


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

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

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

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

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

[[rule.threat.technique]]
id = "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.technique.subtechnique]]
id = "T1550.004"
name = "Web Session Cookie"
reference = "https://attack.mitre.org/techniques/T1550/004/"

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

[rule]
description = "Identifies the execution of a Windows script that was downloaded from the internet."
id = "a87d8240-0b80-4255-8680-cee8c68b2d1e"
license = "Elastic License v2"
name = "Execution of a Windows Script Downloaded from the Internet"
os_list = ["windows"]
version = "1.0.5"

query = '''
sequence with maxspan=5m
 [file where event.action == "creation" and
  file.Ext.windows.zone_identifier == 3 and file.origin_url : "http*" and
  file.extension in~ ("js", "jse", "vbs", "vbe", "wsh", "hta") and
  not file.origin_url like ("https://www.manageengine.com/products/*",
                            "https://*.sharepoint.com/*",
                            "https://artifacts.elastic.co/downloads/*",
                            "https://ajax.googleapis.com/ajax*",
                            "https://api.media.atlassian.com/*",
                            "https://gitlab.com/blooket/blooket-cheats/*", 
                            "https://dl.driverpack.io/test/PROD_Start_DriverPack.hta")
  ] as event0
 [process where event.action == "start" and
  (process.name in~ ("wscript.exe", "cscript.exe", "mshta.exe") or
   process.pe.original_file_name in ("cscript.exe", "wscript.exe", "MSHTA.EXE")) and
   (
    /* substring used to remove Zone.Identifier from file.name */
    stringcontains~(process.command_line, substring(event0.file.name, 0, length(event0.file.name) - 16)) or

    stringcontains~(process.command_line, event0.file.name) or

    startswith~(event0.file.path, process.working_directory)
   )]
'''

min_endpoint_version = "8.15.0"
[[actions]]
action = "kill_process"
field = "process.entity_id"
state = 1
tree = true

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

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

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



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

[internal]
min_endpoint_version = "8.15.0"

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

[rule]
author = ["Elastic"]
description = """
Detects an unusual volume of GKE API get requests against multiple distinct Secret objects from the same client
fingerprint (user, source IP, and user agent) within the rule 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 included and
can signal RBAC probing; system service accounts are excluded only when secret reads succeed, since failed secret access
by a service account may indicate compromise or misconfiguration worth investigating.
"""
false_positives = [
    """
    Startup, Helm, or controllers may legitimately touch many secrets in one window; tune by client.user.email,
    namespace, or IP allowlists when baselined.
    """,
]
from = "now-6m"
language = "esql"
license = "Elastic License v2"
name = "GKE Rapid Secret GET Activity Against Multiple Objects"
note = """## Triage and analysis

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

This rule surfaces clusters of `get` operations on secrets where the same identity and client path
(`client.user.email`, `source.ip`, `user_agent.original`) touch several different secret resource paths within the
lookback window. Allowed and denied outcomes are included: successful reads may indicate harvesting; repeated
failure responses can still signal reconnaissance or RBAC probing. System service accounts and core controllers are
excluded only for successful secret reads, failed attempts from those identities still alert.

### Investigation steps

- Inspect `Esql.event_outcome_values` for a mix of success vs failure and whether failures cluster on sensitive namespaces.
- Map the identity to RBAC and namespace scope; review `Esql.gcp_audit_resource_name_values` 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

- Controllers and Helm may legitimately read many secrets in one window; tune exclusions after baselining known automation.

## Setup

The GCP Fleet integration with GKE audit logs enabled is required to be compatible with this rule."""
references = [
    "https://attack.mitre.org/techniques/T1552/007/",
]
risk_score = 73
rule_id = "4780a3d6-e6a7-490c-9afb-9c5fbb220b9a"
severity = "high"
tags = [
    "Domain: Cloud",
    "Domain: Kubernetes",
    "Data Source: GCP",
    "Data Source: Google Cloud Platform",
    "Use Case: Threat Detection",
    "Tactic: Credential Access",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "esql"

query = '''
from logs-gcp.audit-* metadata _id, _index, _version
| where data_stream.dataset == "gcp.audit"
    and service.name == "k8s.io"
    and event.action == "io.k8s.core.v1.secrets.get"
    and source.ip is not null
    and client.user.email is not null
    and not to_string(source.ip) in ("127.0.0.1", "::1")
    and not (
      (client.user.email in ("system:kube-controller-manager", "system:kube-scheduler") or client.user.email like "system:serviceaccount:*")
      and event.outcome == "success"
    )
    and not gcp.audit.resource_name like "*sh.helm.release.*"
| stats
    Esql.gcp_audit_resource_name_count_distinct = count_distinct(gcp.audit.resource_name),
    Esql.gcp_audit_resource_name_values = values(gcp.audit.resource_name),
    Esql.event_outcome_values = values(event.outcome),
    Esql.timestamp_values = values(@timestamp)
  by client.user.email, source.ip, user_agent.original
| where Esql.gcp_audit_resource_name_count_distinct >= 3
| keep client.user.email, source.ip, user_agent.original, Esql.gcp_audit_resource_name_count_distinct, Esql.gcp_audit_resource_name_values, Esql.event_outcome_values, Esql.timestamp_values
'''

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

[metadata]
creation_date = "2026/03/26"
integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel", "cloud_defend"]
maturity = "production"
min_stack_comments = "Defend for Containers integration was re-introduced in 9.3.0"
min_stack_version = "9.3.0"
updated_date = "2026/05/11"

[rule]
author = ["Elastic"]
description = """
This rule detects the use of the "kubectl get secrets --all-namespaces" command, which enumerates secret resources
across the entire Kubernetes cluster. Attackers may use this command to identify accessible secrets in multiple
namespaces, aiding credential discovery, privilege escalation, or lateral movement.
"""
from = "now-9m"
index = [
    "auditbeat-*",
    "endgame-*",
    "logs-auditd_manager.auditd-*",
    "logs-crowdstrike.fdr*",
    "logs-endpoint.events.process*",
    "logs-sentinel_one_cloud_funnel.*",
    "logs-cloud_defend.process*",
]
language = "eql"
license = "Elastic License v2"
name = "Kubectl Secrets Enumeration Across All Namespaces"
note = """ ## Triage and analysis

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

### Investigating Kubectl Secrets Enumeration Across All Namespaces

Kubectl allows users to query Kubernetes resources from the command line. Adversaries may use "kubectl get secrets --all-namespaces" or "kubectl get secrets -A" to enumerate secret objects across the cluster and identify valuable targets for credential access or privilege escalation. The detection rule identifies this broad secret discovery activity by monitoring kubectl executions that request secrets from all namespaces.

### Possible investigation steps

- Review the full process command line to confirm whether the command used "get secrets --all-namespaces" or the short form "-A", and determine whether additional output modifiers such as "-o yaml" or "-o json" were used.
- Identify the user account and host that launched the kubectl command and determine whether this activity aligns with approved administrative or automation workflows.
- Correlate the event with Kubernetes audit logs to determine what secret resources were listed and whether subsequent access, read, or modification activity followed.
- Examine related kubectl activity from the same user or host, especially commands involving "auth can-i", "--as", "--token", or kubeconfig changes, which may indicate privilege probing or impersonation.
- Investigate whether the same session later accessed sensitive resources, exported command output, or connected to external destinations that could indicate staging or exfiltration of discovered information.

### False positive analysis

- Cluster administrators or platform engineers may legitimately enumerate secrets across namespaces during troubleshooting, audits, or migration work. Create exceptions for known users, hosts, or automation contexts where appropriate.
- CI/CD or compliance tooling may run kubectl commands with "-A" to inventory cluster resources. Review these tools and exclude their specific execution patterns if they are expected.
- Security assessment or validation activity may intentionally enumerate secrets to verify access controls. Coordinate with security teams to document those activities and reduce unnecessary alerts.
- Development or lab environments may generate this behavior during testing. Consider environment-specific tuning if this activity is expected outside production.

### Response and remediation

- Validate whether the user or service account that executed the command should have cluster-wide visibility into secrets, and revoke or reduce permissions if the access is not justified.
- Review Kubernetes audit logs and API activity to determine whether any listed secrets were subsequently read, exported, or abused.
- Rotate any credentials, tokens, or certificates associated with sensitive secrets that may have been exposed to an unauthorized actor.
- Investigate adjacent activity from the same host or identity, including kubeconfig access, impersonation flags, direct API usage, or suspicious network connections.
- Escalate to incident response if the activity is unauthorized, originated from an unusual workstation, or was followed by secret reads, pod creation, or changes to RBAC bindings.
"""
references = [
    "https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#get",
]
risk_score = 73
rule_id = "a87d49f0-24ae-4d6e-a0b4-5fd2f6188d6a"
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 or macOS system:
- Go to the Kibana home page and click "Add integrations".
- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
- Click "Add Elastic Defend".
- Configure the integration name and optionally add a description.
- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).
- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead.
For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
- Click "Save and Continue".
- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts.
For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
"""
severity = "high"
tags = [
  "Domain: Endpoint",
  "Domain: Container",
  "Domain: Kubernetes",
  "OS: Linux",
  "OS: macOS",
  "Use Case: Threat Detection",
  "Tactic: Discovery",
  "Tactic: Credential Access",
  "Data Source: Elastic Defend",
  "Data Source: Elastic Endgame",
  "Data Source: Auditd Manager",
  "Data Source: Crowdstrike",
  "Data Source: SentinelOne",
  "Data Source: Elastic Defend for Containers",
  "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
process where host.os.type in ("linux", "macos") and event.type == "start" and
event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and
process.name == "kubectl" and process.args in ("get", "describe") and process.args in ("secret", "secrets") and
process.args in ("--all-namespaces", "-A")
'''

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

[[rule.threat.technique]]
id = "T1613"
name = "Container and Resource Discovery"
reference = "https://attack.mitre.org/techniques/T1613/"

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

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

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

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

[metadata]
creation_date = "2025/06/24"
integration = ["kubernetes"]
maturity = "production"
updated_date = "2026/04/10"

[rule]
author = ["Elastic"]
description = """
This rule detects attempts to create resources in Kubernetes clusters that are forbidden by the authorization policy. It
specifically looks for creation requests that are denied with a "forbid" decision, indicating that the user or service
account does not have the necessary permissions to perform the action. This activity is commonly associated with
adversaries attempting to create resources in a Kubernetes environment without proper authorization, which can lead to
unauthorized access, manipulation of cluster resources, lateral movement and/or privilege escalation.
"""
index = ["logs-kubernetes.audit_logs-*"]
language = "eql"
license = "Elastic License v2"
name = "Kubernetes Forbidden Creation Request"
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 Kubernetes Forbidden Creation Request

Kubernetes, a container orchestration platform, manages applications across clusters. It uses authorization policies to control resource creation. Adversaries may exploit misconfigurations or attempt unauthorized resource creation to gain access or escalate privileges. The detection rule identifies denied creation requests, signaling potential unauthorized attempts, by analyzing audit logs for forbidden decisions, aiding in threat detection and response.

### Possible investigation steps

- Review the audit logs to identify the user or service account associated with the forbidden creation request by examining the `kubernetes.audit.user.username` field.
- Check the `kubernetes.audit.objectRef.resource` field to determine which specific resource type the unauthorized creation attempt was targeting.
- Investigate the `kubernetes.audit.sourceIPs` field to trace the source IP address of the request, which may help identify the origin of the unauthorized attempt.
- Analyze the `kubernetes.audit.annotations.authorization_k8s_io/reason` field, if available, to understand why the request was forbidden, providing insights into potential misconfigurations or policy violations.
- Cross-reference the user or service account with existing role bindings and cluster role bindings to verify if there are any misconfigurations or missing permissions that could have led to the forbidden request.
- Review recent changes in the cluster's authorization policies or role assignments that might have inadvertently affected permissions, leading to the denied request.
- Consider correlating this event with other security alerts or logs to identify patterns or repeated unauthorized attempts, which could indicate a broader attack strategy.

### False positive analysis

- Service accounts with limited permissions may trigger false positives when attempting to create resources they are not authorized for. Review service account roles and permissions to ensure they align with intended access levels.
- Automated processes or scripts that attempt resource creation without proper permissions can result in false positives. Identify and adjust these processes to ensure they operate within their designated permissions.
- Developers testing new configurations or deployments might inadvertently cause forbidden creation requests. Implement a separate testing environment with appropriate permissions to minimize false positives in production.
- Changes in authorization policies can lead to temporary false positives as users adjust to new permissions. Communicate policy changes effectively and provide guidance on necessary adjustments to avoid unnecessary alerts.
- Regularly scheduled tasks or cron jobs that attempt resource creation without updated permissions can trigger false positives. Review and update these tasks to ensure they have the necessary access rights.

### Response and remediation

- Immediately isolate the affected Kubernetes cluster to prevent further unauthorized access or resource manipulation. This can be done by restricting network access or applying stricter firewall rules temporarily.
- Identify and revoke any unauthorized or suspicious service accounts or user credentials that attempted the forbidden creation request. Ensure that these accounts are disabled or have their permissions reduced to prevent further misuse.
- Review and update the Kubernetes Role-Based Access Control (RBAC) policies to ensure that only authorized users and service accounts have the necessary permissions to create resources. This includes verifying that least privilege principles are applied.
- Conduct a thorough audit of recent Kubernetes audit logs to identify any other unauthorized access attempts or suspicious activities that may have occurred around the same time as the detected alert.
- Escalate the incident to the security operations team for further investigation and to determine if there is a broader security incident or breach. Provide them with all relevant logs and findings.
- Implement additional monitoring and alerting for similar unauthorized creation attempts in the future. This can include setting up alerts for any "forbid" decisions in the audit logs to ensure rapid detection and response.
- Consider deploying additional security tools or services, such as intrusion detection systems or anomaly detection solutions, to enhance the security posture of the Kubernetes environment and prevent similar threats.
"""
risk_score = 47
rule_id = "ec81962e-4bc8-48e6-bfb0-545fc97d8f6a"
severity = "medium"
tags = [
    "Data Source: Kubernetes",
    "Domain: Kubernetes",
    "Use Case: Threat Detection",
    "Tactic: Execution",
    "Resources: Investigation Guide"
    ]
timestamp_override = "event.ingested"
type = "eql"
query = '''
any where data_stream.dataset == "kubernetes.audit_logs" and kubernetes.audit.verb == "create" and
kubernetes.audit.stage == "ResponseComplete" and `kubernetes.audit.annotations.authorization_k8s_io/decision` == "forbid"
'''

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

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

[metadata]
creation_date = "2022/01/13"
integration = ["o365"]
maturity = "production"
updated_date = "2026/04/10"

[rule]
author = ["Elastic"]
description = """
Detects the occurrence of mailbox audit bypass associations. The mailbox audit is responsible for logging specified
mailbox events (like accessing a folder or a message or permanently deleting a message). However, actions taken by some
authorized accounts, such as accounts used by third-party tools or accounts used for lawful monitoring, can create a
large number of mailbox audit log entries and may not be of interest to your organization. Because of this,
administrators can create bypass associations, allowing certain accounts to perform their tasks without being logged.
Attackers can abuse this allowlist mechanism to conceal actions taken, as the mailbox audit will log no activity done by
the account.
"""
false_positives = ["Legitimate allowlisting of noisy accounts"]
from = "now-9m"
index = ["logs-o365.audit-*", "filebeat-*"]
language = "kuery"
license = "Elastic License v2"
name = "M365 Exchange Mailbox Audit Logging Bypass Added"
note = """## Triage and analysis

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

### Investigating M365 Exchange Mailbox Audit Logging Bypass Added

In Microsoft 365 environments, mailbox audit logging is crucial for tracking user activities like accessing or deleting emails. However, administrators can exempt certain accounts from logging to reduce noise, which attackers might exploit to hide their actions. The detection rule identifies successful attempts to create such exemptions, signaling potential misuse of this bypass mechanism.

### Possible investigation steps

- Review the event logs for entries with event.dataset set to o365.audit and event.provider set to Exchange to confirm the presence of the Set-MailboxAuditBypassAssociation action.
- Identify the account associated with the event.action Set-MailboxAuditBypassAssociation and verify if it is a known and authorized account for creating audit bypass associations.
- Check the event.outcome field to ensure the action was successful and determine if there are any other related unsuccessful attempts that might indicate trial and error by an attacker.
- Investigate the history of the account involved in the bypass association to identify any unusual or suspicious activities, such as recent changes in permissions or unexpected login locations.
- Cross-reference the account with any known third-party tools or lawful monitoring accounts to determine if the bypass is legitimate or potentially malicious.
- Assess the risk and impact of the bypass by evaluating the types of activities that would no longer be logged for the account in question, considering the organization's security policies and compliance requirements.

### False positive analysis

- Authorized third-party tools may generate a high volume of mailbox audit log entries, leading to bypass associations being set. Review and document these tools to ensure they are legitimate and necessary for business operations.
- Accounts used for lawful monitoring might be exempted from logging to reduce noise. Verify that these accounts are properly documented and that their activities align with organizational policies.
- Regularly review the list of accounts with bypass associations to ensure that only necessary and approved accounts are included. Remove any accounts that no longer require exemptions.
- Implement a process for periodically auditing bypass associations to detect any unauthorized changes or additions, ensuring that only intended accounts are exempted from logging.
- Consider setting up alerts for any new bypass associations to quickly identify and investigate potential misuse or unauthorized changes.

### Response and remediation

- Immediately isolate the account associated with the successful Set-MailboxAuditBypassAssociation event to prevent further unauthorized actions.
- Review and revoke any unauthorized mailbox audit bypass associations to ensure all relevant activities are logged.
- Conduct a thorough audit of recent activities performed by the affected account to identify any suspicious or malicious actions that may have been concealed.
- Reset credentials for the compromised account and any other accounts that may have been affected to prevent further unauthorized access.
- Notify the security team and relevant stakeholders about the incident for awareness and further investigation.
- Implement additional monitoring for similar bypass attempts to enhance detection capabilities and prevent recurrence.
- Consider escalating the incident to a higher security tier or external cybersecurity experts if the scope of the breach is extensive or if internal resources are insufficient to handle the threat.

## Setup

The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
references = ["https://twitter.com/misconfig/status/1476144066807140355"]
risk_score = 47
rule_id = "675239ea-c1bc-4467-a6d3-b9e2cc7f676d"
severity = "medium"
tags = ["Domain: Cloud", "Data Source: Microsoft 365", "Tactic: Initial Access", "Tactic: Defense Evasion", "Resources: Investigation Guide"]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:o365.audit and event.provider:Exchange and event.action:Set-MailboxAuditBypassAssociation and event.outcome:success
'''


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

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

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

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

[[rule.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 = "2020/12/21"
integration = ["endpoint", "windows", "system"]
maturity = "production"
updated_date = "2025/03/20"

[rule]
author = ["Elastic"]
description = """
Identifies the execution of a Chromium based browser with the debugging process argument, which may indicate an attempt
to steal authentication cookies. An adversary may steal web application or service session cookies and use them to gain
access web applications or Internet services as an authenticated user without needing credentials.
"""
false_positives = ["Developers performing browsers plugin or extension debugging."]
from = "now-9m"
index = [
    "auditbeat-*",
    "logs-endpoint.events.*",
    "logs-system.security*",
    "logs-windows.forwarded*",
    "logs-windows.sysmon_operational-*",
    "winlogbeat-*",
]
language = "eql"
license = "Elastic License v2"
max_signals = 33
name = "Potential Cookies Theft via Browser Debugging"
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 Cookies Theft via Browser Debugging

Chromium-based browsers support debugging features that allow developers to inspect and modify web applications. Adversaries can exploit these features to access session cookies, enabling unauthorized access to web services. The detection rule identifies suspicious browser processes using debugging arguments, which may indicate cookie theft attempts, by monitoring specific process names and arguments across different operating systems.

### Possible investigation steps

- Review the process details to confirm the presence of suspicious debugging arguments such as "--remote-debugging-port=*", "--remote-debugging-targets=*", or "--remote-debugging-pipe=*". Check if these arguments were used in conjunction with "--user-data-dir=*" and ensure "--remote-debugging-port=0" is not present.
- Identify the user account associated with the suspicious browser process to determine if it aligns with expected behavior or if it might be compromised.
- Investigate the source IP address and network activity associated with the process to identify any unusual or unauthorized access patterns.
- Check for any recent changes or anomalies in the user's account activity, such as unexpected logins or access to sensitive applications.
- Correlate the event with other security alerts or logs to identify if this activity is part of a broader attack pattern or campaign.
- If possible, capture and analyze the network traffic associated with the process to detect any data exfiltration attempts or communication with known malicious IP addresses.

### False positive analysis

- Development and testing activities may trigger the rule when developers use debugging features for legitimate purposes. To manage this, create exceptions for known developer machines or user accounts frequently involved in web application development.
- Automated testing frameworks that utilize browser debugging for testing web applications can also cause false positives. Identify and exclude processes initiated by these frameworks by specifying their unique process names or user accounts.
- Browser extensions or tools that rely on debugging ports for functionality might be flagged. Review and whitelist these extensions or tools if they are verified as safe and necessary for business operations.
- Remote support or troubleshooting sessions using debugging features can be mistaken for suspicious activity. Implement a policy to log and review such sessions, allowing exceptions for recognized support tools or personnel.
- Continuous integration/continuous deployment (CI/CD) pipelines that involve browser automation may inadvertently match the rule criteria. Exclude these processes by identifying and filtering based on the CI/CD system's user accounts or process identifiers.

### Response and remediation

- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
- Terminate any suspicious browser processes identified with debugging arguments to stop potential cookie theft in progress.
- Conduct a thorough review of access logs for the affected web applications or services to identify any unauthorized access attempts using stolen cookies.
- Invalidate all active sessions for the affected user accounts and force a re-authentication to ensure that any stolen session cookies are rendered useless.
- Implement stricter browser security policies, such as disabling remote debugging features in production environments, to prevent similar exploitation in the future.
- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data have been compromised.
- Enhance monitoring and alerting for similar suspicious browser activities by refining detection rules and incorporating additional threat intelligence."""
references = [
    "https://github.com/defaultnamehere/cookie_crimes",
    "https://embracethered.com/blog/posts/2020/cookie-crimes-on-mirosoft-edge/",
    "https://github.com/rapid7/metasploit-framework/blob/master/documentation/modules/post/multi/gather/chrome_cookies.md",
    "https://posts.specterops.io/hands-in-the-cookie-jar-dumping-cookies-with-chromiums-remote-debugger-port-34c4f468844e",
]
risk_score = 47
rule_id = "027ff9ea-85e7-42e3-99d2-bbb7069e02eb"
severity = "medium"
tags = [
    "Domain: Endpoint",
    "OS: Linux",
    "OS: Windows",
    "OS: macOS",
    "Use Case: Threat Detection",
    "Tactic: Credential Access",
    "Data Source: Elastic Defend",
    "Resources: Investigation Guide",
    "Data Source: Windows Security Event Logs",
    "Data Source: Sysmon",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
process where event.type in ("start", "process_started", "info") and
  process.name in (
             "Microsoft Edge",
             "chrome.exe",
             "Google Chrome",
             "google-chrome-stable",
             "google-chrome-beta",
             "google-chrome",
             "msedge.exe") and
   process.args : ("--remote-debugging-port=*",
                   "--remote-debugging-targets=*",
                   "--remote-debugging-pipe=*") and
   process.args : "--user-data-dir=*" and not process.args:"--remote-debugging-port=0"
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1539"
name = "Steal Web Session Cookie"
reference = "https://attack.mitre.org/techniques/T1539/"


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

[rule]
description = """
Identifies the creation of a process where the creating thread's stack contains frames pointing outside any known
executable image and using commonly used Windows APIs like WinExec. This is a common pattern for code injection using
default offensive shellcode templates.
"""
id = "58b996a5-634c-4205-9ffa-a6f2b8ebc1ad"
license = "Elastic License v2"
name = "Potential Process Creation via ShellCode"
os_list = ["windows"]
reference = [
    "https://www.elastic.co/security-labs/upping-the-ante-detecting-in-memory-threats-with-kernel-call-stacks",
]
version = "1.0.20"

query = '''
process where event.action == "start" and

process.parent.thread.Ext.call_stack_contains_unbacked == true and

 (process.parent.thread.Ext.call_stack_summary : "*kernel32.dll|Unbacked*" and
  _arraysearch(process.parent.thread.Ext.call_stack, $entry, $entry.symbol_info : "*kernel32.dll!WinExec*")) and

not (process.code_signature.trusted == true and
     process.code_signature.subject_name : ("GIGA-BYTE TECHNOLOGY CO., LTD.", "Intuit Inc", "Ramsauer und Stuermer Software GmbH",
     "Aptean, Inc.", "MICRO-STAR INTERNATIONAL CO., LTD.")) and

not (process.executable : "C:\\Windows\\System32\\sc.exe" and process.parent.executable : "C:\\Windows\\System32\\svchost.exe" and
     process.command_line : "sc start LenovoPcManagerService") and
not process.executable :
                ("C:\\Program Files (x86)\\Ponds33\\Refined Method\\Main.exe",
                 "C:\\Program Files (x86)\\Ponds33\\Underdrain\\UDMain.exe",
                 "C:\\Program Files (x86)\\Ponds33\\NPCalc\\NPCalcMain.exe")
'''

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 = "T1055"
name = "Process Injection"
reference = "https://attack.mitre.org/techniques/T1055/"


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

[internal]
min_endpoint_version = "8.8.0"

[metadata]
creation_date = "2023/07/26"
integration = ["endpoint"]
maturity = "production"
updated_date = "2026/07/17"

[rule]
author = ["Elastic"]
description = """
Identifies the creation of a sudo binary located at /usr/bin/sudo. Attackers may hijack the default sudo binary and
replace it with a custom binary or script that can read the user's password in clear text to escalate privileges or
enable persistence onto the system every time the sudo binary is executed.
"""
from = "now-9m"
index = ["logs-endpoint.events.file*"]
language = "eql"
license = "Elastic License v2"
name = "Potential Sudo Hijacking"
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 Sudo Hijacking

Sudo is a critical utility in Linux environments, allowing users to execute commands with elevated privileges. Adversaries may exploit this by replacing the sudo binary with a malicious version to capture passwords or maintain persistence. The detection rule identifies suspicious creation or renaming of the sudo binary, excluding legitimate package management processes, to flag potential hijacking attempts.

### Possible investigation steps

- Review the file creation or rename event details to confirm the file path is either /usr/bin/sudo or /bin/sudo, as these are critical locations for the sudo binary.
- Check the process executable that triggered the event to ensure it is not part of the legitimate package management processes listed in the query, such as /bin/dpkg or /usr/bin/yum.
- Investigate the user account associated with the event to determine if the activity aligns with their typical behavior or if it appears suspicious.
- Examine the system logs around the time of the event for any unusual activity or errors that might indicate tampering or unauthorized access.
- Verify the integrity of the current sudo binary by comparing its hash with a known good version to detect any unauthorized modifications.
- Assess the system for any additional signs of compromise, such as unexpected network connections or new user accounts, which may indicate broader malicious activity.

### False positive analysis

- Package management processes can trigger false positives when legitimate updates or installations occur. To handle this, ensure that processes like dpkg, rpm, yum, and apt are included in the exclusion list as they are common package managers.
- Custom scripts or automation tools that modify the sudo binary for legitimate reasons may cause alerts. Review these scripts and consider adding their paths to the exclusion list if they are verified as safe.
- Temporary files or directories used during legitimate software installations or updates, such as those in /var/lib/dpkg or /tmp, can lead to false positives. Exclude these paths if they are part of a known and safe process.
- Development or testing environments where sudo binaries are frequently modified for testing purposes might trigger alerts. In such cases, consider excluding these environments from monitoring or adding specific exclusions for known safe modifications.
- Ensure that any process or executable that is known to interact with the sudo binary in a non-malicious way is added to the exclusion list to prevent unnecessary alerts.

### Response and remediation

- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the attacker.
- Verify the integrity of the sudo binary by comparing its hash with a known good version from a trusted source. If compromised, replace it with the legitimate binary.
- Conduct a thorough review of system logs and the process execution history to identify any unauthorized changes or suspicious activities related to the sudo binary.
- Reset passwords for all user accounts on the affected system, especially those with elevated privileges, to mitigate potential credential theft.
- Implement additional monitoring on the affected system and similar environments to detect any further attempts to modify critical binaries or escalate privileges.
- Escalate the incident to the security operations team for a comprehensive investigation and to determine if other systems may be affected.
- Review and update access controls and permissions to ensure that only authorized personnel can modify critical system binaries."""
references = [
    "https://eapolsniper.github.io/2020/08/17/Sudo-Hijacking/",
    "https://www.elastic.co/security-labs/sequel-on-persistence-mechanisms",
]
risk_score = 47
rule_id = "88fdcb8c-60e5-46ee-9206-2663adf1b1ce"
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: Persistence",
    "Data Source: Elastic Defend",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
file where host.os.type == "linux" and event.action in ("creation", "rename") and
file.path in ("/usr/bin/sudo", "/bin/sudo") and not (
  process.name like ("python*", "platform-python*") or
  file.Ext.original.path in ("/usr/bin/sudo", "/bin/sudo") or
  process.executable in (
    "/bin/dpkg", "/usr/bin/dpkg", "/bin/dockerd", "/usr/bin/dockerd", "/usr/sbin/dockerd", "/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", "/usr/bin/microdnf", "/usr/local/bin/dockerd", "/usr/local/bin/podman", "/usr/local/bin/dnf",
    "/kaniko/executor", "/proc/self/exe", "/usr/bin/apt-get", "/usr/bin/apt-cache", "/usr/bin/apt-mark",
    "./usr/bin/podman", "./usr/lib/snapd/snap-update-ns", "/kaniko/kaniko-executor", "/usr/libexec/packagekitd",
    "/usr/bin/dnf5", "/usr/lib/pamac/pamac-daemon", "./usr/libexec/snapd/snap-update-ns", "/usr/bin/update-alternatives",
    "/var/ossec/bin/wazuh-syscheckd", "/usr/local/bin/defender", "/usr/sbin/dnf", "/usr/local/bin/starship", "/bin/dnf4",
    "/usr/sbin/yum-cron", "/bin/buildah", "/usr/bin/buildah"
  ) or
  file.Ext.original.extension == "dpkg-new" or
  file.Ext.original.name like "sudo;*" or
  process.executable : (
    "/nix/store/*", "/var/lib/dpkg/*", "/tmp/vmis.*", "/snap/*", "/dev/fd/*", "/var/lib/docker/*",
    "./snap/snapd/*/usr/lib/snapd/snap-update-ns", "/opt/docker/overlay2/*/dockerd", 
    "/var/lib/containers/storage/overlay/*/dockerd", "/usr/libexec/platform-python*"
  ) or
  process.executable == null or
  (process.name == "sed" and file.name : "sed*")
)
'''

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

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

[[rule.threat.technique.subtechnique]]
id = "T1548.003"
name = "Sudo and Sudo Caching"
reference = "https://attack.mitre.org/techniques/T1548/003/"

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

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

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

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

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

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

[[rule.threat.technique]]
id = "T1056"
name = "Input Capture"
reference = "https://attack.mitre.org/techniques/T1056/"

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