[TTD] FortiSandbox Appliance Command Execution and Security-Control Compromise Exposure

Report Type: Threat To Detection
Threat Category: Security Appliance Command Execution / Defensive Control Compromise Exposure
Assessment Date: June 11, 2026
Primary Impact Domain: Security Control Integrity
Secondary Impact Domains: Malware Analysis Workflow Integrity; Submitted Artifact Confidentiality; Security Tooling Trust; Internal Pivot Risk; Incident Response Assurance
Affected Asset Class: Fortinet FortiSandbox Appliance
Threat Objective Classification: Unauthenticated Appliance Command Execution and Security-Control Abuse

Published by: CyberDax LLC
Author: Edward “Tony” Dolley
Role: Founder / Principal Threat Researcher, CyberDax LLC
Publication Date: June 11
Publication Type: Cybersecurity Research Report / White Paper
URL: [CyberDax.io URL]

BLUF

‍ CVE-2026-39808 creates a high-priority security-appliance compromise risk because affected FortiSandbox systems may allow unauthenticated operating-system command execution through crafted HTTP requests. This issue is best handled as a compact CyberDax Threat-to-Detection package rather than a full EXP report because public proof-of-concept material increases near-term exploitation risk, but confirmed in-the-wild exploitation, KEV listing, named actor adoption, ransomware use, or mature post-exploitation tradecraft has not been established.

Executive Risk Translation

This matters because FortiSandbox is not an ordinary web application. It is a malware-analysis and sandboxing platform that may process suspicious files, detonation artifacts, security telemetry, integrations, and security-fabric trust relationships. A successful compromise could allow an attacker to turn a defensive appliance into a trusted execution point, tamper with malware-analysis workflows, access submitted artifacts, or pivot toward adjacent security infrastructure.

S5 Executive Risk Summary

Business Risk

Affected FortiSandbox deployments create elevated risk of security-control compromise, malware-analysis workflow disruption, sensitive artifact exposure, internal pivoting, and reduced confidence in sandbox verdicts.

Technical Cause

The vulnerability is an OS command injection flaw affecting FortiSandbox 4.4.0 through 4.4.8. Fortinet states that an unauthenticated attacker may execute unauthorized code or commands through crafted HTTP requests.

Threat Posture

Current posture is predictive high risk. Fortinet marks the issue as not known exploited, but public proof-of-concept availability and the unauthenticated command-execution primitive make opportunistic testing and future exploitation plausible.

Executive Decision Requirement

Leadership should require immediate version validation, upgrade to FortiSandbox 4.4.9 or later, exposure reduction for FortiSandbox API and management surfaces, and short-term monitoring for exploitation attempts, appliance egress anomalies, file writes, configuration changes, and local persistence.

S6 Executive Cost Summary

FortiSandbox appliance command execution through CVE-2026-39808 creates scenario-based financial exposure when the organization must determine whether a defensive malware-analysis platform was merely vulnerable, received suspicious unauthenticated HTTP requests, executed unauthorized commands, exposed submitted files or analysis artifacts, initiated attacker-directed egress, or became a pivot point into adjacent security infrastructure. The cost is not driven only by upgrading FortiSandbox from 4.4.0 through 4.4.8 to 4.4.9 or later. It is driven by the work required to prove whether crafted API requests reached the appliance, whether query-string telemetry is complete, whether command execution occurred, whether appliance-originated egress was legitimate detonation traffic or attacker-directed callback behavior, whether submitted samples or analysis results were accessed or altered, whether integration credentials require rotation, and whether connected security workflows can still be trusted.

Financial exposure increases when investigation requires emergency appliance patching, external exposure review, NDR, proxy, WAF, firewall, and DNS correlation, FortiSandbox administrative log review, sandbox verdict validation, detonation-traffic baselining, appliance isolation or rebuild, SIEM, SOAR, mail-security, and Fortinet Security Fabric integration review, credential and token rotation, internal pivot investigation, legal and compliance review, cyber-insurance coordination, and executive assurance that malware-analysis and security-control workflows remain trustworthy.

Low Impact Scenario

Rapid investigation confirms that affected FortiSandbox exposure was limited to one or a small number of appliances running 4.4.0 through 4.4.8, with no confirmed suspicious command-execution behavior. Activity may include vulnerability scanner hits, benign validation attempts, blocked HTTP requests, or isolated suspicious-looking requests where FortiSandbox, proxy, WAF, NDR, firewall, DNS, and administrative evidence confirms failed exploitation or no meaningful post-request activity. No unusual FortiSandbox egress is observed, no submitted files or analysis artifacts appear accessed or altered, no integration credentials require emergency rotation, no security-fabric or SIEM/SOAR workflow impact is confirmed, and no business-critical malware-analysis process is materially disrupted. Response is limited to emergency version validation, upgrade to 4.4.9 or later, exposure review, scanner-source separation, limited log review, short-term FortiSandbox egress monitoring, and executive confirmation that no appliance compromise indicators were found.

Estimated impact $75K - $350K.

Moderate Impact Scenario

Confirmed or strongly suspected exploitation activity affects one or more FortiSandbox appliances, but evidence does not confirm broad downstream compromise. The organization observes suspicious requests to FortiSandbox API paths, command-injection-style query parameters, incomplete query-string visibility, unusual but explainable appliance egress, unexpected file activity, configuration uncertainty, or gaps that prevent immediate confirmation that the activity was benign. Response requires expanded proxy, WAF, NDR, firewall, DNS, SIEM, and FortiSandbox administrative log review; FortiSandbox egress-baseline analysis; validation of submitted-file handling; review of sandbox verdicts generated during the exposure window; selective integration credential review; SOC hunt-mode deployment and tuning; vulnerability-management surge support; and management reporting. Appliance isolation or rebuild may be required if telemetry is incomplete or if command execution cannot be ruled out.

Estimated impact $400K - $2.5M.

High Impact Scenario

FortiSandbox command execution becomes an enterprise-impact event when command execution, appliance tampering, unusual egress, unauthorized file access, configuration modification, local persistence, or FortiSandbox-originated internal movement is confirmed or cannot be reasonably ruled out. The organization may need to assume that a defensive security appliance was under attacker control until evidence proves otherwise. Response may require appliance isolation, rebuild from trusted media, full FortiSandbox administrative and forensic review, submitted-file and analysis-artifact exposure assessment, validation of sandbox verdicts produced during the exposure window, broad integration credential and token rotation, SIEM, SOAR, mail-security, and Fortinet Security Fabric trust review, internal pivot investigation, legal and compliance review, cyber-insurance engagement, executive and board reporting, customer-impact analysis where sensitive artifacts were processed, and formal validation that security-control workflows can safely resume.

Estimated impact $3M - $15M+.

Severe Downstream Security-Control Impact Scenario

Severe exposure occurs if the compromised FortiSandbox appliance is used to access, influence, or pivot toward security tooling, identity systems, SIEM, SOAR, mail-security, file repositories, Fortinet Security Fabric, management networks, malware-analysis pipelines, or other trusted defensive infrastructure. In this scenario, the incident shifts from appliance remediation to broader security-control trust validation. The organization may need to review whether security alerts, sandbox verdicts, detonation artifacts, submitted files, automation workflows, integration tokens, or defensive-routing assumptions were exposed, altered, suppressed, or misused. Response may require enterprise-scale incident response, broad security-tooling credential rotation, review of historical malware-analysis decisions, reprocessing of submitted artifacts, privileged-access review, identity and network segmentation validation, regulatory and legal assessment, customer or partner notification analysis, cyber-insurance coordination, and executive assurance that the organization’s detection and response control plane remains trustworthy.

Estimated impact $15M - $50M+.

S6A Key Cost DRIvers

·        Number and criticality of affected FortiSandbox appliances, including internet-facing systems, partner-accessible systems, VPN-accessible systems, broad-internal systems, malware-analysis hubs, email-security detonation nodes, and Fortinet Security Fabric-connected systems.

·        Whether the appliance was merely vulnerable, received suspicious requests, showed command-injection query indicators, executed commands, wrote files, initiated unusual egress, changed configuration, restarted services, created local persistence, or connected to sensitive internal systems.

·        Ability to reconstruct the activity path across FortiSandbox web/API logs, proxy logs, WAF logs, NDR HTTP telemetry, firewall logs, DNS logs, flow logs, SIEM events, administrative logs, vulnerability-management records, asset inventory, and Fortinet management data.

·        Completeness of raw and decoded query-string retention for FortiSandbox-facing requests, including whether URL-encoded command separators, pipes, redirection, shell substitution, semicolons, backticks, or other command-injection indicators can be reviewed.

·        Ability to distinguish attacker-directed FortiSandbox egress from normal sandbox detonation traffic, Fortinet update traffic, vendor support activity, security-fabric communication, and documented SIEM, SOAR, mail-security, or repository integrations.

·        Whether submitted files, malware samples, detonation outputs, analysis artifacts, or sandbox verdicts may have been accessed, altered, suppressed, deleted, or made unreliable during the exposure window.

·        Whether FortiSandbox integration credentials, API tokens, service accounts, SIEM connectors, SOAR connectors, mail-security integrations, file repository access, Fortinet Security Fabric trust relationships, or management credentials require review or rotation.

·        Scope of appliance recovery, including emergency upgrade, containment, isolation, forensic acquisition, configuration export, rebuild from trusted media, restoration, post-rebuild validation, and re-enrollment into connected security workflows.

·        Extent of internal pivot investigation if FortiSandbox communicated with SIEM, SOAR, identity systems, mail-security systems, management networks, file repositories, security tooling, Fortinet management systems, or administrative jump hosts.

·        Strength of existing segmentation and egress controls around FortiSandbox, including whether the appliance could reach broad internal networks, privileged management systems, sensitive repositories, security tooling, or internet destinations without restriction.

·        SOC and engineering workload required to deploy NDR, Splunk, Elastic, QRadar, SIGMA, and conditional SentinelOne detection logic; map local fields; create FortiSandbox asset groups; validate query-string visibility; create egress allowlists; tune scanner exceptions; baseline false positives; and promote rules from hunt mode to alert mode.

·        Duration of uncertainty around FortiSandbox trust, including whether malware-analysis results, email-security verdicts, incident-response artifacts, detonation records, or security-automation decisions must be reviewed before business and security teams can rely on the platform again.

·        Legal, compliance, cyber-insurance, customer-impact, or partner-impact review if submitted artifacts contained sensitive files, regulated data, customer material, malware samples from active incidents, or internal investigation evidence.

·        Executive and board-level reporting burden where compromise affects a security-control platform rather than an ordinary application server, increasing concern around defensive-control integrity and incident-response confidence.

S6B Compliance and Risk Context

FortiSandbox command execution exposure may affect compliance and risk posture where the appliance supports regulated malware-analysis, email-security review, file detonation, incident response, security monitoring, or security-fabric automation. The compliance concern is not limited to vulnerable software exposure. It includes the possibility that a defensive control processed sensitive files, suspicious attachments, malware samples, investigation artifacts, or security-automation inputs while its integrity was uncertain.

If exploitation is suspected or telemetry is incomplete, organizations may need to validate whether submitted artifacts were exposed, whether sandbox verdicts were altered or made unreliable, whether connected security systems accepted untrusted appliance outputs, whether integration credentials were exposed, and whether response decisions made during the exposure window need review. This can create regulatory, contractual, cyber-insurance, customer-trust, and executive-reporting implications even if broader enterprise compromise is not confirmed.

Compliance Exposure Indicator

High

Risk Register Entry

Risk Title

FortiSandbox Appliance Command Execution and Security-Control Compromise Exposure

Risk Description

Adversaries may exploit FortiSandbox command-injection exposure to move from unauthenticated HTTP request abuse into appliance-level command execution, sandbox workflow tampering, submitted-file or analysis-artifact access, unusual outbound communication, local persistence, configuration modification, integration credential exposure, or FortiSandbox-originated access to adjacent security tooling. This may increase business interruption, malware-analysis trust uncertainty, incident-response cost, credential and token rotation burden, security-fabric review, SIEM, SOAR, and mail-security integration review, legal and compliance assessment, cyber-insurance scrutiny, and executive concern around defensive-control integrity.

Likelihood

High for unpatched FortiSandbox 4.4.0 through 4.4.8 systems that are internet-facing, partner-accessible, VPN-accessible, or broadly reachable from internal networks after public proof-of-concept circulation. Moderate where FortiSandbox is restricted to tightly controlled management networks and query-string, egress, and administrative telemetry are complete.

Impact

Severe where command execution, appliance tampering, submitted-artifact exposure, integration credential access, unusual appliance egress, or FortiSandbox-originated internal pivoting is confirmed or cannot be ruled out.

Risk Rating

High

Annualized Risk Exposure

Estimated $400K - $3M+ for materially exposed enterprise environments with affected FortiSandbox versions, public or broad-internal reachability, incomplete query-string retention, weak FortiSandbox egress baselines, or limited appliance administrative telemetry. Exposure may exceed $15M - $50M+ where FortiSandbox command execution affects malware-analysis integrity, submitted-file confidentiality, SIEM, SOAR, mail-security integrations, Fortinet Security Fabric trust, security-tooling credentials, internal management systems, regulated artifacts, customer-impact review, cyber-insurance obligations, or board-level confidence in defensive-control resilience.

S10 Threat Overview

CVE-2026-39808 is an unauthenticated OS command injection vulnerability in FortiSandbox. The most important CyberDax factor is not only that command execution may be possible, but that the affected product is a defensive appliance. If exploited, attacker control can affect malware-analysis integrity, submitted-file confidentiality, security-fabric trust, and adjacent security infrastructure.

The current evidence supports a compact TTD package because the exploit path is simple, public proof-of-concept material exists, and the affected asset class is high-value. It does not yet support a full EXP report without confirmed exploitation, KEV listing, named actor adoption, ransomware use, or documented post-exploitation behavior.

Scope Note

This TTD is scoped to FortiSandbox 4.4.0 through 4.4.8 as the controlling appliance scope. If an environment uses FortiSandbox PaaS or managed FortiSandbox variants, the same behavioral detection strategy should be reviewed for applicability, but the primary report scope remains the appliance-focused Fortinet FortiSandbox 4.4.x exposure path.

S13 Targets and Exposure Surface

Primary Target Surface

·        FortiSandbox 4.4.0 through 4.4.8.

·        FortiSandbox API and web request-handling paths.

·        Internet-facing or partner-accessible FortiSandbox deployments.

·        Internally reachable FortiSandbox systems accessible after VPN, workstation, server, or edge compromise.

·        Security-fabric, malware-analysis, mail-security, SIEM, SOAR, and file-analysis integrations connected to FortiSandbox.

Higher-Risk Deployment Conditions

·        FortiSandbox reachable from the internet.

·        FortiSandbox reachable from broad internal network ranges.

·        FortiSandbox management or API access not restricted to administrative jump hosts.

·        Weak egress controls from the appliance.

·        Limited HTTP request logging for FortiSandbox-facing traffic.

·        No query-string retention for FortiSandbox API requests.

·        Limited appliance-side process, file-write, configuration-change, or service-change telemetry.

·        Delayed upgrade to FortiSandbox 4.4.9 or later.

S17 MITRE ATT&CK Mapping

Initial Access

T1190 - Exploit Public-Facing Application

Applies where affected FortiSandbox API or web request-handling behavior is reachable by unauthenticated attackers through internet-facing, partner-accessible, VPN-accessible, or broad-internal exposure.

Execution

T1059 - Command and Scripting Interpreter

Applies where crafted HTTP request parameters cause operating-system command execution through the vulnerable FortiSandbox API path.

T1059.004 - Unix Shell

Applies if injected command behavior reaches a Unix-like shell context on the FortiSandbox appliance.

Defense Evasion

T1562 - Impair Defenses

Applies if an attacker tampers with FortiSandbox analysis behavior, logs, security-fabric integration behavior, sandbox verdicts, or local defensive functions after appliance compromise.

Credential Access

T1552 - Unsecured Credentials

Applies if an attacker accesses appliance-resident credentials, API tokens, integration secrets, service-account material, or configuration-stored secrets used by FortiSandbox integrations.

Discovery

T1082 - System Information Discovery

Applies where post-exploitation commands are used to identify appliance host details, operating-system context, privilege level, or runtime environment.

T1083 - File and Directory Discovery

Applies where commands enumerate submitted files, analysis artifacts, temporary paths, configuration files, or web/API-accessible locations.

Command and Control

T1071 - Application Layer Protocol

Applies where the compromised appliance initiates HTTP, HTTPS, DNS, or other application-layer callback or tool-retrieval behavior.

Lateral Movement

T1021 - Remote Services

Conditionally applies where the compromised FortiSandbox appliance is used as a trusted internal point to reach administrative services, security tooling, management systems, repositories, or other internal systems. This mapping depends on observed FortiSandbox-originated internal access or detection logic covering that behavior.

Collection

T1005 - Data from Local System

Applies where an attacker collects submitted files, malware samples, detonation outputs, sandbox verdicts, logs, configuration files, or analysis artifacts from the appliance.

S18 Attack Path Narrative

An attacker identifies an affected FortiSandbox deployment running version 4.4.0 through 4.4.8. The attacker sends crafted HTTP requests to the FortiSandbox API surface and attempts to inject operating-system command behavior through request parameters. If successful, command execution may occur under the context available to the FortiSandbox web or API process.

After execution, the attacker may attempt to verify privilege level, write files, retrieve command output, establish outbound communication, modify configuration, add persistence, or access submitted files and analysis artifacts. In higher-impact cases, the attacker may use the compromised appliance as a trusted point for staging, egress, or access to adjacent security systems.

S20 TTP Analysis

Primary Tradecraft

·        Unauthenticated HTTP request abuse against FortiSandbox API behavior.

·        OS command injection through crafted request parameters.

·        Web or API process spawning shell, interpreter, network, or file-write utilities.

·        Output redirection or temporary file staging.

·        Outbound callback behavior from a security appliance.

·        Local configuration modification, startup alteration, cron changes, service changes, or new user creation.

·        Sandbox workflow tampering or analysis artifact access.

·        Appliance-originated internal connections to security tooling or management infrastructure.

Likely Attacker Objectives

·        Gain command execution on FortiSandbox.

·        Confirm privileged execution context.

·        Access submitted files or analysis artifacts.

·        Tamper with malware-analysis workflows or outputs.

·        Stage tooling from a trusted security device.

·        Pivot toward SIEM, SOAR, mail-security, Fortinet Security Fabric, file repositories, or management networks.

·        Use FortiSandbox egress to reduce detection friction.

S21 Detection Strategy Overview

Detection should focus on behavior-led correlation rather than exploit-string matching alone. The strongest coverage comes from connecting suspicious FortiSandbox HTTP requests with version exposure, unusual appliance egress, internal pivoting, process execution where available, file writes, configuration changes, and service changes.

Priority detection logic should cover:

·        FortiSandbox versions 4.4.0 through 4.4.8 still present in production.

·        HTTP requests to FortiSandbox job-detail or tracer-behavior style paths.

·        Query parameters containing shell metacharacters, command substitution, pipes, redirection, semicolons, backticks, encoded equivalents, or suspicious command-wrapper syntax.

·        FortiSandbox web or API processes spawning shell, interpreter, network, or file-write utilities.

·        FortiSandbox initiating unusual outbound DNS, HTTP, HTTPS, SSH, ICMP, or direct-IP traffic.

·        FortiSandbox connecting to internal management, identity, SIEM, SOAR, mail-security, file-share, or security-tooling systems outside normal integration patterns.

·        New local users, cron changes, startup script changes, service restarts, configuration changes, or unexpected file writes.

Figure 1

S22 Primary Detection Signals

·        FortiSandbox-facing HTTP request URI includes job-detail or tracer-behavior path behavior.

·        Query string or decoded request parameter contains shell metacharacters or command-injection syntax.

·        FortiSandbox web/API process spawns shell, interpreter, network utility, archive utility, file-transfer utility, or system-management command.

·        FortiSandbox writes unexpected files under temporary, web-accessible, analysis, configuration, or startup paths.

·        FortiSandbox initiates unusual outbound DNS, HTTP, HTTPS, SSH, ICMP, or direct-IP traffic.

·        FortiSandbox initiates new internal connections to security tooling or management systems.

·        FortiSandbox local account, service, configuration, cron, or startup state changes occur near suspicious HTTP requests.

·        Vulnerability inventory shows FortiSandbox 4.4.0 through 4.4.8 after advisory publication.

S23 Telemetry Requirements

·        FortiSandbox version inventory.

·        FortiSandbox web/API access logs.

·        Proxy, WAF, reverse proxy, load-balancer, or NDR HTTP logs.

·        URI path, raw query string, decoded query string, method, status, source IP, destination IP, user agent, and timestamp.

·        DNS, proxy, firewall, and flow logs for FortiSandbox egress.

·        Asset inventory identifying FortiSandbox appliances and exposure state.

·        Vulnerability scanner data confirming affected versions.

·        Process execution telemetry from appliance-supported logging where available.

·        File integrity, file-write, service-change, startup-change, cron-change, and local-account telemetry where available.

·        FortiSandbox administrative, configuration, upgrade, and authentication logs.

·        Approved FortiSandbox egress and integration allowlists.

S24 Detection Opportunities and Gaps

Detection Opportunities

·        High-confidence exploit-attempt detection from FortiSandbox-specific path plus command-injection query indicators.

·        Stronger compromise suspicion from suspicious inbound request followed by unusual FortiSandbox egress.

·        Stronger post-exploitation signal from FortiSandbox-originated access to internal security-tooling or management assets.

·        Strong incident signal from process execution, file writes, local account creation, startup changes, service changes, or configuration modification near suspicious requests.

·        Immediate preventive value from identifying FortiSandbox 4.4.0 through 4.4.8 still present after advisory publication.

Detection Gaps

·        Appliance process telemetry may not be available.

·        Full query strings may not be retained by proxy, WAF, or NDR logging.

·        Encrypted traffic can hide request details unless inspected at an approved control point.

·        Sandbox detonation traffic may resemble suspicious egress unless analysis-path traffic is separated from management-plane traffic.

·        Exploit-string-only rules can miss encoded, fragmented, or modified payloads.

·        Cloud-only anomalies should not be attributed to CVE-2026-39808 without FortiSandbox exposure and inbound request correlation.

S25 Ultra-Tuned Detection Engineering Rules

NDR / Network Behavioral Analytics

Detection Viability Assessment

NDR has high detection value for this TTD because the exploit path is HTTP-based and the highest-confidence behaviors are visible at the network layer: suspicious FortiSandbox API requests, command-injection-style query parameters, unusual appliance egress, and FortiSandbox-originated internal connections after suspicious inbound activity. Three rules are included. These rules are production-ready detection patterns pending local NDR schema mapping, asset-group validation, query-string retention validation, and FortiSandbox egress baseline approval.

Rule

FortiSandbox API Request With Command Injection Indicators

Rule Format

NDR behavioral query pattern

Detection Purpose

Detect suspicious HTTP requests to FortiSandbox API behavior where request parameters suggest command injection against an appliance management or analysis endpoint.

Detection Logic

Alert when HTTP traffic targets a FortiSandbox asset and the URI path resembles FortiSandbox job-detail or tracer-behavior behavior while raw or decoded query content contains shell metacharacters, encoded separators, command substitution, output redirection, pipe usage, or suspicious command-wrapper syntax.

Required Telemetry

·        HTTP metadata from NDR, proxy, WAF, reverse proxy, or load balancer.

·        URI path and full request URL.

·        Raw query string and decoded query string.

·        Source IP and destination IP.

·        Destination asset identity or asset group.

·        HTTP method, response status, user agent, and timestamp.

·        Approved scanner source lookup.

·        FortiSandbox asset inventory or asset tag.

Engineering Implementation Instructions

The local engineer should create or validate an asset group named fortisandbox_assets with the fields asset_id, hostname, ip, version, exposure, owner, environment, and criticality. The engineer should validate that all FortiSandbox 4.4.0 through 4.4.8 systems and any upgraded 4.4.9 or later systems are represented so the rule can support both detection and post-patch assurance. The engineer must map local NDR fields to uri_path, request_url, query_raw, query_decoded, src_ip, dest_ip, http_method, http_status, user_agent, and event_time. Query-string retention must be tested with a controlled benign request containing a harmless encoded delimiter so the engineer can confirm raw and decoded query visibility. The engineer should create regex objects named cmd_injection_meta_regex, shell_substitution_regex, redirection_or_pipe_regex, and encoded_separator_regex, using local NDR-supported syntax. A lookup named approved_scanner_sources should contain vulnerability scanners, penetration-testing hosts, and validation tools, but scanner events should be retained for patch and exposure review rather than dropped. The rule should run in hunt mode for at least one normal operational cycle, then move to alert mode only after asset scope, query visibility, scanner suppression, and false-positive rates are validated.

DRI Assessment

This rule has strong detection relevance because it observes the exploitation delivery path directly. It detects likely exploitation attempts, not confirmed command execution.

DRI

8.6 / 10

TCR Assessment

Operational confidence is high when FortiSandbox assets are accurately tagged and full query strings are retained. Full confidence requires correlation with appliance egress, process telemetry, file writes, service changes, or configuration changes.

Operational TCR

8.0 / 10

Full-Telemetry TCR

9.1 / 10

Limitations

This rule may miss traffic where TLS inspection, reverse proxy logging, WAF logging, or NDR HTTP parsing does not retain query strings. Authorized scanning and validation testing can resemble exploitation attempts.

Detection Query Pattern

FROM ndr_http_events

WHERE dest_ip IN LOOKUP("fortisandbox_assets.ip")

AND (

  LOWER(uri_path) CONTAINS "/fortisandbox/job-detail/tracer-behavior"

  OR (

    LOWER(uri_path) CONTAINS "job-detail"

    AND LOWER(uri_path) CONTAINS "tracer"

  )

)

AND (

  query_raw MATCHES LOOKUP_REGEX("cmd_injection_meta_regex")

  OR query_decoded MATCHES LOOKUP_REGEX("cmd_injection_meta_regex")

  OR query_decoded MATCHES LOOKUP_REGEX("shell_substitution_regex")

  OR query_decoded MATCHES LOOKUP_REGEX("redirection_or_pipe_regex")

  OR query_decoded MATCHES LOOKUP_REGEX("encoded_separator_regex")

)

AND src_ip NOT IN LOOKUP("approved_scanner_sources.ip")

GROUP BY src_ip, dest_ip, uri_path, http_method, user_agent

WINDOW 10m

EMIT suspicious_fortisandbox_api_command_injection_attempt

Rule

FortiSandbox Suspicious API Request Followed By Unusual Egress

Rule Format

NDR sequence query pattern

Detection Purpose

Detect likely post-exploitation behavior by correlating suspicious FortiSandbox API requests with unusual outbound traffic from the same appliance.

Detection Logic

Alert when a FortiSandbox asset receives suspicious API-path traffic and then initiates DNS, HTTP, HTTPS, SSH, ICMP, direct-IP, rare-domain, suspicious-reputation, or nonstandard egress shortly afterward.

Required Telemetry

·        HTTP inbound metadata.

·        DNS logs.

·        Proxy logs.

·        Firewall or network flow logs.

·        Source and destination asset identity.

·        Destination IP, destination domain, destination port, and protocol.

·        Destination reputation, domain rarity, domain age, or equivalent enrichment.

·        Approved FortiSandbox egress lookup.

·        Approved detonation-path lookup.

·        Timestamp-normalized event correlation.

Engineering Implementation Instructions

The local engineer should create approved_fortisandbox_egress with dest_ip, dest_domain, dest_port, protocol, business_purpose, owner, and expiration_date fields. The lookup should include Fortinet update destinations, approved detonation paths, sandbox analysis destinations, SIEM/SOAR integrations, mail-security integrations, repository integrations, vendor support destinations, and documented administrative workflows. The engineer must confirm that the inbound HTTP event’s dest_ip can be correlated to the outbound flow event’s src_ip and that both data sets use synchronized timestamps. If the NDR does not support domain age or reputation, the engineer should substitute local DNS rarity, threat-intelligence category, direct-IP flag, first-seen destination, or abnormal-port logic. Detonation-generated traffic should be baselined separately from appliance management-plane traffic, using one normal operational cycle as the minimum baseline. The rule should begin in hunt mode and move to alert mode only after approved egress entries are validated, detonation behavior is baselined, scanner and validation traffic is tuned, and SOC triage instructions distinguish failed exploitation, sandbox detonation, and likely post-exploitation callback behavior.

DRI Assessment

This rule provides strong post-exploitation correlation because it looks for appliance behavior after an exploitation-pattern request.

DRI

8.9 / 10

TCR Assessment

Operational confidence depends on egress baselining and destination enrichment. Full confidence requires the ability to separate detonation-generated traffic from appliance management-plane traffic.

Operational TCR

8.2 / 10

Full-Telemetry TCR

9.3 / 10

Limitations

FortiSandbox may legitimately contact unusual destinations during malware detonation. Triage must determine whether egress originated from sandbox analysis behavior, normal integrations, or the appliance control plane.

Detection Query Pattern

LET suspicious_inbound =

  FROM ndr_http_events

  WHERE dest_ip IN LOOKUP("fortisandbox_assets.ip")

  AND (

    LOWER(uri_path) CONTAINS "/fortisandbox/job-detail/tracer-behavior"

    OR (

      LOWER(uri_path) CONTAINS "job-detail"

      AND LOWER(uri_path) CONTAINS "tracer"

    )

  )

  AND (

    query_raw MATCHES LOOKUP_REGEX("cmd_injection_meta_regex")

    OR query_decoded MATCHES LOOKUP_REGEX("cmd_injection_meta_regex")

  )

  AND src_ip NOT IN LOOKUP("approved_scanner_sources.ip");

LET unusual_egress =

  FROM ndr_flow_events

  WHERE src_ip IN LOOKUP("fortisandbox_assets.ip")

  AND dest_ip NOT IN LOOKUP("approved_fortisandbox_egress.dest_ip")

  AND dest_domain NOT IN LOOKUP("approved_fortisandbox_egress.dest_domain")

  AND (

    dest_reputation IN ("rare", "new", "suspicious", "malicious")

    OR dest_port IN (22, 4444, 8080, 8443)

    OR protocol IN ("icmp", "ssh")

    OR dest_is_direct_ip = true

    OR dest_domain_age_days < 30

  );

SEQUENCE suspicious_inbound THEN unusual_egress

WHERE unusual_egress.timestamp BETWEEN suspicious_inbound.timestamp

AND suspicious_inbound.timestamp + 30m

GROUP BY src_ip, dest_ip, dest_domain, dest_port, protocol

EMIT possible_fortisandbox_command_execution_with_egress

Rule

FortiSandbox-Originated Internal Security Tooling Pivot

Rule Format

NDR lateral-movement query pattern

Detection Purpose

Detect possible appliance compromise followed by FortiSandbox-originated access to sensitive internal security, management, logging, or identity systems.

Detection Logic

Alert when a FortiSandbox asset receives suspicious API traffic and then connects to management, SIEM, SOAR, identity, mail-security, repository, file-share, Fortinet management, or other security-tooling assets outside approved integration paths.

Required Telemetry

·        HTTP metadata.

·        East-west network flow logs.

·        Source and destination asset identity.

·        Internal asset role tags.

·        Destination port and protocol.

·        Approved FortiSandbox internal integration lookup.

·        Sensitive security-tooling and management asset lookup.

·        Timestamp-normalized correlation.

Engineering Implementation Instructions

The local engineer should create security_tooling_or_management_assets with asset_id, hostname, ip, role, owner, environment, and criticality fields. This lookup should include SIEM, SOAR, identity, mail-security, file repositories, Fortinet management, administrative jump hosts, privileged management systems, and security tooling. The engineer should also create approved_fortisandbox_internal_integrations as approved source, destination, port, protocol, and business-purpose tuples rather than broad subnet exclusions. East-west NDR fields for src_ip, dest_ip, dest_port, protocol, connection_tuple, and event_time must be mapped before deployment. The rule should be tested against documented FortiSandbox integrations and tuned so it alerts on non-approved security-tooling or management-plane access. SOC triage should require confirming whether the suspicious inbound request preceded the internal connection, whether the destination is privileged or sensitive, and whether the connection matches a documented integration. Alert-mode promotion should occur only after integration allowlists, sensitive asset tagging, and false-positive rates are validated.

DRI Assessment

This rule is useful for detecting compromised-appliance movement toward adjacent security infrastructure.

DRI

8.1 / 10

TCR Assessment

Operational confidence depends on internal asset-role tagging and accurate FortiSandbox integration allowlists.

Operational TCR

7.6 / 10

Full-Telemetry TCR

8.9 / 10

Limitations

Legitimate FortiSandbox integrations may produce similar traffic without mature asset tagging and allowlist management.

Detection Query Pattern

LET suspicious_api =

  FROM ndr_http_events

  WHERE dest_ip IN LOOKUP("fortisandbox_assets.ip")

  AND (

    LOWER(uri_path) CONTAINS "/fortisandbox/job-detail/tracer-behavior"

    OR (

      LOWER(uri_path) CONTAINS "job-detail"

      AND LOWER(uri_path) CONTAINS "tracer"

    )

  )

  AND (

    query_raw MATCHES LOOKUP_REGEX("cmd_injection_meta_regex")

    OR query_decoded MATCHES LOOKUP_REGEX("cmd_injection_meta_regex")

  );

LET internal_followon =

  FROM ndr_flow_events

  WHERE src_ip IN LOOKUP("fortisandbox_assets.ip")

  AND dest_ip IN LOOKUP("security_tooling_or_management_assets.ip")

  AND connection_tuple NOT IN LOOKUP("approved_fortisandbox_internal_integrations.connection_tuple");

SEQUENCE suspicious_api THEN internal_followon

WHERE internal_followon.timestamp BETWEEN suspicious_api.timestamp

AND suspicious_api.timestamp + 2h

GROUP BY src_ip, dest_ip, dest_port, protocol

EMIT possible_fortisandbox_security_tooling_pivot

SentinelOne

Detection Viability Assessment

SentinelOne has conditional detection value for this TTD. FortiSandbox is typically an appliance, so standard SentinelOne endpoint-agent visibility may not exist on the affected host layer. If SentinelOne Deep Visibility or equivalent forwarded endpoint telemetry is available, these rules can detect web/API child-process execution and suspicious process-to-network follow-on behavior. If that telemetry is not available, SentinelOne should be treated as non-primary coverage and detection should rely on NDR, proxy, WAF, SIEM, DNS, firewall, and FortiSandbox administrative logs. Two conditional rules are included. These rules are production-ready detection patterns only where the environment confirms SentinelOne process and network telemetry from the FortiSandbox host layer.

Rule

FortiSandbox Web/API Parent Spawning Shell or Network Utility

Rule Format

SentinelOne Deep Visibility / behavioral query pattern

Detection Purpose

Detect possible command execution from FortiSandbox web or API service context.

Detection Logic

Alert when a FortiSandbox-tagged host or appliance-like system shows a web/API parent process spawning shell, interpreter, network, file-transfer, archive, file-write, or system-management utilities.

Required Telemetry

·        SentinelOne process creation telemetry from the FortiSandbox host layer.

·        Endpoint tag or asset group identifying FortiSandbox.

·        Parent process name.

·        Child process name.

·        Command line.

·        User context.

·        Hostname.

·        Timestamp.

·        Approved vendor support or administrative maintenance exception list.

Engineering Implementation Instructions

The local engineer must first confirm whether SentinelOne Deep Visibility or equivalent forwarded telemetry exists for the FortiSandbox host layer. If endpoint telemetry is not available, this rule should remain documented as conditional coverage and should not be enabled. If telemetry exists, the engineer should tag FortiSandbox systems with FortiSandbox or an equivalent endpoint tag and validate the fields endpoint_name, endpoint_tags, parent_process_name, process_name, command_line, user, and event_time. The engineer should identify actual FortiSandbox web/API parent process names through vendor-supported logging, controlled administrative testing, or historical process telemetry. The engineer should define a controlled utility list containing shells, interpreters, file-transfer utilities, network utilities, archive utilities, discovery commands, and file-write utilities observed as abnormal under the FortiSandbox web/API parent. Vendor support sessions and approved administrative troubleshooting should be captured in a time-bounded exception list. The rule should stay in hunt mode until a local test confirms parent-child process visibility and the SOC has a triage path for distinguishing vendor support, appliance maintenance, and likely exploitation.

DRI Assessment

This rule has high behavioral relevance if process telemetry is available. Deployability is conditional because FortiSandbox may not support standard endpoint telemetry.

DRI

8.7 / 10

TCR Assessment

Operational confidence depends on parent-process mapping, FortiSandbox tagging, and process telemetry availability.

Operational TCR

6.9 / 10

Full-Telemetry TCR

9.3 / 10

Limitations

This rule should not be treated as primary coverage unless SentinelOne or equivalent process telemetry is confirmed for the FortiSandbox host layer.

Detection Query Pattern

FROM ProcessCreation

WHERE endpoint_tags CONTAINS "FortiSandbox"

AND parent_process_name IN LOOKUP("fortisandbox_web_api_parents.name")

AND process_name IN LOOKUP("shell_network_or_file_utility_names.name")

AND (

  command_line MATCHES LOOKUP_REGEX("suspicious_command_or_file_write_regex")

  OR command_line MATCHES LOOKUP_REGEX("network_utility_usage_regex")

  OR command_line MATCHES LOOKUP_REGEX("system_discovery_command_regex")

)

AND event_time NOT IN LOOKUP("approved_vendor_support_windows.time_window")

GROUP BY endpoint_name, parent_process_name, process_name, command_line, user

WINDOW 30m

EMIT fortisandbox_web_api_child_process_execution

Rule

FortiSandbox Suspicious Process Followed By External Network Connection

Rule Format

SentinelOne Deep Visibility sequence query pattern

Detection Purpose

Detect possible post-exploitation behavior where suspicious process execution on a FortiSandbox-tagged system is followed by unusual outbound network communication.

Detection Logic

Alert when a FortiSandbox-tagged endpoint shows suspicious web/API child-process execution and then initiates network communication to an unapproved, rare, suspicious, direct-IP, SSH, ICMP, or abnormal-port destination.

Required Telemetry

·        SentinelOne process creation telemetry.

·        SentinelOne network connection telemetry.

·        Endpoint tag or asset group identifying FortiSandbox.

·        Destination IP, domain, port, and protocol.

·        Destination reputation or rarity enrichment where available.

·        Approved FortiSandbox egress lookup.

·        Approved vendor support or administrative maintenance exception list.

Engineering Implementation Instructions

The local engineer must confirm that SentinelOne sees both process creation and network connection events for the FortiSandbox host layer before this rule is treated as deployable. The engineer should map local SentinelOne network fields for destination_ip, destination_domain, destination_port, protocol, destination_reputation, direct_ip_flag, and event_time. The lookup approved_fortisandbox_egress should include Fortinet update destinations, detonation paths, vendor support destinations, and documented integrations. Detonation-generated traffic should be baselined separately from management-plane traffic where possible. The rule should be validated in hunt mode by reviewing historical FortiSandbox process-to-network sequences and confirming that approved vendor support and maintenance activity do not create unacceptable noise. Alert-mode promotion should require confirmed process visibility, confirmed network visibility, tuned approved-egress logic, and SOC triage instructions that check for suspicious inbound HTTP activity near the process event.

DRI Assessment

This rule has strong post-exploitation relevance when both process and network telemetry are present.

DRI

8.8 / 10

TCR Assessment

Operational confidence is conditional but high when SentinelOne observes both process creation and network connections from the appliance.

Operational TCR

7.0 / 10

Full-Telemetry TCR

9.4 / 10

Limitations

Sandbox detonation traffic and vendor support activity may create unusual outbound connections. This rule requires local validation before alert-mode deployment.

Detection Query Pattern

SEQUENCE BY endpoint_name

  ProcessCreation

    WHERE endpoint_tags CONTAINS "FortiSandbox"

    AND parent_process_name IN LOOKUP("fortisandbox_web_api_parents.name")

    AND process_name IN LOOKUP("shell_network_or_file_utility_names.name")

  THEN NetworkConnection

    WHERE endpoint_tags CONTAINS "FortiSandbox"

    AND destination_ip NOT IN LOOKUP("approved_fortisandbox_egress.dest_ip")

    AND destination_domain NOT IN LOOKUP("approved_fortisandbox_egress.dest_domain")

    AND (

      destination_reputation IN ("rare", "suspicious", "malicious")

      OR destination_port IN (22, 4444, 8080, 8443)

      OR direct_ip_flag = true

      OR protocol IN ("icmp", "ssh")

    )

WITHIN 30m

EMIT possible_fortisandbox_process_execution_followed_by_egress

Splunk

Detection Viability Assessment

Splunk has high detection value where proxy, WAF, NDR, DNS, firewall, vulnerability, and asset data are indexed. Splunk is well suited for exploit-attempt detection, request-to-egress correlation, and affected-version inventory control. Three rules are included. These rules are production-ready detection patterns pending local index, sourcetype, field, lookup, macro, and schedule validation.

Rule

FortiSandbox HTTP Command Injection Attempt

Rule Format

Splunk SPL correlation pattern

Detection Purpose

Detect suspicious HTTP requests to FortiSandbox API behavior with command-injection indicators.

Detection Logic

Search HTTP logs for FortiSandbox destination assets, FortiSandbox job-detail or tracer-behavior path indicators, and command-injection metacharacter patterns in raw or decoded query fields.

Required Telemetry

·        Proxy logs, WAF logs, reverse proxy logs, load-balancer logs, or NDR HTTP logs.

·        URI path, full URL, raw query string, and decoded query string.

·        Source IP and destination IP.

·        HTTP method, status, and user agent.

·        FortiSandbox asset lookup.

·        Approved scanner source lookup.

·        Splunk macro for command-injection matching.

Engineering Implementation Instructions

The local Splunk engineer should create fortisandbox_assets.csv with ip, hostname, version, exposure, environment, owner, and criticality fields. The engineer should create approved_scanner_sources.csv with ip, scanner_name, owner, and business_purpose fields. The macro cmd_injection_meta_regex should include shell separators, pipe usage, command substitution, redirection, semicolons, backticks, encoded equivalents, and locally observed validation strings. The engineer must map local indexes and sourcetypes into ENV_PROXY_OR_NDR_INDEX and ENV_HTTP_SOURCETYPES, then replace placeholder fields with local field names if they differ from uri_path, uri, url, request_uri, query, uri_query, url_query, request, src_ip, dest_ip, http_method, status, and user_agent. Query-string retention must be verified before alert-mode deployment. This search should run in hunt mode first, with scanner events retained for exposure validation and only alert suppression applied after false-positive review. Alert-mode promotion should require lookup completeness, query visibility, macro validation, sourcetype validation, and acceptable false-positive volume.

DRI Assessment

This rule is a strong exploit-attempt detector when URI and query-string fields are retained.

DRI

8.6 / 10

TCR Assessment

Operational confidence depends on query-string logging, URL decoding, and FortiSandbox asset lookup accuracy.

Operational TCR

8.1 / 10

Full-Telemetry TCR

9.2 / 10

Limitations

This rule does not prove command execution without correlation to process, file, configuration, service, or egress activity.

Detection Query Pattern

index=ENV_PROXY_OR_NDR_INDEX sourcetype IN (ENV_HTTP_SOURCETYPES)

| lookup fortisandbox_assets.csv ip AS dest_ip OUTPUT hostname AS fortisandbox_host version exposure environment owner criticality

| where isnotnull(fortisandbox_host)

| lookup approved_scanner_sources.csv ip AS src_ip OUTPUT scanner_name AS approved_scanner

| eval uri_l=lower(coalesce(uri_path, uri, url, request_uri))

| eval q_raw=coalesce(query, uri_query, url_query, request, uri)

| eval q_decoded=urldecode(q_raw)

| where like(uri_l,"%/fortisandbox/job-detail/tracer-behavior%")

   OR (like(uri_l,"%job-detail%") AND like(uri_l,"%tracer%"))

| where match(q_raw, `cmd_injection_meta_regex`)

   OR match(q_decoded, `cmd_injection_meta_regex`)

| eval scanner_context=if(isnotnull(approved_scanner),"approved_scanner","non_scanner_source")

| stats count

  min(_time) as first_seen

  max(_time) as last_seen

  values(uri_l) as uri

  values(q_decoded) as decoded_query

  values(user_agent) as user_agent

  values(http_method) as http_method

  values(status) as status

  values(scanner_context) as scanner_context

  by src_ip dest_ip fortisandbox_host version exposure environment owner criticality

| where scanner_context!="approved_scanner"

| eval severity=case(exposure="internet","critical", exposure="broad_internal","high", criticality="high","high", true(),"medium")

Rule

FortiSandbox Suspicious Request Followed By Unusual Egress

Rule Format

Splunk SPL sequence correlation pattern

Detection Purpose

Detect likely post-exploitation behavior by correlating suspicious FortiSandbox HTTP requests with unusual outbound network activity from the appliance.

Detection Logic

Identify suspicious inbound FortiSandbox API requests and correlate them with DNS, proxy, firewall, or flow events from the same FortiSandbox asset within a bounded time window.

Required Telemetry

·        HTTP logs.

·        DNS logs.

·        Proxy logs.

·        Firewall logs.

·        Flow logs.

·        FortiSandbox asset lookup.

·        Approved FortiSandbox egress lookup.

·        Destination reputation, direct-IP, port, and protocol fields.

·        Timestamp-normalized Splunk ingestion.

Engineering Implementation Instructions

The local Splunk engineer should create approved_fortisandbox_egress.csv with dest, dest_type, dest_port, protocol, business_purpose, owner, and expiration_date fields. The dest field should support both IP and domain values or be split into dest_ip and dest_domain if local data requires it. HTTP, DNS, proxy, firewall, and flow indexes should be mapped into ENV_PROXY_OR_NDR_INDEX and ENV_DNS_PROXY_FIREWALL_INDEX; sourcetypes should be mapped into ENV_HTTP_SOURCETYPES and ENV_EGRESS_SOURCETYPES. The FortiSandbox destination IP in the HTTP event must map to the FortiSandbox source IP in the egress event. If transaction is too expensive for production, the engineer should convert this into a scheduled correlation using summary indexing, accelerated data models, or stats with bounded time buckets. The rule should remain in hunt mode until detonation traffic is baselined, approved egress is tuned, query performance is tested, and SOC triage can separate scanner traffic, sandbox-analysis traffic, and possible attacker callbacks.

DRI Assessment

This rule increases confidence by linking exploitation-pattern requests with appliance behavior.

DRI

8.8 / 10

TCR Assessment

Operational confidence depends on egress baselining, reliable asset identity, and destination enrichment.

Operational TCR

8.0 / 10

Full-Telemetry TCR

9.2 / 10

Limitations

FortiSandbox detonation workflows may legitimately generate unusual egress. Triage must determine whether traffic aligns with analysis behavior or appliance control-plane behavior.

Detection Query Pattern

(

  search index=ENV_PROXY_OR_NDR_INDEX sourcetype IN (ENV_HTTP_SOURCETYPES)

  | lookup fortisandbox_assets.csv ip AS dest_ip OUTPUT hostname AS fortisandbox_host

  | where isnotnull(fortisandbox_host)

  | eval uri_l=lower(coalesce(uri_path, uri, url, request_uri))

  | eval q_decoded=urldecode(coalesce(query, uri_query, request, uri))

  | where like(uri_l,"%/fortisandbox/job-detail/tracer-behavior%")

     OR (like(uri_l,"%job-detail%") AND like(uri_l,"%tracer%"))

  | where match(q_decoded, `cmd_injection_meta_regex`)

  | eval event_type="suspicious_inbound"

  | eval fortisandbox_ip=dest_ip

  | fields _time event_type src_ip fortisandbox_ip fortisandbox_host uri_l q_decoded

)

| append [

  search index=ENV_DNS_PROXY_FIREWALL_INDEX sourcetype IN (ENV_EGRESS_SOURCETYPES)

  | lookup fortisandbox_assets.csv ip AS src_ip OUTPUT hostname AS fortisandbox_host

  | where isnotnull(fortisandbox_host)

  | lookup approved_fortisandbox_egress.csv dest AS dest OUTPUT dest AS approved_dest

  | where isnull(approved_dest)

  | where dest_reputation IN ("rare","new","suspicious","malicious")

     OR dest_port IN (22,4444,8080,8443)

     OR protocol IN ("icmp","ssh")

     OR dest_is_direct_ip=1

  | eval event_type="unusual_egress"

  | eval fortisandbox_ip=src_ip

  | fields _time event_type fortisandbox_ip fortisandbox_host dest dest_port protocol dest_reputation

]

| transaction fortisandbox_ip maxspan=30m startswith=event_type="suspicious_inbound" endswith=event_type="unusual_egress"

| search event_type="suspicious_inbound" event_type="unusual_egress"

Rule

Affected FortiSandbox Version Still Present After Advisory

Rule Format

Splunk SPL inventory-control pattern

Detection Purpose

Detect FortiSandbox systems still running affected versions after advisory publication.

Detection Logic

Search asset, vulnerability, CMDB, or Fortinet inventory data for FortiSandbox versions 4.4.0 through 4.4.8 and escalate based on exposure.

Required Telemetry

·        Vulnerability scanner inventory.

·        CMDB records.

·        Fortinet inventory.

·        Product, vendor, and application fields.

·        Software version or detected version.

·        Exposure classification.

·        Asset owner and environment.

·        Scanner ingestion timestamp.

Engineering Implementation Instructions

The local engineer should map vulnerability scanner, CMDB, and Fortinet inventory data into ENV_VULN_OR_ASSET_INDEX. The fields product, app, vendor, version, detected_version, software_version, exposure, owner, and environment should be normalized before scheduling the rule. Version parsing must be tested so 4.4.0 through 4.4.8 match and 4.4.9 or later does not match. Exposure should be normalized to local categories such as internet, broad_internal, restricted_management, or unknown. The rule should run after scanner ingestion completes and should be routed to the asset owner and vulnerability-management queue. Alert-mode deployment is appropriate after scanner freshness, version parsing, owner mapping, and exposure classification are validated.

DRI Assessment

This is a preventive exposure-control rule with high operational value.

DRI

7.8 / 10

TCR Assessment

Confidence is high when scanner inventory is fresh, authenticated, and mapped to exposure state.

Operational TCR

8.6 / 10

Full-Telemetry TCR

9.3 / 10

Limitations

Unauthenticated scanners may misidentify appliance versions. Confirm with FortiSandbox administrative inventory.

Detection Query Pattern

index=ENV_VULN_OR_ASSET_INDEX

| search product="FortiSandbox" OR app="FortiSandbox" OR vendor="Fortinet"

| eval version_norm=coalesce(version, detected_version, software_version)

| where match(version_norm, "^4\.4\.[0-8]$")

| eval remediation="Upgrade FortiSandbox to 4.4.9 or later"

| eval severity=case(exposure="internet","critical", exposure="broad_internal","high", exposure="unknown","high", true(),"medium")

| stats latest(_time) as last_seen

  values(version_norm) as affected_version

  values(exposure) as exposure

  values(remediation) as remediation

  by asset hostname ip owner environment

Elastic

Detection Viability Assessment

Elastic has strong detection value where HTTP, proxy, NDR, DNS, network, vulnerability, and asset data are normalized into ECS or consistent custom fields. Elastic is well suited for FortiSandbox HTTP attempt detection, egress anomaly detection, and request-to-egress sequence correlation. Three rules are included. These rules are production-ready detection patterns pending local ECS mapping, enrichment, value-list creation, query-string validation, and event-correlation testing.

Rule

FortiSandbox API Request With Command Injection Indicators

Rule Format

Elastic KQL / EQL pattern

Detection Purpose

Detect suspicious HTTP requests targeting FortiSandbox API behavior with command-injection indicators.

Detection Logic

Match FortiSandbox destination assets and job-detail or tracer-behavior request patterns where URL query, original URL, or request content contains suspicious shell metacharacter, encoded command separator, redirection, pipe, or command-substitution indicators.

Required Telemetry

·        HTTP, proxy, WAF, load-balancer, or NDR logs.

·        url.path, url.query, and url.original.

·        http.request.method and http.response.status_code.

·        source.ip and destination.ip.

·        user_agent.original.

·        FortiSandbox asset enrichment.

·        Approved scanner exception list.

·        Command-injection value list or regex.

Engineering Implementation Instructions

The local Elastic engineer should create FortiSandbox asset enrichment using destination.ip, host.name, asset.id, asset.group, environment, exposure, and owner. Proxy, WAF, load-balancer, and NDR logs should be mapped to ECS fields including url.path, url.query, url.original, http.request.method, http.response.status_code, source.ip, destination.ip, and user_agent.original. If local data does not use ECS, the engineer should create ECS aliases or update the rule to local field names. Query-string retention and URL-decoding behavior must be validated with controlled benign requests. The value list cmd_injection_meta_pattern should include raw and encoded separators, pipe, command substitution, redirection, semicolon, backtick, and other locally supported command-injection indicators. Approved scanner sources should be implemented as an exception list while retaining the underlying telemetry. The rule should begin in detection preview or hunt mode and move to alert mode only after field mapping, asset enrichment, query retention, exception handling, and false-positive rates are confirmed.

DRI Assessment

This rule has high relevance for exploit-attempt detection when full URL telemetry is available.

DRI

8.5 / 10

TCR Assessment

Operational confidence depends on URL query retention, decoding normalization, and accurate FortiSandbox asset enrichment.

Operational TCR

7.9 / 10

Full-Telemetry TCR

9.0 / 10

Limitations

This rule detects attempts and scans, not confirmed execution by itself.

Detection Query Pattern

event.dataset:("proxy" OR "waf" OR "ndr" OR "http")

AND destination.ip IN value_list("fortisandbox_asset_ips")

AND (

  url.path: "/fortisandbox/job-detail/tracer-behavior"

  OR (url.path: *job-detail* AND url.path: *tracer*)

)

AND (

  url.query: value_list("cmd_injection_meta_pattern")

  OR url.original: value_list("cmd_injection_meta_pattern")

  OR http.request.body.content: value_list("cmd_injection_meta_pattern")

)

AND NOT source.ip IN value_list("approved_scanner_sources")

Rule

FortiSandbox Unusual Outbound Network Activity

Rule Format

Elastic KQL / EQL network pattern

Detection Purpose

Detect unusual egress from FortiSandbox that may indicate callback, tool staging, exfiltration preparation, or lateral movement after exploitation.

Detection Logic

Alert when FortiSandbox initiates outbound communication to unapproved, rare, direct-IP, suspicious, malicious, SSH, ICMP, or abnormal-port destinations.

Required Telemetry

·        Network connection logs.

·        DNS logs.

·        Proxy and firewall logs.

·        source.ip, destination.ip, destination.port, and network.transport.

·        dns.question.name and destination.domain.

·        Destination reputation, rarity, or first-seen enrichment.

·        Approved FortiSandbox egress value lists.

·        FortiSandbox source enrichment.

Engineering Implementation Instructions

The local Elastic engineer should map network, DNS, proxy, and firewall telemetry to source.ip, destination.ip, destination.port, destination.domain, dns.question.name, network.transport, destination risk fields, first-seen fields, and direct-IP indicators. FortiSandbox source asset enrichment must be validated so this rule evaluates only traffic originating from FortiSandbox appliances. Value lists approved_fortisandbox_egress_ips and approved_fortisandbox_egress_domains should include Fortinet updates, detonation paths, approved integrations, vendor support destinations, and documented security-fabric communication. Detonation traffic should be baselined separately from appliance control-plane traffic. Exceptions should be reviewed periodically and should include owner and expiration metadata where the backend supports it. Keep the rule in hunt mode until approved egress, detonation behavior, and false-positive rates are understood.

DRI Assessment

This rule has moderate-to-high relevance as a post-exploitation behavior signal.

DRI

8.2 / 10

TCR Assessment

Confidence depends on separating detonation traffic from appliance control-plane traffic.

Operational TCR

7.5 / 10

Full-Telemetry TCR

8.9 / 10

Limitations

Malware detonation workflows can generate unusual outbound traffic. Correlation with suspicious inbound HTTP activity is recommended.

Detection Query Pattern

source.ip IN value_list("fortisandbox_asset_ips")

AND NOT destination.ip IN value_list("approved_fortisandbox_egress_ips")

AND NOT destination.domain IN value_list("approved_fortisandbox_egress_domains")

AND (

  destination.port: (22 OR 4444 OR 8080 OR 8443)

  OR network.transport: "icmp"

  OR destination.risk: ("suspicious" OR "malicious")

  OR destination.domain.rarity: "rare"

  OR destination.ip_is_direct: true

)

Rule

FortiSandbox HTTP Attempt Followed By Unusual Egress

Rule Format

Elastic EQL sequence pattern

Detection Purpose

Correlate suspicious FortiSandbox API requests with unusual outbound communication from the same appliance.

Detection Logic

Alert when a FortiSandbox destination receives a suspicious API request and the same appliance initiates unusual outbound traffic within a bounded time window.

Required Telemetry

·        HTTP logs.

·        Network connection logs.

·        DNS logs.

·        Shared FortiSandbox identity across inbound and outbound telemetry.

·        FortiSandbox asset enrichment.

·        Approved egress value lists.

·        Timestamp-normalized correlation.

Engineering Implementation Instructions

The local Elastic engineer should confirm that HTTP and network events can be correlated by a stable FortiSandbox identity, such as host.id, asset.id, destination.ip from the inbound event mapped to source.ip from the outbound event, or enriched asset name. If host.id is not shared between HTTP and network events, this sequence should be rewritten to correlate destination.ip from the inbound event to source.ip from the egress event. The engineer must validate event category, event dataset, URL fields, destination and source fields, value lists, and timestamp behavior. The sequence window should be tested against log ingestion latency and expected FortiSandbox detonation timing. This rule should remain in hunt mode until correlation fidelity is proven and detonation-generated egress is tuned. Alert-mode promotion should require documented triage steps for reviewing the inbound request, outbound destination, FortiSandbox version, and nearby administrative activity.

DRI Assessment

This rule improves confidence over HTTP attempt detection alone by requiring follow-on appliance behavior.

DRI

8.7 / 10

TCR Assessment

Operational confidence is high when HTTP and egress events can be correlated by destination/source appliance identity.

Operational TCR

8.0 / 10

Full-Telemetry TCR

9.1 / 10

Limitations

This rule may miss successful exploitation without outbound communication. It may also alert on detonation-generated egress if baselines are incomplete.

Detection Query Pattern

sequence by host.id with maxspan=30m

  [network where event.dataset in ("http", "proxy", "waf", "ndr")

   and destination.ip in value_list("fortisandbox_asset_ips")

   and (

     url.path == "/fortisandbox/job-detail/tracer-behavior"

     or (url.path like "*job-detail*" and url.path like "*tracer*")

   )

   and (

     url.query regex value_list("cmd_injection_meta_pattern")

     or url.original regex value_list("cmd_injection_meta_pattern")

   )]

  [network where source.ip in value_list("fortisandbox_asset_ips")

   and destination.ip not in value_list("approved_fortisandbox_egress_ips")

   and destination.domain not in value_list("approved_fortisandbox_egress_domains")

   and (

     destination.port in (22, 4444, 8080, 8443)

     or network.transport == "icmp"

     or destination.risk in ("suspicious", "malicious")

     or destination.ip_is_direct == true

   )]

QRadar

Detection Viability Assessment

QRadar has strong detection value when HTTP, firewall, DNS, vulnerability, flow, and asset-role data are available. QRadar is well suited for FortiSandbox exploit-attempt detection, request-to-egress correlation, and affected-version exposure control. Three rules are included. These rules are production-ready detection patterns pending reference-set creation, custom-property extraction, CRE building-block validation, scanner tuning, and offense-routing validation.

Rule

FortiSandbox Suspicious API Command Injection Attempt

Rule Format

QRadar AQL / CRE pattern

Detection Purpose

Detect suspicious requests to FortiSandbox API paths with command-injection characteristics.

Detection Logic

Match FortiSandbox destination assets, FortiSandbox path indicators, and command-injection metacharacter patterns in request URL, query, or payload text.

Required Telemetry

·        Web proxy events.

·        WAF events.

·        NDR HTTP events.

·        URL and query custom properties.

·        Payload text where available.

·        Source IP and destination IP.

·        User agent custom property.

·        FortiSandbox reference set.

·        Approved scanner reference set.

·        Command-injection regex building block.

Engineering Implementation Instructions

The local QRadar engineer should create ENV_FORTISANDBOX_ASSETS as a reference set populated from CMDB, Fortinet inventory, vulnerability scanner output, and management IP ranges. The engineer should create ENV_APPROVED_SCANNER_SOURCES for scanner and validation hosts. Custom properties for URL, query string, payload text, user agent, source IP, and destination IP must be validated across web proxy, WAF, and NDR log sources. If URL or query fields are not extracted, custom property extraction must be created before alert-mode deployment. ENV_CMD_INJECTION_META_REGEX should be implemented as a QRadar-supported regex building block and tested against raw and encoded request values. The CRE rule should start as a low-impact offense or hunt rule until reference sets, custom properties, scanner handling, and false-positive volume are validated. Offense severity should increase for internet-facing FortiSandbox assets and non-scanner sources.

DRI Assessment

This rule has strong detection relevance when URL and query fields are normalized.

DRI

8.4 / 10

TCR Assessment

Confidence depends on URL retention, reference-set quality, and custom property extraction.

Operational TCR

7.8 / 10

Full-Telemetry TCR

9.0 / 10

Limitations

Coverage is reduced if query strings are not parsed or retained.

Detection Query Pattern

SELECT

  sourceip,

  destinationip,

  UTF8(payload) AS payload_text,

  URL,

  "User Agent" AS user_agent,

  COUNT(*) AS event_count

FROM events

WHERE destinationip IN REFERENCESET('ENV_FORTISANDBOX_ASSETS')

AND sourceip NOT IN REFERENCESET('ENV_APPROVED_SCANNER_SOURCES')

AND (

  LOWER(URL) LIKE '%/fortisandbox/job-detail/tracer-behavior%'

  OR (LOWER(URL) LIKE '%job-detail%' AND LOWER(URL) LIKE '%tracer%')

)

AND (

  URL IMATCHES 'ENV_CMD_INJECTION_META_REGEX'

  OR UTF8(payload) IMATCHES 'ENV_CMD_INJECTION_META_REGEX'

)

GROUP BY sourceip, destinationip, URL, user_agent

LAST 10 MINUTES

Rule

FortiSandbox Suspicious API Request Followed By Rare Egress

Rule Format

QRadar CRE sequence pattern

Detection Purpose

Detect potential successful exploitation by correlating suspicious FortiSandbox API traffic with unusual outbound network behavior.

Detection Logic

Trigger when a FortiSandbox asset receives suspicious API traffic and then initiates rare or unapproved outbound DNS, HTTP, HTTPS, SSH, ICMP, direct-IP, or abnormal-port communication.

Required Telemetry

·        HTTP events.

·        DNS events.

·        Firewall events.

·        Flow events.

·        FortiSandbox asset reference set.

·        Approved egress reference set.

·        Destination reputation, rarity, or local threat-intelligence category.

·        CRE building blocks for suspicious API request and unusual egress.

Engineering Implementation Instructions

The local QRadar engineer should implement two CRE building blocks: BuildingBlock_FortiSandbox_Suspicious_API_Request and BuildingBlock_FortiSandbox_Rare_Or_Unapproved_Egress. The engineer must ensure first.destinationip from the inbound request can be correlated to second.sourceip from the outbound egress event. ENV_APPROVED_FORTISANDBOX_EGRESS should be created as a reference set containing approved Fortinet update destinations, detonation paths, vendor support destinations, and documented integration endpoints. Flow, firewall, DNS, and proxy log sources must map destination, destination port, protocol, domain, and reputation or rarity fields. The rule should be deployed first in a monitoring state to baseline normal FortiSandbox egress and detonation traffic. Alert-mode promotion should require validated reference sets, stable building-block matching, SOC triage steps, and acceptable false-positive volume.

DRI Assessment

This rule has strong post-exploitation correlation value when both inbound and outbound telemetry exist.

DRI

8.6 / 10

TCR Assessment

Confidence depends on accurate egress allowlists, FortiSandbox asset identity, and detonation traffic baselines.

Operational TCR

7.9 / 10

Full-Telemetry TCR

9.1 / 10

Limitations

Sandbox-generated egress can create noise without baseline separation.

Detection Query Pattern

WHEN BuildingBlock_FortiSandbox_Suspicious_API_Request MATCHES

FOLLOWED BY BuildingBlock_FortiSandbox_Rare_Or_Unapproved_Egress

WITHIN 30 minutes

WHERE first.destinationip = second.sourceip

AND second.destination NOT IN REFERENCESET('ENV_APPROVED_FORTISANDBOX_EGRESS')

RESPOND WITH high severity offense

GROUP BY fortisandbox_asset, triggering_source, outbound_destination

Rule

Affected FortiSandbox Version Exposure

Rule Format

QRadar vulnerability / asset query pattern

Detection Purpose

Identify FortiSandbox systems still running affected versions.

Detection Logic

Query vulnerability, asset, or scanner data for FortiSandbox versions 4.4.0 through 4.4.8 and prioritize by exposure.

Required Telemetry

·        Vulnerability scanner integration.

·        Asset inventory.

·        Product and vendor fields.

·        Software version.

·        Exposure classification.

·        Asset owner and environment.

·        Scanner freshness timestamp.

Engineering Implementation Instructions

The local QRadar engineer should confirm that QRadar Vulnerability Manager or imported scanner data includes FortiSandbox product names, software version, asset name, IP, owner, and exposure classification. If the local vulnerability table uses different product or version fields, the query should be updated before deployment. Version matching should be validated against known patched and unpatched FortiSandbox systems to avoid matching 4.4.9 or later. Internet-facing and broad-internal exposure should be mapped from attack-surface management, firewall, CMDB, or scanner context. The rule should run on a schedule aligned to vulnerability scanner ingestion. Alert-mode promotion is appropriate after scanner freshness, version parsing, ownership mapping, and remediation workflow routing are validated.

DRI Assessment

This is a preventive exposure-control rule with strong remediation value.

DRI

7.7 / 10

TCR Assessment

Confidence is high when authenticated scanning or Fortinet inventory confirms version.

Operational TCR

8.5 / 10

Full-Telemetry TCR

9.3 / 10

Limitations

Scanner data may lag upgrades. Validate against FortiSandbox administrative inventory.

Detection Query Pattern

SELECT

  assetname,

  ip,

  vulnerabilityname,

  softwareversion,

  exposure,

  owner

FROM vulnerabilities

WHERE LOWER(product) LIKE '%fortisandbox%'

AND softwareversion IMATCHES '^4\.4\.[0-8]$'

LAST 7 DAYS

SIGMA

Detection Viability Assessment

SIGMA is useful for portable detection logic across proxy, HTTP, network, and process backends. Deployment quality depends on backend field mapping, URL decoding, regex support, and FortiSandbox asset tagging. Three rules are included. These rules are production-ready portable detection patterns after backend-specific conversion, field mapping, asset scoping, and exception tuning.

Rule

FortiSandbox Suspicious API Command Injection Attempt

Rule Format

SIGMA HTTP detection pattern

Detection Purpose

Detect suspicious HTTP requests to FortiSandbox API behavior with command-injection indicators.

Detection Logic

Match FortiSandbox tracer-behavior path requests and suspicious query-string or URL patterns associated with command injection.

Required Telemetry

·        Web proxy logs.

·        WAF logs.

·        NDR HTTP logs.

·        URI path and query string.

·        Source IP and destination IP or hostname.

·        User agent.

·        Backend asset enrichment or FortiSandbox destination filter.

·        Approved scanner exception list.

Engineering Implementation Instructions

The local detection engineer should convert this SIGMA logic to the target backend only after confirming that the backend receives FortiSandbox-facing proxy, WAF, or NDR HTTP logs. Backend fields for URL, query, source IP, destination IP, user agent, and asset identity must be mapped explicitly. If the backend does not support regex in the same way as SIGMA, ENV_CMD_INJECTION_META_REGEX should be translated into supported contains, wildcard, or value-list logic. FortiSandbox asset scoping should be added during conversion so the rule does not run against all proxy traffic without destination context. Query-string retention and URL-decoding behavior must be validated in the target backend. Approved scanner and validation sources should be tuned after initial hunt-mode review. The rule should not be enabled as an alert until backend conversion, asset scoping, URL/query visibility, and false-positive handling are confirmed.

DRI Assessment

This rule has strong attempt-detection value where full URL fields exist.

DRI

8.3 / 10

TCR Assessment

Confidence depends on backend URL-field mapping and query-string retention.

Operational TCR

7.6 / 10

Full-Telemetry TCR

8.9 / 10

Limitations

Backends differ in regex support and URL decoding. Validate locally before enabling alert mode.

Detection Query Pattern

title: FortiSandbox Suspicious API Command Injection Attempt

status: test

logsource:

  category: proxy

detection:

  selection_path:

    url|contains: "/fortisandbox/job-detail/tracer-behavior"

  selection_injection_raw:

    url|re: "ENV_CMD_INJECTION_META_REGEX"

  selection_injection_query:

    query|re: "ENV_CMD_INJECTION_META_REGEX"

  filter_approved_scanner:

    src_ip:

      - "ENV_APPROVED_SCANNER_SOURCE_1"

      - "ENV_APPROVED_SCANNER_SOURCE_2"

  condition: selection_path and (selection_injection_raw or selection_injection_query) and not filter_approved_scanner

fields:

  - src_ip

  - dest_ip

  - url

  - query

  - user_agent

falsepositives:

  - Authorized vulnerability scanning

  - Internal validation testing

level: high

Rule

FortiSandbox Unusual Egress From Security Appliance

Rule Format

SIGMA network connection pattern

Detection Purpose

Detect suspicious outbound network activity from FortiSandbox.

Detection Logic

Match FortiSandbox-originated network connections to unapproved destinations, suspicious ports, direct IPs, rare domains, or suspicious-reputation destinations.

Required Telemetry

·        Network connection logs.

·        Source asset identity.

·        Destination IP, port, and domain.

·        Protocol.

·        Approved egress allowlist.

·        Destination reputation or rarity enrichment.

·        Backend asset enrichment.

Engineering Implementation Instructions

The local detection engineer should convert this SIGMA logic only after confirming the target backend receives FortiSandbox-originated network, proxy, firewall, or flow telemetry. FortiSandbox source asset tagging must be implemented during backend conversion through source IP, hostname, asset group, or CMDB enrichment. Approved FortiSandbox egress destinations should be converted into backend-supported lookup, value list, or exception logic. The engineer should validate fields for destination IP, destination port, destination domain, reputation, rarity, and protocol before enabling the rule. Because detonation traffic can produce unusual destinations, the rule should be deployed first in hunt mode and tuned against normal sandbox detonation, vendor updates, and integration behavior. Alert-mode promotion should require source asset scoping, egress allowlists, and false-positive baselines.

DRI Assessment

This rule is useful as a post-exploitation signal when egress is well baselined.

DRI

8.0 / 10

TCR Assessment

Confidence depends on separating detonation traffic from appliance-originated control-plane traffic.

Operational TCR

7.3 / 10

Full-Telemetry TCR

8.7 / 10

Limitations

Sandbox detonation can create unusual traffic. Alerting should be correlation-driven where possible.

Detection Query Pattern

title: FortiSandbox Unusual Egress From Security Appliance

status: test

logsource:

  category: network_connection

detection:

  selection_source:

    source.asset.group: "fortisandbox"

  selection_suspicious_port:

    DestinationPort:

      - 22

      - 4444

      - 8080

      - 8443

  selection_suspicious_reputation:

    destination.reputation:

      - suspicious

      - malicious

      - rare

  filter_approved_domain:

    destination.domain:

      - "ENV_APPROVED_FORTISANDBOX_DOMAIN_1"

      - "ENV_APPROVED_FORTISANDBOX_DOMAIN_2"

  condition: selection_source and (selection_suspicious_port or selection_suspicious_reputation) and not filter_approved_domain

fields:

  - source.ip

  - destination.ip

  - destination.port

  - destination.domain

falsepositives:

  - Malware detonation traffic

  - Approved vendor updates

  - Approved integrations

level: high

Rule

FortiSandbox Web/API Process Spawning Shell Utility

Rule Format

SIGMA process creation pattern

Detection Purpose

Detect FortiSandbox web or API service spawning shell, interpreter, network, or file-transfer utilities where process telemetry exists.

Detection Logic

Match process creation events on FortiSandbox-tagged hosts where a web/API parent process launches suspicious child utilities.

Required Telemetry

·        Process creation events.

·        Parent process name.

·        Process name.

·        Command line.

·        Host identity.

·        FortiSandbox asset tagging.

·        Vendor support or administrative exception logic.

Engineering Implementation Instructions

The local detection engineer should treat this rule as conditional and convert it only if the target backend receives process creation telemetry from the FortiSandbox host layer or an equivalent forwarded source. Host asset tagging must identify FortiSandbox systems through host asset group, hostname, IP, CMDB enrichment, or backend-specific tags. The engineer must map parent image, child image, command line, host name, and user fields to the target backend. Local FortiSandbox web/API parent process names should be identified before alert-mode deployment rather than relying only on placeholders. Vendor support actions and authorized administrative troubleshooting should be converted into exceptions after historical review. The rule should remain in hunt mode until process telemetry availability, parent-process mapping, and expected administrative behavior are validated.

DRI Assessment

This rule has strong confirmation value if available.

DRI

8.8 / 10

TCR Assessment

Operational confidence is limited primarily by appliance telemetry availability.

Operational TCR

7.0 / 10

Full-Telemetry TCR

9.4 / 10

Limitations

Most FortiSandbox appliances may not provide conventional endpoint process telemetry. Treat this as conditional detection logic.

Detection Query Pattern

title: FortiSandbox Web API Process Spawning Shell Utility

status: test

logsource:

  category: process_creation

detection:

  selection_host:

    host.asset.group: "fortisandbox"

  selection_parent:

    ParentImage|contains:

      - "ENV_FORTISANDBOX_WEB_API_PARENT_1"

      - "ENV_FORTISANDBOX_WEB_API_PARENT_2"

  selection_child:

    Image|endswith:

      - "/sh"

      - "/bash"

      - "/python"

      - "/perl"

      - "/curl"

      - "/wget"

      - "/nc"

      - "/ncat"

  condition: selection_host and selection_parent and selection_child

fields:

  - host.name

  - ParentImage

  - Image

  - CommandLine

falsepositives:

  - Vendor support actions

  - Authorized administrative troubleshooting

level: critical

AWS

Detection Viability Assessment

AWS has limited direct detection value for this TTD unless FortiSandbox traffic is routed through AWS WAF, ALB, CloudFront, VPC Flow Logs, Route 53 Resolver logs, or centralized AWS logging. No AWS-native rule should be presented as sufficient proof of FortiSandbox exploitation. Use AWS telemetry only as supporting visibility for HTTP path observation, egress review, and exposure validation where FortiSandbox traffic actually traverses AWS-controlled logging points. The local cloud engineer should document whether FortiSandbox traffic is visible in AWS at all, which AWS log groups contain the relevant HTTP or egress data, whether URI and query strings are retained, and whether FortiSandbox assets can be identified by IP, hostname, target group, load balancer, or routing context. If those conditions are not met, AWS should remain a limited-viability visibility source rather than a rule-bearing detection platform for this TTD.

Azure

Detection Viability Assessment

Azure has limited direct detection value for this TTD unless FortiSandbox traffic is visible through Azure Application Gateway, Azure Firewall, WAF, Sentinel-ingested proxy logs, imported NDR telemetry, or other Azure-controlled logging paths. No Azure-native rule should be presented as sufficient proof of FortiSandbox exploitation. Use Azure primarily for supporting HTTP-path visibility, egress correlation, and Sentinel enrichment where those logs exist. The local cloud engineer should document whether Azure sees FortiSandbox inbound HTTP requests, outbound egress, or relevant routing paths, and should validate URI/query retention, FortiSandbox asset mapping, table names, and field names before creating any local Sentinel rule. If Azure only sees unrelated cloud activity, it should not be used to attribute activity to CVE-2026-39808.

GCP

Detection Viability Assessment

GCP has limited direct detection value for this TTD unless FortiSandbox traffic is visible through Cloud Load Balancing, Cloud Armor, VPC Flow Logs, Cloud DNS, or centralized GCP logging. No GCP-native rule should be presented as sufficient proof of FortiSandbox exploitation. Use GCP telemetry only as supporting visibility for HTTP request observation, egress review, and exposure validation where FortiSandbox traffic actually traverses GCP-controlled logging points. The local cloud engineer should confirm whether GCP logs contain FortiSandbox URI, query, destination, source, DNS, or flow context and should document any visibility gap. If FortiSandbox traffic is not routed through GCP-controlled telemetry, GCP should remain limited-viability coverage only.

S29 Detection Coverage Summary

High-Coverage Areas

·        Suspicious HTTP requests targeting FortiSandbox API behavior.

·        Command-injection indicators in URL or query fields.

·        FortiSandbox unusual egress after suspicious inbound activity.

·        FortiSandbox-originated connections to sensitive internal security or management assets.

·        Continued presence of affected FortiSandbox versions.

Moderate-Coverage Areas

·        Appliance process execution where supported telemetry exists.

·        File writes and persistence changes where appliance or adjacent logging exists.

·        Security-fabric tampering where integration and administrative logs are forwarded.

Low-Coverage Areas

·        In-memory-only execution without process logging.

·        Exploitation through encrypted paths where no proxy, WAF, or NDR HTTP metadata is retained.

·        Successful exploitation without outbound callbacks or file-system changes.

·        Cloud-only anomalies without FortiSandbox exposure and inbound request correlation.

S33 Defensive Control & Hardening Improvements

·        Upgrade FortiSandbox 4.4.0 through 4.4.8 to 4.4.9 or later.

·        Validate that FortiSandbox is not internet-accessible unless explicitly required and strongly controlled.

·        Restrict FortiSandbox API and management access to approved management networks and administrative jump hosts.

·        Limit FortiSandbox reachability to SIEM, SOAR, identity, mail-security, file repositories, management infrastructure, and other security tooling.

·        Enforce FortiSandbox egress controls and allow only required vendor, update, detonation, and integration destinations.

·        Enable FortiSandbox-facing proxy, WAF, reverse proxy, or NDR HTTP logging.

·        Preserve raw and decoded query visibility where legally and operationally acceptable.

·        Forward FortiSandbox administrative, configuration, upgrade, authentication, and service-change logs to the SIEM.

·        Monitor FortiSandbox-originated DNS, proxy, firewall, and flow traffic.

·        Review and rotate integration credentials if suspicious activity is found.

·        Validate sandbox verdicts and submitted-file handling during the exposure window if exploitation is suspected.

·        Add FortiSandbox to critical security-control asset groups for elevated detection and response priority.

S39 Economic Impact & Organizational Exposure

Economic Exposure DRIvers

·        Emergency patching or appliance rebuild.

·        Incident-response labor to determine whether command execution occurred.

·        Review of submitted files, detonation artifacts, and sandbox verdicts.

·        Credential rotation for FortiSandbox integrations.

·        Retrospective hunting across HTTP, proxy, NDR, DNS, firewall, SIEM, and appliance logs.

·        Downtime or reduced trust in malware-analysis workflows.

·        Potential compliance or customer-impact review if submitted artifacts contained sensitive data.

Operational Exposure

The highest operational exposure exists where FortiSandbox is internet-accessible, broadly reachable from internal networks, integrated with privileged security tooling, or used as a central malware-analysis platform for email, endpoint, file-upload, or incident-response workflows.

Current Coverage Count

·        CVEs directly addressed by this TTD: 1.

·        KEV-listed CVEs directly addressed by this TTD: 0.

·        Primary affected product family: Fortinet FortiSandbox.

·        Primary exploit behavior: unauthenticated OS command injection through crafted HTTP requests.

Coverage Qualification

This TTD provides behavior-led coverage for FortiSandbox command-injection attempts, likely post-exploitation egress, appliance-originated pivot behavior, and affected-version exposure. It should not be treated as proof of exploitation unless request telemetry is correlated with process execution, file writes, outbound callbacks, persistence, configuration changes, or incident-response findings.

S40 References

Vendor / Platform Documentation

·        Fortinet FortiGuard PSIRT, FG-IR-26-100, “OS Command Injection through API endpoint.”
hxxps://fortiguard[.]fortinet[.]com/psirt/FG-IR-26-100

Vulnerability Reference

·        NVD, CVE-2026-39808 Detail.
hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-39808

Known Exploitation Status Reference

·        CISA Known Exploited Vulnerabilities Catalog.
hxxps://www[.]cisa[.]gov/known-exploited-vulnerabilities-catalog

Public PoC / Exploit-Readiness Reference

·        GitHub public PoC reference for CVE-2026-39808.
hxxps://github[.]com/0xBlackash/CVE-2026-39808

Threat Technique Framework

MITRE ATT&CK Enterprise Matrix.
hxxps://attack[.]mitre[.]org