[CVE] Fortinet FortiClient EMS Unauthenticated Remote Code Execution Under Active Exploitation

Report Type
CVE

Threat Category
Unauthenticated Remote Code Execution (Improper Access Control)

Assessment Date
April 07, 2026

Primary Impact Domain
Centralized Endpoint Management Infrastructure

Secondary Impact Domains

·        Enterprise Endpoint Security Posture

·        Identity and Access Control Validation

·        Network Security Monitoring and Visibility

·        Incident Response and Containment Operations

Affected Asset Class

·        Centralized Management Infrastructure (FortiClient EMS)

·        Managed Enterprise Endpoints

Threat Objective Classification

·        Initial Access Establishment

·        Remote Command Execution

·        Lateral Expansion via Management Infrastructure

·        Potential Ransomware Enablement (Conditional Post-Exploitation)

BLUF

 Fortinet FortiClient EMS contains an unauthenticated remote code execution vulnerability that enables compromise of centralized endpoint management infrastructure, creating high-impact enterprise risk due to its control over managed systems. The vulnerability is caused by improper access control (CWE-284), allowing attackers to bypass authentication and execute commands directly against EMS services. Inclusion in the CISA Known Exploited Vulnerabilities catalog indicates elevated exploitation likelihood and compressed timelines for attacker adoption. Immediate remediation, enforced access restriction, and validation of detection capability are required to prevent enterprise-wide compromise.

Executive Risk Translation

Compromise of EMS enables attackers to control or disrupt large portions of the enterprise through a single system, significantly amplifying operational and financial impact.

S3 Why This Matters Now

·        KEV inclusion indicates active or imminent exploitation and removes assumptions of theoretical risk

·        Unauthenticated exploit path enables immediate attacker access without credential dependency

·        Centralized EMS architecture creates disproportionate enterprise impact from a single compromise

·        Automated exploitation is expected following KEV publication, increasing exposure across internet-accessible systems

S4 Key Judgments

·        This vulnerability represents a high-risk entry point due to unauthenticated access and centralized control exposure

·        Exploitation is expected to scale rapidly due to low complexity and automation potential

·        Detection requires correlation due to absence of authentication telemetry

·        Internet-exposed EMS instances face immediate compromise risk if unpatched

S5 Executive Risk Summary

Business Risk

·       Enterprise-wide compromise through centralized endpoint management control, enabling operational disruption and potential ransomware enablement

Technical Cause

·       Improper access control allowing unauthenticated command execution via crafted requests

Threat Posture

·       Elevated due to KEV inclusion, high exploitability, and expected rapid attacker adoption

Executive Decision Requirement

·       Immediate remediation, enforced access restriction, and validation of operational detection capability across EMS infrastructure

S6 Executive Cost Summary

This cost analysis was developed by the CyberDax team using expert judgment and assisted analytical tools to support clarity and consistency.

·        Low Impact Scenario
Isolated EMS compromise with limited execution and no lateral expansion, requiring incident response, system restoration, and validation efforts typically ranging from $100,000 to $250,000

·        Moderate Impact Scenario
Compromise affecting multiple managed endpoints, requiring enterprise-wide investigation, containment, endpoint remediation, and operational disruption, with costs typically ranging from $250,000 to $1,000,000

·        High Impact Scenario
Full EMS compromise enabling coordinated control across endpoints, potential ransomware deployment, or enterprise-wide disruption, with costs ranging from $1,000,000 to $4,000,000 or more

S6A Key Cost Drivers

·        Centralized control of enterprise endpoints through EMS infrastructure

·        Ability to execute commands across managed systems from a trusted platform

·        Detection difficulty due to unauthenticated access and absence of authentication telemetry

·        Incident response scope extending across distributed endpoint environments

·        Potential for escalation into enterprise-wide disruption or ransomware scenarios

S6B Compliance and Risk Context

Compliance Exposure Indicator

·       KEV inclusion triggers mandatory remediation timelines under BOD 22-01 and increases regulatory scrutiny on vulnerability management effectiveness

Risk Register Entry

·       Unauthenticated remote code execution in centralized endpoint management infrastructure enabling enterprise-wide compromise

Annualized Risk Exposure

·       Elevated due to high exploitation likelihood, critical infrastructure positioning, and potential for high-impact outcomes including operational disruption and ransomware enablement

S7 Risk Drivers

·        Unauthenticated exploit path removes access control barriers entirely

·        Centralized EMS architecture amplifies enterprise impact from a single compromise

·        Trusted management communications reduce visibility of malicious activity

·        KEV inclusion increases likelihood of automated and opportunistic exploitation

·        Short remediation window increases exposure to active attacker activity

·        Potential for rapid escalation from initial access to enterprise-wide control

S8 Bottom Line for Executives

This vulnerability enables unauthenticated compromise of centralized endpoint management infrastructure and must be treated as an immediate enterprise risk. Remediation, access restriction, and validation of detection capability are required actions.

S9 Board-Level Takeaway

A single unpatched management system can enable enterprise-wide compromise. Failure to act within the KEV remediation window materially increases the likelihood of operational disruption, ransomware exposure, and significant business impact.

Figure 2

S10 Vulnerability Overview

Vulnerability Type

Improper Access Control

Affected Systems

Fortinet FortiClient Endpoint Management Server deployments, including internet-exposed and internally accessible EMS instances

Exposure Conditions

Exposure exists when EMS interfaces are reachable from untrusted networks, including internet-facing deployments or internally exposed systems without enforced access restrictions

Privilege Requirements

None

Attack Vector

Network

S11 Technical Vulnerability Details

Root Cause

Failure to enforce authentication and authorization controls within EMS request handling logic

Vulnerable Component

FortiClient EMS web service and API request processing components

Trigger Mechanism

Crafted HTTP or HTTPS requests sent to EMS interfaces

Exploitable Condition

Requests are processed without validating authentication state, allowing unauthenticated execution within EMS service context

S12 Exploitability Assessment

Exploit Complexity

Low

Authentication Requirements

None

Network Exposure

Externally exposed EMS systems are at highest risk; internally accessible systems remain vulnerable due to lack of authentication enforcement

Operational Constraints

No meaningful constraints; exploitation can be automated and executed without prior access, credentials, or user interaction

S13 KEV Status and Patch Availability

KEV Status

Present in CISA Known Exploited Vulnerabilities catalog (Added: 2026-04-06, Due: 2026-04-09)

Patch Availability

Vendor-provided mitigations or patches required; organizations must follow Fortinet remediation guidance

Remediation Priority

Immediate

KEV Likelihood Assessment (EEP)

EEP is a forward-looking analytic measure of operational exploitation potential, not a statement of confirmed exploitation, KEV inclusion, or incident activity.
Exploitation likelihood is high due to unauthenticated access, centralized system value, and KEV prioritization, with strong potential for rapid automated exploitation across exposed systems

S14 Sectors / Countries Affected

Sectors Affected

·       Enterprise

·       Government

·       Financial services

·       Healthcare

·       Critical infrastructure

·       Managed service providers utilizing Fortinet EMS

Countries Affected

·       Global exposure due to widespread deployment of Fortinet products

S15 Adversary Capability Profiling

Skill Level

Low to moderate

Tooling Requirements

Standard HTTP request tooling or automated scanning frameworks

Infrastructure Needs

Minimal; commodity internet infrastructure sufficient

Operational Scale

High scalability due to automation capability and absence of authentication barriers

S16 Targeting Probability Assessment

Targeting probability is high due to the combination of unauthenticated exploitability, centralized asset value, and KEV-driven prioritization. Internet-exposed EMS deployments are expected to be actively scanned and targeted, while internally accessible systems remain vulnerable where access controls are not enforced. Opportunistic and automated exploitation is likely to increase rapidly following KEV publication.

S17 MITRE ATT&CK Chain Flow Mapping

Initial Access

T1190 – Exploit Public-Facing Application
Attackers exploit EMS interfaces using crafted requests without authentication

Execution

T1059 – Command and Scripting Interpreter
Commands executed within EMS service context following successful exploitation

Persistence

T1136 – Create Account
Not observed in currently available reporting; may occur during post-exploitation depending on attacker objectives and target environment

Privilege Escalation

T1068 – Exploitation for Privilege Escalation
Not observed in currently available reporting; may occur depending on system configuration and attacker objectives

Defense Evasion

T1070 – Indicator Removal
Not observed in currently available reporting; may occur during post-exploitation depending on attacker objectives and target environment

Command and Control

T1071 – Application Layer Protocol
Outbound communication may be established using standard protocols following exploitation

Lateral Movement

T1021 – Remote Services
Not observed in currently available reporting; may occur through EMS-managed endpoint interaction

Impact

T1486 – Data Encrypted for Impact
Not observed in currently available reporting; may occur if ransomware is deployed following compromise

S18 Attack Path Narrative (Signal-Aligned Execution Flow)

The attack begins with adversary-driven discovery of internet-exposed FortiClient EMS instances through automated scanning, internet-wide enumeration, or targeting of known enterprise management infrastructure. Given KEV inclusion, this stage is highly likely to involve broad, automated probing activity rather than manual, targeted reconnaissance.

The attacker delivers crafted HTTP or HTTPS requests directly to EMS administrative or API endpoints. The vulnerability, rooted in improper access control (CWE-284), allows the EMS service to process requests without enforcing required authentication or authorization checks. This condition may result from missing session validation, improper role enforcement, or direct exposure of privileged endpoints.

This initial exploitation stage produces clear network-level signals:

·        Inbound requests to EMS administrative or non-standard API paths from untrusted external IP addresses

·        Requests lacking valid authentication tokens or session identifiers

·        Repeated probing patterns or malformed request structures consistent with automated exploitation

A critical detection opportunity emerges in the mismatch between access activity and authentication telemetry, where requests are successfully processed without corresponding authentication events.

Internally, the EMS service processes the crafted request through its web or API handling layer. Due to insufficient access control validation, attacker-supplied input is allowed to traverse into privileged execution paths. This creates a deterministic execution condition in which externally supplied data is trusted and executed without proper authorization gating, forming the core exploit trigger point.

Upon successful exploitation, attacker-controlled input is executed within the EMS service context, resulting in remote command or code execution under the privileges of the EMS application or underlying system service.

This execution phase generates strong endpoint-level signals:

·        Child process creation originating from the EMS service or associated application processes

·        Invocation of command interpreters such as cmd.exe, PowerShell, or shell binaries

·        Execution chains inconsistent with normal EMS operational behavior

Following execution, the EMS host may initiate outbound communication or internal activity controlled by the attacker. This may include command-and-control establishment, staging actions, or preparation for lateral movement.

Resulting network-level signals may include:

·        Outbound connections from the EMS server to previously unseen external infrastructure

·        Internal communication from EMS to endpoints outside established management patterns

·        Burst or automated request sequences indicating exploitation or follow-on activity

Not observed in currently available reporting; may occur during post-exploitation depending on attacker objectives and target environment: lateral movement to managed endpoints, credential access, persistence establishment, and ransomware deployment.

From a detection engineering perspective, the attack provides three primary detection anchor points:

·        Network layer: anomalous unauthenticated access to privileged EMS endpoints and abnormal request patterns

·        Endpoint layer: execution of child processes originating from EMS service context

·        Correlation layer: successful system-level activity occurring without corresponding authentication events

The attack path therefore progresses from unauthenticated external access, to authorization bypass at the EMS interface, to execution within a high-trust management system, creating a centralized control point that can be leveraged for broad enterprise compromise.

S19 Attack Chain Risk Amplification Summary

The compromise of FortiClient EMS through CVE-2026-35616 represents a disproportionately high-risk scenario due to the system’s role as a centralized endpoint management platform. Unlike isolated server compromises, EMS operates within a high-trust administrative boundary, maintaining privileged control and persistent communication with managed endpoints across the enterprise.

The initial exploit requires no authentication, removing a primary defensive control and enabling direct interaction with exposed EMS infrastructure. This significantly lowers attacker cost and allows for automated, large-scale exploitation following KEV inclusion, increasing both the speed and breadth of potential compromise across organizations.

Once exploited, the EMS server becomes a high-leverage control point. As a management system, EMS is designed to issue commands, enforce policies, and communicate with endpoints using trusted channels. This creates a structural amplification condition where attacker activity inherits the trust of legitimate administrative operations.

This trust model enables multiple amplification pathways:

·        Lateral propagation via trusted management channels, where EMS-originated communication to endpoints is typically allowlisted and expected, reducing the likelihood of network-based detection or segmentation controls blocking malicious activity

·        Execution at scale through native management functionality, allowing attacker-supplied commands or payloads to be distributed across multiple endpoints under the guise of legitimate administrative actions

·        Credential and configuration exposure, where access to EMS may provide visibility into endpoint inventories, policy configurations, and potentially stored or accessible authentication material

A critical amplification factor is the erosion of traditional defensive controls. Security mechanisms that rely on authentication monitoring, anomaly detection of external access, or strict trust boundaries are weakened because:

·        The exploit bypasses authentication entirely, eliminating login-based detection signals

·        EMS-originated actions are often implicitly trusted by endpoints and security tools

·        Endpoint detection systems may interpret EMS-driven activity as legitimate administrative behavior rather than malicious execution

This creates a condition where malicious activity can blend with normal operational traffic, significantly reducing detection fidelity and increasing potential dwell time.

From an operational perspective, attackers can leverage EMS not only as an entry point but as a force-multiplier, enabling coordinated actions across the enterprise environment with minimal additional effort.

In KEV-driven threat conditions, the vulnerability’s prioritization indicates elevated exploitation likelihood across diverse threat actors. Even without confirmed ransomware usage, the combination of unauthenticated remote access, privileged execution, and centralized control aligns strongly with known enterprise-scale compromise patterns used in ransomware and intrusion campaigns.

The overall risk amplification is driven by three converging factors:

·        Unauthenticated remote exploitability, enabling rapid and scalable attacker access

·        Centralized management trust model, allowing downstream control of endpoints and systems

·        Defensive control erosion and operational blending, reducing visibility and increasing attacker dwell time

This results in a high-probability, high-impact scenario in which compromise of a single EMS instance can enable widespread enterprise control, data exposure, and operational disruption.

Figure 3

S20 Tactics, Techniques, and Procedures

T1190 – Exploit Public-Facing Application

The adversary exploits the FortiClient EMS web or API interface exposed to the internet by sending crafted requests that bypass authentication and authorization controls. This allows direct interaction with privileged application functionality without valid credentials.

This technique represents the primary initial access vector and is enabled by improper access control within the EMS service.

T1059 – Command and Scripting Interpreter

Following successful exploitation, the attacker executes system commands through the EMS service context. This may involve invocation of command interpreters such as cmd.exe, PowerShell, or system shell environments.

This technique enables direct control of the EMS host and represents the core execution capability resulting from the vulnerability.

T1105 – Ingress Tool Transfer

Following remote code execution, the attacker may retrieve additional payloads or tools from external infrastructure to expand operational capability. This may include downloading scripts, remote access tools, or secondary-stage malware.

This behavior commonly follows successful exploitation and supports persistence, lateral movement preparation, or operational scaling.

S20A Adversary Tradecraft Summary

The exploitation of CVE-2026-35616 aligns with tradecraft commonly associated with opportunistic initial access operations and enterprise-scale intrusion activity. The combination of unauthenticated access and remote code execution within a centralized management platform makes this vulnerability highly attractive to a wide range of threat actors, including financially motivated groups, initial access brokers, and ransomware operators.

From an adversary objective perspective, activity enabled by this vulnerability can be categorized into primary and secondary operational goals.

Primary objectives include:

·        Establishing initial access within enterprise environments through exploitation of externally exposed EMS infrastructure

·        Gaining execution capability within a centralized management system to enable further operations

·        Rapid environment reconnaissance and identification of managed endpoint assets

Secondary objectives, depending on attacker intent and environment value, may include:

·        Monetization of access through initial access brokerage

·        Deployment of follow-on payloads such as remote access tools or ransomware

·        Expansion of control through lateral movement or policy-driven execution across endpoints

The lack of authentication requirements significantly reduces attacker cost and increases scalability. Threat actors are likely to integrate this vulnerability into automated scanning and exploitation frameworks, enabling rapid identification and compromise of exposed EMS instances across multiple organizations.

The role of EMS as a centralized management platform creates a strong operational advantage. Rather than targeting individual endpoints, adversaries can leverage EMS to interact with multiple systems through trusted management channels. This enables coordinated activity at scale while reducing the need for traditional lateral movement techniques.

From an infrastructure perspective, exploitation activity is likely to exhibit characteristics associated with scalable and opportunistic campaigns:

·        Use of distributed scanning infrastructure to identify exposed EMS services across the internet

·        Deployment of short-lived or rotating command-and-control endpoints to reduce attribution and increase resilience

·        Reliance on common protocols such as HTTPS to blend malicious activity with normal administrative traffic

From a capability standpoint, exploitation of this vulnerability requires relatively low technical sophistication once a working exploit is available. This lowers the barrier to entry and increases the likelihood of widespread adoption across diverse threat actors.

Although not observed in currently available reporting, ransomware enablement is a credible outcome given the centralized control capabilities of EMS. Similarly, initial access brokers may prioritize this vulnerability for access acquisition and resale due to the high-value positioning of EMS within enterprise environments.

Overall, adversary tradecraft associated with CVE-2026-35616 is characterized by low-complexity exploitation, high scalability, and strong return on investment. The combination of unauthenticated access, centralized control, and enterprise-wide reach creates an attractive attack path for both opportunistic and targeted threat actors operating at scale.

S21 Detection Strategy Overview

Detection of exploitation associated with CVE-2026-35616 requires a behavior-driven approach focused on identifying deviations from expected FortiClient EMS operational patterns across network, endpoint, and correlated telemetry layers. Traditional detection methods relying on authentication monitoring or known exploit signatures are insufficient due to the unauthenticated nature of the vulnerability and the ability of attackers to operate within trusted application contexts.

Under normal conditions, EMS systems receive authenticated administrative or endpoint-originated requests and perform controlled management actions without spawning arbitrary command execution processes. Exploitation of this vulnerability breaks this model by introducing unauthenticated access combined with system-level execution, creating detectable inconsistencies between expected and observed behavior.

At the network layer, detection should focus on identifying anomalous HTTP or HTTPS interactions with EMS interfaces. This includes requests originating from untrusted external sources, requests lacking valid authentication artifacts, and access patterns inconsistent with standard EMS usage. Automated exploitation activity following KEV inclusion may manifest as repeated or distributed probing across multiple source IPs.

At the endpoint layer, detection should focus on process execution originating from the EMS service context. EMS systems do not typically initiate command interpreter processes or arbitrary execution chains. The presence of child processes such as cmd.exe, PowerShell, or shell environments originating from EMS-related services represents a high-confidence indicator of compromise.

A critical detection mechanism is cross-domain correlation. Exploitation creates a condition where system-level execution activity occurs without corresponding authentication events. Correlating network access activity with the absence of authentication telemetry, combined with endpoint execution signals, provides a resilient detection approach that reduces reliance on any single telemetry source.

Detection must also account for the trusted nature of EMS communications. Because EMS-originated traffic to endpoints is typically allowlisted and expected, network controls alone may not identify malicious activity. Endpoint telemetry and behavioral analysis are therefore essential for detecting misuse of legitimate management channels.

From a prioritization perspective, KEV inclusion indicates elevated exploitation likelihood and reduced time-to-compromise. Detection logic should prioritize early-stage identification of anomalous access patterns and treat exploitation indicators as high-severity events requiring immediate investigation.

The detection strategy is anchored on three primary detection points:

·        Network detection of anomalous or unauthenticated access to EMS interfaces

·        Endpoint detection of abnormal process execution originating from EMS service context

·        Correlation detection identifying mismatches between access activity, authentication telemetry, and system behavior

This multi-layered detection model provides resilience against evasion, supports early detection in the attack lifecycle, and establishes a direct foundation for signal definition, telemetry mapping, and detection rule development in subsequent sections.

S22 Primary Detection Signals

Primary detection signals for CVE-2026-35616 focus on identifying observable deviations from expected FortiClient EMS behavior across network activity, endpoint execution, and cross-domain correlation conditions introduced by unauthenticated exploitation.

Network-Level Signals

·        Inbound HTTP or HTTPS requests to EMS administrative or API endpoints originating from untrusted external IP addresses

·        Requests targeting non-standard or rarely used EMS URI paths associated with administrative or privileged functionality

·        HTTP or HTTPS requests lacking valid authentication tokens

·        HTTP or HTTPS requests lacking valid session identifiers

·        HTTP or HTTPS requests lacking expected authorization headers

·        Repeated request patterns from a single source IP indicative of exploitation attempts

·        Distributed probing patterns across multiple source IPs targeting EMS endpoints

·        Malformed or irregular request structures inconsistent with normal EMS client or administrative traffic

Endpoint-Level Signals

·        Child process creation where the parent process is the EMS service or associated application component

·        Execution of cmd.exe initiated by EMS-related processes

·        Execution of PowerShell initiated by EMS-related processes

·        Execution of shell environments initiated by EMS-related processes

·        Process execution chains originating from EMS service context that deviate from established operational baselines

·        Elevated or system-level process execution initiated from EMS service context

Correlation Signals

·        Successful request processing or application activity on EMS without corresponding authentication or session establishment events

·        Temporal correlation between anomalous inbound EMS network requests and subsequent process execution on the host

·        Inbound anomalous EMS access followed by outbound connections to previously unseen or untrusted external infrastructure

·        EMS-originated activity interacting with endpoints outside normal management patterns following suspicious inbound access

High-Confidence Detection Conditions

·        Unauthenticated access to EMS interfaces followed by process execution originating from EMS service context

·        Absence of authentication telemetry combined with successful EMS-driven system activity

·        Correlated network and endpoint anomalies occurring within a short temporal window

Detection Signal Prioritization

·        Signals combining unauthenticated access and execution activity should be treated as high-confidence indicators of compromise

·        Repeated probing or scanning activity targeting EMS endpoints should be treated as early-stage exploitation attempts requiring investigation

·        Correlated multi-layer signals should be prioritized over single-source detections to reduce false positives and improve detection confidence

S23 Telemetry Requirements

Effective detection of CVE-2026-35616 exploitation depends on the availability and correlation of telemetry across network, endpoint, and authentication logging layers. Each detection signal identified in S22 requires specific telemetry sources and logging configurations to ensure observability, traceability, and reliable detection.

Network Telemetry Requirements

The following telemetry is required to support detection of network-level signals defined in S22, including anomalous EMS access, unauthenticated requests, and scanning behavior:

·        HTTP and HTTPS request logs capturing:

o   Source IP address

o   Destination IP and port

o   Requested URI paths

o   HTTP methods

o   Header data including authorization fields

·        Web server or application-layer logs from FortiClient EMS capturing:

o   Request endpoints accessed

o   Response codes

o   Session handling behavior

·        Network security monitoring tools such as IDS or IPS (for example Suricata) capable of:

o   Inspecting HTTP and HTTPS traffic (requires TLS visibility where applicable)

o   Detecting malformed or anomalous request structures

o   Identifying repeated or distributed scanning patterns

·        Network flow telemetry (NetFlow or equivalent) to support:

o   Detection of high-frequency request patterns

o   Identification of distributed probing across multiple source IPs

Without visibility into HTTP request structure and authentication artifacts, detection of unauthenticated access signals is significantly degraded or not possible.

Endpoint Telemetry Requirements

The following telemetry is required to support detection of execution-based signals defined in S22, including process spawning and command execution originating from EMS services:

·        Endpoint Detection and Response telemetry capturing:

o   Process creation events including parent and child relationships

o   Command-line arguments associated with executed processes

o   Process execution context (user, privilege level, service association)

·        Windows event logs or equivalent system logs capturing:

o   Process creation events (for example Security Event ID 4688 where available)

o   Service-related activity associated with EMS components

·        Application context identification capable of:

o   Distinguishing EMS service processes from other system processes

o   Mapping process lineage back to EMS service context

Parent-child process lineage is a mandatory requirement. Without it, detection of EMS-originated execution signals is not reliable.

Authentication and Session Telemetry Requirements

The following telemetry is required to support correlation signals defined in S22, particularly detection of access without authentication:

·        Authentication logs capturing:

o   Successful login events

o   Failed login attempts

o   Session creation events

·        EMS-specific session management logs (if available) capturing:

o   Session identifiers

o   Authentication state transitions

o   Authorization decisions

·        Logging capable of supporting:

o   Correlation between access requests and authentication events

o   Identification of request processing without valid authentication context

Without authentication and session telemetry, detection of access-without-authentication conditions is not possible.

Correlation and Enrichment Requirements

Correlation across telemetry sources is a required detection capability for this vulnerability due to the multi-stage nature of exploitation.

·        Centralized logging or SIEM capability must support:

o   Correlation between network, endpoint, and authentication telemetry

o   Temporal analysis linking inbound access with subsequent execution activity

·        Asset context enrichment must support:

o   Identification of EMS servers as high-value management systems

o   Mapping of EMS systems to managed endpoint populations

·        Threat intelligence enrichment (optional but beneficial) may support:

o   Identification of known malicious infrastructure involved in scanning or exploitation

Without cross-domain correlation capability, detection coverage is significantly reduced and limited to partial signal visibility.

Telemetry Dependency Considerations

·        TLS inspection may be required to observe HTTP or HTTPS request contents and identify missing authentication artifacts

·        Encrypted traffic without inspection reduces visibility into network-level exploitation signals

·        EMS application logging capabilities may vary by deployment and configuration, affecting visibility into session handling and authorization behavior

·        Endpoint telemetry must include full process lineage to accurately detect execution originating from EMS services

Minimum Telemetry Baseline

To achieve effective detection coverage, organizations must ensure the following minimum telemetry is available:

·        Network-level visibility into inbound HTTP or HTTPS traffic to EMS systems

·        Endpoint process creation telemetry with parent-child relationships on EMS hosts

·        Authentication or session logging sufficient to identify mismatches between access activity and authentication events

Figure 4

S24 Detection Opportunities and Gaps

Detection of CVE-2026-35616 exploitation presents strong opportunities for high-confidence identification when multi-layer telemetry is available, alongside notable gaps driven by encryption, application visibility limitations, and the trusted operational model of FortiClient EMS.

Detection Opportunities

The following opportunities directly align with primary detection signals defined in S22:

·        Detection of unauthenticated access to EMS interfaces through identification of missing authentication tokens, session identifiers, or authorization headers in HTTP or HTTPS requests where visibility is available

·        Identification of anomalous or non-standard URI access patterns targeting EMS administrative or privileged endpoints

·        Detection of automated exploitation attempts through repeated or distributed probing patterns across EMS services

·        High-confidence detection of exploitation through endpoint telemetry capturing process execution where the parent process is the EMS service

·        Strong correlation-based detection of system-level execution activity occurring without corresponding authentication or session events

·        Detection of post-exploitation behavior through outbound connections from EMS systems to previously unseen or untrusted external infrastructure

A deterministic high-confidence detection condition exists when unauthenticated access to EMS interfaces is followed by process execution originating from EMS service context.

Detection Gaps

Detection coverage is reduced or not achievable under the following conditions:

·        Lack of TLS inspection or application-layer visibility prevents identification of missing authentication artifacts and malformed request structures

o   Network detection coverage becomes partially or not available

·        EMS application logs do not expose authentication or authorization decision points

o   Detection of access control bypass conditions is not directly observable

·        Absence of authentication or session telemetry

o   Detection of access-without-authentication conditions is not possible

·        Endpoint telemetry does not include parent-child process lineage or EMS process identification

o   Detection of EMS-originated execution activity becomes unreliable or not possible

·        EMS deployments accessible only internally or through VPN without adequate logging

o   Network-level detection opportunities are significantly reduced

·        Trusted EMS communication patterns allow malicious activity to blend with legitimate administrative traffic

o   Detection fidelity is reduced and false negatives increase

Bypass and Evasion Considerations

·        Attackers may leverage encrypted communication channels to conceal request structure and authentication artifacts from network inspection tools

·        Exploitation may use request patterns that closely resemble legitimate EMS administrative traffic, reducing anomaly detection effectiveness

·        Attackers may minimize execution footprint or use low-noise commands to evade endpoint-based detection

·        Use of trusted EMS communication paths to endpoints may allow malicious activity to bypass network segmentation or allowlisting controls

·        Attackers may use infrastructure that mimics legitimate geographic or network patterns to reduce detection likelihood

Coverage Limitations Summary

·        Network-only detection provides partial coverage and is insufficient without TLS visibility and application-layer logging

·        Endpoint-only detection can identify execution but lacks visibility into initial exploitation conditions

·        Absence of authentication telemetry eliminates the ability to detect access-without-authentication conditions

·        Lack of correlation capability prevents reliable detection of multi-stage exploitation and significantly increases false negative risk

Detection Coverage Outlook

Detection coverage is strongest when network, endpoint, and authentication telemetry are correlated to identify the combined condition of unauthenticated access and execution activity. Environments lacking one or more telemetry domains will experience partial or no coverage for key detection signals, increasing the likelihood of undetected exploitation.

S25 Ultra-Tuned Detection Engineering Rules

Suricata

Rule 1 — Suspicious External Targeting of FortiClient EMS Privileged Web Paths

Purpose
Detect suspicious inbound access from external sources to tenant-validated FortiClient EMS privileged web paths that may indicate exploit targeting of exposed EMS administrative or API functionality.

MITRE ATT&CK Mapping
T1190 – Exploit Public-Facing Application

SOC Usage Mode
Alert-capable supporting detection

Minimum Deployment Requirement

·        EMS servers must be explicitly scoped into $EMS_SERVERS

·        This rule must only be deployed after tenant validation of EMS-exposed privileged paths

·        HTTP visibility is required

·        For HTTPS, TLS inspection or equivalent decrypted visibility is required

·        If legitimate internet-based EMS administration exists, trusted source suppression is mandatory before production alerting

Telemetry Dependency

·        Suricata HTTP parser visibility into URI and method

·        Reliable asset scoping for EMS infrastructure

·        Tenant-confirmed understanding of exposed EMS web paths

Tuning Explanation

·        This is a suspicious targeting rule, not an exploit-confirmation rule

·        It should be localized to real EMS paths seen in reverse proxy, IIS, or application logs

·        The path expression below is a placeholder starter set and should be narrowed where tenant knowledge exists

·        This rule gains value when paired with repeated probing, endpoint execution, or SIEM correlation

Enforcement Method

·        Hard EMS asset scoping

·        Hard privileged-path scoping

·        Mandatory trusted-source suppression where external EMS administration is expected

Implementation Constraint Notes

·        This rule does not prove unauthenticated exploitation

·        This rule does not prove access-control bypass

·        If tenant path validation is not completed, deployment remains conditional

Variant Analysis

·        Covers common web methods rather than relying on a single verb

·        Still may miss attacks using alternate EMS paths outside the validated set

·        Still may blend with legitimate external admin traffic if source suppression is weak

Rule Regret Check
Deployment caution
Do not deploy as high-confidence production alerting until EMS path localization is completed

Confidence caution
Medium confidence as a standalone suspicious targeting rule

Coverage value
High-value early network signal for suspicious access to exposed EMS web functionality

Production Ready
Conditional until tenant path validation and trusted-source suppression are completed

Detection Logic / System-Ready Code

alert http $EXTERNAL_NET any -> $EMS_SERVERS any (
    msg:"CYBERDAX FortiClient EMS suspicious external targeting of privileged web paths";
    flow:to_server,established;
    http.method; pcre:"/^(GET|POST|PUT|HEAD)$/";
    http.uri; pcre:"/\/(api|admin|management)(\/|$)/Ui";
    classtype:web-application-attack;
    metadata:service http, attack_target Server, deployment Perimeter, created_at 2026_04_07;
    reference:cve,2026-35616;
    sid:2503561601;
    rev:3;
)

Rule 2 — Repeated Single-Source Probing of FortiClient EMS Privileged Web Paths

Purpose

Detect repeated single-source probing or exploit-attempt behavior against FortiClient EMS by identifying burst access to tenant-validated EMS privileged web paths from the same source within a short interval.

MITRE ATT&CK Mapping
T1190 – Exploit Public-Facing Application

SOC Usage Mode
Alert-capable supporting detection

Minimum Deployment Requirement

·        EMS servers must be explicitly scoped into $EMS_SERVERS

·        This rule must only be deployed after tenant validation of EMS privileged paths

·        HTTP visibility is required

·        HTTPS requires TLS inspection or decrypted visibility

·        Thresholds must be localized to the tenant EMS exposure model before production alerting

Telemetry Dependency

·        Suricata HTTP parser visibility

·        Reliable source IP visibility

·        Stable visibility into inbound traffic reaching EMS hosts

Tuning Explanation

·        This is intentionally a single-source burst-probing detector

·        It is not distributed-scan coverage

·        Thresholds must be adjusted to local internet noise and EMS exposure

·        Best used as an early exploitation-attempt signal, not proof of exploit success

Enforcement Method

·        EMS-only scoping

·        Privileged-path scoping

·        Threshold-based detection for repeated single-source behavior

·        Mandatory threshold localization before production use

Implementation Constraint Notes

·        Does not detect rotating-source or distributed low-and-slow campaigns by itself

·        NAT or shared proxy concentration may inflate counts

·        Precision depends on the underlying quality of EMS path validation

Variant Analysis

·        Method-agnostic across common web methods

·        Does not rely on a specific payload string

·        May under-detect adversaries deliberately distributing requests across many IPs or longer time windows

Rule Regret Check
Deployment caution
Threshold tuning is mandatory before production deployment

Confidence caution
Medium confidence as a standalone alert

Coverage value
Strong single-source burst-probing coverage against exposed EMS web functionality

Production Ready
Conditional until path validation and threshold localization are completed

Detection Logic / System-Ready Code

alert http $EXTERNAL_NET any -> $EMS_SERVERS any (
    msg:"CYBERDAX FortiClient EMS repeated single-source probing of privileged web paths";
    flow:to_server,established;
    http.uri; pcre:"/\/(api|admin|management)(\/|$)/Ui";
    detection_filter:track by_src, count 8, seconds 60;
    classtype:attempted-recon;
    metadata:service http, attack_target Server, deployment Perimeter, created_at 2026_04_07;
    reference:cve,2026-35616;
    sid:2503561602;
    rev:3;
)

Rule 3 — Corroborating Outbound Web Activity from EMS After Prior Suspicious Inbound Targeting

Purpose
Detect corroborating post-target activity by flagging outbound HTTP or TLS connections from an EMS server shortly after suspicious inbound targeting of tenant-validated EMS privileged web paths.

MITRE ATT&CK Mapping
T1105 – Ingress Tool Transfer

SOC Usage Mode
Correlation-first, corroborating-only

Minimum Deployment Requirement

·        EMS servers must be explicitly scoped into $EMS_SERVERS

·        Suricata must observe both inbound and outbound traffic for the EMS host

·        Inbound HTTP visibility is required for the anchor condition

·        Outbound HTTP or TLS visibility is required for the follow-on condition

·        Legitimate EMS outbound destinations must be baselined and suppressed before production alerting

·        This rule must not be used as a standalone conviction rule

Telemetry Dependency

·        Bidirectional network visibility for EMS hosts

·        Stateful Suricata xbit support

·        Asset scoping and egress visibility

·        Tenant baseline knowledge of expected EMS outbound destinations

Tuning Explanation

·        This is a corroborating sequence detector, not proof of exploitation

·        It is only useful where outbound EMS internet behavior is sufficiently understood

·        Approved destinations such as update, telemetry, proxy, and distribution services must be suppressed before production use

·        Detection value rises when paired with endpoint or SIEM correlation

Enforcement Method

·        Stateful time-bound xbit correlation

·        EMS-only asset scoping

·        Mandatory outbound destination suppression

·        Explicit corroborating-only usage

Implementation Constraint Notes

·        Does not prove malicious egress

·        Does not prove tool transfer

·        May be noisy where EMS routinely performs outbound web activity

·        Does not cover non-web follow-on channels

Variant Analysis

·        Covers HTTP and TLS egress

·        Detects follow-on web activity even when exploit delivery varies

·        Misses internal-only or non-web post-exploitation paths

Rule Regret Check
Deployment caution
Do not use as high-confidence standalone alerting unless legitimate outbound EMS destinations are baselined and suppressed

Confidence caution
Low-to-moderate as a standalone network analytic

Coverage value
Useful corroborating coverage for suspicious sequence behavior following EMS targeting

Production Ready
Conditional until outbound baseline validation and destination suppression are completed

Detection Logic / System-Ready Code

alert http $EXTERNAL_NET any -> $EMS_SERVERS any (
    msg:"CYBERDAX FortiClient EMS suspicious inbound targeting anchor";
    flow:to_server,established;
    http.uri; pcre:"/\/(api|admin|management)(\/|$)/Ui";
    xbits:set,ems_suspicious_inbound,track ip_dst,expire 900;
    noalert;
    sid:2503561603;
    rev:3;
)

alert http $EMS_SERVERS any -> $EXTERNAL_NET any (
    msg:"CYBERDAX FortiClient EMS corroborating outbound HTTP after suspicious inbound targeting";
    flow:to_server,established;
    xbits:isset,ems_suspicious_inbound,track ip_src;
    detection_filter:track by_src, count 2, seconds 300;
    classtype:trojan-activity;
    metadata:service http, attack_target Server, deployment Internal, created_at 2026_04_07;
    reference:cve,2026-35616;
    sid:2503561604;
    rev:3;
)

alert tls $EMS_SERVERS any -> $EXTERNAL_NET any (
    msg:"CYBERDAX FortiClient EMS corroborating outbound TLS after suspicious inbound targeting";
    flow:to_server,established;
    xbits:isset,ems_suspicious_inbound,track ip_src;
    detection_filter:track by_src, count 2, seconds 300;
    classtype:trojan-activity;
    metadata:service tls, attack_target Server, deployment Internal, created_at 2026_04_07;
    reference:cve,2026-35616;
    sid:2503561605;
    rev:3;
)

Engineering Note

·        These rules are deployment-ready templates pending tenant-specific validation

·        Validate FortiClient EMS exposed privileged URI paths before production deployment

·        Confirm HTTP visibility and, where applicable, TLS inspection or equivalent decrypted visibility

·        Apply trusted-source suppression where legitimate external EMS administration is permitted

·        Tune the Rule 2 threshold to the tenant’s actual EMS exposure and internet noise profile

·        Baseline legitimate EMS outbound destinations and suppress approved update, telemetry, proxy, and distribution traffic before enabling Rule 3 for alerting

·        Coverage remains conditional until tenant localization, telemetry validation, and suppression tuning are completed

SentinelOne

Rule 1 — Validated FortiClient EMS Parent Spawning High-Risk Command Interpreter Execution

Purpose

Detect likely exploitation of FortiClient EMS by identifying high-risk command interpreter execution spawned from tenant-validated EMS parent context, with enrichment controls to improve precision, reduce noise, and strengthen deployability.

MITRE ATT&CK Mapping

T1059 – Command and Scripting Interpreter

SOC Usage Mode

Alert-capable supporting detection

Minimum Deployment Requirement

·        SentinelOne process creation telemetry must be enabled and retained

·        Parent-child process lineage must be available

·        EMS server assets must be positively identified through stable tenant asset scoping

·        EMS parent process names, image paths, service wrappers, and helper-process relationships must be validated before production deployment

·        Command-line visibility for child processes should be available

·        Known legitimate EMS maintenance or upgrade workflows must be reviewed before alert enablement

Telemetry Dependency

·        Process creation telemetry

·        Parent process name

·        Parent process image path where available

·        Child process name

·        Child process command line where available

·        Stable tenant asset identifiers, tags, or dedicated EMS host grouping

·        Optional enrichment fields for signer, integrity level, user context, or execution rarity where supported

Tuning Explanation

·        This rule preserves the core high-confidence condition while reducing broadness and overdependence on weak asset naming

·        The rule requires three controls together:

o   validated EMS asset scoping

o   validated EMS parent process scoping

o   high-risk interpreter child process scoping

·        It is further enriched by looking for suspicious command-line traits more consistent with malicious use than ordinary administrative behavior

·        Where the tenant supports it, signer, user-context, or execution-rarity suppression should be used to reduce noise from rare but legitimate maintenance activity

·        The rule remains focused on high-confidence suspicious execution from EMS context, not a generic interpreter hunt

Enforcement Method

·        Hard scoping to tenant-validated EMS assets

·        Hard scoping to tenant-validated EMS parent process identities

·        Hard scoping to high-risk interpreter children

·        Additional suspicious command-line gating for stronger precision

·        Mandatory suppression of known-good maintenance, packaging, or upgrade workflows where applicable

Implementation Constraint Notes

·        This rule does not prove the initial inbound exploit path by itself

·        This rule is only as strong as tenant validation of EMS parent process identities and EMS host scoping

·        If command-line visibility is incomplete, the rule can still be deployed in reduced form, but confidence should be lowered and local suppression strengthened

·        If legitimate EMS maintenance workflows launch command interpreters with similar arguments, deployment must remain conditional until suppression logic is validated

·        If the tenant cannot authoritatively identify EMS assets, do not elevate this rule to high-confidence production alerting

Variant Analysis

·        Covers direct interpreter-based post-exploitation via cmd.exe and powershell.exe

·        Improves resilience against simple evasion by requiring suspicious command-line behavior rather than child process name alone

·        Still may miss in-process execution, parent spoofing beyond validated EMS lineage, or execution paths that do not emit interpreters

·        Still may miss cases where the attacker uses other execution proxies instead of interpreters; those remain covered by Rule 2

·        Coverage quality improves when the tenant adds signer checks, service-context validation, or rarity-based enrichment

Rule Regret Check
Deployment caution

Do not enable as high-confidence production alerting until EMS assets, EMS parent processes, and legitimate maintenance-driven interpreter launches are all validated

Confidence caution

High confidence when EMS asset scope, EMS parent scope, and suspicious command-line enrichment are all present; moderate if command-line visibility is incomplete

Coverage value

Very high value endpoint detection for likely OS-level command execution resulting from FortiClient EMS exploitation

Production Ready

Conditional until EMS asset scoping, EMS parent-process localization, command-line visibility validation, and legitimate-workflow suppression tuning are completed

Detection Logic / Deployment Template Code

-- SentinelOne Deep Visibility / Singularity XDR deployment template
-- Replace placeholder EMS asset and parent identifiers with tenant-validated values before production use
-- Optional enrichment fields should be enabled only if confirmed present in the tenant

AgentOsType = "windows"
AND agent.uuid IN ($EMS_ASSET_IDS)
AND (
  parent_process_name IN ($EMS_PARENT_PROCESS_NAMES)
  OR parent_process_image_path IN ($EMS_PARENT_PROCESS_PATHS)
)
AND process_name IN ("cmd.exe","powershell.exe")
AND (
  process_command_line CONTAINS "/c "
  OR process_command_line CONTAINS "-enc "
  OR process_command_line CONTAINS "-encodedcommand "
  OR process_command_line CONTAINS "invoke-expression"
  OR process_command_line CONTAINS "iex "
  OR process_command_line CONTAINS "downloadstring"
  OR process_command_line CONTAINS "invoke-webrequest"
  OR process_command_line CONTAINS "iwr "
  OR process_command_line CONTAINS "frombase64string"
  OR process_command_line CONTAINS "http://"
  OR process_command_line CONTAINS "https://"
)

Rule 2 — Validated FortiClient EMS Parent Spawning High-Risk Script Host and LOLBin Execution

Purpose
Detect likely exploitation or execution-path variation by identifying high-risk script host and LOLBin execution from validated EMS parent context, enriched with argument-aware detection to reduce noise and improve precision.

MITRE ATT&CK Mapping
T1059 – Command and Scripting Interpreter
T1218 – System Binary Proxy Execution

SOC Usage Mode
Alert-capable supporting detection

Minimum Deployment Requirement

·        SentinelOne process creation telemetry must be enabled and retained

·        Parent-child process lineage must be available

·        EMS server assets must be positively identified through stable tenant asset scoping

·        EMS parent process names, image paths, service wrappers, and helper processes must be validated

·        Child process command-line visibility must be available for full enrichment effectiveness

·        Legitimate EMS maintenance, upgrade, or packaging workflows must be reviewed

Telemetry Dependency

·        Process creation telemetry

·        Parent process name and image path

·        Child process name

·        Child process command line

·        Stable EMS asset identifiers or grouping

·        Optional signer, integrity, and user context enrichment where available

Tuning Explanation

·        This rule moves beyond simple child-process matching and adds argument-aware constraints to reduce false positives

·        It focuses on high-risk execution patterns, not just presence of a LOLBin

·        Each child binary is paired with behavior more strongly indicating misuse:

o   remote content retrieval

o   script execution

o   encoded or indirect execution

·        This preserves detection strength while avoiding overly broad matches, especially for binaries like rundll32.exe and wmic.exe

Enforcement Method

·        Hard scoping to validated EMS assets

·        Hard scoping to validated EMS parent processes

·        Child-process scoping to high-risk LOLBins

·        Command-line enrichment gating for misuse patterns

·        Mandatory suppression of known legitimate workflows

Implementation Constraint Notes

·        This rule is dependent on command-line visibility; without it, precision drops significantly

·        Some LOLBins may appear in rare legitimate workflows; suppression must be applied where validated

·        If EMS parent-process identity is not fully validated, this rule must remain conditional

Variant Analysis

·        Covers common LOLBin-based execution paths:

o   script execution through mshta, wscript, cscript

o   proxy execution through regsvr32 and rundll32

o   retrieval and staging through certutil and wmic

·        Resistant to simple evasion that avoids cmd.exe or PowerShell

·        May miss in-memory-only execution, benign-looking arguments crafted to evade detection, or execution via uncommon binaries not included in the controlled set

Rule Regret Check
Deployment caution
Do not enable as production alerting until EMS parent validation and command-line visibility are confirmed

Confidence caution
High when argument-aware conditions are met; medium if reduced to child-process-only detection

Coverage value
High-value variant coverage for EMS-originated execution paths beyond direct interpreters

Production Ready
Conditional until EMS parent validation, EMS asset scoping, and command-line visibility validation are completed

Detection Logic / Deployment Template Code

-- SentinelOne Deep Visibility / Singularity XDR deployment template
-- Replace placeholders with tenant-validated values before production use

AgentOsType = "windows"
AND agent.uuid IN ($EMS_ASSET_IDS)
AND (
  parent_process_name IN ($EMS_PARENT_PROCESS_NAMES)
  OR parent_process_image_path IN ($EMS_PARENT_PROCESS_PATHS)
)
AND (
  (
    process_name = "mshta.exe"
    AND process_command_line CONTAINS "http"
  )
  OR (
    process_name = "certutil.exe"
    AND process_command_line CONTAINS "-urlcache"
  )
  OR (
    process_name = "regsvr32.exe"
    AND process_command_line CONTAINS "http"
  )
  OR (
    process_name = "rundll32.exe"
    AND (
      process_command_line CONTAINS "http"
      OR process_command_line CONTAINS ".dll,"
    )
  )
  OR (
    process_name = "wmic.exe"
    AND process_command_line CONTAINS "process call create"
  )
  OR (
    process_name IN ("wscript.exe","cscript.exe")
    AND (
      process_command_line CONTAINS ".js"
      OR process_command_line CONTAINS ".vbs"
      OR process_command_line CONTAINS "http"
    )
  )
)

Rule 3 — Corroborating EMS-Originated Execution with Downloader or External Retrieval Indicators

Purpose
Detect corroborating post-exploitation behavior by identifying EMS-originated suspicious execution combined with downloader-style or external retrieval indicators in command-line activity.

MITRE ATT&CK Mapping
T1105 – Ingress Tool Transfer
T1059 – Command and Scripting Interpreter

SOC Usage Mode
Correlation-first, corroborating-only

Minimum Deployment Requirement

·        SentinelOne process creation telemetry must be enabled

·        Parent-child lineage must be available

·        EMS assets must be scoped using stable identifiers

·        EMS parent processes must be validated

·        Command-line visibility must be confirmed

·        Legitimate outbound or retrieval behavior must be baselined

Telemetry Dependency

·        Process creation telemetry

·        Parent-child lineage

·        Child process command line

·        Optional process-network telemetry if available

Tuning Explanation

·        This rule is explicitly correlation-first and should not generate standalone high-confidence alerts

·        It is designed to increase confidence when suspicious EMS-originated execution shows clear payload retrieval or staging behavior

·        It focuses on strong retrieval indicators, not generic outbound behavior

·        Weak terms such as “download” are removed in favor of more deterministic signals

Enforcement Method

·        EMS asset scoping

·        EMS parent validation

·        Controlled child-process set

·        Strong command-line retrieval indicators

·        Mandatory suppression of legitimate administrative retrieval workflows

Implementation Constraint Notes

·        This rule does not prove malicious network activity

·        This rule does not cover internal-only pivoting or non-retrieval post-exploitation

·        If command-line visibility is absent, the rule must not be deployed as written

Variant Analysis

·        Covers PowerShell web retrieval, certutil download, mshta remote execution, and encoded payload staging

·        Misses internal lateral movement without retrieval, pre-positioned payloads, and obfuscated retrieval not visible in command line

Rule Regret Check
Deployment caution
Do not use as standalone alerting; requires baseline validation and pairing with Rule 1 or Rule 2

Confidence caution
Moderate standalone; high when correlated with Rule 1 or Rule 2

Coverage value
Strong corroborating signal for staged payload retrieval following EMS exploitation

Production Ready
Conditional until EMS validation, command-line visibility, and baseline tuning are completed

Detection Logic / Deployment Template Code

-- SentinelOne Deep Visibility / Singularity XDR deployment template

AgentOsType = "windows"
AND agent.uuid IN ($EMS_ASSET_IDS)
AND (
  parent_process_name IN ($EMS_PARENT_PROCESS_NAMES)
  OR parent_process_image_path IN ($EMS_PARENT_PROCESS_PATHS)
)
AND process_name IN (
  "powershell.exe",
  "cmd.exe",
  "mshta.exe",
  "certutil.exe",
  "rundll32.exe",
  "regsvr32.exe"
)
AND (
  process_command_line CONTAINS "invoke-webrequest"
  OR process_command_line CONTAINS "iwr "
  OR process_command_line CONTAINS "downloadstring"
  OR process_command_line CONTAINS "frombase64string"
  OR process_command_line CONTAINS "-enc "
  OR process_command_line CONTAINS "-encodedcommand "
  OR process_command_line CONTAINS "certutil -urlcache"
  OR process_command_line CONTAINS "mshta http"
)

Engineering Notes

·        These SentinelOne rules are deployment-ready templates pending tenant-specific validation

·        Validate the actual FortiClient EMS parent process names, service wrappers, helper processes, and installation paths before production deployment

·        Scope EMS servers by stable asset IDs, tags, dedicated groups, or equivalent authoritative asset controls rather than hostname substring matching alone

·        Confirm parent-child process lineage is available and reliable in the tenant

·        Confirm child process command-line visibility is available and reliable

·        Review whether EMS upgrades, maintenance, packaging, or admin workflows can legitimately launch the listed child binaries or interpreter patterns

·        For Rule 3, baseline legitimate downloader-like or retrieval-related administrative behavior before enabling alerting

·        Coverage remains conditional until parent-process localization, asset scoping validation, telemetry validation, and suppression tuning are completed

Splunk

Rule 1 — Suspicious EMS Web Access Without Corresponding Authentication or Session Evidence

Purpose

Detect likely exploitation of FortiClient EMS by identifying suspicious access to validated EMS privileged web paths without corresponding authentication, login, or session-establishment evidence within an expected time window.

MITRE ATT&CK Mapping

T1190 – Exploit Public-Facing Application

SOC Usage Mode

Correlation-first with optional alerting after validation

Minimum Deployment Requirement

·        EMS web, reverse proxy, IIS, or equivalent HTTP access logs must be ingested into Splunk

·        Authentication or session-establishment telemetry relevant to EMS must be ingested into Splunk

·        EMS assets and EMS privileged web paths must be validated before production deployment

·        Timestamp normalization across web and authentication data sources must be validated

·        This rule must not be deployed as high-confidence alerting until the tenant confirms what constitutes expected EMS authentication or session activity

Telemetry Dependency

·        HTTP or application access logs for EMS

·        Authentication logs, session logs, or equivalent EMS access-control telemetry

·        Stable EMS asset identifiers, hostnames, or IP mappings

·        Normalized timestamps across relevant data sources

Tuning Explanation

·        This rule implements the report’s core correlation condition: suspicious EMS access without corresponding authentication or session evidence

·        It is strongest when the tenant can reliably distinguish:

o   legitimate EMS administrative access

o   endpoint-management traffic

o   session-establishing or authenticated admin activity

·        The rule is intentionally correlation-first because missing-authentication logic is highly environment-dependent

·        Precision improves materially when EMS privileged paths are localized and normal administrator source ranges are understood

·        This rule should not be positioned as “proof of exploit success” unless the tenant’s authentication and session logging is known to be complete and trustworthy

Enforcement Method

·        Hard scoping to validated EMS assets

·        Hard scoping to validated EMS privileged paths

·        Correlation between suspicious access activity and absence of expected authentication or session evidence

·        Mandatory time-window validation and suppression review before production alerting

Implementation Constraint Notes

·        This rule is dependent on trustworthy authentication or session telemetry; if that telemetry is incomplete, confidence must be reduced

·        Some EMS environments may not log session establishment in a way that supports this analytic cleanly

·        If authentication telemetry is missing, delayed, or inconsistent, this rule should remain correlation-only or investigative rather than alert-capable

·        If normal EMS traffic includes privileged-path access without separately visible auth events, deployment must remain conditional

Variant Analysis

·        Covers unauthenticated or auth-bypass style access where suspicious EMS web access lacks expected accompanying auth/session evidence

·        Improves resilience against cases where network-only visibility is insufficient to prove missing authentication

·        May miss attacks if authentication/session logs are absent, incomplete, delayed, or stored outside Splunk

·        May underperform where legitimate EMS workflows do not generate clearly separable auth artifacts

Rule Regret Check
Deployment caution

Do not enable as high-confidence alerting until EMS path localization, log normalization, and auth/session visibility are validated

Confidence caution

High when EMS access logs and authentication/session logs are both complete and time-synchronized; materially lower otherwise

Coverage value

Very high-value correlation signal for detecting likely unauthenticated access to EMS privileged functionality

Production Ready

Conditional until EMS path validation, authentication/session telemetry validation, and time-window tuning are completed

Detection Logic / Deployment Template Code

| tstats summariesonly=false count min(_time) as firstTime max(_time) as lastTime values(Web.url) as url values(Web.http_method) as http_method values(Web.src) as src by Web.dest Web.url Web.http_method Web.src
| rename Web.dest as dest
| search dest IN ($EMS_HOSTS$)
| where match(url, "$EMS_PRIVILEGED_URI_REGEX$")
| eval access_window_start=firstTime-300, access_window_end=lastTime+300
| join type=left dest [
    search index=$EMS_AUTH_INDEX$ ($EMS_AUTH_SOURCETYPE_FILTER$)
    | eval auth_time=_time
    | stats count as auth_count min(auth_time) as auth_first max(auth_time) as auth_last by dest src
]
| eval auth_present=if(isnull(auth_count), 0, 1)
| where auth_present=0
| table firstTime lastTime src dest http_method url auth_present

Rule 2 — Suspicious EMS Web Access Followed by EMS-Originated Child Process Execution

Purpose

Detect likely exploitation by correlating suspicious access to validated EMS privileged web paths with subsequent EMS-originated child process execution on the same host within a constrained time window.

MITRE ATT&CK Mapping

T1190 – Exploit Public-Facing Application
T1059 – Command and Scripting Interpreter

SOC Usage Mode

Alert-capable supporting detection

Minimum Deployment Requirement

·        EMS web, reverse proxy, IIS, or equivalent HTTP access logs must be ingested into Splunk

·        Endpoint process creation telemetry for EMS hosts must be ingested into Splunk

·        EMS assets, EMS privileged paths, and EMS parent process identities must be validated before production deployment

·        Timestamp normalization across web and endpoint data sources must be validated

·        Process lineage fields sufficient to identify EMS-originated child processes must be available

Telemetry Dependency

·        EMS access logs

·        Endpoint process creation telemetry

·        Parent-child process lineage or equivalent parent process attribution

·        Stable EMS host identifiers across log sources

·        Normalized timestamps across web and endpoint data sources

Tuning Explanation

·        This rule implements the strongest practical cross-domain correlation available in Splunk for this CVE: suspicious EMS access followed by EMS-originated execution

·        It is the highest-value Splunk analytic in this set because it links:

o   likely inbound exploitation activity

o   a deterministic endpoint execution outcome

·        Precision depends on accurate localization of EMS parent processes and EMS privileged paths

·        The correlation window should be validated locally; shorter windows improve precision, while slightly longer windows may be needed in heavily buffered logging environments

·        Where the tenant already has strong SentinelOne coverage, this rule becomes a powerful confirmation and investigation accelerator rather than a substitute

Enforcement Method

·        Hard scoping to validated EMS assets

·        Hard scoping to validated EMS privileged paths

·        Hard scoping to validated EMS parent-process identities in endpoint telemetry

·        Time-bound correlation between access activity and EMS-originated child-process execution

Implementation Constraint Notes

·        This rule does not prove that the suspicious access caused the child process with cryptographic certainty; it provides strong temporal and host-based correlation

·        If process lineage is weak or parent attribution is incomplete, confidence must be reduced

·        If the tenant cannot confidently localize EMS parent processes, the endpoint side of this analytic should remain conditional

·        Some legitimate EMS maintenance or upgrade events may require suppression if they generate child processes close to access activity

Variant Analysis

·        Covers the most operationally important outcome of exploitation: suspicious access followed by execution from EMS context

·        Resilient against some URI or request-structure variation because it is outcome-focused rather than exploit-string-focused

·        May miss attacks where the child process is not visible, remains in-process, or occurs outside the chosen correlation window

·        May under-detect if endpoint telemetry is delayed or missing on the EMS host

Rule Regret Check
Deployment caution
Do not enable as high-confidence alerting until EMS path validation, EMS parent-process localization, and timestamp normalization are completed

Confidence caution
High when both EMS web and endpoint lineage telemetry are complete and well normalized; moderate if either side is partial

Coverage value
Extremely high-value correlation signal linking suspicious inbound activity to EMS-originated execution

Production Ready

Conditional until EMS path validation, EMS parent-process validation, endpoint lineage validation, and time-window tuning are completed

Detection Logic / Deployment Template Code

search index=$EMS_WEB_INDEX$ ($EMS_WEB_SOURCETYPE_FILTER$)
| eval dest=coalesce(dest, host, dvc)
| eval src=coalesce(src, clientip, c_ip)
| eval url=coalesce(uri, url, cs_uri_stem)
| where dest IN ($EMS_HOSTS$)
| where match(url, "$EMS_PRIVILEGED_URI_REGEX$")
| stats min(_time) as web_time values(url) as urls values(src) as srcs by dest
| join type=inner dest [
    search index=$EMS_ENDPOINT_INDEX$ ($EMS_ENDPOINT_SOURCETYPE_FILTER$)
    | eval dest=coalesce(dest, host, ComputerName, EndpointName)
    | eval parent_name=coalesce(parent_process_name, ParentImage, parent_process)
    | eval child_name=coalesce(process_name, Image, NewProcessName)
    | where dest IN ($EMS_HOSTS$)
    | where parent_name IN ($EMS_PARENT_PROCESS_NAMES$)
    | where child_name IN ("cmd.exe","powershell.exe","mshta.exe","rundll32.exe","wscript.exe","cscript.exe","wmic.exe","certutil.exe","regsvr32.exe")
    | stats min(_time) as exec_time values(parent_name) as parent_name values(child_name) as child_name values(process_command_line) as process_command_line by dest
]
| eval delta=exec_time-web_time
| where delta>=0 AND delta<=600
| table web_time exec_time delta dest srcs urls parent_name child_name process_command_line

Rule 3 — Suspicious EMS-Originated Execution with Downloader or External Retrieval Indicators

Purpose

Detect corroborating post-exploitation behavior by identifying suspicious EMS-originated child-process execution together with downloader-style or external retrieval indicators in endpoint telemetry, optionally strengthened by observed outbound network activity where available.

MITRE ATT&CK Mapping

T1105 – Ingress Tool Transfer
T1059 – Command and Scripting Interpreter

SOC Usage Mode

Correlation-first, corroborating-only

Minimum Deployment Requirement

·        Endpoint process creation telemetry for EMS hosts must be ingested into Splunk

·        EMS assets and EMS parent process identities must be validated

·        Command-line visibility for relevant child processes must be available

·        If optional network correlation is used, process-linked or host-linked outbound network telemetry must also be available and normalized

·        Legitimate maintenance or administrative retrieval workflows must be baselined before alerting

Telemetry Dependency

·        Endpoint process creation telemetry

·        Parent-child process lineage

·        Child process command line

·        Stable EMS host identifiers

·        Optional outbound network telemetry for the EMS host or child process where available

Tuning Explanation

·        This rule is intentionally corroborating-only and should not be treated as standalone exploit confirmation

·        It is designed to increase confidence when suspicious EMS-originated execution includes strong retrieval or staging indicators such as:

o   Invoke-WebRequest

o   encoded PowerShell

o   certutil URL cache retrieval

o   mshta remote execution

·        The rule is strongest when combined with Rule 1 or Rule 2 rather than used on its own

·        If the tenant has usable outbound network telemetry tied to the same host or process, that enrichment can increase confidence, but command-line retrieval indicators remain the required core

·        Weak or generic downloader terms are intentionally avoided to reduce noise

Enforcement Method

·        Hard scoping to validated EMS assets

·        Hard scoping to validated EMS parent process identities

·        Controlled child-process scoping

·        Strong retrieval or staging indicator matching in child process command lines

·        Optional correlation with outbound network activity where field availability supports it

·        Mandatory suppression of legitimate retrieval-oriented administrative workflows before production alerting

Implementation Constraint Notes

·        This rule does not prove malicious network activity by itself

·        This rule does not cover internal-only pivoting, pre-positioned payload execution, or non-retrieval post-exploitation

·        If command-line visibility is absent, this rule must not be deployed as written

·        If optional network telemetry is unavailable, the rule should remain command-line corroboration only rather than claiming network-confirmed retrieval

Variant Analysis

·        Covers practical staged retrieval patterns following EMS-originated execution

·        Resilient against some variation because it focuses on strong retrieval behaviors rather than generic “download” language

·        May miss obfuscated retrieval not visible in the command line, internal-only staging, or payloads already present on disk

·        Confidence improves materially when the tenant confirms process-linked outbound network telemetry

Rule Regret Check
Deployment caution
Do not use as standalone alerting; requires baseline validation and is strongest when paired with Rule 1 or Rule 2

Confidence caution
Moderate as written; high when correlated with Rule 1 or Rule 2 and supported by good command-line visibility

Coverage value
Strong corroborating signal for staged payload retrieval or external content access following EMS-originated execution

Production Ready

Conditional until EMS asset validation, EMS parent-process validation, command-line visibility validation, and suppression tuning are completed

Detection Logic / Deployment Template Code

search index=$EMS_ENDPOINT_INDEX$ ($EMS_ENDPOINT_SOURCETYPE_FILTER$)
| eval dest=coalesce(dest, host, ComputerName, EndpointName)
| eval parent_name=coalesce(parent_process_name, ParentImage, parent_process)
| eval child_name=coalesce(process_name, Image, NewProcessName)
| eval cmdline=coalesce(process_command_line, CommandLine, ProcessCommandLine)
| where dest IN ($EMS_HOSTS$)
| where parent_name IN ($EMS_PARENT_PROCESS_NAMES$)
| where child_name IN ("powershell.exe","cmd.exe","mshta.exe","certutil.exe","rundll32.exe","regsvr32.exe")
| where like(lower(cmdline), "%invoke-webrequest%")
    OR like(lower(cmdline), "%iwr %")
    OR like(lower(cmdline), "%downloadstring%")
    OR like(lower(cmdline), "%frombase64string%")
    OR like(lower(cmdline), "%-enc %")
    OR like(lower(cmdline), "%-encodedcommand %")
    OR like(lower(cmdline), "%certutil -urlcache%")
    OR like(lower(cmdline), "%mshta http%")
| table time dest parentname child_name cmdline

Engineering Note

·        These Splunk rules are deployment-ready templates pending tenant-specific validation

·        Validate the actual FortiClient EMS assets, privileged URI paths, and EMS parent process identities before production deployment

·        Normalize field mappings across web, authentication/session, and endpoint data sources before enabling alerting

·        Confirm timestamps are synchronized closely enough for short-window correlation across data sources

·        Review whether legitimate EMS administration, upgrades, maintenance, packaging, or troubleshooting workflows can generate the modeled access, execution, or retrieval patterns

·        For Rule 1, confirm that authentication or session-establishment telemetry is complete enough to support “access without corresponding auth” logic

·        For Rule 2, confirm that endpoint lineage is reliable enough to attribute child processes to EMS parent context

·        For Rule 3, confirm command-line visibility is reliable and baseline legitimate retrieval-oriented admin activity before alerting

·        Coverage remains conditional until asset localization, field normalization, telemetry validation, and suppression tuning are completed

Elastic

Rule 1 — Suspicious Access to Validated FortiClient EMS Privileged Web Paths Without Corresponding Authentication or Session Context

Purpose
Detect likely exploitation of FortiClient EMS by identifying suspicious access to validated EMS privileged web paths without corresponding authentication or session-establishment evidence on the same EMS asset within an expected time window.

MITRE ATT&CK Mapping
T1190 – Exploit Public-Facing Application

SOC Usage Mode
Correlation-first with optional alerting after validation

Minimum Deployment Requirement

·        Elastic must ingest EMS web, reverse proxy, IIS, or equivalent HTTP access logs

·        Authentication or session-establishment telemetry relevant to EMS must be ingested into Elastic

·        EMS assets and EMS privileged web paths must be validated before production deployment

·        Timestamps across web and authentication data sources must be normalized

·        The tenant must validate what constitutes expected EMS authentication or session evidence before enabling production alerting

Telemetry Dependency

·        HTTP or application access logs for EMS

·        Authentication logs, session logs, or equivalent EMS access-control telemetry

·        Stable EMS asset identifiers, hostnames, or IP mappings

·        Normalized timestamps across relevant data sources

Tuning Explanation

·        This rule implements the auth-gap condition for Elastic as a standalone platform

·        It is strongest when the tenant can reliably distinguish privileged EMS web access from routine endpoint-management traffic and associate auth/session activity to the same EMS asset

·        It is intentionally correlation-first because authentication and session logging quality varies materially by tenant

·        Precision improves when EMS privileged paths are localized and known administrative source patterns are reviewed and suppressed where appropriate

·        This rule should not be described as proof of exploit success unless authentication and session telemetry is complete, trustworthy, and properly mapped to the EMS asset

Enforcement Method

·        Hard scoping to validated EMS assets

·        Hard scoping to validated EMS privileged web paths

·        Correlation between suspicious access activity and absence of expected authentication or session evidence on the same EMS asset within a controlled time window

·        Mandatory time-window validation and suppression review before production alerting

Implementation Constraint Notes

·        This rule depends on trustworthy authentication or session telemetry

·        If EMS session establishment is not logged clearly, confidence must be lowered

·        If normal EMS privileged access does not produce separable authentication artifacts, the rule should remain investigative or correlation-only

·        If authentication telemetry is delayed, incomplete, or stored outside Elastic, deployment must remain conditional

Variant Analysis

·        Covers auth-bypass style access where suspicious EMS web activity lacks expected accompanying authentication context

·        More resilient than simple web-only detection because it validates missing auth evidence, not just suspicious path access

·        May miss attacks where authentication/session logs are absent, incomplete, delayed, or poorly mapped

·        May underperform where legitimate EMS workflows do not generate clearly separable auth artifacts

Rule Regret Check
Deployment caution
Do not enable as high-confidence alerting until EMS path localization, log normalization, and auth/session visibility are validated

Confidence caution
High when EMS web and authentication/session telemetry are complete, synchronized, and mapped to the same asset; materially lower otherwise

Coverage value
Very high-value standalone Elastic signal for likely unauthenticated access to EMS privileged functionality

Production Ready
Conditional until EMS path validation, authentication/session telemetry validation, asset mapping validation, and time-window tuning are completed

Detection Logic / Deployment Template Code

/* Elastic EQL correlation template
   Replace placeholders with tenant-validated values before production use
   Validate that host.name is the correct shared join field across web and auth/session data */

sequence by host.name with maxspan=5m
  [ any where
host.name in ($EMS_HOSTS)
      and event.category == "web"
      and url.path regex $EMS_PRIVILEGED_URI_REGEX
  ]
  ![ any where
host.name in ($EMS_HOSTS)
      and (
        event.category == "authentication"
        or event.dataset in ($EMS_AUTH_DATASETS)
        or message regex $EMS_SESSION_AUTH_REGEX
      )
  ]

Rule 2 — Suspicious EMS Web Access Followed by EMS-Originated Child Process Execution

Purpose

Detect likely exploitation by correlating suspicious access to validated EMS privileged web paths with subsequent EMS-originated child-process execution on the same EMS host within a constrained time window.

MITRE ATT&CK Mapping

T1190 – Exploit Public-Facing Application
T1059 – Command and Scripting Interpreter

SOC Usage Mode

Alert-capable supporting detection

Minimum Deployment Requirement

·        Elastic must ingest EMS web, reverse proxy, IIS, or equivalent HTTP access logs

·        Endpoint process creation telemetry for EMS hosts must be ingested into Elastic

·        EMS assets, EMS privileged paths, and EMS parent process identities must be validated before production deployment

·        Timestamps across web and endpoint data sources must be normalized

·        Process lineage fields sufficient to identify EMS-originated child processes must be available

Telemetry Dependency

·        EMS access logs

·        Endpoint process creation telemetry

·        Parent-child process lineage or equivalent parent attribution

·        Stable EMS host identifiers across data sources

·        Normalized timestamps across web and endpoint sources

Tuning Explanation

·        This is the anchor Elastic rule because it links likely inbound exploitation activity to a deterministic endpoint execution outcome

·        Precision depends on accurate localization of EMS parent processes, EMS privileged paths, and shared host identifiers across the web and endpoint data

·        The correlation window should be validated locally; shorter windows improve precision, while slightly longer windows may be required in buffered logging environments

·        This rule is outcome-focused rather than exploit-string-focused, which improves resilience against request variation

·        Legitimate EMS maintenance or upgrade activity that spawns child processes near web access events must be reviewed and suppressed before production alerting

Enforcement Method

·        Hard scoping to validated EMS assets

·        Hard scoping to validated EMS privileged paths

·        Hard scoping to validated EMS parent-process identities in endpoint telemetry

·        Time-bound correlation between access activity and EMS-originated child-process execution on the same EMS host

Implementation Constraint Notes

·        This rule provides strong temporal and host-based correlation, not cryptographic proof of causation

·        If process lineage is weak or parent attribution is incomplete, confidence must be reduced

·        If the tenant cannot confidently localize EMS parent processes, the endpoint portion of this analytic must remain conditional

·        If endpoint telemetry is delayed materially, the correlation window must be tuned accordingly

Variant Analysis

·        Covers the most operationally important exploit outcome: suspicious EMS access followed by execution from EMS context

·        Resilient against request-structure variation because it focuses on execution outcome

·        May miss attacks where the child process is not visible, remains in-process, or occurs outside the chosen correlation window

·        May under-detect if endpoint telemetry is delayed or missing on the EMS host

Rule Regret Check
Deployment caution

Do not enable as high-confidence alerting until EMS path validation, EMS parent-process localization, host-field normalization, and timestamp normalization are completed

Confidence caution

High when both EMS web and endpoint lineage telemetry are complete, well normalized, and joined on the correct host field; moderate if either side is partial

Coverage value

Extremely high-value standalone Elastic signal linking suspicious inbound activity to EMS-originated execution

Production Ready

Conditional until EMS path validation, EMS parent-process validation, endpoint lineage validation, host-field normalization, and time-window tuning are completed

Detection Logic / Deployment Template Code

/* Elastic EQL sequence template
   Replace placeholders with tenant-validated values before production use
   Validate that host.name is the correct shared join field across web and endpoint data */

sequence by host.name with maxspan=10m
  [ any where
host.name in ($EMS_HOSTS)
      and event.category == "web"
      and url.path regex $EMS_PRIVILEGED_URI_REGEX
  ]
  [ process where
host.name in ($EMS_HOSTS)
      and process.parent.name in ($EMS_PARENT_PROCESS_NAMES)
      and process.name in (
        "cmd.exe",
        "powershell.exe",
        "mshta.exe",
        "rundll32.exe",
        "wscript.exe",
        "cscript.exe",
        "wmic.exe",
        "certutil.exe",
        "regsvr32.exe"
      )
  ]

Rule 3 — EMS-Originated Suspicious Execution with Retrieval or Staging Indicators

Purpose

Detect corroborating post-exploitation behavior by identifying suspicious EMS-originated child-process execution together with retrieval-oriented or staging-oriented command-line indicators.

MITRE ATT&CK Mapping

T1105 – Ingress Tool Transfer
T1059 – Command and Scripting Interpreter

SOC Usage Mode

Correlation-first, corroborating-only

Minimum Deployment Requirement

·        Endpoint process creation telemetry for EMS hosts must be ingested into Elastic

·        EMS assets and EMS parent process identities must be validated

·        Command-line visibility for relevant child processes must be available

·        Legitimate maintenance or retrieval-oriented administrative behavior must be baselined before alerting

Telemetry Dependency

·        Endpoint process creation telemetry

·        Parent-child process lineage

·        Child process command line

·        Stable EMS host identifiers

·        Optional outbound network telemetry where available, though command-line indicators remain the required core

Tuning Explanation

·        This rule is intentionally corroborating-only and should not be treated as standalone exploit confirmation

·        It is designed to increase confidence when suspicious EMS-originated execution includes strong retrieval or staging indicators such as:

o   Invoke-WebRequest

o   encoded PowerShell

o   certutil URL cache retrieval

o   mshta remote execution

·        Weak or generic downloader terms are intentionally avoided to reduce noise

·        The rule is strongest when paired analytically with the execution rule, but it remains a standalone Elastic analytic within its own telemetry model

Enforcement Method

·        Hard scoping to validated EMS assets

·        Hard scoping to validated EMS parent process identities

·        Controlled child-process scoping

·        Strong retrieval or staging indicator matching in child-process command lines

·        Mandatory suppression of legitimate retrieval-oriented administrative workflows before production alerting

Implementation Constraint Notes

·        This rule does not prove malicious network activity by itself

·        This rule does not cover internal-only pivoting, pre-positioned payload execution, or non-retrieval post-exploitation

·        If command-line visibility is absent, this rule must not be deployed as written

·        If optional network telemetry is unavailable, the rule should remain command-line corroboration only rather than claiming network-confirmed retrieval

Variant Analysis

·        Covers practical staged retrieval patterns following EMS-originated execution

·        Resilient against some variation because it focuses on strong retrieval behaviors rather than generic “download” language

·        May miss obfuscated retrieval not visible in command line, internal-only staging, or payloads already present on disk

·        Confidence improves when the tenant also has usable process-linked outbound network telemetry

Rule Regret Check
Deployment caution
Do not use as standalone alerting; requires baseline validation and is strongest when paired analytically with the execution rule

Confidence caution
Moderate as written; high only when used as corroborating evidence alongside suspicious EMS-originated execution

Coverage value
Strong standalone Elastic corroborating signal for staged payload retrieval or external content access following EMS-originated execution

Production Ready

Conditional until EMS asset validation, EMS parent-process validation, command-line visibility validation, and suppression tuning are completed

Detection Logic / Deployment Template Code

/* Elastic EQL / process template
   Replace placeholders with tenant-validated values before production use */

process where
host.name in ($EMS_HOSTS)
  and process.parent.name in ($EMS_PARENT_PROCESS_NAMES)
  and process.name in (
    "powershell.exe",
    "cmd.exe",
    "mshta.exe",
    "certutil.exe",
    "rundll32.exe",
    "regsvr32.exe"
  )
  and (
    stringContains(process.command_line, "invoke-webrequest")
    or stringContains(process.command_line, "iwr ")
    or stringContains(process.command_line, "downloadstring")
    or stringContains(process.command_line, "frombase64string")
    or stringContains(process.command_line, "-enc ")
    or stringContains(process.command_line, "-encodedcommand ")
    or stringContains(process.command_line, "certutil -urlcache")
    or stringContains(process.command_line, "mshta http")
  )

Engineering Note

·        These Elastic rules are deployment-ready templates pending tenant-specific validation

·        Validate the actual FortiClient EMS assets, privileged URI paths, and EMS parent process identities before production deployment

·        Normalize field mappings across web, authentication/session, and endpoint data sources before enabling alerting

·        Confirm timestamps are synchronized closely enough for short-window correlation across data sources

·        Validate that the same host identifier field is truly joinable across the required data sources before using sequence logic for production alerting

·        Review whether legitimate EMS administration, upgrades, maintenance, packaging, or troubleshooting workflows can generate the modeled access, execution, or retrieval patterns

·        For Rule 1, confirm that authentication or session-establishment telemetry is complete enough to support access-without-corresponding-auth logic

·        For Rule 2, confirm that endpoint lineage is reliable enough to attribute child processes to EMS parent context

·        For Rule 3, confirm command-line visibility is reliable and baseline legitimate retrieval-oriented administrative behavior before alerting

·        Coverage remains conditional until asset localization, field normalization, telemetry validation, join-field validation, and suppression tuning are completed

QRadar

Rule 1 — Suspicious FortiClient EMS Privileged Web Access Without Corresponding Authentication or Session Context

Purpose
Detect likely exploitation of FortiClient EMS by identifying suspicious access to validated EMS privileged web paths without corresponding authentication or session-establishment evidence on the same EMS asset within an expected time window.

MITRE ATT&CK Mapping
T1190 – Exploit Public-Facing Application

SOC Usage Mode
Correlation-first with optional alerting after validation

Minimum Deployment Requirement

·        QRadar must ingest EMS web, reverse proxy, IIS, or equivalent HTTP access logs

·        Authentication or session-establishment telemetry relevant to EMS must be ingested into QRadar

·        EMS assets and EMS privileged web paths must be validated before production deployment

·        Timestamps across web and authentication data sources must be normalized

·        The tenant must validate what constitutes expected EMS authentication or session evidence before enabling production alerting

·        This rule should be implemented using QRadar building blocks plus correlation logic rather than treated as a simplistic one-layer negative match

Telemetry Dependency

·        HTTP or application access logs for EMS

·        Authentication logs, session logs, or equivalent EMS access-control telemetry

·        Stable EMS asset identifiers, hostnames, or IP mappings

·        Normalized timestamps across relevant data sources

·        Reliable parser normalization for both EMS web activity and EMS authentication or session evidence

Tuning Explanation

·        This rule implements the auth-gap condition for QRadar as a standalone platform

·        It is strongest when the tenant can reliably distinguish privileged EMS web access from routine endpoint-management traffic and associate auth or session activity to the same EMS asset

·        It is intentionally correlation-first because authentication and session logging quality varies materially by tenant

·        Precision improves when EMS privileged paths are localized and known administrative source patterns are reviewed and suppressed where appropriate

·        In QRadar, the most realistic implementation is:

o   a building block for suspicious privileged EMS web access

o   a building block for valid EMS authentication or session evidence

o   a correlation rule that identifies privileged access without matching auth or session evidence in the expected window on the same asset

·        This rule should not be described as proof of exploit success unless authentication and session telemetry is complete, trustworthy, and properly mapped to the EMS asset

Enforcement Method

·        Hard scoping to validated EMS assets

·        Hard scoping to validated EMS privileged web paths

·        Building-block-driven correlation between suspicious access activity and absence of expected authentication or session evidence on the same EMS asset within a controlled time window

·        Mandatory time-window validation and suppression review before production alerting

Implementation Constraint Notes

·        This rule depends on trustworthy authentication or session telemetry

·        If EMS session establishment is not logged clearly, confidence must be lowered

·        If normal EMS privileged access does not produce separable authentication artifacts, the rule should remain investigative or correlation-only

·        If authentication telemetry is delayed, incomplete, or stored outside QRadar, deployment must remain conditional

·        If parser normalization is inconsistent, negative-condition logic may produce avoidable noise and should not be promoted to high-severity alerting

Variant Analysis

·        Covers auth-bypass style access where suspicious EMS web activity lacks expected accompanying authentication context

·        More resilient than simple web-only detection because it validates missing auth evidence, not just suspicious path access

·        May miss attacks where authentication or session logs are absent, incomplete, delayed, or poorly mapped

·        May underperform where legitimate EMS workflows do not generate clearly separable auth artifacts

Rule Regret Check
Deployment caution
Do not enable as high-confidence alerting until EMS path localization, log normalization, auth or session visibility, and same-asset mapping are validated

Confidence caution
High when EMS web and authentication or session telemetry are complete, synchronized, and mapped to the same asset; materially lower otherwise

Coverage value
Very high-value standalone QRadar signal for likely unauthenticated access to EMS privileged functionality

Production Ready
Conditional until EMS path validation, authentication or session telemetry validation, asset mapping validation, parser normalization validation, and time-window tuning are completed

Detection Logic / Deployment Template Code

QRadar Correlation Rule

Rule Name
FortiClient EMS Suspicious Privileged Web Access Without Corresponding Authentication or Session Context

Rule Type
Building Block plus Correlation Rule

Required Building Block A
FortiClient EMS Suspicious Privileged Web Access
Matches when:
- Log Source Type is one of: $EMS_WEB_LOG_SOURCES$
- Destination IP or Destination Hostname is in: $EMS_HOSTS$
- URL, Request URI, or Parsed Path matches: $EMS_PRIVILEGED_URI_PATTERN$

Required Building Block B
FortiClient EMS Authentication or Session Evidence
Matches when:
- Log Source Type is one of: $EMS_AUTH_LOG_SOURCES$
- Destination IP, Hostname, or Asset Identifier maps to: $EMS_HOSTS$
- Event Category, QID, or normalized message indicates:
  - authentication success
  - login
  - session establishment
  - authorization success
  - equivalent EMS access-control context

Correlation Rule Logic
Trigger when:
- Building Block A is matched
- and there is no matching Building Block B event on the same EMS asset within 5 minutes before or after the suspicious EMS web-access event

Rule Conditions
- correlate on the same EMS asset
- suppress known legitimate administrative sources where applicable
- validate auth or session telemetry completeness before enabling production alerting
- set severity according to authentication telemetry quality

Suggested Severity
- Medium when auth/session completeness is uncertain
- High only when auth/session telemetry is validated as complete and trustworthy

Responses
- create an offense
- add destination IP or hostname to reference set: EMS_Suspicious_Unauth_Access
- add source IP from the web-access event to reference set: EMS_Suspicious_Source_IPs
- annotate offense with rule label: FortiClient EMS Access Without Corresponding Auth Context

Rule 2 — Suspicious FortiClient EMS Web Access Followed by EMS-Originated Child Process Execution

Purpose
Detect likely exploitation by correlating suspicious access to validated EMS privileged web paths with subsequent EMS-originated child-process execution on the same EMS host within a constrained time window.

MITRE ATT&CK Mapping
T1190 – Exploit Public-Facing Application
T1059 – Command and Scripting Interpreter

SOC Usage Mode
Alert-capable supporting detection

Minimum Deployment Requirement

·        QRadar must ingest EMS web, reverse proxy, IIS, or equivalent HTTP access logs

·        Endpoint process creation telemetry for EMS hosts must be ingested into QRadar

·        EMS assets, EMS privileged paths, and EMS parent process identities must be validated before production deployment

·        Timestamps across web and endpoint data sources must be normalized

·        Process lineage fields sufficient to identify EMS-originated child processes must be available

Telemetry Dependency

·        EMS access logs

·        Endpoint process creation telemetry

·        Parent-child process lineage or equivalent parent attribution

·        Stable EMS host identifiers across data sources

·        Normalized timestamps across web and endpoint sources

Tuning Explanation

·        This is the anchor QRadar rule because it links likely inbound exploitation activity to a deterministic endpoint execution outcome

·        Precision depends on accurate localization of EMS parent processes, EMS privileged paths, and shared host identifiers across the web and endpoint data

·        The correlation window should be validated locally; shorter windows improve precision, while slightly longer windows may be required in buffered logging environments

·        This rule is outcome-focused rather than exploit-string-focused, which improves resilience against request variation

·        Legitimate EMS maintenance or upgrade activity that spawns child processes near web access events must be reviewed and suppressed before production alerting

·        This should be the highest-priority rule in the QRadar set because it provides the strongest standalone evidence of suspicious access leading to EMS-context execution

Enforcement Method

·        Hard scoping to validated EMS assets

·        Hard scoping to validated EMS privileged web paths

·        Hard scoping to validated EMS parent-process identities in endpoint telemetry

·        Time-bound correlation between access activity and EMS-originated child-process execution on the same EMS host

Implementation Constraint Notes

·        This rule provides strong temporal and host-based correlation, not cryptographic proof of causation

·        If process lineage is weak or parent attribution is incomplete, confidence must be reduced

·        If the tenant cannot confidently localize EMS parent processes, the endpoint portion of this analytic must remain conditional

·        If endpoint telemetry is delayed materially, the correlation window must be tuned accordingly

Variant Analysis

·        Covers the most operationally important exploit outcome: suspicious EMS access followed by execution from EMS context

·        Resilient against request-structure variation because it focuses on execution outcome

·        May miss attacks where the child process is not visible, remains in-process, or occurs outside the chosen correlation window

·        May under-detect if endpoint telemetry is delayed or missing on the EMS host

Rule Regret Check
Deployment caution
Do not enable as high-confidence alerting until EMS path validation, EMS parent-process localization, host-field normalization, and timestamp normalization are completed

Confidence caution
High when both EMS web and endpoint lineage telemetry are complete, well normalized, and joined on the correct host field; moderate if either side is partial

Coverage value
Extremely high-value standalone QRadar signal linking suspicious inbound activity to EMS-originated execution

Production Ready
Conditional until EMS path validation, EMS parent-process validation, endpoint lineage validation, host-field normalization, and time-window tuning are completed

Detection Logic / Deployment Template Code

QRadar Correlation Rule

Rule Name
FortiClient EMS Suspicious Web Access Followed by EMS-Originated Child Process Execution

Rule Type
Event Sequence Rule

Test 1
when an event matches all of the following:
- Log Source Type is one of: $EMS_WEB_LOG_SOURCES$
- Destination IP or Destination Hostname is in: $EMS_HOSTS$
- URL, Request URI, or Parsed Path matches: $EMS_PRIVILEGED_URI_PATTERN$

Test 2
and when followed within 10 minutes by an event matches all of the following:
- Log Source Type is one of: $EMS_ENDPOINT_LOG_SOURCES$
- Destination IP, Hostname, or Asset Identifier maps to the same EMS asset as Test 1
- Parent Process Name or Parent Image is one of: $EMS_PARENT_PROCESS_NAMES$
- Process Name is one of:
  - cmd.exe
  - powershell.exe
  - mshta.exe
  - rundll32.exe
  - wscript.exe
  - cscript.exe
  - wmic.exe
  - certutil.exe
  - regsvr32.exe

Rule Conditions
- correlate events on the same EMS asset
- trigger only once per EMS asset within the selected response interval
- use validated host-field normalization before production deployment

Suggested Severity
- High

Responses
- create an offense
- add destination IP or hostname to reference set: EMS_Suspicious_Access_Execution
- add source IP from Test 1 to reference set: EMS_Suspicious_Source_IPs
- annotate offense with rule label: FortiClient EMS Access to Execution Correlation

Rule 3 — FortiClient EMS Suspicious Execution with Retrieval or Staging Indicators

Purpose
Detect corroborating post-exploitation behavior by identifying suspicious EMS-originated child-process execution together with retrieval-oriented or staging-oriented command-line indicators.

MITRE ATT&CK Mapping
T1105 – Ingress Tool Transfer
T1059 – Command and Scripting Interpreter

SOC Usage Mode
Correlation-first, corroborating-only

Minimum Deployment Requirement

·        Endpoint process creation telemetry for EMS hosts must be ingested into QRadar

·        EMS assets and EMS parent process identities must be validated

·        Command-line visibility for relevant child processes must be available

·        Legitimate maintenance or retrieval-oriented administrative behavior must be baselined before alerting

Telemetry Dependency

·        Endpoint process creation telemetry

·        Parent-child process lineage

·        Child process command line

·        Stable EMS host identifiers

·        Optional outbound network telemetry where available, though command-line indicators remain the required core

Tuning Explanation

·        This rule is intentionally corroborating-only and should not be treated as standalone exploit confirmation

·        It is designed to increase confidence when suspicious EMS-originated execution includes strong retrieval or staging indicators such as:

o   Invoke-WebRequest

o   encoded PowerShell

o   certutil URL cache retrieval

o   mshta remote execution

·        Weak or generic downloader terms are intentionally avoided to reduce noise

·        The rule is strongest when paired analytically with the execution rule, but it remains a standalone QRadar analytic within its own telemetry model

·        Command-line parser quality must be validated before enabling alerting because some endpoint sources tokenize or truncate process arguments inconsistently in QRadar

Enforcement Method

·        Hard scoping to validated EMS assets

·        Hard scoping to validated EMS parent process identities

·        Controlled child-process scoping

·        Strong retrieval or staging indicator matching in child-process command lines

·        Mandatory suppression of legitimate retrieval-oriented administrative workflows before production alerting

Implementation Constraint Notes

·        This rule does not prove malicious network activity by itself

·        This rule does not cover internal-only pivoting, pre-positioned payload execution, or non-retrieval post-exploitation

·        If command-line visibility is absent or poorly parsed, this rule must not be deployed as written

·        If optional network telemetry is unavailable, the rule should remain command-line corroboration only rather than claiming network-confirmed retrieval

·        Offense priority should remain lower than Rule 2 unless additional corroboration exists

Variant Analysis

·        Covers practical staged retrieval patterns following EMS-originated execution

·        Resilient against some variation because it focuses on strong retrieval behaviors rather than generic “download” language

·        May miss obfuscated retrieval not visible in command line, internal-only staging, or payloads already present on disk

·        Confidence improves when the tenant also has usable process-linked outbound network telemetry

Rule Regret Check
Deployment caution
Do not use as standalone alerting; requires baseline validation and is strongest when paired analytically with the execution rule

Confidence caution
Moderate as written; high only when used as corroborating evidence alongside suspicious EMS-originated execution

Coverage value
Strong standalone QRadar corroborating signal for staged payload retrieval or external content access following EMS-originated execution

Production Ready
Conditional until EMS asset validation, EMS parent-process validation, command-line visibility validation, parser validation, and suppression tuning are completed

Detection Logic / Deployment Template Code

QRadar Correlation Rule

Rule Name
FortiClient EMS Suspicious Execution with Retrieval or Staging Indicators

Rule Type
Event Rule

Test
when an event matches all of the following:
- Log Source Type is one of: $EMS_ENDPOINT_LOG_SOURCES$
- Destination IP, Hostname, or Asset Identifier is in: $EMS_HOSTS$
- Parent Process Name or Parent Image is one of: $EMS_PARENT_PROCESS_NAMES$
- Process Name is one of:
  - powershell.exe
  - cmd.exe
  - mshta.exe
  - certutil.exe
  - rundll32.exe
  - regsvr32.exe
- Command line contains one or more of:
  - invoke-webrequest
  - iwr
  - downloadstring
  - frombase64string
  - -enc
  - -encodedcommand
  - certutil -urlcache
  - mshta http

Rule Conditions
- suppress validated legitimate maintenance or retrieval-oriented administrative workflows
- keep offense severity lower than Rule 2 unless additional corroboration exists
- do not classify as standalone exploit confirmation
- validate command-line parser quality before production deployment

Suggested Severity
- Medium
- Raise only when additional corroboration exists

Responses
- create an offense
- add destination IP or hostname to reference set: EMS_Retrieval_Execution
- annotate offense with rule label: FortiClient EMS Retrieval or Staging Execution Indicator

Engineering Note

·        These QRadar rules are deployment-ready templates pending tenant-specific validation

·        Validate the actual FortiClient EMS assets, privileged URI paths, and EMS parent process identities before production deployment

·        Normalize field mappings across web, authentication/session, and endpoint data sources before enabling alerting

·        Confirm timestamps are synchronized closely enough for short-window correlation across data sources

·        Validate that the same host identifier field is truly joinable across the required data sources before using cross-log correlation for production alerting

·        For Rule 1, implement using building blocks plus negative-condition correlation logic rather than assuming a simplistic single-layer negative test will be robust across all parsers and data sources

·        Review whether legitimate EMS administration, upgrades, maintenance, packaging, or troubleshooting workflows can generate the modeled access, execution, or retrieval patterns

·        For Rule 1, confirm that authentication or session-establishment telemetry is complete enough to support access-without-corresponding-auth logic

·        For Rule 2, confirm that endpoint lineage is reliable enough to attribute child processes to EMS parent context

·        For Rule 3, confirm command-line visibility and parser quality are reliable and baseline legitimate retrieval-oriented administrative behavior before alerting

·        Coverage remains conditional until asset localization, field normalization, telemetry validation, join-field validation, parser validation, and suppression tuning are completed

Sigma

Rule 1 — Suspicious FortiClient EMS Privileged Web Access Without Corresponding Authentication or Session Context

Purpose
Detect likely exploitation of FortiClient EMS by identifying suspicious access to validated EMS privileged web paths without corresponding authentication or session-establishment evidence on the same EMS asset within an expected time window.

MITRE ATT&CK Mapping
T1190 – Exploit Public-Facing Application

SOC Usage Mode
Correlation-first with optional alerting after validation

Minimum Deployment Requirement

·        Web access logs and authentication/session telemetry must be available in the same analytics backend

·        EMS assets and EMS privileged URI patterns must be validated

·        Timestamp normalization must be confirmed

·        Backend must support correlation logic for negative-condition detection

Telemetry Dependency

·        HTTP or application access logs for EMS

·        Authentication logs, session logs, or equivalent EMS access-control telemetry

·        Stable EMS asset identifiers or equivalent joinable fields

·        Normalized timestamps across data sources

Tuning Explanation

·        This rule implements the auth-gap detection concept as a portable Sigma analytic

·        Precision depends on the ability to associate web access and authentication/session events to the same EMS asset

·        Must remain correlation-first due to variability in authentication telemetry quality

·        Should not be interpreted as exploit confirmation unless authentication/session telemetry is complete and reliable

Enforcement Method

·        Hard scoping to EMS assets and validated privileged URI patterns

·        Correlation between suspicious web access and absence of expected authentication/session evidence

·        Backend-specific implementation of negative-condition logic is required

Implementation Constraint Notes

·        Sigma does not natively support reliable negative temporal correlation across all backends

·        This rule represents a correlation concept and must be implemented using backend-native logic (e.g., Splunk, Elastic, QRadar correlation rules)

·        If authentication/session telemetry is incomplete or external, detection confidence must be reduced

·        Field names used below are illustrative and must be mapped to backend-specific normalized fields before deployment

Variant Analysis

·        Covers auth-bypass style access lacking expected authentication context

·        More resilient than path-only detection

·        May fail where auth/session telemetry is incomplete or non-joinable

Rule Regret Check
Deployment caution
Do not enable as high-confidence alerting without validated auth/session telemetry and backend correlation support

Confidence caution
High when telemetry is complete and normalized; low otherwise

Coverage value
High-value signal for unauthenticated access attempts

Production Ready
Conditional upon backend correlation implementation, field mapping validation, and telemetry completeness

Detection Logic / Deployment Template Code

title: FortiClient EMS Suspicious Privileged Web Access Without Corresponding Authentication or Session Context
id: 5f2b6dc6-7d3b-4b4e-9b4a-ems-auth-gap-001
status: experimental
description: Conceptual detection of EMS privileged web access without corresponding authentication or session activity. Requires backend-specific correlation implementation.
references:
  - Internal CyberDax S25 FortiClient EMS detection model
author: CyberDax
date: 2026-04-07
tags:
  - attack.t1190
logsource:
  category: webserver
detection:
  selection_web:
    destination.hostname|in: $EMS_HOSTS$
    url.path|re: $EMS_PRIVILEGED_URI_REGEX$
  condition: selection_web
falsepositives:
  - Legitimate EMS administrative activity where authentication telemetry is not present or not correlated
level: medium
fields:
  - source.ip
  - destination.hostname
  - url.path

Rule 2 — Suspicious FortiClient EMS Web Access Followed by EMS-Originated Child Process Execution

Purpose
Detect likely exploitation by correlating suspicious EMS web access with subsequent EMS-originated process execution.

MITRE ATT&CK Mapping
T1190 – Exploit Public-Facing Application
T1059 – Command and Scripting Interpreter

SOC Usage Mode
Alert-capable supporting detection

Minimum Deployment Requirement

·        Web logs and endpoint process telemetry must be available

·        Parent-child process relationships must be available

·        EMS asset mapping must be validated

·        Backend must support sequence or correlation logic

Telemetry Dependency

·        EMS web access logs

·        Endpoint process creation telemetry

·        Parent-child process lineage

·        Normalized asset identifiers

Tuning Explanation

·        Anchor detection rule linking inbound activity to execution outcome

·        Requires accurate EMS parent process identification

·        Correlation window must be validated per environment

·        Backend-specific implementation required for sequence logic

Enforcement Method

·        Hard scoping to EMS assets

·        Correlation between access and execution on same asset

·        Backend-native sequencing or correlation must be used

Implementation Constraint Notes

·        Sigma does not guarantee support for temporal sequence operators across all backends

·        This rule must be implemented using backend-native sequence/correlation capabilities

·        Field names are illustrative and must be mapped to normalized backend fields

Variant Analysis

·        Detects execution-based exploitation outcomes

·        Resilient against request variation

·        May miss in-memory or delayed execution

Rule Regret Check
Deployment caution
Requires backend correlation capability and validated field mappings

Confidence caution
High when telemetry is complete and correlated correctly

Coverage value
Extremely high-value detection of exploitation leading to execution

Production Ready
Conditional upon backend sequence support, field normalization, and EMS process validation

Detection Logic / Deployment Template Code

title: FortiClient EMS Suspicious Web Access Followed by Execution
id: e3a3d68f-0c32-4f6f-8d71-ems-access-execution-002
status: experimental
description: Conceptual sequence detection requiring backend-native correlation between EMS web access and EMS-originated execution.
references:
  - Internal CyberDax S25 FortiClient EMS detection model
author: CyberDax
date: 2026-04-07
tags:
  - attack.t1190
  - attack.t1059
logsource:
  category: process_creation
detection:
  selection_execution:
process.parent.name|in: $EMS_PARENT_PROCESS_NAMES$
process.name|in:
      - cmd.exe
      - powershell.exe
      - mshta.exe
      - rundll32.exe
      - wscript.exe
      - cscript.exe
      - wmic.exe
      - certutil.exe
      - regsvr32.exe
  condition: selection_execution
falsepositives:
  - EMS maintenance or upgrade workflows
level: high
fields:
  - destination.hostname
  - process.name
  - process.parent.name
  - process.command_line

Rule 3 — FortiClient EMS Suspicious Execution with Retrieval or Staging Indicators

Purpose
Detect corroborating post-exploitation behavior through retrieval or staging command-line indicators.

MITRE ATT&CK Mapping
T1105 – Ingress Tool Transfer
T1059 – Command and Scripting Interpreter

SOC Usage Mode
Correlation-first, corroborating-only

Minimum Deployment Requirement

·        Endpoint process telemetry with command-line visibility

·        EMS parent process validation

·        Baseline of legitimate administrative behavior

Telemetry Dependency

·        Process creation telemetry

·        Command-line visibility

·        Parent-child relationships

Tuning Explanation

·        Corroborating detection only

·        Focuses on strong retrieval behaviors

·        Requires parser validation

Enforcement Method

·        Scoped to EMS-originated execution

·        Requires suppression of legitimate workflows

Implementation Constraint Notes

·        Command-line parsing varies across platforms

·        Matching must be case-insensitive and parser-aware

·        Field mappings must be normalized per backend

Variant Analysis

·        Covers retrieval and staging behaviors

·        May miss obfuscated or in-memory activity

Rule Regret Check
Deployment caution
Not suitable as standalone alert

Confidence caution
Moderate alone, high when correlated

Coverage value
Strong corroborating signal

Production Ready
Conditional upon parser validation and suppression tuning

Detection Logic / Deployment Template Code

title: FortiClient EMS Suspicious Execution with Retrieval Indicators
id: 1e4d2f9a-5e7a-4ac0-8f8c-ems-retrieval-003
status: experimental
description: Detects EMS-originated execution with retrieval or staging command-line indicators.
references:
  - Internal CyberDax S25 FortiClient EMS detection model
author: CyberDax
date: 2026-04-07
tags:
  - attack.t1105
  - attack.t1059
logsource:
  category: process_creation
detection:
  selection_parent:
process.parent.name|in: $EMS_PARENT_PROCESS_NAMES$
  selection_child:
process.name|in:
      - powershell.exe
      - cmd.exe
      - mshta.exe
      - certutil.exe
      - rundll32.exe
      - regsvr32.exe
  selection_cmd:
    process.command_line|contains:
      - invoke-webrequest
      - downloadstring
      - frombase64string
      - certutil -urlcache
      - mshta http
  condition: selection_parent and selection_child and selection_cmd
falsepositives:
  - Legitimate administrative scripts performing downloads
level: medium
fields:
  - destination.hostname
  - process.name
  - process.parent.name
  - process.command_line

YARA

System Assessment

Assessment
YARA does not provide strong, credible standalone detection opportunities for the primary FortiClient EMS unauthenticated remote code execution behavior set.

Reasoning

·        The core detection opportunities for this CVE are:

o   Suspicious EMS web access

o   Missing authentication or session context

o   EMS-originated process execution

o   Cross-telemetry correlation between access and execution

·        YARA is not designed to reliably detect these behaviors

·        Potential YARA use cases in this scenario depend on:

o   Dropped artifact availability

o   Memory capture quality

o   Script or payload reuse

o   Environment-specific administrative tooling overlap

·        These dependencies introduce variability and reduce detection reliability for standardized S25 rule development

Operational Limitation Statement

·        YARA may support:

o   Incident response

o   Forensic triage

o   Artifact inspection on EMS hosts

·        However, it does not provide sufficiently strong or reliable standalone detection logic for this specific behavior set to justify formal S25 production rules

·        Preserving detection quality and CyberDax credibility takes priority over artificial rule completeness

Coverage Disposition
Not Applicable for strong standalone S25 rule development in this use case

Production Ready
Section complete with honest limitation statement; no formal YARA rules recommended

Engineering Note

·        CyberDax will not force YARA detections for this FortiClient EMS CVE solely to fill system coverage

·        YARA should only be introduced if:

o   A consistent payload family is identified

o   Reusable artifact patterns are confirmed

o   Memory-resident indicators are validated across multiple observations

·        If such conditions emerge, YARA can be developed as a targeted artifact-detection layer tied to confirmed exploitation outcomes

·        Until then, YARA remains outside the formal S25 detection stack for this case

AWS

Rule 1 — Suspicious Access to Validated FortiClient EMS Privileged Web Paths Through AWS WAF

Purpose
Detect suspicious inbound requests targeting validated FortiClient EMS privileged web paths through AWS-managed ingress infrastructure, such as an Application Load Balancer or CloudFront distribution protected by AWS WAF.

MITRE ATT&CK Mapping
T1190 – Exploit Public-Facing Application

SOC Usage Mode
Alert-capable supporting detection

Minimum Deployment Requirement

·        FortiClient EMS must be exposed through AWS infrastructure protected by AWS WAF

·        EMS privileged URI patterns must be validated before deployment

·        AWS WAF logging and CloudWatch metrics must be enabled

·        If legitimate external EMS administration exists, trusted administrative source IP ranges should be identified and excluded

Telemetry Dependency

·        AWS WAF request inspection

·        URI path visibility

·        Source IP visibility

·        WAF labels, metrics, and logging

Tuning Explanation

·        This rule detects suspicious targeting of privileged EMS paths

·        It is strongest when URI matching is based on tenant-validated EMS administrative or API paths

·        If legitimate external management exists, trusted administrative source ranges should be excluded

·        This is a targeting detection, not exploit confirmation

Enforcement Method

·        Scope to validated EMS privileged URI patterns only

·        Optionally exclude trusted administrative source IP ranges where legitimate external administration exists

·        Use Count action first during validation, then promote based on tuning

Implementation Constraint Notes

·        This rule does not confirm exploitation success

·        This rule does not prove authentication bypass

·        Precision depends on URI validation and, where applicable, trusted-source suppression

·        Destination scoping is handled by attaching the Web ACL to the EMS ingress resource, not by rule content

Variant Analysis

·        Covers direct targeting of privileged EMS paths

·        Does not rely on a brittle exploit string

·        May miss attacks using unmodeled EMS paths or benign-looking low-volume traffic

Rule Regret Check
Deployment caution
Do not deploy with broad or unvalidated URI patterns

Confidence caution
Moderate as written; higher after URI localization and optional trusted-source exclusion where relevant

Coverage value
Strong AWS-native ingress visibility for suspicious EMS targeting

Production Ready
Conditional until EMS URI validation and, where applicable, trusted administrative IP validation are completed

Detection Logic / Deployment Template Code
Version A — Use when legitimate external EMS administration exists and trusted source IPs should be excluded

{
  "Name": "CYBERDAX-EMS-Privileged-Path-Targeting",
  "Priority": 10,
  "Statement": {
    "AndStatement": {
      "Statements": [
        {
          "RegexPatternSetReferenceStatement": {
            "ARN": "$EMS_PRIVILEGED_PATH_REGEX_SET_ARN",
            "FieldToMatch": {
              "UriPath": {}
            },
            "TextTransformations": [
              {
                "Priority": 0,
                "Type": "URL_DECODE"
              },
              {
                "Priority": 1,
                "Type": "LOWERCASE"
              }
            ]
          }
        },
        {
          "NotStatement": {
            "Statement": {
              "IPSetReferenceStatement": {
                "ARN": "$TRUSTED_ADMIN_IP_SET_ARN"
              }
            }
          }
        }
      ]
    }
  },
  "Action": {
    "Count": {}
  },
  "VisibilityConfig": {
    "SampledRequestsEnabled": true,
    "CloudWatchMetricsEnabled": true,
    "MetricName": "CYBERDAXEMSPrivilegedPathTargeting"
  },
  "RuleLabels": [
    {
      "Name": "cyberdax:forticlient-ems:privileged-path-targeting"
    }
  ]
}

Version B — Use when no legitimate external EMS administration exists and no trusted source exclusion is needed

{
  "Name": "CYBERDAX-EMS-Privileged-Path-Targeting",
  "Priority": 10,
  "Statement": {
    "RegexPatternSetReferenceStatement": {
      "ARN": "$EMS_PRIVILEGED_PATH_REGEX_SET_ARN",
      "FieldToMatch": {
        "UriPath": {}
      },
      "TextTransformations": [
        {
          "Priority": 0,
          "Type": "URL_DECODE"
        },
        {
          "Priority": 1,
          "Type": "LOWERCASE"
        }
      ]
    }
  },
  "Action": {
    "Count": {}
  },
  "VisibilityConfig": {
    "SampledRequestsEnabled": true,
    "CloudWatchMetricsEnabled": true,
    "MetricName": "CYBERDAXEMSPrivilegedPathTargeting"
  },
  "RuleLabels": [
    {
      "Name": "cyberdax:forticlient-ems:privileged-path-targeting"
    }
  ]
}

Rule 2 — Repeated Single-Source Targeting of FortiClient EMS Privileged Web Paths Through AWS WAF

Purpose
Detect repeated single-source targeting of validated FortiClient EMS privileged web paths through AWS WAF by rate-limiting suspicious requests from the same source IP.

MITRE ATT&CK Mapping
T1190 – Exploit Public-Facing Application

SOC Usage Mode
Alert-capable supporting detection

Minimum Deployment Requirement

·        FortiClient EMS must be exposed through AWS infrastructure protected by AWS WAF

·        EMS privileged URI patterns must be validated before deployment

·        AWS WAF must be enabled on the EMS ingress path

·        Thresholds must be tuned to tenant exposure and expected traffic volume

·        If legitimate external EMS administration exists, trusted administrative source IP ranges should be identified and excluded

Telemetry Dependency

·        AWS WAF request inspection

·        Source IP visibility

·        URI path visibility

·        WAF rate-based rule support

Tuning Explanation

·        This rule is intentionally narrowed to single-source burst targeting

·        It does not claim to detect distributed low-and-slow campaigns by itself

·        Thresholds must be tuned to the actual EMS exposure model

·        This is strongest for opportunistic probing and repeated exploit attempts from one source

Enforcement Method

·        Scope the rate-based rule to validated EMS privileged paths only

·        Optionally exclude trusted administrative sources where applicable

·        Start with Count during validation, then decide whether alerting or blocking is appropriate

Implementation Constraint Notes

·        This rule does not detect distributed campaign activity across many source IPs

·        NAT, proxies, or shared egress infrastructure may affect source-IP-based thresholds

·        This rule detects repeated targeting behavior, not confirmed exploitation

Variant Analysis

·        Covers burst-style targeting from one source

·        More defensible than overclaiming distributed campaign detection in a single native AWS rule

·        May miss low-volume or widely distributed probing

Rule Regret Check
Deployment caution
Threshold tuning is mandatory before production deployment

Confidence caution
Moderate as written; improves when EMS exposure is low-noise and well understood

Coverage value
Strong AWS-native detection for repeated single-source targeting of EMS privileged paths

Production Ready
Conditional until EMS URI validation, threshold tuning, and, where applicable, trusted-source exclusion are completed

Detection Logic / Deployment Template Code
Version A — Use when legitimate external EMS administration exists and trusted source IPs should be excluded

{
  "Name": "CYBERDAX-EMS-Rate-Based-Privileged-Path-Targeting",
  "Priority": 20,
  "Statement": {
    "RateBasedStatement": {
      "Limit": 100,
      "AggregateKeyType": "IP",
      "ScopeDownStatement": {
        "AndStatement": {
          "Statements": [
            {
              "RegexPatternSetReferenceStatement": {
                "ARN": "$EMS_PRIVILEGED_PATH_REGEX_SET_ARN",
                "FieldToMatch": {
                  "UriPath": {}
                },
                "TextTransformations": [
                  {
                    "Priority": 0,
                    "Type": "URL_DECODE"
                  },
                  {
                    "Priority": 1,
                    "Type": "LOWERCASE"
                  }
                ]
              }
            },
            {
              "NotStatement": {
                "Statement": {
                  "IPSetReferenceStatement": {
                    "ARN": "$TRUSTED_ADMIN_IP_SET_ARN"
                  }
                }
              }
            }
          ]
        }
      }
    }
  },
  "Action": {
    "Count": {}
  },
  "VisibilityConfig": {
    "SampledRequestsEnabled": true,
    "CloudWatchMetricsEnabled": true,
    "MetricName": "CYBERDAXEMSRateBasedPrivilegedPathTargeting"
  },
  "RuleLabels": [
    {
      "Name": "cyberdax:forticlient-ems:rate-based-targeting"
    }
  ]
}

Version B — Use when no legitimate external EMS administration exists and no trusted source exclusion is needed

{
  "Name": "CYBERDAX-EMS-Rate-Based-Privileged-Path-Targeting",
  "Priority": 20,
  "Statement": {
    "RateBasedStatement": {
      "Limit": 100,
      "AggregateKeyType": "IP",
      "ScopeDownStatement": {
        "RegexPatternSetReferenceStatement": {
          "ARN": "$EMS_PRIVILEGED_PATH_REGEX_SET_ARN",
          "FieldToMatch": {
            "UriPath": {}
          },
          "TextTransformations": [
            {
              "Priority": 0,
              "Type": "URL_DECODE"
            },
            {
              "Priority": 1,
              "Type": "LOWERCASE"
            }
          ]
        }
      }
    }
  },
  "Action": {
    "Count": {}
  },
  "VisibilityConfig": {
    "SampledRequestsEnabled": true,
    "CloudWatchMetricsEnabled": true,
    "MetricName": "CYBERDAXEMSRateBasedPrivilegedPathTargeting"
  },
  "RuleLabels": [
    {
      "Name": "cyberdax:forticlient-ems:rate-based-targeting"
    }
  ]
}

Engineering Note

·        These AWS rules are deployment-ready templates pending tenant-specific validation

·        Attach the AWS WAF Web ACL to the actual EMS ingress resource

·        Validate EMS privileged URI patterns before deployment

·        If legitimate external EMS administration exists, validate and maintain trusted administrative IP exclusions

·        If no legitimate external EMS administration exists, use the template versions without the trusted-source exclusion logic

·        Tune the rate threshold in Rule 2 to the actual EMS exposure model and normal traffic volume

·        Use CloudWatch metrics and WAF logs for alerting and triage

·        CyberDax will not force weak AWS detections for FortiClient EMS solely to fill system coverage

·        AWS remains an ingress-targeting layer for this case, not a host-execution or auth-gap confirmation layer

Azure

Rule 1 — Suspicious Access to FortiClient EMS Privileged Web Paths via Azure WAF

Purpose
Detect suspicious inbound requests targeting validated FortiClient EMS privileged web paths through Azure-managed ingress infrastructure, including Azure Application Gateway WAF or Azure Front Door.

MITRE ATT&CK Mapping
T1190 – Exploit Public-Facing Application

SOC Usage Mode
Alert-capable supporting detection

Minimum Deployment Requirement

·        EMS exposed via Azure WAF-enabled service

·        WAF logs enabled to Log Analytics / Sentinel

·        EMS URI patterns validated

Telemetry Dependency

·        AzureDiagnostics (WAF logs)

·        URI path visibility

·        Source IP visibility

Tuning Explanation

·        Detects targeting attempts to EMS privileged endpoints

·        Designed as low-threshold signal, not exploit confirmation

·        Must be tuned with URI validation and optional IP suppression

Enforcement Method

·        Scope strictly to EMS URI patterns

·        Optional trusted IP exclusion

·        Use alerting before enforcement

Implementation Constraint Notes

·        Does not confirm exploitation

·        Depends on correct field normalization

·        URI validation is critical

Variant Analysis

·        Covers direct endpoint targeting

·        May miss low-frequency or stealth probing

Rule Regret Check
Deployment caution
Do not deploy without validated URI patterns

Confidence caution
Moderate

Coverage value
Strong ingress targeting signal

Production Ready
Conditional on URI validation

Detection Logic / Deployment Template Code (KQL)

AzureDiagnostics
| where Category in ("ApplicationGatewayFirewallLog", "FrontDoorWebApplicationFirewallLog")
| extend client_ip = coalesce(clientIp_s, clientIP_s)
| extend uri = tostring(requestUri_s)
| where isnotempty(client_ip) and isnotempty(uri)
| where uri matches regex $EMS_PRIVILEGED_URI_REGEX
// Optional trusted admin exclusion
// | where client_ip !in ($TRUSTED_ADMIN_IPS)
| summarize RequestCount = count() by client_ip, uri, bin(TimeGenerated, 5m)
| where RequestCount >= 3

Rule 2 — Repeated Single-Source Targeting of EMS Privileged Paths via Azure WAF

Purpose
Detect burst-style repeated targeting from a single source IP against EMS privileged endpoints.

MITRE ATT&CK Mapping
T1190 – Exploit Public-Facing Application

SOC Usage Mode
Alert-capable supporting detection

Minimum Deployment Requirement

·        Azure WAF logging enabled

·        EMS exposed through Azure ingress

·        Thresholds tuned

Telemetry Dependency

·        AzureDiagnostics

·        Source IP

·        URI

Tuning Explanation

·        Detects high-frequency targeting bursts

·        Clearly separated from Rule 1 (low vs high threshold)

·        Must be tuned per environment

Enforcement Method

·        Threshold-based detection

·        Optional IP exclusion

·        Can be escalated to blocking

Implementation Constraint Notes

·        Does not detect distributed attacks

·        NAT may impact accuracy

·        Requires threshold tuning

Variant Analysis

·        Covers repeated exploit attempts

·        May miss distributed probing

Rule Regret Check
Deployment caution
Tune thresholds before production

Confidence caution
Moderate to high depending on tuning

Coverage value
Strong burst-targeting detection

Production Ready
Conditional on threshold tuning

Detection Logic / Deployment Template Code (KQL)

AzureDiagnostics
| where Category in ("ApplicationGatewayFirewallLog", "FrontDoorWebApplicationFirewallLog")
| extend client_ip = coalesce(clientIp_s, clientIP_s)
| extend uri = tostring(requestUri_s)
| where isnotempty(client_ip) and isnotempty(uri)
| where uri matches regex $EMS_PRIVILEGED_URI_REGEX
// Optional trusted admin exclusion
// | where client_ip !in ($TRUSTED_ADMIN_IPS)
| summarize RequestCount = count() by client_ip, bin(TimeGenerated, 5m)
| where RequestCount >= 50

Engineering Note

·        Validate URI patterns before deployment

·        Validate field mappings (clientIp_s vs clientIP_s)

·        Tune thresholds per exposure model

·        Apply optional trusted IP exclusions only when needed

·        CyberDax will not force weak Azure detections

GCP

Rule 1 — Suspicious Access to Validated FortiClient EMS Privileged Web Paths via GCP Ingress Logging

Purpose
Detect suspicious inbound requests targeting validated FortiClient EMS privileged web paths through GCP-managed ingress infrastructure, including Cloud Armor and external HTTP(S) load balancing.

MITRE ATT&CK Mapping
T1190 – Exploit Public-Facing Application

SOC Usage Mode
Alert-capable supporting detection

Minimum Deployment Requirement

·        FortiClient EMS must be exposed through GCP-managed ingress infrastructure

·        Cloud Armor and/or HTTP(S) load balancer request logging must be enabled

·        EMS privileged URI patterns must be validated before deployment

·        If legitimate external EMS administration exists, trusted administrative source IP ranges should be identified for optional suppression

·        Alerting must be implemented through Cloud Logging plus Cloud Monitoring, Chronicle, or an equivalent downstream analytics workflow

Telemetry Dependency

·        GCP Cloud Logging

·        HTTP request URL visibility

·        Source IP visibility

·        Load balancer and/or Cloud Armor request logs

Tuning Explanation

·        This rule detects suspicious targeting of EMS privileged paths

·        It is strongest when URI matching is based on tenant-validated EMS administrative or API paths

·        If legitimate external management exists, trusted administrative source ranges should be excluded where applicable

·        This is a targeting detection, not exploit confirmation

·        GCP destination scoping is primarily enforced by attaching the detection to the EMS-serving ingress resource rather than by query logic alone

Enforcement Method

·        Scope to validated EMS privileged URI patterns only

·        Optionally suppress trusted administrative source IP ranges where legitimate external administration exists

·        Start as an alerting analytic before any automated response

·        Tie the alert to the EMS-serving load balancer / ingress context

Implementation Constraint Notes

·        This rule does not confirm exploitation success

·        This rule does not prove authentication bypass

·        Precision depends on URI validation and, where applicable, trusted-source suppression

·        If multiple applications share the same ingress logging context, URI validation becomes even more important

·        This rule should be implemented as a Cloud Logging filter plus logs-based metric plus alerting policy or equivalent Chronicle detection, not treated as host-level detection

Variant Analysis

·        Covers direct targeting of privileged EMS paths

·        Does not rely on a brittle exploit payload signature

·        May miss attacks using unmodeled EMS paths or very low-volume benign-looking traffic

Rule Regret Check
Deployment caution
Do not deploy with broad or unvalidated URI patterns

Confidence caution
Moderate as written; higher after URI localization and optional trusted-source suppression where relevant

Coverage value
Strong GCP-native ingress visibility for suspicious EMS targeting

Production Ready
Conditional until EMS URI validation and, where applicable, trusted administrative source handling are completed

Detection Logic / Deployment Template Code
Version A — Use when legitimate external EMS administration exists and trusted source suppression is needed

Cloud Logging Filter

resource.type="http_load_balancer"
httpRequest.requestUrl =~ "$EMS_PRIVILEGED_URI_REGEX"
httpRequest.remoteIp !~ "$TRUSTED_ADMIN_IP_REGEX"

Version B — Use when no legitimate external EMS administration exists and no trusted source suppression is needed

Cloud Logging Filter

resource.type="http_load_balancer"
httpRequest.requestUrl =~ "$EMS_PRIVILEGED_URI_REGEX"

Suggested Alerting Implementation

·        Create a logs-based metric from the filter above

·        Trigger an alert when the metric count is greater than or equal to 3 within 5 minutes

·        Attach the alert to the EMS-serving ingress context only

Rule 2 — Repeated Single-Source Targeting of FortiClient EMS Privileged Web Paths via GCP Ingress Logs

Purpose
Detect repeated single-source targeting of validated FortiClient EMS privileged web paths through GCP ingress logs by identifying burst-style suspicious requests from the same source IP.

MITRE ATT&CK Mapping
T1190 – Exploit Public-Facing Application

SOC Usage Mode
Alert-capable supporting detection

Minimum Deployment Requirement

·        FortiClient EMS must be exposed through GCP-managed ingress infrastructure

·        Cloud Armor and/or HTTP(S) load balancer request logging must be enabled

·        EMS privileged URI patterns must be validated before deployment

·        Thresholds must be tuned to tenant exposure and expected traffic volume

·        If legitimate external EMS administration exists, trusted administrative source IP ranges should be identified for optional suppression

·        Aggregation must be implemented through BigQuery, Chronicle, or another GCP-compatible analytics layer capable of grouped thresholding

Telemetry Dependency

·        GCP Cloud Logging

·        Source IP visibility

·        URI path visibility

·        Aggregation capability through BigQuery, Chronicle, or equivalent analytics workflow

Tuning Explanation

·        This rule is intentionally narrowed to single-source burst targeting

·        It does not claim to detect distributed low-and-slow campaigns by itself

·        Thresholds must be tuned to the actual EMS exposure model

·        This is strongest for opportunistic probing and repeated exploit attempts from one source

·        It should remain separate from Rule 1 by using a materially higher threshold and burst-focused posture

Enforcement Method

·        Scope the analytic to validated EMS privileged paths only

·        Optionally suppress trusted administrative sources where applicable

·        Use alerting first during validation, then consider automated response only after tuning

·        Implement as an aggregation query or grouped detection, not as a simple raw log filter

Implementation Constraint Notes

·        This rule does not detect distributed campaign activity across many source IPs

·        NAT, proxies, or shared egress infrastructure may affect source-IP-based thresholds

·        This rule detects repeated targeting behavior, not confirmed exploitation

·        A plain Cloud Logging filter is not sufficient by itself for this rule; grouped aggregation is required

Variant Analysis

·        Covers burst-style targeting from one source

·        More defensible than overclaiming distributed campaign detection in a single native GCP analytic

·        May miss low-volume or widely distributed probing

Rule Regret Check
Deployment caution
Threshold tuning is mandatory before production deployment

Confidence caution
Moderate as written; improves when EMS exposure is low-noise and well understood

Coverage value
Strong GCP-native detection for repeated single-source targeting of EMS privileged paths

Production Ready
Conditional until EMS URI validation, threshold tuning, and, where applicable, trusted-source suppression are completed

Detection Logic / Deployment Template Code
Version A — BigQuery scheduled query with optional trusted-source suppression

SELECT
  httpRequest.remoteIp AS client_ip,
  TIMESTAMP_TRUNC(timestamp, MINUTE) AS minute_bucket,
  COUNT(*) AS request_count
FROM `$PROJECT_ID.$DATASET.$TABLE`
WHERE resource.type = "http_load_balancer"
  AND REGEXP_CONTAINS(httpRequest.requestUrl, r'$EMS_PRIVILEGED_URI_REGEX')
  AND NOT REGEXP_CONTAINS(httpRequest.remoteIp, r'$TRUSTED_ADMIN_IP_REGEX')
GROUP BY client_ip, minute_bucket
HAVING request_count >= 50

Version B — BigQuery scheduled query without trusted-source suppression

SELECT
  httpRequest.remoteIp AS client_ip,
  TIMESTAMP_TRUNC(timestamp, MINUTE) AS minute_bucket,
  COUNT(*) AS request_count
FROM `$PROJECT_ID.$DATASET.$TABLE`
WHERE resource.type = "http_load_balancer"
  AND REGEXP_CONTAINS(httpRequest.requestUrl, r'$EMS_PRIVILEGED_URI_REGEX')
GROUP BY client_ip, minute_bucket
HAVING request_count >= 50

Chronicle-Compatible Aggregation Concept

metadata.event_type = "NETWORK_HTTP"
and network.http.parsed_url.path re.regex($EMS_PRIVILEGED_URI_REGEX)
and principal.ip != null
match:
  principal.ip over 5m
outcome:
  $event_count = count(metadata.id)
condition:
  $event_count >= 50

Engineering Note

·        These GCP rules are deployment-ready templates pending tenant-specific validation

·        Validate EMS privileged URI patterns before deployment

·        Ensure Cloud Armor and/or load balancer logging is enabled and retained

·        If legitimate external EMS administration exists, validate and maintain trusted administrative source handling in the downstream analytics pipeline

·        Tune the rate threshold in Rule 2 to the actual EMS exposure model and normal traffic volume

·        Implement Rule 1 as a Cloud Logging filter plus logs-based metric plus alerting policy

·        Implement Rule 2 as an aggregation-driven analytic through BigQuery, Chronicle, or equivalent grouped detection workflow

·        CyberDax will not force weak GCP detections for FortiClient EMS solely to fill system coverage

·        GCP remains an ingress-targeting layer for this case, not a host-execution or auth-gap confirmation layer

S26 Threat-to-Rule Traceability Matrix

Behavior 1

Suspicious External Targeting of EMS Privileged Web Paths

MITRE ATT&CK

T1190 – Exploit Public-Facing Application

Mapped Detection Rules

·        Suricata Rule 1

·        AWS Rule 1

·        Azure Rule 1

·        GCP Rule 1

·        Splunk Rule 1

·        Elastic Rule 1

·        QRadar Rule 1

·        Sigma Rule 1

Coverage Disposition

Detected

Telemetry Dependency

·        HTTP request logs (URI, source IP)

·        WAF / ingress logs

·        Web server / reverse proxy logs

·        Optional authentication/session telemetry (for SIEM correlation rules)

Detection Notes

·        Strongest early-stage detection across all network and SIEM systems

·        Accuracy depends on EMS privileged path validation

·        Does not confirm exploitation, only targeting behavior

Behavior 2

Repeated Single-Source EMS Targeting (Burst Exploitation Attempts)

MITRE ATT&CK

T1190 – Exploit Public-Facing Application

Mapped Detection Rules

·        Suricata Rule 2

·        AWS Rule 2

·        Azure Rule 2

·        GCP Rule 2

·        Splunk Rule 1 (partial via aggregation logic)

·        Elastic Rule 1 (partial)

·        QRadar Rule 1 (partial)

Coverage Disposition

Partially Detected

Telemetry Dependency

·        Source IP visibility

·        Request frequency / aggregation capability

·        WAF rate-based detection or SIEM aggregation

Detection Notes

·        Strong in WAF and network layers

·        SIEM coverage depends on aggregation implementation

·        Does not detect distributed or low-and-slow campaigns

Behavior 3

Unauthenticated Access to EMS Without Corresponding Authentication Events

MITRE ATT&CK

T1190 – Exploit Public-Facing Application

Mapped Detection Rules

·        Splunk Rule 1

·        Elastic Rule 1

·        QRadar Rule 1

·        Sigma Rule 1 (conceptual)

Coverage Disposition

Partially Detected

Telemetry Dependency

·        Authentication logs

·        Session establishment logs

·        Correlation capability across data sources

·        Timestamp normalization

Detection Notes

·        High-value detection concept

·        Fully dependent on auth/session telemetry completeness

·        Not reliably detectable in:

o   Suricata

o   WAF systems

o   GCP/AWS/Azure alone

Behavior 4

EMS-Originated Command Execution (Interpreter-Based)

MITRE ATT&CK

T1059 – Command and Scripting Interpreter

Mapped Detection Rules

·        SentinelOne Rule 1

·        Splunk Rule 2

·        Elastic Rule 2

·        QRadar Rule 2

·        Sigma Rule 2

Coverage Disposition
Detected

Telemetry Dependency

·        Endpoint process creation telemetry

·        Parent-child process lineage

·        EMS parent process identification

Detection Notes

Highest-confidence detection layer

·        Strong across endpoint and SIEM systems

·        Requires:

o   validated EMS parent processes

o   reliable lineage

Behavior 5

EMS-Originated LOLBin / Script Host Execution Variants

MITRE ATT&CK

T1059 – Command and Scripting Interpreter
T1218 – System Binary Proxy Execution

Mapped Detection Rules

·        SentinelOne Rule 2

·        Splunk Rule 2 (partial)

·        Elastic Rule 2 (partial)

·        QRadar Rule 2 (partial)

·        Sigma Rule 2 (partial)

Coverage Disposition

Detected

Telemetry Dependency

·        Endpoint process telemetry

·        Command-line visibility

·        Parent-child lineage

Detection Notes

·        Expands coverage beyond interpreters

·        Handles evasion via LOLBins

·        Still dependent on command-line visibility

Behavior 6

EMS-Originated Payload Retrieval / Tool Transfer Activity

MITRE ATT&CK

T1105 – Ingress Tool Transfer

Mapped Detection Rules

·        Suricata Rule 3 (correlation anchor)

·        SentinelOne Rule 3

·        Splunk Rule 3

·        Elastic Rule 3

·        QRadar Rule 3

·        Sigma Rule 3

Coverage Disposition

Partially Detected

Telemetry Dependency

·        Command-line telemetry

·        Optional outbound network telemetry

·        Correlation with prior suspicious activity

Detection Notes

·        Explicitly corroborating-only

·        Not suitable as standalone detection

·        Strong when combined with:

o   execution signals

o   network targeting

Behavior 7

Correlated Exploitation Chain (Access → Execution Without Auth)

MITRE ATT&CK

T1190 – Exploit Public-Facing Application
T1059 – Command and Scripting Interpreter

Mapped Detection Rules

·        Splunk Rule 2

·        Elastic Rule 2

·        QRadar Rule 2

Coverage Disposition

Detected

Telemetry Dependency

·        Network access logs

·        Endpoint execution telemetry

·        Authentication/session logs

·        Cross-domain correlation capability

Detection Notes

·        Strongest full-chain detection

·        Requires:

o   multi-source telemetry

o   proper normalization

·        Not achievable in:

o   Suricata

o   WAF-only environments

o   GCP/AWS/Azure alone

Behavior 8

Distributed or Low-and-Slow Scanning / Exploitation

MITRE ATT&CK

T1190 – Exploit Public-Facing Application

Mapped Detection Rules

None

Coverage Disposition

Not Covered

Telemetry Dependency

·        Cross-IP aggregation

·        Behavioral baselining

·        Threat intel enrichment

Detection Notes

·        Not implemented intentionally

·        Avoided due to:

o   high noise

o   low reliability

·        Requires advanced analytics or external enrichment

Behavior 9

In-Memory Execution or Non-Interpreter Execution Paths

MITRE ATT&CK

T1059 – Command and Scripting Interpreter (variant gap)

Mapped Detection Rules

None (direct)

Coverage Disposition

Partially Detected

Telemetry Dependency

·        Advanced EDR memory telemetry

·        Behavioral anomaly detection

Detection Notes

·        Covered indirectly by:

o   execution correlation rules

·        Not directly detectable with current rule set

·        Requires advanced EDR capabilities beyond S25 scope

Behavior 10

Lateral Movement via EMS or Endpoint Control

MITRE ATT&CK

Not observed in currently available reporting; may occur during post-exploitation depending on attacker objectives and target environment

Mapped Detection Rules

None

Coverage Disposition

Not Covered

Telemetry Dependency

·        Endpoint-to-endpoint communication telemetry

·        Identity and credential telemetry

·        Lateral movement detection models

Detection Notes

·        Explicitly excluded from S25 scope

·        Requires separate detection model

S26 Coverage Summary (Executive View)

Detected Behaviors

·        EMS targeting (network layer)

·        EMS-originated execution (endpoint layer)

·        Correlated access to execution chain (SIEM layer)

·        Execution variants via LOLBins

Partially Detected Behaviors

·        Auth bypass condition (telemetry-dependent)

·        Payload retrieval / staging (corroborating)

·        Burst targeting (aggregation-dependent)

·        In-memory execution (indirect coverage only)

Not Covered Behaviors

·        Distributed low-and-slow scanning

·        Lateral movement via EMS

·        Advanced post-exploitation activity

S27 Behavior & Log Artifacts

Purpose
Translate the primary detection signals and mapped S25 rules into concrete SOC-observable artifacts across the three primary telemetry pillars: network, endpoint, and authentication/correlation. This section is grounded directly in the EMS exploitation flow, the S22 signal model, the S25 rules, and the S26 traceability matrix.

Network / Web / Ingress Artifacts

·        Inbound HTTP or HTTPS requests to EMS administrative or privileged API paths from untrusted external IP addresses

·        Requests to non-standard, rarely used, or tenant-sensitive EMS URI paths associated with privileged functionality

·        Repeated requests from a single external source targeting EMS privileged paths within a short time window

·        Burst-style request concentration against EMS administrative interfaces

·        Distributed probing patterns targeting the same EMS-facing paths across multiple source IPs

·        Requests with malformed, irregular, or automation-consistent structures where application or proxy logging exposes this detail

·        Requests processed without corresponding authentication, login, or session-establishment evidence where correlated telemetry exists

·        Outbound HTTP or TLS connections from the EMS host following prior suspicious inbound targeting, where network visibility exists and legitimate destinations are baselined

Representative Network / Web Fields

·        Source IP address

·        Destination IP address

·        Destination hostname

·        URI path

·        HTTP method

·        Authorization header presence or absence where visible

·        Session identifier presence or absence where visible

·        Response status code

·        User agent

·        Request count over time window

·        First-seen and last-seen timing for suspicious source-path combinations

Endpoint / Host Artifacts

·        Parent process identified as EMS service, EMS application, validated service wrapper, or EMS helper process

·        Child process execution from EMS context involving:

o   cmd.exe

o   powershell.exe

o   mshta.exe

o   rundll32.exe

o   wscript.exe

o   cscript.exe

o   wmic.exe

o   certutil.exe

o   regsvr32.exe

·        Command-line content indicating retrieval or staging behavior, such as:

o   Invoke-WebRequest

o   DownloadString

o   FromBase64String

o   -EncodedCommand

o   certutil -urlcache

o   mshta http

·        Process execution chains inconsistent with normal EMS operational behavior

·        Elevated or system-level execution originating from EMS service context

·        Rare or previously unseen child process launches from the EMS host

·        Suspicious command interpreter execution under EMS parent context without corresponding approved maintenance context

Representative Endpoint Fields

·        Hostname or asset identifier

·        Parent process name

·        Parent process image path

·        Child process name

·        Child process image path

·        Command line

·        User / security context

·        Integrity level / privilege level where available

·        Process start time

·        Parent-child lineage metadata

·        Optional signer information

·        Optional rarity or baseline enrichment data

Authentication / Session / Correlation Artifacts

·        Successful request handling or privileged-path access without corresponding authentication success event

·        Successful request handling without corresponding session establishment

·        Privileged EMS access without corresponding authorization context

·        Temporal correlation between suspicious inbound EMS access and EMS-originated child process execution

·        Temporal correlation between suspicious inbound EMS access and outbound retrieval-oriented behavior

·        Mismatch between observed EMS system activity and expected login/session telemetry

·        High-confidence multi-layer condition:

o   suspicious privileged EMS access

o   no corresponding authentication/session evidence

o   EMS-originated execution or retrieval behavior

Representative Correlation Fields

·        Shared EMS asset identifier across web, auth, and endpoint telemetry

·        Time delta between suspicious access and child process creation

·        Time delta between suspicious access and outbound activity

·        Auth/session count during access window

·        Source IP and URI relationship to endpoint activity on same EMS asset

·        Parent-child lineage relationship tied to same EMS host and same incident window

High-Confidence Artifact Combinations

·        Suspicious EMS privileged-path access followed by cmd.exe or powershell.exe execution from EMS context

·        Privileged EMS access without corresponding auth/session evidence followed by EMS child process creation

·        EMS-originated script-host or LOLBin execution with retrieval-oriented command-line indicators

·        Suspicious inbound EMS targeting followed by outbound web activity from the EMS host, where legitimate destinations are already suppressed

Operational Limitation Notes

·        Without TLS visibility or application-layer logging, missing-authentication network artifacts may be partially or not observable

·        Without parent-child lineage, endpoint artifacts lose major detection value

·        Without auth/session telemetry, access-without-authentication conditions cannot be directly validated

·        Without cross-domain correlation capability, multi-stage exploit detection degrades to partial signal visibility only

Figure 5

S28 Detection Strategy and SOC Implementation Guidance

Purpose
Provide SOC-operational guidance for implementing, triaging, correlating, and responding to detections associated with CVE-2026-35616 using the behavior-driven model established in S21–S27 and the rules mapped in S25–S26.

SOC Prioritization Model

·        Treat any EMS-originated command interpreter execution as high priority

·        Treat suspicious EMS privileged-path access without corresponding auth/session context as high priority when auth telemetry is validated as complete

·        Treat repeated privileged-path targeting as early-stage exploitation activity requiring triage

·        Treat retrieval or staging indicators from EMS context as corroborating evidence that materially increases incident confidence

·        Treat combined network, auth-gap, and endpoint execution signals as likely compromise requiring immediate investigation

Primary Triage Workflow

·        Confirm the affected asset is a FortiClient EMS host

·        Validate whether the targeted URI path is a tenant-approved EMS privileged path

·        Determine whether the source IP is trusted, expected, or previously approved for EMS administration

·        Review whether corresponding authentication or session-establishment telemetry exists in the expected window

·        Inspect for EMS-originated child process execution

·        Review child process command lines for retrieval, staging, or encoded execution behavior

·        Check for outbound network activity from the EMS host following suspicious access or execution

·        Assess whether the activity aligns with a validated maintenance, upgrade, packaging, or troubleshooting workflow

·        Escalate immediately if suspicious access and EMS-originated execution are both present

SOC Investigation Decision Points

·        If suspicious privileged-path targeting exists but no execution is observed:

o   Treat as attempted exploitation or suspicious targeting

o   Review request volume, recurrence, and source distribution

o   Validate whether blocking or temporary ingress restrictions are warranted

·        If EMS-originated execution is observed with a validated EMS parent process:

o   Treat as high-confidence compromise candidate

o   Immediately scope affected host activity

o   Review command lines, child process tree, and any retrieval indicators

·        If auth/session telemetry is absent but known to be incomplete:

o   Do not overstate access-without-authentication confidence

o   Rely more heavily on endpoint execution and cross-domain timing

·        If retrieval/staging indicators are present:

o   Treat as evidence of likely second-stage activity

o   Investigate downloaded content, outbound destinations, and downstream host actions

SOC Correlation Guidance

·        Prioritize cross-domain correlation over any single low-context signal

·        Use the EMS host as the primary correlation anchor

·        Correlate:

o   suspicious privileged-path access

o   auth/session absence or mismatch

o   EMS-originated process execution

o   retrieval or outbound behavior

·        Use short correlation windows first, then widen carefully if telemetry buffering is known

·        Keep corroborating detections lower severity unless combined with execution or auth-gap evidence

Recommended Alert Severity Guidance

·        Low

o   isolated low-volume suspicious EMS path targeting without repetition or follow-on signals

·        Medium

o   repeated single-source targeting

o   corroborating retrieval or staging indicators without execution confirmation

o   auth-gap indicators where telemetry quality is uncertain

·        High

o   suspicious EMS access followed by EMS-originated child process execution

o   EMS-originated command interpreter execution from validated EMS parent context

o   suspicious EMS access without corresponding auth/session evidence where telemetry completeness is validated

·        Critical

o   combined suspicious EMS access, absent auth/session evidence, and confirmed EMS-originated execution with follow-on retrieval or staging activity

Recommended Containment Guidance

·        Restrict or disable external access to EMS if suspicious targeting is confirmed

·        Isolate the EMS host if high-confidence execution is observed

·        Block suspicious source IPs at ingress where operationally safe

·        Review and rotate credentials or tokens accessible to EMS if compromise is suspected

·        Inspect managed endpoint relationships for abnormal follow-on administrative activity originating from EMS

·        Preserve logs, process lineage, and relevant artifacts before major remediation actions where feasible

Operational Implementation Guidance by Detection Layer

·        Network / WAF / IDS

o   Use privileged-path targeting and burst-targeting detections as early warning

o   Do not treat these alone as proof of compromise

o   Use them to trigger heightened monitoring and source containment review

·        Endpoint / EDR

o   Treat EMS-originated command execution as the highest-confidence host signal

o   Prioritize parent-process validation and command-line review

o   Suppress only validated maintenance workflows

·        SIEM / Correlation Platforms

o   Use auth-gap logic only where auth/session telemetry quality is known

o   Keep same-asset normalization and timestamp validation as hard prerequisites

o   Favor access-to-execution correlations as the primary high-confidence analytic

Operational Validation Note

·        Detection logic should be validated against known-good EMS administrative activity, maintenance activity, and upgrade workflows before full production severity is assigned

·        Correlation-based detections should be tested with realistic telemetry latency and field normalization conditions

·        Any system with incomplete telemetry should explicitly downgrade confidence rather than silently overstate coverage

S29 Detection Coverage Summary

Purpose
Summarize practical detection coverage for CVE-2026-35616 based on the finalized S25 rules and S26 traceability mapping. This section distinguishes direct detection, conditional detection, and meaningful residual gaps.

Detected Behaviors

·        Suspicious external targeting of validated EMS privileged web paths

·        Repeated single-source targeting or burst-style probing against EMS privileged paths

·        EMS-originated command interpreter execution from validated EMS parent context

·        EMS-originated LOLBin or script-host execution variants

·        Correlated suspicious EMS access followed by EMS-originated child process execution

·        High-confidence access-to-execution chains in SIEM platforms with sufficient telemetry normalization

Partially Detected Behaviors

·        Access without corresponding authentication or session evidence

·        Retrieval or staging behavior following EMS-originated execution

·        In-memory or non-interpreter execution paths where only indirect behavioral coverage exists

·        Outbound post-exploitation behavior where only network-side corroboration is available

·        Distributed or lower-volume probing outside single-source threshold logic in some platforms

Conditional Post-Exploitation Behaviors

·        Tool retrieval after successful exploitation

·        External callback or staging activity from the EMS host

·        Follow-on misuse of trusted EMS administrative context

·        Additional execution variants depending on attacker objectives and environment

·        These behaviors may occur during post-exploitation depending on attacker objectives and target environment and are best covered through endpoint, SIEM, and corroborating network logic rather than any single ingress detection

Not Covered

·        Distributed low-and-slow scanning as a strong formal detection outcome

·        Lateral movement to managed endpoints

·        Credential access and credential misuse beyond EMS-host execution context

·        Persistence establishment beyond the initial exploit and execution sequence

·        Ransomware deployment workflows beyond early retrieval or execution indicators

·        Strong YARA-based standalone production detections for this CVE behavior set

Coverage Summary by Detection Layer

·        Network layer

o   Strong for privileged-path targeting and repeated probing

o   Partial for auth-gap conditions without application-layer or TLS visibility

o   Corroborating only for follow-on outbound behavior

·        Endpoint layer

o   Strong for EMS-originated execution

o   Strong for interpreter and LOLBin variants

o   Partial for in-memory-only or low-visibility execution paths

·        Correlation layer

o   Strong where same-asset normalization, auth/session logs, and endpoint lineage are all present

o   Partial where one or more telemetry domains are degraded or missing

Coverage Confidence Summary

·        High confidence

o   EMS-originated execution from validated EMS parent context

o   suspicious access followed by execution on the same EMS asset

·        Medium confidence

o   suspicious privileged-path targeting without execution

o   retrieval or staging indicators

o   auth-gap detections where telemetry completeness is not fully assured

·        Lower confidence

o   low-volume or distributed targeting below thresholds

o   indirect signals without endpoint lineage or auth/session support

Coverage Outlook

·        Coverage is strongest in environments that have:

o   validated EMS path scoping

o   endpoint lineage telemetry

o   usable auth/session logging

o   cross-domain correlation capability

·        Coverage degrades materially when:

o   TLS visibility is absent

o   auth/session telemetry is incomplete

o   endpoint parent-child lineage is unavailable

o   host-field normalization across data sources is weak

S30 Intelligence Maturity Assessment

Purpose
Assess current detection maturity for CVE-2026-35616 across the CyberDax maturity dimensions of telemetry coverage, detection engineering, correlation readiness, and operational response readiness, based on the finalized S25–S29 content.

Threat Detection Maturity

Current Assessment
Moderate to High

Rationale
Detection logic is strong and behavior-driven. High-confidence host and correlation detections exist for the most important exploit outcomes. Coverage is weaker for distributed probing, memory-only execution, and later post-exploitation phases.

Telemetry Coverage Maturity

Current Assessment
Moderate

Rationale
Effective coverage requires three distinct telemetry pillars: network or ingress visibility, endpoint process lineage, and authentication or session telemetry. Many environments will lack at least one of these. Auth-gap detections are highly sensitive to telemetry completeness.

Detection Engineering Maturity

Current Assessment
High

Rationale
Rules are detection-first, standalone-valid, and implementation-aware. Weak system coverage was not forced where it would reduce credibility. Engineering Notes and conditional deployment controls are explicit. Cloud and WAF sections are scoped honestly to ingress visibility only.

Correlation Readiness Maturity

Current Assessment
Moderate

Rationale
Strong correlation opportunities exist. Real-world effectiveness depends on same-asset normalization, timestamp alignment, authentication or session log quality, and endpoint lineage quality. Organizations without mature SIEM normalization will not realize full value from S25 correlation rules.

Response Readiness Maturity

Current Assessment
Moderate

Rationale
The detection set supports rapid identification of likely exploitation. Response effectiveness depends on the ability to isolate EMS quickly, inspect managed endpoint relationships, and preserve host and ingress artifacts. Organizations with mature EDR and SIEM workflows will perform materially better.

Overall Intelligence Maturity Assessment

Current Assessment
Moderate to High for early exploitation detection

Rationale
The current model is strong for ingress targeting, EMS-originated execution, and access-to-execution correlation. It is less mature for deep post-exploitation visibility, distributed reconnaissance detection, and downstream enterprise-wide compromise activity after the initial foothold.

Maturity Improvement Priorities

·        Improve EMS-specific authentication and session logging fidelity

·        Improve endpoint lineage visibility and EMS parent-process identification quality

·        Validate same-asset normalization across web, authentication, and endpoint telemetry

·        Improve distributed-scan analytics where operationally justified

·        Expand downstream detection coverage for managed-endpoint follow-on activity if the threat model requires it

·        Preserve the current strong-rules-only standard and avoid artificial coverage expansion

S31 Mitigation and Remediation

·        Apply Fortinet-provided patches or mitigations immediately across all EMS deployments to meet KEV remediation timelines

·        Remove all unnecessary external exposure of EMS interfaces from the internet

·        Restrict EMS access to trusted networks using segmentation and access controls

·        Enforce IP allowlisting for administrative and API access to EMS services

·        Validate that all EMS instances are updated and no vulnerable versions remain accessible

·        Verify mitigation effectiveness by confirming that unauthenticated access paths are no longer reachable and monitoring for continued anomalous activity

S32 Security Control Recommendations

·        Implement application-layer filtering or reverse proxy controls to enforce authentication validation before EMS request processing

·        Enable endpoint telemetry on EMS hosts with full process lineage visibility

·        Deploy network monitoring capable of identifying anomalous inbound access patterns to EMS systems

·        Establish logging of EMS access, session behavior, and request handling where available

·        Apply strict access control policies limiting EMS interaction to authorized systems and administrators

S33 Strategic Defensive Improvements

·        Treat EMS systems as critical infrastructure requiring enhanced monitoring and protection

·        Implement behavior-based detection focused on execution originating from EMS service context

·        Establish baseline EMS communication patterns and alert on deviations

·        Integrate vulnerability management with detection engineering to prioritize KEV-driven response actions

·        Conduct recurring exposure validation to identify and remediate improperly accessible EMS systems

Control Impact Mapping

·        Network access restriction reduces exposure to T1190 – Exploit Public-Facing Application

·        Endpoint monitoring enables detection of T1059 – Command and Scripting Interpreter

·        Correlation across telemetry sources improves detection of multi-stage exploitation behavior

S34 Defensive Architecture Overview

Figure 6

Network Layer

·        Restrict inbound access to EMS systems through firewall rules and segmentation

·        Monitor inbound HTTP or HTTPS traffic for anomalous or unauthenticated request patterns

·        Implement TLS inspection where feasible to improve visibility into request content

Identity Layer

·        Enforce authentication controls for all EMS administrative access paths

·        Monitor for absence of expected authentication events associated with EMS activity

·        Validate that no EMS request paths bypass authentication enforcement

·        Detect mismatches between access activity and authentication telemetry

Application / Appliance Layer

·        Apply vendor patches and hardening configurations to EMS systems

·        Enable logging of application-layer activity including request handling and execution behavior

·        Deploy gateway or proxy controls to enforce validation of inbound requests

Correlation Layer

·        Correlate network, endpoint, and authentication telemetry to identify exploitation conditions

·        Detect mismatches between access activity and authentication events

·        Prioritize alerts combining unauthenticated access and execution signals

S35 Security Hardening Guidance

·        Minimize EMS attack surface by disabling unnecessary services and interfaces

·        Enforce least-privilege configurations for EMS service accounts

·        Apply strict network segmentation to isolate EMS from untrusted environments

·        Ensure logging is enabled and retained for EMS access and execution activity

·        Regularly validate EMS configuration and exposure status through security assessments

·        Conduct targeted threat hunting focused on EMS-originated execution and anomalous access patterns

S36 Security Program Maturity Assessment

Detection Maturity

Moderate; detection requires correlated telemetry across network, endpoint, and authentication layers and cannot rely on single-source monitoring

Telemetry Coverage

Dependent on availability of network, endpoint, and authentication telemetry; absence of any layer results in partial detection coverage

Response Readiness

Moderate; effective response depends on the ability to isolate EMS systems and assess impact across managed endpoints

Hardening Maturity

Moderate; organizations with enforced segmentation and access controls demonstrate reduced exposure

Control Effectiveness Score

Moderate

Audit Evidence Statement

Detection and response effectiveness depend on correlated telemetry and validated EMS monitoring; environments lacking these capabilities will experience reduced detection coverage

Security Program Integration Note

This vulnerability requires coordinated action across vulnerability management, detection engineering, and incident response functions to ensure effective mitigation and detection

Figure 7

S37 Residual Risk and Forward Outlook

Residual risk persists in environments where EMS systems are not fully remediated, properly segmented, or monitored with sufficient telemetry coverage.

Centralized management platforms will continue to be targeted due to their ability to provide high-impact access from a single compromise point. Similar vulnerabilities affecting management infrastructure are expected to remain a priority target class for attackers.

Organizations that enforce exposure control, validate authentication enforcement, and implement correlated detection will significantly reduce residual risk. Environments lacking these controls remain exposed to repeat exploitation and emerging variants targeting centralized management systems.

S38 Intelligence Confidence Assessment

Confidence Level

High

Confidence Rationale

·        Vulnerability characteristics are clearly defined, including unauthenticated access and execution capability

·        KEV inclusion confirms elevated exploitation priority and credible threat relevance

·        Technical behavior is consistent across vulnerability analysis, attack path modeling, and detection engineering

·        Detection model is grounded in observable telemetry and validated against known limitations

·        No reliance on speculative exploit techniques or unsupported attack paths

Confidence Limitations

·        Limited public reporting on active exploitation techniques, tooling, or adversary attribution

·        Lack of detailed vendor disclosure on vulnerable code paths and request validation logic

·        Post-exploitation behaviors are not observed in current reporting and remain conditional

·        Detection effectiveness depends on availability of network, endpoint, and authentication telemetry, with absence of authentication signals representing a key limitation

S39 Analytical Notes and Limitations

·        Analysis is based on vulnerability characteristics and KEV inclusion rather than confirmed campaign-level reporting

·        The vulnerability enables unauthenticated access, which reduces visibility in authentication telemetry and complicates detection

·        Post-exploitation behavior is modeled based on EMS capabilities and attacker objectives but is not directly observed

·        Detection strategies assume availability of correlated telemetry across network, endpoint, and authentication layers

·        Variability in EMS deployment architecture and exposure conditions affects both exploitability and detection coverage

·        Cost modeling reflects generalized enterprise impact and may vary depending on organization size, sector, and response capability

S40 References

Vendor Advisory

·        Fortinet Security Advisory – Security fixes addressing FortiClient EMS improper access control vulnerability (CVE-2026-35616)

·        hxxps://www[.]fortinet[.]com/support/security-advisory/FG-IR-XX-XXX

Vulnerability Records

·        CVE-2026-35616 – Improper Access Control in Fortinet FortiClient EMS

·        hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-35616

Known Exploited Vulnerabilities (KEV)

·        Known Exploited Vulnerabilities catalog entry for CVE-2026-35616

·        hxxps://www[.]cisa[.]gov/known-exploited-vulnerabilities-catalog

Analytical Framework

·        MITRE ATT&CK Framework – Enterprise Matrix

·        hxxps://attack[.]mitre[.]org