Elastic rules: 23

[rule]
description = """
In an Active Directory LDAP query, (objectGUID=*) is a search filter that evaluates to TRUE for every object in the
directory, meaning it will return all objects. This may indicate an attempt to dump AD database using tools such as
ADExplorer for offline analysis or exfiltration.
"""
id = "e79d5328-16fc-45ea-8179-ea2746042af6"
license = "Elastic License v2"
name = "Active Directory Data Collection via LDAP"
os_list = ["windows"]
reference = ["https://learn.microsoft.com/en-us/windows/win32/adschema/a-objectguid"]
version = "1.0.3"

query = '''
api where process.Ext.api.name == "ldap_search" and process.Ext.api.parameters.search_filter : ("(objectGUID=?)", "objectGUID=?")
'''

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

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1069"
name = "Permission Groups Discovery"
reference = "https://attack.mitre.org/techniques/T1069/"
[[threat.technique.subtechnique]]
id = "T1069.002"
name = "Domain Groups"
reference = "https://attack.mitre.org/techniques/T1069/002/"


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


[[threat.technique]]
id = "T1482"
name = "Domain Trust Discovery"
reference = "https://attack.mitre.org/techniques/T1482/"

[[threat.technique]]
id = "T1482"
name = "Domain Trust Discovery"
reference = "https://attack.mitre.org/techniques/T1482/"

[[threat.technique]]
id = "T1615"
name = "Group Policy Discovery"
reference = "https://attack.mitre.org/techniques/T1615/"


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

[internal]
min_endpoint_version = "9.1.0"

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

[rule]
author = ["Elastic"]
description = """
Detects failed, access-denied attempts to modify or delete resource-based access policies on AWS Bedrock resources via
the PutResourcePolicy and DeleteResourcePolicy API calls. Resource-based policies govern which principals (including
external accounts) may access Bedrock resources such as agents, knowledge bases, and custom models. A principal that is
repeatedly denied when attempting to attach or remove these policies may be a compromised or under-privileged identity
probing for the ability to grant external or cross-account access, or to weaken existing access controls. Unlike the
companion rule that detects successful changes, this rule surfaces the attempt itself, which is a high-signal indicator
of credential boundary-testing even though no change occurred.
"""
false_positives = [
    """
    Access-denied errors can result from benign permission gaps: a newly created role or user whose IAM policy has not
    yet been provisioned, infrastructure-as-code pipelines running ahead of permission grants, or developers
    experimenting in non-production accounts. Verify whether the user identity, user agent, and source IP are expected
    to manage Bedrock resource policies in your environment. Recurring denials from known automation or onboarding
    workflows can be exempted from the rule.
    """,
]
from = "now-6m"
index = ["logs-aws.cloudtrail-*"]
language = "kuery"
license = "Elastic License v2"
name = "AWS Bedrock Unauthorized Resource-Based Policy Modification Attempt"
note = """## Triage and analysis

### Investigating AWS Bedrock Unauthorized Resource-Based Policy Modification Attempt

AWS Bedrock resource-based policies control which principals can access Bedrock resources such as agents,
knowledge bases, and custom models. An adversary who has compromised a credential may attempt to attach a policy
that grants an external principal access for persistence or cross-account access, or delete a policy to break
existing access controls. This rule detects `PutResourcePolicy` and `DeleteResourcePolicy` calls that were denied
(`AccessDenied` / unauthorized), which indicates an identity attempting an action it is not permitted to perform —
a strong signal of boundary-testing by a compromised or under-privileged principal even though the change did not
take effect.

#### Possible investigation steps

- **Identify the actor and context**
  - Review `aws.cloudtrail.user_identity.arn`, `aws.cloudtrail.user_identity.type`,
    `aws.cloudtrail.user_identity.access_key_id`, `user_agent.original`, and `source.ip`.
  - Determine whether this identity has any legitimate reason to manage Bedrock resource policies. A denial for an
    identity that should never touch these APIs is more suspicious than one from an admin with a transient gap.
- **Assess the attempt**
  - Inspect `aws.cloudtrail.error_code` and `aws.cloudtrail.error_message` to confirm the denial reason.
  - For `PutResourcePolicy`, review `aws.cloudtrail.request_parameters` and
    `aws.cloudtrail.flattened.request_parameters` for the target resource ARN and the attempted policy document.
    Look for `Principal` values referencing external AWS account IDs, `"*"`, or unfamiliar roles.
- **Correlate activity**
  - Look for repeated denials across Bedrock or IAM APIs from the same identity, which can indicate permission
    enumeration or escalation attempts.
  - Check whether the identity later succeeded (e.g., after acquiring new permissions) on the same or related
    resources, and review any IAM changes in the surrounding window.

### False positive analysis

- **Permission gaps**: Newly provisioned roles/users or IaC pipelines running before policy grants are applied may
  generate transient denials. Validate against change tickets and known automation.
- **Exploration in non-production**: Developers testing in sandbox accounts may hit denials. Confirm the account and
  identity context.

### Response and remediation

- If the attempt is unexpected, treat the identity as potentially compromised: disable or rotate the credentials in
  `aws.cloudtrail.user_identity.access_key_id` and review the actor's recent activity.
- Review all Bedrock and IAM activity from the same identity in the surrounding time window for successful access
  grants, permission changes, or other persistence attempts.
- Confirm least-privilege on `bedrock:PutResourcePolicy` and `bedrock:DeleteResourcePolicy`, and alert on both denied
  and successful calls.
"""
references = [
    "https://docs.aws.amazon.com/bedrock/latest/APIReference/API_PutResourcePolicy.html",
    "https://docs.aws.amazon.com/bedrock/latest/APIReference/API_DeleteResourcePolicy.html"
]
risk_score = 21
rule_id = "2e99477f-6099-48a9-ae0e-68801d97079c"
severity = "low"
tags = [
    "Domain: Cloud",
    "Domain: LLM",
    "Data Source: AWS",
    "Data Source: AWS CloudTrail",
    "Data Source: Amazon Web Services",
    "Data Source: Amazon Bedrock",
    "Use Case: Identity and Access Audit",
    "Resources: Investigation Guide",
    "Tactic: Persistence",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset: "aws.cloudtrail" and
    event.provider: "bedrock.amazonaws.com" and
    event.action: ("PutResourcePolicy" or "DeleteResourcePolicy") and
    event.outcome: "failure" and
    aws.cloudtrail.error_code: (
        "AccessDenied" or
        "AccessDeniedException"
    )
'''

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

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

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

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

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

[rule]
author = ["Elastic"]
description = """
Identifies when an Azure Automation runbook is created or modified. An adversary may create or modify an Azure
Automation runbook to execute malicious code and maintain persistence in their target's environment.
"""
from = "now-9m"
index = ["logs-azure.activitylogs-*", "filebeat-*"]
language = "kuery"
license = "Elastic License v2"
name = "Azure Automation Runbook Created or Modified"
note = """## Triage and analysis

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

### Investigating Azure Automation Runbook Created or Modified

Azure Automation Runbooks are scripts that automate tasks in cloud environments, enhancing operational efficiency. However, adversaries can exploit them to execute unauthorized code and maintain persistence. The detection rule monitors specific Azure activity logs for runbook creation or modification events, flagging successful operations to identify potential misuse. This helps in early detection of malicious activities, ensuring cloud security.

### Possible investigation steps

- Review the Azure activity logs to identify the specific runbook that was created or modified, focusing on the operation names: "MICROSOFT.AUTOMATION/AUTOMATIONACCOUNTS/RUNBOOKS/DRAFT/WRITE", "MICROSOFT.AUTOMATION/AUTOMATIONACCOUNTS/RUNBOOKS/WRITE", or "MICROSOFT.AUTOMATION/AUTOMATIONACCOUNTS/RUNBOOKS/PUBLISH/ACTION".
- Check the event.outcome field to confirm the operation was successful, as indicated by the values "Success" or "success".
- Identify the user or service principal that performed the operation by examining the relevant user identity fields in the activity logs.
- Investigate the content and purpose of the runbook by reviewing its script or configuration to determine if it contains any unauthorized or suspicious code.
- Correlate the runbook activity with other security events or alerts in the environment to identify any patterns or related malicious activities.
- Verify if the runbook changes align with recent legitimate administrative activities or if they were unexpected, which could indicate potential misuse.

### False positive analysis

- Routine updates or maintenance activities by authorized personnel can trigger alerts. To manage this, create exceptions for known maintenance windows or specific user accounts that regularly perform these tasks.
- Automated deployment processes that include runbook creation or modification might be flagged. Identify and exclude these processes by tagging them with specific identifiers in the logs.
- Integration with third-party tools that modify runbooks as part of their normal operation can result in false positives. Work with your IT team to whitelist these tools or their associated accounts.
- Frequent testing or development activities in non-production environments may cause alerts. Consider setting up separate monitoring rules or thresholds for these environments to reduce noise.
- Scheduled runbook updates for compliance or policy changes can be mistaken for suspicious activity. Document these schedules and adjust the detection rule to account for them, possibly by excluding specific operation names during these times.

### Response and remediation

- Immediately isolate the affected Azure Automation account to prevent further unauthorized runbook executions. This can be done by disabling the account or restricting its permissions temporarily.
- Review the modified or newly created runbooks to identify any malicious code or unauthorized changes. Remove or revert any suspicious modifications to ensure the integrity of the automation scripts.
- Conduct a thorough audit of recent activities associated with the affected Azure Automation account, focusing on identifying any unauthorized access or changes made by adversaries.
- Reset credentials and update access controls for the affected Azure Automation account to prevent further unauthorized access. Ensure that only authorized personnel have the necessary permissions to create or modify runbooks.
- Implement additional monitoring and alerting for Azure Automation activities, specifically focusing on runbook creation and modification events, to enhance early detection of similar threats in the future.
- Escalate the incident to the security operations team for further investigation and to determine if additional systems or accounts have been compromised.
- Document the incident, including all actions taken and findings, to improve response strategies and update incident response plans for future reference.

## Setup

The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule."""
references = [
    "https://powerzure.readthedocs.io/en/latest/Functions/operational.html#create-backdoor",
    "https://github.com/hausec/PowerZure",
    "https://posts.specterops.io/attacking-azure-azure-ad-and-introducing-powerzure-ca70b330511a",
    "https://azure.microsoft.com/en-in/blog/azure-automation-runbook-management/",
]
risk_score = 21
rule_id = "16280f1e-57e6-4242-aa21-bb4d16f13b2f"
severity = "low"
tags = ["Domain: Cloud", "Data Source: Azure", "Use Case: Configuration Audit", "Tactic: Execution", "Resources: Investigation Guide"]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:azure.activitylogs and
  azure.activitylogs.operation_name:
  (
    "MICROSOFT.AUTOMATION/AUTOMATIONACCOUNTS/RUNBOOKS/DRAFT/WRITE" or
    "MICROSOFT.AUTOMATION/AUTOMATIONACCOUNTS/RUNBOOKS/WRITE" or
    "MICROSOFT.AUTOMATION/AUTOMATIONACCOUNTS/RUNBOOKS/PUBLISH/ACTION"
  ) and
  event.outcome:(Success or success)
'''

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

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

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

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

[[rule.threat.technique]]
id = "T1053"
name = "Scheduled Task/Job"
reference = "https://attack.mitre.org/techniques/T1053/"

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

[rule]
description = "Identifies the load of the Microsoft Common Language Runtime DLL CLR.dll from a recently dropped unsigned DLL."
id = "d8d90a1a-a912-4716-994b-26e24d363d76"
license = "Elastic License v2"
name = "Common Language Runtime Loaded via an Unsigned Module"
os_list = ["windows"]
reference = [
    "https://www.elastic.co/security-labs/upping-the-ante-detecting-in-memory-threats-with-kernel-call-stacks",
]
version = "1.0.20"

query = '''
sequence by process.entity_id with maxspan=1m
 [library where
  dll.Ext.relative_file_creation_time <= 300 and
  dll.code_signature.trusted  != true and not startswith~(dll.name, process.name) and
  dll.hash.sha256 : "??*" and dll.path : "?*" and
  (process.code_signature.subject_name : "Microsoft*" or process.code_signature.exists == false) and
  not dll.code_signature.status : ("trusted", "errorCode_endpoint*") and
  not process.executable : ("?:\\Program Files\\*", "?:\\Program Files (x86)\\*", "?:\\Windows\\System32\\DriverStore\\FileRepository\\*") and
  not dll.path : ("?:\\Windows\\assembly\\NativeImages_v*",
                  "?:\\Windows\\System32\\DriverStore\\FileRepository\\*",
                  "?:\\Windows\\SoftwareDistribution\\Download\\*",
                  "?:\\Windows\\WinSxS\\*",
                  "?:\\Program Files\\*",
                  "?:\\Program Files (x86)\\*") and
  not dll.hash.sha256 : "f51ff500ace815d2d2213fe961a2080f8b7da98474d7a7736a49961938e1028e"] as event0
 [library where dll.name : "clr.dll" and
  stringcontains~(process.thread.Ext.call_stack_summary, concat("mscoreei.dll|", event0.dll.name)) and
  not process.thread.Ext.call_stack_summary : "*mscoreei.dll|msi*.tmp|msi.dll*"]
'''

min_endpoint_version = "8.10.0"
reputation = true
[[actions]]
action = "kill_process"
field = "process.entity_id"
state = 0

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

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


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

[internal]
min_endpoint_version = "8.10.0"

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

[rule]
author = ["Elastic"]
description = """
Identifies unusual instances of Control Panel with suspicious keywords or paths in the process command line value.
Adversaries may abuse control.exe to proxy execution of malicious code.
"""
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 = "Control Panel Process with Unusual Arguments"
references = ["https://www.joesandbox.com/analysis/476188/1/html"]
risk_score = 73
rule_id = "416697ae-e468-4093-a93d-59661fa619ec"
severity = "high"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Defense Evasion",
    "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 : "control.exe" and
  process.command_line : (
    "*.jpg*", "*.png*",
    "*.gif*", "*.bmp*",
    "*.jpeg*", "*.TIFF*",
    "*.inf*", "*.cpl:*/*",
    "*../../..*",
    "*/AppData/Local/*",
    "*:\\Users\\Public\\*",
    "*\\AppData\\Local\\*"
)
'''

note = """## Triage and analysis

### Investigating Control Panel Process with Unusual Arguments

#### Possible investigation steps

- Which suspicious argument family did the alert preserve, and what does it imply?
  - Focus: `process.command_line` and `@timestamp`, identifying image or INF targets, ".cpl:" indirection, traversal (".."), "AppData\\Local", or "Users\\Public" fragments.
  - Implication: escalate when Control Panel points at non-applet content, user-writable paths, traversal, or URL-like ".cpl:" loading; lower suspicion only when the path and argument resolve to one recognized vendor applet, driver package, or support workflow.

- Is the alerting binary really the expected Control Panel executable?
  - Focus: `process.executable`, `process.pe.original_file_name`, `process.code_signature.subject_name`, `process.code_signature.trusted`, and `process.hash.sha256`.
  - Implication: escalate if "control.exe" is renamed, unsigned or untrusted, has an unfamiliar hash, or runs outside the Windows system path; Microsoft identity lowers masquerade risk but does not clear the arguments.

- Does the parent and user context fit this launch?
  - Focus: `process.parent.executable`, `process.parent.command_line`, `user.id`, and `user.name`.
  - Implication: Office, browser, script-host, archive-tool, remote-admin, or mismatched-user launches make the command abnormal; keep validating only when parent and user context fit the applet, driver, support, or lab workflow named by the command line.

- Did Control Panel hand off to follow-on execution?
  - Focus: child starts on the same `host.id` where `process.parent.entity_id` equals the alert `process.entity_id`; review child `process.executable`, `process.command_line`, and `process.pe.original_file_name`. $investigate_0
  - Implication: follow-on execution confirms proxy-abuse risk when the chain uses "rundll32.exe" or "Control_RunDLL", or spawns PowerShell, cmd, mshta, regsvr32, wscript, cscript, or another unexpected LOLBin; a clean stop at the expected applet or support component narrows scope.
  - Hint: if `process.entity_id` is absent, recover children with `host.id` + `process.pid` near `@timestamp`; treat ambiguity as unresolved.

- Did the referenced path contain staged or renamed payload content?
  - Focus: file events for `host.id` + `process.entity_id`, or `host.id` + `process.pid` near `@timestamp`; review `file.path`, `file.Ext.original.path`, `file.Ext.header_bytes`, and `file.Ext.windows.zone_identifier`. $investigate_1
  - Implication: escalate when file events show executable or script content, mismatched headers, recent renames, internet provenance, or payloads under "AppData\\Local" or "Users\\Public"; artifacts confined to the same recognized vendor package layout reduce file concern. Missing file telemetry is unresolved, not benign.

- Did the process or host contact delivery or command-and-control infrastructure?
  - Focus: DNS and connection events for `host.id` + `process.entity_id`, or `host.id` + `process.pid` near `@timestamp`; compare DNS `dns.question.name` and `dns.resolved_ip` with `destination.ip` and `destination.port`. $investigate_2
  - Implication: escalate when network events show the same process or host reaching rare external domains, payload hosts, or mismatched service ports after launch; urgency drops only when traffic stays limited to the same recognized vendor or internal service. Missing network telemetry is unresolved, not benign.
  - Hint: separate DNS events from connection events before correlating `dns.resolved_ip` to `destination.ip`.

- If local evidence is suspicious or unresolved, does related alert activity change the user or host scope?
  - Focus: alerts for the same `user.id` showing delivery, persistence, defense evasion, suspicious children, or other proxy-execution utilities such as "rundll32.exe", "mshta.exe", or "regsvr32.exe". $investigate_3
  - Hint: use the host pivot separately for the same patterns on `host.id`, especially when user context is absent or shared. $investigate_4
  - Implication: broaden scope when either pivot shows related delivery, persistence, proxy execution, or repeated suspicious Control Panel launches; keep local only when local evidence is explained and related alerts do not contradict it.

- Escalate when command intent plus any meaningful corroborator indicates proxy execution, staged payloads, unexpected child execution, suspicious destinations, or spread; close only when alert-local process evidence and supported recovery bind the exact activity to one recognized workflow with no contradictions; if evidence is mixed or visibility is incomplete, preserve artifacts and escalate.

### False positive analysis

- Vendor applets, printer/display drivers, hardware-management packages, support troubleshooting, or lab validation can trigger unusual Control Panel paths. Confirm `process.command_line` names the expected CPL or INF target, `process.executable` is the Microsoft system binary, `process.parent.executable` and `process.parent.command_line` match the installer or support component, `user.id` and `host.id` fit the endpoint or lab cohort, artifacts stay inside the vendor package layout, and no suspicious child process or unexpected external destination follows. Use package, change, or lab records only as corroboration; without them, close only when this case's telemetry binds the exact workflow. Treat it as a candidate exception until records or recurrence confirm stability.
- Before creating an exception, validate that the same `process.executable`, `process.parent.executable`, stable `process.command_line` pattern, `user.id`, and `host.id` recur across prior alerts from this rule. Build the exception from that minimum confirmed workflow pattern. Avoid exceptions on "control.exe" alone, on a file extension alone, or on a host alone.

### Response and remediation

- If confirmed benign, reverse any temporary containment and document the command, binary identity, parent workflow, account, host, artifact, and destination evidence that proved one recognized workflow. Create an exception only if that same workflow recurs across prior alerts from this rule.
- If suspicious but unconfirmed, preserve a case export with `process.command_line`, `process.entity_id`, parent and child lineage, referenced artifacts, and network indicators when available before containment. Apply reversible containment first, such as temporary egress restrictions or heightened monitoring on the affected `host.id` and `user.id`, and avoid deleting files or killing child processes until follow-on execution is scoped.
- Do not isolate or suspend based on the alert alone. Escalate suspicious-but-unconfirmed cases to host isolation or account action only when child-process, artifact, network, or related-alert evidence shows likely follow-on execution or broader exposure.
- If confirmed malicious, preserve the same process, artifact, and network evidence before destructive action. Isolate the endpoint to stop further execution while keeping telemetry available; if direct endpoint response is unavailable, hand off the preserved `host.id`, `user.id`, `process.entity_id`, and command-line evidence to the team that can isolate the host or suspend the account.
- After scoping related hosts, users, parent processes, command-line fragments, referenced paths, and follow-on children, quarantine or remove the malicious applets, DLLs, scripts, archives, or dropped artifacts identified during the investigation. Restore affected Control Panel or shell-association paths to the expected baseline and verify no persistence remains.
- Post-incident hardening: restrict document-, script-, and archive-driven launches of Control Panel on privileged or shared systems, retain any file or network telemetry that limited the case, and record the confirmed workflow or malicious artifact pattern for future triage.
"""

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.name",
    "host.id",
    "user.name",
    "user.id",
    "process.entity_id",
    "process.pid",
    "process.executable",
    "process.command_line",
    "process.working_directory",
    "process.pe.original_file_name",
    "process.parent.entity_id",
    "process.parent.name",
    "process.parent.executable",
    "process.parent.command_line",
]

[transform]

[[transform.investigate]]
label = "Child process events for Control Panel"
description = ""
providers = [
  [
    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
    { excluded = false, field = "process.parent.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" },
    { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" }
  ]
]
relativeFrom = "now-1h"
relativeTo = "now"

[[transform.investigate]]
label = "File events for Control Panel"
description = ""
providers = [
  [
    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
    { excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" },
    { excluded = false, field = "event.category", queryType = "phrase", value = "file", valueType = "string" }
  ]
]
relativeFrom = "now-1h"
relativeTo = "now"

[[transform.investigate]]
label = "Network events for Control Panel"
description = ""
providers = [
  [
    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
    { excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" },
    { excluded = false, field = "event.category", queryType = "phrase", value = "network", valueType = "string" }
  ],
  [
    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
    { excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" },
    { excluded = false, field = "event.category", queryType = "phrase", value = "dns", valueType = "string" }
  ]
]
relativeFrom = "now-1h"
relativeTo = "now"

[[transform.investigate]]
label = "Alerts associated with the user"
description = ""
providers = [
  [
    { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
    { excluded = false, field = "user.id", queryType = "phrase", value = "{{user.id}}", valueType = "string" }
  ]
]
relativeFrom = "now-48h/h"
relativeTo = "now"

[[transform.investigate]]
label = "Alerts associated with the host"
description = ""
providers = [
  [
    { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }
  ]
]
relativeFrom = "now-48h/h"
relativeTo = "now"

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

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

[metadata]
creation_date = "2025/07/31"
integration = ["elastic_security"]
maturity = "production"
promotion = true
updated_date = "2025/10/17"

[rule]
author = ["Elastic"]
description = """
Generates a detection alert for each Elastic Security alert written to the configured indices. Enabling this rule allows
you to immediately begin investigating Elastic Security alerts in the app.
"""
from = "now-2m"
index = ["logs-elastic_security.alert-*"]
interval = "1m"
language = "kuery"
license = "Elastic License v2"
max_signals = 1000
name = "Elastic Security External Alerts"
note = """## Triage and analysis

### Investigating Elastic Security External Alerts

The Elastic Security integration facilitates transferring security alert data from another Elasticsearch instance to your own, enabling threats to be investigated in a centralized manner.

### Possible investigation steps

- Correlate the alert with recent activity on the affected endpoint to identify any unusual or suspicious behavior patterns.
- Check for any additional alerts or logs related to the same endpoint or user to determine if this is part of a broader attack or isolated incident.
- Investigate the source and destination IP addresses involved in the alert to assess if they are known to be malicious or associated with previous threats.
- Analyze any files or processes flagged in the alert to determine if they are legitimate or potentially malicious, using threat intelligence sources if necessary.
- Consult the Elastic Security investigation guide and resources tagged in the alert for specific guidance on handling similar threats.

### False positive analysis

- Alerts triggered by routine software updates or patches can be false positives. Review the context of the alert to determine if it aligns with scheduled maintenance activities.
- Legitimate administrative tools or scripts may trigger alerts. Identify and whitelist these tools if they are verified as non-threatening.
- Frequent alerts from known safe applications or processes can be excluded by creating exceptions for these specific behaviors in the Elastic Security configuration.
- Network scanning or monitoring tools used by IT teams might be flagged. Ensure these tools are documented and excluded from triggering alerts if they are part of regular operations.
- User behavior that is consistent with their role but triggers alerts should be reviewed. If deemed non-malicious, adjust the rule to exclude these specific user actions.

### Response and remediation

- Isolate the affected endpoint immediately to prevent lateral movement and further compromise within the network.
- Analyze the specific alert details to identify the nature of the threat and any associated indicators of compromise (IOCs).
- Remove or quarantine any malicious files or processes identified by the Elastic Security alert to neutralize the threat.
- Apply relevant security patches or updates to address any exploited vulnerabilities on the affected endpoint.
- Conduct a thorough scan of the network to identify any additional endpoints that may have been compromised or are exhibiting similar behavior.
- Document the incident and escalate to the appropriate security team or management if the threat is part of a larger attack campaign or if additional resources are needed for remediation.
- Review and update endpoint protection policies and configurations to enhance detection and prevention capabilities against similar threats in the future.
"""
references = ["https://docs.elastic.co/en/integrations/elastic_security"]
risk_score = 47
rule_id = "720fc1aa-e195-4a1d-81d8-04edfe5313ed"
rule_name_override = "kibana.alert.rule.name"
setup = """## Setup

### Elastic Security Alert Integration
This rule is designed to capture alert events generated by the Elastic Security integration and promote them as Elastic detection alerts.

To capture Elastic Security alerts, install and configure the Elastic Security integration to ingest alert events into the `logs-elastic_security.alert-*` index pattern.

If this rule is enabled alongside the External Alerts promotion rule (UUID: eb079c62-4481-4d6e-9643-3ca499df7aaa), you may receive duplicate alerts for the same Elastic Security events. Consider adding a rule exception for the External Alert rule to exclude data_stream.dataset:elastic_security.alert to avoid receiving duplicate alerts.

### Additional notes

For information on troubleshooting the maximum alerts warning please refer to this [guide](https://www.elastic.co/guide/en/security/current/alerts-ui-monitor.html#troubleshoot-max-alerts).
"""
severity = "medium"
tags = [
    "Data Source: Elastic Security",
    "Use Case: Threat Detection",
    "Resources: Investigation Guide",
    "Promotion: External Alerts",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
event.kind: alert and data_stream.dataset: elastic_security.alert
'''


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

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

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

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

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

[rule]
description = """
Identifies execution of the Apple script interpreter (osascript) without a password prompt with administrator privileges
and from unsigned or untrusted parent process.
"""
id = "f17c8dcf-d65f-479a-b047-3558233f774e"
license = "Elastic License v2"
name = "Elevated Apple Script Execution via Unsigned Parent"
os_list = ["macos"]
reference = ["https://discussions.apple.com/thread/2266150"]
version = "1.0.26"

query = '''
sequence with maxspan=1m
 [process where event.action == "exec" and
  (process.code_signature.trusted == false or process.code_signature.exists == false)] by process.entity_id
 [process where event.action == "exec" and (process.name in ("osascript", "sh", "bash", "zsh", "dash", "csh", "tcsh", "ksh", "tclsh", "fish") or process.name like "tclsh*") and
  process.command_line like~ "*osascript*with administrator privileges*"] by process.parent.entity_id
'''

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

[[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.tactic]
id = "TA0002"
name = "Execution"
reference = "https://attack.mitre.org/tactics/TA0002/"
[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1548"
name = "Abuse Elevation Control Mechanism"
reference = "https://attack.mitre.org/techniques/T1548/"


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

[internal]
min_endpoint_version = "8.1.0"

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

[rule]
author = ["Elastic"]
description = """
Detects potentially suspicious OAuth authorization activity in Microsoft Entra ID where first-party Microsoft
applications from the FOCI (Family of Client IDs) group request access to Microsoft Graph or legacy Azure AD resources.
Developer tools like Azure CLI, Visual Studio Code, and Azure PowerShell accessing these resources are flagged, as they
are commonly abused in phishing campaigns like ConsentFix. Additionally, any FOCI family application accessing the
deprecated Windows Azure Active Directory resource is flagged since this API is rarely used legitimately and attackers
target it for stealth. First-party apps are trusted by default in all tenants and cannot be blocked, making them ideal
for OAuth phishing attacks.
"""
from = "now-9m"
index = ["filebeat-*", "logs-azure.signinlogs-*"]
language = "kuery"
license = "Elastic License v2"
name = "Entra ID OAuth Phishing via First-Party Microsoft Application"
note = """## Triage and analysis

### Investigating Entra ID OAuth Phishing via First-Party Microsoft Application

This rule detects OAuth authorization activity where FOCI (Family of Client IDs) applications access Microsoft Graph or legacy Azure AD resources. Adversaries exploit these trusted first-party apps in phishing campaigns like ConsentFix to steal authorization codes and exchange them for tokens from attacker infrastructure. Because first-party apps are pre-consented and cannot be blocked, attackers use them to bypass consent prompts and access user data without triggering typical OAuth alerts.

The rule uses split detection logic: developer tools (Azure CLI, VSCode, PowerShell) accessing either Graph or legacy AAD are flagged, while any FOCI app accessing legacy AAD is flagged since this deprecated API is rarely used legitimately and attackers target it for stealth.

### Possible investigation steps

- Review `azure.signinlogs.properties.user_principal_name` to identify the affected user and determine if they are a high-value target (privileged roles, executives, IT admins).
- Analyze `source.ip` and `source.geo.*` for geographic anomalies. ConsentFix attackers exchange codes from different IPs than the victim's location.
- Check `azure.signinlogs.properties.app_display_name` to confirm which first-party application was used. Azure CLI or PowerShell access by non-developers is suspicious.
- Examine `azure.signinlogs.properties.resource_id` to identify the target resource. Legacy AAD (`00000002-0000-0000-c000-000000000000`) access is unusual for most users.
- Review `azure.signinlogs.properties.is_interactive` - non-interactive sign-ins shortly after interactive ones from different IPs indicate token replay.
- Correlate with other sign-in events using `azure.signinlogs.properties.session_id` to identify the full OAuth flow sequence.
- Pivot to `azure.graphactivitylogs` to search for subsequent Graph API activity from the same session or user from unusual locations.
- Check `azure.auditlogs` for device registration events around the same timeframe, which may indicate persistence attempts.

### False positive analysis

- Developers or IT administrators legitimately using Azure CLI, PowerShell, or VS Code to access Microsoft Graph or Azure AD.
- Enterprise automation or CI/CD pipelines using these tools with user-delegated permissions.
- Users working from multiple locations (VPN, travel) may show different IPs.
- Consider excluding known developer machines, managed devices, or specific user groups that regularly use these tools.
- Maintain an allowlist of expected source IPs tied to corporate infrastructure or developer environments.

### Response and remediation

- Contact the user immediately to confirm if they initiated the OAuth flow and used the detected application.
- If unauthorized, revoke all refresh tokens for the user via Microsoft Entra ID portal or PowerShell.
- Review the user's recent Microsoft Graph activity (email access, file downloads, Teams messages) for signs of data exfiltration.
- Block the source IP if confirmed malicious.
- Check for any devices registered during this session via `azure.auditlogs` and remove unauthorized device registrations.
- Implement Conditional Access policies to restrict OAuth flows for these applications to compliant devices only.
- Educate users about OAuth phishing and the risks of pasting authorization codes into websites.
"""
references = [
    "https://docs.microsoft.com/en-us/azure/active-directory/reports-monitoring/reference-azure-monitor-sign-ins-log-schema",
    "https://www.volexity.com/blog/2025/04/22/phishing-for-codes-russian-threat-actors-target-microsoft-365-oauth-workflows/",
    "https://pushsecurity.com/blog/consentfix",
    "https://github.com/secureworks/family-of-client-ids-research",
]
risk_score = 47
rule_id = "14fa0285-fe78-4843-ac8e-f4b481f49da9"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Data Source: Azure",
    "Data Source: Microsoft Entra ID",
    "Data Source: Microsoft Entra ID Sign-in Logs",
    "Use Case: Identity and Access Audit",
    "Resources: Investigation Guide",
    "Tactic: Initial Access",

]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset: "azure.signinlogs" and
event.action: "Sign-in activity" and
event.outcome: "success" and
(
  (
    azure.signinlogs.properties.app_id: (
      "aebc6443-996d-45c2-90f0-388ff96faa56" or
      "04b07795-8ddb-461a-bbee-02f9e1bf7b46" or
      "1950a258-227b-4e31-a9cf-717495945fc2"
    ) and (
      azure.signinlogs.properties.resource_id: ("00000003-0000-0000-c000-000000000000" or "00000002-0000-0000-c000-000000000000") or
      azure.signinlogs.properties.resource_display_name: ("Microsoft Graph" or "Windows Azure Active Directory")
    )
  ) or
  (
    azure.signinlogs.properties.app_id: (
      "00b41c95-dab0-4487-9791-b9d2c32c80f2" or
      "1fec8e78-bce4-4aaf-ab1b-5451cc387264" or
      "26a7ee05-5602-4d76-a7ba-eae8b7b67941" or
      "27922004-5251-4030-b22d-91ecd9a37ea4" or
      "4813382a-8fa7-425e-ab75-3b753aab3abb" or
      "ab9b8c07-8f02-4f72-87fa-80105867a763" or
      "872cd9fa-d31f-45e0-9eab-6e460a02d1f1" or
      "af124e86-4e96-495a-b70a-90f90ab96707" or
      "2d7f3606-b07d-41d1-b9d2-0d0c9296a6e8" or
      "844cca35-0656-46ce-b636-13f48b0eecbd" or
      "87749df4-7ccf-48f8-aa87-704bad0e0e16" or
      "cf36b471-5b44-428c-9ce7-313bf84528de" or
      "0ec893e0-5785-4de6-99da-4ed124e5296c" or
      "22098786-6e16-43cc-a27d-191a01a1e3b5" or
      "4e291c71-d680-4d0e-9640-0a3358e31177" or
      "57336123-6e14-4acc-8dcf-287b6088aa28" or
      "57fcbcfa-7cee-4eb1-8b25-12d2030b4ee0" or
      "66375f6b-983f-4c2c-9701-d680650f588f" or
      "a40d7d7d-59aa-447e-a655-679a4107e548" or
      "a569458c-7f2b-45cb-bab9-b7dee514d112" or
      "b26aadf8-566f-4478-926f-589f601d9c74" or
      "c0d2a505-13b8-4ae0-aa9e-cddd5eab0b12" or
      "d326c1ce-6cc6-4de2-bebc-4591e5e13ef0" or
      "e9c51622-460d-4d3d-952d-966a5b1da34c" or
      "eb539595-3fe1-474e-9c1d-feb3625d1be5" or
      "ecd6b820-32c2-49b6-98a6-444530e5a77a" or
      "f05ff7c9-f75a-4acd-a3b5-f4b6a870245d" or
      "f44b1140-bc5e-48c6-8dc0-5cf5a53c0e34" or
      "be1918be-3fe3-4be9-b32b-b542fc27f02e" or
      "cab96880-db5b-4e15-90a7-f3f1d62ffe39" or
      "d7b530a4-7680-4c23-a8bf-c52c121d2e87" or
      "dd47d17a-3194-4d86-bfd5-c6ae6f5651e3" or
      "e9b154d0-7658-433b-bb25-6b8e0a8a7c59"
    ) and (
      azure.signinlogs.properties.resource_id: "00000002-0000-0000-c000-000000000000" or
      azure.signinlogs.properties.resource_display_name: "Windows Azure Active Directory"
    )
  )
)
'''


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

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

[[rule.threat.technique]]
id = "T1199"
name = "Trusted Relationship"
reference = "https://attack.mitre.org/techniques/T1199/"

[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 = "T1528"
name = "Steal Application Access Token"
reference = "https://attack.mitre.org/techniques/T1528/"

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

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

[[rule.threat.technique]]
id = "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]
description = """
Detects when a file is cloned by an unsigned or untrusted process. Cloning of files is highly abnormal but especially so
when done by an unsigned or untrusted process to duplicate a file or payload via api call.
"""
id = "aac13c8f-fd32-43c8-b71c-85019ad6fe50"
license = "Elastic License v2"
name = "File Cloned by Unsigned or Untrusted Process"
os_list = ["macos"]
version = "1.0.4"

query = '''
file where event.action == "clone" and 
 (process.code_signature.exists == false or process.code_signature.trusted == false)
'''

min_endpoint_version = "8.11.1"
optional_actions = []
[[actions]]
action = "kill_process"
field = "Effective_process.executable"
state = 0

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

[[threat]]
framework = "MITRE ATT&CK"
[[threat.technique]]
id = "T1559"
name = "Inter-Process Communication"
reference = "https://attack.mitre.org/techniques/T1559/"


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

[internal]
min_endpoint_version = "8.11.1"

[metadata]
creation_date = "2023/09/11"
integration = ["github"]
maturity = "production"
updated_date = "2026/04/10"

[rule]
author = ["Elastic"]
description = """
This rule detects when a member is granted the organization owner role of a GitHub organization. This role provides
admin level privileges. Any new owner role should be investigated to determine its validity. Unauthorized owner roles
could indicate compromise within your organization and provide unlimited access to data and settings.
"""
from = "now-9m"
index = ["logs-github.audit-*"]
language = "eql"
license = "Elastic License v2"
name = "GitHub Owner Role Granted To User"
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 GitHub Owner Role Granted To User

In GitHub organizations, the owner role grants comprehensive administrative privileges, enabling full control over repositories, settings, and data. Adversaries may exploit this by elevating privileges to maintain persistence or exfiltrate data. The detection rule monitors audit logs for changes in member roles to 'admin', signaling potential unauthorized access or privilege escalation attempts, thus aiding in early threat identification.

### Possible investigation steps

- Review the audit logs for the specific event where the member's role was changed to 'admin' to identify the user who made the change and the user who received the new role.
- Verify the legitimacy of the role change by contacting the user who was granted the owner role and the user who performed the action to confirm if the change was authorized.
- Check the organization's recent activity logs for any unusual or suspicious actions performed by the user who was granted the owner role, such as changes to repository settings or data access.
- Investigate any recent changes in the organization's membership or permissions that could indicate a broader compromise or unauthorized access.
- Assess the potential impact of the role change by identifying sensitive repositories or data that the new owner role could access, and determine if any data exfiltration or unauthorized changes have occurred.

### False positive analysis

- Role changes due to organizational restructuring or legitimate promotions can trigger alerts. Regularly update the list of expected role changes to minimize unnecessary alerts.
- Automated scripts or integrations that manage user roles might inadvertently trigger the rule. Identify and whitelist these scripts to prevent false positives.
- Temporary role assignments for project-specific tasks can be mistaken for unauthorized access. Implement a process to document and pre-approve such temporary changes.
- Changes made by trusted administrators during routine audits or maintenance may be flagged. Maintain a log of scheduled maintenance activities to cross-reference with alerts.
- Onboarding processes that involve granting admin roles to new employees can generate alerts. Ensure that onboarding procedures are documented and known exceptions are configured in the detection system.

### Response and remediation

- Immediately revoke the owner role from the user account identified in the alert to prevent further unauthorized access or changes.
- Conduct a thorough review of recent activities performed by the user with the elevated privileges to identify any unauthorized changes or data access.
- Reset the credentials and enforce multi-factor authentication for the affected user account to secure it against further compromise.
- Notify the security team and relevant stakeholders about the potential breach and involve them in the investigation and remediation process.
- Review and update access control policies to ensure that owner roles are granted only through a formal approval process and are regularly audited.
- Implement additional monitoring and alerting for changes to high-privilege roles within the organization to detect similar threats in the future."""
risk_score = 47
rule_id = "9b343b62-d173-4cfd-bd8b-e6379f964ca4"
severity = "medium"
tags = [
    "Domain: Cloud",
    "Use Case: Threat Detection",
    "Use Case: UEBA",
    "Tactic: Persistence",
    "Data Source: Github",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"

query = '''
iam where data_stream.dataset == "github.audit" and event.action == "org.update_member" and github.permission == "admin"
'''


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

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

[[rule.threat.technique.subtechnique]]
id = "T1098.003"
name = "Additional Cloud Roles"
reference = "https://attack.mitre.org/techniques/T1098/003/"

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

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

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

[[rule.threat.technique.subtechnique]]
id = "T1098.003"
name = "Additional Cloud Roles"
reference = "https://attack.mitre.org/techniques/T1098/003/"

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

[metadata]
creation_date = "2022/09/06"
integration = ["google_workspace"]
maturity = "production"
updated_date = "2026/05/22"

[rule]
author = ["Elastic"]
description = """
Users in Google Workspace are typically assigned a specific organizational unit that grants them permissions to certain
services and roles that are inherited from this organizational unit. Adversaries may compromise a valid account and
change which organizational account the user belongs to which then could allow them to inherit permissions to
applications and resources inaccessible prior to.
"""
false_positives = [
    """
    Google Workspace administrators may change which organizational unit a user belongs to as a result of internal role
    adjustments.
    """,
]
from = "now-130m"
index = ["filebeat-*", "logs-google_workspace.admin-*"]
interval = "10m"
language = "kuery"
license = "Elastic License v2"
name = "Google Workspace User Organizational Unit Changed"
note = """## Triage and analysis

### Investigating Google Workspace User Organizational Unit Changed

An organizational unit is a group that an administrator can create in the Google Admin console to apply settings to a specific set of users for Google Workspace. By default, all users are placed in the top-level (parent) organizational unit. Child organizational units inherit the settings from the parent but can be changed to fit the needs of the child organizational unit.

Permissions and privileges for users are often inherited from the organizational unit they are placed in. Therefore, if a user is changed to a separate organizational unit, they will inherit all privileges and permissions. User accounts may have unexpected privileges when switching organizational units that would allow a threat actor to gain a stronger foothold within the organization. The principle of least privileged (PoLP) should be followed when users are switched to different groups in Google Workspace.

This rule identifies when a user has been moved to a different organizational unit.

### Possible investigation steps

- Identify the associated user accounts by reviewing `user.name` or `user.email` fields in the alert.
  - The `user.target.email` field contains the user that had their assigned organizational unit switched.
- Identify the user's previously assigned unit and new organizational unit by checking the `google_workspace.admin.org_unit.name` and `google_workspace.admin.new_value` fields.
- Identify Google Workspace applications whose settings were explicitly set for this organizational unit.
    - Search for `event.action` is `CREATE_APPLICATION_SETTING` where `google_workspace.admin.org_unit.name` is the new organizational unit.
- After identifying the involved user, verify administrative privileges are scoped properly to allow changing user organizational units.
- Identify if the user account was recently created by searching for `event.action: CREATE_USER`.
  - Add `user.email` with the target user account that recently had their organizational unit changed.
- Filter on `user.name` or `user.target.email` of the user who took this action and review the last 48 hours of activity for anything that may indicate a compromise.

### False positive analysis

- After identifying the user account that changed another user's organizational unit, verify the action was intentional.
- Verify whether the target user who received this update is expected to inherit privileges from the new organizational unit.
- Review potential maintenance notes or organizational changes. They might explain why a user's organization was changed.

### Response and remediation

- Initiate the incident response process based on the outcome of the triage.
- Disable or limit the account during the investigation and response.
- Identify the possible impact of the incident and prioritize accordingly; the following actions can help you gain context:
    - Identify the account role in the cloud environment.
    - Assess the criticality of affected services and servers.
    - Work with your IT team to identify and minimize the impact on users.
    - Identify if the attacker is moving laterally and compromising other accounts, servers, or services.
    - Identify any regulatory or legal ramifications related to this activity.
- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords or delete API keys as needed to revoke the attacker's access to the environment. Work with your IT teams to minimize the impact on business operations during these actions.
- Review the permissions assigned to the implicated user to ensure that the least privilege principle is being followed.
- Implement security best practices [outlined](https://support.google.com/a/answer/7587183) by Google.
- Determine the initial vector abused by the attacker and take action to prevent reinfection via the same vector.
- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).

## Setup

The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.

### Important Information Regarding Google Workspace Event Lag Times
- As per Google's documentation, Google Workspace administrators may observe lag times ranging from minutes up to 3 days between the time of an event's occurrence and the event being visible in the Google Workspace admin/audit logs.
- This rule is configured to run every 10 minutes with a lookback time of 130 minutes.
- To reduce the risk of false negatives, consider reducing the interval that the Google Workspace (formerly G Suite) Filebeat module polls Google's reporting API for new events.
- By default, `var.interval` is set to 2 hours (2h). Consider changing this interval to a lower value, such as 10 minutes (10m).
- See the following references for further information:
  - https://support.google.com/a/answer/7061566
  - https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-module-google_workspace.html"""
references = [
    "https://support.google.com/a/answer/6328701?hl=en#",
    "https://www.elastic.co/security-labs/google-workspace-attack-surface-part-one",
    "https://www.elastic.co/security-labs/google-workspace-attack-surface-part-two",
]
risk_score = 21
rule_id = "cc6a8a20-2df2-11ed-8378-f661ea17fbce"
severity = "low"
tags = [
    "Domain: Cloud",
    "Data Source: Google Workspace",
    "Use Case: Configuration Audit",
    "Tactic: Persistence",
    "Tactic: Privilege Escalation",
    "Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "query"

query = '''
data_stream.dataset:"google_workspace.admin" and google_workspace.event.type:"USER_SETTINGS" and event.action:"MOVE_USER_TO_ORG_UNIT"
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1098"
name = "Account Manipulation"
reference = "https://attack.mitre.org/techniques/T1098/"
[[rule.threat.technique.subtechnique]]
id = "T1098.003"
name = "Additional Cloud Roles"
reference = "https://attack.mitre.org/techniques/T1098/003/"



[rule.threat.tactic]
id = "TA0003"
name = "Persistence"
reference = "https://attack.mitre.org/tactics/TA0003/"
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1098"
name = "Account Manipulation"
reference = "https://attack.mitre.org/techniques/T1098/"
[[rule.threat.technique.subtechnique]]
id = "T1098.003"
name = "Additional Cloud Roles"
reference = "https://attack.mitre.org/techniques/T1098/003/"



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

[rule.investigation_fields]
field_names = [
    "@timestamp",
    "user.name",
    "user.email",
    "source.ip",
    "google_workspace.actor.type",
    "user.target.email",
    "google_workspace.admin.org_unit.name",
    "google_workspace.admin.new_value",
    "event.action",
    "cloud.account.id",
]

[metadata]
creation_date = "2026/07/02"
integration = ["endpoint", "sentinel_one_cloud_funnel"]
maturity = "production"
updated_date = "2026/07/06"

[rule]
author = ["Elastic"]
description = """
Detects applications making a curl request to a known public IP address lookup web service. Malware tends to perform this 
action to assess potential targets.
"""
from = "now-9m"
index = [
        "logs-endpoint.events.process*",
        "logs-sentinel_one_cloud_funnel.*",
]
language = "eql"
license = "Elastic License v2"
name = "Linux External IP Address Discovery via Curl"
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 Linux External IP Address Discovery via Curl

This rule flags a Linux process that uses curl to contact public IP lookup sites, a common way malware learns the host’s internet-facing address before choosing follow-on actions. An attacker who gains shell access on a server or container may run curl against services like ifconfig.me or ipify, then use the returned address to verify outbound reachability, tailor command-and-control, or decide whether the system sits behind cloud or NAT infrastructure.

### Possible investigation steps

- Trace the full process ancestry and nearby commands to determine whether the curl execution came from an interactive shell, scheduled task, deployment script, container entrypoint, or an unexpected program launched from a writable path.
- Review the invoked URL, arguments, working directory, and any captured output to determine whether the request was a one-off connectivity check or part of a broader script performing follow-on discovery, download, or beaconing.
- Correlate the activity with the initiating account, TTY/session details, recent SSH and sudo events, and change records to quickly separate approved administrator troubleshooting from suspicious post-compromise behavior.
- Pivot to surrounding network activity from the same host to identify repeated lookups, subsequent outbound connections to unfamiliar infrastructure, or signs of staging and command-and-control immediately after the public IP query.
- Inspect the parent script or binary on disk for recent creation or modification, unusual persistence mechanisms, and prevalence on peer systems to assess whether the behavior is tied to malware, a rogue change, or benign automation.

### False positive analysis

- Legitimate startup, login-banner, or scheduled maintenance scripts may use curl to learn the host’s public IP for configuration or status display, so verify the parent script or service path is expected, recently approved, and consistently seen at boot or on a routine schedule.
- An administrator or engineer may manually run curl to a public IP lookup site during troubleshooting or deployment validation, so confirm the initiating user, TTY or session context, and shell history align with authorized activity and that no suspicious follow-on commands occurred.

### Response and remediation

- Isolate the affected Linux host or container from the network immediately, allow only a secured management path, and preserve volatile evidence such as the running parent process, shell history, and the script or binary that launched curl.
- Terminate the malicious process chain and remove persistence by inspecting and cleaning cron jobs, systemd unit files, rc.local, user shell profiles, container entrypoints, SSH authorized_keys, and any attacker files staged in writable locations such as /tmp, /var/tmp, or /dev/shm.
- Rotate credentials and secrets exposed to the compromised system, including SSH keys, API tokens, cloud instance credentials, and application secrets found in scripts, environment files, or shell history.
- Restore the asset to a known-good state by rebuilding from a trusted image or clean backup and validating startup scripts, packages, and container images before returning the system to production.
- Escalate to incident response and broaden scoping across peer systems if the IP lookup was followed by downloads, reverse shells, new outbound connections to unfamiliar infrastructure, or if the same parent script, binary, or persistence artifact appears on multiple hosts.
- Harden the environment by restricting outbound curl access to approved destinations, blocking public IP lookup services where not needed, limiting execution from writable directories, and adding detections for unexpected systemd, cron, and shell-profile modifications.
"""
risk_score = 21
rule_id = "996e2e09-087e-4e99-a3cc-a9225d24ba3d"
setup = """## Setup

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

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

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

#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
- Go to the Kibana home page and click "Add integrations".
- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
- Click "Add Elastic Defend".
- Configure the integration name and optionally add a description.
- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).
- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead.
For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
- Click "Save and Continue".
- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts.
For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
"""
severity = "low"
tags = [
  "Domain: Endpoint",
  "OS: Linux",
  "Use Case: Threat Detection",
  "Tactic: Discovery",
  "Data Source: Elastic Defend",
  "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", "start") and
process.name == "curl" and (
  process.parent.name like ".*" or process.parent.executable like (
    "/tmp/*", "/var/tmp/*", "/dev/shm/*", "/opt/*",  "/etc/*", "./*", "/run/user/*", "/var/run/user/*",
    "/usr/bin/*", "/bin/*", "/usr/local/bin/*", "/sbin/*", "/usr/sbin/*", "/usr/local/sbin/*",
    "/usr/lib/*", "/usr/local/lib/*", "/lib/*", "/lib64/*", "/usr/lib64/*", "/usr/local/lib64/*"
  )
) and
process.command_line like~ (
  "*ip-api.com*", "*checkip.dyndns.org*", "*api.ipify.org*", "*whatismyip.akamai.com*", "*bot.whatismyipaddress.com*",
  "*ifcfg.me*", "*ifconfig.me*", "*ident.me*", "*ipof.in*", "*ip.tyk.nu*", "*icanhazip.com*", "*curlmyip.com*",
  "*wgetip.com*", "*eth0.me*", "*ipecho.net*", "*ip.appspot.com*", "*api.myip.com*", "*geoiptool.com*", "*api.2ip.ua*",
  "*api.ip.sb*", "*ipinfo.io*", "*checkip.amazonaws.com*", "*wtfismyip.com*", "*iplogger.*", "*freegeoip.net*",
  "*freegeoip.app*", "*geoplugin.net*", "*myip.dnsomatic.com*", "*www.geoplugin.net*",
  "*api64.ipify.org*", "*ip4.seeip.org*", "*.geojs.io*", "*portmap.io*", "*api.db-ip.com*",
  "*geolocation-db.com*", "*httpbin.org*", "*myip.opendns.com*", "*ipv4.icanhazip.com*", "*ipv6.icanhazip.com*"
) and
not (
  process.parent.name in ("jamf", "make") or
  process.parent.name in (".", "./alert_api_call.sh", "nvim", "teleport") or
  process.parent.executable like (
    "/usr/local/bin/teleport", "/usr/local/bin/current_ip", "/tmp/go-build*", "/usr/bin/neofetch",
    "/usr/bin/show-location-info", "/opt/tpot/bin/myip.sh", "/usr/sbin/sshd", "/tmp/newroot/var/quest/kace/scripts/*",
    "./Linux_Inventory_Sheets.sh", "/opt/qvm/bin/update_info_qsuite", "/usr/lib/check_mk_agent/local/public_ip_check",
    "/opt/teleport/system/bin/teleport", "/opt/Elastic/Endpoint/elastic-endpoint", "/etc/update-motd.d/motd.sh",
    "/opt/coe/cadence/IC231/tools.lnx86/cda/bin/64bit/cda.exe", "/etc/update-motd.d/10-armbian-header",
    "/opt/saltstack/salt/bin/python*", "/usr/bin/python*", "/usr/local/bin/detect-external-ip"
  ) or
  process.parent.args in ("/var/www/html/admin/modules/leucoalarm/scripts/system.php", "/etc/cont-init.d/50-ddns") or
  (
    process.parent.executable == "/usr/bin/java" and
    process.args like "/opt/streamsets-datacollector/libexec/bootstrap-libs/*"
  ) or
  process.parent.command_line == "runc init" or
  (
    process.parent.executable == "/usr/bin/busybox" and
    (process.parent.command_line == "sh /etc/cont-init.d/50-ddns" or process.working_directory == "/opt/outline-server")
  )
)
'''

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

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

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

[metadata]
creation_date = "2026/02/19"
maturity = "production"
min_stack_comments = "ES|QL inline stats became generally available in 9.3.0"
min_stack_version = "9.3.0"
updated_date = "2026/04/10"

[rule]
author = ["Elastic"]
description = """
Identifies hosts that triggered multiple distinct Elastic Defend behavior rules, while reducing false positives by
considering only behavior rules that appear on a single host globally (via INLINE STATS). Hosts with two or more
such rare behavior rules are more likely to be compromised and warrant prioritized triage.
"""
from = "now-60m"
interval = "30m"
language = "esql"
license = "Elastic License v2"
name = "Multiple Rare Elastic Defend Behavior Rules by Host"
risk_score = 99
rule_id = "c4f7a2b1-5d8e-4c3a-9b6e-2f1a0d8c7e5b"
severity = "critical"
tags = ["Use Case: Threat Detection", "Rule Type: Higher-Order Rule", "Resources: Investigation Guide", "Data Source: Elastic Defend"]
timestamp_override = "event.ingested"
type = "esql"

query = '''
from logs-endpoint.alerts-* metadata _id
| where data_stream.dataset == "endpoint.alerts" and event.code == "behavior"
| INLINE STATS hosts = COUNT_DISTINCT(host.id) BY rule.name
// excludes rules triggering on multiple hosts to reduce potential FPs
| where hosts == 1
| stats Esql.rule_name_count_distinct = COUNT_DISTINCT(rule.name),
        Esql.rule_name_values = VALUES(rule.name),
        Esql.process_executable_values = VALUES(process.executable),
        Esql.process_parent_executable_values = VALUES(process.parent.executable),
        Esql.process_command_line_values = VALUES(process.command_line),
		Esql.process_parent_command_line_values = VALUES(process.parent.command_line),
        Esql.process_hash_sha256_values = VALUES(process.hash.sha256), 
		Esql.file_path_values = VALUES(file.path),
        Esql.dll_path_values = VALUES(dll.path),
        Esql.dll_hash_sha256_values = VALUES(dll.hash.sha256), 
		Esql.user_name_values = VALUES(user.name) by host.id
// at least 2 unique rules
| where Esql.rule_name_count_distinct >= 2
// populate fields to use in rule exceptions
| eval process.hash.sha256 = MV_FIRST(Esql.process_hash_sha256_values),
       process.executable = MV_FIRST(Esql.process_executable_values),
       process.parent.executable = MV_FIRST(Esql.process_parent_executable_values),
       process.command_line = MV_FIRST(Esql.process_command_line_values),
       user.name = MV_FIRST(Esql.user_name_values)
| Keep host.id, user.name, process.executable, process.parent.executable, process.hash.sha256, process.command_line, Esql.*
'''
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 Multiple Rare Elastic Defend Behavior Rules by Host

This rule correlates Elastic Defend behavior alerts by host and applies a global prevalence filter: only behavior rules that fire on a single host in the lookback window are considered. Hosts that trigger two or more such rare behavior rules are flagged, as this pattern is more likely to indicate real compromise than commonly seen behavior rules.

### Possible investigation steps

- Review the listed behavior rule names and the associated process command lines (and parent command lines) to understand what actions triggered the alerts.
- Identify the user(s) associated with the activity and confirm whether the behavior is expected for that role or host.
- Correlate with other endpoint and network data for the host (process, network, file events) to assess scope and persistence.
- Compare timestamps of the alerts to determine if activity is part of a single campaign or staged execution.

### False positive analysis

- The global prevalence filter (rules seen on only one host) reduces noise from behavior rules that fire widely (e.g., common software or policy). If legitimate single-host tools or scripts trigger multiple rare behavior rules, consider documenting and excluding known-good rule names or hosts.
- Development or testing hosts may exhibit multiple rare behaviors; consider lowering severity or excluding those hosts if appropriate.

### Response and remediation

- Isolate the host if triage indicates compromise, then follow standard incident response procedures.
- Collect and preserve artifacts (process hashes, command lines, files) for further analysis.
- Escalate to the security team for full investigation and potential containment or eradication actions.
"""
references = [
"https://www.elastic.co/docs/reference/query-languages/esql/commands/inlinestats-by", 
"https://github.com/elastic/protections-artifacts/tree/main/behavior"
]

[metadata]
creation_date = "2020/02/18"
integration = ["endpoint", "windows"]
maturity = "production"
updated_date = "2026/05/04"

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

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

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

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


[rule]
author = ["Elastic"]
description = """
Identifies the native Windows tools regsvr32.exe, regsvr64.exe, RegSvcs.exe, or RegAsm.exe making a network connection.
This may be indicative of an attacker bypassing allowlists or running arbitrary scripts via a signed Microsoft binary.
"""
false_positives = [
    """
    Security testing may produce events like this. Activity of this kind performed by non-engineers and ordinary users
    is unusual.
    """,
]
from = "now-9m"
index = [
    "winlogbeat-*",
    "logs-endpoint.events.process-*",
    "logs-endpoint.events.network-*",
    "logs-windows.sysmon_operational-*",
]
language = "eql"
license = "Elastic License v2"
name = "Network Connection via Registration Utility"
note = """## Triage and analysis

### Investigating Network Connection via Registration Utility

By examining the specific traits of Windows binaries -- such as process trees, command lines, network connections, registry modifications, and so on -- it's possible to establish a baseline of normal activity. Deviations from this baseline can indicate malicious activity such as masquerading, and deserve further investigation.

This rule looks for the execution of `regsvr32.exe`, `RegAsm.exe`, or `RegSvcs.exe` utilities followed by a network connection to an external address. Attackers can abuse utilities to execute malicious files or masquerade as those utilities in order to bypass detections and evade defenses.

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

#### Possible investigation steps

- Investigate other alerts associated with the user/host during the past 48 hours.
- Investigate the process execution chain (parent process tree) for unknown processes. Examine their executable files for prevalence, whether they are located in expected locations, and if they are signed with valid digital signatures.
  - Investigate any abnormal behavior by the subject process such as network connections, registry or file modifications, and any spawned child processes.
  - Investigate the file digital signature and process original filename, if suspicious, treat it as potential malware.
- Investigate the target host that the signed binary is communicating with.
  - Check if the domain is newly registered or unexpected.
  - Check the reputation of the domain or IP address.
- Assess whether this behavior is prevalent in the environment by looking for similar occurrences across hosts.
- Examine the host for derived artifacts that indicate suspicious activities:
  - Analyze the process executable using a private sandboxed analysis system.
  - Observe and collect information about the following activities in both the sandbox and the alert subject host:
    - Attempts to contact external domains and addresses.
      - Use the Elastic Defend network events to determine domains and addresses contacted by the subject process by filtering by the process' `process.entity_id`.
      - Examine the DNS cache for suspicious or anomalous entries.
        - $osquery_0
    - Use the Elastic Defend registry events to examine registry keys accessed, modified, or created by the related processes in the process tree.
    - Examine the host services for suspicious or anomalous entries.
      - $osquery_1
      - $osquery_2
      - $osquery_3
  - Retrieve the files' SHA-256 hash values using the PowerShell `Get-FileHash` cmdlet and search for the existence and reputation of the hashes in resources like VirusTotal, Hybrid-Analysis, CISCO Talos, Any.run, etc.

### False positive analysis

- If this activity is expected and noisy in your environment, consider adding exceptions — preferably with a combination of destination IP address and command line conditions.

### 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.
- Remove and block malicious artifacts identified during triage.
- Run a full antimalware scan. This may reveal additional artifacts left in the system, persistence mechanisms, and malware components.
- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.
- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).
"""

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:

- [Sysmon Event ID 1 - Process Creation](https://ela.st/sysmon-event-1-setup)
- [Sysmon Event ID 3 - Network Connection](https://ela.st/sysmon-event-3-setup)
"""

references = ["https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml"]
risk_score = 21
rule_id = "fb02b8d3-71ee-4af1-bacd-215d23f17efa"
severity = "low"
tags = [
    "Domain: Endpoint",
    "OS: Windows",
    "Use Case: Threat Detection",
    "Tactic: Execution",
    "Tactic: Defense Evasion",
    "Resources: Investigation Guide",
    "Data Source: Elastic Defend",
    "Data Source: Sysmon",
]
type = "eql"

query = '''
sequence by process.entity_id
  [process where host.os.type == "windows" and event.type == "start" and
   process.name : ("regsvr32.exe", "RegAsm.exe", "RegSvcs.exe") and
   not (
         (?process.Ext.token.integrity_level_name : "System" or ?winlog.event_data.IntegrityLevel : "System") and
         (process.parent.name : "msiexec.exe" or process.parent.executable : ("C:\\Program Files (x86)\\*.exe", "C:\\Program Files\\*.exe"))
       )
   ]
  [network where host.os.type == "windows" and process.name : ("regsvr32.exe", "RegAsm.exe", "RegSvcs.exe")  and
   not cidrmatch(destination.ip, "10.0.0.0/8", "127.0.0.0/8", "169.254.0.0/16", "172.16.0.0/12", "192.0.0.0/24",
       "192.0.0.0/29", "192.0.0.8/32", "192.0.0.9/32", "192.0.0.10/32", "192.0.0.170/32", "192.0.0.171/32",
       "192.0.2.0/24", "192.31.196.0/24", "192.52.193.0/24", "192.168.0.0/16", "192.88.99.0/24", "224.0.0.0/4",
       "100.64.0.0/10", "192.175.48.0/24","198.18.0.0/15", "198.51.100.0/24", "203.0.113.0/24", "240.0.0.0/4", "::1",
       "FE80::/10", "FF00::/8") and network.protocol != "dns"]
'''


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

[rule.threat.tactic]
id = "TA0002"
name = "Execution"
reference = "https://attack.mitre.org/tactics/TA0002/"
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1218"
name = "System Binary Proxy Execution"
reference = "https://attack.mitre.org/techniques/T1218/"
[[rule.threat.technique.subtechnique]]
id = "T1218.009"
name = "Regsvcs/Regasm"
reference = "https://attack.mitre.org/techniques/T1218/009/"

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



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

[metadata]
creation_date = "2026/01/26"
integration = ["okta"]
maturity = "production"
updated_date = "2026/03/24"

[rule]
author = ["Elastic"]
description = """
Detects potential Adversary-in-the-Middle (AiTM) session cookie replay attacks against Okta. This rule identifies when
an Okta session is used from multiple IP addresses or with suspicious non-browser user agents after initial
authentication. AiTM attacks capture session cookies via phishing proxies (e.g., Evilginx, Modlishka) and replay them
from attacker infrastructure, bypassing MFA. The detection correlates session start events with subsequent policy
evaluations or SSO attempts that occur from different IPs or programmatic user agents.
"""
false_positives = [
    """
    Users legitimately switching networks (e.g., VPN connect/disconnect, office to home) may trigger IP-based detection.
    Review the geographic distance and time between IP changes to assess legitimacy.
    """,
    """
    Automated integrations or scripts using service accounts with session cookies may trigger user-agent based
    detection. Consider excluding known automation accounts by okta.actor.alternate_id.
    """,
    """
    Mobile users switching between WiFi and cellular may show IP address changes. Correlate with device type and typical
    user behavior patterns.
    """,
]
from = "now-30m"
language = "esql"
license = "Elastic License v2"
name = "Okta AiTM Session Cookie Replay"
note = """## Triage and analysis

### Investigating Okta AiTM Session Cookie Replay

Adversary-in-the-Middle (AiTM) attacks use reverse proxies to intercept authentication flows, capturing session cookies after victims complete MFA. Attackers then replay these cookies from their own infrastructure to hijack authenticated sessions. This rule detects the post-capture phase by identifying sessions used from anomalous contexts.

This is an ES|QL aggregation-based rule. Pivot into raw events using the root session ID for full investigation context.

### Possible investigation steps

- Review the collected IP addresses from the alert to identify all IPs that accessed this session. Investigate geographic locations and ASN ownership for each IP.
- Examine the user agent values for non-browser user agents like `python-requests`, `curl`, or `Headless` browsers that indicate programmatic access.
- Check Okta's risk assessment fields. HIGH risk with reasons like "Anomalous Device" or "Anomalous Location" strengthens AiTM suspicion.
- Correlate the session start timestamp with the first replay attempt timestamp to understand the attack timeline.
- Query raw Okta events for the session ID to see all activity within this session, including accessed applications.
- Review proxy detection fields to determine if attacker requests originated from VPN/proxy infrastructure.
- Check the user's recent password reset or MFA enrollment events, as these may indicate account compromise leading to the AiTM attack.
- Contact the user to verify if they received phishing emails with links to suspicious login pages around the session start time.

### False positive analysis

- Legitimate VPN usage may cause IP address changes within a session. Check if both IPs belong to known corporate VPN ranges or the user's typical locations.
- Users traveling may show geographic IP changes. Correlate with travel schedules or expense reports if available.
- Browser extensions or security tools may modify user agents. Verify the user agent patterns match known tools in the environment.
- API integrations using user context may trigger non-browser UA detection. Exclude known service accounts.

### Response and remediation

- Immediately terminate all active sessions for the affected user via Okta Admin Console.
- Reset the user's password and require MFA re-enrollment to invalidate any captured credentials.
- Review and revoke any OAuth tokens or API keys associated with the user.
- Check Okta System Log for applications accessed during the suspicious session and assess data exposure.
- If downstream applications were accessed, coordinate with application owners to review access logs and potential data exfiltration.
- Block the attacker IP addresses at the network perimeter and add to threat intelligence feeds.
- Implement Okta sign-on policies that challenge or block sessions with HIGH risk scores or proxy detection.
- Consider enabling Okta ThreatInsight to automatically block known malicious IPs.
- Review email security logs for phishing attempts targeting the user around the session start time.
- Escalate to incident response if sensitive applications (AWS, Salesforce, email) were accessed from the attacker IP.
"""
references = [
    "https://www.bleepingcomputer.com/news/security/okta-sso-accounts-targeted-in-vishing-based-data-theft-attacks/",
    "https://reliaquest.com/blog/threat-spotlight-shinyhunters-data-breach-targets-salesforce-amid-scattered-spider-collaboration/",
    "https://securitylabs.datadoghq.com/articles/investigating-an-aitm-phishing-campaign-m365-okta/)",
    "https://www.microsoft.com/en-us/security/blog/2022/07/12/from-cookie-theft-to-bec-attackers-use-aitm-phishing-sites-as-entry-point-to-further-financial-fraud/",
    "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 = 73
rule_id = "9ed5d08f-aad6-4c03-838c-d686da887c2c"
severity = "high"
tags = [
    "Domain: Identity",
    "Use Case: Identity and Access Audit",
    "Data Source: Okta",
    "Data Source: Okta System Logs",
    "Tactic: Credential Access",
    "Tactic: Lateral Movement",
    "Resources: Investigation Guide",

]
timestamp_override = "event.ingested"
type = "esql"

query = '''
FROM logs-okta.system-*

// Filter to relevant event types for AiTM detection
| WHERE
    okta.event_type IN ("user.session.start", "policy.evaluate_sign_on", "user.authentication.sso") AND
    okta.authentication_context.root_session_id IS NOT NULL AND
    okta.actor.alternate_id != "system@okta.com"

// Create event type flags
| EVAL Esql.is_session_start = okta.event_type == "user.session.start"
| EVAL Esql.is_policy_eval = okta.event_type == "policy.evaluate_sign_on"
| EVAL Esql.is_sso = okta.event_type == "user.authentication.sso"
| EVAL Esql.is_replay_event = Esql.is_policy_eval OR Esql.is_sso

// Flag suspicious non-browser user agents
| EVAL Esql.is_suspicious_ua =
    user_agent.original LIKE "python-requests*" OR
    user_agent.original LIKE "curl/*" OR
    user_agent.original LIKE "httpx*" OR
    user_agent.original LIKE "aiohttp*" OR
    user_agent.original LIKE "Go-http-client*" OR
    user_agent.original LIKE "*Headless*" OR
    user_agent.original LIKE "Java/*" OR
    user_agent.original LIKE "okhttp*"

// Aggregate by session
| STATS
    Esql.session_start_count = SUM(CASE(Esql.is_session_start, 1, 0)),
    Esql.replay_event_count = SUM(CASE(Esql.is_replay_event, 1, 0)),
    Esql.session_start_time = MIN(CASE(Esql.is_session_start, @timestamp, null)),
    Esql.first_replay_time = MIN(CASE(Esql.is_replay_event, @timestamp, null)),
    Esql.last_replay_time = MAX(CASE(Esql.is_replay_event, @timestamp, null)),
    Esql.session_start_ip = MAX(CASE(Esql.is_session_start, okta.client.ip, null)),
    Esql.session_start_ua = MAX(CASE(Esql.is_session_start, user_agent.original, null)),
    Esql.suspicious_ua_count = SUM(CASE(Esql.is_suspicious_ua, 1, 0)),
    Esql.okta_client_ip_count_distinct = COUNT_DISTINCT(okta.client.ip),
    Esql.user_agent_count_distinct = COUNT_DISTINCT(user_agent.original),
    Esql.okta_client_ip_values = VALUES(okta.client.ip),
    Esql.user_agent_values = VALUES(user_agent.original),
    Esql.okta_event_type_values = VALUES(okta.event_type),
    Esql.okta_outcome_result_values = VALUES(okta.outcome.result),
    Esql.source_geo_country_name_values = VALUES(source.geo.country_name),
    Esql.source_geo_city_name_values = VALUES(source.geo.city_name),
    Esql.okta_debug_context_debug_data_risk_level_values = VALUES(okta.debug_context.debug_data.risk_level),
    Esql.okta_debug_context_debug_data_risk_reasons_values = VALUES(okta.debug_context.debug_data.risk_reasons)
  BY okta.authentication_context.root_session_id, okta.actor.alternate_id

// Detection conditions
| WHERE
    Esql.session_start_count >= 1
    AND Esql.replay_event_count >= 1
    AND Esql.first_replay_time > Esql.session_start_time
    AND (
            (
                Esql.okta_client_ip_count_distinct > 1 OR Esql.user_agent_count_distinct > 1
            ) AND Esql.suspicious_ua_count > 0
        )

| SORT Esql.session_start_time DESC
| KEEP Esql.*, okta.authentication_context.root_session_id, okta.actor.alternate_id
'''


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

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

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

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

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

[[rule.threat.technique.subtechnique]]
id = "T1550.004"
name = "Web Session Cookie"
reference = "https://attack.mitre.org/techniques/T1550/004/"

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