Elastic rules: 2f

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

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

### Investigating Attempt to Modify an Okta Policy

Modifications to Okta policies may indicate attempts to weaken an organization's security controls. If such an attempt is detected, consider the following steps for investigation.

#### Possible investigation steps:
- Identify the actor associated with the event. Check the fields `okta.actor.id`, `okta.actor.type`, `okta.actor.alternate_id`, and `okta.actor.display_name`.
- Determine the client used by the actor. You can look at `okta.client.device`, `okta.client.ip`, `okta.client.user_agent.raw_user_agent`, `okta.client.ip_chain.ip`, and `okta.client.geographical_context`.
- Check the nature of the policy modification. You can review the `okta.target` field, especially `okta.target.display_name` and `okta.target.id`.
- Examine the `okta.outcome.result` and `okta.outcome.reason` fields to understand the outcome of the modification attempt.
- Check if there have been other similar modification attempts in a short time span from the same actor or IP address.

### False positive analysis:
- This alert might be a false positive if Okta policies are regularly updated in your organization as a part of normal operations.
- Check if the actor associated with the event has legitimate rights to modify the Okta policies.
- Verify the actor's geographical location and the time of the modification attempt. If these align with the actor's regular behavior, it could be a false positive.

### Response and remediation:
- If unauthorized modification is confirmed, initiate the incident response process.
- Lock the actor's account and enforce password change as an immediate response.
- Reset MFA tokens for the actor and enforce re-enrollment, if applicable.
- Review any other actions taken by the actor to assess the overall impact.
- If the attack was facilitated by a particular technique, ensure your systems are patched or configured to prevent such techniques.
- Consider a security review of your Okta policies and rules to ensure they follow security best practices.

## Setup

The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
references = [
    "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 = "6731fbf2-8f28-49ed-9ab9-9a918ceb5a45"
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.update
'''


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

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

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

[[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 attempts to load the BindFltApi module by an unusual process. This may indicate the presence of folder
redirection functionality using the bind link feature of Windows.
"""
id = "167be4b9-c953-4610-860e-4c5cde709683"
license = "Elastic License v2"
name = "BindFltApi Loaded by an Unusual Process"
os_list = ["windows"]
reference = [
    "https://www.zerosalarium.com/2025/10/DR-Redir-Break-EDR-Via-BindLink-Cloud-Filter.html",
    "https://learn.microsoft.com/en-us/windows/win32/bindlink/",
]
version = "1.0.3"

query = '''
library where (dll.name : ("bindfltapi.dll", "bindflt.dll") or dll.pe.original_file_name in ("BindFltApi.dll", "BindFlt.dll")) and
 user.id != null and process.executable != null and process.thread.Ext.call_stack_summary != null and 
 not (user.id == "S-1-5-18" and
      process.code_signature.subject_name in ("Microsoft Windows", "Microsoft Windows Publisher", "Microsoft Corporation", "Beijing Qihu Technology Co., Ltd.") and
      process.code_signature.trusted == true)
'''

min_endpoint_version = "8.10.0"
optional_actions = []
[[actions]]
action = "kill_process"
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.tactic]
id = "TA0005"
name = "Defense Evasion"
reference = "https://attack.mitre.org/tactics/TA0005/"

[internal]
min_endpoint_version = "8.10.0"

[rule]
description = """
Identifies when a Windows scripting utility or a program running from a world writable directory attempts to connect to
a suspicious URL. This behavior may indicate the presence of a malware command and control activity.
"""
id = "a6befb1f-b1d8-4e64-80fb-fca43cdcee98"
license = "Elastic License v2"
name = "Connection to a Suspicious URL"
os_list = ["windows"]
reference = ["https://attack.mitre.org/techniques/T1071/"]
version = "1.0.4"

query = '''
api where process.Ext.api.name in ("InternetOpenURL", "WinHttpOpenRequest") and
 (
  process.name : ("wscript.exe", "mshta.exe", "powershell.exe") or
  (process.executable : ("?:\\ProgramData\\*", "?:\\Users\\*\\AppData\\*", "?:\\Users\\Public\\*", "?:\\Users\\Downloads\\*") and
   process.code_signature.trusted != true)
 ) and
 url.full : ("http*.php", "http*.php/*", "http*.php\\*", "http*/wp-content/*", "http*\\wp-content\\*") and
 not url.full : ("https://zeek.org/wp-content/*", "https://*.wp.com/*", "http://stat.eliang.com/cstat.php", "http*.foxitservice.com/*")
'''

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

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


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

[internal]
min_endpoint_version = "9.2.0"

[metadata]
creation_date = "2026/06/29"
integration = ["azure"]
maturity = "production"
updated_date = "2026/06/29"

[rule]
author = ["Elastic"]
description = """
Identifies a Microsoft Entra ID identity-compromise chain in which a single user, within a 10-minute window,
authenticates to the Device Registration Service through the Microsoft Authentication Broker (MAB) client, registers a
device, and then uses the resulting Primary Refresh Token (PRT) to access a resource other than the Device Registration
Service. This sequence is the core post-adversary-in-the-middle (AiTM) persistence pattern used by phishing kits such as
Tycoon2FA and Kali365: after capturing a victim session, the kit registers an Azure AD-joined device to obtain a
device-bound PRT, which survives user-level session revocation and password resets and grants trusted, MFA-free access.
Correlating the broker sign-in, the device-registration audit event, and the follow-on PRT sign-in for the same user
within a short window is a high-fidelity indicator of active account takeover.
"""
false_positives = [
    """
    Legitimate device onboarding (for example a user enrolling a new corporate device through Azure AD join) can produce
    a broker authentication to the Device Registration Service followed by PRT issuance. Validate that the device,
    source IP/ASN, and user agent are expected, and that the device is managed/compliant.
    """,
    """
    Authorized red team or penetration testing engagements that register devices and exercise PRTs will match this
    sequence. Document the engagement and add scoped exceptions for the involved principals or source addresses.
    """,
]
from = "now-15m"
index = ["logs-azure.signinlogs-*", "logs-azure.auditlogs-*"]
language = "eql"
license = "Elastic License v2"
name = "Entra ID AiTM Phishing-Kit Chain Detected"
note = """## Triage and analysis

### Investigating Entra ID AiTM Phishing-Kit Chain Detected

This rule correlates three events for the same user within a 10-minute window that together represent the canonical post-AiTM identity-compromise chain:

1. A non-interactive sign-in through the Microsoft Authentication Broker (MAB) client (`app_id` `29d9ed98-a469-4536-ade2-f981bc1d605e`) to the `Device Registration Service` resource, with an `unbound` session token (`token_protection_status_details.sign_in_session_status`).
2. A successful `Register device` audit event initiated by the same user for a target device named `DESKTOP-*`.
3. An interactive sign-in using a `primaryRefreshToken` (PRT) to a resource other than the Device Registration Service, from an unmanaged device.

After an AiTM kit captures a victim session, it registers an Azure AD-joined device to obtain a device-bound PRT. Because the PRT is bound to the device rather than the user session, it survives `revokeSignInSessions` and password resets, providing durable, MFA-free access. Observing the broker-to-DRS auth, the registration, and the first PRT use in quick succession is strong evidence of active account takeover rather than benign onboarding.

### Possible investigation steps

- Identify the user via `azure.signinlogs.properties.user_principal_name` / `azure.signinlogs.properties.user_id` and the registered device via the `Register device` event (`azure.auditlogs.properties.target_resources.0.display_name`). Default `DESKTOP-<random>` names that do not match your convention are suspicious.
- Review the source of each step: `source.ip`, `source.as.organization.name`, and `source.geo.*`. Hosting/VPS ASNs (for example Tencent or Alibaba) and unexpected geographies, or a single source driving all three steps, are high-fidelity suspicious.
- Inspect the registration user agent on the `Register device` event (`azure.auditlogs.properties.userAgent`); a spoofed `Dsreg/10.0 (Windows <build>)` string or a raw HTTP client such as `axios/*` or `python-requests/*` indicates tooling.
- Confirm the PRT step: `azure.signinlogs.properties.incoming_token_type` is `primaryRefreshToken`, the device `trust_type` is `Azure AD joined`, and `device_detail.is_managed` is false (unmanaged), and the `resource_display_name` is a real resource (Microsoft Graph, Office 365 Exchange Online, etc.) rather than the Device Registration Service.
- Check for additional persistence established in the same window: an attacker-registered MFA method (`User registered security info`), multiple device registrations by the same user, or broker tokens minted for other resources.
- Review Conditional Access outcomes to determine whether device compliance or MFA was bypassed.

### False positive analysis

- Legitimate Azure AD join / device onboarding can produce a broker-to-DRS auth followed by PRT issuance. Validate the device against inventory and confirm it is managed/compliant and registered from an expected source.
- Authorized security assessments that register devices and exercise PRTs will match. Document and add scoped exceptions.

### Response and remediation

- Treat as likely account takeover. Remove the rogue device registration BEFORE revoking sessions, because device-bound PRTs survive `revokeSignInSessions` and a device left in place re-establishes access.
    - `GET /v1.0/users/{id}/registeredDevices` and `/ownedDevices`, then `DELETE /v1.0/devices/{deviceObjectId}` for unrecognized devices.
- Revoke refresh tokens and sessions, then reset credentials and re-register MFA.
    - `POST /v1.0/users/{id}/revokeSignInSessions`.
- Temporarily disable the account if activity must be halted during investigation.
    - `PATCH /v1.0/users/{id}` with body `{"accountEnabled": false}`.
- Remove other attacker persistence: attacker-registered MFA methods, malicious inbox/forwarding rules, and OAuth consents.
- Tighten device registration and join controls via Conditional Access (restrict who can register/join devices, require MFA for registration, and require a compliant/managed device for resource access).
"""
references = [
    "https://any.run/malware-trends/tycoon/",
    "https://www.huntress.com/blog/kali365-device-code-phishing-kit",
    "https://any.run/malware-trends/kali365/",
    "https://arcticwolf.com/resources/blog/token-bingo-dont-let-your-code-be-the-winner/",
    "https://www.elastic.co/security-labs/tycoon-2fa-aitm-detection-engineering"
]
risk_score = 73
rule_id = "d2c02b2b-bd01-4d4a-a17a-8df8f357b015"
severity = "high"
tags = [
    "Domain: Cloud",
    "Domain: Identity",
    "Data Source: Azure",
    "Data Source: Microsoft Entra ID",
    "Data Source: Microsoft Entra ID Sign-In Logs",
    "Data Source: Microsoft Entra ID Audit Logs",
    "Use Case: Identity and Access Audit",
    "Use Case: Threat Detection",
    "Tactic: Persistence",
    "Tactic: Credential Access",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
sequence with maxspan=3m
  [authentication where
    data_stream.dataset == "azure.signinlogs" and
    azure.signinlogs.category == "NonInteractiveUserSignInLogs" and
    azure.signinlogs.properties.app_id == "29d9ed98-a469-4536-ade2-f981bc1d605e" and
    azure.signinlogs.properties.resource_display_name == "Device Registration Service" and
    azure.signinlogs.properties.incoming_token_type == "refreshToken" and
    azure.signinlogs.properties.token_protection_status_details.sign_in_session_status == "unbound" and
    azure.signinlogs.properties.user_type == "Member" and
    azure.signinlogs.result_signature == "SUCCESS"
  ] by azure.signinlogs.properties.user_id
  [any where
    data_stream.dataset == "azure.auditlogs" and
    azure.auditlogs.operation_name == "Register device" and
    azure.auditlogs.properties.initiated_by.user.id != null and
    azure.auditlogs.properties.target_resources.`0`.display_name like "DESKTOP-*" and
    event.outcome == "success"
  ] by azure.auditlogs.properties.initiated_by.user.id
  [authentication where
    data_stream.dataset == "azure.signinlogs" and
    azure.signinlogs.properties.incoming_token_type == "primaryRefreshToken" and
    azure.signinlogs.properties.original_transfer_method == "deviceCodeFlow" and
    azure.signinlogs.properties.is_interactive == true and
    azure.signinlogs.properties.resource_display_name != "Device Registration Service" and
    azure.signinlogs.properties.device_detail.is_managed != true and
    azure.signinlogs.result_signature == "SUCCESS"
  ] by azure.signinlogs.properties.user_id
'''


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


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



[rule.threat.tactic]
id = "TA0003"
name = "Persistence"
reference = "https://attack.mitre.org/tactics/TA0003/"
[[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.tactic]
id = "TA0005"
name = "Defense Evasion"
reference = "https://attack.mitre.org/tactics/TA0005/"
[[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.investigation_fields]
field_names = [
    "@timestamp",
    "azure.signinlogs.properties.user_principal_name",
    "azure.signinlogs.properties.user_id",
    "azure.signinlogs.properties.app_id",
    "azure.signinlogs.properties.resource_display_name",
    "azure.signinlogs.properties.incoming_token_type",
    "azure.signinlogs.properties.device_detail.trust_type",
    "azure.signinlogs.properties.device_detail.is_managed",
    "azure.auditlogs.operation_name",
    "azure.auditlogs.properties.target_resources.0.display_name",
    "source.ip",
    "source.as.organization.name",
    "source.geo.country_name",
]

[metadata]
creation_date = "2026/08/28"
integration = ["azure"]
maturity = "production"
updated_date = "2026/08/28"

[rule]
author = ["Elastic"]
description = """
Detects a first-party FOCI tooling client (Azure CLI, PowerShell, VS Code, Graph CLI, Azure AD PowerShell, or Visual
Studio) redeeming a device-bound Primary Refresh Token (PRT) for Microsoft Graph, SharePoint/OneDrive, or Exchange
Online from a source IP that has not been seen with that deviceid. Replay events are limited to compliant or
Intune-managed devices. Adversaries who steal a WAM PRT SSO cookie replay it off-box; the token keeps the workstation
deviceid, so this pair is new even when Windows Sign-In for that device is outside a correlation window.
"""
false_positives = [
    """
    A user who runs Azure CLI, Azure PowerShell, VS Code, Graph CLI, or Visual Studio from a new egress (VPN, hotel,
    Cloud Shell, jump host) while WAM still attaches a compliant or managed workstation deviceid will match on first
    sight of that IP. Exception: add known developer and Cloud Shell ranges after confirming the client ran there.
    """,
    """
    Split-tunnel or dual-homed devices can present a new Microsoft 365 egress for tooling clients. Confirm the IP
    belongs to the enrolled device before treating the event as cookie theft.
    """,
    """
    Microsoft Teams, Office, OneDrive SyncEngine, Authentication Broker, Outlook Mobile, Bing, Azure Portal, and Office
    365 Management are omitted because first sight of a mobile or M365 egress IP for those clients is routine.
    """,
]
from = "now-9m"
index = ["filebeat-*", "logs-azure.signinlogs-*"]
language = "kuery"
license = "Elastic License v2"
name = "Entra ID Device-Bound PRT from Unusual Device IP"
note = """## Triage and analysis

### Investigating Entra ID Device-Bound PRT from Unusual Device IP

This rule fires when a tooling FOCI client redeems a device-bound PRT from a `source.ip` that has not appeared with that `device_id` in the prior 5 days. Unlike **Entra ID Device-Bound PRT Replay via First-Party App from Unusual IP**, it does not need a Windows Sign-In or WAM event in the same window — so a workstation that last signed in yesterday still alerts when the cookie is redeemed from a new address.

PRTremote and similar harvest tools steal a WAM PRT SSO cookie and POST it from attacker infrastructure. The issued token keeps the *workstation* deviceid, so Conditional Access that requires a compliant device can succeed. Replay events must be `is_compliant` or `is_managed`. The stolen cookie nonce is typically valid for about five minutes; that is the attacker’s redeem window, not this rule’s history.

This is not ConsentFix / OAuth-code phishing. Those flows show `OAuth2:Authorize` with `Redirect` and often lack a bound compliant device.

### Possible investigation steps

- Review `azure.signinlogs.properties.user_principal_name`, `azure.signinlogs.properties.device_detail.device_id`, `azure.signinlogs.properties.device_detail.display_name`, and `source.ip`. Confirm `incoming_token_type` is `primaryRefreshToken` and `device_detail.is_compliant` / `is_managed` are true.
- Compare `azure.signinlogs.properties.app_display_name` and `user_agent.original` with the resource (`resource_display_name`). A cookie POST through WAM can show a Trident/MSIE user agent on the Azure CLI client ID; that is the same IE stack legitimate Windows `az login` uses when it brokers through WAM, so it is triage context, not a detection key. TokenTactics commonly presents as Microsoft Office (that client is omitted here; hunt it separately if harvest is already confirmed).
- Hunt prior Windows Sign-In / `Windows-AzureAD-Authentication-Provider/1.0` events for the same deviceid. If those IPs differ from `source.ip`, treat this as the same story as the ES|QL companion. A Microsoft-owned ASN (including 8075) does not clear the alert.
- Hunt endpoint telemetry for the same user or device display name as `host.name`: InteractiveToken scheduled tasks, `svchost.exe` (Schedule) → `cmd.exe` → `BrowserCore.exe`, or files `formatted_nonce.txt` / `prt_cookie.txt`.
- Review Graph, SharePoint, and mailbox activity after the sign-in for directory, file, or mail enumeration.

### False positive analysis

- Developers who run Azure CLI, Graph CLI, or VS Code from a new network while WAM still attaches the workstation deviceid. Exception known Cloud Shell / jump-host IPs after confirming the client actually ran there.
- First use of a tooling client on a new device, or the first time a laptop appears on a new ISP, will fire once per `(device_id, source.ip)` pair and then age out of novelty.
- Hybrid-joined workstations that report both `is_compliant` and `is_managed` as false (no Intune) will not match. Hunt those deviceids separately if harvest is already confirmed.
- Microsoft Teams, Office, OneDrive SyncEngine, Authentication Broker, Outlook Mobile, Bing, Azure Portal, and Office 365 Management are excluded. Do not treat their absence as a miss.

### Response and remediation

- Contact the user to confirm whether they ran the first-party client from `source.ip`.
- If unauthorized, revoke refresh tokens and primary refresh tokens for the user. The deviceid on the token is often the *legitimate* workstation — do not delete that device as if it were a ROADtx registration until you confirm otherwise.
- Isolate the workstation, hunt for InteractiveToken scheduled tasks and BrowserCore harvest, and treat the admin identity that registered the task as a second compromised principal.
"""
references = [
    "https://www.armadin.com/blog-posts/prtremote-extract-prt-cookies-remotely-with-interactivetoken-scheduled-task",
    "https://github.com/armadin-public/PRTremote",
    "https://github.com/dmcxblue/ANIMO/blob/master/helpers/scripts/GrabTokenAzureAD/PrtExtractor.cs",
    "https://github.com/rvrsh3ll/TokenTactics",
    "https://github.com/Gerenios/AADInternals",
]
risk_score = 73
rule_id = "9e8d9bb5-6d3a-4431-a0d0-8d0475e726a4"
setup = """The Azure Fleet integration (or Filebeat Azure module) with Microsoft Entra ID sign-in logs is required. Ingest `SignInLogs` and `NonInteractiveUserSignInLogs` into `logs-azure.signinlogs-*`.

See [Microsoft Entra ID sign-in logs](https://learn.microsoft.com/en-us/entra/identity/monitoring-health/concept-sign-ins) and the [Azure integration](https://docs.elastic.co/integrations/azure).
"""
severity = "high"
tags = [
    "Domain: Cloud",
    "Domain: Identity",
    "Use Case: Threat Detection",
    "Use Case: Identity and Access Audit",
    "Data Source: Azure",
    "Data Source: Microsoft Entra ID",
    "Data Source: Microsoft Entra ID Sign-in Logs",
    "Platform: Entra ID",
    "Tactic: Credential Access",
    "Tactic: Defense Evasion",
    "Resources: Investigation Guide",
    "Rule Type: New Terms",
]
timestamp_override = "event.ingested"
type = "new_terms"

query = '''
data_stream.dataset: azure.signinlogs and
    event.outcome: success and
    azure.signinlogs.properties.status.error_code: 0 and
    azure.signinlogs.properties.incoming_token_type: "primaryRefreshToken" and
    azure.signinlogs.properties.device_detail.device_id: * and
    source.ip: * and
    (
        azure.signinlogs.properties.device_detail.is_compliant: true or
        azure.signinlogs.properties.device_detail.is_managed: true
    ) and azure.signinlogs.properties.app_id: (
        "04b07795-8ddb-461a-bbee-02f9e1bf7b46" or
        "1950a258-227b-4e31-a9cf-717495945fc2" or
        "aebc6443-996d-45c2-90f0-388ff96faa56" or
        "14d82eec-204b-4c2f-b7e8-296a70dab67e" or
        "1b730954-1685-4b74-9bfd-dac224a7b894" or
        "872cd9fa-d31f-45e0-9eab-6e460a02d1f1"
    ) and azure.signinlogs.properties.resource_id: (
        "00000003-0000-0000-c000-000000000000" or
        "00000003-0000-0ff1-ce00-000000000000" or
        "6a9b9266-8161-4a7b-913a-a9eda19da220" or
        "00000002-0000-0ff1-ce00-000000000000"
    )
'''


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


[rule.threat.tactic]
id = "TA0006"
name = "Credential Access"
reference = "https://attack.mitre.org/tactics/TA0006/"
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "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/"
[[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.investigation_fields]
field_names = [
    "azure.signinlogs.properties.user_principal_name",
    "azure.signinlogs.properties.user_id",
    "azure.signinlogs.properties.device_detail.device_id",
    "azure.signinlogs.properties.device_detail.display_name",
    "azure.signinlogs.properties.app_id",
    "azure.signinlogs.properties.app_display_name",
    "azure.signinlogs.properties.resource_id",
    "azure.signinlogs.properties.resource_display_name",
    "azure.signinlogs.properties.incoming_token_type",
    "azure.signinlogs.properties.device_detail.is_compliant",
    "azure.signinlogs.properties.device_detail.is_managed",
    "azure.signinlogs.properties.authentication_requirement",
    "azure.signinlogs.properties.conditional_access_status",
    "source.ip",
    "source.geo.country_name",
    "user_agent.original",
]

[rule.new_terms]
field = "new_terms_fields"
value = ["azure.signinlogs.properties.device_detail.device_id", "source.ip"]
[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-5d"

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

[rule]
author = ["Elastic", "Willem D'Haese"]
description = """
Identifies suspicious activity reported by users in Microsoft Entra ID where users have reported suspicious activity related to their accounts, which may indicate potential compromise or unauthorized access attempts. Reported suspicious activity typically occurs during the authentication process and may involve various authentication methods, such as password resets, account recovery, or multi-factor authentication challenges. Adversaries may attempt to exploit user accounts by leveraging social engineering techniques or other methods to gain unauthorized access to sensitive information or resources.
"""
from = "now-9m"
index = ["logs-azure.auditlogs-*"]
language = "kuery"
license = "Elastic License v2"
name = "Entra ID User Reported Suspicious Activity"
note = """## Triage and Analysis

### Investigating Entra ID User Reported Suspicious Activity

This rule detects when a user in Microsoft Entra ID reports suspicious activity associated with their account. This feature is often used to report MFA fatigue or unsolicited push notifications, and is logged during authentication flows involving methods like Microsoft Authenticator. Such events may indicate that an attacker attempted unauthorized access and triggered a push that was denied or flagged by the user.

### Possible investigation steps

- Review the `azure.auditlogs.identity` field to identify the reporting user.
- Confirm that `event.action` is `"Suspicious activity reported"` and the result was `"success"`.
- Check the `azure.auditlogs.properties.additional_details` array for `AuthenticationMethod`, which shows how the login attempt was performed (e.g., `PhoneAppNotification`).
- Look at the `azure.auditlogs.properties.initiated_by.user.userPrincipalName` and `displayName` to confirm which user reported the suspicious activity.
- Investigate recent sign-in activity (`signinlogs`) for the same user. Focus on:
  - IP address geolocation and ASN.
  - Device, operating system, and browser.
  - MFA prompt patterns or unusual login attempts.
- Determine whether the user actually initiated a login attempt, or if it was unexpected and aligns with MFA fatigue or phishing attempts.
- Correlate this report with any risky sign-in detections, conditional access blocks, or password resets in the past 24–48 hours.

### False positive analysis

- Users unfamiliar with MFA push notifications may mistakenly report legitimate sign-in attempts.
- Shared accounts or device switching can also trigger unintended notifications.
- Legitimate travel or network changes might confuse users into thinking activity was malicious.

### Response and remediation

- Contact the user to validate the suspicious activity report and assess whether they were targeted or tricked by a malicious actor.
- If the report is confirmed to be valid:
  - Reset the user’s credentials immediately.
  - Revoke active sessions and refresh tokens.
  - Review their activity across Microsoft 365 services for signs of compromise.
- If other users report similar behavior around the same time, assess for a broader MFA fatigue campaign or targeted phishing.
- Consider tuning conditional access policies to require number matching or stronger MFA mechanisms.
- Educate users on reporting suspicious MFA prompts and following up with IT/security teams promptly.
"""
references = [
    "https://chris-brumm.medium.com/microsoft-entra-mfa-fraud-deep-dive-7764fd8f76ad",
    "https://janbakker.tech/report-suspicious-activity-fraud-alert-for-azure-mfa/"
]
risk_score = 47
rule_id = "caaa8b78-367c-11f0-beb8-f661ea17fbcd"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Data Source: Azure",
    "Data Source: Microsoft Entra ID",
    "Data Source: Microsoft Entra ID Audit Logs",
    "Use Case: Identity and Access Audit",
    "Resources: Investigation Guide",
    "Tactic: Initial Access",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset: "azure.auditlogs"
    and azure.auditlogs.operation_name: "Suspicious activity reported"
    and azure.auditlogs.properties.additional_details.key: "AuthenticationMethod"
    and azure.auditlogs.properties.target_resources.*.type: "User"
    and event.outcome: "success"
'''


[[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 = "T1621"
name = "Multi-Factor Authentication Request Generation"
reference = "https://attack.mitre.org/techniques/T1621/"

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

[metadata]
creation_date = "2021/01/20"
integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel", "system", "crowdstrike"]
maturity = "production"
updated_date = "2026/05/04"

[rule]
author = ["Elastic"]
description = """
Windows Component Object Model (COM) is an inter-process communication (IPC) component of the native Windows application
programming interface (API) that enables interaction between software objects or executable code. Xwizard can be used to
run a COM object created in registry to evade defensive counter measures.
"""
from = "now-9m"
index = [
    "endgame-*",
    "logs-crowdstrike.fdr*",
    "logs-endpoint.events.process-*",
    "logs-m365_defender.event-*",
    "logs-sentinel_one_cloud_funnel.*",
    "logs-system.security*",
    "logs-windows.forwarded*",
    "logs-windows.sysmon_operational-*",
    "winlogbeat-*",
]
language = "eql"
license = "Elastic License v2"
name = "Execution of COM object via Xwizard"
note = """## Triage and analysis

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

### Investigating Execution of COM object via Xwizard

The Windows Component Object Model (COM) facilitates communication between software components. Adversaries exploit this by using Xwizard to execute COM objects, bypassing security measures. The detection rule identifies suspicious Xwizard executions by monitoring process starts, checking for unusual arguments, and verifying executable paths, thus flagging potential misuse of COM objects for malicious activities.

### Possible investigation steps

- Review the process start event details to confirm the presence of xwizard.exe execution, focusing on the process.name and process.pe.original_file_name fields.
- Examine the process.args field to identify any unusual or suspicious arguments, particularly looking for the "RunWizard" command and any GUIDs or patterns that may indicate malicious activity.
- Verify the process.executable path to ensure it matches the expected system paths (C:\\Windows\\SysWOW64\\xwizard.exe or C:\\Windows\\System32\\xwizard.exe). Investigate any deviations from these paths as potential indicators of compromise.
- Check the parent process of xwizard.exe to understand the context of its execution and identify any potentially malicious parent processes.
- Correlate the event with other security data sources such as Microsoft Defender XDR or Sysmon logs to gather additional context and identify any related suspicious activities or patterns.
- Investigate the user account associated with the process execution to determine if it aligns with expected behavior or if it indicates potential unauthorized access or privilege escalation.

### False positive analysis

- Legitimate software installations or updates may trigger the rule if they use Xwizard to execute COM objects. Users can create exceptions for known software update processes by verifying the executable paths and arguments.
- System administrators might use Xwizard for legitimate configuration tasks. To handle this, identify and document regular administrative activities and exclude these from the rule by specifying the expected process arguments and executable paths.
- Automated scripts or management tools that utilize Xwizard for system management tasks can cause false positives. Review and whitelist these scripts or tools by ensuring their execution paths and arguments are consistent with known safe operations.
- Some security tools or monitoring solutions might use Xwizard as part of their normal operations. Confirm these activities with the tool's documentation and exclude them by adding their specific execution patterns to the exception list.

### Response and remediation

- Isolate the affected system from the network to prevent further malicious activity and lateral movement.
- Terminate any suspicious xwizard.exe processes identified by the detection rule to halt potential malicious execution.
- Conduct a thorough review of the system's registry for unauthorized COM objects and remove any entries that are not recognized or are deemed malicious.
- Restore the system from a known good backup if unauthorized changes or persistent threats are detected.
- Update and patch the system to the latest security standards to close any vulnerabilities that may have been exploited.
- Monitor the network for any signs of similar activity or related threats, ensuring that detection systems are tuned to identify variations of this attack.
- Escalate the incident to the security operations center (SOC) or relevant security team for further analysis and to determine if additional systems are affected."""
references = [
    "https://lolbas-project.github.io/lolbas/Binaries/Xwizard/",
    "http://www.hexacorn.com/blog/2017/07/31/the-wizard-of-x-oppa-plugx-style/",
]
risk_score = 47
rule_id = "1a6075b0-7479-450e-8fe7-b8b8438ac570"
severity = "medium"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Execution",
    "Data Source: Elastic Endgame",
    "Data Source: Elastic Defend",
    "Data Source: Windows Security Event Logs",
    "Data Source: Microsoft Defender XDR",
    "Data Source: Sysmon",
    "Data Source: SentinelOne",
    "Data Source: Crowdstrike",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
process where host.os.type == "windows" and event.type == "start" and
 (process.name : "xwizard.exe" or ?process.pe.original_file_name : "xwizard.exe") and
 (
   (process.args : "RunWizard" and process.args : "{*}") or
   (process.executable != null and
     not process.executable : (
        "C:\\Windows\\SysWOW64\\xwizard.exe",
        "C:\\Windows\\System32\\xwizard.exe",

        /* Crowdstrike specific exclusion as it uses NT Object paths */
        "\\Device\\HarddiskVolume*\\Windows\\SysWOW64\\xwizard.exe",
        "\\Device\\HarddiskVolume*\\Windows\\System32\\xwizard.exe"
     )
   )
 )
'''

setup = """## Setup

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

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

### Additional data sources

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

- [CrowdStrike](https://ela.st/crowdstrike-integration)
- [Microsoft Defender XDR](https://ela.st/m365-defender)
- [SentinelOne Cloud Funnel](https://ela.st/sentinel-one-cloud-funnel)
- [Sysmon Event ID 1 - Process Creation](https://ela.st/sysmon-event-1-setup)
- [Windows Process Creation Logs](https://ela.st/audit-process-creation)
"""


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

[[rule.threat.technique]]
id = "T1559"
name = "Inter-Process Communication"
reference = "https://attack.mitre.org/techniques/T1559/"

[[rule.threat.technique.subtechnique]]
id = "T1559.001"
name = "Component Object Model"
reference = "https://attack.mitre.org/techniques/T1559/001/"

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

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

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

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

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

[rule]
author = ["Elastic"]
description = """
This rule detects the loading of a kernel module from an unusual location. Threat actors may use
this technique to maintain persistence on a system by loading a kernel module into the kernel namespace.
This behavior is strongly related to the presence of a rootkit on the system.
"""
from = "now-9m"
index = ["logs-endpoint.events.process*"]
language = "eql"
license = "Elastic License v2"
name = "Kernel Module Load from Unusual Location"
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 Kernel Module Load from Unusual Location

This rule detects attempts to load Linux kernel modules from atypical directories, which can indicate an attacker trying to run code in kernel space for stealth and long-term persistence. Adversaries often drop a malicious `.ko` into writable paths like `/tmp` or `/dev/shm` after initial access, then use `insmod` or `modprobe` to insert it and hide processes, files, or network activity as a rootkit.

### Possible investigation steps

- Capture the full command line and resolve any referenced `.ko` path, then collect the module file for hashing and static analysis to determine provenance and known-malware matches.  
- Confirm whether the module is currently loaded by querying `lsmod`/`/proc/modules`, then map it to its on-disk location with `modinfo -n <module>` (or `/sys/module/<module>/sections/*`) to validate it was loaded from the suspicious directory.  
- Review recent kernel and audit telemetry (`dmesg`, `/var/log/kern.log`, `journalctl -k`, and any audit records) around the event time for insertion messages, signature/taint indicators, and any follow-on errors suggesting tampering.  
- Identify the initiating user/session and execution chain (parent process tree, TTY/SSH source, container context), then determine whether the action aligns with legitimate admin activity or coincides with other compromise signals on the host.  
- Hunt for persistence and repeatability by checking for recurring module-load attempts and inspecting boot-time and scheduled execution paths (systemd units, init scripts, cron, rc.local) that could reload the module after reboot.

### False positive analysis

- A system administrator or automated maintenance workflow may build or test an out-of-tree kernel module and load it with `insmod`/`modprobe` from a staging directory such as `/tmp`, `/root`, or `/mnt` before installing it into standard module paths.  
- A legitimate bootstrapping or recovery operation may load a required driver module from nonstandard media or temporary runtime locations (e.g., `/boot`, `/run`, `/var/run`, or `/mnt`) during troubleshooting, initramfs/early-boot tasks, or mounting encrypted/storage devices.

### Response and remediation

- Isolate the affected Linux host from the network and disable external access (e.g., revoke SSH keys or block inbound SSH) to prevent additional module loads or lateral movement while preserving evidence.  
- If the suspicious module is currently loaded, record `lsmod` and `modinfo` output, then unload it where safe (`modprobe -r <name>`/`rmmod <name>`) and quarantine the corresponding `.ko` from the unusual path (e.g., `/tmp`, `/dev/shm`, `/home`, `/mnt`) for hashing and malware analysis.  
- Remove persistence mechanisms that would reload the module by deleting or disabling any related systemd units, init scripts, cron entries, and boot-time hooks, and validate `/etc/modules-load.d/`, `/lib/modules/$(uname -r)/`, and `depmod` outputs for unauthorized additions.  
- Recover the host by restoring known-good kernel/module packages and rebuilding the initramfs, then reboot and verify no unexpected modules remain in `/proc/modules` and no new load attempts occur from writable directories.  
- Escalate immediately to IR/forensics and consider full host rebuild if the module is unsigned/unknown, the kernel is tainted, module removal fails, or post-reboot evidence indicates stealth behavior consistent with a rootkit.  
- Harden by restricting module loading (enable Secure Boot/module signature enforcement where supported, set `kernel.modules_disabled=1` after boot on fixed-function systems, and limit `CAP_SYS_MODULE` to trusted admins), and enforce file integrity monitoring/permissions to prevent `.ko` creation in world-writable locations."""
references = [
    "https://decoded.avast.io/davidalvarez/linux-threat-hunting-syslogk-a-kernel-rootkit-found-under-development-in-the-wild/",
]
risk_score = 73
rule_id = "d54b649d-46d0-4b4c-a9a7-1bc9fc458d3c"
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: Endpoint",
    "OS: Linux",
    "Use Case: Threat Detection",
    "Tactic: Persistence",
    "Tactic: Defense Evasion",
    "Threat: Rootkit",
    "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 == "kmod" and process.args == "insmod" and process.args like~ "*.ko*") or
  (process.name == "kmod" and process.args == "modprobe" and not process.args in ("-r", "--remove")) or
  (process.name == "insmod" and process.args like~ "*.ko*") or
  (process.name == "modprobe" and not process.args in ("-r", "--remove"))
) and (
  process.working_directory like (
    "/tmp*", "/var/tmp*", "/dev/shm*", "/run*", "/var/run*", "/home*/*", "/root*",
    "/var/www*", "/boot*", "/srv*", "/mnt*", "/media*"
  ) or
  process.parent.working_directory like (
    "/tmp*", "/var/tmp*", "/dev/shm*", "/run*", "/var/run*", "/home*/*", "/root*",
    "/var/www*", "/boot*", "/srv*", "/mnt*", "/media*"
  ) or
  process.args like (
    "/tmp/*", "/var/tmp/*", "/dev/shm/*", "/run/*", "/var/run/*", "/home/*/*", "/root/*",
    "/var/www/*", "/boot/*", "/srv/*", "/mnt/*", "/media/*", "./*"
  )
) and
not (
  process.parent.executable == "/usr/bin/podman" or
  process.working_directory like "/tmp/newroot"
)
'''

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

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

[[rule.threat.technique.subtechnique]]
id = "T1547.006"
name = "Kernel Modules and Extensions"
reference = "https://attack.mitre.org/techniques/T1547/006/"

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

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

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

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

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

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

[[rule.threat.technique.subtechnique]]
id = "T1547.006"
name = "Kernel Modules and Extensions"
reference = "https://attack.mitre.org/techniques/T1547/006/"

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

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

[rule]
author = ["Elastic"]
description = """
Detects pod or attach exec API calls where the decoded request query implies curl or wget fetching an
https URL. Attackers with permission to exec into workloads often run one-liners to stage tooling, pull
scripts or binaries, or exfiltrate data over HTTPS—activity that should be rare compared to shells, debuggers, or
expected health checks. The rule decodes the audit requestURI, reconstructs a readable command string from
repeated command parameters, and applies noise filters for common cluster health and OIDC/JWKS endpoints so
benign automation is less likely to alert.
"""
from = "now-6m"
interval = "5m"
language = "esql"
license = "Elastic License v2"
name = "Kubernetes Pod Exec with Curl or Wget to HTTPS"
note = """## Triage and analysis

### Investigating Kubernetes Pod Exec with Curl or Wget to HTTPS

Kubernetes audit logs record exec (and similar attach) calls on requestURI, including URL-encoded
command segments. This rule URL-decodes the URI, extracts the query portion into a single string, and 
flags curl or wget combined with https, excluding several common health, localhost, and OIDC/JWKS patterns.

### Possible investigation steps

- Confirm who may exec into the target namespace: review kubernetes.audit.user.username, groups, impersonation, and
  source.ip / user_agent.original (kubectl, CI, webhooks).
- Map the pod (kubernetes.audit.objectRef.name) and workload owner; retrieve the decoded URI from
  Esql.decoded_uri and the reconstructed Esql.executed_command in the alert.
- Search for adjacent audit events from the same identity: secret reads, additional execs, RBAC changes, or anonymous
  access.
- If malicious, revoke credentials used for exec, review RoleBindings for **`pods/exec`**, and inspect the pod
  filesystem or snapshot for dropped artifacts.

### False positive analysis

- Approved runbooks or support sessions may use kubectl exec with curl/wget to test egress or download vendor tools;
  document break-glass identities and tune exclusions.
- Some cluster components use HTTPS to **kubernetes.default.svc** or **.well-known** endpoints; the rule attempts to
  filter those—expand the exclusion list if your platform uses additional first-party URLs.

### Response and remediation

- Rotate any secrets accessible from the pod, cordon or delete the workload if compromised, and tighten RBAC so only
  required principals retain **`pods/exec`** on sensitive namespaces.
"""
references = [
    "https://attack.mitre.org/techniques/T1609/",
    "https://attack.mitre.org/techniques/T1105/",
]
risk_score = 73
rule_id = "c9d4e8f1-2a3b-4c5d-8e9f-0a1b2c3d4e5f"
severity = "high"
tags = [
    "Data Source: Kubernetes",
    "Data Source: Kubernetes API Server Audit Logs",
    "Domain: Kubernetes",
    "Platform: Kubernetes",
    "Use Case: Threat Detection",
    "Tactic: Execution",
    "Tactic: Command and Control",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "esql"
query = '''
FROM logs-kubernetes.audit_logs-* metadata _id, _index, _version
| WHERE kubernetes.audit.objectRef.subresource == "exec"
  AND kubernetes.audit.requestURI LIKE "*command=*"
| EVAL Esql.decoded_uri = URL_DECODE(kubernetes.audit.requestURI)
| GROK Esql.decoded_uri "%{DATA}/exec\\?%{DATA:raw_commands}&(?:container|stdin|stdout|stderr)=%{GREEDYDATA}"
| EVAL command = REPLACE(raw_commands, "command=", "")
| EVAL command = REPLACE(command, "&", " ")
| EVAL Esql.executed_command = REPLACE(command, "\\+", " ")
| WHERE Esql.executed_command IS NOT NULL 
  AND Esql.executed_command RLIKE """.*(curl.*https|wget.*https).*"""
  AND NOT Esql.executed_command RLIKE """.*(/api/v1/health|/healthz|/readyz|/livez|127\.0\.0\.1|localhost|/openid/v1/jwks|/openid-connect/certs|/.well-known/openid-configuration|/.well-known/jwks\.json|kubernetes\.default\.svc).*"""
| KEEP Esql.*, user.name, user_agent.original, event.*, source.ip, kubernetes.audit.*, _id, _version, _index, data_stream.namespace
'''

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

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

[[rule.threat.technique]]
id = "T1105"
name = "Ingress Tool Transfer"
reference = "https://attack.mitre.org/techniques/T1105/"

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

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

[rule]
author = ["Elastic"]
description = """
This rule detects a request to attach a controller service account to an existing or new pod running in the kube-system
namespace. By default, controllers running as part of the API Server utilize admin-equivalent service accounts hosted in
the kube-system namespace. Controller service accounts aren't normally assigned to running pods and could indicate
adversary behavior within the cluster. An attacker that can create or modify pods or pod controllers in the kube-system
namespace, can assign one of these admin-equivalent service accounts to a pod and abuse their powerful token to escalate
privileges and gain complete cluster control.
"""
false_positives = [
    """
    Controller service accounts aren't normally assigned to running pods, this is abnormal behavior with very few
    legitimate use-cases and should result in very few false positives.
    """,
]
index = ["logs-kubernetes.audit_logs-*"]
language = "kuery"
license = "Elastic License v2"
name = "Kubernetes Suspicious Assignment of Controller Service Account"
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 Suspicious Assignment of Controller Service Account

Kubernetes uses service accounts to manage pod permissions, with controller service accounts in the kube-system namespace having elevated privileges. Adversaries may exploit this by assigning these accounts to pods, gaining admin-level access. The detection rule identifies such suspicious assignments by monitoring audit logs for pod creation events in the kube-system namespace with controller service accounts, flagging potential privilege escalation attempts.

### Possible investigation steps

- Review the audit logs to confirm the presence of a "create" event for a pod in the "kube-system" namespace with a service account name containing "controller".
- Identify the source of the request by examining the user or service account that initiated the pod creation event in the audit logs.
- Check the history of the involved service account to determine if it has been used in any other suspicious activities or unauthorized access attempts.
- Investigate the pod's configuration and associated resources to understand its purpose and whether it aligns with expected operations within the cluster.
- Assess the potential impact by evaluating the permissions and roles associated with the controller service account assigned to the pod.
- Review recent changes or deployments in the "kube-system" namespace to identify any unauthorized modifications or anomalies.

### False positive analysis

- Routine maintenance tasks in the kube-system namespace may involve creating or modifying pods with elevated service accounts. Review the context of such actions to determine if they are part of scheduled maintenance or updates.
- Automated deployment tools might temporarily assign controller service accounts to pods for configuration purposes. Verify if these actions align with known deployment processes and consider excluding these specific tools from triggering alerts.
- Legitimate testing or debugging activities by cluster administrators could involve using controller service accounts. Ensure these activities are documented and consider creating exceptions for known testing environments.
- Some monitoring or logging solutions might require elevated permissions and could inadvertently trigger this rule. Validate the necessity of these permissions and whitelist these solutions if they are deemed non-threatening.
- Regularly review and update the list of known benign service account assignments to ensure that only unexpected or unauthorized assignments are flagged.

### Response and remediation

- Immediately isolate the affected pod by cordoning the node it is running on to prevent further scheduling of pods and drain the node if necessary to stop the pod from executing.
- Revoke the service account token associated with the suspicious pod to prevent further unauthorized access or actions using the compromised credentials.
- Conduct a thorough review of recent changes in the kube-system namespace to identify unauthorized modifications or deployments, focusing on the creation and modification of pods and service accounts.
- Reset credentials and rotate keys for any service accounts that may have been compromised to ensure that any stolen credentials are rendered useless.
- Implement network policies to restrict pod-to-pod communication within the kube-system namespace, limiting the potential lateral movement of an attacker.
- Escalate the incident to the security operations team for further investigation and to determine if additional clusters or systems have been affected.
- Enhance monitoring and alerting for similar activities by ensuring audit logs are comprehensive and that alerts are configured to detect unauthorized service account assignments promptly.

## Setup

The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule."""
references = [
    "https://www.paloaltonetworks.com/apps/pan/public/downloadResource?pagePath=/content/pan/en_US/resources/whitepapers/kubernetes-privilege-escalation-excessive-permissions-in-popular-platforms",
]
risk_score = 47
rule_id = "63c05204-339a-11ed-a261-0242ac120002"
severity = "medium"
tags = [
    "Data Source: Kubernetes",
    "Domain: Kubernetes",
    "Use Case: Threat Detection",
    "Tactic: Execution",
    "Tactic: Privilege Escalation",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"
query = '''
data_stream.dataset : "kubernetes.audit_logs" and kubernetes.audit.annotations.authorization_k8s_io/decision:"allow" and
kubernetes.audit.verb : "create" and kubernetes.audit.objectRef.resource : "pods" and
kubernetes.audit.objectRef.namespace : "kube-system" and kubernetes.audit.requestObject.spec.serviceAccountName:*controller and
not kubernetes.audit.requestObject.spec.containers.image:(
  mirror.gcr.io/aquasec/trivy* or *amazonaws.com/eks/snapshot-controller* or rancher/mirrored-sig-storage-snapshot-controller* or
  public.ecr.aws/eks/aws-load-balancer-controller* or docker.io/bitnami/sealed-secrets-controller* or exoscale/csi-driver* or
  registry.k8s.io/autoscaling/vpa-admission-controller* or registry.k8s.io/sig-storage/csi-attacher* or registry.k8s.io/sig-storage/csi-provisioner*
)
'''

[[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.001"
name = "Default Accounts"
reference = "https://attack.mitre.org/techniques/T1078/001/"

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

[rule]
description = """
Detects the execution of Powershell (pwsh) with the encoded command flag set in the process arguments, in conjunction
with an unusual process command line length. Powershell usage on Linux is rare, and the usage of encoded commands with
unusual lengths is through Powershell may indicate malicious behavior.
"""
id = "cd6e64ec-2890-4bd8-9d07-bef06465b06f"
license = "Elastic License v2"
name = "Linux Powershell Encoded Command"
os_list = ["linux"]
version = "1.0.16"

query = '''
process where event.action == "exec" and event.type == "start" and process.name == "pwsh" and
process.args : ("-EncodedCommand", "-enc", "-E") and process.args : ("-nop", "-noprofile") and 
length(process.command_line) >= 100 and not (
  process.parent.name in ("node", "code", "code-insiders", "cursor") or
  process.parent.command_line : "*Invoke-Pester*" or
  process.parent.args == "--utility-sub-type=node.mojom.NodeService" or
  process.parent.executable like ("/data/user/docker/*", "/tmp/.mount_Cursor*/usr/share/cursor/cursor") or
  process.parent.executable in ("/usr/lib/electron30/electron", "/usr/lib/electron32/electron", "/tmp/newroot/proc/self/exe") or
  (
    process.args == "IAAoAEcAZQB0AC0ASABvAHMAdAApAC4AVgBlAHIAcwBpAG8AbgAuAFQAbwBTAHQAcgBpAG4AZwAoACkAIAA=" and 
    process.parent.args == "Invoke-LightRail.ps1"
  ) or
  process.args like~ "JABFAHIAcgBvAHIAQQBjAHQAaQBvAG4AUAByAGUAZgBlAHIAZQBuAGMAZQAgAD0AIAAnAFMAdABvAHAAJwAKAFsAdgBlAHIAcwBp*" or
  process.args in (
    "VwByAGkAdABlAC0ATwB1AHQAcAB1AHQAIAAnAEgARQBMAEwATwAgAFcATwBSAEwARAAnAA==", "dwByAGkAdABlAC0AaABvAHMAdAAgACIAdABlAHMAdAAiAA=",
    "dwByAGkAdABlAC0AaABvAHMAdAAgACIAdABlAHMAdAAiAA=="
  )
)
'''

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

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

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



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

[internal]
min_endpoint_version = "7.15.0"

[metadata]
creation_date = "2023/02/28"
integration = ["endpoint"]
maturity = "production"
updated_date = "2026/03/24"

[transform]
[[transform.osquery]]
label = "Osquery - Retrieve File Information"
query = "SELECT * FROM file WHERE path = {{file.path}}"

[[transform.osquery]]
label = "Osquery - Retrieve File Listing Information"
query = "SELECT * FROM file WHERE path LIKE '/etc/update-motd.d/%'"

[[transform.osquery]]
label = "Osquery - Retrieve Additional File Listing Information"
query = """
SELECT f.path, u.username AS file_owner, g.groupname AS group_owner, datetime(f.atime, 'unixepoch') AS
file_last_access_time, datetime(f.mtime, 'unixepoch') AS file_last_modified_time, datetime(f.ctime, 'unixepoch') AS
file_last_status_change_time, datetime(f.btime, 'unixepoch') AS file_created_time, f.size AS size_bytes FROM file f LEFT
JOIN users u ON f.uid = u.uid LEFT JOIN groups g ON f.gid = g.gid WHERE path LIKE '/etc/update-motd.d/%'
"""

[[transform.osquery]]
label = "Osquery - Retrieve Running Processes by User"
query = "SELECT pid, username, name FROM processes p JOIN users u ON u.uid = p.uid ORDER BY username"

[[transform.osquery]]
label = "Osquery - Retrieve Crontab Information"
query = "SELECT * FROM crontab"

[rule]
author = ["Elastic"]
description = """
This rule detects the creation of potentially malicious files within the default MOTD file directories. Message of the
day (MOTD) is the message that is presented to the user when a user connects to a Linux server via SSH or a serial
connection. Linux systems contain several default MOTD files located in the "/etc/update-motd.d/" directory. These
scripts run as the root user every time a user connects over SSH or a serial connection. Adversaries may create
malicious MOTD files that grant them persistence onto the target every time a user connects to the system by executing a
backdoor script or command.
"""
from = "now-9m"
index = ["logs-endpoint.events.file*"]
language = "eql"
license = "Elastic License v2"
name = "Message-of-the-Day (MOTD) File Creation"
note = """## Triage and analysis

### Investigating Message-of-the-Day (MOTD) File Creation

The message-of-the-day (MOTD) is used to display a customizable system-wide message or information to users upon login in Linux.

Attackers can abuse message-of-the-day (motd) files to run scripts, commands or malicious software every time a user connects to a system over SSH or a serial connection, by creating a new file within the `/etc/update-motd.d/` directory. Executable files in these directories automatically run with root privileges.

This rule identifies the creation of new files within the `/etc/update-motd.d/` directory.

> **Note**:
> This investigation guide uses the [Osquery Markdown Plugin](https://www.elastic.co/guide/en/security/current/invest-guide-run-osquery.html) introduced in Elastic Stack version 8.5.0. Older Elastic Stack versions will display unrendered Markdown in this guide.
> This investigation guide uses [placeholder fields](https://www.elastic.co/guide/en/security/current/osquery-placeholder-fields.html) to dynamically pass alert data into Osquery queries. Placeholder fields were introduced in Elastic Stack version 8.7.0. If you're using Elastic Stack version 8.6.0 or earlier, you'll need to manually adjust this investigation guide's queries to ensure they properly run.

#### Possible Investigation Steps

- Investigate the file that was created or modified.
  - $osquery_0
- Investigate whether any other files in the `/etc/update-motd.d/` directory have been altered.
  - $osquery_1
  - $osquery_2
- Investigate the script execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence and whether they are located in expected locations.
  - $osquery_3
- Investigate other alerts associated with the user/host during the past 48 hours.
- Investigate whether the modified scripts call other malicious scripts elsewhere on the file system.
  - If scripts or executables were dropped, retrieve the files and determine if they are malicious:
    - Use a private sandboxed malware analysis system to perform analysis.
      - Observe and collect information about the following activities:
        - Attempts to contact external domains and addresses.
          - Check if the domain is newly registered or unexpected.
          - Check the reputation of the domain or IP address.
        - File access, modification, and creation activities.
        - Cron jobs, services and other persistence mechanisms.
            - $osquery_4

### Related Rules

- Process Spawned from Message-of-the-Day (MOTD) - 4ec47004-b34a-42e6-8003-376a123ea447

### False positive analysis

- This activity is unlikely to happen legitimately. Any activity that triggered the alert and is not inherently malicious must be monitored by the security team.

### Response and remediation

- Initiate the incident response process based on the outcome of the triage.
- Isolate the involved host to prevent further post-compromise behavior.
- If the triage identified malware, search the environment for additional compromised hosts.
  - Implement temporary network rules, procedures, and segmentation to contain the malware.
  - Stop suspicious processes.
  - Immediately block the identified indicators of compromise (IoCs).
  - Inspect the affected systems for additional malware backdoors like reverse shells, reverse proxies, or droppers that attackers could use to reinfect the system.
- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services.
- Delete the MOTD files or restore their original configuration.
- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.
- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.
- Leverage the incident response data and logging to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).
"""
references = [
    "https://pberba.github.io/security/2022/02/06/linux-threat-hunting-for-persistence-initialization-scripts-and-shell-configuration/#10-boot-or-logon-initialization-scripts-motd",
    "https://www.elastic.co/security-labs/sequel-on-persistence-mechanisms",
]
risk_score = 47
rule_id = "96d11d31-9a79-480f-8401-da28b194608f"
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: Persistence",
    "Resources: Investigation Guide",
    "Data Source: Elastic Defend",
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
file where host.os.type == "linux" and event.action == "creation" and file.path like "/etc/update-motd.d/*" and
not (
  process.executable in (
    "/bin/dpkg", "/usr/bin/dpkg", "/bin/dockerd", "/usr/bin/dockerd", "/usr/sbin/dockerd", "/bin/microdnf",
    "/usr/bin/microdnf", "/bin/rpm", "/usr/bin/rpm", "/bin/snapd", "/usr/bin/snapd", "/bin/yum", "/usr/bin/yum",
    "/bin/dnf", "/usr/bin/dnf", "/bin/podman", "/usr/bin/podman", "/bin/dnf-automatic", "/usr/bin/dnf-automatic",
    "/bin/pacman", "/usr/bin/pacman", "/usr/bin/dpkg-divert", "/bin/dpkg-divert", "/sbin/apk", "/usr/sbin/apk",
    "/usr/local/sbin/apk", "/usr/bin/apt", "/usr/sbin/pacman", "/bin/podman", "/usr/bin/podman", "/usr/bin/puppet",
    "/bin/puppet", "/opt/puppetlabs/puppet/bin/puppet", "/usr/bin/chef-client", "/bin/chef-client", "/usr/bin/buildah",
    "/bin/autossl_check", "/usr/bin/autossl_check", "/proc/self/exe", "/usr/bin/pamac-daemon", "/.envbuilder/bin/envbuilder",
    "/bin/pamac-daemon", "/usr/lib/snapd/snapd", "/usr/local/bin/dockerd", "./usr/bin/podman", "/opt/saltstack/salt/bin/python3.10",
    "/opt/puppetlabs/puppet/bin/ruby", "/usr/bin/crio"
  ) or
  file.extension in ("swp", "swpx", "swx", "dpkg-remove") or
  file.Ext.original.extension == "dpkg-new" or
  process.executable : (
    "/nix/store/*", "/var/lib/dpkg/*", "/tmp/vmis.*", "/snap/*", "/dev/fd/*", "/usr/lib/virtualbox/*"
  ) or
  process.executable == null or
  process.name in ("executor", "dockerd", "crio") or
  (process.name == "sed" and file.name : "sed*") or
  (process.name == "perl" and file.name : "e2scrub_all.tmp*")
)
'''

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

[[rule.threat.technique]]
id = "T1037"
name = "Boot or Logon Initialization Scripts"
reference = "https://attack.mitre.org/techniques/T1037/"

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

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

[[rule.threat.technique]]
id = "T1037"
name = "Boot or Logon Initialization Scripts"
reference = "https://attack.mitre.org/techniques/T1037/"

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

[metadata]
creation_date = "2020/02/18"
integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_funnel"]
maturity = "production"
updated_date = "2026/03/24"

[rule]
author = ["Elastic"]
description = """
Nping ran on a Linux host. Nping is part of the Nmap tool suite and has the ability to construct raw packets for a wide
variety of security testing applications, including denial of service testing.
"""
false_positives = [
    """
    Some normal use of this command may originate from security engineers and network or server administrators, but this
    is usually not routine or unannounced. Use of `Nping` by non-engineers or ordinary users is uncommon.
    """,
]
from = "now-9m"
index = [
    "auditbeat-*",
    "endgame-*",
    "logs-auditd_manager.auditd-*",
    "logs-crowdstrike.fdr*",
    "logs-endpoint.events.process*",
    "logs-sentinel_one_cloud_funnel.*",
]
language = "eql"
license = "Elastic License v2"
name = "Nping Process Activity"
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 Nping Process Activity

Nping, a component of the Nmap suite, is used for crafting raw packets, aiding in network diagnostics and security testing. Adversaries may exploit Nping to perform network reconnaissance or denial-of-service attacks by sending crafted packets to probe network services. The detection rule identifies Nping's execution on Linux systems by monitoring process start events, helping to flag potential misuse for malicious network discovery activities.

### Possible investigation steps

- Review the process start event details to confirm the execution of Nping, focusing on the process name field to ensure it matches "nping".
- Identify the user account associated with the Nping process execution to determine if it aligns with expected or authorized usage patterns.
- Examine the command line arguments used with Nping to understand the intent of the execution, such as specific network targets or packet types.
- Check the timing and frequency of the Nping execution to assess if it correlates with any known maintenance windows or unusual activity patterns.
- Investigate network logs or traffic data to identify any unusual or unauthorized network scanning or probing activities originating from the host where Nping was executed.
- Correlate the Nping activity with other security alerts or logs from the same host to identify potential indicators of compromise or broader attack patterns.

### False positive analysis

- Routine network diagnostics by IT teams using Nping for legitimate purposes can trigger alerts. To manage this, create exceptions for specific user accounts or IP addresses known to perform regular network testing.
- Automated scripts or monitoring tools that incorporate Nping for network health checks may cause false positives. Identify these scripts and whitelist their execution paths or associated processes.
- Security assessments or penetration tests conducted by authorized personnel might involve Nping usage. Coordinate with security teams to schedule these activities and temporarily adjust detection rules or add exceptions for the duration of the tests.
- Development or testing environments where Nping is used for application testing can generate alerts. Exclude these environments from monitoring or adjust the rule to ignore specific hostnames or network segments.
- Training sessions or workshops that include Nping demonstrations can lead to false positives. Notify the security team in advance and apply temporary exceptions for the event duration.

### Response and remediation

- Immediately isolate the affected Linux host from the network to prevent further reconnaissance or potential denial-of-service attacks.
- Terminate the Nping process on the affected host to stop any ongoing malicious activity.
- Conduct a thorough review of recent network traffic logs from the affected host to identify any unusual or unauthorized network service discovery attempts.
- Check for any unauthorized changes or installations on the affected host that may indicate further compromise or persistence mechanisms.
- Update and apply network security policies to restrict the use of network diagnostic tools like Nping to authorized personnel only.
- Escalate the incident to the security operations team for further investigation and to determine if the activity is part of a larger attack campaign.
- Enhance monitoring and alerting for similar activities across the network by ensuring that detection rules are in place for unauthorized use of network diagnostic tools."""
references = ["https://en.wikipedia.org/wiki/Nmap"]
risk_score = 47
rule_id = "0d69150b-96f8-467c-a86d-a67a3378ce77"
setup = """## Setup

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

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

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

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

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

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

query = '''
process where host.os.type == "linux" and event.type == "start" and
 event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and
 process.name == "nping"
'''


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

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

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

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

[[rule.threat.technique]]
id = "T1498"
name = "Network Denial of Service"
reference = "https://attack.mitre.org/techniques/T1498/"

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

[rule]
description = """
Detects when a .pl file gets created or modified by a non-perl binary. Perl is a scripting language that comes
pre-installed on macOS and is a trusted binary offering an extensive set of capabilities and advantages to an adversary.
Its use on a macOS system is not common and therefore specific behaviors exhibited can be classified as malicious or
suspicious at least.
"""
id = "f2fa4350-6700-46d1-b79c-fedd385f6984"
license = "Elastic License v2"
name = "Perl Script File Creation or Modification"
os_list = ["macos"]
version = "1.0.8"

query = '''
sequence by process.entity_id with maxspan=15s
[network where event.type == "start"]
[file where event.action == "modification" and file.extension == "pl" and 
  (process.code_signature.trusted == false or process.code_signature.exists == false) and
  file.path like ("/Users/Shared/*", "/tmp/*", "/private/tmp/*", "/var/tmp/*", "/private/var/tmp/*") and
  not Effective_process.executable like "/nix/store/*-nix-*/bin/nix"]
'''

min_endpoint_version = "8.16.0"
optional_actions = []
[[actions]]
action = "kill_process"
field = "Effective_process.entity_id"
state = 1

[[actions]]
action = "kill_process"
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.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.16.0"

[metadata]
creation_date = "2026/09/04"
integration = ["endpoint", "windows", "system", "crowdstrike", "sentinel_one_cloud_funnel", "m365_defender"]
maturity = "production"
updated_date = "2026/09/04"

[rule]
author = ["Elastic"]
description = """
Identifies anomalous execution of BrowserCore.exe, the Windows component used by Chromium-based browsers for native
messaging with the Web Account Manager (WAM). Adversaries abuse BrowserCore to extract Entra ID Primary Refresh Tokens
(PRTs) without interactive browser context, enabling session hijacking. Legitimate BrowserCore launches carry a
chrome-extension:// argument from the browser native-messaging host.
"""
from = "now-9m"
language = "esql"
license = "Elastic License v2"
name = "Potential Entra ID PRT Extraction via BrowserCore"
references = [
    "https://www.armadin.com/blog-posts/prtremote-extract-prt-cookies-remotely-with-interactivetoken-scheduled-task",
    "https://github.com/dmcxblue/ANIMO/blob/master/helpers/scripts/GrabTokenAzureAD/PrtExtractor.cs",
    "https://attack.mitre.org/techniques/T1528/",
]
risk_score = 73
rule_id = "8f44478a-5b6a-4463-8a0a-3300bf3a62c9"
severity = "high"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Platform: Windows",
    "Use Case: Threat Detection",
    "Tactic: Credential Access",
    "Resources: Investigation Guide",
    "Rule Type: ESQL",
    "Data Source: Elastic Defend",
    "Data Source: Sysmon",
    "Data Source: Windows Security Event Logs",
    "Data Source: Crowdstrike",
    "Data Source: SentinelOne",
    "Data Source: Microsoft Defender XDR",
]
timestamp_override = "event.ingested"
type = "esql"

query = '''
from logs-endpoint.events.process-*, logs-windows.sysmon_operational-*, logs-system.security-*, logs-windows.*, winlogbeat-*, logs-crowdstrike.fdr*, logs-sentinel_one_cloud_funnel.*, logs-m365_defender.event-* metadata _id, _version, _index
| where KQL(""" event.category : "process" and event.type : "start" and host.os.type : "windows" """) and 
        to_lower(process.name) == "browsercore.exe" and process.parent.name is not null and process.command_line is not null and
        not to_lower(process.command_line) like "*chrome-extension://*"
| keep
    @timestamp, 
    _id, 
    _version, 
    _index,
    data_stream.namespace,
    host.id,
    host.name,
    user.name,
    user.id,
    process.entity_id,
    process.name,
    process.executable,
    process.command_line,
    process.pe.original_file_name,
    process.parent.name,
    process.parent.executable,
    process.parent.command_line
'''

note = """## Triage and analysis

### Investigating Potential Entra ID PRT Extraction via BrowserCore

BrowserCore.exe is the Chromium native-messaging helper that brokers Web Account Manager (WAM) / Entra ID token
operations for Edge and Chrome. Tools such as PRTRemote and PrtExtractor invoke it outside the browser's
native-messaging context to obtain Primary Refresh Tokens (PRTs).

#### Possible investigation steps

- Is BrowserCore running from a non-canonical path or with a mismatched original filename?
  - Focus: `process.executable`, `process.name`, `process.pe.original_file_name`, `process.hash.sha256`, and signer fields.
  - Implication: escalate when the PE original name is BrowserCore.exe but the path is outside
    `C:\\Windows\\BrowserCore\\`, or when the binary is recently dropped/renamed.

- Does the command line lack the browser native-messaging extension URI?
  - Focus: `process.command_line`, `process.parent.name`, `process.parent.executable`, `process.parent.command_line`.
  - Hint: legitimate launches include `chrome-extension://`. Abuse often omits that URI and may be launched by Task
    Scheduler, scripts, or remote tools.
  - Implication: escalate when `chrome-extension://` is absent and the parent is `svchost.exe` (task), `powershell.exe`,
    `wscript.exe`, or another unexpected launcher.

- Was there related token theft or Entra ID activity around the same time?
  - Focus: related alerts for `user.id` / `host.id` covering credential access, unusual logons, or cloud session abuse.
  - Implication: broaden scope when PRT extraction coincides with suspicious Azure/Entra sign-ins or cookie theft.

### False positive analysis

- Legitimate browser SSO and account linking launch BrowserCore with a `chrome-extension://` argument and should not
  match pivot 2. Rare custom helpers that invoke BrowserCore without that URI may need exceptions scoped to
  `process.executable`, `process.parent.executable`, `user.id`, and `host.id`.

### Response and remediation

- If confirmed malicious, isolate the host, terminate the anomalous BrowserCore tree, and assume the user's Entra ID
  PRT/session may be compromised: revoke refresh tokens / sign the user out of all sessions and rotate credentials.
- Hunt for the same `process.command_line` pattern, scheduled tasks, or scripts that invoke BrowserCore across the estate.
- Remove persistence (scheduled tasks, scripts) that launched BrowserCore outside the browser native-messaging flow.
"""

setup = """## Setup

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

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

### Additional data sources

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

- [CrowdStrike](https://ela.st/crowdstrike-integration)
- [Microsoft Defender XDR](https://ela.st/m365-defender)
- [SentinelOne Cloud Funnel](https://ela.st/sentinel-one-cloud-funnel)
- [Sysmon Event ID 1 - Process Creation](https://ela.st/sysmon-event-1-setup)
- [Windows Process Creation Logs](https://ela.st/audit-process-creation)
"""

[rule.investigation_fields]
field_names = [
    "@timestamp",
    "host.id",
    "host.name",
    "user.name",
    "user.id",
    "process.entity_id",
    "process.name",
    "process.executable",
    "process.command_line",
    "process.pe.original_file_name",
    "process.parent.name",
    "process.parent.executable",
    "process.parent.command_line",
]

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