[EXP] FortiSandbox Command Injection and Security-Control Compromise Risk

Report Type: Exploitation (EXP)
Threat Category: Command Injection and Security-Control Compromise
Assessment Date: July 16, 2026
Primary Impact Domain: Malware-Analysis and Security-Control Integrity
Secondary Impact Domains: Privileged Access, Credential and Integration-Secret Exposure, Logging and Evidence Degradation, Connected-System Compromise, Cloud Security, and Business Resilience
Affected Asset Class: FortiSandbox Physical Appliances, Virtual Appliances, Cloud and PaaS Deployments, Administrative Interfaces, Analysis Workflows, and Connected Security Systems
Threat Objective Classification: Unauthorized Command Execution, Analysis and Verdict Manipulation, Defensive-Control Degradation, Credential Access, Persistence, and Downstream Expansion

Published by: CyberDax LLC
Author: Edward “Tony” Dolley
Role: Founder / Principal Threat Researcher, CyberDax LLC
Publication Date: July 16, 2026
Publication Type: Cybersecurity Research Report / White Paper

S2 BLUF

‍ ‍FortiSandbox command injection and security-control compromise create material enterprise risk because unauthorized command execution within a trusted malware-analysis platform may allow an adversary to alter appliance configuration, manipulate analysis workflows, suppress threat findings, change verdicts or reports, access credentials and integration secrets, degrade logging and notifications, establish persistence, communicate externally, or misuse trusted connections to downstream security and management systems. The technical risk arises when an adversary reaches a FortiSandbox management, API, service, upload, reporting, analysis, or administrative interface and converts command-injection capability or privileged access into unauthorized control over appliance services, administrators, analysis profiles, sandbox virtual machines, jobs, databases, reports, notifications, integrations, or FortiCloud PaaS settings. Successful compromise may weaken the organization’s ability to trust malware verdicts, submitted-file handling, URL-analysis results, reports, quarantine decisions, alerts, indicators, connected-product actions, and security decisions that depend on FortiSandbox output. Immediate executive action is required to validate FortiSandbox exposure, preserve appliance and remotely forwarded evidence, investigate suspicious interface and administrative activity, verify analysis and reporting integrity, rotate exposed credentials and integration secrets, restrict affected trust relationships, assess connected systems, and restore confidence that the malware-analysis and security-control environment is operating as intended.

Executive Risk Translation

FortiSandbox compromise shifts the business risk from a single vulnerable appliance or malformed request to uncertainty over whether the organization can continue to trust malware-analysis results, threat classifications, reports, quarantine actions, notifications, connected-product decisions, and administrative activity associated with the affected platform. When available evidence cannot reliably distinguish attempted exploitation from successful command execution, legitimate analysis variation from malicious result manipulation, or approved integration activity from misuse of trusted credentials, leadership may need to assume that affected submissions, verdicts, reports, alerts, integrations, and downstream security actions were capable of being altered until proven otherwise. That response may require emergency isolation, credential and certificate rotation, FortiCloud IAM review, analysis-profile validation, submission reprocessing, independent malware analysis, report reconstruction, connected-product investigation, logging restoration, cloud and infrastructure review, legal and compliance assessment, cyber-insurance coordination, customer or partner impact analysis, executive reporting, and formal confirmation that FortiSandbox and its dependent defensive systems can safely return to trusted operation.

S3 — Why This Matters Now

·        FortiSandbox may occupy a high-trust position between untrusted files, URLs, email, network traffic, cloud workloads, endpoint systems, analysts, and connected security platforms.

·        Command injection against a FortiSandbox interface may convert a single crafted request into unauthorized appliance or service activity without requiring a conventional interactive administrative session.

·        Successful execution may occur through web services, APIs, application components, workers, analysis services, queues, helper utilities, or privileged system contexts.

·        Command execution may be blind, delayed, asynchronous, encoded, fragmented, short-lived, or limited to appliance-local changes that do not produce an obvious response or external callback.

·        An adversary may alter analysis profiles, sandbox-VM assignments, detonation behavior, submission handling, rescans, threat classifications, verdict generation, reports, quarantine actions, notifications, or result delivery.

·        Manipulated findings may cause malicious files or URLs to be treated as safe, legitimate content to be treated as malicious, or downstream controls to make incorrect enforcement decisions.

·        Compromise may expose administrator credentials, API keys, access tokens, certificates, SSH keys, mail credentials, cloud settings, storage settings, service accounts, or trusted-integration secrets.

·        FortiSandbox-derived credentials or trusted integrations may provide access to Fortinet products, SIEM, SOAR, endpoint, email, cloud, storage, management, analysis, orchestration, or other security systems.

·        Logging reduction, report deletion, forwarding interruption, CLI-history disablement, kernel-logging disablement, notification suppression, or event manipulation may reduce the organization’s ability to reconstruct the incident.

·        A compromised FortiSandbox platform may remain operational while selectively manipulating one submission, analysis job, virtual machine, threat finding, verdict, report, notification, or integration.

·        Malware-detonation traffic may resemble malicious appliance communication, making it difficult to distinguish compromise from expected sandbox activity without strong architectural separation and attribution.

·        Physical appliances, virtual appliances, clustered deployments, cloud-hosted systems, and FortiSandbox PaaS environments may expose materially different evidence and response options.

·        FortiSandbox PaaS investigations may depend on customer-accessible FortiCloud IAM, API, service-status, integration, job, administrative, cloud, and vendor-support evidence rather than direct operating-system telemetry.

·        Local FortiSandbox logs may rotate before suspicious activity is identified, and locally retained reports may expire before the investigation establishes that analysis integrity was affected.

·        Patching, service restoration, or appliance replacement cannot determine whether command execution, credential access, analysis manipulation, or downstream integration abuse occurred before remediation.

·        Detection based only on CVE identifiers, vulnerable versions, proof-of-concept strings, static request patterns, administrator logins, service faults, unusual verdicts, or rare outbound destinations cannot provide durable assurance.

S4 — Key Judgments

·        FortiSandbox command injection should be treated as a security-control integrity, malware-analysis trust, privileged-access, connected-system, and business-resilience risk, not only as a vulnerability-management or appliance-management issue.

·        The primary enterprise risk is reduced ability to determine whether FortiSandbox analysis results, verdicts, reports, alerts, quarantine decisions, notifications, and connected-product actions remained trustworthy after suspected compromise.

·        A command-like request does not prove command execution, but suspicious interface activity followed by unexpected CLI, kernel, system, service, configuration, file, process, or outbound-network behavior provides materially stronger evidence of probable execution.

·        Probable command execution followed by identity, credential, logging, update, database, integration, persistence, or sustained system-level activity should be treated as probable appliance or service compromise.

·        Appliance or service compromise becomes analysis-control compromise when it affects submission handling, scan flow, virtual-machine behavior, analysis jobs, rescans, findings, verdicts, reporting, quarantine, notification, or result delivery.

·        Security-control compromise occurs when manipulated FortiSandbox behavior, credentials, integrations, findings, verdicts, or reports weaken or misdirect connected defensive systems.

·        Downstream compromise becomes materially more likely when FortiSandbox-derived credentials, trusted identities, certificates, tokens, integrations, reports, or outputs are used to modify connected systems, suppress alerts, distribute unsafe results, establish persistence, or expand access.

·        A completed analysis job, apparently valid verdict, successful report generation, or functioning appliance does not prove that the submission path, profile, virtual-machine assignment, threat record, database state, report, or delivery path remained trustworthy.

·        Missing process, shell, command-line, file, kernel, or diagnostic telemetry cannot be treated as proof that execution did not occur when those sources were unsupported, disabled, rotated, unavailable, or inaccessible.

·        Business exposure increases sharply when FortiSandbox supports broad Security Fabric relationships, privileged APIs, sensitive malware submissions, email or endpoint enforcement, regulated workloads, cloud-hosted infrastructure, customer environments, or high-trust defensive decision-making.

·        Credential rotation and patching may be necessary but may not be sufficient when an attacker could have created new administrators, modified trust, changed connected systems, altered reports, established persistence, or distributed manipulated results.

·        Rebuilding or replacing the appliance may create false closure unless the organization also validates analysis integrity, reprocesses high-risk submissions, reconstructs reports, reviews connected-system actions, rotates integration secrets, and removes downstream persistence.

·        Incomplete remote logging, short report retention, missing request metadata, weak appliance attribution, shared NAT, inconsistent event normalization, undocumented integrations, and absent change records increase response cost because the organization may need to investigate a broader population of submissions, systems, users, credentials, and defensive actions.

·        The most damaging outcome occurs when FortiSandbox compromise enables malicious content to evade detection, security controls to be weakened, credentials or trusted integrations to be abused, connected systems to be modified, sensitive data to be exposed, or enterprise response decisions to be based on manipulated evidence.

S5 — Executive Risk Summary

Business Risk

FortiSandbox command injection and security-control compromise can weaken the organization’s ability to trust malware-analysis results and the defensive decisions that depend on them. Risk increases when FortiSandbox receives files or URLs from email systems, endpoints, network controls, cloud environments, storage platforms, business applications, customer systems, regulated workloads, or security operations and then distributes verdicts, indicators, reports, quarantine actions, or automated decisions to connected platforms. The business impact is not limited to the appliance or service where command execution occurred; it can expand into uncertainty over whether malicious content was incorrectly classified, defensive actions were suppressed, legitimate content was disrupted, reports were altered, credentials were exposed, connected systems were changed, alerts were redirected, or adversaries used trusted security infrastructure to establish persistence or expand access.

Technical Cause

The risk is driven by unauthorized command execution or privileged control within a FortiSandbox appliance, virtual deployment, cluster, cloud-hosted system, or PaaS environment. The enabling path may involve an exposed management or service interface, malformed or encoded request, vulnerable application component, API, upload function, reporting interface, analysis service, worker, queue, privileged administrative path, compromised account, stolen session, trusted host, certificate, access token, API identity, service account, or integration credential. Technical exposure becomes material when suspicious interface or administrative activity aligns with CLI or kernel activity, service manipulation, configuration changes, administrator changes, analysis-profile modification, virtual-machine changes, job disruption, finding suppression, database activity, report alteration, logging degradation, credential access, rare outbound communication, persistence, or connected-system changes. Exposure increases when request telemetry, local and remote logs, CLI history, kernel logging, configuration records, submission history, job and virtual-machine events, threat findings, report history, notification evidence, destination baselines, identity records, cloud logs, and change-management evidence are incomplete.

Threat Posture

The threat posture is elevated because a compromised FortiSandbox platform may provide an adversary with both privileged system access and influence over security decisions made elsewhere in the environment. Malicious activity may originate from an external source, internal network, management segment, VPN, reverse proxy, trusted administrator system, connected Fortinet product, cloud service, vendor-support path, or compromised integration. The posture becomes critical when FortiSandbox has access to sensitive submissions, privileged APIs, Security Fabric relationships, endpoint or email enforcement, cloud infrastructure, SIEM or SOAR workflows, security-management systems, storage platforms, administrative portals, or customer-facing analysis services. The threat may remain active after patching, service restart, password reset, or appliance replacement if stolen credentials, certificates, tokens, API access, connected-system persistence, manipulated reports, altered trust relationships, or false-safe verdicts remain in use.

Executive Decision Requirement

Executives must require measurable assurance that every FortiSandbox physical appliance, virtual appliance, cluster, PaaS instance, tenant, region, management interface, service interface, API, externally reachable endpoint, administrative path, analysis profile, virtual machine, submission source, report store, credential, certificate, token, and connected integration is inventoried and assessed. Leadership should require validation of suspicious request history, administrator and FortiCloud IAM activity, CLI and kernel evidence where available, configuration changes, analysis jobs, virtual-machine behavior, threat findings, database activity, report integrity, logging and notification health, outbound communication, integration-secret access, connected-system actions, and cloud-control changes. When compromise cannot be ruled out, executives must be prepared to authorize appliance or service isolation, emergency patching or replacement, credential and certificate rotation, integration suspension, session invalidation, independent reanalysis of high-risk submissions, report reconstruction, connected-product review, cloud and infrastructure investigation, persistence removal, legal and compliance escalation, customer or partner impact analysis, and broader restoration of trust across the defensive environment. Leadership should also require evidence that security operations, incident response, malware analysis, network security, cloud, identity, endpoint, email, infrastructure, application, legal, privacy, communications, cyber-insurance, and business owners can support a coordinated response.

S6 — Executive Cost Summary

FortiSandbox command injection and security-control compromise create financial exposure because the organization must determine whether suspicious requests resulted in unauthorized execution, whether appliance or service state changed, whether analysis workflows were manipulated, whether malware findings or reports remained trustworthy, whether credentials or integration secrets were accessed, and whether connected defensive systems were altered. The cost profile is different from a routine appliance patch, service restart, or configuration correction because FortiSandbox may sit within a broader decision chain that affects email, endpoint, network, cloud, SIEM, SOAR, storage, security management, and incident-response operations. A single compromise condition can therefore require investigation across the FortiSandbox deployment, reverse proxies, firewalls, load balancers, VPNs, administrative systems, FortiCloud, cloud infrastructure, connected Fortinet products, third-party security platforms, malware-analysis workflows, business applications, and customer or partner environments.

Response cost is driven by the work required to validate affected interfaces and deployment models, reconstruct suspicious requests, preserve local and remotely forwarded logs, review administrator and FortiCloud IAM activity, inspect CLI and kernel evidence where available, validate services and configuration, compare known-good appliance state, investigate submissions and analysis jobs, inspect virtual-machine assignments, validate threat findings, examine databases and reports, review notification delivery, analyze outbound communication, rotate credentials and integration secrets, suspend or rebuild affected trust relationships, reprocess high-risk files and URLs, independently validate prior verdicts, investigate connected systems, remove persistence, and prove that the malware-analysis and defensive-control environment has been restored.

Cost increases materially when local logs have rotated, report retention has expired, request bodies or parameters were not retained, appliance-management traffic cannot be separated from malware-detonation traffic, shared NAT prevents attribution, administrators or service accounts are shared, CLI or kernel logging was disabled, event forwarding was incomplete, PaaS evidence is limited, analysis and report history cannot be reconstructed, connected products do not retain the originating FortiSandbox identity, integration secrets are broadly privileged, or third-party platform owners cannot rapidly preserve evidence and validate activity. The highest-cost cases occur when affected FortiSandbox systems support broad Security Fabric relationships, customer-facing analysis, regulated submissions, email or endpoint enforcement, cloud environments, security orchestration, privileged management, backup or storage systems, sensitive intellectual property, critical business applications, or large populations of connected systems.

Low Impact Scenario

Rapid investigation confirms a vulnerable, exposed, misconfigured, or targeted FortiSandbox system without evidence of successful unauthorized command execution, appliance-state modification, credential access, analysis manipulation, logging degradation, persistence, suspicious outbound communication, or downstream integration abuse. Suspicious requests were blocked, rejected, unsuccessful, or unsupported by correlated native events, configuration changes, service behavior, job or virtual-machine anomalies, report changes, threat-finding inconsistencies, or connected-system activity. FortiSandbox, proxy, firewall, DNS, cloud, administrator, change-management, and connected-product records support a failed, contained, approved, or non-impacting event. Response is limited to targeted patching, exposure reduction, configuration validation, access restriction, logging improvement, focused hunting, evidence preservation, credential review, short-term enhanced monitoring, and executive assurance that analysis and security-control integrity were not materially affected. Estimated impact $500K - $3M.

Moderate Impact Scenario

Confirmed or strongly suspected unauthorized command execution affects one or more FortiSandbox appliances, virtual systems, cluster nodes, PaaS instances, analysis services, administrative paths, or trusted integrations. Evidence may include suspicious requests followed by CLI or kernel activity, service manipulation, configuration changes, administrator changes, job or virtual-machine disruption, report modification, threat-finding inconsistency, logging degradation, credential access, unusual egress, or connected-system activity. The organization cannot immediately determine which submissions, verdicts, reports, credentials, integrations, or downstream defensive actions were affected. Response requires enterprise-focused appliance and service investigation, credential and certificate rotation, FortiCloud IAM review, configuration comparison, report and analysis reconstruction, independent reanalysis of high-risk submissions, integration validation, connected-product investigation, cloud and infrastructure review, logging restoration, legal and compliance review, cyber-insurance coordination, executive reporting, and strengthened monitoring for continued activity. Estimated impact $5M - $35M.

High Impact Scenario

FortiSandbox compromise becomes an enterprise-impact event when confirmed or suspected command execution results in broad analysis manipulation, false-safe verdicts, malicious-file distribution, security-control degradation, credential or integration-secret theft, persistent administrative access, connected-system compromise, cloud-control changes, sensitive-submission exposure, customer or regulated data exposure, destructive activity, ransomware enablement, or widespread defensive failure. The organization may need to assume that files, URLs, verdicts, reports, indicators, quarantine actions, alerts, credentials, integrations, cloud resources, and connected security decisions associated with the affected deployment were exposed or unreliable until evidence proves otherwise. Response may require emergency isolation or replacement of FortiSandbox systems, broad credential and certificate rotation, suspension of integrations, reanalysis of historical submissions, reconstruction of threat findings and reports, connected-product shutdown or restriction, cloud-role limitation, forensic investigation, persistence removal, customer or partner notification analysis, privacy and regulatory escalation, cyber-insurance engagement, communications planning, executive and board reporting, and formal validation that the defensive-control environment can safely return to operation. Estimated impact $40M - $200M+.

S6A — Key Cost Drivers

·        Number and sensitivity of affected FortiSandbox physical appliances, virtual appliances, clusters, PaaS instances, tenants, regions, administrative systems, reverse proxies, load balancers, firewalls, VPNs, cloud resources, and connected security platforms.

·        Scope of exposed management, API, service, upload, reporting, analysis, administrative, diagnostic, or service-to-service interfaces.

·        Number of suspicious requests, affected sessions, source systems, administrative identities, API clients, trusted hosts, service accounts, FortiCloud IAM users, certificates, access tokens, SSH keys, and integration identities requiring validation.

·        Availability and retention of FortiSandbox Input, System, Job, VM, Threat, Database, Report, Performance, Resource, HA, Notification, SNMP, administrator, authentication, configuration, API, CLI-history, kernel, cloud, proxy, firewall, DNS, flow, and connected-product telemetry.

·        Ability to identify the exact deployment, appliance, node, tenant, region, source IP, request path, method, parameter, session, administrator, IAM user, API identity, service, action, status, message identifier, job, virtual machine, sample, URL, report, destination, and event time associated with suspicious activity.

·        Ability to distinguish expected sample-analysis traffic from appliance-management, service, integration, administrative, or attacker-controlled communication.

·        Ability to distinguish approved maintenance, upgrades, vendor support, troubleshooting, content updates, virtual-machine changes, database maintenance, report administration, integration changes, migration, backup, recovery, and incident response from attacker-driven activity.

·        Availability of known-good configuration exports, identity inventories, certificate inventories, trusted-host records, service state, analysis profiles, virtual-machine assignments, content versions, database state, report history, logging state, notification settings, and integration mappings.

·        Number and sensitivity of files, URLs, email messages, network objects, cloud workloads, customer submissions, regulated data sets, intellectual-property artifacts, credentials, or business records processed during the suspected compromise period.

·        Number of analysis profiles, sandbox virtual machines, engines, content versions, submission paths, job workflows, rescan processes, verdict mechanisms, report stores, quarantine workflows, and result-delivery channels requiring validation.

·        Number of historical submissions and threat findings requiring reprocessing, independent analysis, report reconstruction, or comparison with endpoint, network, email, threat-intelligence, and third-party sandbox evidence.

·        Scope of administrator, FortiCloud IAM, API, certificate, token, SSH-key, mail, storage, cloud, update, logging, and service-account credentials accessible to the affected deployment.

·        Complexity of rotating credentials, certificates, tokens, API keys, service accounts, trusted hosts, mail credentials, storage credentials, cloud credentials, and integration secrets without disrupting defensive operations.

·        Number and privilege level of connected systems, including FortiGate, FortiManager, FortiAnalyzer, FortiMail, FortiWeb, SIEM, SOAR, endpoint security, email security, cloud security, storage platforms, identity systems, hypervisors, backup systems, code repositories, deployment platforms, and administrative portals.

·        Need to review policy changes, trust changes, exclusions, allowlists, quarantine actions, alert suppression, logging changes, credential creation, administrator activity, cloud changes, automation actions, and data access across connected platforms.

·        Extent of logging reduction, event deletion, report deletion, remote-forwarding interruption, notification suppression, timestamp inconsistency, or evidence loss caused by short retention or local rotation.

·        Need to validate FortiSandbox PaaS activity through FortiCloud IAM, API, service-status, integration, job, cloud, administrative, support, and vendor-provided evidence.

·        Business disruption caused by appliance isolation, integration suspension, email or endpoint enforcement changes, delayed malware analysis, manual review, reanalysis queues, report unavailability, cloud restrictions, administrative freezes, or temporary distrust of automated defensive decisions.

·        Dependence on Fortinet, cloud providers, managed-service providers, third-party security vendors, partners, customers, and application owners to preserve evidence, rotate credentials, validate integrations, reconstruct activity, or restore services.

·        Legal, privacy, regulatory, contractual, cyber-insurance, communications, customer, partner, executive, or board-level obligations triggered by security-control failure, sensitive-submission exposure, malicious-content misclassification, connected-system compromise, incomplete containment, or inability to prove analysis integrity.

S6B — Compliance and Risk Context

Figure 1

FortiSandbox command injection and security-control compromise executive risk model showing how suspicious interface activity can progress into probable command execution, appliance or service compromise, analysis-control manipulation, credential or integration-secret exposure, logging degradation, manipulated findings or reports, trusted-integration abuse, downstream security-control compromise, data exposure, operational disruption, and enterprise-level financial and regulatory impact.

Compliance Exposure Indicator

High

Risk Register Entry

Risk Title

FortiSandbox Command Injection and Security-Control Compromise Risk

Risk Description

Adversaries may obtain unauthorized command execution or privileged control through exposed or vulnerable FortiSandbox management, API, service, upload, reporting, analysis, administrative, worker, queue, or trusted-access paths. Successful compromise may allow modification of appliance configuration, administrators, services, analysis profiles, virtual-machine assignments, submission handling, scan flow, rescans, threat findings, verdicts, databases, reports, quarantine actions, notifications, logging, credentials, certificates, tokens, APIs, and integrations. Manipulated FortiSandbox outputs or stolen trusted credentials may weaken or misdirect connected Fortinet products, SIEM, SOAR, endpoint, email, cloud, storage, management, and other defensive systems. This may increase business interruption, security-control failure, malware exposure, credential compromise, cloud or infrastructure compromise, sensitive-submission exposure, legal and compliance review, customer or partner notification analysis, cyber-insurance scrutiny, and board-level concern. Compliance exposure should be driven by local evidence of suspicious interface activity, probable execution, unauthorized state change, analysis manipulation, credential access, logging degradation, unusual egress, connected-system activity, data access, persistence, or operational impact, not by vulnerable-version status, CVE association, public exploitation reporting, command-like input, isolated faults, administrator activity, verdict differences, or rare destinations alone.

Likelihood

High

Impact

Severe

Risk Rating

Critical

Annualized Risk Exposure

Estimated annualized exposure of $6M - $45M+ for materially exposed enterprise environments where FortiSandbox supports high-volume malware analysis, sensitive submissions, email or endpoint enforcement, cloud workloads, privileged Security Fabric connections, SIEM or SOAR automation, customer-facing services, regulated environments, or broad defensive-control integration and where exposed interfaces, incomplete request telemetry, short local-log retention, limited report retention, weak traffic separation, broad administrative access, privileged integration credentials, undocumented dependencies, incomplete PaaS visibility, or inconsistent connected-system attribution increase both incident likelihood and response burden. A realized severe event may exceed $40M - $200M+ when FortiSandbox compromise results in manipulated malware verdicts, distribution of unsafe results, broad security-control degradation, persistent credential or integration abuse, cloud or infrastructure compromise, sensitive-submission exposure, customer or partner impact, operational disruption, ransomware or destructive activity, widespread connected-system compromise, incomplete restoration of trust, legal escalation, regulatory reporting, cyber-insurance review, communications response, or board-level intervention.

S7 — Risk Drivers

·        FortiSandbox may function as a central analysis and trust provider for email, endpoint, network, cloud, storage, SIEM, SOAR, incident-response, and security-management workflows.

·        The platform may process untrusted files, URLs, archives, documents, scripts, executables, email attachments, cloud objects, and other content while operating with trusted access to defensive infrastructure.

·        Exposed management, API, service, upload, reporting, analysis, or administrative interfaces may provide a path from crafted input to privileged appliance or service activity.

·        Command injection may execute through application components, web services, APIs, workers, queues, analysis services, helper utilities, or privileged system contexts.

·        Blind or asynchronous execution may produce no direct output, obvious error, interactive shell, malware download, or persistent process.

·        Short-lived commands may be sufficient to access configuration, credentials, certificates, tokens, reports, databases, logging settings, or integration information.

·        FortiSandbox may remain operational while one submission, job, virtual machine, finding, verdict, report, notification, or integration is selectively manipulated.

·        An adversary may suppress or reclassify threat findings, alter verdicts, modify reports, change quarantine actions, redirect notifications, or interfere with result delivery.

·        False-safe results may cause malicious content to bypass downstream security controls or receive trusted distribution through established workflows.

·        False-malicious results may disrupt business operations, quarantine legitimate content, increase analyst workload, or undermine trust in automated controls.

·        Administrator accounts, remote users, FortiCloud IAM users, API identities, certificates, tokens, SSH keys, trusted hosts, service accounts, and integration credentials may provide persistence or downstream access.

·        Connected products may accept FortiSandbox-derived actions, findings, reports, indicators, or credentials without independently validating the integrity of the originating analysis.

·        FortiSandbox-originated access may appear legitimate because it uses approved IP addresses, familiar integrations, trusted certificates, standard APIs, expected protocols, or privileged service identities.

·        Malware-detonation traffic may resemble attacker-controlled callbacks, downloads, tunneling, or command-and-control communication.

·        Shared NAT, proxying, service-to-service architecture, cloud routing, and multi-tenant PaaS infrastructure may obscure the source of suspicious activity.

·        Local logs may rotate, reports may expire, and low-level process, shell, memory, syscall, or file telemetry may not be available through standard customer-accessible logging.

·        Attackers may disable or reduce CLI history, kernel logging, remote forwarding, report retention, notifications, SNMP delivery, or administrator auditing.

·        Physical appliances, virtual systems, clustered deployments, cloud-hosted deployments, and PaaS environments may require different evidence, containment, and recovery methods.

·        Patching or restoring appliance availability cannot prove that credentials were not stolen, reports were not altered, malicious content was not misclassified, or downstream systems were not modified.

·        Business exposure increases when FortiSandbox supports regulated data, customer submissions, sensitive intellectual property, privileged security administration, cloud infrastructure, email protection, endpoint enforcement, backup systems, or critical incident-response decisions.

·        Security-control failure, credential exposure, manipulated evidence, malicious-content escape, connected-system compromise, operational disruption, and incomplete containment can transform an appliance incident into legal, regulatory, communications, cyber-insurance, customer, partner, executive, and board-level exposure.

S8 — Bottom Line for Executives

FortiSandbox command injection and security-control compromise should be treated as a high-priority security-control integrity, malware-analysis trust, privileged-access, connected-system, and business-resilience risk because unauthorized command execution can allow an adversary to manipulate the platform that the organization uses to identify, classify, report, and respond to malicious content. The executive question is not only whether FortiSandbox was patched, whether a crafted request was observed, whether an administrator account changed, whether a service restarted, whether a report differed, or whether an unusual outbound connection occurred; it is whether the organization can prove that appliance and service control remained intact, analysis workflows were not manipulated, findings and reports remained trustworthy, credentials and integrations were not exposed, logging was not degraded, and suspicious activity did not lead to downstream security-control changes, persistent access, sensitive-submission exposure, or broader compromise. Response must focus on validating suspicious interface activity, preserving remote and local evidence, reviewing administrative and FortiCloud IAM actions, verifying analysis and report integrity, rotating credentials and integration secrets, reprocessing high-risk submissions, investigating connected systems, removing persistence, and confirming that defensive trust has been restored before leadership relies on affected FortiSandbox outputs or integrations.

S9 — Board-Level Takeaway

FortiSandbox compromise becomes a board-level issue when an adversary can convert access to a malware-analysis interface, administrative path, API, trusted identity, or integration into control over the organization’s security decision-making and connected defensive infrastructure. The risk is not simply that a FortiSandbox vulnerability existed, a command-like request reached the platform, an appliance required patching, a service failed, a report changed, or an outbound destination appeared unusual; it is the possibility that adversaries manipulated threat findings, caused malicious content to be treated as safe, exposed sensitive submissions, stole trusted credentials, weakened downstream controls, suppressed evidence, established persistence, or expanded through connected systems while operating through a platform intended to protect the enterprise. Leadership should require evidence that asset inventory, interface restrictions, administrative governance, FortiCloud IAM controls, request logging, remote log preservation, CLI and kernel evidence where available, analysis-profile governance, virtual-machine integrity, job and report history, credential management, integration mapping, cloud visibility, connected-system auditing, independent reanalysis, incident-response readiness, legal readiness, communications planning, and business-continuity procedures can support rapid and defensible decisions when FortiSandbox trust cannot be confirmed.

S10 — Threat Overview

FortiSandbox command injection and security-control compromise describe adversary behavior in which unauthorized interaction with a FortiSandbox management, API, service, upload, reporting, analysis, or administrative interface may be converted into command execution, appliance or service compromise, analysis-pipeline manipulation, credential or integration-secret exposure, logging degradation, persistence, suspicious outbound communication, or downstream defensive-control abuse. The activity may begin through an externally reachable interface, internal management path, reverse proxy, VPN, trusted administrator system, compromised API client, connected product, cloud service, FortiCloud account, or another path capable of reaching a privileged FortiSandbox function. Multiple vulnerabilities, access conditions, stolen identities, authorization weaknesses, administrative compromises, and service exposures may produce this behavior, but the durable enterprise risk is broader than any single CVE identifier, proof-of-concept implementation, request string, command, interface path, or affected version.

·        This is not only a vulnerable-version, CVE, KEV, proof-of-concept, scanner, request-string, command-string, administrator-login, service-fault, verdict-anomaly, or rare-destination model.

·        The core threat behavior is suspicious interaction with a FortiSandbox interface followed by probable unauthorized command execution, appliance or service modification, analysis-control manipulation, credential access, security-control weakening, or downstream trusted-system activity.

·        FortiSandbox physical appliances, virtual appliances, clusters, PaaS instances, management interfaces, service interfaces, APIs, administrative paths, analysis services, workers, queues, virtual machines, and connected systems represent the primary compromise surface.

·        Email, endpoint, network, cloud, storage, SIEM, SOAR, Security Fabric, malware-analysis, and security-management platforms represent the primary downstream trust surface.

·        A successful HTTP response does not prove exploitation, and a failed response does not prove that command execution was unsuccessful.

·        Command injection may be blind, delayed, encoded, fragmented, asynchronous, short-lived, or executed through a privileged background service without producing an interactive shell or obvious malware artifact.

·        A completed analysis job, apparently valid verdict, generated report, functioning appliance, or successful notification does not prove that the analysis path or resulting security decision remained trustworthy.

·        Compromise may remain limited to temporary execution, configuration access, credential collection, logging changes, analysis manipulation, report modification, or trusted-integration abuse without causing broad appliance instability.

·        The primary enterprise risk is reduced ability to determine whether suspicious activity remained limited to an attempted exploit or approved administration or progressed into appliance compromise, security-control manipulation, and downstream access.

·        Suspected FortiSandbox compromise creates uncertainty around submitted files and URLs, threat findings, verdicts, reports, quarantine actions, notifications, credentials, APIs, integrations, connected security systems, and incident-response decisions.

·        Patching, service restart, administrator-password reset, appliance replacement, or exposure reduction may not contain or disprove compromise when credentials, certificates, tokens, integrations, manipulated outputs, or downstream persistence remain active.

·        Public reporting on individual vulnerabilities, active exploitation, proof-of-concept availability, or KEV inclusion should increase urgency without narrowing the assessment into a single-CVE, actor, exploit-artifact, or indicator-only model.

S11 — Threat Classification and Type

Threat Type

FortiSandbox command injection and security-control compromise risk.

Threat Sub-Type

Unauthorized management or service-interface access, command injection, application or worker execution, privileged service-context abuse, appliance configuration modification, administrator or FortiCloud IAM manipulation, credential and integration-secret access, API or certificate misuse, analysis-profile alteration, virtual-machine assignment manipulation, submission-flow interference, job disruption, threat-finding suppression or reclassification, verdict manipulation, database modification, report alteration or deletion, quarantine interference, logging and notification degradation, persistence, suspicious outbound communication, trusted-integration abuse, downstream security-control modification, sensitive-submission exposure, and enterprise expansion.

Operational Classification

Public-facing or trusted-path service exploitation, privileged appliance execution, malware-analysis control compromise, defensive-control integrity loss, trusted-integration abuse, credential-enabled downstream access, and enterprise security-management compromise pathway.

Primary Function

Obtain unauthorized execution or privileged control within FortiSandbox and use that access to modify appliance or service state, manipulate malware-analysis and reporting functions, expose credentials or trusted integrations, suppress or redirect evidence, establish persistent access, communicate with attacker-controlled or unauthorized systems, and influence or compromise connected security, cloud, email, endpoint, storage, management, or orchestration platforms while creating uncertainty around analysis integrity, defensive decisions, containment completeness, and enterprise trust.

S12 — Campaign or Activity Overview

Figure 2

FortiSandbox command injection and security-control compromise activity model showing suspicious interface access, probable unauthorized command execution, appliance or service compromise, analysis-pipeline manipulation, credential or integration-secret access, logging degradation, manipulated findings or reports, suspicious outbound communication, trusted-integration abuse, and possible downstream security-control compromise.

This report assesses FortiSandbox command injection and security-control compromise as a durable behavior class rather than a single vulnerability, exploit release, malformed request, affected version, administrative event, proof-of-concept repository, actor cluster, or patch event. The core activity pattern begins with suspicious or unauthorized interaction with a FortiSandbox interface, may progress through command execution and privileged appliance activity, and may result in configuration modification, analysis-control manipulation, credential exposure, evidence suppression, persistence, outbound communication, or trusted access to connected systems. Successful compromise may then enable one or more conditional downstream behaviors, including false-safe or false-malicious verdict production, report manipulation, alert suppression, connected-product changes, credential creation, cloud or management access, sensitive-submission exposure, or lateral expansion.

·        The activity is best understood as a security-control integrity, malware-analysis trust, privileged-access, connected-system, cloud-security, and business-resilience threat rather than a routine patch-management or appliance-maintenance issue.

·        The initial access method may vary and is not required to be fully established for the command-execution and security-control-compromise behavior model to remain valid.

·        Adversaries may reach FortiSandbox through internet-facing services, internal management networks, reverse proxies, load balancers, VPNs, trusted hosts, administrative workstations, APIs, service-to-service connections, connected Fortinet products, cloud infrastructure, or compromised support paths.

·        Exploit activity may involve command delimiters, encoded metacharacters, substitutions, interpreter fragments, redirection operators, malformed parameter structures, functionally inconsistent values, repeated request variation, or blind-execution timing behavior.

·        Activity may remain limited to malformed requests, blocked attempts, service faults, temporary instability, failed administration, unexpected native events, or unconfirmed command execution.

·        Probable execution is indicated when suspicious request activity is followed by unexpected CLI, kernel, process, service, system, configuration, file, or outbound-network behavior associated with the same deployment.

·        Appliance or service compromise is indicated when probable execution is followed by unauthorized administrator, authentication, credential, configuration, logging, persistence, update, database, or integration activity.

·        Analysis-control compromise may involve changes to submission handling, analysis profiles, virtual-machine assignments, scan flow, rescans, threat findings, verdict generation, reports, quarantine actions, notifications, or result delivery.

·        Analysis manipulation may be selective and limited to one file, URL, job, virtual machine, finding, verdict, report, notification, or integration while the broader platform continues to operate.

·        Credential access may involve appliance administrators, remote users, FortiCloud IAM identities, service accounts, API keys, tokens, certificates, SSH keys, mail credentials, storage credentials, cloud settings, or trusted-integration secrets.

·        Evidence suppression may involve local log deletion, report deletion, remote-forwarding interruption, CLI-history disablement, kernel-logging disablement, notification suppression, SNMP changes, timestamp manipulation, or short-retention exploitation.

·        Outbound activity may include DNS lookups, callbacks, downloads, raw-IP communication, file transfer, cloud-storage use, tunneling, or communication with rare or unapproved destinations.

·        Downstream activity may involve Fortinet products, SIEM, SOAR, endpoint, email, cloud, storage, analysis, identity, hypervisor, backup, deployment, code, or management platforms.

·        FortiSandbox PaaS activity may involve FortiCloud IAM users, mapped access profiles, secondary accounts, tenants, regions, APIs, service settings, cloud control planes, and vendor-managed service evidence.

·        Actor names, exploit names, CVE references, KEV status, public proof-of-concept releases, source infrastructure, request values, commands, hashes, filenames, or isolated native events should enrich the assessment rather than replace local behavior-led evidence.

S13 — Targets and Exposure Surface

The exposure surface includes FortiSandbox physical appliances, virtual appliances, clustered deployments, cloud-hosted systems, and PaaS environments where unauthorized interface access or administrative control could lead to command execution, analysis manipulation, credential exposure, or trusted-integration abuse. It also includes every submission source, analyst workflow, administrative path, virtual machine, report repository, credential, cloud resource, and connected defensive system that depends on the affected FortiSandbox deployment.

·        FortiSandbox physical appliances, virtual appliances, cluster nodes, HA systems, PaaS instances, tenants, regions, management networks, service networks, administrative interfaces, APIs, upload functions, reporting functions, analysis services, diagnostic functions, and externally reachable endpoints.

·        Reverse proxies, load balancers, web-application firewalls, firewalls, VPNs, trusted hosts, jump systems, privileged-access platforms, management systems, vendor-support paths, and remote-administration workflows capable of reaching FortiSandbox.

·        FortiSandbox web services, application components, background workers, queues, controllers, daemons, helper utilities, system services, databases, report services, notification services, update services, and privileged execution contexts.

·        Appliance administrators, remote-authentication users, FortiCloud IAM users, mapped access profiles, secondary accounts, API identities, integration identities, service accounts, support accounts, maintenance accounts, certificates, tokens, SSH keys, trusted hosts, and authentication mappings.

·        Analysis profiles, sandbox virtual machines, VM assignments, detonation settings, submission routes, scan flows, rescans, malware engines, URL-analysis functions, threat findings, verdict logic, quarantine actions, report generation, notification delivery, and result-distribution workflows.

·        Input sources including direct uploads, URL submissions, network shares, ICAP clients, BCC adapters, MTA adapters, email systems, endpoint systems, network controls, cloud services, storage platforms, connected products, APIs, and automated submission workflows.

·        Submitted executables, documents, archives, scripts, URLs, email attachments, network objects, cloud objects, customer samples, regulated information, intellectual property, credentials, internal tools, and other sensitive analysis content.

·        System, Job, VM, Threat, Database, Report, Performance, Resource, HA, Notification, SNMP, administrative, authentication, configuration, update, integration, logging, CLI-history, and kernel telemetry.

·        Local log stores, remote syslog destinations, FortiAnalyzer, FortiAnalyzer Cloud, SIEM platforms, report stores, backup systems, exported reports, configuration backups, evidence repositories, and retention workflows.

·        DNS, NTP, proxy, routing, update, licensing, reputation, mail, storage, cloud, remote-logging, management, and vendor-support destinations trusted by the deployment.

·        FortiGate, FortiManager, FortiAnalyzer, FortiMail, FortiWeb, SIEM, SOAR, endpoint-security, email-security, cloud-security, storage-management, identity, hypervisor, backup, orchestration, code, deployment, and administrative systems connected to FortiSandbox.

·        AWS accounts, Azure subscriptions, Google Cloud projects, cloud networks, virtual machines, service identities, storage resources, security groups, firewall rules, logging services, IAM roles, APIs, and management planes supporting cloud-hosted FortiSandbox deployments.

·        Environments with exposed interfaces, weak segmentation, broad trusted-host rules, shared administrative accounts, undocumented integrations, privileged API connectivity, limited request logging, disabled CLI or kernel logging, short local-log retention, limited report retention, incomplete event forwarding, shared NAT, poor asset attribution, or weak change governance.

S14 — Sectors / Countries Affected

Sectors Affected

·        Technology, SaaS, software, telecommunications, hosting, cloud-service, managed-service, cybersecurity, malware-analysis, and digital-platform organizations using FortiSandbox to inspect files, URLs, email, network traffic, endpoints, cloud workloads, or customer submissions.

·        Financial services, insurance, banking, payment-adjacent, legal, consulting, and professional-services organizations using sandboxing to protect regulated information, customer systems, email, endpoints, remote access, cloud platforms, or privileged operations.

·        Healthcare, life sciences, public-sector, defense, education, research, nonprofit, and regulated-service organizations using FortiSandbox for workforce security, sensitive-data protection, threat analysis, email inspection, endpoint defense, or security operations.

·        Retail, e-commerce, hospitality, travel, transportation, logistics, media, marketing, and customer-facing service organizations using FortiSandbox to protect distributed workforces, customer communications, payment-adjacent systems, business applications, and cloud services.

·        Manufacturing, industrial, energy, utilities, supply-chain, aerospace, engineering, and supplier-dependent organizations using FortiSandbox for enterprise security, remote administration, email protection, endpoint defense, partner content inspection, and operational support.

·        Managed security providers, security operations centers, incident-response teams, malware-analysis laboratories, cloud-service operators, and organizations providing sandboxing or security-analysis services to external customers.

·        Organizations integrating FortiSandbox with FortiGate, FortiMail, FortiWeb, FortiManager, FortiAnalyzer, SIEM, SOAR, endpoint, email, cloud, storage, or security-management systems.

·        Large enterprises, distributed organizations, hybrid-cloud operators, government contractors, regulated organizations, multinational businesses, and environments with broad Security Fabric or third-party security-platform integration.

Countries Affected

·        Global.

·        Exposure is not limited to a single country or region because FortiSandbox appliances, virtual deployments, cloud-hosted systems, PaaS services, Fortinet products, email platforms, endpoint systems, and enterprise security environments are deployed globally.

·        Countries with large populations of Fortinet infrastructure, hybrid-cloud environments, government contractors, regulated industries, managed-security providers, cloud-connected organizations, multinational enterprises, and high-volume malware-analysis operations may face elevated operational exposure.

·        Cross-border security operations, multinational tenants, regional PaaS deployments, shared security services, customer-facing analysis, global email systems, cloud resources, and international managed-service relationships can expand the investigation and containment scope.

·        Country-specific impact should be assessed by deployment exposure, interface accessibility, integration criticality, submission sensitivity, credential privilege, connected-system scope, cloud dependency, telemetry maturity, notification obligations, and incident-response capability rather than geography alone.

S15 — Adversary Capability Profiling

Capability Level

Moderate to High

Technical Sophistication

Adversaries require sufficient capability to identify and reach a FortiSandbox management, API, service, upload, reporting, analysis, administrative, or trusted integration path; construct or adapt command-injection input; understand the platform’s request processing and service behavior; and convert execution into useful appliance, analysis, credential, logging, or downstream-control activity. Lower-complexity activity may use public proof-of-concept code, vulnerability scanners, common encoding methods, shell metacharacters, standard interpreters, native utilities, direct callbacks, or simple configuration changes. Higher-capability activity may involve blind or asynchronous execution, payload fragmentation, service-context abuse, selective analysis manipulation, stealthy verdict or report changes, credential and certificate collection, logging suppression, integration-secret abuse, traffic blending, PaaS or cloud-control activity, delayed downstream access, and coordinated modification of multiple connected defensive systems.

Infrastructure Maturity

Moderate

Infrastructure maturity varies by activity pattern. Lower-maturity activity may rely on one scanning system, public exploit code, commodity cloud infrastructure, raw-IP callbacks, common download utilities, direct file transfer, and obvious command or shell behavior. Higher-maturity activity may use rotating cloud hosts, residential proxies, compromised management systems, trusted VPN paths, internal relays, compromised administrators, valid API clients, approved cloud services, dynamic DNS, encrypted channels, separate staging and control infrastructure, low-volume callbacks, legitimate integration identities, and activity designed to resemble malware detonation, maintenance, vendor support, content updates, administrative automation, or normal security-product communication.

Operational Scale

Single-interface exploitation to multi-platform defensive-control compromise

Operational scale ranges from a suspicious request against one FortiSandbox interface to enterprise-wide security-control compromise when unauthorized execution affects multiple appliances, nodes, PaaS instances, tenants, regions, submission workflows, analysis profiles, virtual machines, reports, credentials, or connected systems. Within one organization, scale can expand from temporary command execution into persistent appliance control, selective malware-analysis manipulation, broad credential exposure, false-safe verdict distribution, logging degradation, cloud-control changes, connected-product modification, sensitive-submission exposure, lateral expansion, destructive activity, or widespread defensive failure. Managed-service, customer-facing, multi-tenant, multi-region, and centrally integrated deployments may increase the scale beyond the originating FortiSandbox system.

Escalation Likelihood

High

Escalation likelihood is high when suspicious interface activity is followed by CLI, kernel, process, service, system, file, configuration, or execution-consistent network behavior. Escalation likelihood increases further when probable execution is followed by administrator changes, FortiCloud IAM changes, credential access, logging degradation, analysis-profile modification, virtual-machine changes, job disruption, finding suppression, verdict manipulation, database activity, report changes, persistence, rare outbound communication, or unexpected use of connected systems. Escalation likelihood is highest when analysis outputs are distributed to downstream controls, privileged integration credentials are accessible, sensitive submissions are processed, evidence has rotated or been suppressed, or the organization cannot rapidly distinguish appliance-management traffic from malware-detonation activity.

S16 — Targeting Probability Assessment

Overall Targeting Probability

High

Targeting Drivers

·        FortiSandbox may provide centralized malware analysis and security decision support for email, endpoint, network, cloud, storage, and incident-response workflows.

·        A single FortiSandbox deployment may be trusted by multiple security products and may influence blocking, quarantine, alerting, prioritization, and investigation decisions.

·        Internet-facing services, management interfaces, APIs, upload functions, reverse proxies, VPNs, trusted hosts, administrative systems, and connected products may provide multiple paths to the platform.

·        Public vulnerability research, proof-of-concept code, request examples, scanning tools, encoding methods, shell syntax, and documented platform behavior may lower the barrier for technically capable adversaries.

·        Command execution within a privileged appliance or service context may provide direct access to configuration, credentials, reports, databases, logging controls, and trusted integrations.

·        Selective analysis manipulation may allow an adversary to influence defensive outcomes without causing broad appliance failure or obvious operational disruption.

·        Attackers benefit from environments where request telemetry, CLI history, kernel logging, remote forwarding, report retention, asset attribution, integration inventories, administrator governance, and connected-system logging are incomplete.

·        Malware-detonation traffic, shared NAT, cloud routing, trusted communication, approved protocols, and privileged integration identities may help malicious activity blend into expected behavior.

·        Long-lived certificates, tokens, API keys, service accounts, trusted-host rules, integration credentials, cloud identities, and automation relationships can increase the value of successful compromise.

·        Sensitive submissions, customer samples, regulated data, intellectual property, internal tools, credentials, and security reports may provide additional collection value.

·        Managed-service, customer-facing, multi-tenant, multi-region, and centrally integrated deployments may allow one compromise to affect multiple business units, customers, regions, or connected systems.

·        Targeting probability should be assessed through interface exposure, deployment criticality, privileged access, integration scope, submission sensitivity, cloud connectivity, telemetry maturity, and local evidence of request-to-execution-to-control-compromise behavior rather than CVE count or exploit names alone.

Most Likely Targets

·        FortiSandbox appliances, virtual deployments, clusters, and PaaS instances supporting high-volume file, URL, email, endpoint, network, cloud, or customer-submission analysis.

·        Internet-facing, externally reachable, internally trusted, reverse-proxied, VPN-accessible, API-enabled, upload, reporting, analysis, diagnostic, or administrative interfaces.

·        Appliance administrators, remote-authentication users, FortiCloud IAM users, API identities, integration identities, service accounts, support accounts, maintenance accounts, and privileged administrative paths.

·        Reverse proxies, load balancers, firewalls, VPNs, jump hosts, privileged-access systems, management workstations, cloud consoles, and vendor-support paths used to reach FortiSandbox.

·        Analysis profiles, sandbox virtual machines, VM assignments, detonation settings, submission routes, scan flows, rescans, threat findings, verdicts, quarantine actions, reports, notifications, and result-delivery processes.

·        Certificates, tokens, API keys, SSH keys, trusted hosts, mail credentials, storage credentials, cloud credentials, update settings, logging settings, and connected-product integration secrets.

·        FortiGate, FortiManager, FortiAnalyzer, FortiMail, FortiWeb, SIEM, SOAR, endpoint-security, email-security, cloud-security, storage, identity, backup, hypervisor, deployment, code, and administrative platforms connected to FortiSandbox.

·        AWS, Azure, and Google Cloud environments hosting or supporting FortiSandbox systems, networks, storage, service identities, logging, management, and security controls.

·        Organizations processing regulated information, customer submissions, intellectual property, sensitive documents, internal executables, credentials, malware samples, or security-investigation evidence.

·        Environments with broad interface exposure, weak segmentation, shared administrators, privileged APIs, undocumented integrations, incomplete event forwarding, disabled CLI or kernel logging, short retention, limited report preservation, weak destination baselines, shared NAT, or poor connected-system attribution.

S17 — MITRE ATT&CK Chain Flow Mapping

Stage 1 — Externally Reachable FortiSandbox Interface Exploitation

The adversary exploits an Internet-facing or externally exposed FortiSandbox management, API, service, upload, reporting, analysis, or administrative interface to obtain unauthorized application or service execution.

·        T1190 — Exploit Public-Facing Application

Stage 2 — Command Execution

The adversary uses command injection to execute commands through the compromised FortiSandbox application or service context.

·        T1059 — Command and Scripting Interpreter

Stage 3 — Security-Control Manipulation

The adversary disables, degrades, or modifies FortiSandbox logging, analysis functions, verdict production, reports, quarantine actions, notifications, or related defensive capabilities to reduce visibility or alter security outcomes.

·        T1685 — Disable or Modify Tools

Stage 4 — Downstream Access Through Compromised Accounts

The adversary uses compromised FortiSandbox administrator, service, integration, or cloud accounts to access connected security, cloud, storage, or management systems.

·        T1078 — Valid Accounts

S18 — Attack Path Narrative (Signal-Aligned Execution Flow)

FortiSandbox command injection and security-control compromise begin when an adversary reaches an Internet-facing, externally exposed, internally trusted, cloud-hosted, PaaS, API, upload, reporting, analysis, management, or administrative path capable of interacting with a privileged FortiSandbox function. The core attack path is movement from suspicious interface activity into probable unauthorized command execution, appliance or service compromise, analysis-control manipulation, security-control degradation, and possible downstream access through trusted identities or integrations. Credential theft, persistence, sensitive-submission exposure, cloud-control activity, connected-product compromise, lateral expansion, destructive activity, ransomware deployment, and enterprise-wide defensive failure remain conditional outcomes unless supporting telemetry confirms them.

Stage 1: Suspicious FortiSandbox Interface Interaction

The adversary identifies and interacts with a FortiSandbox management, API, service, upload, reporting, analysis, diagnostic, or administrative interface. Observable evidence may include reconnaissance, repeated endpoint access, malformed requests, encoded characters, shell metacharacters, command delimiters, substitutions, redirection operators, functionally inconsistent parameter values, repeated request variation, unusual methods, unexpected content types, anomalous request sizes, timing changes, or access from rare sources. This stage does not establish exploitation because vulnerability scanning, security testing, automation errors, malformed client traffic, administrative activity, and unsupported requests may generate similar behavior. It becomes material when the targeted endpoint and parameter are capable of invoking a privileged FortiSandbox function and the request pattern is followed by execution-consistent appliance, service, file, configuration, or network behavior.

Stage 2: Probable Unauthorized Command Execution

The adversary converts the interface interaction into unauthorized execution within a FortiSandbox application, worker, helper, daemon, service, or other privileged context. Observable evidence may include unexpected shell or command-interpreter activity, child-process creation, native utility execution, new files, temporary artifacts, permission changes, service interaction, CLI commands, kernel events, process-linked DNS activity, outbound connections, downloads, file transfer, or system behavior inconsistent with the initiating FortiSandbox function. Blind or asynchronous command execution may produce limited or delayed evidence and may not create an interactive shell. This stage should be classified as probable execution when suspicious request activity aligns with one or more execution-consistent signals, not as confirmed compromise based only on a response code, request string, timeout, service error, or isolated native event.

Stage 3: Appliance or Service Compromise

Following probable execution, the adversary may modify FortiSandbox system, service, application, authentication, administrator, configuration, update, database, logging, notification, integration, or persistence state. Observable evidence may include administrator creation or modification, authentication changes, FortiCloud IAM changes, mapped-access-profile changes, secondary-account activity, service changes, startup modification, scheduled execution, trusted-host changes, certificate or key interaction, configuration export, database access, update manipulation, new files, report changes, remote-forwarding changes, CLI-history disablement, kernel-logging disablement, or persistent outbound communication. This stage becomes the central appliance-compromise point when probable execution is followed by unauthorized control-plane, service, identity, persistence, logging, or configuration activity that cannot be reconciled with approved administration, maintenance, support, upgrade, or recovery.

Stage 4: Analysis-Control and Verdict Manipulation

The adversary uses appliance or service control to alter how FortiSandbox accepts, routes, detonates, rescans, classifies, reports, quarantines, or distributes analysis results. Observable evidence may include changes to analysis profiles, sandbox virtual-machine assignments, detonation settings, submission routes, scan flow, rescans, job state, threat findings, verdict production, quarantine actions, report generation, report deletion, notification delivery, or result distribution. Manipulation may be selective and limited to one file, URL, job, virtual machine, threat finding, verdict, report, notification, customer, tenant, or integration while the wider platform continues to function. This stage becomes high priority when analysis or verdict changes align with prior suspicious interface activity, probable execution, unauthorized configuration changes, unexplained job or VM behavior, database activity, report modification, or downstream defensive decisions inconsistent with the underlying submission evidence.

Stage 5: Security-Control and Evidence Degradation

The adversary disables, degrades, redirects, suppresses, or modifies FortiSandbox logging, monitoring, notifications, reports, quarantine behavior, analysis capabilities, event forwarding, or connected defensive functions to reduce visibility or alter security outcomes. Observable evidence may include local log deletion, shortened retention, remote-syslog interruption, FortiAnalyzer forwarding changes, CLI-history disablement, kernel-logging disablement, notification suppression, SNMP changes, timestamp inconsistencies, report deletion, finding suppression, false-safe verdicts, false-malicious verdicts, quarantine changes, sensor-health degradation, or unexplained differences between appliance and downstream records. This stage becomes critical when evidence loss or defensive-control modification follows probable execution or appliance compromise and prevents the organization from determining whether submitted content, analysis results, alerts, or connected controls remain trustworthy.

Stage 6: Trusted-Integration and Downstream Expansion

The adversary uses compromised FortiSandbox administrator, service, integration, API, or cloud identities or trusted connectivity to access connected Fortinet products, SIEM, SOAR, endpoint, email, cloud, storage, identity, hypervisor, backup, deployment, code, or management systems. Observable evidence may include unexpected API use, new sessions, administrative changes, rule or policy modification, credential creation, service-account activity, cloud-control events, storage access, report or alert suppression, security-policy changes, new integrations, rare destination access, or activity across multiple connected platforms. This stage becomes critical when downstream behavior aligns with the FortiSandbox compromise through identity, API client, certificate, token, source, destination, integration, tenant, region, cloud resource, administrative action, or bounded time window.

S19 — Attack Chain Risk Amplification Summary

FortiSandbox command injection amplifies risk because it can convert access to one security-analysis interface into privileged command execution, appliance compromise, analysis manipulation, evidence degradation, and possible trusted access to multiple connected defensive systems. The chain becomes materially more dangerous when suspicious request activity is followed by execution-consistent appliance behavior, unauthorized control-plane changes, manipulated findings or verdicts, credential or integration-secret access, logging degradation, or downstream activity using FortiSandbox-associated identities or trusted paths.

·        Internet-facing or externally exposed interfaces increase exposure because adversaries may interact with privileged FortiSandbox functions without first compromising an internal administrative system.

·        Internally trusted, VPN-accessible, reverse-proxied, API-enabled, and service-to-service paths expand the attack surface because exploitation may occur through systems already permitted to communicate with FortiSandbox.

·        Blind, asynchronous, delayed, or fragmented command execution increases uncertainty because successful execution may not produce an interactive shell, direct output, or obvious immediate failure.

·        Privileged service execution amplifies impact because FortiSandbox applications, workers, helpers, or daemons may access configuration, analysis functions, reports, databases, credentials, logs, files, and trusted integrations.

·        Administrator, FortiCloud IAM, mapped-profile, secondary-account, service-account, or API-identity changes increase persistence and downstream-access risk.

·        Configuration, update, database, service, certificate, trusted-host, or startup changes increase concern because they may alter appliance operation, preserve access, or conceal unauthorized control.

·        Analysis-profile and virtual-machine changes amplify risk because they may determine how submitted content is detonated, observed, classified, and reported.

·        Job disruption, rescan manipulation, threat-finding suppression, verdict alteration, and report modification increase defensive uncertainty because downstream systems may act on inaccurate or incomplete analysis.

·        False-safe verdicts increase enterprise exposure because malicious files or URLs may be released, deprioritized, or permitted by connected controls.

·        False-malicious verdicts increase operational impact because legitimate business content may be blocked, quarantined, escalated, or disrupted.

·        Selective manipulation increases investigation difficulty because one submission, customer, tenant, profile, VM, report, or integration may be affected while the wider platform appears healthy.

·        Credential, API-key, token, certificate, SSH-key, mail-secret, storage-secret, cloud-secret, or integration-secret access expands the blast radius beyond the originating appliance.

·        Local log deletion, remote-forwarding interruption, CLI-history disablement, kernel-logging disablement, notification suppression, report deletion, or timestamp manipulation reduces confidence in reconstruction and containment.

·        Malware-detonation traffic creates attribution challenges because outbound DNS, HTTP, HTTPS, file transfer, raw-IP communication, or cloud access may originate from legitimate analysis activity or adversary-controlled appliance execution.

·        Shared NAT, proxying, cloud routing, clustered nodes, PaaS service boundaries, and vendor-managed infrastructure may make it difficult to identify the exact compromised component or execution context.

·        FortiSandbox integration with FortiGate, FortiMail, FortiWeb, FortiManager, FortiAnalyzer, SIEM, SOAR, endpoint, email, cloud, storage, and management platforms increases downstream consequence.

·        Sensitive submissions amplify confidentiality risk because sandboxed content may include customer samples, regulated information, intellectual property, credentials, internal tools, incident evidence, or malicious code under investigation.

·        PaaS and cloud deployments expand the evidence boundary because FortiCloud IAM, tenant, region, API, vendor-managed service, cloud-control-plane, network, and storage evidence may be required.

·        Delayed downstream use increases investigation difficulty because original request, command-execution, job, VM, report, or log evidence may fall outside common retention and correlation windows.

·        Response burden increases because teams may need to isolate or replace appliances, preserve reports and logs, rotate credentials and certificates, validate analysis profiles and VMs, reassess prior verdicts, inspect connected systems, and prove that defensive trust has been restored.

S20 — Tactics, Techniques, and Procedures

Figure 3

FortiSandbox Interface Discovery and Access

Adversaries may identify Internet-facing, externally exposed, reverse-proxied, VPN-accessible, internally trusted, cloud-hosted, PaaS, API, upload, reporting, analysis, diagnostic, management, or administrative FortiSandbox interfaces. Observable behavior may include endpoint enumeration, service fingerprinting, repeated requests, unusual methods, unexpected content types, rare sources, automated scanning, parameter discovery, authentication testing, or interaction with functions not normally used by the source. This behavior becomes risk-relevant when the accessed interface and parameter can invoke a privileged function and the activity is followed by execution-consistent appliance behavior.

Command-Injection Request Construction

Adversaries may use shell metacharacters, command delimiters, substitutions, encoded characters, redirection operators, interpreter fragments, malformed structures, repeated request variation, delayed-response testing, or functionally inconsistent values to influence server-side command handling. Requests may be encoded, fragmented, nested, or adapted to bypass input validation, proxies, web-application firewalls, normalization, or signature-based controls. This behavior becomes materially significant when suspicious requests target a validated command-processing path and correlate with unexpected CLI, kernel, process, service, file, configuration, or network activity.

Blind or Asynchronous Command Execution

Adversaries may execute commands without receiving direct output by causing DNS lookups, callbacks, downloads, file creation, service changes, delayed execution, or other side effects. Execution may occur through background workers, queues, helper utilities, privileged services, or asynchronous job processing and may be separated from the original request by time. This behavior becomes high priority when request timing, job activity, native events, new artifacts, process-linked networking, or service-state changes align within a bounded sequence.

Appliance and Service Control

Adversaries may modify administrators, authentication settings, FortiCloud IAM access, mapped profiles, secondary accounts, services, startup behavior, schedules, trusted hosts, certificates, keys, configuration, updates, databases, logging, or integration settings after gaining execution. Activity may occur through native administration, command-line functions, service files, direct configuration changes, database interaction, or API use. This behavior becomes high priority when the change is unauthorized, follows probable execution, and cannot be reconciled with approved maintenance, support, upgrade, recovery, or administrative workflows.

Analysis-Profile and Virtual-Machine Manipulation

Adversaries may alter analysis profiles, sandbox virtual-machine assignments, detonation settings, scan behavior, submission routes, rescan logic, VM availability, or job processing to influence how content is analyzed. Manipulation may cause samples to run in inappropriate environments, bypass required analysis, produce incomplete behavior, fail repeatedly, or avoid selected engines or profiles. This behavior becomes materially significant when changes follow suspicious interface or appliance activity and are associated with unexpected verdict, job, VM, report, or downstream-control outcomes.

Threat-Finding and Verdict Manipulation

Adversaries may suppress, reclassify, add, remove, or alter threat findings and verdicts to cause malicious content to appear safe or legitimate content to appear malicious. Manipulation may occur through analysis settings, database activity, result handling, report generation, application logic, or direct modification of stored findings. This behavior becomes critical when verdict differences cannot be explained by engine updates, profile changes, rescan conditions, sample differences, environmental variance, or approved analyst action and align with prior compromise signals.

Report, Quarantine, and Notification Interference

Adversaries may alter, delete, delay, redirect, or suppress reports, quarantine actions, alerts, email notifications, SNMP events, SIEM forwarding, FortiAnalyzer forwarding, or result-distribution workflows. This may prevent defenders and connected products from receiving accurate or timely analysis outcomes. This behavior becomes high priority when report or notification changes follow probable execution, database activity, configuration changes, or unusual administrator or integration use.

Logging and Visibility Degradation

Adversaries may clear local logs, reduce retention, interrupt remote forwarding, disable CLI history, disable kernel logging, modify timestamps, suppress notifications, change SNMP settings, delete reports, or create gaps between FortiSandbox and downstream records. Observable behavior may include logging-state changes, missing expected events, forwarding failures, ingestion gaps, unexplained clock differences, reduced event volume, or administrative changes without a valid change record. This behavior becomes materially significant when it follows suspicious request, command-execution, appliance-control, or analysis-manipulation activity.

Credential and Trusted-Integration Access

Adversaries may access administrator credentials, remote-authentication information, service accounts, API keys, tokens, certificates, SSH keys, mail credentials, storage credentials, cloud settings, trusted hosts, or connected-product integration secrets available to the compromised deployment. Access may occur through configuration, files, databases, process memory, administrative functions, exports, backups, or service settings. This behavior becomes high priority when sensitive material is accessed, exported, copied, used from a new source, or followed by unexpected sessions or changes in connected environments.

Outbound Communication and Tool Transfer

Adversaries may use DNS, HTTP, HTTPS, raw-IP communication, cloud storage, file transfer, tunneling, callbacks, or download utilities to retrieve tools, transfer data, maintain command and control, or stage further activity. FortiSandbox malware-detonation behavior can make this activity difficult to distinguish from legitimate sample execution. This behavior becomes risk-relevant when the communication originates from the appliance or management plane rather than an expected detonation context, involves rare or unapproved destinations, follows suspicious request activity, or aligns with new files, processes, services, or administrative changes.

Trusted-Account and Integration Abuse

Adversaries may use compromised FortiSandbox administrator, service, API, integration, FortiCloud IAM, or cloud accounts to access connected Fortinet products, SIEM, SOAR, endpoint, email, storage, cloud, identity, backup, deployment, code, or management systems. This behavior becomes materially significant when the account, source, client, destination, privilege, action, tenant, region, or timing is inconsistent with approved operations and aligns with prior FortiSandbox compromise evidence.

Operational Blending With Security Administration and Malware Analysis

Adversaries may blend malicious behavior into legitimate vulnerability scanning, product maintenance, content updates, malware detonation, vendor support, troubleshooting, administrative automation, report generation, rescan activity, VM management, cloud operations, or incident response. This blending is effective because FortiSandbox routinely processes hostile content, executes suspicious behavior, communicates with external systems, changes analysis state, and generates high-volume security telemetry. Detection and response require correlation across the interface, endpoint, parameter, request, source, appliance, node, process, service, job, VM, finding, verdict, report, administrator, identity, integration, destination, cloud resource, change record, and bounded time window rather than reliance on one event.

Post-Remediation Defensive-Trust Validation Failure

Adversaries may retain access through newly created administrators, modified services, startup changes, scheduled execution, compromised API identities, stolen integration credentials, certificates, tokens, cloud accounts, or downstream persistence after patching, service restart, password reset, appliance replacement, or interface isolation. Manipulated verdicts, deleted reports, altered profiles, compromised connected systems, and previously distributed false-safe results may continue to create risk after the initial appliance is remediated. This behavior becomes high priority when suspicious appliance, analysis, identity, integration, or downstream activity continues after remediation and cannot be tied to approved recovery or trust-validation activity.

S20A — Adversary Tradecraft Summary

FortiSandbox command injection and security-control compromise target the trust relationship among exposed or trusted interfaces, privileged application and service functions, appliance administration, malware-analysis profiles, sandbox virtual machines, threat findings, verdict production, reports, quarantine actions, notifications, logging, credentials, integrations, connected security platforms, and downstream defensive decisions. The adversary objective is to convert unauthorized interface interaction into privileged execution and security-control influence while blending malicious activity into the hostile files, network behavior, administrative operations, and high-volume telemetry that FortiSandbox is designed to process.

·        The core tradecraft pattern is suspicious interface interaction followed by probable command execution, appliance or service compromise, analysis-control manipulation, security-control degradation, and possible downstream trusted-system access.

·        The behavior is not dependent on a single CVE, exploit name, affected version, proof-of-concept repository, request string, command string, file path, hash, source IP, actor name, or static indicator.

·        Adversaries may use scanners, crafted HTTP requests, encoded characters, shell metacharacters, command delimiters, substitutions, redirection operators, interpreter fragments, native utilities, background workers, APIs, cloud services, or compromised administrative systems.

·        Blind, delayed, fragmented, and asynchronous execution may separate the original request from later appliance, file, service, network, or configuration evidence.

·        A successful or failed HTTP response does not prove whether command execution occurred, and an apparently functioning appliance does not prove that analysis integrity remains intact.

·        Adversaries may modify administrators, authentication, FortiCloud IAM access, mapped profiles, secondary accounts, services, schedules, trusted hosts, certificates, configuration, updates, databases, logging, notifications, or integrations.

·        Analysis manipulation may target profiles, virtual-machine assignments, submission routes, rescans, job handling, threat findings, verdicts, quarantine actions, reports, or result distribution.

·        Selective manipulation may affect one sample, URL, job, VM, customer, tenant, finding, verdict, report, notification, or integration while broader platform operations appear normal.

·        False-safe outcomes may permit malicious content to reach endpoints, users, networks, cloud services, or business systems, while false-malicious outcomes may disrupt legitimate operations.

·        Credentials, API keys, tokens, certificates, SSH keys, service accounts, mail credentials, storage credentials, cloud identities, and integration secrets may convert appliance compromise into downstream access.

·        Malware-detonation traffic, shared NAT, proxies, cloud routing, approved protocols, trusted integrations, and normal business hours may help adversary activity blend into expected behavior.

·        Logging degradation, forwarding interruption, report deletion, notification suppression, CLI-history disablement, kernel-logging disablement, and timestamp manipulation may reduce reconstruction confidence.

·        Detection requires visibility into requests, endpoints, parameters, appliance and service behavior, CLI and kernel activity, processes, files, jobs, VMs, findings, verdicts, reports, administrators, FortiCloud IAM, credentials, integrations, network destinations, cloud control planes, and connected-system actions.

·        Response requires treating suspected FortiSandbox compromise as a malware-analysis trust and enterprise defensive-control incident, not only as a vulnerable-version, malformed-request, patch-management, appliance-maintenance, or administrator-account issue.

·        The behavior remains durable because the adversary objective is to abuse privileged security-analysis functions and trusted integrations regardless of the initial vulnerability, access path, command syntax, deployment model, affected interface, or downstream platform used.

S21 — Detection Strategy Overview

Detection Philosophy

Detect FortiSandbox command injection and security-control compromise through correlated behavior across exposed management and service interfaces, native FortiSandbox events, administrative activity, CLI and kernel telemetry where enabled, configuration integrity, malware-submission flow, analysis jobs, sandbox virtual machines, threat findings, database operations, report production, performance and resource state, notification delivery, outbound communication, trusted integrations, and downstream defensive-control activity. The durable detection model is a suspicious request or administrative interaction followed by probable unauthorized command execution, appliance or service state change, analysis-pipeline manipulation, credential or integration-secret access, logging or notification degradation, persistence, outbound communication, or misuse of FortiSandbox trust relationships. CVE identifiers, vulnerable-version findings, malformed requests, isolated administrator activity, service faults, processing errors, verdict differences, or missing telemetry are prioritization inputs and must not be treated as standalone proof of compromise.

Primary Detection Anchors

·        Suspicious HTTP or HTTPS activity reaching a FortiSandbox management, API, service, upload, reporting, analysis, or administrative interface with command delimiters, shell-control characters, encoded metacharacters, nested substitutions, interpreter syntax, redirection operators, or parameter values inconsistent with the requested function.

·        Input Events showing unusual submissions, sources, adapters, devices, URLs, files, or processing entry points near suspicious request or administrative activity.

·        System Events showing unexpected user creation, login activity, firmware or content operations, configuration changes, system actions, daemon behavior, controller activity, service changes, or privileged operations.

·        CLI-history or kernel telemetry showing unexpected commands, system-level activity, service manipulation, account changes, network changes, or configuration access where those logging options are supported and enabled.

·        Job Events showing unexplained changes in file or URL scan flow, processing state, rescan activity, analysis progression, failure conditions, verdict generation, report creation, or result delivery.

·        VM Events showing unexpected sandbox-VM initialization, assignment, reset, interruption, failure, recovery, or lifecycle changes near suspicious activity.

·        Threat Events showing unexplained disappearance, suppression, reclassification, or inconsistency of malware or URL findings.

·        Database Events showing unexpected database changes, failures, maintenance actions, access patterns, or state changes associated with suspicious activity.

·        Report Events showing unauthorized report generation, deletion, modification, suppression, access, export, or delivery changes.

·        Performance Events showing abnormal processing latency, throughput change, queue behavior, or sustained performance degradation following suspicious activity.

·        Resource Events showing unexpected CPU, memory, storage, VM-capacity, queue, or other resource conditions near suspected exploitation.

·        HA Events showing unexplained failover, synchronization failure, role change, node removal, or cluster-configuration activity.

·        Notification or SNMP Events showing alert-delivery failure, notification suppression, destination change, or trap anomalies following suspicious activity.

·        Unauthorized changes to analysis profiles, VM assignments, detonation behavior, submission handling, rescans, file routing, verdict generation, reporting, quarantine actions, or result delivery.

·        Unexpected creation, modification, deletion, or privilege change involving appliance administrators, remote-authentication users, API or integration identities, certificates, access tokens, SSH keys, trusted hosts, authentication settings, or authorization mappings.

·        For FortiSandbox PaaS, unexpected FortiCloud IAM-user, access-profile, secondary-account, region, API, or service-setting changes.

·        Access to or modification of integration credentials, API keys, certificates, service accounts, mail settings, storage settings, cloud settings, update configuration, or connected-product trust information.

·        Unexpected reduction, interruption, deletion, suppression, redirection, or modification of logs, reports, alerts, administrator auditing, kernel logging, CLI logging, notification delivery, event forwarding, or remote-log configuration.

·        Outbound communication from FortiSandbox to a rare, newly observed, unapproved, raw-IP, file-transfer, cloud-storage, paste, tunneling, or command-and-control-like destination following suspicious activity.

·        Unexpected FortiSandbox communication with connected Fortinet, SIEM, SOAR, endpoint, email, cloud, storage, management, or other security systems outside established integration behavior.

·        Security-policy weakening, trust expansion, exclusion creation, alert suppression, logging degradation, credential creation, or administrative change in a connected system following suspected FortiSandbox compromise.

·        Similar request, event, configuration, job, VM, threat, report, performance, resource, notification, or outbound anomalies across multiple FortiSandbox appliances, nodes, clusters, PaaS instances, regions, or connected products within a bounded time window.

Detection Prioritization Model

·        Prioritize suspicious interface activity followed by native FortiSandbox events indicating command execution, system change, configuration change, service manipulation, job disruption, VM disruption, logging degradation, or outbound communication.

·        Prioritize unauthenticated, externally sourced, low-context, or otherwise anomalous requests followed by privileged appliance or service behavior.

·        Prioritize unexpected CLI, kernel, process, service, or system activity associated with a FortiSandbox web, API, management, worker, analysis, update, or integration context.

·        Prioritize unauthorized administrator, authentication, API, certificate, trusted-host, logging, update, analysis-profile, VM, report, notification, or integration changes.

·        Prioritize Job Event sequences that diverge from expected submission, processing, analysis, verdict, report, and delivery workflows.

·        Prioritize unexplained Threat, Database, Report, Performance, or Resource Events that align with suspicious request, system, or administrative activity.

·        Prioritize access to integration secrets, API credentials, certificates, tokens, mail credentials, storage credentials, cloud settings, or connected-product configuration.

·        Prioritize logging interruption, remote-forwarding changes, CLI-history disablement, kernel-logging disablement, report deletion, or notification suppression after suspicious activity.

·        Prioritize outbound communication following probable command execution, configuration access, archive creation, credential access, or service manipulation.

·        Prioritize activity affecting FortiSandbox systems with broad Security Fabric integration, privileged API connectivity, sensitive submissions, or high-trust defensive placement.

·        Prioritize connected-product policy, logging, trust, alerting, quarantine, credential, or administrative changes following suspected FortiSandbox compromise.

·        Treat isolated exposure findings, malformed requests, administrator logins, event failures, VM faults, resource spikes, service restarts, configuration changes, or verdict discrepancies as supporting evidence unless corroborated.

Correlation Strategy (Strict Enforcement)

Do not promote a vulnerable FortiSandbox deployment, suspicious request, administrator login, CLI command, kernel event, native event, service fault, configuration change, processing error, missing report, verdict anomaly, new outbound connection, or connected-product action to confirmed compromise without correlation by deployment, appliance, device identifier, node, cluster, PaaS instance, tenant, region, source IP, request path, HTTP method, parameter, session, appliance administrator, remote-authentication user, FortiCloud IAM user, API or integration identity, user interface, action, status, log type, subtype, message identifier, log-type-specific field, sample or URL identifier, job, VM, analysis profile, service, configuration object, destination, connected product, change record, or bounded time window.

Use the following confidence progression:

·        Exposure condition: a FortiSandbox deployment is vulnerable, externally reachable, broadly accessible, or insufficiently monitored, but locally observable exploit behavior has not been identified.

·        Suspicious request activity: an unexpected request reaches a FortiSandbox interface with command-like, encoded, malformed, or functionally inconsistent input.

·        Probable command execution: suspicious request activity is followed by unexpected CLI, kernel, system, service, configuration, process, file, or outbound-network behavior consistent with unauthorized command execution.

·        Appliance or service compromise: probable command execution is followed by unauthorized identity, credential, configuration, logging, persistence, update, integration, database, or sustained system-level activity.

·        Analysis-control compromise: appliance or service compromise affects submission handling, scan flow, VM behavior, analysis jobs, rescans, threat findings, verdict generation, reporting, quarantine, notification, or result delivery.

·        Security-control compromise: manipulated FortiSandbox behavior, credentials, integrations, reports, verdicts, or threat findings weaken or misdirect connected defensive systems.

·        Downstream compromise: FortiSandbox-derived trust, credentials, integrations, or manipulated outputs are used to alter connected systems, suppress detection, distribute unsafe results, establish persistence, or expand access.

Absence of process, shell, kernel, CLI, file, or diagnostic telemetry must not be treated as evidence that command execution did not occur. A successful HTTP response does not prove exploitation, and a failed response does not prove the attempt was unsuccessful. A completed analysis job or apparently valid verdict does not prove that the submission path, analysis profile, VM assignment, threat record, database state, report, or result-delivery path remained trustworthy.

Telemetry Prioritization

·        Input Events covering submitted files, URLs, devices, network shares, ICAP clients, BCC adapters, MTA adapters, and other enabled submission sources.

·        System Events covering system operation, administrator activity, user changes, configuration changes, downloads, updates, daemon activity, controllers, services, and other appliance-level behavior.

·        Job Events preserving the scan flow of submitted files and URLs.

·        VM Events covering sandbox-VM initialization, assignment, lifecycle, failure, reset, and recovery.

·        Threat Events covering malware, malicious URL, and related threat findings.

·        Database Events covering database activity, state, maintenance, and failures.

·        Report Events covering report generation, access, delivery, deletion, and failure.

·        Performance Events covering throughput, latency, processing performance, and operational degradation.

·        Resource Events covering CPU, memory, storage, VM capacity, queues, and other resource conditions.

·        HA Events covering cluster configuration, node role, synchronization, and failover.

·        Notification and SNMP Events covering email alerts, traps, destinations, and delivery outcomes.

·        Standard log fields including timestamp, level, user, message, action, status, user interface, type, subtype, message identifier, device identifier, and other documented fields.

·        Log-type-specific fields such as job, sample, URL, VM, source, destination, process, controller, report, database, threat, resource, or integration context where present.

·        FortiSandbox administrative, authentication, API, certificate, trusted-host, update, logging, report, integration, and configuration telemetry.

·        Kernel logging and CLI-history logging where supported and enabled.

·        Reverse-proxy, load-balancer, web-application firewall, firewall, VPN, IDS, NDR, DNS, flow, and packet telemetry covering FortiSandbox interfaces.

·        Remote-log telemetry forwarded to FortiAnalyzer, FortiAnalyzer Cloud, syslog, SIEM, or another durable repository.

·        Connected-product telemetry associated with FortiSandbox submissions, verdicts, reports, quarantine actions, APIs, and integrations.

·        Change-management, maintenance, troubleshooting, upgrade, vendor-support, migration, integration, backup, recovery, and incident-response records.

Detection Design Constraints

·        Do not base detection on CVE identifiers, advisory names, proof-of-concept names, fixed payload strings, static commands, hashes, source IPs, filenames, request paths, or vulnerable-version matches.

·        Do not assume command injection always produces an interactive shell, malware download, reverse shell, new account, persistence, obvious file creation, or external callback.

·        Do not assume direct process, command-line, shell, syscall, memory, or file visibility is available through standard FortiSandbox logging.

·        Treat the complete native event and alert model as the primary detection foundation.

·        Treat kernel logs, CLI history, process data, diagnostic evidence, hypervisor telemetry, and operating-system evidence as conditional enrichment.

·        Treat standard log fields as broadly available only where documented and qualify additional values as log-type-specific.

·        Account for execution through web services, APIs, application components, background workers, analysis services, queues, helper utilities, or privileged system contexts.

·        Do not require direct observation of the injected command when correlated request, native-event, configuration, service, job, VM, report, resource, or outbound evidence provides sufficient support.

·        Distinguish malicious activity from approved upgrades, troubleshooting, vendor support, maintenance, content updates, VM changes, certificate operations, integration changes, backup, recovery, migration, or incident response.

·        Preserve scope around command injection, appliance or PaaS service compromise, analysis-control manipulation, credential exposure, logging degradation, trusted-integration abuse, and downstream defensive impact.

·        Support encoded, obfuscated, fragmented, nested, delayed, asynchronous, and blind command-execution variants.

·        Support exploitation through external, internal, trusted, VPN, reverse-proxy, management, cloud, API, or service-to-service paths.

·        Support deployments that remain operational while selectively manipulating one submission, job, VM, threat finding, verdict, report, alert, or integration.

·        Avoid treating every unusual event, rescan, verdict change, report difference, service fault, VM failure, database error, resource spike, or administrator action as compromise.

·        Distinguish physical and virtual appliance controls from FortiSandbox PaaS controls and customer-accessible telemetry.

·        Apply FortiCloud IAM terminology only to PaaS access and use appliance-administrator, remote-authentication-user, API-identity, or integration-identity terminology for non-PaaS deployments.

Baseline and Deployment Requirements

·        Inventory all FortiSandbox physical appliances, virtual appliances, clusters, PaaS instances, tenants, regions, management interfaces, service interfaces, APIs, and externally reachable endpoints.

·        Document version, build, patch state, deployment model, exposure path, management network, reverse proxies, load balancers, firewalls, VPNs, trusted hosts, and administrative access paths.

·        Baseline normal HTTP methods, request paths, parameters, content types, request sizes, source networks, API clients, user agents, authentication states, and service-to-service activity.

·        Baseline Input, System, Job, VM, Threat, Database, Report, Performance, Resource, HA, Notification, and SNMP Event patterns.

·        Baseline event levels, users, messages, actions, statuses, interfaces, types, subtypes, message identifiers, device identifiers, and relevant log-type-specific values.

·        Baseline appliance administrators, remote-authentication users, API identities, integration identities, service accounts, support accounts, authentication methods, trusted hosts, certificates, SSH keys, tokens, and privilege levels.

·        For PaaS, baseline FortiCloud IAM users, mapped access profiles, secondary accounts, regions, API access, and service settings.

·        Baseline submission sources, file and URL types, analysis profiles, VM assignments, scan flow, processing duration, rescan behavior, failure rates, threat findings, verdict distribution, report generation, quarantine actions, and result-delivery paths.

·        Baseline configuration, services, logging levels, kernel logging, CLI logging, report retention, local-log behavior, remote forwarding, notifications, updates, certificates, integrations, and connected-product trust relationships.

·        Inventory credentials, API keys, certificates, tokens, service accounts, mail settings, storage settings, cloud settings, update settings, and security-product integrations accessible to FortiSandbox.

·        Map FortiSandbox relationships with connected Fortinet products, SIEM, SOAR, endpoint, email, cloud, storage, management, and other security platforms.

·        Configure durable remote logging because local FortiSandbox logs retain up to 1 GB and rotate when the capacity limit is reached.

·        Configure local report retention within the supported 1–28-day range and preserve high-value reports externally when investigation requirements exceed local retention.

·        Enable kernel logging, CLI-history logging, and relevant submission-event logging where supported, operationally acceptable, and consistent with deployment requirements.

·        Maintain approved change records for upgrades, patches, troubleshooting, vendor support, maintenance, content updates, VM changes, integration changes, certificate operations, backup, recovery, migration, and incident response.

·        Validate timestamp synchronization and normalize deployment, device, user, administrator, IAM user, API identity, source, action, status, type, subtype, message identifier, sample, URL, job, VM, integration, and destination fields.

·        Define approved outbound destinations for Fortinet updates, licensing, reputation services, DNS, NTP, mail, storage, remote logging, management, cloud services, and vendor support.

Variant Resilience Requirements

·        Rules must remain effective when attackers vary request paths, parameter names, HTTP methods, encoding, shell syntax, interpreters, utilities, command separators, quoting, payload length, or execution method.

·        Detection should emphasize request-to-event linkage, unexpected native events, unauthorized state change, job-flow anomalies, VM anomalies, threat or report inconsistency, logging degradation, outbound activity, and downstream control impact.

·        Support blind command injection that produces no direct response content.

·        Support delayed or asynchronous execution through workers, queues, scheduled functions, analysis services, or background processes.

·        Support commands that use native utilities or appliance functions.

·        Support short-lived execution that leaves limited process or file evidence.

·        Support activity limited to credential collection, configuration access, database change, report manipulation, verdict manipulation, logging degradation, or temporary control weakening.

·        Support activity originating from trusted management networks, VPNs, reverse proxies, connected products, compromised administrator systems, cloud infrastructure, or familiar geographies.

·        Support narrowly targeted manipulation of one file, URL, job, VM, profile, threat finding, verdict, report, notification, or integration.

·        Support analysis-result tampering without sustained command-and-control communication.

·        Support physical, virtual, clustered, multi-tenant, multi-region, and PaaS deployment models.

·        Support exploitation chained with stolen credentials, API abuse, session theft, authorization weaknesses, or trusted-service access.

·        Remain applicable when attackers use FortiSandbox as a pivot into connected security, management, cloud, email, endpoint, storage, or network systems.

Operational Detection Model

·        Begin with asset identification, deployment-model classification, interface mapping, exposure validation, version assessment, administrative-path mapping, integration mapping, and telemetry validation.

·        Enable and validate relevant native events, alerts, administrative logs, submission-event logs, kernel logs, CLI history, remote forwarding, and report preservation before relying on higher-order correlation.

·        Run suspicious-request, request-to-event, job-integrity, VM-integrity, threat-integrity, report-integrity, service-health, resource-health, configuration-change, logging-health, outbound-communication, credential-access, and integration-change analytics in hunt mode before production alerting.

·        Escalate suspicious requests when followed by unexpected native events, CLI or kernel activity, service changes, configuration changes, job or VM anomalies, database changes, report changes, logging degradation, or outbound communication.

·        Escalate unauthorized administrator, remote-user, PaaS IAM, API, certificate, trusted-host, logging, update, service, analysis-profile, VM, submission, verdict, report, quarantine, notification, or integration changes.

·        Escalate unexplained scan-flow changes, rescan anomalies, processing failures, threat-finding changes, missing results, verdict changes, report changes, quarantine changes, or notification suppression when correlated with appliance or service activity.

·        Escalate access to credentials, tokens, keys, certificates, mail settings, cloud settings, storage settings, update settings, or connected-product configuration.

·        Escalate outbound communication to rare or unapproved destinations following probable execution, configuration access, credential access, database activity, report manipulation, or service change.

·        Escalate connected-product policy changes, trust changes, alert suppression, credential creation, logging degradation, or administrative actions following suspected FortiSandbox compromise.

·        Preserve investigation windows sufficient to connect earlier exploit activity with delayed credential use, persistence, analysis manipulation, or downstream security-control changes.

·        Route high-confidence findings to network security, malware analysis, security engineering, SOC, incident response, identity, cloud, email, endpoint, infrastructure, legal, and relevant business owners.

·        Preserve the distinction between exposure, suspicious request activity, probable command execution, appliance or service compromise, analysis-control compromise, security-control compromise, and downstream compromise.

Explicit Non-Deployment Guardrails

·        Do not deploy CVE-name, vulnerable-version, patch-state, scanner, static request-string, payload, hash, or proof-of-concept matches as compromise detections.

·        Do not classify every encoded, malformed, or special-character-bearing request as command injection without validating the endpoint, parameter, expected function, source, response, and subsequent FortiSandbox activity.

·        Do not classify ordinary administrator, PaaS IAM, API, CLI, system, update, maintenance, or support activity as malicious without identity, source, interface, action, status, deployment, and change context.

·        Do not classify every native event, service restart, processing failure, queue delay, database error, performance degradation, resource spike, or VM fault as exploitation without correlated request, command, configuration, logging, or outbound evidence.

·        Do not classify every rescan, threat change, verdict change, report difference, or analyst disagreement as manipulation without validating submission identity, scan flow, analysis profile, VM state, content version, and independent evidence.

·        Do not assume absence of CLI, kernel, process, or file evidence proves execution did not occur when the telemetry was disabled, unavailable, rotated, inaccessible, or unsupported.

·        Do not attribute connected-product activity to FortiSandbox compromise without deployment, integration, identity, credential, action, destination, and time-window linkage.

·        Do not suppress suspicious activity solely because it originated from an administrator, trusted host, management network, VPN, reverse proxy, FortiCloud account, vendor-support path, or connected Fortinet product.

·        Do not promote rules to production until deployment model, interfaces, normal requests, native-event coverage, logging options, retention, remote forwarding, report preservation, administrative workflows, job and VM baselines, outbound destinations, integrations, change records, and false-positive controls have been validated.

S22 — Primary Detection Signals

Figure 4

Primary Detection Signals

·        Suspicious requests to FortiSandbox interfaces containing command delimiters, shell syntax, encoded metacharacters, nested substitutions, redirection operators, interpreter fragments, or values inconsistent with the expected parameter function.

·        Input Events showing unusual submission sources, adapters, devices, shares, files, URLs, or entry points near suspicious request activity.

·        System Events showing unexpected login, user, configuration, update, service, controller, daemon, or privileged system activity following suspicious requests.

·        Unexpected CLI-history or kernel activity following suspicious request or administrative activity where those sources are enabled.

·        Job Events showing unexplained changes in submission processing, scan flow, rescans, analysis progression, failure state, verdict generation, report creation, or result delivery.

·        VM Events showing unexpected initialization, reset, interruption, failure, assignment change, recovery, or lifecycle behavior.

·        Threat Events showing unexplained removal, suppression, reclassification, or inconsistency of malware or URL findings.

·        Database Events showing unexpected database access, modification, failure, maintenance action, or state change.

·        Report Events showing unauthorized report generation, access, export, modification, deletion, suppression, or delivery change.

·        Performance or Resource Events showing abnormal latency, throughput, queue behavior, CPU use, memory use, storage use, VM-capacity change, or sustained degradation.

·        HA Events showing unexpected failover, synchronization failure, role change, node removal, or cluster modification.

·        Notification or SNMP Events showing alert-delivery failure, destination modification, suppression, or trap anomalies.

·        Unauthorized changes to analysis profiles, VM assignments, detonation behavior, submission handling, rescan logic, routing, verdict generation, reporting, quarantine actions, or result delivery.

·        Unexpected appliance-administrator, remote-user, API-identity, integration-identity, access-token, SSH-key, certificate, trusted-host, authentication, or privilege changes.

·        For PaaS, unexpected FortiCloud IAM-user, mapped-profile, secondary-account, region, API, or service-setting changes.

·        Access to or modification of integration credentials, API keys, certificates, service accounts, mail settings, cloud settings, storage settings, update settings, or connected-product trust configuration.

·        Log deletion, report deletion, audit reduction, kernel-logging disablement, CLI-logging disablement, remote-forwarding interruption, notification suppression, or unexplained telemetry gaps.

·        Outbound communication to a rare, newly observed, unapproved, raw-IP, file-transfer, cloud-storage, paste, tunneling, or command-and-control-like destination.

·        Analysis results, scores, classifications, reports, indicators, quarantine actions, or delivery outcomes inconsistent with prior processing, duplicate submissions, independent analysis, endpoint detections, or network evidence.

·        Security-policy weakening, trust expansion, exclusion creation, alert suppression, logging degradation, credential creation, or administrative change in connected systems following suspected FortiSandbox compromise.

·        Similar suspicious request, event, configuration, logging, job, VM, threat, database, report, performance, resource, notification, or outbound behavior across multiple deployments.

Supporting Detection Signals

·        Requests from first-seen, rare, unauthorized, external, cloud-hosted, proxy, VPN, partner, or management sources.

·        HTTP methods, content types, parameter combinations, request sizes, header structures, encodings, user agents, authentication states, or response behavior inconsistent with normal clients.

·        Authentication failures, missing session context, privilege mismatches, unusual API use, or administrative access preceding suspicious requests.

·        Requests targeting rarely used, legacy, diagnostic, import, export, report, configuration, or privileged functions.

·        Native events showing unusual combinations of user, message, action, status, interface, type, subtype, message identifier, device, job, VM, sample, URL, report, database, threat, or resource context.

·        CLI commands or kernel activity by identities or paths that do not normally perform system-level operations.

·        Changes to DNS, NTP, proxy, routing, update, licensing, repository, mail, storage, remote logging, alerting, or management destinations.

·        New network connections, listening services, internal destinations, or changes in established appliance behavior.

·        Changes to local log levels, report retention, kernel logging, CLI logging, submission-event logging, event forwarding, or notification delivery.

·        Unexpected account creation, password change, privilege change, trusted-host change, key addition, certificate change, or API-token activity.

·        Unexpected export, download, deletion, replay, resubmission, rescan, reclassification, or report access.

·        Discrepancies between FortiSandbox findings and connected-product, endpoint, network, threat-intelligence, or independent-sandbox evidence.

·        FortiSandbox activity without corresponding maintenance, upgrade, support, integration, analysis, or change records.

Exploit Attempt and Instability Signals

·        Repeated requests containing shell metacharacters, encoded delimiters, substitutions, redirection syntax, interpreter fragments, nested expressions, or parameter values inconsistent with the endpoint.

·        Variation of encoding, delimiter, spacing, quoting, capitalization, parameter placement, content type, or HTTP method across repeated attempts.

·        Requests producing unusual response codes, timeouts, delayed responses, size changes, connection resets, service errors, or abnormal processing latency.

·        Blind-command indicators such as request-linked delays, DNS lookups, outbound connections, configuration changes, CLI activity, service changes, or resource changes without returned output.

·        Unauthenticated or minimally contextual requests followed by privileged native events.

·        Repeated access followed by a transition from failure to success or altered system behavior.

·        Web, API, application, worker, analysis, queue, database, report, or system failures near crafted requests.

·        Unexpected service restarts, watchdog recovery, VM resets, queue disruption, configuration-loading failures, report failures, notification failures, or HA changes.

·        Performance or Resource Events showing abnormal CPU, memory, storage, VM, queue, or network conditions after suspicious requests.

·        Short-lived CLI activity, system changes, outbound connections, or configuration changes created and reversed within a narrow time window.

·        Logging interruption, report deletion, kernel-logging disablement, CLI-logging disablement, forwarding interruption, or notification suppression following suspicious activity.

·        Similar exploit-like request and instability patterns across multiple nodes, clusters, PaaS instances, tenants, regions, or interfaces.

Outbound Communication Signals

·        Outbound DNS, HTTP, HTTPS, SSH, FTP, SFTP, SMB, SMTP, API, cloud-storage, raw-IP, paste, or tunneling communication following suspicious request or event activity.

·        Communication associated with an unexpected user, administrator, PaaS IAM identity, API identity, integration identity, CLI action, process, controller, service, or system context where visible.

·        Connections to rare, newly registered, first-seen, unapproved, residential-proxy, anonymization, cloud-hosted, dynamic-DNS, or threat-associated destinations.

·        DNS queries with high-entropy labels, encoded data, unusual subdomain length, or request-linked timing consistent with blind execution.

·        Transfer involving appliance configuration, reports, samples, analysis data, logs, certificates, credentials, API keys, tokens, or integration information.

·        Unexpected communication to management, backup, storage, mail, cloud, hypervisor, directory, endpoint, SIEM, SOAR, or connected Fortinet systems.

·        Repeated callbacks, beacon-like intervals, low-volume connections, long-duration sessions, or protocol use inconsistent with normal FortiSandbox activity.

·        Communication outside approved Fortinet update, licensing, reputation, DNS, NTP, mail, storage, logging, management, cloud, or support destinations.

·        New outbound activity following identity changes, credential access, database activity, report changes, service changes, logging degradation, or persistence.

·        Subsequent administrative or API activity in connected systems from a FortiSandbox source, credential, token, certificate, IAM identity, or integration identity.

Persistence and Post-Exploitation Signals (Conditional)

·        Creation or modification of appliance administrators, remote users, service accounts, API identities, access tokens, SSH keys, certificates, trusted hosts, or authentication settings.

·        For PaaS, unauthorized FortiCloud IAM-user, mapped-profile, secondary-account, API, region, or service-setting changes.

·        Unexpected CLI or system activity establishing recurring execution, altered services, startup behavior, persistent access, or modified management paths where visible.

·        Modification of FortiSandbox services, application components, analysis components, worker components, libraries, configuration, database state, or update content.

·        Changes to DNS, routing, proxy, mail, storage, logging, forwarding, update, licensing, repository, or management configuration.

·        Changes to analysis profiles, VM assignments, detonation behavior, sample handling, rescans, threat classification, verdict generation, quarantine actions, reporting, or result delivery.

·        Changes to log levels, report retention, kernel logging, CLI logging, submission-event logging, notifications, FortiAnalyzer forwarding, syslog forwarding, or administrator auditing.

·        Creation of exclusions, allowlists, trusted indicators, safe classifications, or analysis bypasses that reduce defensive effectiveness.

·        Credential, certificate, API-key, token, or integration-secret access followed by continued activity.

·        Unauthorized updates, content rollback, altered signature state, disabled validation, or unexpected update-source changes.

·        Repeated access after password reset, account disablement, service restart, patching, or session invalidation.

·        Persistence established in connected security, cloud, email, endpoint, storage, or management platforms through trusted integrations or stolen credentials.

Lateral Movement and Expansion Signals (Conditional)

·        FortiSandbox-originated administrative, API, SSH, HTTPS, or service-to-service access to connected security, cloud, storage, or management systems.

·        Use of appliance-stored API keys, certificates, passwords, tokens, SSH keys, mail credentials, cloud credentials, IAM identities, or service accounts against downstream systems.

·        Configuration, policy, trust, routing, logging, quarantine, alerting, or update changes in connected products following suspected compromise.

·        Access from FortiSandbox to systems not normally contacted by the deployment or integration identity.

·        Movement into management interfaces, hypervisors, backup platforms, storage systems, directory services, cloud consoles, code repositories, deployment platforms, or security-management systems.

·        Creation of accounts, credentials, tokens, service principals, API keys, certificates, access policies, or trusted integrations in downstream platforms.

·        Submission or distribution of malicious files, altered reports, manipulated indicators, false-safe verdicts, or modified intelligence through trusted FortiSandbox channels.

·        Suppression, deletion, reclassification, or redirection of alerts and events in SIEM, SOAR, email, endpoint, network, or cloud systems.

·        Similar suspicious activity across connected products using the same source, credential, token, certificate, API identity, IAM identity, integration identity, or time window.

·        Conversion of temporary FortiSandbox access into persistent downstream credentials, sessions, automation, API access, or management-plane control.

Signal Usage Constraints

Do not treat any single signal as compromise confirmation. Promote confidence only when evidence aligns by deployment, appliance, node, cluster, PaaS instance, tenant, region, source, request, session, administrator, remote user, IAM user, API identity, integration identity, action, status, type, subtype, message identifier, device, sample, URL, job, VM, threat, database, report, resource, service, configuration object, destination, connected product, change record, or bounded time window.

·        A vulnerable deployment does not prove exploitation.

·        A command-like request does not prove command execution.

·        A successful response does not prove exploitation succeeded.

·        A timeout, delay, crash, VM failure, queue disruption, resource spike, or service restart does not independently prove blind command execution.

·        A native event, CLI command, kernel event, report action, or administrator action may be legitimate during approved operations.

·        A configuration change requires identity, source, interface, action, status, workflow, deployment, and change context.

·        A rescan, threat change, verdict change, processing failure, report difference, or missing result does not independently prove manipulation.

·        Outbound communication requires destination, identity, service, purpose, and allowlist context.

·        Administrative activity from a trusted source, FortiCloud account, connected product, support path, or privileged identity may still be malicious.

·        Patch status, public exploitation, proof-of-concept availability, scanner findings, and CVE references are urgency inputs, not detection proof.

S23 — Telemetry Requirements

Endpoint and Process Execution Telemetry

·        Native System Events preserving documented timestamp, level, user, message, action, status, user-interface, type, subtype, message-identifier, device-identifier, and available log-type-specific context.

·        CLI-history telemetry preserving administrative commands where supported and enabled.

·        Kernel logging preserving internal system activity where supported and enabled.

·        Native administrator, authentication, configuration, update, integration, service, and system-state telemetry.

·        Hypervisor, infrastructure, console, privileged-access, and management-platform telemetry for physical or virtual deployments where available.

·        Process creation, parent-child lineage, command line, executable path, user, privilege, working directory, timestamp, session, and network destination only where supported through diagnostic, infrastructure, or vendor-assisted collection.

·        Remote-access telemetry for SSH, console, hypervisor console, privileged-access systems, vendor support, management systems, and administrative jump hosts.

·        Authorized appliance-administrator, remote-user, PaaS IAM, API, integration, service-account, support, maintenance, upgrade, and incident-response lookups.

·        Deployment-role classification for appliances, nodes, clusters, PaaS instances, reverse proxies, load balancers, management systems, connected products, and administrative workstations.

·        Where direct process telemetry is unavailable, use request, native-event, CLI, kernel, service, configuration, job, VM, threat, database, report, performance, resource, notification, and network evidence.

Memory and Execution Telemetry

·        Process-memory, module-load, syscall, privilege, code-injection, or execution telemetry involving FortiSandbox services only where supported through diagnostics, infrastructure monitoring, or vendor assistance.

·        Evidence of shell invocation, interpreter use, process spawning, file operations, privilege changes, or network-socket creation where technically available.

·        Execution activity associated with credential access, token access, certificate access, configuration modification, logging changes, analysis manipulation, database activity, report manipulation, or service control where visible.

·        Execution lineage connecting suspicious requests, CLI activity, kernel events, service changes, configuration changes, staging, and outbound communication.

·        Abnormal binary, library, script, service, or runtime-component activity where integrity or diagnostic telemetry is available.

·        Memory, syscall, process, and direct command telemetry must be treated as conditional enrichment rather than minimum required coverage.

·        FortiSandbox PaaS may not expose appliance-level execution telemetry to customers.

·        Absence of memory, syscall, process, or command-line evidence must not be used to rule out execution or compromise.

Crash and Fault Telemetry

·        Input, System, Job, VM, Threat, Database, Report, Performance, Resource, HA, Notification, and SNMP Events.

·        HTTP errors, service exceptions, application faults, worker failures, queue failures, database errors, permission errors, configuration-loading failures, and abnormal response latency.

·        Service startup, shutdown, restart, watchdog recovery, process termination, repeated recovery, and degraded-functionality events.

·        Job Events showing scan-flow interruption, rescan anomalies, processing failure, result-generation failure, report-generation failure, or delivery failure.

·        VM Events showing initialization failure, abnormal reset, interruption, assignment issue, resource problem, or repeated recovery.

·        Database Events showing unexpected errors, maintenance, access, modification, or state change.

·        Report Events showing generation, deletion, access, export, delivery, or failure anomalies.

·        Performance and Resource Events showing abnormal throughput, latency, CPU, memory, storage, queue, VM-capacity, or network conditions.

·        HA Events showing unexplained failover, synchronization failure, role change, node removal, or cluster change.

·        Notification or SNMP Events showing alert-delivery, trap, or destination failure.

·        Authentication faults, privilege failures, certificate errors, API failures, integration failures, update failures, and licensing anomalies.

·        Logging interruption, kernel-logging change, CLI-logging change, report deletion, forwarding failure, time change, and unexplained event gaps.

·        Fault telemetry must be correlated with suspicious request, identity, administrative, CLI, kernel, configuration, job, VM, database, report, or outbound activity.

·        Isolated service, VM, job, database, queue, notification, performance, or resource faults should remain operational signals.

File and Persistence Telemetry

·        File creation, read, write, modification, replacement, rename, copy, export, archive, encryption, deletion, permission, ownership, and timestamp telemetry only where exposed through diagnostics, infrastructure, storage, backup, or vendor-assisted collection.

·        Integrity coverage for system configuration, application configuration, service components, analysis components, database state, report stores, result stores, log stores, certificate stores, update content, and persistence-relevant paths where supported.

·        Detection of temporary scripts, command output, downloaded utilities, staged payloads, archives, exported configurations, credentials, certificates, API keys, tokens, and integration data where visible.

·        Native configuration telemetry for analysis profiles, VM assignments, detonation settings, submission handling, rescans, verdict generation, quarantine actions, reports, result delivery, logging, notification, and integrations.

·        Monitoring for administrator, remote-user, PaaS IAM, authentication, trusted-host, SSH-key, certificate, API-token, service-account, and privilege changes.

·        Monitoring for update, logging, report-retention, kernel-logging, CLI-logging, submission-event, forwarding, proxy, routing, DNS, NTP, mail, storage, and management changes.

·        Known-good inventories for critical configuration, identities, services, certificates, trusted hosts, integrations, content versions, analysis profiles, VM assignments, database state, reporting, verdict behavior, and logging state.

·        Backup and export comparison data for appliance configuration, identities, services, analysis settings, integrations, certificates, logging, reporting, database state, and update state.

·        Change-management, maintenance, support, upgrade, migration, backup, recovery, integration, and incident-response records.

·        File-level telemetry may be unavailable in FortiSandbox PaaS or other managed deployment models.

Network and Outbound Communication Telemetry

·        Firewall, reverse-proxy, load-balancer, web-application firewall, VPN, IDS, NDR, DNS, flow, packet, and FortiSandbox network telemetry covering inbound interface access and outbound communication.

·        Source IP, source port, destination IP, destination port, hostname, protocol, direction, timestamp, byte volume, duration, action, TLS metadata, session, administrator, IAM identity, API identity, integration identity, and process where available.

·        HTTP method, URI, path, parameter names, content type, request size, response code, response size, latency, user agent, authentication context, session identifier, and proxy chain.

·        Preservation of normalized or encoded request characteristics sufficient to identify command-like input without retaining unnecessary sensitive submission content.

·        Outbound DNS, HTTP, HTTPS, SSH, FTP, SFTP, SMB, SMTP, API, cloud-storage, raw-IP, tunneling, update, licensing, reputation, and management activity.

·        Destination reputation, first-seen status, domain age, ASN, country, hosting type, approved purpose, and allowlist enrichment.

·        Approved Fortinet update, licensing, reputation, DNS, NTP, mail, storage, logging, management, cloud, and vendor-support destination lookups.

·        Internal destination mapping for connected Fortinet, endpoint, SIEM, SOAR, storage, cloud, hypervisor, directory, backup, and management systems.

·        Network telemetry must preserve the relationship between suspicious inbound activity and subsequent FortiSandbox outbound or integration activity.

·        Network telemetry alone cannot prove appliance-side execution, analysis manipulation, database change, report manipulation, or credential access.

Web and Application Telemetry (Conditional Availability)

·        Input, System, Job, VM, Threat, Database, Report, Performance, Resource, HA, Notification, and SNMP Events.

·        Malware and network-alert logs where available, including malware, network-attack, botnet, and malicious-URL context.

·        FortiSandbox administrative, authentication, API, configuration, update, integration, reporting, logging, and system-health telemetry.

·        Request telemetry preserving endpoint, method, parameter names, source, session, user, administrator, IAM identity, API identity, authentication state, response, latency, and correlation identifiers where available.

·        Administrative telemetry preserving identity, role, source, user interface, action, status, target object, previous value, new value, timestamp, and change identifier where available.

·        Job telemetry preserving submission source, sample or URL identity, file hash, job, scan flow, analysis state, rescan activity, processing result, failure condition, verdict, report, and delivery context where available.

·        VM telemetry preserving VM identity, initialization, assignment, lifecycle, state, failure, recovery, and analysis relationship where available.

·        Submission-event telemetry for devices, network shares, ICAP clients, BCC adapters, MTA adapters, and other enabled sources.

·        Connected-product logs associated with FortiSandbox integrations.

·        API and service-to-service telemetry preserving integration identity, token or certificate identity, source, destination, action, object, result, and timestamp.

·        Remote FortiAnalyzer, FortiAnalyzer Cloud, syslog, or SIEM copies of FortiSandbox events.

·        Where request bodies cannot be retained, preserve endpoint, parameter names, encoding indicators, request size, source, response behavior, and correlation identifiers.

·        Where submission content cannot be retained, preserve hashes, URLs, identifiers, metadata, job history, verdict history, report history, and connected-control actions.

Telemetry Availability Requirements

·        Minimum viable coverage requires native System and Job Events, administrative activity, authentication, configuration changes, service health, reporting, logging state, and outbound-network telemetry.

·        Strong coverage requires relevant Input, VM, Threat, Database, Report, Performance, Resource, HA, Notification, and SNMP Events in addition to System and Job Events.

·        Strong exploit coverage requires suspicious inbound requests joined to native events, CLI history, kernel events, configuration activity, service changes, jobs, VMs, and outbound communication.

·        Strong analysis-control coverage requires submission, job, VM, profile, rescan, threat, verdict, report, quarantine, notification, and result-delivery context.

·        Highest confidence requires correlation across suspicious request activity, probable execution, unauthorized state change, analysis-control impact, logging degradation, credential or integration access, outbound activity, and downstream defensive changes.

·        Logging must preserve events and alerts at levels sufficient for investigation.

·        Kernel logging, CLI-history logging, and relevant submission-event logging should be enabled where supported and operationally acceptable.

·        Durable remote forwarding to FortiAnalyzer, FortiAnalyzer Cloud, syslog, SIEM, or another repository is required because local logs are limited to 1 GB and rotate.

·        Local report retention must be deliberately configured within the supported 1–28-day range.

·        High-value reports required beyond local retention must be exported or preserved externally.

·        Reverse proxies, firewalls, load balancers, or web-application firewalls must preserve sufficient metadata for FortiSandbox-facing requests.

·        Connected security platforms must retain administrative, API, policy, alert, quarantine, logging, and configuration events linked to FortiSandbox identities and integrations.

·        PaaS deployments require customer-accessible cloud, IAM, API, integration, job, administrative, service-status, and vendor-support evidence sufficient for investigation.

·        Clock synchronization and consistent normalization of deployment, device, identity, action, status, type, subtype, message identifier, sample, URL, job, VM, report, threat, resource, and integration context are mandatory.

·        Retention must support delayed discovery of manipulated verdicts, stolen credentials, persistence, or downstream integration abuse.

Telemetry Limitations and Gaps

·        FortiSandbox may not expose full operating-system, process, shell, command-line, syscall, memory, or file telemetry through standard customer-accessible logs.

·        FortiSandbox PaaS may limit direct access to service internals and low-level diagnostic evidence.

·        Kernel logging, CLI-history logging, or submission-event logging may be disabled, unavailable, incomplete, or rotated before investigation.

·        Local FortiSandbox logs retain up to 1 GB and may rotate before suspicious activity is identified.

·        Local report retention is limited to 1–28 days and defaults to eight days.

·        HTTP logs may omit request bodies, parameter values, decoded content, proxy headers, session context, or correlation identifiers.

·        Reverse proxies, VPNs, NAT, management systems, and trusted networks may obscure the original request source.

·        Command injection may be blind, asynchronous, delayed, encoded, fragmented, or executed through a background worker.

·        Short-lived commands may leave little persistent process or file evidence.

·        Native utilities or service functions may make malicious behavior appear operationally normal.

·        Privileged service contexts may reduce the visibility of a separate privilege-escalation step.

·        Service faults, VM failures, Job Event errors, Database Events, queue delays, Performance Events, and Resource Events may have legitimate causes.

·        FortiSandbox may record a configuration result without exposing the underlying execution path.

·        Analysis manipulation may be selective and may not create broad service degradation.

·        Legitimate upgrades, vendor support, troubleshooting, content updates, VM changes, integration changes, migration, backup, and recovery may resemble post-exploitation activity.

·        Verdicts may legitimately differ because of profile, VM, content, timing, network, engine, or submission-behavior differences.

·        Connected products may log FortiSandbox-driven activity differently or omit the originating integration identity.

·        Credentials, API keys, certificates, or tokens may be used downstream without preserving attribution to FortiSandbox.

·        Attackers may remove temporary changes or restore expected configuration before investigation.

·        Patching and hardening cannot determine whether exploitation, credential access, analysis manipulation, or downstream use occurred before remediation.

·        Telemetry gaps must reduce confidence and expand investigative requirements rather than support unsupported conclusions.

S24 — Detection Opportunities and Gaps

Detection Opportunities

·        FortiSandbox-facing request telemetry can identify command-like input, anomalous parameters, encoding changes, unusual methods, and repeated exploit attempts.

·        Input Events can identify unexpected submission sources, devices, adapters, files, URLs, or entry points.

·        System Events can identify unexpected identity, configuration, service, controller, daemon, update, and system activity.

·        CLI-history and kernel logging can provide direct command or internal-system evidence where enabled.

·        Job Events can trace file and URL scan flow and identify unexplained processing, rescan, verdict, report, or delivery changes.

·        VM Events can identify unexpected initialization, assignment, reset, failure, recovery, or lifecycle behavior.

·        Threat Events can identify suspicious disappearance, suppression, or reclassification of findings.

·        Database Events can identify unexpected database access, modification, failure, maintenance, or state changes.

·        Report Events can identify unauthorized generation, access, export, deletion, modification, suppression, or delivery.

·        Performance and Resource Events can identify abnormal throughput, latency, queue, CPU, memory, storage, or VM-capacity conditions.

·        HA Events can identify unexplained failover, synchronization, role, node, or cluster changes.

·        Notification and SNMP Events can identify suppressed, failed, redirected, or altered alert delivery.

·        Configuration auditing can identify unauthorized changes to identities, authentication, certificates, trusted hosts, APIs, integrations, analysis profiles, VMs, logging, reporting, updates, routing, proxy, DNS, mail, storage, or alerting.

·        Network telemetry can identify blind execution through request-linked DNS activity, callbacks, downloads, file transfer, tunneling, or rare destinations.

·        Duplicate-submission, historical-result, endpoint, network, threat-intelligence, and independent-analysis comparisons can identify suspicious verdict or report divergence.

·        Connected-product telemetry can identify unexpected policy, trust, alert, quarantine, logging, credential, or administrative changes initiated through FortiSandbox integrations.

·        Durable remote logging can preserve native evidence after local logs rotate.

·        External report preservation can retain high-value evidence beyond the 1–28-day local report-retention range.

·        Long-duration correlation can connect earlier suspicious requests with delayed credential use, persistence, analysis manipulation, or downstream security-control impact.

·        Multi-deployment correlation can identify similar request, event, configuration, logging, or outbound behavior across appliances, nodes, clusters, PaaS instances, tenants, or regions.

·        Known-good baselines for requests, identities, native events, services, jobs, VMs, profiles, threats, database state, reports, resources, destinations, integrations, and verdict behavior can reveal unauthorized deviation.

·        Change-management, support, maintenance, upgrade, integration, backup, recovery, and incident-response records can distinguish approved activity from suspicious behavior.

Detection Gaps

·        Direct appliance process, shell, command-line, syscall, memory, and file telemetry may be unavailable.

·        PaaS deployments may expose only limited customer-accessible service or diagnostic telemetry.

·        Kernel, CLI, or submission-event logging may not have been enabled before exploitation.

·        Local logs may rotate before suspicious activity is identified.

·        Reports may expire within 1–28 days unless preserved externally.

·        Request logging may omit the specific parameter or decoded value used for command injection.

·        Blind command execution may produce no response content or obvious front-end error.

·        Commands may execute asynchronously through workers, queues, analysis services, or background functions.

·        Attackers may use native utilities, short-lived commands, or service functions that leave minimal evidence.

·        Execution may occur under an expected privileged system or service context.

·        FortiSandbox may remain operational while selectively manipulating one submission, job, VM, threat finding, database record, verdict, report, alert, or integration.

·        Analysis-result manipulation may be difficult to distinguish from legitimate engine, profile, VM, content, timing, or network differences.

·        Service faults, VM failures, queue delays, database errors, performance degradation, or resource spikes may occur during ordinary processing.

·        Attackers may obtain credentials, certificates, API keys, tokens, or integration secrets and use them from another system.

·        Connected-product logs may not preserve the originating FortiSandbox identity, token, certificate, IAM identity, or API context.

·        Reverse proxies, VPNs, NAT, management systems, and trusted networks may obscure the original source.

·        Legitimate troubleshooting, vendor support, upgrade, recovery, VM change, content update, database maintenance, report administration, or integration activity may resemble compromise.

·        Attackers may alter logging and then restore normal settings before investigation.

·        Short retention may prevent correlation between initial execution and later analysis or downstream-control impact.

·        Multi-tenant or managed environments may restrict access to supporting infrastructure evidence.

·        A clean appliance or service review cannot rule out prior short-lived execution, stolen credentials, manipulated results, or downstream integration abuse.

·        Patching cannot establish whether exploitation occurred before remediation.

·        Vulnerable-state findings cannot establish whether execution, appliance compromise, PaaS compromise, or security-control manipulation occurred.

Compensating Controls

·        Use reverse-proxy, load-balancer, firewall, web-application firewall, VPN, IDS, NDR, DNS, flow, and packet logs when native request telemetry is incomplete.

·        Use the full native event and alert model when direct process telemetry is unavailable.

·        Enable CLI-history, kernel, and relevant submission-event logging where supported and operationally appropriate.

·        Forward logs to FortiAnalyzer, FortiAnalyzer Cloud, syslog, SIEM, or another durable repository.

·        Configure local report retention deliberately and preserve high-value reports externally.

·        Use hypervisor, infrastructure, console, storage, backup, and management-platform telemetry for physical or virtual deployments.

·        Use FortiCloud IAM, API, service-status, integration, and support evidence for PaaS deployments.

·        Use outbound DNS and network telemetry to identify blind execution, callbacks, downloads, file transfer, and tunneling.

·        Use configuration exports, backups, integrity comparisons, and known-good baselines to identify unauthorized state changes.

·        Use duplicate submissions, independent sandboxes, endpoint detections, network detections, and threat intelligence to validate verdict, threat, and report integrity.

·        Use connected-product logs to reconstruct integration activity and downstream impact.

·        Use administrator, privileged-access, IAM, API, certificate, token, and service-account records to reconstruct identity and credential use.

·        Use approved update, licensing, reputation, DNS, NTP, mail, storage, logging, management, cloud, and vendor-support destination lists to assess outbound communication.

·        Use change-management, maintenance, troubleshooting, upgrade, vendor-support, recovery, integration, and incident-response records to validate approved activity.

·        Use long-duration correlation to connect earlier suspicious requests with delayed identity changes, credential use, persistence, analysis manipulation, or connected-product changes.

·        Preserve FortiSandbox, proxy, firewall, DNS, flow, FortiAnalyzer, SIEM, SOAR, endpoint, email, cloud, and connected-product evidence before rotation.

·        Request Fortinet incident-support evidence when PaaS or managed-deployment telemetry is insufficient.

·        Treat exposure, public-exploitation, proof-of-concept, and scanner findings as investigation-prioritization inputs rather than compromise proof.

Non-Coverage Conditions

·        Vulnerable or unpatched FortiSandbox status without suspicious request, native-event, CLI, kernel, service, configuration, job, VM, threat, database, report, performance, resource, logging, outbound, credential, integration, or downstream evidence.

·        Internet exposure, management exposure, broad accessibility, or missing segmentation without locally observed exploit behavior.

·        Malformed, encoded, or command-like HTTP input that is blocked, rejected, or uncorrelated with FortiSandbox activity.

·        Routine administrator, remote-user, PaaS IAM, API, CLI, system, maintenance, upgrade, vendor-support, troubleshooting, migration, backup, recovery, database, report, or integration activity supported by approved context.

·        Expected Input, System, Job, VM, Threat, Database, Report, Performance, Resource, HA, Notification, or SNMP Events associated with legitimate operations.

·        Ordinary service restarts, VM failures, queue delays, analysis failures, database errors, performance changes, resource spikes, or appliance faults without exploit correlation.

·        Legitimate analysis-profile, VM, rescan, threat, verdict, quarantine, report, logging, update, certificate, user, IAM, API, or integration changes.

·        Verdict or report differences explained by engine, content, profile, VM, timing, network, or submission-behavior differences.

·        Outbound communication to approved Fortinet update, licensing, reputation, DNS, NTP, mail, storage, logging, management, cloud, or support destinations.

·        Administrative activity from approved sources using expected authentication, role, interface, action, status, workflow, deployment, and change context.

·        FortiSandbox-only, proxy-only, network-only, endpoint-only, cloud-only, identity-only, or connected-product-only anomalies without request, deployment, identity, action, status, event, sample, job, VM, threat, database, report, service, configuration, credential, integration, destination, or time-window linkage.

·        Unrelated connected-product or platform vulnerabilities that do not produce the report’s FortiSandbox command-execution and security-control-compromise behavior family.

·        Stolen passwords, stolen sessions, API abuse, certificate theft, malicious submission, or connected-product compromise that does not involve FortiSandbox command execution or service compromise.

·        Public proof-of-concept availability, exploitation reporting, CVE status, scanner findings, exploit names, or vendor advisories without locally observed behavioral evidence.

·        Absence of malware, persistence, reverse shell, new account, or command-and-control activity does not establish non-compromise because execution may be brief, blind, selective, or limited to configuration, credential, database, logging, analysis, report, or integration manipulation.

S25 — Ultra-Tuned Detection Engineering Rules

NDR

Detection Viability Assessment

NDR provides strong network-level coverage for FortiSandbox command-injection attempts, blind-execution callbacks, unusual appliance-originated communication, and downstream access to connected security or management systems. NDR cannot independently prove appliance-side command execution, configuration modification, credential access, or analysis-result manipulation when those behaviors do not produce observable network activity. Production deployment requires FortiSandbox asset identification, management-interface visibility, bidirectional traffic coverage, TLS inspection or equivalent HTTP metadata where permitted, approved-destination baselines, internal role mapping, and correlation with FortiSandbox native events in the SIEM or investigation workflow.

Rule

Suspicious FortiSandbox Request Followed by Execution-Consistent Network Behavior

Rule Format

Native NDR behavioral correlation analytic using bidirectional HTTP or HTTPS request metadata, response behavior, DNS activity, network flows, and FortiSandbox asset classification.

Detection Purpose

Detect suspicious command-injection activity against a FortiSandbox management or service interface when the request is followed by network behavior consistent with blind or successful command execution.

Detection Logic

Identify inbound HTTP or HTTPS requests to a validated FortiSandbox interface containing command-control characters, encoded metacharacters, nested substitutions, interpreter syntax, redirection operators, or parameter values inconsistent with the requested function. Correlate the request with one or more execution-consistent network outcomes from the same FortiSandbox system within 10 minutes, including a request-linked DNS query, first-seen outbound connection, callback to the originating infrastructure, download from an unusual destination, raw-IP communication, tunneling behavior, or communication through a protocol not normally initiated by the appliance.

Require the inbound request and subsequent network activity to align by FortiSandbox asset identity and bounded time window. Increase confidence when the outbound activity begins within 60 seconds, uses a destination related to the request source, contains high-entropy DNS labels, or is followed by repeated callbacks.

Exclude approved vulnerability scanners, penetration-testing systems, vendor-support activity, documented administrative testing, known Fortinet services, approved update infrastructure, licensing services, reputation services, DNS, NTP, mail relays, storage systems, remote-log collectors, and established integration destinations.

Required Telemetry

·        Bidirectional network visibility for FortiSandbox management, API, service, upload, reporting, and administrative interfaces.

·        HTTP method, URI, parameter names, content type, request size, response code, response size, latency, source, destination, session, and TLS metadata where available.

·        DNS queries and responses originating from FortiSandbox systems.

·        Network-flow or packet metadata for outbound connections from FortiSandbox.

·        FortiSandbox physical appliance, virtual appliance, cluster-node, and PaaS endpoint inventories.

·        Approved scanner, administrator, vendor-support, update, licensing, reputation, DNS, NTP, mail, storage, logging, cloud, and integration destination lists.

·        Destination reputation, first-seen status, domain age, ASN, hosting type, country, and internal asset-role enrichment.

Engineering Implementation Instructions

·        Define validated FortiSandbox assets by stable device, IP, hostname, cluster, tenant, region, and deployment identifiers.

·        Identify every externally and internally reachable FortiSandbox interface before enabling the analytic.

·        Decode URL encoding and normalize request parameters before evaluating command-control characters.

·        Detect command separators, substitutions, redirection operators, interpreter fragments, and nested expressions as behavioral features rather than relying on one static exploit string.

·        Maintain separate baselines for browser administration, API clients, service integrations, file submissions, URL submissions, and automated security-product communication.

·        Correlate inbound requests with outbound DNS and network activity by FortiSandbox asset and event time.

·        Use a 10-minute maximum correlation window and retain the original request timestamp for investigation.

·        Raise severity when the outbound destination is first-seen, unapproved, related to the source infrastructure, raw-IP based, high risk, or contacted repeatedly.

·        Suppress only validated scanners, approved testing, documented vendor support, and known operational destinations.

·        Do not suppress activity solely because the source is internal, authenticated, trusted, or located on a management network.

·        Deploy initially in hunt mode and validate against at least 30 days of normal FortiSandbox traffic.

·        Route detections for correlation with FortiSandbox System, Job, VM, Threat, Database, Report, Performance, Resource, HA, Notification, CLI, kernel, configuration, and administrative events.

DRI Assessment

High detection value when the exploit produces a callback, DNS lookup, download, tunnel, or other execution-linked network behavior. Detection reliability decreases when command execution is limited to appliance-local configuration, credential access, report manipulation, or logging changes.

DRI

8.7/10

TCR Assessment

The rule has strong operational viability when bidirectional request metadata and FortiSandbox outbound traffic are visible. TLS opacity, proxy normalization, asymmetric routing, shared source infrastructure, and incomplete asset identification reduce confidence.

Operational TCR

8.4/10

Full-Telemetry TCR

9.3/10

Limitations

·        Blind command execution may produce no external network behavior.

·        TLS encryption may prevent inspection of command-like request content.

·        A reverse proxy or load balancer may obscure the original source or request parameter.

·        FortiSandbox may legitimately contact new Fortinet or cloud infrastructure.

·        Vulnerability scanning can resemble exploit activity.

·        Outbound activity may be initiated by normal sample analysis rather than appliance compromise.

·        The rule cannot independently prove that the injected command executed.

·        Appliance-local changes without observable network activity are outside direct NDR coverage.

Detection Query Pattern

Implement the following logic in the native NDR rule builder, using the vendor’s decoded HTTP, DNS, flow, asset, reputation, and temporal-correlation fields:

MATCH inbound network session

WHERE destination_asset.role == "FortiSandbox"

  AND destination_service IN approved_fortisandbox_interfaces

  AND (

        http.request_contains_command_control_features == true

        OR http.parameter_function_mismatch == true

        OR http.request_encoding_anomaly == true

      )

  AND source_asset NOT IN approved_security_test_sources

FOLLOWED WITHIN 10 MINUTES BY outbound network session

WHERE source_asset == matched_fortisandbox_asset

  AND (

        dns.high_entropy_query == true

        OR destination.first_seen_for_asset == true

        OR destination IN high_risk_destinations

        OR destination.related_to_original_source == true

        OR protocol NOT IN approved_fortisandbox_outbound_protocols

        OR network.behavior IN (

             "callback",

             "download",

             "raw_ip_connection",

             "tunneling",

             "repeated_beacon"

           )

      )

  AND destination NOT IN approved_fortisandbox_destinations

GROUP BY fortisandbox_asset, original_source, outbound_destination

EMIT alert

WITH original_request, response_behavior, dns_activity,

     outbound_session, destination_context, and correlation_timestamps

Rule

FortiSandbox Outbound Callback or Command-and-Control-Like Communication

Rule Format

Native NDR anomaly and reputation analytic using FortiSandbox asset baselines, DNS behavior, destination novelty, protocol behavior, session timing, and outbound-flow characteristics.

Detection Purpose

Detect outbound communication from a FortiSandbox deployment that is inconsistent with approved updates, analysis activity, logging, storage, mail, cloud, management, or security-product integrations and may indicate attacker-controlled command execution or persistence.

Detection Logic

Monitor outbound connections from validated FortiSandbox assets and identify communication to destinations that are first-seen, rare, unapproved, recently registered, dynamically addressed, raw-IP based, anonymized, threat-associated, or inconsistent with the appliance’s normal communication profile.

Increase confidence when the communication uses an unusual protocol, originates shortly after suspicious inbound traffic, follows an administrator or configuration change, exhibits beacon-like periodicity, contains high-entropy DNS labels, transfers archive-like or configuration-sized data, or continues after the initiating inbound session has ended.

Require the destination to be outside approved Fortinet, update, licensing, reputation, DNS, NTP, mail, storage, cloud, remote-logging, management, and connected-product destinations.

Required Telemetry

·        Outbound network flows or packet metadata from all FortiSandbox assets.

·        DNS queries and responses.

·        TLS server name, certificate, JA3 or equivalent client metadata where available.

·        Session start, duration, bytes, packets, protocol, port, direction, and connection result.

·        FortiSandbox asset and deployment inventory.

·        Approved outbound-destination and protocol baselines.

·        Domain age, registration, reputation, ASN, hosting, geolocation, and first-seen enrichment.

·        Historical communication frequency by FortiSandbox asset and destination.

·        Optional correlation with suspicious inbound request, administrative, and configuration activity.

Engineering Implementation Instructions

·        Establish separate outbound baselines for physical appliances, virtual appliances, clusters, and PaaS-facing endpoints.

·        Maintain explicit allowlists for Fortinet update, licensing, reputation, cloud, vendor-support, DNS, NTP, mail, storage, logging, and management destinations.

·        Treat new Fortinet infrastructure as a validation requirement rather than automatically malicious.

·        Calculate destination novelty per FortiSandbox asset and across the FortiSandbox asset group.

·        Detect periodic callbacks using repeated-session intervals and bounded jitter.

·        Detect high-entropy or unusually long DNS labels.

·        Identify raw-IP HTTPS, uncommon outbound ports, protocol mismatch, and unexpected SSH, FTP, SFTP, SMB, or tunneling behavior.

·        Increase severity when communication follows suspicious inbound traffic, administrator changes, logging changes, service instability, or newly observed internal access.

·        Exclude network traffic generated by known malware-analysis detonation ranges when those ranges are architecturally separated and reliably attributable.

·        Do not globally suppress cloud-hosted destinations because attacker infrastructure may use major cloud providers.

·        Validate the analytic in hunt mode against at least 30 days of historical traffic.

·        Preserve session and packet evidence sufficient to distinguish appliance communication from traffic generated inside sandboxed analysis VMs.

DRI Assessment

Strong for externally communicating compromise and persistent access. Effectiveness depends on separating appliance-management traffic from malware detonation traffic and maintaining accurate destination baselines.

DRI

8.9/10

TCR Assessment

The rule is operationally reliable when FortiSandbox management-plane traffic is distinguishable from sandbox-VM egress. Shared NAT, incomplete segmentation, and rapidly changing cloud destinations can increase false positives.

Operational TCR

8.5/10

Full-Telemetry TCR

9.4/10

Limitations

·        FortiSandbox may legitimately connect to new cloud or Fortinet infrastructure.

·        Malware-analysis traffic can resemble command-and-control communication.

·        Shared NAT may prevent attribution to the appliance management plane.

·        Attackers may use approved cloud or storage destinations.

·        Appliance compromise that remains local will not trigger this rule.

·        Low-frequency or one-time exfiltration may evade beacon analytics.

·        Encrypted sessions may limit content inspection.

·        The rule cannot independently establish the method by which the appliance was compromised.

Detection Query Pattern

Implement the following behavior in the native NDR anomaly and correlation engine:

MATCH outbound network session

WHERE source_asset.role == "FortiSandbox"

  AND traffic_context != "validated_sandbox_vm_detonation"

  AND destination NOT IN approved_fortisandbox_destinations

  AND (

        destination.first_seen_for_asset == true

        OR destination.rare_for_fortisandbox_group == true

        OR destination.reputation IN ("suspicious", "malicious")

        OR destination.domain_age_days < local_new_domain_threshold

        OR destination.addressing == "raw_ip"

        OR destination.hosting_type IN ("dynamic_dns", "anonymizer", "residential_proxy")

        OR dns.high_entropy_query == true

        OR network.periodicity_score >= local_beacon_threshold

        OR protocol NOT IN approved_fortisandbox_outbound_protocols

      )

OPTIONALLY CORRELATE WITHIN 30 MINUTES TO

  suspicious_inbound_request

  OR fortisandbox_administrative_change

  OR fortisandbox_logging_change

  OR fortisandbox_service_instability

GROUP BY fortisandbox_asset, destination, protocol

EMIT alert

WITH destination_novelty, reputation, dns_features,

     session_pattern, byte_volume, protocol_context,

     related_inbound_activity, and asset_baseline

Rule

FortiSandbox-Originated Access to Unusual Internal Security or Management Systems

Rule Format

Native NDR east-west behavioral analytic using internal asset roles, FortiSandbox communication baselines, protocol expectations, destination criticality, identity context where available, and temporal correlation.

Detection Purpose

Detect potential lateral movement, integration-secret abuse, or downstream security-control compromise when a FortiSandbox system communicates with an internal administrative, security, identity, storage, cloud-management, or infrastructure system outside its approved integration pattern.

Detection Logic

Identify new, rare, or unauthorized communication from FortiSandbox assets to internal systems classified as security management, network management, identity infrastructure, hypervisors, backup platforms, storage systems, cloud-management gateways, SIEM, SOAR, endpoint management, email security, administrative portals, code repositories, deployment platforms, or other privileged infrastructure.

Increase confidence when the destination has never previously communicated with the FortiSandbox asset, the protocol is inconsistent with the approved integration, the connection follows suspicious inbound activity or outbound callback behavior, the source begins scanning multiple internal systems, or the activity is followed by configuration, policy, logging, credential, or administrative changes in the destination platform.

Exclude documented FortiSandbox integrations, approved management access, configured submission sources, remote logging, mail delivery, storage access, update infrastructure, monitoring, backup, and vendor-support workflows.

Required Telemetry

·        East-west network-flow or packet metadata for FortiSandbox systems.

·        Internal asset inventory and role classification.

·        Approved FortiSandbox integration and communication matrix.

·        Source, destination, port, protocol, direction, duration, bytes, packets, connection result, and timestamp.

·        Historical communication baselines by FortiSandbox asset and internal destination.

·        Internal destination criticality and management-plane classification.

·        Optional identity, certificate, API, or service-account context.

·        Optional SIEM correlation with downstream administrative or configuration events.

Engineering Implementation Instructions

·        Classify internal systems by role and criticality before enabling the analytic.

·        Document every approved FortiSandbox connection to Fortinet products, SIEM, SOAR, mail, storage, cloud, logging, management, and submission systems.

·        Baseline normal protocols, ports, connection frequency, direction, timing, and byte volume for each approved integration.

·        Detect first-seen and rare communication separately from known integrations using unusual protocols.

·        Increase severity for SSH, administrative HTTPS, SMB, database, hypervisor, directory, remote-management, or management-API access when not explicitly approved.

·        Identify fan-out behavior in which one FortiSandbox asset contacts multiple new internal destinations.

·        Correlate with suspicious inbound requests, callback behavior, credential-access indicators, and subsequent downstream configuration changes.

·        Suppress only documented integrations with validated source, destination, protocol, service, and purpose.

·        Do not suppress an entire destination role or management subnet.

·        Maintain separate logic for PaaS because customer-visible source addresses and service-to-service paths may differ from appliance deployments.

·        Validate in hunt mode and review all first-seen privileged-destination communications before production enablement.

·        Route high-confidence alerts to the owners of both FortiSandbox and the contacted destination platform.

DRI Assessment

Strong for downstream expansion and misuse of trusted FortiSandbox integrations. The rule has lower value when the attacker uses only established integrations and expected protocols without creating a detectable network anomaly.

DRI

8.8/10

TCR Assessment

Operational reliability is high when internal asset roles and FortiSandbox integration matrices are current. Incomplete inventories and undocumented management activity can materially increase false positives.

Operational TCR

8.6/10

Full-Telemetry TCR

9.5/10

Limitations

·        Established integrations may permit malicious activity over normal protocols.

·        Shared service accounts or API gateways may obscure the originating identity.

·        Some PaaS communication may not be visible as customer-controlled network flow.

·        Undocumented integrations may generate false positives.

·        A network connection does not prove successful authentication or downstream compromise.

·        The rule cannot see manipulation performed entirely through an existing encrypted session without behavioral change.

·        Downstream configuration or policy changes require confirmation from destination-platform telemetry.

·        Internal traffic segmentation and sensor placement may limit visibility.

Detection Query Pattern

Implement the following logic using the NDR platform’s internal asset-role, communication-baseline, protocol, and temporal-correlation capabilities:

MATCH internal network session

WHERE source_asset.role == "FortiSandbox"

  AND destination_asset.role IN (

        "security_management",

        "network_management",

        "identity_infrastructure",

        "siem",

        "soar",

        "endpoint_management",

        "email_security",

        "cloud_management",

        "hypervisor",

        "backup",

        "storage",

        "code_repository",

        "deployment_platform",

        "administrative_portal"

      )

  AND (

        communication.first_seen_pair == true

        OR communication.rare_pair == true

        OR protocol NOT IN approved_integration_protocols[source_asset, destination_asset]

        OR destination NOT IN approved_fortisandbox_integrations[source_asset]

        OR source_asset.internal_fanout_score >= local_fanout_threshold

      )

OPTIONALLY CORRELATE WITHIN 60 MINUTES TO

  suspicious_fortisandbox_request

  OR fortisandbox_outbound_callback

  OR fortisandbox_identity_or_logging_change

  OR downstream_administrative_or_configuration_change

GROUP BY fortisandbox_asset, destination_asset, protocol

EMIT alert

WITH asset_roles, destination_criticality, pair_novelty,

     protocol_deviation, fanout_context, related_fortisandbox_activity,

     and downstream_change_context

SentinelOne

Detection Viability Assessment

SentinelOne provides strong correlated coverage when FortiSandbox events, reverse-proxy or firewall traffic, DNS, network-flow data, and connected-product telemetry are ingested into Singularity AI SIEM or Singularity Data Lake. PowerQuery can search, transform, aggregate, join, and combine third-party telemetry without requiring a SentinelOne agent on the FortiSandbox appliance. Log-based detections should generate alerts and investigation workflows. Endpoint containment actions must not be assigned to FortiSandbox unless a supported SentinelOne agent and approved response policy are present.

Rule

Suspicious FortiSandbox Request Followed by Appliance-State Change

Rule Format

SentinelOne PowerQuery detection using normalized FortiSandbox request, administrative, configuration, service, CLI, kernel, job, VM, and network telemetry.

Detection Purpose

Detect a suspicious request to a FortiSandbox interface followed by native appliance activity consistent with unauthorized command execution or system-state modification.

Detection Logic

Identify requests to validated FortiSandbox management, API, service, upload, reporting, analysis, or administrative interfaces that contain command separators, encoded metacharacters, nested substitutions, interpreter fragments, redirection operators, or abnormal parameter structures.

Correlate the request with FortiSandbox activity from the same appliance within 10 minutes involving unexpected administrative action, CLI or kernel activity, service operation, configuration change, account change, logging change, update activity, database activity, report modification, Job Event anomaly, VM Event anomaly, or outbound communication.

Increase severity when the request was unauthenticated, originated from an unapproved source, or was followed by multiple distinct appliance-change categories.

Exclude approved vulnerability testing, documented vendor support, authorized maintenance, expected upgrades, and established administrative automation.

Required Telemetry

·        FortiSandbox System, Job, VM, Database, Report, Performance, Resource, HA, Notification, Input, and Threat Events where relevant.

·        FortiSandbox administrator, authentication, configuration, CLI-history, kernel, service, update, logging, and API events where available.

·        Reverse-proxy, firewall, web-application firewall, VPN, or application-access logs covering FortiSandbox interfaces.

·        Source IP, destination appliance, HTTP method, request path, parameter metadata, authentication state, response, session, and timestamp.

·        FortiSandbox appliance, cluster-node, PaaS-instance, tenant, and region inventory.

·        Approved administrator, scanner, support, maintenance, API-client, source-network, and change-window lookups.

·        Normalized appliance, identity, action, status, event category, interface, and timestamp fields.

Engineering Implementation Instructions

·        Ingest FortiSandbox syslog or CEF events into a dedicated normalized source type.

·        Normalize appliance identity across FortiSandbox, proxy, firewall, DNS, and network events.

·        Map user, action, status, interface, type, subtype, message identifier, device identifier, job, VM, sample, URL, and destination fields where available.

·        Decode URL-encoded values before evaluating command-control features.

·        Maintain approved scanner, source, administrator, API-client, support, and maintenance lists as locally mapped fields or ingestion-time enrichments.

·        Use a 10-minute request-to-activity correlation window.

·        Require one suspicious request and at least one subsequent FortiSandbox state-change event.

·        Increase severity when multiple event categories follow the request.

·        Do not suppress activity solely because the request was authenticated or originated internally.

·        Validate the query in hunt mode before enabling alert generation.

·        Generate an alert only. Do not initiate response actions unless a supported response integration and approved response policy are present.

DRI Assessment

High detection value when request telemetry and FortiSandbox native events are both available. Reliability decreases when request parameters are unavailable or execution produces no logged appliance-state change.

DRI

9.0/10

TCR Assessment

The rule is operationally strong after FortiSandbox field normalization, asset mapping, and maintenance exclusions. Inconsistent appliance identifiers or incomplete parsing can prevent reliable correlation.

Operational TCR

8.7/10

Full-Telemetry TCR

9.5/10

Limitations

·        Encrypted traffic may prevent inspection of request parameters.

·        FortiSandbox may not expose direct command-line or process telemetry.

·        Blind command execution may produce limited state changes.

·        Legitimate maintenance may create similar events.

·        Proxy or NAT behavior may obscure the original request source.

·        Consistent appliance identity is required across the joined data sources.

·        The rule cannot prove the exact command that executed.

·        Local activity producing no native event or network change may remain undetected.

Detection Query Pattern

Use the following PowerQuery after mapping the placeholder source types, fields, and approved-value fields to the local SentinelOne schema:

| join

    request = (

        $source_type = "fortisandbox_http"

        && destination_asset_role = "FortiSandbox"

        && source_ip_is_approved_test_source = false

        | let command_input =

            (

                request_parameter matches "(?i)(;|&&|\\|\\||`|\\$\\(|\\$\\{|>|<|%3[bB]|%26%26|%7[cC]%7[cC])"

                OR request_parameter matches "(?i)(/bin/(sh|bash)|powershell|python|perl|wget|curl)"

            ) ? 1 : 0

        | filter command_input = 1

        | columns appliance_id,

                  request_time = timestamp,

                  source_ip,

                  request_method,

                  request_path,

                  authentication_state

    ),

    activity = (

        $source_type = "fortisandbox"

        && event_category in (

            "system",

            "administrative",

            "configuration",

            "cli",

            "kernel",

            "service",

            "update",

            "database",

            "report",

            "job",

            "vm",

            "logging",

            "network"

        )

        && action_is_approved = false

        | columns appliance_id,

                  activity_time = timestamp,

                  event_category,

                  user,

                  action,

                  status,

                  message

    )

on

    appliance_id

| let elapsed_seconds = (activity.activity_time - request.request_time) / 1000000000

| filter elapsed_seconds >= 0 && elapsed_seconds <= 600

| group activity_count = count(),

        distinct_activity_categories = estimate_distinct(activity.event_category)

    by appliance_id,

       request.source_ip,

       request.request_time,

       request.request_method,

       request.request_path,

       request.authentication_state

| filter activity_count >= 1

| sort -distinct_activity_categories, -activity_count

Rule

FortiSandbox Analysis-Control, Identity, and Logging Manipulation

Rule Format

SentinelOne PowerQuery detection using normalized FortiSandbox administrative, configuration, identity, analysis, VM, job, threat, database, report, notification, and logging events.

Detection Purpose

Detect unauthorized changes that may weaken FortiSandbox analysis, alter verdict production, suppress evidence, establish access, or compromise trusted integrations.

Detection Logic

Identify FortiSandbox activity involving administrator creation, privilege modification, trusted-host changes, certificate or token changes, API or integration changes, logging reduction, report deletion, notification suppression, analysis-profile changes, VM changes, rescan changes, threat reclassification, verdict modification, quarantine modification, database changes, or result-delivery changes.

Prioritize actions performed by an unusual identity, source, interface, API client, or administrative path. Increase confidence when multiple control areas are modified within 30 minutes or identity or analysis changes occur with logging, report, forwarding, or notification degradation.

For PaaS deployments, include unexpected FortiCloud IAM-user, mapped-profile, secondary-account, API, region, or service-setting changes.

Exclude approved maintenance, authorized content updates, documented profile tuning, expected VM administration, scheduled database maintenance, report-retention activity, and validated incident-response actions.

Required Telemetry

·        FortiSandbox System, Job, VM, Threat, Database, Report, Notification, SNMP, and administrative events.

·        Identity, authentication, API, certificate, trusted-host, administrator, and privilege-change telemetry.

·        Analysis-profile, VM, rescan, verdict, quarantine, report, database, logging, forwarding, and notification telemetry.

·        FortiCloud IAM and PaaS administrative logs where applicable.

·        Source IP, appliance identity, user, role, action, status, interface, event category, message, and timestamp.

·        Approved administrator, API-client, service-account, support, maintenance, and change-management enrichment.

·        Baselines for identities, actions, interfaces, analysis profiles, VMs, logging state, reports, and integrations.

Engineering Implementation Instructions

·        Normalize relevant control-changing events into consistent event categories.

·        Create a derived control-area field for identity, analysis, VM, threat, database, report, logging, notification, and integration changes.

·        Maintain separate baselines for appliance administrators, remote users, API identities, integration identities, and FortiCloud IAM users.

·        Require successful or completed changes unless failed attempts are being investigated separately.

·        Correlate by appliance or PaaS instance, identity, and 30-minute time bucket.

·        Increase severity when multiple control areas are changed.

·        Increase severity when identity or analysis changes occur with logging, report, forwarding, or notification changes.

·        Use ingestion-time enrichment fields to identify approved service identities, change records, support actions, and maintenance windows.

·        Do not suppress privileged identities globally.

·        Validate expected administrative workflows before enabling alerts.

·        Generate an alert or approved third-party investigation workflow.

DRI Assessment

Strong detection value for security-control compromise that produces native administrative or configuration events. The rule is less effective when attackers change state through unlogged operating-system access or restore settings before collection.

DRI

9.2/10

TCR Assessment

The rule is production viable when FortiSandbox event parsing, identity normalization, approved-change enrichment, and control-area mapping are complete.

Operational TCR

8.9/10

Full-Telemetry TCR

9.6/10

Limitations

·        Some changes may appear only as generic system messages.

·        Legitimate profile, VM, database, report, or logging administration can resemble malicious activity.

·        PaaS telemetry may differ from appliance telemetry.

·        Attackers may use an approved administrator or API identity.

·        Some analysis manipulation may not produce a distinct configuration event.

·        Forwarding failure may cause evidence loss.

·        Restored settings may hide the final compromised state.

·        The rule cannot independently prove command injection.

Detection Query Pattern

Use the following PowerQuery after creating the locally normalized event-category and enrichment fields:

$source_type = "fortisandbox"

&& event_category in (

    "user",

    "administrator",

    "iam",

    "authentication",

    "trusted_host",

    "analysis_profile",

    "rescan",

    "verdict",

    "quarantine",

    "vm",

    "threat",

    "database",

    "report",

    "logging",

    "forwarding",

    "notification",

    "snmp",

    "certificate",

    "token",

    "api",

    "integration"

)

&& status in (

    "success",

    "completed",

    "changed",

    "enabled",

    "disabled",

    "deleted",

    "created"

)

&& approved_service_identity = false

&& approved_change = false

&& maintenance_window = false

&& support_activity = false

| let control_area =

    (

        event_category in (

            "user",

            "administrator",

            "iam",

            "authentication",

            "trusted_host"

        )

    ) ? "identity" :

    (

        event_category in (

            "analysis_profile",

            "rescan",

            "verdict",

            "quarantine"

        )

    ) ? "analysis" :

    (

        event_category = "vm"

    ) ? "vm" :

    (

        event_category = "threat"

    ) ? "threat" :

    (

        event_category = "database"

    ) ? "database" :

    (

        event_category = "report"

    ) ? "report" :

    (

        event_category in (

            "logging",

            "forwarding"

        )

    ) ? "logging" :

    (

        event_category in (

            "notification",

            "snmp"

        )

    ) ? "notification" :

    "integration"

| group event_count = count(),

        distinct_control_areas = estimate_distinct(control_area),

        distinct_actions = estimate_distinct(action)

    by appliance_id,

       user,

       source_ip,

       user_interface,

       time_bucket_30m

| filter distinct_control_areas >= 2

    OR distinct_actions >= 2

    OR event_count >= local_single_area_change_threshold

| sort -distinct_control_areas, -distinct_actions, -event_count

Rule

FortiSandbox Outbound Communication or Downstream Integration Abuse

Rule Format

SentinelOne PowerQuery detection using FortiSandbox, DNS, firewall, network-flow, API, and connected-security-platform telemetry.

Detection Purpose

Detect suspicious FortiSandbox-originated communication or use of trusted integrations that may indicate command execution, credential theft, lateral movement, or downstream security-control compromise.

Detection Logic

Identify outbound communication from a validated FortiSandbox system to a first-seen, rare, unapproved, threat-associated, raw-IP, dynamic-DNS, anonymization, file-transfer, tunneling, or unusual internal management destination.

Also identify FortiSandbox-originated or FortiSandbox-credentialed administrative and API activity affecting connected security, network, cloud, email, endpoint, SIEM, SOAR, storage, or management systems outside the approved integration pattern.

Increase confidence when the activity follows suspicious request, identity, logging, configuration, analysis, service, or credential-access activity.

Exclude approved Fortinet services, updates, licensing, reputation services, DNS, NTP, mail, storage, remote logging, management, and documented integrations.

Required Telemetry

·        DNS, firewall, proxy, NDR, network-flow, VPN, and TLS metadata.

·        FortiSandbox appliance, cluster, PaaS, tenant, and region inventory.

·        Approved outbound-destination and integration enrichment.

·        Destination novelty, reputation, hosting type, domain age, geolocation, and internal asset role.

·        FortiSandbox API, certificate, token, service-account, and integration-identity context where available.

·        Connected-product administrative, configuration, policy, logging, alerting, quarantine, credential, and API events.

·        Source, destination, protocol, port, identity, action, result, and timestamp.

Engineering Implementation Instructions

·        Normalize network and connected-product events into shared appliance, identity, destination, action, and timestamp fields.

·        Distinguish appliance-management traffic from sandbox-VM detonation traffic.

·        Maintain approved destinations and approved integration actions as ingestion-time enrichment fields.

·        Calculate destination novelty before the query or map it from the relevant telemetry source.

·        Identify external destinations separately from internal management destinations.

·        Increase severity for privileged protocols or APIs outside the approved integration pattern.

·        Do not globally allow cloud-hosted destinations.

·        Do not treat a connection or API call alone as proof of downstream compromise.

·        Validate at least 30 days of FortiSandbox and integration activity before production alerting.

·        Generate an alert or approved third-party investigation workflow.

DRI Assessment

Strong for compromise involving outbound communication, integration-secret misuse, or downstream security-system activity. Detection value decreases when attackers use approved destinations and expected integration actions.

DRI

9.1/10

TCR Assessment

The rule is operationally strong when FortiSandbox management traffic, detonation traffic, integration identities, and connected-product activity are consistently normalized.

Operational TCR

8.8/10

Full-Telemetry TCR

9.6/10

Limitations

·        Malware-detonation traffic can resemble appliance-originated malicious communication.

·        Shared NAT may complicate attribution.

·        Established integrations may be abused through normal protocols.

·        Connected products may not retain the originating FortiSandbox identity.

·        PaaS network paths may not be fully visible.

·        Attackers may use approved cloud or storage destinations.

·        A connection or API call does not prove downstream compromise.

·        Appliance-local compromise without network or integration activity will not trigger the rule.

Detection Query Pattern

Use the following PowerQuery after mapping the local source types and enrichment fields:

| union

    (

        $source_type in (

            "dns",

            "firewall",

            "proxy",

            "ndr",

            "network_flow"

        )

        && source_asset_role = "FortiSandbox"

        && validated_sandbox_vm_detonation = false

        && approved_destination = false

        && (

            destination_first_seen = true

            OR destination_rare_for_asset = true

            OR destination_reputation in (

                "suspicious",

                "malicious"

            )

            OR destination_address_type = "raw_ip"

            OR destination_hosting_type in (

                "dynamic_dns",

                "anonymizer",

                "residential_proxy"

            )

            OR destination_domain_age_days < local_new_domain_threshold

            OR approved_protocol = false

        )

        | columns timestamp,

                  appliance_id,

                  source_ip,

                  destination,

                  destination_role,

                  protocol,

                  activity_type = "network"

    ),

    (

        $source_type in (

            "fortigate",

            "fortimanager",

            "fortianalyzer",

            "fortimail",

            "fortiweb",

            "siem",

            "soar",

            "endpoint_security",

            "cloud_security",

            "email_security",

            "storage_management"

        )

        && source_identity_type in (

            "fortisandbox_api",

            "fortisandbox_certificate",

            "fortisandbox_service_account"

        )

        && (

            approved_integration_destination = false

            OR approved_integration_action = false

        )

        | columns timestamp,

                  appliance_id,

                  source_ip,

                  destination = destination_asset,

                  destination_role,

                  protocol = api_service,

                  activity_type = "integration"

    )

| group activity_count = count(),

        distinct_activity_types = estimate_distinct(activity_type)

    by appliance_id,

       destination,

       destination_role,

       protocol,

       time_bucket_15m

| filter activity_count >= 1

| sort -distinct_activity_types, -activity_count

Splunk

Detection Viability Assessment

Splunk provides strong coverage when FortiSandbox events, management-interface traffic, DNS, network-flow data, and connected-product telemetry are indexed and normalized. SPL can correlate suspicious requests with subsequent appliance changes, identify security-control manipulation, and detect outbound or downstream integration abuse. Production deployment requires local index, source type, field, asset, identity, destination, and approved-activity mappings.

Rule

Suspicious FortiSandbox Request Followed by Appliance-State Change

Rule Format

Splunk SPL event-based correlation search or risk rule using FortiSandbox interface and native-event telemetry.

Detection Purpose

Detect a suspicious request to a FortiSandbox interface followed by appliance activity consistent with unauthorized command execution or system-state modification.

Detection Logic

Identify command-like requests to validated FortiSandbox management, API, service, upload, reporting, analysis, or administrative interfaces. Correlate those requests with FortiSandbox administrative, configuration, CLI, kernel, service, update, database, report, job, VM, logging, or outbound-network activity from the same appliance within 10 minutes.

Increase confidence when the request was unauthenticated, originated from an unapproved source, or was followed by multiple appliance-change categories.

Exclude approved vulnerability testing, vendor support, maintenance, upgrades, and documented automation.

Required Telemetry

·        FortiSandbox native events forwarded to Splunk.

·        Reverse-proxy, firewall, web-application firewall, VPN, or application-access logs.

·        Appliance identity, source IP, request path, request parameters, authentication state, event category, action, status, and timestamp.

·        Approved scanner, administrator, support, maintenance, automation, and source-network lookups.

·        Consistent FortiSandbox asset identifiers across data sources.

Engineering Implementation Instructions

·        Map the placeholder indexes and source types to local data sources.

·        Normalize FortiSandbox appliance identity into appliance_id.

·        Decode request parameters before applying command-feature matching.

·        Normalize FortiSandbox activity into event_category.

·        Create lookup fields for approved testing and approved appliance actions.

·        Schedule the search frequently enough to preserve the 10-minute correlation window.

·        Validate the search in hunt mode before creating findings or risk events.

·        Assign risk to the FortiSandbox appliance rather than the external source alone.

·        Do not configure automated containment unless an approved response integration exists.

DRI Assessment

High detection value when request metadata and native FortiSandbox events are available. Reliability decreases when encrypted traffic hides request parameters or command execution produces no recorded state change.

DRI

9.1/10

TCR Assessment

The rule is production viable after source normalization, asset mapping, and approved-activity enrichment. Inconsistent appliance identifiers can break correlation.

Operational TCR

8.9/10

Full-Telemetry TCR

9.6/10

Limitations

·        Encrypted traffic may prevent request inspection.

·        FortiSandbox may not expose direct process or command-line telemetry.

·        Legitimate maintenance may produce similar events.

·        Proxy or NAT activity may obscure the original source.

·        Blind execution may produce no recorded appliance change.

·        The rule cannot prove the exact command executed.

Detection Query Pattern

Use the following SPL after mapping the placeholder indexes, source types, fields, and lookups:

index=<web_or_network_index> sourcetype=<fortisandbox_interface_sourcetype>

| eval appliance_id=coalesce(appliance_id, dest, dvc, host)

| eval request_value=urldecode(coalesce(request_parameter, uri_query, url, request))

| eval suspicious_request=if(

    match(request_value, "(?i)(;|&&|\|\||`|\$\(|\$\{|>|<|%3b|%26%26|%7c%7c)")

    OR match(request_value, "(?i)(/bin/(sh|bash)|powershell|python|perl|wget|curl)"),

    1,

    0

  )

| where suspicious_request=1

| lookup approved_fortisandbox_test_sources source_ip OUTPUT is_approved_test

| where coalesce(is_approved_test, "false")!="true"

| eval request_time=_time

| fields appliance_id request_time source_ip http_method uri_path authentication_state

| join type=inner appliance_id

    [

      search index=<fortisandbox_index> sourcetype=<fortisandbox_event_sourcetype>

      | eval appliance_id=coalesce(appliance_id, devid, dvc, host)

      | eval event_category=lower(coalesce(event_category, subtype, type))

      | where event_category IN (

          "system",

          "administrative",

          "configuration",

          "cli",

          "kernel",

          "service",

          "update",

          "database",

          "report",

          "job",

          "vm",

          "logging",

          "network"

        )

      | lookup approved_fortisandbox_actions action OUTPUT is_approved_action

      | where coalesce(is_approved_action, "false")!="true"

      | eval activity_time=_time

      | fields appliance_id activity_time event_category user action status message

    ]

| eval elapsed_seconds=activity_time-request_time

| where elapsed_seconds>=0 AND elapsed_seconds<=600

| stats count AS activity_count

        dc(event_category) AS distinct_activity_categories

        values(event_category) AS activity_categories

        values(action) AS actions

        values(user) AS users

        min(activity_time) AS first_activity_time

        max(activity_time) AS last_activity_time

    BY appliance_id source_ip request_time http_method uri_path authentication_state

| where activity_count>=1

| eval risk_object=appliance_id, risk_object_type="system"

| eval risk_score=case(

    distinct_activity_categories>=3, 75,

    distinct_activity_categories=2, 60,

    true(), 45

  )

Rule

FortiSandbox Analysis-Control, Identity, and Logging Manipulation

Rule Format

Splunk SPL event-based detection or risk rule using normalized FortiSandbox administrative and control-change events.

Detection Purpose

Detect unauthorized changes that may weaken FortiSandbox analysis, alter verdicts or reports, suppress evidence, establish access, or compromise trusted integrations.

Detection Logic

Identify successful changes involving administrators, remote users, PaaS IAM users, trusted hosts, certificates, API credentials, analysis profiles, VM settings, rescans, verdicts, quarantine actions, threat classifications, databases, reports, logging, forwarding, notifications, or integrations.

Increase confidence when an identity changes multiple control areas within 30 minutes or when identity or analysis changes occur with logging, report, forwarding, or notification changes.

Exclude approved maintenance, support, content updates, profile tuning, database maintenance, report-retention activity, and incident-response actions.

Required Telemetry

·        FortiSandbox administrative, System, Job, VM, Threat, Database, Report, Notification, SNMP, logging, and configuration events.

·        FortiCloud IAM events for PaaS where applicable.

·        Appliance identity, user, source IP, interface, event category, action, status, and timestamp.

·        Approved maintenance, support, and change-record lookups.

·        Baselines for administrative identities and expected control changes.

Engineering Implementation Instructions

·        Normalize each event into a consistent control_area.

·        Normalize appliance and PaaS service identity into appliance_id.

·        Limit production alerting to successful or completed changes.

·        Enrich events with change records, maintenance windows, and support activity.

·        Aggregate by appliance and identity over 30 minutes.

·        Raise risk when multiple control areas or multiple high-impact actions occur.

·        Do not globally suppress privileged administrators.

·        Validate normal administrative workflows before production deployment.

DRI Assessment

Strong detection value for security-control changes represented in FortiSandbox telemetry. The rule is less effective when changes occur through unlogged system access.

DRI

9.3/10

TCR Assessment

The rule is production viable when event categorization and approved-change enrichment are complete.

Operational TCR

9.0/10

Full-Telemetry TCR

9.7/10

Limitations

·        Some changes may appear only in generic system messages.

·        Legitimate administration can resemble malicious behavior.

·        Appliance and PaaS event schemas may differ.

·        Attackers may use approved identities.

·        Restored settings may hide the compromised state.

·        The rule does not independently prove command injection.

Detection Query Pattern

Use the following SPL after mapping local FortiSandbox fields and lookups:

index=<fortisandbox_index> sourcetype=<fortisandbox_event_sourcetype>

| eval appliance_id=coalesce(appliance_id, devid, dvc, host)

| eval event_category=lower(coalesce(event_category, subtype, type))

| eval normalized_status=lower(coalesce(status, result))

| where normalized_status IN (

    "success",

    "successful",

    "completed",

    "changed",

    "enabled",

    "disabled",

    "deleted",

    "created"

  )

| eval control_area=case(

    event_category IN ("user","administrator","iam","authentication","trusted_host"), "identity",

    event_category IN ("analysis_profile","rescan","verdict","quarantine"), "analysis",

    event_category="vm", "vm",

    event_category="threat", "threat",

    event_category="database", "database",

    event_category="report", "report",

    event_category IN ("logging","forwarding"), "logging",

    event_category IN ("notification","snmp"), "notification",

    event_category IN ("certificate","token","api","integration"), "integration",

    true(), "other"

  )

| where control_area!="other"

| lookup approved_fortisandbox_changes change_id OUTPUT is_approved_change

| where coalesce(is_approved_change, "false")!="true"

| where coalesce(maintenance_window, "false")!="true"

| where coalesce(support_activity, "false")!="true"

| bin _time span=30m

| stats count AS event_count

        dc(control_area) AS distinct_control_areas

        dc(action) AS distinct_actions

        values(control_area) AS control_areas

        values(action) AS actions

        values(status) AS statuses

    BY time applianceid user source_ip user_interface

| where distinct_control_areas>=2

    OR distinct_actions>=2

    OR event_count>=<local_single_area_change_threshold>

| eval risk_object=appliance_id, risk_object_type="system"

| eval risk_score=case(

    distinct_control_areas>=3, 80,

    distinct_control_areas=2, 65,

    true(), 50

  )

Rule

FortiSandbox Outbound Communication or Downstream Integration Abuse

Rule Format

Splunk SPL event-based correlation search or risk rule using network and connected-product telemetry.

Detection Purpose

Detect suspicious FortiSandbox-originated communication or trusted-integration activity that may indicate command execution, credential misuse, lateral movement, or downstream security-control compromise.

Detection Logic

Identify FortiSandbox communication to first-seen, rare, unapproved, threat-associated, raw-IP, dynamic-DNS, anonymization, file-transfer, tunneling, or unusual internal management destinations.

Also identify FortiSandbox API, certificate, token, or service-account activity against connected systems when the destination or action falls outside the approved integration pattern.

Exclude known detonation traffic and approved Fortinet, update, licensing, reputation, DNS, NTP, mail, storage, logging, management, and integration activity.

Required Telemetry

·        DNS, firewall, proxy, NDR, network-flow, VPN, and TLS data.

·        Connected-product administrative and API events.

·        FortiSandbox asset and integration-identity inventory.

·        Approved destination, protocol, integration, and action lookups.

·        Destination novelty, reputation, domain age, hosting type, and internal asset role.

·        Source, destination, protocol, identity, action, result, and timestamp.

Engineering Implementation Instructions

·        Normalize FortiSandbox network and integration activity into common fields.

·        Distinguish appliance-management traffic from sandbox-VM detonation traffic.

·        Enrich network events with destination reputation and novelty before correlation.

·        Maintain approved destination and approved integration-action lookups.

·        Alert on external communication and internal management access using the same risk object.

·        Do not globally suppress cloud-hosted destinations.

·        Validate at least 30 days of normal communication and integration activity.

·        Treat connections and API calls as suspicious activity, not proof of downstream compromise.

DRI Assessment

Strong for compromise involving outbound communication or trusted-integration misuse. Detection value decreases when attackers use approved destinations and expected actions.

DRI

9.2/10

TCR Assessment

The rule is operationally strong when management traffic, detonation traffic, integration identities, and destination baselines are consistently normalized.

Operational TCR

8.9/10

Full-Telemetry TCR

9.7/10

Limitations

·        Detonation traffic can resemble malicious appliance communication.

·        Shared NAT may complicate attribution.

·        Established integrations may be abused through expected protocols.

·        Connected systems may not retain the originating FortiSandbox identity.

·        PaaS network activity may not be fully visible.

·        Appliance-local compromise will not trigger this rule.

·        A connection or API action does not prove downstream compromise.

Detection Query Pattern

Use the following SPL after mapping local indexes, source types, and enrichment fields:

index=<network_index> sourcetype IN (

    <dns_sourcetype>,

    <firewall_sourcetype>,

    <proxy_sourcetype>,

    <ndr_sourcetype>,

    <network_flow_sourcetype>

  )

source_asset_role="FortiSandbox"

validated_sandbox_vm_detonation!="true"

approved_destination!="true"

(

  destination_first_seen="true"

  OR destination_rare_for_asset="true"

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

  OR destination_address_type="raw_ip"

  OR destination_hosting_type IN ("dynamic_dns","anonymizer","residential_proxy")

  OR destination_domain_age_days < <local_new_domain_threshold>

  OR approved_protocol!="true"

)

| eval appliance_id=coalesce(appliance_id, src, src_host, dvc)

| eval activity_type="network"

| fields time applianceid source_ip destination destination_role protocol activity_type

| append

    [

      search index=<connected_product_index>

          sourcetype IN (

            <fortigate_sourcetype>,

            <fortimanager_sourcetype>,

            <fortianalyzer_sourcetype>,

            <fortimail_sourcetype>,

            <fortiweb_sourcetype>,

            <siem_sourcetype>,

            <soar_sourcetype>,

            <endpoint_security_sourcetype>,

            <cloud_security_sourcetype>

          )

          source_identity_type IN (

            "fortisandbox_api",

            "fortisandbox_certificate",

            "fortisandbox_service_account"

          )

          (

            approved_integration_destination!="true"

            OR approved_integration_action!="true"

          )

      | eval appliance_id=coalesce(appliance_id, source_appliance_id, src)

      | eval destination=coalesce(destination_asset, dest)

      | eval protocol=coalesce(api_service, protocol)

      | eval activity_type="integration"

      | fields time applianceid source_ip destination destination_role protocol activity_type action

    ]

| bin _time span=15m

| stats count AS activity_count

        dc(activity_type) AS distinct_activity_types

        values(activity_type) AS activity_types

        values(action) AS actions

    BY time applianceid destination destination_role protocol

| where activity_count>=1

| eval risk_object=appliance_id, risk_object_type="system"

| eval risk_score=case(

    distinct_activity_types=2, 75,

    destination_role IN (

      "security_management",

      "identity_infrastructure",

      "cloud_management",

      "hypervisor"

    ), 65,

    true(), 50

  )

Elastic

Detection Viability Assessment

Elastic provides strong coverage when FortiSandbox events, interface traffic, DNS, network-flow data, and connected-product telemetry are indexed and normalized. EQL can correlate ordered activity across bounded periods, while ES|QL can categorize and aggregate control changes. Production deployment requires local data-stream, field, asset, identity, destination, and approved-activity mappings.

Rule

Suspicious FortiSandbox Request Followed by Appliance-State Change

Rule Format

Elastic EQL event-correlation rule using FortiSandbox interface and native-event telemetry.

Detection Purpose

Detect a suspicious request to a FortiSandbox interface followed by appliance activity consistent with unauthorized command execution or system-state modification.

Detection Logic

Identify command-like requests to validated FortiSandbox management, API, service, upload, reporting, analysis, or administrative interfaces.

Correlate the request with subsequent administrative, configuration, CLI, kernel, service, update, database, report, job, VM, logging, or outbound-network activity from the same FortiSandbox appliance within 10 minutes.

Increase confidence when the request was unauthenticated, originated from an unapproved source, or was followed by a high-impact appliance action.

Exclude approved vulnerability testing, vendor support, maintenance, upgrades, and documented administrative automation.

Required Telemetry

·        FortiSandbox native events indexed in Elastic.

·        Reverse-proxy, firewall, web-application firewall, VPN, or application-access logs.

·        Appliance identity, source IP, request path, decoded request parameters, authentication state, event category, action, status, and timestamp.

·        Approved testing, support, maintenance, automation, and action-enrichment fields.

·        Consistent appliance identifiers across data sources.

Engineering Implementation Instructions

·        Map FortiSandbox and interface events to Elastic Common Schema where practical.

·        Normalize appliance identity into observer.serial_number or another stable correlation field.

·        Decode request values before ingestion or store a decoded field.

·        Normalize FortiSandbox activity into event.category and event.action.

·        Enrich events with approved-testing and approved-action fields.

·        Use a 10-minute EQL sequence window.

·        Validate the sequence in hunt mode before enabling alerts.

·        Assign the FortiSandbox appliance as the primary alert entity.

·        Do not configure automated containment unless an approved response integration exists.

DRI Assessment

High detection value when request metadata and native FortiSandbox events are available. Reliability decreases when encrypted traffic hides request parameters or execution produces no recorded appliance change.

DRI

9.1/10

TCR Assessment

The rule is production viable after field normalization, asset mapping, and approved-activity enrichment.

Operational TCR

8.9/10

Full-Telemetry TCR

9.6/10

Limitations

·        Encrypted traffic may prevent request inspection.

·        FortiSandbox may not expose direct process or command-line telemetry.

·        Legitimate maintenance may produce similar events.

·        Proxy or NAT behavior may obscure the original request source.

·        Blind execution may produce no recorded state change.

·        The rule cannot prove the exact command executed.

Detection Query Pattern

Use the following EQL after mapping the placeholder fields and data streams:

sequence by observer.serial_number with maxspan=10m

  [any where

      event.dataset == "fortisandbox.interface"

      and destination.asset.type == "fortisandbox"

      and fortisandbox.approved_test_source == false

      and (

        url.query : (

          "*;*",

          "*&&*",

          "*||*",

          "*`*",

          "*$(*",

          "*${*",

          "*>*",

          "*<*",

          "*%3b*",

          "*%26%26*",

          "*%7c%7c*"

        )

        or url.query : (

          "*/bin/sh*",

          "*/bin/bash*",

          "*powershell*",

          "*python*",

          "*perl*",

          "*wget*",

          "*curl*"

        )

      )

  ]

  [any where

      event.dataset == "fortisandbox.events"

      and fortisandbox.approved_action == false

      and event.action : (

        "administrative-change",

        "configuration-change",

        "cli-activity",

        "kernel-activity",

        "service-change",

        "update-action",

        "database-change",

        "report-change",

        "job-anomaly",

        "vm-anomaly",

        "logging-change",

        "outbound-connection"

      )

  ]

Rule

FortiSandbox Analysis-Control, Identity, and Logging Manipulation

Rule Format

Elastic ES|QL detection rule using normalized FortiSandbox administrative and control-change events.

Detection Purpose

Detect unauthorized changes that may weaken FortiSandbox analysis, alter verdicts or reports, suppress evidence, establish access, or compromise trusted integrations.

Detection Logic

Identify successful changes involving administrators, PaaS IAM users, trusted hosts, certificates, API credentials, analysis profiles, VM settings, rescans, verdicts, quarantine actions, threat classifications, databases, reports, logging, forwarding, notifications, or integrations.

Increase confidence when the same identity changes multiple control areas within 30 minutes or performs multiple distinct high-impact actions.

Exclude approved maintenance, vendor support, content updates, profile tuning, database maintenance, report-retention activity, and incident-response actions.

Required Telemetry

·        FortiSandbox administrative, System, Job, VM, Threat, Database, Report, Notification, SNMP, logging, and configuration events.

·        FortiCloud IAM events for PaaS where applicable.

·        Appliance identity, user, source IP, interface, category, action, status, and timestamp.

·        Approved-change, maintenance, and support enrichment.

·        Baselines for administrative identities and expected control changes.

Engineering Implementation Instructions

·        Normalize relevant FortiSandbox events into a dedicated data stream.

·        Map each event into a consistent control area.

·        Normalize appliance and PaaS identity fields.

·        Limit production detection to successful or completed actions.

·        Enrich events with approved-change, maintenance, and support indicators.

·        Aggregate by appliance, identity, source, and 30-minute time bucket.

·        Alert when multiple control areas or distinct actions are observed.

·        Do not globally suppress privileged administrators.

·        Validate normal administrative workflows before production deployment.

DRI Assessment

Strong detection value for security-control changes represented in FortiSandbox telemetry. The rule is less effective when changes occur through unlogged operating-system access.

DRI

9.3/10

TCR Assessment

The rule is production viable when event categorization and approved-change enrichment are complete.

Operational TCR

9.0/10

Full-Telemetry TCR

9.7/10

Limitations

·        Some changes may appear only as generic system messages.

·        Legitimate administration can resemble malicious behavior.

·        Appliance and PaaS schemas may differ.

·        Attackers may use approved identities.

·        Restored settings may hide the compromised state.

·        The rule does not independently prove command injection.

Detection Query Pattern

Use the following ES|QL after mapping the local index and normalized fields:

FROM logs-fortisandbox-*

| WHERE event.outcome == "success"

    AND fortisandbox.approved_change == false

    AND fortisandbox.maintenance_window == false

    AND fortisandbox.support_activity == false

    AND event.action IN (

      "administrator-create",

      "privilege-change",

      "trusted-host-change",

      "certificate-change",

      "token-change",

      "api-change",

      "integration-change",

      "analysis-profile-change",

      "vm-change",

      "rescan-change",

      "verdict-change",

      "quarantine-change",

      "threat-reclassification",

      "database-change",

      "report-delete",

      "logging-change",

      "forwarding-change",

      "notification-change"

    )

| EVAL control_area = CASE(

    event.action IN (

      "administrator-create",

      "privilege-change",

      "trusted-host-change"

    ), "identity",

    event.action IN (

      "analysis-profile-change",

      "rescan-change",

      "verdict-change",

      "quarantine-change"

    ), "analysis",

    event.action == "vm-change", "vm",

    event.action == "threat-reclassification", "threat",

    event.action == "database-change", "database",

    event.action == "report-delete", "report",

    event.action IN (

      "logging-change",

      "forwarding-change"

    ), "logging",

    event.action == "notification-change", "notification",

    "integration"

  )

| STATS

    event_count = COUNT(*),

    distinct_control_areas = COUNT_DISTINCT(control_area),

    distinct_actions = COUNT_DISTINCT(event.action)

  BY BUCKET(@timestamp, 30 minutes),

     observer.serial_number,

user.name,

     source.ip

| WHERE distinct_control_areas >= 2

    OR distinct_actions >= 2

    OR event_count >= local_single_area_change_threshold

| SORT distinct_control_areas DESC, distinct_actions DESC, event_count DESC

Rule

FortiSandbox Outbound Communication or Downstream Integration Abuse

Rule Format

Elastic EQL event-correlation rule using FortiSandbox, network, DNS, and connected-product telemetry.

Detection Purpose

Detect suspicious FortiSandbox-originated communication or trusted-integration activity following behavior that may indicate appliance compromise.

Detection Logic

Identify suspicious FortiSandbox administrative, identity, logging, analysis, service, configuration, or credential-access activity.

Correlate that activity within 60 minutes with either:

·        FortiSandbox-originated network communication to an unapproved, first-seen, rare, threat-associated, raw-IP, anonymized, or unusual internal management destination.

·        FortiSandbox API, certificate, token, or service-account activity against a connected system when the destination or action is outside the approved integration pattern.

Exclude validated sandbox-VM detonation traffic and approved Fortinet, update, licensing, reputation, DNS, NTP, mail, storage, logging, management, and integration activity.

Required Telemetry

·        FortiSandbox administrative and native events.

·        DNS, firewall, proxy, NDR, network-flow, VPN, and TLS data.

·        Connected-product administrative and API events.

·        FortiSandbox asset and integration-identity inventory.

·        Approved destination, protocol, integration, and action enrichment.

·        Destination novelty, reputation, hosting type, confidence score, and internal asset-role fields.

·        Consistent appliance identifiers across FortiSandbox, network, and connected-product telemetry.

Engineering Implementation Instructions

·        Normalize FortiSandbox and connected-product telemetry to ECS-compatible fields where practical.

·        Distinguish appliance-management traffic from sandbox-VM detonation traffic.

·        Normalize appliance identity across FortiSandbox, network, and connected-product events.

·        Enrich network events with destination approval, novelty, reputation, hosting, and confidence context.

·        Enrich integration events with FortiSandbox source-identity type, approved destination, and approved action fields.

·        Use a 60-minute EQL sequence window.

·        Map numeric threat-confidence thresholds to the organization’s enrichment source.

·        Do not globally suppress cloud-hosted destinations.

·        Treat connections and API actions as suspicious activity, not proof of downstream compromise.

·        Validate at least 30 days of normal activity before production deployment.

DRI Assessment

Strong for compromise involving outbound communication or trusted-integration misuse. Detection value decreases when attackers use approved destinations and expected integration actions.

DRI

9.2/10

TCR Assessment

The rule is operationally strong when management traffic, detonation traffic, integration identities, and destination baselines are consistently normalized.

Operational TCR

8.9/10

Full-Telemetry TCR

9.7/10

Limitations

·        Detonation traffic can resemble malicious appliance communication.

·        Shared NAT may complicate attribution.

·        Established integrations may be abused through expected protocols.

·        Connected systems may not retain the originating FortiSandbox identity.

·        PaaS network paths may not be fully visible.

·        Appliance-local compromise will not trigger the rule.

·        A connection or API action does not prove downstream compromise.

Detection Query Pattern

Use the following EQL after mapping local data streams and enrichment fields:

sequence by observer.serial_number with maxspan=60m

  [any where

      event.dataset == "fortisandbox.events"

      and event.action : (

        "administrator-change",

        "identity-change",

        "logging-change",

        "configuration-change",

        "analysis-control-change",

        "service-anomaly",

        "credential-access"

      )

      and fortisandbox.approved_change == false

  ]

  [any where

      (

        event.category == "network"

        and source.asset.type == "fortisandbox"

        and fortisandbox.validated_detonation_traffic == false

        and fortisandbox.approved_destination == false

        and (

          destination.first_seen == true

          or destination.rare_for_asset == true

          or threat.indicator.confidence >= 75

          or destination.address_type == "raw_ip"

          or destination.hosting_type : (

            "dynamic_dns",

            "anonymizer",

            "residential_proxy"

          )

          or network.approved_protocol == false

          or destination.asset.type : (

            "security_management",

            "identity_infrastructure",

            "cloud_management",

            "hypervisor"

          )

        )

      )

      or

      (

        event.dataset : (

          "fortigate.events",

          "fortimanager.events",

          "fortianalyzer.events",

          "fortimail.events",

          "fortiweb.events",

          "siem.events",

          "soar.events",

          "endpoint_security.events",

          "cloud_security.events"

        )

        and fortisandbox.source_identity_type : (

          "fortisandbox_api",

          "fortisandbox_certificate",

          "fortisandbox_token",

          "fortisandbox_service_account"

        )

        and (

          fortisandbox.approved_integration_destination == false

          or fortisandbox.approved_integration_action == false

        )

      )

  ]

QRadar

Detection Viability Assessment

QRadar provides strong correlated coverage when FortiSandbox events, management-interface traffic, DNS, network flows, and connected-product telemetry are normalized into usable event properties. The Custom Rules Engine can detect suspicious requests, bounded event sequences, security-control changes, outbound communication, and downstream integration abuse. Production deployment requires FortiSandbox log-source identification, custom-property extraction, asset classification, building blocks, reference data, and locally validated thresholds.

Rule

Suspicious FortiSandbox Request Followed by Appliance-State Change

Rule Format

QRadar CRE event rule using custom properties, FortiSandbox host-definition building blocks, reference sets, and a bounded event sequence.

Detection Purpose

Detect a suspicious request to a FortiSandbox interface followed by appliance activity consistent with unauthorized command execution or system-state modification.

Detection Logic

Identify command-like requests to validated FortiSandbox management, API, service, upload, reporting, analysis, or administrative interfaces.

Correlate the request with subsequent administrative, configuration, CLI, kernel, service, update, database, report, job, VM, logging, or outbound-network activity from the same FortiSandbox appliance within 10 minutes.

Increase confidence when the request originates from an unapproved source, is unauthenticated, or is followed by multiple appliance-change categories.

Exclude approved vulnerability testing, vendor support, maintenance, upgrades, and documented automation.

Required Telemetry

·        FortiSandbox System, Job, VM, Database, Report, Performance, Resource, HA, Notification, Input, and Threat Events where relevant.

·        Reverse-proxy, firewall, web-application firewall, VPN, or application-access events.

·        Appliance identity, source IP, HTTP method, request path, decoded request value, authentication state, event category, action, status, and timestamp.

·        FortiSandbox asset and cluster-node inventory.

·        Approved scanner, testing, support, maintenance, automation, and action reference data.

·        Custom properties that consistently identify the FortiSandbox appliance across log sources.

Engineering Implementation Instructions

·        Create a BB:HostDefinition: FortiSandbox Systems building block containing validated appliance, virtual appliance, cluster-node, and visible PaaS addresses.

·        Create custom properties for FortiSandbox Appliance ID, Request Value, Request Path, Authentication State, Event Category, Event Action, User Interface, Job ID, and VM ID where present.

·        Decode or normalize request values before evaluating command-control characters.

·        Create a BB:BehaviorDefinition: Suspicious FortiSandbox Request building block.

·        Create a BB:BehaviorDefinition: FortiSandbox Appliance-State Change building block.

·        Maintain approved testing sources and approved appliance actions in reference sets.

·        Correlate events by FortiSandbox Appliance ID or validated destination and source identity.

·        Use a maximum 10-minute sequence window.

·        Configure the rule response to create an offense indexed by FortiSandbox Appliance ID.

·        Include source IP, request path, event category, action, user, and message in the offense evidence.

·        Validate in a non-response or low-severity state before production enablement.

DRI Assessment

High detection value when interface telemetry and native FortiSandbox events are available. Reliability decreases when encrypted traffic hides request content or execution produces no recorded appliance event.

DRI

9.0/10

TCR Assessment

The rule is production viable after custom-property extraction, appliance mapping, and approved-activity reference data are complete.

Operational TCR

8.8/10

Full-Telemetry TCR

9.6/10

Limitations

·        Encrypted traffic may prevent inspection of request parameters.

·        FortiSandbox may not expose direct process or command-line telemetry.

·        Legitimate maintenance may produce similar events.

·        Proxy or NAT behavior may obscure the original source.

·        Inconsistent custom-property extraction can break correlation.

·        Blind execution may produce no appliance-state event.

·        The rule cannot prove the exact command executed.

Detection Query Pattern

Implement the following CRE rule stack:

Rule Type:

Event Rule

Apply:

Suspicious FortiSandbox Request Followed by Appliance-State Change

When:

- The destination matches BB:HostDefinition: FortiSandbox Systems

- The event matches BB:BehaviorDefinition: Suspicious FortiSandbox Request

- The source IP is not contained in REF: Approved FortiSandbox Testing Sources

Followed within 10 minutes by:

- An event from the same FortiSandbox Appliance ID

- The event matches BB:BehaviorDefinition: FortiSandbox Appliance-State Change

- The Event Action is not contained in REF: Approved FortiSandbox Actions

Suspicious FortiSandbox Request building block:

- Log source is an approved FortiSandbox-facing proxy, firewall, WAF, VPN, or application source

- Request Value contains one or more normalized command-control features:

  - command separator

  - logical command operator

  - command substitution

  - redirection operator

  - interpreter reference

  - download utility

  - encoded command-control character

- Destination matches BB:HostDefinition: FortiSandbox Systems

FortiSandbox Appliance-State Change building block:

- Log source is FortiSandbox

- Event Category or Event Action indicates:

  - administrative change

  - configuration change

  - CLI activity

  - kernel activity

  - service change

  - update action

  - database change

  - report change

  - job anomaly

  - VM anomaly

  - logging change

  - outbound connection

Rule Response:

- Create an offense

- Index offense by FortiSandbox Appliance ID

- Set severity according to the number and impact of subsequent event categories

- Add request and subsequent event properties to offense evidence

Rule

FortiSandbox Analysis-Control, Identity, and Logging Manipulation

Rule Format

QRadar CRE event rule using FortiSandbox control-change building blocks, custom properties, reference data, and threshold tests.

Detection Purpose

Detect unauthorized changes that may weaken FortiSandbox analysis, alter verdicts or reports, suppress evidence, establish access, or compromise trusted integrations.

Detection Logic

Identify successful changes involving administrators, remote users, PaaS IAM users, trusted hosts, certificates, API credentials, analysis profiles, VM settings, rescans, verdicts, quarantine actions, threat classifications, databases, reports, logging, forwarding, notifications, or integrations.

Increase confidence when the same identity modifies multiple control areas within 30 minutes or performs multiple distinct high-impact actions.

Exclude approved maintenance, vendor support, content updates, profile tuning, database maintenance, report-retention activity, and incident-response actions.

Required Telemetry

·        FortiSandbox administrative, System, Job, VM, Threat, Database, Report, Notification, SNMP, logging, and configuration events.

·        FortiCloud IAM events for PaaS deployments where available.

·        Appliance identity, username, source IP, interface, control area, action, status, message, and timestamp.

·        Approved change, maintenance, support, and service-identity reference data.

·        Custom properties for control area and normalized action.

Engineering Implementation Instructions

·        Create a BB:BehaviorDefinition: FortiSandbox High-Impact Control Change building block.

·        Create custom properties for FortiSandbox Appliance ID, Control Area, Normalized Action, Change ID, User Interface, and Action Status.

·        Map control areas to identity, analysis, VM, threat, database, report, logging, notification, and integration.

·        Require successful or completed actions for the production rule.

·        Maintain approved change records, maintenance windows, and support sources in reference data.

·        Do not globally suppress privileged administrators.

·        Use threshold tests to detect multiple control areas or distinct high-impact actions by the same appliance and username within 30 minutes.

·        Create offenses indexed by FortiSandbox Appliance ID and username.

·        Preserve all contributing events in the offense.

DRI Assessment

Strong detection value for security-control changes represented in FortiSandbox telemetry. The rule is less effective when changes occur through unlogged operating-system access.

DRI

9.2/10

TCR Assessment

The rule is production viable when control-area categorization, custom-property extraction, and approved-change enrichment are complete.

Operational TCR

8.9/10

Full-Telemetry TCR

9.7/10

Limitations

·        Some changes may appear only as generic system messages.

·        Legitimate administration can resemble malicious behavior.

·        Appliance and PaaS event formats may differ.

·        Attackers may use approved identities.

·        Restored settings may hide the compromised state.

·        Missing change identifiers can reduce exclusion accuracy.

·        The rule does not independently prove command injection.

Detection Query Pattern

Implement the following CRE rule stack:

Rule Type:

Event Rule

Apply:

FortiSandbox Analysis-Control, Identity, and Logging Manipulation

When:

- The event is detected by one or more FortiSandbox log sources

- The event matches BB:BehaviorDefinition: FortiSandbox High-Impact Control Change

- Action Status indicates success or completion

- Change ID is not contained in REF: Approved FortiSandbox Changes

- Source IP is not contained in REF: Approved FortiSandbox Support Sources

- The event does not occur during an approved maintenance condition

And when either:

- At least 2 distinct Control Area values are observed for the same FortiSandbox Appliance ID and Username within 30 minutes

- At least 2 distinct Normalized Action values are observed for the same FortiSandbox Appliance ID and Username within 30 minutes

- A locally defined number of high-impact changes occur within 30 minutes

FortiSandbox High-Impact Control Change building block:

- Control Area is one of:

  - identity

  - analysis

  - VM

  - threat

  - database

  - report

  - logging

  - notification

  - integration

- Normalized Action indicates:

  - create

  - delete

  - disable

  - enable

  - grant

  - modify

  - replace

  - suppress

  - clear

  - reclassify

  - change

Rule Response:

- Create an offense

- Index offense by FortiSandbox Appliance ID and Username

- Increase severity when identity or analysis changes occur with logging, report, forwarding, or notification changes

- Include Control Area, Normalized Action, source IP, interface, and message in offense evidence

Rule

FortiSandbox Outbound Communication or Downstream Integration Abuse

Rule Format

QRadar CRE event-and-flow rule using network building blocks, connected-product events, custom properties, reference data, and bounded correlation.

Detection Purpose

Detect suspicious FortiSandbox-originated communication or trusted-integration activity that may indicate command execution, credential misuse, lateral movement, or downstream security-control compromise.

Detection Logic

Identify FortiSandbox communication to an unapproved, first-seen, rare, threat-associated, raw-IP, anonymized, tunneling, or unusual internal management destination.

Also identify FortiSandbox API, certificate, token, or service-account activity against connected systems when the destination or action is outside the approved integration pattern.

Increase confidence when the activity follows suspicious FortiSandbox administrative, identity, logging, configuration, analysis, service, or credential-access activity within 60 minutes.

Exclude validated sandbox-VM detonation traffic and approved Fortinet, update, licensing, reputation, DNS, NTP, mail, storage, logging, management, and integration activity.

Required Telemetry

·        FortiSandbox administrative and native events.

·        QRadar Network Insights, QFlow, firewall, proxy, DNS, NDR, VPN, or comparable flow and event telemetry.

·        Connected-product administrative and API events.

·        FortiSandbox asset and integration-identity inventory.

·        Approved destination, protocol, integration, and action reference data.

·        Destination reputation, novelty, hosting type, internal role, and threat context.

·        Custom properties identifying appliance-management traffic and sandbox-VM detonation traffic.

Engineering Implementation Instructions

·        Create a BB:BehaviorDefinition: Suspicious FortiSandbox Precursor Activity building block.

·        Create a BB:BehaviorDefinition: Suspicious FortiSandbox Outbound Communication building block.

·        Create a BB:BehaviorDefinition: FortiSandbox Integration Abuse building block.

·        Maintain approved FortiSandbox destinations and protocols in reference data.

·        Use reference maps when approval depends on an appliance-to-destination or identity-to-action combination.

·        Distinguish appliance-management traffic from sandbox-VM detonation traffic.

·        Normalize FortiSandbox API, certificate, token, and service-account identities across connected-product events.

·        Correlate precursor activity with either suspicious network activity or integration abuse within 60 minutes.

·        Create offenses indexed by FortiSandbox Appliance ID.

·        Increase severity for internal security, identity, hypervisor, cloud-management, SIEM, SOAR, endpoint-management, or administrative destinations.

DRI Assessment

Strong for compromise involving outbound communication or trusted-integration misuse. Detection value decreases when attackers use approved destinations and expected integration actions.

DRI

9.1/10

TCR Assessment

The rule is operationally strong when appliance traffic, detonation traffic, integration identities, and destination baselines are consistently classified.

Operational TCR

8.8/10

Full-Telemetry TCR

9.6/10

Limitations

·        Detonation traffic can resemble malicious appliance communication.

·        Shared NAT may complicate attribution.

·        Established integrations may be abused through expected protocols.

·        Connected systems may not retain the originating FortiSandbox identity.

·        PaaS network paths may not be fully visible.

·        Destination novelty may require external enrichment.

·        Appliance-local compromise will not trigger the rule.

·        A connection or API action does not prove downstream compromise.

Detection Query Pattern

Implement the following CRE rule stack:

Rule Type:

Event and Flow Rule

Apply:

FortiSandbox Outbound Communication or Downstream Integration Abuse

When:

- An event matches BB:BehaviorDefinition: Suspicious FortiSandbox Precursor Activity

Followed within 60 minutes by either:

- A flow or network event that matches BB:BehaviorDefinition: Suspicious FortiSandbox Outbound Communication

- An event that matches BB:BehaviorDefinition: FortiSandbox Integration Abuse

Suspicious FortiSandbox Precursor Activity building block:

- Log source is FortiSandbox

- Event Action indicates:

  - administrator change

  - identity change

  - logging change

  - configuration change

  - analysis-control change

  - service anomaly

  - credential access

- Change ID is not contained in REF: Approved FortiSandbox Changes

Suspicious FortiSandbox Outbound Communication building block:

- Source matches BB:HostDefinition: FortiSandbox Systems

- Traffic is not identified as validated sandbox-VM detonation traffic

- Destination is not contained in REF: Approved FortiSandbox Destinations

- At least one condition is true:

  - destination is first-seen for the appliance

  - destination is rare for the FortiSandbox asset group

  - destination is threat-associated

  - destination is addressed directly by IP

  - destination uses dynamic DNS or anonymization infrastructure

  - protocol is not contained in REF: Approved FortiSandbox Protocols

  - destination matches a privileged internal asset building block

  - the appliance contacts multiple new internal destinations

FortiSandbox Integration Abuse building block:

- Log source is a connected security, management, cloud, email, storage, SIEM, SOAR, endpoint, or network platform

- Source Identity Type indicates:

  - FortiSandbox API identity

  - FortiSandbox certificate

  - FortiSandbox token

  - FortiSandbox service account

- Appliance-to-destination mapping is not contained in REF MAP: Approved FortiSandbox Integrations

- Or identity-to-action mapping is not contained in REF MAP: Approved FortiSandbox Integration Actions

Rule Response:

- Create an offense

- Index offense by FortiSandbox Appliance ID

- Increase severity for privileged internal destinations or combined network and integration activity

- Add the source identity, destination, protocol, action, reputation, and precursor event to offense evidence

SIGMA

Detection Viability Assessment

SIGMA provides portable detection logic when FortiSandbox, interface, network, and connected-product events are normalized into consistent fields before conversion to the target SIEM. Two standalone YAML rules detect suspicious control changes and analysis-pipeline disruption. One formal ordered temporal correlation detects a suspicious FortiSandbox request followed by appliance-state change or outbound communication. Backend conversion and local field mapping remain required.

Rule

FortiSandbox Identity, Administrative, Logging, or Configuration Modification

Rule Format

SIGMA YAML detection rule for normalized FortiSandbox administrative and control-change events.

Detection Purpose

Detect suspicious changes to FortiSandbox identity, administrative access, logging, configuration, certificates, API credentials, notifications, or trusted integrations.

Detection Logic

Identify successful creation, deletion, disabling, replacement, privilege modification, trusted-host modification, certificate change, token change, API change, logging change, forwarding change, or integration change.

Exclude events associated with approved changes, maintenance, vendor support, or validated automation.

Required Telemetry

·        FortiSandbox System, administrative, logging, configuration, Notification, SNMP, and API events.

·        FortiCloud IAM events for PaaS deployments where available.

·        Appliance identity, user, source IP, action, status, interface, and timestamp.

·        Approved-change, maintenance, support, and automation enrichment.

Engineering Implementation Instructions

·        Normalize FortiSandbox actions into the fields used by the rule.

·        Map successful actions to EventOutcome: success.

·        Populate approval fields during ingestion or through the target SIEM.

·        Convert the rule with the appropriate Sigma backend and processing pipeline.

·        Do not globally suppress privileged administrators.

·        Validate expected administrative activity before production enablement.

DRI Assessment

Strong for control changes represented in FortiSandbox telemetry. Detection reliability decreases when attackers use unlogged operating-system access.

DRI

8.9/10

TCR Assessment

The rule is portable and operationally viable after local field mapping and approved-change enrichment.

Operational TCR

8.7/10

Full-Telemetry TCR

9.4/10

Limitations

·        FortiSandbox event schemas may vary by deployment and version.

·        Legitimate administration can resemble malicious activity.

·        Attackers may use approved identities.

·        Some changes may appear only as generic system events.

·        The rule does not prove that command injection occurred.

Detection Query Pattern

title: FortiSandbox Identity Administrative Logging or Configuration Modification

id: 29fb6421-9652-49df-a996-42dc8dd40446

name: fortisandbox_control_modification

status: experimental

description: Detects suspicious successful changes to FortiSandbox identity, administrative, logging, configuration, certificate, API, notification, or integration controls.

logsource:

  product: fortinet

  service: fortisandbox

detection:

  selection_action:

    EventAction:

      - administrator_create

      - administrator_delete

      - privilege_change

      - trusted_host_change

      - certificate_change

      - token_change

      - api_change

      - configuration_change

      - logging_disable

      - logging_change

      - forwarding_change

      - notification_disable

      - integration_change

  selection_success:

    EventOutcome: success

  filter_approved:

    ApprovedChange: true

  filter_maintenance:

    MaintenanceWindow: true

  filter_support:

    VendorSupportActivity: true

  condition: selection_action and selection_success and not 1 of filter_*

falsepositives:

  - Approved FortiSandbox administration

  - Scheduled maintenance

  - Vendor-supported troubleshooting

  - Validated configuration automation

level: high

Rule

FortiSandbox Analysis Pipeline or Operational Control Disruption

Rule Format

SIGMA YAML detection rule for normalized FortiSandbox Job, VM, Threat, Database, Report, Performance, Resource, and Notification events.

Detection Purpose

Detect suspicious activity that may disrupt FortiSandbox analysis, alter results, suppress reporting, manipulate verdicts, or degrade operational controls.

Detection Logic

Identify successful or completed actions involving analysis-profile changes, VM changes, job cancellation, rescan modification, verdict modification, threat reclassification, quarantine modification, database modification, report deletion, resource-control change, performance-control change, or notification suppression.

Exclude approved tuning, maintenance, retention activity, and incident-response actions.

Required Telemetry

·        FortiSandbox Job, VM, Threat, Database, Report, Performance, Resource, Notification, and System Events.

·        Appliance identity, user, source IP, action, status, job, VM, sample, and timestamp.

·        Approved-change, maintenance, retention, and response enrichment.

Engineering Implementation Instructions

·        Normalize operational actions into EventAction.

·        Normalize successful or completed results into EventOutcome.

·        Populate approval and maintenance fields before backend conversion.

·        Preserve job, VM, sample, and report identifiers for investigation.

·        Validate expected analysis administration and retention workflows.

DRI Assessment

Strong for analysis-control manipulation and operational disruption represented in native events.

DRI

9.0/10

TCR Assessment

The rule is production viable after event-action normalization and operational exclusions are mapped.

Operational TCR

8.8/10

Full-Telemetry TCR

9.5/10

Limitations

·        Some operational events may be informational rather than malicious.

·        Scheduled retention or database maintenance may resemble destructive activity.

·        PaaS deployments may expose fewer fields.

·        The rule cannot detect unlogged appliance-local manipulation.

·        A matched action does not independently prove compromise.

Detection Query Pattern

title: FortiSandbox Analysis Pipeline or Operational Control Disruption

id: a30dd5ce-9ab8-4db4-a3fb-05d021866395

name: fortisandbox_analysis_disruption

status: experimental

description: Detects suspicious successful changes affecting FortiSandbox analysis, jobs, virtual machines, verdicts, reports, databases, resources, performance, or notifications.

logsource:

  product: fortinet

  service: fortisandbox

detection:

  selection_action:

    EventAction:

      - analysis_profile_change

      - vm_change

      - vm_disable

      - job_cancel

      - job_delete

      - rescan_change

      - verdict_change

      - threat_reclassification

      - quarantine_change

      - database_change

      - report_delete

      - report_suppress

      - performance_control_change

      - resource_control_change

      - notification_disable

  selection_outcome:

    EventOutcome:

      - success

      - completed

  filter_approved:

    ApprovedChange: true

  filter_maintenance:

    MaintenanceWindow: true

  filter_retention:

    ApprovedRetentionActivity: true

  filter_response:

    ApprovedIncidentResponse: true

  condition: selection_action and selection_outcome and not 1 of filter_*

falsepositives:

  - Approved analysis-profile tuning

  - Scheduled virtual-machine administration

  - Database maintenance

  - Report-retention activity

  - Validated incident-response actions

level: high

Rule

Suspicious FortiSandbox Request Followed by Appliance Change or Outbound Communication

Rule Format

Formal SIGMA ordered temporal-correlation rule using two supporting SIGMA YAML event detections.

Detection Purpose

Detect a suspicious request to a FortiSandbox interface followed by appliance-state change or unusual outbound communication from the same system within 10 minutes.

Detection Logic

Identify a request containing command-control syntax, encoded metacharacters, interpreter references, or download utilities.

Correlate that request with a subsequent FortiSandbox administrative, configuration, service, logging, job, VM, database, report, or outbound-network event from the same appliance.

Exclude approved testing sources and approved appliance actions.

Required Telemetry

·        Reverse-proxy, firewall, web-application firewall, VPN, or application-access events.

·        FortiSandbox native and outbound-network events.

·        Stable FortiSandbox appliance identity across both event sources.

·        Decoded request values and approved-testing enrichment.

·        Approved-action enrichment.

Engineering Implementation Instructions

·        Deploy both supporting rules with the correlation rule.

·        Normalize the appliance identifier into FortiSandboxApplianceId.

·        Decode request values before matching.

·        Preserve event timestamps with sufficient precision for ordered correlation.

·        Use a backend that supports Sigma ordered temporal correlation.

·        Where native correlation conversion is unavailable, implement the same ordered two-rule sequence directly in the destination SIEM.

·        Validate the correlation in hunt mode before production alerting.

DRI Assessment

High detection value when interface and appliance telemetry are both available.

DRI

9.1/10

TCR Assessment

The correlation is operationally strong when the target backend supports Sigma ordered temporal correlation and appliance identity is consistent.

Operational TCR

8.7/10

Full-Telemetry TCR

9.6/10

Limitations

·        Backend support for Sigma correlations varies.

·        Clock skew can affect temporal matching.

·        Encrypted traffic may hide request values.

·        Blind execution may produce no subsequent observable event.

·        The correlation cannot prove the exact command executed.

·        Local field and pipeline mapping remain required.

Detection Query Pattern

title: Suspicious Request to FortiSandbox Interface

id: b7d90e42-c3de-4a76-8088-5bf6418a47fd

name: fortisandbox_suspicious_request

status: experimental

logsource:

  category: webserver

detection:

  selection_target:

    DestinationAssetType: fortisandbox

  selection_request:

    RequestValue|contains:

      - ';'

      - '&&'

      - '||'

      - '`'

      - '$('

      - '${'

      - '/bin/sh'

      - '/bin/bash'

      - 'wget'

      - 'curl'

  selection_encoded:

    RequestValue|contains:

      - '%3b'

      - '%26%26'

      - '%7c%7c'

  filter_testing:

    ApprovedTestSource: true

  condition: selection_target and (selection_request or selection_encoded) and not filter_testing

level: medium

---

title: FortiSandbox Appliance Change or Outbound Communication

id: 6f601d0a-cc82-4d16-b376-16264ca6d32e

name: fortisandbox_change_or_outbound

status: experimental

logsource:

  product: fortinet

  service: fortisandbox

detection:

  selection:

    EventAction:

      - administrative_change

      - configuration_change

      - cli_activity

      - kernel_activity

      - service_change

      - logging_change

      - database_change

      - report_change

      - job_anomaly

      - vm_anomaly

      - outbound_connection

  filter_approved:

    ApprovedAction: true

  condition: selection and not filter_approved

level: medium

---

title: Suspicious FortiSandbox Request Followed by Appliance Change or Outbound Communication

id: af86c151-8067-49e7-9a10-e710ea3316e7

status: experimental

correlation:

  type: temporal_ordered

  rules:

    - fortisandbox_suspicious_request

    - fortisandbox_change_or_outbound

  group-by:

    - FortiSandboxApplianceId

  timespan: 10m

condition:

  gte: 2

falsepositives:

  - Authorized vulnerability testing

  - Vendor-supported troubleshooting

  - Approved maintenance or administrative automation

level: high

YARA

YARA Coverage Disposition

YARA has zero deployable rules for this EXP report.

YARA is not viable as a primary S25 detection system because the report’s detection model is behavioral, sequence-based, appliance-event driven, identity-context based, administrative-control based, network-correlation based, SIEM-correlation based, and downstream integration-correlation based rather than static-file or malware-signature based.

YARA may provide limited supporting value only if a confirmed malicious binary, script, exploit artifact, encoded payload, archive, memory artifact, command-execution utility, persistence mechanism, or reusable malware family is recovered and independently validated.

Final YARA Outcome

No YARA rules survive.

AWS

Detection Viability Assessment

AWS provides supporting cloud-control coverage when FortiSandbox is deployed in AWS or depends on AWS-hosted networking, identity, storage, logging, or management components. AWS telemetry does not directly prove command injection inside the FortiSandbox guest operating system. CloudTrail and EventBridge can detect unauthorized changes to the surrounding deployment that may weaken isolation, alter instance identity, disrupt logging, modify storage controls, or destroy supporting resources.

Rule

FortiSandbox AWS Deployment Security-Control Modification

Rule Format

AWS EventBridge rule using CloudTrail management events for identified FortiSandbox AWS resources.

Detection Purpose

Detect unauthorized AWS control-plane changes affecting a FortiSandbox deployment, including security-group exposure, network-interface modification, instance-profile changes, instance metadata changes, IAM modification, logging disruption, S3 bucket-control changes, and destructive resource actions.

Detection Logic

Identify successful CloudTrail management events involving AWS resources that support a validated FortiSandbox deployment.

Detect changes involving:

·        Security-group ingress or egress rules.

·        EC2 network-interface attributes.

·        EC2 instance state, instance attributes, metadata options, or attached IAM instance profiles.

·        IAM roles, inline policies, managed-policy attachments, trust relationships, or access keys used by FortiSandbox.

·        CloudTrail trails, EventBridge rules, or CloudWatch log groups supporting monitoring and detection.

·        S3 bucket policies, encryption, lifecycle configuration, or bucket deletion affecting FortiSandbox logs, reports, or artifacts.

·        EC2 instance termination, volume detachment or deletion, and snapshot deletion affecting the deployment.

Exclude validated infrastructure-as-code deployments, approved maintenance, authorized incident-response actions, and documented administrative changes.

Required Telemetry

·        AWS CloudTrail management events from all accounts and Regions hosting FortiSandbox resources.

·        AWS resource tags, ARNs, account IDs, Regions, instance IDs, network-interface IDs, security-group IDs, role ARNs, volume IDs, snapshot IDs, bucket names, trail names, EventBridge rule names, and log-group names associated with FortiSandbox.

·        CloudTrail eventSource, eventName, userIdentity, sourceIPAddress, userAgent, requestParameters, resources, errorCode, and event time.

·        Approved administrator, automation role, infrastructure-as-code role, maintenance, support, and change-management context.

·        EventBridge delivery to an approved Lambda function, enrichment workflow, SIEM, or alerting destination.

Engineering Implementation Instructions

·        Tag and inventory all AWS resources supporting FortiSandbox.

·        Enable CloudTrail management-event coverage across all relevant accounts and Regions.

·        Preserve calling identity, assumed-role session, source identity, source IP, user agent, event name, affected resources, and request parameters.

·        Route EventBridge matches to an enrichment step that verifies the affected resource belongs to the FortiSandbox deployment.

·        Maintain approved-principal and approved-change context in the enrichment or downstream SIEM workflow.

·        Do not globally suppress infrastructure-as-code or automation roles.

·        Increase severity for logging, IAM, security-group, metadata-option, and instance-profile changes.

·        Increase severity when the same principal modifies multiple FortiSandbox resources within 30 minutes.

·        Treat this rule as supporting cloud-control detection, not direct proof of FortiSandbox command execution.

·        Monitor S3 object-level activity separately only when CloudTrail data events are explicitly enabled.

DRI Assessment

Strong for unauthorized AWS control-plane modification affecting a FortiSandbox deployment. It does not detect appliance-local execution when the attacker makes no AWS API calls.

DRI

8.6/10

TCR Assessment

The rule is operationally viable when FortiSandbox resources are completely inventoried and CloudTrail is enabled across all relevant accounts and Regions.

Operational TCR

8.5/10

Full-Telemetry TCR

9.3/10

Limitations

·        The rule cannot directly detect command injection inside the FortiSandbox guest.

·        Resource attribution may fail when tags and inventories are incomplete.

·        Approved automation may generate similar changes.

·        CloudTrail request data may be omitted or truncated.

·        Guest-operating-system changes are outside AWS control-plane visibility.

·        S3 object creation, access, and deletion are not covered by this management-event rule.

·        A matched AWS change does not prove that FortiSandbox was compromised.

Detection Query Pattern

Deploy the following EventBridge pattern and validate FortiSandbox resource ownership through the downstream enrichment workflow:

{

  "source": [

    "aws.ec2",

    "aws.iam",

    "aws.cloudtrail",

    "aws.events",

    "aws.logs",

    "aws.s3"

  ],

  "detail-type": [

    "AWS API Call via CloudTrail"

  ],

  "detail": {

    "eventName": [

      "AuthorizeSecurityGroupIngress",

      "AuthorizeSecurityGroupEgress",

      "RevokeSecurityGroupIngress",

      "RevokeSecurityGroupEgress",

      "ModifyNetworkInterfaceAttribute",

      "AssociateIamInstanceProfile",

      "ReplaceIamInstanceProfileAssociation",

      "DisassociateIamInstanceProfile",

      "ModifyInstanceAttribute",

      "ModifyInstanceMetadataOptions",

      "StopInstances",

      "TerminateInstances",

      "DetachVolume",

      "DeleteVolume",

      "DeleteSnapshot",

      "PutRolePolicy",

      "DeleteRolePolicy",

      "AttachRolePolicy",

      "DetachRolePolicy",

      "UpdateAssumeRolePolicy",

      "CreateAccessKey",

      "DeleteAccessKey",

      "StopLogging",

      "DeleteTrail",

      "UpdateTrail",

      "DisableRule",

      "DeleteRule",

      "DeleteLogGroup",

      "PutBucketPolicy",

      "DeleteBucketPolicy",

      "PutBucketEncryption",

      "DeleteBucketEncryption",

      "PutBucketLifecycle",

      "DeleteBucketLifecycle",

      "DeleteBucket"

    ],

    "errorCode": [

      {

        "exists": false

      }

    ]

  }

}

Route matched events to a Lambda function, EventBridge enrichment workflow, or SIEM pipeline that confirms at least one affected resource belongs to the FortiSandbox deployment before generating the final alert.

Azure

Detection Viability Assessment

Azure provides supporting cloud-control coverage when FortiSandbox is deployed in Azure or relies on Azure-hosted networking, identity, storage, logging, or management resources. Azure telemetry does not directly prove command injection inside the FortiSandbox guest operating system. Azure Activity Log and Azure Monitor can detect unauthorized control-plane changes that expose management access, alter virtual-machine identity, weaken network controls, disrupt monitoring, modify storage protections, or destroy supporting resources.

Rule

FortiSandbox Azure Deployment Security-Control Modification

Rule Format

Azure Monitor scheduled query rule using KQL against the AzureActivity table.

Detection Purpose

Detect unauthorized Azure control-plane changes affecting an identified FortiSandbox deployment.

Detection Logic

Identify successful Azure Resource Manager write, delete, or action operations involving FortiSandbox resource groups or explicitly inventoried FortiSandbox resources.

Prioritize changes affecting:

·        Network security groups, public IP addresses, network interfaces, virtual networks, route tables, or load balancers.

·        Virtual machines, disks, snapshots, extensions, availability sets, or managed identities.

·        Azure role assignments, role definitions, or access controls.

·        Diagnostic settings, Log Analytics workspaces, alert rules, action groups, or monitoring resources.

·        Storage accounts, containers, encryption, network access, lifecycle controls, or access policies.

·        Key Vault access policies, role assignments, keys, certificates, or secrets supporting the deployment.

·        Resource deletion, virtual-machine deallocation, or destructive modification.

Exclude validated infrastructure-as-code deployments, approved maintenance, incident-response actions, and documented administrative changes.

Required Telemetry

·        Azure Activity Log exported to a Log Analytics workspace.

·        FortiSandbox subscription, resource-group, resource-ID, virtual-machine, network, storage, identity, Key Vault, and monitoring inventory.

·        OperationNameValue, ActivityStatusValue, CategoryValue, ResourceId, ResourceGroup, ResourceProviderValue, Caller, CallerIpAddress, Authorization_d, Properties_d, and TimeGenerated.

·        Approved administrator, service-principal, managed-identity, automation, maintenance, and change-management context.

·        Azure Monitor scheduled query rule and action group.

Engineering Implementation Instructions

·        Maintain dedicated FortiSandbox resource groups where practical.

·        Replace the resource-group placeholders with validated FortiSandbox resource groups.

·        If FortiSandbox shares resource groups with other systems, add exact ResourceId filtering before production deployment.

·        Export Activity Log data from every relevant subscription to the monitored workspace.

·        Preserve caller, source IP, operation, resource, authorization scope, and correlation identifiers.

·        Maintain approved-change and approved-principal enrichment in the SIEM or alert workflow.

·        Do not globally suppress deployment or automation identities.

·        Increase severity for identity, network exposure, monitoring disruption, Key Vault, storage-control, deallocation, and destructive operations.

·        Increase severity when the same caller changes multiple FortiSandbox resources within 30 minutes.

·        Treat this rule as supporting cloud-control detection, not proof of appliance-local command execution.

DRI Assessment

Strong for unauthorized Azure control-plane modification affecting a FortiSandbox deployment. It does not detect appliance-local execution when no Azure Resource Manager operation occurs.

DRI

8.6/10

TCR Assessment

The rule is operationally viable when FortiSandbox resources are completely inventoried and Activity Log data is collected from all relevant subscriptions.

Operational TCR

8.5/10

Full-Telemetry TCR

9.3/10

Limitations

·        The rule cannot directly detect command injection inside the FortiSandbox guest.

·        Shared resource groups can increase false positives.

·        Approved automation may generate similar changes.

·        Guest-operating-system changes are outside Azure Activity Log visibility.

·        Data-plane access may require separate Azure resource logs.

·        Resource attribution may fail when inventories are incomplete.

·        A matched Azure change does not prove that FortiSandbox was compromised.

Detection Query Pattern

Use the following KQL after replacing the resource-group placeholders and mapping approved-change enrichment:

let FortiSandboxResourceGroups = dynamic([

    "<fortisandbox-resource-group-1>",

    "<fortisandbox-resource-group-2>"

]);

AzureActivity

| where CategoryValue =~ "Administrative"

| where ActivityStatusValue =~ "Succeeded"

| where ResourceGroup in~ (FortiSandboxResourceGroups)

| extend Operation = tolower(OperationNameValue)

| where Operation endswith "/write"

    or Operation endswith "/delete"

    or Operation endswith "/action"

    or Operation endswith "/deallocate/action"

| extend ChangeClass = case(

    Operation has "networksecuritygroups"

        or Operation has "publicipaddresses"

        or Operation has "networkinterfaces"

        or Operation has "virtualnetworks"

        or Operation has "routetables"

        or Operation has "loadbalancers",

        "Network Control Change",

    Operation has "roleassignments"

        or Operation has "roledefinitions"

        or Operation has "managedidentities",

        "Identity or Access Change",

    Operation has "diagnosticsettings"

        or Operation has "scheduledqueryrules"

        or Operation has "activitylogalerts"

        or Operation has "actiongroups"

        or Operation has "workspaces",

        "Monitoring or Logging Change",

    Operation has "vaults"

        or Operation has "keys"

        or Operation has "secrets"

        or Operation has "certificates",

        "Key Vault Change",

    Operation has "storageaccounts"

        or Operation has "blobservices"

        or Operation has "containers",

        "Storage Control Change",

    Operation has "virtualmachines/deallocate"

        or Operation endswith "/deallocate/action",

        "Virtual Machine Deallocation",

    Operation has "virtualmachines"

        or Operation has "disks"

        or Operation has "snapshots"

        or Operation has "extensions"

        or Operation has "availabilitysets",

        "Compute Change",

    Operation endswith "/delete",

        "Resource Deletion",

    "Other Control-Plane Change"

)

| summarize

    ChangeCount = count(),

    DistinctResources = dcount(ResourceId),

    ChangeClasses = make_set(ChangeClass),

    Operations = make_set(OperationNameValue),

    Resources = make_set(ResourceId),

    SourceIPs = make_set(CallerIpAddress)

    by bin(TimeGenerated, 30m), Caller, SubscriptionId, ResourceGroup

| where ChangeCount >= 2

    or set_has_element(ChangeClasses, "Identity or Access Change")

    or set_has_element(ChangeClasses, "Network Control Change")

    or set_has_element(ChangeClasses, "Monitoring or Logging Change")

    or set_has_element(ChangeClasses, "Key Vault Change")

    or set_has_element(ChangeClasses, "Storage Control Change")

    or set_has_element(ChangeClasses, "Virtual Machine Deallocation")

    or set_has_element(ChangeClasses, "Resource Deletion")

| project

    TimeGenerated,

    Caller,

    SourceIPs,

    SubscriptionId,

    ResourceGroup,

    ChangeCount,

    DistinctResources,

    ChangeClasses,

    Operations,

    Resources

GCP

Detection Viability Assessment

GCP provides supporting cloud-control coverage when FortiSandbox is deployed in Google Cloud or relies on GCP-hosted networking, identity, storage, logging, or management resources. GCP telemetry does not directly prove command injection inside the FortiSandbox guest operating system. Cloud Audit Logs and Cloud Monitoring can detect control-plane changes that weaken isolation, alter instance identity, disrupt logging, expose management access, or destroy supporting resources.

Rule

FortiSandbox GCP Deployment Security-Control Modification

Rule Format

Google Cloud log-based alerting policy using Cloud Audit Logs.

Detection Purpose

Detect unauthorized GCP control-plane changes affecting an identified FortiSandbox deployment.

Detection Logic

Identify administrative operations involving FortiSandbox projects, instances, networks, service accounts, storage resources, logging controls, or encryption resources.

Prioritize changes affecting:

·        Compute Engine instances, metadata, service accounts, disks, snapshots, or instance deletion.

·        Firewall rules, routes, networks, subnetworks, external addresses, or forwarding rules.

·        Project IAM policies, service accounts, or service-account keys.

·        Logging sinks, exclusions, buckets, or monitoring alert policies.

·        Cloud Storage bucket configuration, access, retention, encryption, or deletion.

·        Cloud KMS keys, key versions, or IAM policies supporting the deployment.

Exclude validated infrastructure-as-code deployments, approved maintenance, incident-response actions, and documented administrative changes.

Required Telemetry

·        Cloud Audit Logs Admin Activity events from all projects hosting FortiSandbox resources.

·        FortiSandbox project IDs, instance names, resource names, networks, service accounts, buckets, logging resources, and KMS resources.

·        protoPayload.methodName, protoPayload.serviceName, protoPayload.authenticationInfo, protoPayload.authorizationInfo, protoPayload.request, protoPayload.resourceName, resource, and timestamp.

·        Approved administrator, service-account, automation, maintenance, and change-management context.

·        Cloud Monitoring log-based alerting policy and notification channel.

Engineering Implementation Instructions

·        Maintain an inventory of all GCP resources supporting FortiSandbox.

·        Replace the project placeholders with validated FortiSandbox project identifiers.

·        Collect Admin Activity logs from every relevant project.

·        Preserve principal identity, caller IP, service name, method name, resource name, authorization data, and request details.

·        Validate that the affected resource belongs to the FortiSandbox deployment before escalation.

·        Maintain approved-principal and approved-change enrichment in the alert workflow.

·        Do not globally suppress automation or service accounts.

·        Increase severity for IAM, firewall, metadata, service-account, logging, encryption, and destructive changes.

·        Treat this rule as supporting cloud-control detection, not proof of appliance-local command execution.

DRI Assessment

Strong for unauthorized GCP control-plane modification affecting a FortiSandbox deployment. It does not detect appliance-local execution when no GCP administrative operation occurs.

DRI

8.6/10

TCR Assessment

The rule is operationally viable when FortiSandbox resources are completely inventoried and Admin Activity logs are retained and monitored across all relevant projects.

Operational TCR

8.5/10

Full-Telemetry TCR

9.3/10

Limitations

·        The rule cannot directly detect command injection inside the FortiSandbox guest.

·        Resource attribution may fail when inventories are incomplete.

·        Approved automation may generate similar changes.

·        Guest-operating-system changes are outside Cloud Audit Logs control-plane visibility.

·        Object-level storage activity requires separately enabled Data Access audit logs.

·        A matched GCP change does not prove that FortiSandbox was compromised.

Detection Query Pattern

Use the following Cloud Logging filter after replacing the FortiSandbox project placeholders:

log_id("cloudaudit.googleapis.com/activity")

AND resource.labels.project_id=(

  "<fortisandbox-project-1>" OR

  "<fortisandbox-project-2>"

)

AND (

  protoPayload.methodName=(

    "v1.compute.instances.setMetadata" OR

    "v1.compute.instances.setServiceAccount" OR

    "v1.compute.instances.delete" OR

    "v1.compute.instances.stop" OR

    "v1.compute.disks.delete" OR

    "v1.compute.snapshots.delete" OR

    "v1.compute.firewalls.insert" OR

    "v1.compute.firewalls.patch" OR

    "v1.compute.firewalls.update" OR

    "v1.compute.firewalls.delete" OR

    "v1.compute.routes.insert" OR

    "v1.compute.routes.delete" OR

    "v1.compute.networks.patch" OR

    "v1.compute.networks.delete" OR

    "v1.compute.subnetworks.patch" OR

    "v1.compute.subnetworks.delete" OR

    "v1.compute.addresses.insert" OR

    "v1.compute.addresses.delete" OR

    "v1.compute.forwardingRules.insert" OR

    "v1.compute.forwardingRules.delete" OR

    "google.iam.admin.v1.CreateServiceAccount" OR

    "google.iam.admin.v1.UpdateServiceAccount" OR

    "google.iam.admin.v1.DisableServiceAccount" OR

    "google.iam.admin.v1.DeleteServiceAccount" OR

    "google.iam.admin.v1.CreateServiceAccountKey" OR

    "google.iam.admin.v1.UploadServiceAccountKey" OR

    "google.iam.admin.v1.DisableServiceAccountKey" OR

    "google.iam.admin.v1.DeleteServiceAccountKey" OR

    "google.logging.v2.ConfigServiceV2.CreateSink" OR

    "google.logging.v2.ConfigServiceV2.UpdateSink" OR

    "google.logging.v2.ConfigServiceV2.DeleteSink" OR

    "google.logging.v2.ConfigServiceV2.CreateExclusion" OR

    "google.logging.v2.ConfigServiceV2.UpdateExclusion" OR

    "google.logging.v2.ConfigServiceV2.DeleteExclusion" OR

    "google.logging.v2.ConfigServiceV2.UpdateBucket" OR

    "google.logging.v2.ConfigServiceV2.UpdateBucketAsync" OR

    "google.logging.v2.ConfigServiceV2.DeleteBucket" OR

    "google.monitoring.v3.AlertPolicyService.UpdateAlertPolicy" OR

    "google.monitoring.v3.AlertPolicyService.DeleteAlertPolicy" OR

    "storage.buckets.update" OR

    "storage.buckets.delete" OR

    "UpdateCryptoKey" OR

    "UpdateCryptoKeyPrimaryVersion" OR

    "UpdateCryptoKeyVersion" OR

    "DeleteCryptoKey" OR

    "DeleteCryptoKeyVersion" OR

    "DestroyCryptoKeyVersion"

  )

  OR (

    protoPayload.methodName="SetIamPolicy"

    AND (

      resource.type="project"

      OR protoPayload.resourceName:"/keyRings/"

      OR protoPayload.resourceName:"/cryptoKeys/"

    )

  )

)

Configure a log-based alerting policy to notify when this filter matches and validate that the affected resource belongs to the FortiSandbox deployment before escalation.

S26 — Threat-to-Rule Traceability Matrix

Traceability Purpose

This section maps the primary behavioral threat conditions in this report to the S25 detection coverage developed across NDR / Network Behavioral Analytics, SentinelOne, Splunk, Elastic, QRadar, SIGMA, YARA, AWS, Azure, and GCP.

The traceability model is behavior-led. It does not rely on a single CVE identifier, exploit name, proof-of-concept name, command string, file path, request path, source IP, user-agent value, scanner result, campaign name, actor name, or static indicator as the basis for coverage.

Coverage Scope

The S25 rule set provides coverage for observable behavior associated with suspicious FortiSandbox management-plane interaction, command-injection precursors, probable appliance-local command or process execution, unexpected native Input, System, Job, VM, Threat, Database, Report, Performance, Resource, HA, Notification, and SNMP Events, unauthorized administrative or security-control changes, analysis-profile and VM manipulation, scan-flow or rescan disruption, threat-finding or verdict manipulation, report or result-delivery interference, suspicious file or script activity, appliance-originated outbound communication, credential or session misuse, downstream integration abuse, and supporting AWS, Azure, and GCP control-plane changes.

Coverage is strongest where FortiSandbox native event classes; administrative, authentication, API, CLI-history, kernel, configuration, update, logging, notification, and integration telemetry; process and file telemetry where available; request and network telemetry; administrator and FortiCloud IAM context; approved-workflow records; downstream integration logs; cloud audit telemetry; and SIEM correlation can be joined into bounded behavioral sequences.

Primary Coverage Areas

·        Suspicious external or internal interaction with FortiSandbox management, API, service, upload, reporting, analysis, or administrative interfaces

·        Repeated, malformed, encoded, unusual, or functionally inconsistent requests directed at FortiSandbox services

·        Unexpected shell, interpreter, command, utility, service, controller, daemon, system, or child-process activity associated with the appliance

·        Suspicious script, file, temporary-artifact, archive, staging, payload, persistence, or transfer activity associated with appliance compromise

·        Unexpected Input or System Events involving submissions, users, administrators, services, daemons, controllers, updates, configuration, or privileged appliance operations

·        Job or VM Events showing unexplained scan-flow changes, rescan behavior, processing interruption, assignment changes, lifecycle disruption, failure, reset, or recovery

·        Threat, Database, or Report Events showing unexplained finding suppression, reclassification, state changes, report modification, report deletion, export, suppression, or delivery interference

·        Performance, Resource, HA, Notification, or SNMP Events showing suspicious degradation, capacity changes, failover, synchronization failure, alert-delivery interruption, destination changes, or notification suppression

·        Unauthorized changes to analysis profiles, VM assignments, detonation behavior, submission handling, scan flow, verdict generation, quarantine actions, reporting, notifications, or result delivery

·        Unauthorized changes to administrators, authentication controls, access policies, logging, monitoring, networking, integrations, update controls, certificates, trusted hosts, or other security-relevant configuration

·        FortiSandbox-originated communication to rare, newly observed, unapproved, or high-risk external destinations

·        Unexpected use of administrative credentials, sessions, API access, service accounts, tokens, certificates, or trusted integrations

·        Downstream activity involving connected Fortinet, SIEM, SOAR, endpoint, email, storage, cloud, analysis, orchestration, or management systems

·        For FortiSandbox PaaS, unexpected FortiCloud IAM-user, mapped-profile, secondary-account, region, tenant, API, or service-setting changes

·        Supporting AWS, Azure, and GCP control-plane changes affecting cloud-hosted FortiSandbox deployments

Traceability Mapping

Suspicious FortiSandbox Management-Plane Interaction

This behavior is covered where network, appliance, authentication, proxy, firewall, or SIEM telemetry identifies unusual access to FortiSandbox management services, administrative endpoints, APIs, upload functions, reporting interfaces, analysis services, or trusted management paths.

Mapped Coverage

·        NDR / Network Behavioral Analytics provides primary network coverage for unusual management access, new source-to-appliance relationships, unexpected protocols, abnormal timing, repeated requests, command-like input, and management access followed by suspicious egress

·        SentinelOne, Splunk, Elastic, and QRadar provide correlation across FortiSandbox access logs, authentication events, request behavior, appliance identity, administrator identity, source context, native events, and approved workflows

·        SIGMA provides portable event-level coverage for suspicious FortiSandbox request and appliance activity where the backend supplies the required normalized fields

·        AWS, Azure, and GCP contribute only when FortiSandbox is cloud-hosted and related cloud-control changes affect the identified deployment

Coverage Qualification

·        Access to the FortiSandbox management interface alone is not sufficient

·        A rare source IP alone is not sufficient

·        Repeated requests alone are not sufficient

·        Use of HTTPS alone is not sufficient

·        A malformed or encoded request alone is not sufficient

·        Successful administrative authentication alone is not sufficient

·        Coverage requires FortiSandbox asset mapping, management-path context, actor identity, source context, request behavior, event ordering, approved-workflow evaluation, or corroborating appliance, native-event, endpoint, network, configuration, or integration evidence

·        Approved administration, vulnerability validation, vendor support, deployment, upgrade, troubleshooting, maintenance, monitoring, security testing, and incident-response activity requires validation rather than unconditional suppression

Probable Command Injection and Appliance-Local Execution

This behavior is covered where suspicious FortiSandbox interaction is followed by unexpected CLI, kernel, command, shell, interpreter, utility, service, controller, system, process, file, configuration, or network activity consistent with unauthorized execution.

Mapped Coverage

·        SentinelOne provides primary correlation where FortiSandbox events, request telemetry, network telemetry, and conditional process, CLI, kernel, or system telemetry are available

·        Splunk, Elastic, and QRadar provide primary correlation across suspicious request activity, native events, authentication context, administrative actions, appliance state, configuration changes, and network behavior

·        SIGMA provides portable event-level coverage for suspicious FortiSandbox request and appliance activity where normalized command-execution or state-change events exist

·        NDR / Network Behavioral Analytics provides supporting evidence where suspicious interaction is followed by callbacks, rare egress, high-entropy DNS, downloads, tunneling, raw-IP communication, or unusual internal access

·        AWS, Azure, and GCP do not directly detect command execution inside the FortiSandbox guest and provide only surrounding infrastructure context

Coverage Qualification

·        A shell process alone is not sufficient

·        A CLI command alone is not sufficient

·        An interpreter process alone is not sufficient

·        A service restart alone is not sufficient

·        A suspicious command string alone is not sufficient

·        A delayed response, timeout, fault, or resource spike alone is not sufficient

·        Coverage requires FortiSandbox asset attribution, unexpected execution or state-change context, suspicious management interaction, unusual user or session context, native-event evidence, file or network behavior, configuration modification, or another corroborating signal

·        Legitimate maintenance, diagnostics, upgrades, malware analysis, support activity, testing, and incident response may produce similar behavior

·        Detection may establish probable command execution without independently proving the exact command or request that caused it

Suspicious Script, File, Payload, or Staging Activity

This behavior is covered where appliance, infrastructure, or supporting-host telemetry identifies unexpected script creation, temporary-file activity, archive creation, payload retrieval, executable staging, file transfer, persistence-related changes, or command-output artifacts associated with suspected FortiSandbox compromise.

Mapped Coverage

·        SentinelOne provides endpoint and data-lake coverage where file, script, process, archive, transfer, or network events are available

·        Splunk, Elastic, and QRadar provide primary SIEM correlation where file, process, request, native-event, authentication, network, and administrative telemetry is normalized

·        SIGMA provides supporting portable event-level coverage when the required file or execution telemetry exists

·        NDR / Network Behavioral Analytics provides supporting coverage where payload retrieval, staging, collection, or transfer is followed by unusual outbound communication

·        YARA has no deployable primary rules because stable malicious file content is not established

Coverage Qualification

·        A temporary file alone is not sufficient

·        Script execution alone is not sufficient

·        Archive creation alone is not sufficient

·        File permission or ownership change alone is not sufficient

·        A downloaded executable alone is not sufficient

·        FortiSandbox routinely processes malicious and suspicious files; sample presence alone does not establish appliance compromise

·        Coverage requires FortiSandbox asset context, suspicious execution lineage, administrative anomaly, staging behavior, persistence behavior, transfer activity, or corroborating request, native-event, network, or configuration evidence

FortiSandbox Native-Event and Analysis-Control Manipulation

This behavior is covered where FortiSandbox native events identify unexplained changes or disruption involving submission intake, system operation, analysis jobs, sandbox virtual machines, threat findings, database state, reports, performance, resources, high availability, notifications, SNMP activity, or result delivery.

Mapped Coverage

·        SentinelOne, Splunk, Elastic, and QRadar provide primary correlation across Input, System, Job, VM, Threat, Database, Report, Performance, Resource, HA, Notification, SNMP, administrative, configuration, authentication, request, and network telemetry

·        SIGMA provides portable event-level coverage for successful or completed FortiSandbox identity, logging, configuration, analysis-profile, VM, rescan, verdict, quarantine, threat, database, report, resource, performance, notification, and integration changes

·        NDR / Network Behavioral Analytics provides supporting evidence when native-event anomalies align with suspicious inbound interaction, rare egress, callbacks, or unexpected internal communication

·        SentinelOne, Splunk, Elastic, and QRadar provide PaaS support where FortiCloud IAM-user, mapped-profile, secondary-account, tenant, region, API, or service-setting events are available

·        AWS, Azure, and GCP provide supporting infrastructure context but do not directly identify FortiSandbox analysis-pipeline manipulation

Coverage Qualification

·        A Job Event failure alone is not sufficient

·        A VM reset, interruption, or failure alone is not sufficient

·        A threat reclassification alone is not sufficient

·        A verdict difference alone is not sufficient

·        A report difference, deletion, or delivery failure alone is not sufficient

·        A database event alone is not sufficient

·        A performance or resource anomaly alone is not sufficient

·        An HA, Notification, or SNMP event alone is not sufficient

·        Coverage requires FortiSandbox appliance or PaaS attribution, event ordering, affected submission, sample, URL, job, VM, profile, finding, verdict, report, database, notification, or integration context, approved-workflow evaluation, or corroborating request, identity, configuration, network, or downstream evidence

·        Approved malware analysis, rescanning, profile tuning, VM maintenance, content updates, report retention, database maintenance, failover testing, troubleshooting, vendor support, and incident response require validation

·        Native-event correlation may identify probable analysis-control manipulation without independently proving the command or mechanism that caused it

Unauthorized Security-Control or Administrative Configuration Change

This behavior is covered where FortiSandbox logs, configuration records, administrative events, native events, or SIEM telemetry identify unauthorized changes to accounts, access policies, trusted hosts, authentication, certificates, API credentials, logging, reporting, notifications, network controls, integrations, analysis profiles, VM settings, updates, or other security-relevant configuration.

Mapped Coverage

·        SentinelOne, Splunk, Elastic, and QRadar provide primary correlation across administrator activity, FortiCloud IAM activity, configuration changes, affected control areas, source context, prior suspicious activity, and approved-change records

·        SIGMA provides portable event-level coverage for successful identity, administrative, logging, configuration, certificate, API, notification, analysis, and integration changes

·        NDR / Network Behavioral Analytics provides supporting evidence where the change alters exposure, communication paths, or appliance-originated traffic

·        AWS, Azure, and GCP provide supporting cloud-control coverage where changes affect infrastructure surrounding the FortiSandbox deployment

Coverage Qualification

·        A configuration change alone is not sufficient

·        An administrator-account change alone is not sufficient

·        A logging or notification change alone is not sufficient

·        A network-policy change alone is not sufficient

·        A certificate, token, or trusted-host change alone is not sufficient

·        Coverage requires affected-control classification, actor identity, source context, change outcome, prior or subsequent suspicious behavior, approved-workflow evaluation, or corroborating appliance, native-event, network, identity, or cloud evidence

·        Approved deployment, profile tuning, upgrade, integration, content update, maintenance, troubleshooting, recovery, and incident-response changes require complete workflow validation

FortiSandbox-Originated Rare or Unapproved Egress

This behavior is covered where network telemetry identifies FortiSandbox communicating with a rare, newly observed, unapproved, anomalous, or high-risk destination after suspicious request, execution, native-event, identity, file, credential, configuration, or analysis-control activity.

Mapped Coverage

·        NDR / Network Behavioral Analytics provides primary network coverage for FortiSandbox-originated callbacks, high-entropy DNS, downloads, raw-IP communication, unusual protocols, tunneling, beacons, and rare destinations

·        SentinelOne, Splunk, Elastic, and QRadar provide correlation across FortiSandbox events, source and destination context, DNS, proxy, firewall, flow, identity, approved destinations, and bounded sequencing

·        SIGMA provides portable event-level support where the backend performs asset-aware temporal correlation

·        AWS, Azure, and GCP provide supporting context where cloud networking or infrastructure changes relate to the same deployment

Coverage Qualification

·        Outbound communication alone is not sufficient

·        A newly observed destination alone is not sufficient

·        Destination reputation alone is not sufficient

·        TCP 443 alone is not sufficient

·        High transfer volume alone is not sufficient

·        Malware-detonation traffic must be distinguished from appliance-management and service traffic

·        Coverage requires appliance attribution, prior suspicious behavior, process, service, identity, session, native-event, or configuration context, destination rarity, approved-destination evaluation, and bounded sequencing

Credential, Session, API, Certificate, or Trusted-Integration Misuse

This behavior is covered where an administrator account, API identity, service account, session, token, certificate, SSH key, mail credential, storage credential, cloud setting, or trusted integration associated with FortiSandbox is used outside expected source, workflow, time, privilege, role, or operational context.

Mapped Coverage

·        SentinelOne, Splunk, Elastic, and QRadar provide primary identity and session correlation across FortiSandbox authentication, administrative activity, API access, FortiCloud IAM, certificates, tokens, trusted hosts, connected systems, and approved workflows

·        SIGMA provides portable event-level coverage for identity, administrative, certificate, token, API, logging, and integration modifications

·        NDR / Network Behavioral Analytics provides supporting context for unusual source-to-appliance and appliance-to-connected-system relationships

·        AWS, Azure, and GCP provide supporting control-plane coverage when cloud identities or infrastructure associated with the deployment are modified

Coverage Qualification

·        Successful authentication alone is not sufficient

·        Use of a privileged identity alone is not sufficient

·        An API call alone is not sufficient

·        A certificate or token change alone is not sufficient

·        Use outside normal business hours alone is not sufficient

·        Coverage requires identity context, source context, session continuity, privilege use, affected resource, behavioral deviation, approved-workflow evaluation, or corroborating appliance, native-event, network, or configuration evidence

Downstream Integration and Connected-System Activity

This behavior is covered where suspicious FortiSandbox activity is followed by unauthorized use of connected Fortinet products, SIEM, SOAR, endpoint, email, storage, cloud, analysis, management, or other trusted systems.

Mapped Coverage

·        SentinelOne, Splunk, Elastic, and QRadar provide primary cross-platform correlation between suspicious FortiSandbox activity and downstream administrative, credential, policy, trust, alerting, quarantine, logging, configuration, or data-access behavior

·        NDR / Network Behavioral Analytics provides primary or supporting coverage for unusual FortiSandbox-originated access to internal security, identity, cloud-management, hypervisor, backup, storage, code, deployment, or administrative systems

·        SIGMA provides supporting event-level coverage where connected-system actions are normalized

·        AWS, Azure, and GCP provide supporting control-plane coverage when the connected deployment or integration uses those platforms

Coverage Qualification

·        Downstream administrative activity alone is not sufficient

·        Connected-system authentication alone is not sufficient

·        A policy, trust, logging, or alert change alone is not sufficient

·        Automation execution alone is not sufficient

·        Coverage requires reliable FortiSandbox-to-integration linkage, identity or credential context, suspicious upstream behavior, affected-system attribution, bounded timing, and approved-workflow evaluation

·        Activity that cannot be linked to suspicious FortiSandbox behavior remains outside this traceability path

AWS Coverage Disposition

AWS provides one supporting control-plane rule for unauthorized changes affecting an AWS-hosted FortiSandbox deployment.

Coverage includes security-group changes, network-interface changes, EC2 instance-profile changes, metadata-option changes, IAM-role and policy changes, access-key activity, CloudTrail disruption, EventBridge disruption, CloudWatch log-group deletion, S3 bucket-control changes, instance termination, volume deletion or detachment, and snapshot deletion.

AWS does not directly detect command injection, native FortiSandbox analysis manipulation, or guest-operating-system execution. Promotion requires reliable FortiSandbox resource attribution and qualifying AWS control-plane activity.

Azure Coverage Disposition

Azure provides one supporting control-plane rule for unauthorized changes affecting an Azure-hosted FortiSandbox deployment.

Coverage includes network-control changes, identity and access changes, monitoring and logging changes, Key Vault changes, storage-control changes, virtual-machine deallocation, resource deletion, and repeated control-plane modifications affecting identified FortiSandbox resources.

Azure does not directly detect command injection, native FortiSandbox analysis manipulation, or guest-operating-system execution. Promotion requires reliable resource-group or resource-ID attribution and qualifying Azure Activity Log evidence.

GCP Coverage Disposition

GCP provides one supporting control-plane rule for unauthorized changes affecting a Google Cloud-hosted FortiSandbox deployment.

Coverage includes Compute Engine metadata and service-account changes, instance and disk destruction, firewall and route changes, network changes, IAM and service-account administration, logging sink and exclusion changes, logging-bucket changes, monitoring-policy changes, Cloud Storage bucket changes, and Cloud KMS activity.

GCP does not directly detect command injection, native FortiSandbox analysis manipulation, or guest-operating-system execution. Promotion requires reliable project and resource attribution and qualifying Cloud Audit Log evidence.

NDR / Network Behavioral Analytics Coverage Disposition

NDR / Network Behavioral Analytics provides three primary network-behavior rules for suspicious FortiSandbox request activity followed by execution-consistent network behavior, outbound callback or command-and-control-like communication, and FortiSandbox-originated access to unusual internal security or management systems.

NDR cannot independently confirm appliance-local command execution, identify the exact command executed, prove analysis-profile or verdict manipulation, establish credential theft, or confirm downstream compromise without FortiSandbox native events, administrative, identity, configuration, endpoint, or destination-platform telemetry.

SentinelOne Coverage Disposition

SentinelOne provides three correlated rules for suspicious FortiSandbox requests followed by appliance-state change, FortiSandbox analysis-control, identity, logging, and configuration manipulation, and outbound communication or downstream integration abuse.

Coverage may include native System, Job, VM, Threat, Database, Report, Performance, Resource, HA, Notification, SNMP, administrative, authentication, configuration, CLI-history, kernel, API, network, PaaS, FortiCloud IAM, and connected-product telemetry ingested into Singularity AI SIEM or Singularity Data Lake.

SentinelOne does not independently prove the exact command executed or establish that every native-event anomaly resulted from command injection.

Splunk Coverage Disposition

Splunk provides three primary SIEM-correlation rules across suspicious FortiSandbox requests, native appliance-state changes, administrator and authentication activity, analysis profiles, jobs, VMs, rescans, threat findings, verdicts, quarantine actions, databases, reports, notifications, logging, configuration, outbound communication, approved workflows, and downstream integrations.

Coverage depends on reliable field normalization, appliance identity, event ordering, approved-change enrichment, destination baselines, and separation of appliance traffic from malware-detonation traffic.

Elastic Coverage Disposition

Elastic provides three primary sequence and correlation rules across suspicious FortiSandbox requests, native appliance events, administrator and identity activity, analysis profiles, jobs, VMs, threats, databases, reports, performance, resources, notifications, configuration changes, network activity, cloud activity, and downstream integrations.

Coverage depends on reliable ECS-compatible or locally normalized fields, EQL or equivalent sequence construction, asset and identity enrichment, event ordering, exceptions, and approved-workflow context.

QRadar Coverage Disposition

QRadar provides three primary CRE correlation rules across suspicious FortiSandbox requests, native Input, System, Job, VM, Threat, Database, Report, Performance, Resource, HA, Notification, SNMP, administrative, configuration, identity, network, cloud, and connected-system events.

Coverage depends on DSM parsing, custom properties, FortiSandbox asset building blocks, reference data, event ordering, approved-action context, offense grouping, and temporal correlation.

SIGMA Coverage Disposition

SIGMA provides three portable event-level rules for suspicious FortiSandbox request and appliance activity, identity, administrative, logging, configuration, certificate, API, notification, and integration modification, and analysis-pipeline or operational-control disruption involving jobs, VMs, threats, databases, reports, performance, resources, and notifications.

SIGMA is useful for portable event-rule construction but does not independently provide full request-to-event, multi-source, or temporal correlation unless the target backend implements it.

YARA Coverage Disposition

YARA has zero deployable rules for this EXP report.

YARA is not viable as a primary S25 detection system because the governing detection model is behavioral, sequence-based, appliance-event driven, identity-context based, administrative-control based, analysis-pipeline based, network-correlation based, SIEM-correlation based, and downstream integration-correlation based rather than static-file or malware-signature based.

YARA may provide limited supporting value only if responders recover a validated malicious binary, script, exploit artifact, encoded payload, archive, memory artifact, command-execution utility, persistence mechanism, or reusable malware family independently linked to the incident.

Final YARA Outcome

No YARA rules survive.

Coverage Gaps and Non-Coverage Conditions

The S25 rule set does not independently prove that a suspicious request successfully triggered command injection, that a specific command executed, that an attacker obtained persistent appliance control, that credentials or sessions were stolen, that a verdict or report was maliciously manipulated, or that downstream activity resulted from FortiSandbox compromise.

Coverage Weakens Under the Following Conditions

·        FortiSandbox administrative, authentication, API, appliance, configuration, process, or network telemetry is unavailable, incomplete, delayed, rotated, or not ingested

·        Input, System, Job, VM, Threat, Database, Report, Performance, Resource, HA, Notification, or SNMP Events are unavailable, incompletely parsed, or not retained

·        Sample, URL, job, VM, analysis-profile, threat, verdict, quarantine, database, report, notification, or result-delivery identifiers cannot be correlated

·        FortiCloud IAM and PaaS administrative telemetry is unavailable or cannot be reconciled with the affected account, tenant, region, service, API, or access profile

·        FortiSandbox asset identity, management interfaces, administrative services, trusted integrations, deployment model, or cloud resources are not inventoried

·        CLI-history, kernel, process, command-line, script, file, archive, persistence, or process-linked network telemetry is unavailable

·        Management requests are not logged with sufficient source, session, account, endpoint, parameter, action, or outcome context

·        Reverse proxies, VPNs, NAT, management systems, or trusted networks obscure the original request source

·        Analysis manipulation is selective and affects only one submission, job, VM, finding, verdict, report, notification, or integration without broad service degradation

·        Legitimate engine, content, profile, VM, timing, network, or submission differences cannot be distinguished from malicious verdict or report manipulation

·        Local logs rotate or reports expire before investigation

·        Native events show a resulting state change but do not expose the underlying execution path

·        Appliance compromise occurs in memory without durable file, process, configuration, native-event, or network evidence

·        Service faults, queue delays, database errors, VM failures, performance changes, and resource spikes cannot be separated from ordinary processing

·        Logging, forwarding, or notifications are disabled before relevant evidence is preserved

·        Malware-detonation traffic cannot be reliably distinguished from appliance-management or service traffic

·        Connected systems do not preserve originating identity, certificate, token, service account, source, session, or integration context

·        AWS, Azure, or GCP resource inventories are incomplete

·        Cloud control-plane changes occur inside approved automation but cannot be distinguished from malicious use

·        Data-plane or guest-operating-system activity is incorrectly assumed to be visible through cloud control-plane logs

·        Vendor support, upgrades, content updates, profile tuning, VM changes, database maintenance, report retention, failover testing, automation, malware analysis, or incident-response activity is not accurately modeled

·        The attacker uses legitimate credentials, expected administrators, familiar source systems, trusted management paths, normal business hours, approved destinations, standard utilities, or low-volume activity

·        Vulnerable-state findings, public exploitation reporting, proof-of-concept availability, scanner findings, or CVE references are treated as compromise evidence without local behavioral support

·        A clean appliance review is treated as proof that command injection, analysis manipulation, credential misuse, or downstream compromise did not occur

Traceability Conclusion

The S25 detection set provides broad behavior-led coverage across suspicious FortiSandbox management-plane interaction, probable command injection and appliance-local execution, native Input and System Event anomalies, Job and VM disruption, Threat, Database, and Report manipulation, Performance, Resource, HA, Notification, and SNMP anomalies, analysis-profile and result-delivery interference, script and payload activity, unauthorized security-control modification, rare or unapproved appliance-originated egress, credential or session misuse, downstream integration activity, FortiCloud IAM and PaaS administration, and supporting AWS, Azure, and Google Cloud control-plane changes.

Coverage is strongest where FortiSandbox native event classes, administrative and authentication logs, API and PaaS telemetry, CLI-history and kernel evidence where available, process and file telemetry, configuration-change records, submission, job, VM, threat, database, report, performance, resource, notification, network, administrator identity, connected-system, approved-workflow, cloud audit, and time-bounded SIEM correlation are available.

The rule set intentionally avoids treating CVE status, vulnerable versions, management access, successful authentication, command strings, shell processes, native-event faults, Job or VM anomalies, verdict differences, report differences, temporary files, configuration changes, rare destinations, administrator identities, cloud changes, scanner results, campaign names, actor names, or any other isolated indicator as proof of compromise.

Detection confidence depends on correlating suspicious FortiSandbox interaction, native appliance and analysis-pipeline events, probable command or process execution, file and script activity, identity and security-control changes, job and VM behavior, threat and verdict state, database and report activity, notification and logging health, appliance-originated communication, downstream integration behavior, and cloud-control activity while preserving the distinction between exposure, suspicious request activity, probable execution, appliance or service compromise, analysis-control compromise, security-control compromise, and downstream compromise.

S27 — Behavior & Log Artifacts

Purpose

This section identifies the primary behavior and log artifacts that support detection, investigation, triage, and validation for suspicious FortiSandbox management-plane interaction, probable command injection, appliance-local execution, native-event anomalies, analysis-pipeline manipulation, unauthorized security-control modification, suspicious script or file activity, appliance-originated outbound communication, credential or session misuse, downstream integration activity, FortiCloud IAM or PaaS administration, and supporting AWS, Azure, and GCP control-plane changes.

The artifacts below are behavior-led. They should not be treated as proof of successful command injection, persistent appliance compromise, malicious verdict manipulation, credential theft, unauthorized downstream access, data exposure, or cloud compromise unless they are correlated into a coherent sequence.

Primary Artifact Categories

·        FortiSandbox management-plane access and network-path artifacts

·        FortiSandbox authentication, administrator, API, certificate, token, and session artifacts

·        FortiSandbox Input, System, Job, VM, Threat, Database, Report, Performance, Resource, HA, Notification, and SNMP Event artifacts

·        Analysis-profile, submission-flow, rescan, verdict, quarantine, report-generation, notification, and result-delivery artifacts

·        FortiCloud IAM-user, mapped-profile, secondary-account, PaaS instance, tenant, region, API, and service-setting artifacts

·        Appliance-local process, command, shell, interpreter, service, controller, and execution artifacts

·        Script, file, payload, archive, staging, persistence, and transfer artifacts

·        FortiSandbox configuration, logging, monitoring, integration, update, and security-control artifacts

·        Appliance-originated network, DNS, proxy, firewall, flow, and destination artifacts

·        Administrative-workstation, remote-management, credential, and endpoint artifacts

·        Downstream integration, connected-system, automation, and administrative artifacts

·        Supporting AWS, Azure, and Google Cloud control-plane artifacts

·        Actor, source, appliance, session, process, submission, job, VM, finding, report, configuration, integration, resource, and timestamp correlation artifacts

FortiSandbox Management-Plane and Network-Access Artifacts

Relevant Artifacts

FortiSandbox appliance ID, appliance hostname, deployment type, management IP, management interface, service interface, administrative endpoint, API endpoint, upload endpoint, reporting endpoint, analysis endpoint, source host, source IP, destination IP, source ASN, source geography, destination port, protocol, HTTP method, request path, parameter name, encoded-value indicator, request size, response code, response size, latency, authentication result, session identifier, administrator identity, API identity, user agent, first-seen source-to-appliance relationship, rare source, unusual timing, repeated request behavior, command-control-character indicator, parameter-function mismatch, policy violation, proxy action, firewall action, network flow, appliance criticality, and event timestamp.

Useful Log Sources

·        FortiSandbox administrative, authentication, API, and system logs

·        FortiSandbox Input and System Events

·        Reverse-proxy logs

·        Web-application firewall logs

·        Firewall logs

·        NDR / Network Behavioral Analytics telemetry

·        VPN and remote-access logs

·        Identity-provider and privileged-access logs

·        SIEM-normalized management telemetry

·        Asset, deployment, and application inventory

Detection Use

These artifacts support detection when an unusual source, identity, system, or session accesses FortiSandbox management, API, service, upload, reporting, analysis, or administrative functions in a manner inconsistent with established behavior.

They are strongest when followed by native-event anomalies, probable execution, analysis-control manipulation, security-control changes, unusual egress, or downstream integration activity.

Investigation Use

Investigators should determine whether the source, administrator, API identity, session, endpoint, method, parameter characteristics, timing, authentication result, management route, and affected appliance align with approved administration, automation, vendor support, vulnerability validation, deployment, upgrade, troubleshooting, monitoring, malware analysis, testing, or incident response.

Non-Coverage Conditions

Management access alone is not sufficient.

A rare source IP alone is not sufficient.

Repeated requests alone are not sufficient.

HTTPS access alone is not sufficient.

Command-like input alone is not sufficient.

These artifacts require asset mapping, management-path context, actor identity, source context, request behavior, event ordering, approved-workflow evaluation, or corroborating native-event, endpoint, network, configuration, or integration evidence.

FortiSandbox Authentication, Administrator, API, and Session Artifacts

Relevant Artifacts

Administrator account, remote-authentication user, FortiCloud IAM user, account role, mapped access profile, API identity, integration identity, service account, authentication source, result, failed-authentication count, successful login, logout, session identifier, session source, privilege level, role assignment, administrator creation, administrator deletion, password change, API-key creation, token creation, token revocation, certificate change, SSH-key change, trusted-host change, account enablement, account disablement, authentication-policy change, multi-factor authentication state, source-address restriction, and event timestamp.

Useful Log Sources

·        FortiSandbox authentication and administrative logs

·        FortiCloud IAM logs

·        LDAP, Active Directory, RADIUS, or TACACS+ logs

·        Privileged-access management logs

·        VPN and reverse-proxy logs

·        API gateway logs

·        SIEM-normalized identity and session telemetry

Detection Use

These artifacts support detection when an administrator, remote user, FortiCloud IAM user, API identity, integration identity, service account, certificate, token, or session is used outside expected source, time, privilege, role, interface, workflow, or operational context.

Investigation Use

Investigators should validate the identity’s expected role, access profile, source systems, normal schedule, approved task, authentication method, privilege use, account changes, certificate or token activity, and relationship to subsequent native events, configuration changes, execution, egress, or downstream behavior.

Non-Coverage Conditions

Successful authentication alone is not sufficient.

Use of a privileged identity alone is not sufficient.

A failed-authentication burst alone is not sufficient.

A new API key, token, certificate, or session alone is not sufficient.

These artifacts require identity, source, privilege, session, affected-resource, workflow, and corroborating appliance or network context.

FortiSandbox Native-Event and Analysis-Pipeline Artifacts

Relevant Artifacts

Input Event type, submission source, device, adapter, network share, ICAP client, BCC adapter, MTA adapter, file identifier, URL identifier, sample hash, System Event type, administrator action, user action, configuration action, update action, daemon or controller activity, Job Event, job identifier, scan-flow stage, analysis state, rescan state, processing result, failure state, VM Event, VM identifier, VM assignment, initialization, reset, interruption, recovery, Threat Event, threat finding, classification, suppression, reclassification, Database Event, database action, Report Event, report identifier, generation, access, export, modification, deletion, delivery, Performance Event, Resource Event, HA Event, node role, synchronization state, failover state, Notification Event, SNMP Event, destination, delivery result, analysis profile, verdict, quarantine action, result-delivery state, and event timestamp.

Useful Log Sources

·        FortiSandbox Input Events

·        FortiSandbox System Events

·        FortiSandbox Job Events

·        FortiSandbox VM Events

·        FortiSandbox Threat Events

·        FortiSandbox Database Events

·        FortiSandbox Report Events

·        FortiSandbox Performance Events

·        FortiSandbox Resource Events

·        FortiSandbox HA Events

·        FortiSandbox Notification Events

·        FortiSandbox SNMP Events

·        FortiSandbox administrative and configuration logs

·        FortiAnalyzer, FortiAnalyzer Cloud, remote syslog, or SIEM copies

·        Submission, report, and result-delivery records

·        Change-management and maintenance records

Detection Use

These artifacts support detection when suspicious request or administrative activity is followed by unexplained changes in submissions, system operation, jobs, virtual machines, threat findings, database state, reports, performance, resources, high availability, notifications, or result delivery.

They also support detection when analysis profiles, rescans, verdicts, quarantine actions, reports, notifications, or defensive outputs are modified outside an approved workflow.

Investigation Use

Investigators should preserve the submission, file, URL, sample, job, VM, profile, threat, verdict, quarantine, database, report, notification, appliance, node, actor, source, action, status, and timestamp relationships.

Investigators should determine whether the activity aligns with expected malware analysis, duplicate submission, rescan, content update, profile tuning, VM maintenance, database maintenance, report retention, failover testing, troubleshooting, vendor support, or incident response.

Non-Coverage Conditions

A Job Event anomaly alone is not sufficient.

A VM failure or reset alone is not sufficient.

A threat reclassification alone is not sufficient.

A verdict difference alone is not sufficient.

A report deletion, difference, or delivery failure alone is not sufficient.

A performance, resource, HA, Notification, or SNMP anomaly alone is not sufficient.

These artifacts require appliance or PaaS attribution, affected-object identity, event ordering, approved-workflow validation, historical comparison, or corroborating request, identity, configuration, CLI, kernel, network, or downstream evidence.

Native events may identify the resulting state change without exposing the underlying command or execution path.

FortiSandbox PaaS and FortiCloud IAM Artifacts

Relevant Artifacts

FortiCloud account, FortiCloud IAM user, mapped access profile, secondary account, PaaS instance, tenant, region, service setting, API identity, administrative action, authentication event, access-profile change, region change, account association, service-setting change, support action, source IP, session, action result, and event timestamp.

Useful Log Sources

·        FortiCloud IAM logs

·        FortiSandbox PaaS administrative logs

·        PaaS API and service logs

·        FortiCloud account and secondary-account records

·        Customer-accessible service-status evidence

·        Vendor-support records

·        SIEM-normalized PaaS telemetry

Detection Use

These artifacts support detection when FortiCloud IAM users, mapped profiles, secondary accounts, tenants, regions, APIs, or service settings change unexpectedly or align with suspicious FortiSandbox activity.

Investigation Use

Investigators should validate the account, IAM user, profile, secondary account, tenant, region, source, session, API, affected service setting, approval record, and vendor-support context.

Non-Coverage Conditions

A FortiCloud login alone is not sufficient.

An IAM-user change alone is not sufficient.

A region, tenant, profile, or service-setting change alone is not sufficient.

PaaS activity requires identity, source, session, affected-service, approved-workflow, or corroborating FortiSandbox event context.

Appliance-Local Command, Process, Shell, and Interpreter Artifacts

Relevant Artifacts

CLI command, kernel event, process name, process path, process ID, parent process, command line, process user, effective user, shell invocation, interpreter invocation, utility execution, service action, daemon action, controller action, system action, child-process creation, working directory, remote-session context, process-linked network connection, process-linked file activity, and event timestamp.

Useful Log Sources

·        FortiSandbox CLI-history logs

·        FortiSandbox kernel logs

·        FortiSandbox System Events

·        Diagnostic or vendor-assisted telemetry

·        SentinelOne or other EDR telemetry where applicable

·        Hypervisor, infrastructure, console, or operating-system telemetry where available

·        SIEM-normalized execution telemetry

Detection Use

These artifacts support detection when suspicious FortiSandbox interaction is followed by unexpected CLI, kernel, shell, interpreter, command, utility, service, controller, daemon, or system activity.

Investigation Use

Investigators should determine whether the activity aligns with FortiSandbox operation, malware analysis, diagnostics, content updates, support, maintenance, upgrade, recovery, or incident response.

Non-Coverage Conditions

A CLI command alone is not sufficient.

A kernel event alone is not sufficient.

A shell, interpreter, service, or controller action alone is not sufficient.

Direct execution telemetry may be unavailable in appliance or PaaS deployments.

These artifacts require request, identity, native-event, configuration, file, or network corroboration.

Script, File, Payload, Archive, Staging, and Persistence Artifacts

Relevant Artifacts

File name, path, type, hash, owner, permissions, creation, modification, deletion, temporary directory, script creation, script execution, archive creation, archive extraction, payload retrieval, executable staging, configuration export, credential or certificate artifact, persistence file, service modification, startup change, permission change, hidden file, encoded content, transfer utility, and event timestamp.

Useful Log Sources

·        SentinelOne or EDR telemetry where available

·        File-integrity monitoring

·        Diagnostic, infrastructure, storage, backup, or vendor-assisted telemetry

·        FortiSandbox system and configuration logs

·        Script, archive, package, or network-share logs

·        SIEM-normalized file and persistence telemetry

Detection Use

These artifacts support detection when suspicious FortiSandbox activity is followed by unexpected script creation, payload retrieval, temporary-file activity, archive creation, executable staging, credential or configuration export, persistence behavior, or transfer.

Investigation Use

Investigators should determine whether the artifact belongs to an expected malware sample, analysis package, diagnostic bundle, software update, support package, backup, recovery, or incident-response workflow.

Non-Coverage Conditions

A temporary file alone is not sufficient.

Script execution alone is not sufficient.

Archive creation alone is not sufficient.

FortiSandbox routinely handles malicious files; file presence alone does not establish appliance compromise.

Configuration, Logging, Monitoring, Integration, and Security-Control Artifacts

Relevant Artifacts

Configuration object, prior value, new value, administrator identity, source, result, logging level, log destination, remote forwarding, report retention, kernel logging, CLI logging, submission-event logging, notification state, SNMP destination, administrative-access policy, trusted host, authentication policy, network policy, route, DNS, NTP, proxy, mail, storage, update, licensing, repository, certificate, analysis profile, VM assignment, verdict setting, quarantine setting, integration configuration, API configuration, service state, database state, and event timestamp.

Useful Log Sources

·        FortiSandbox administrative and configuration logs

·        System, Job, VM, Threat, Database, Report, Notification, and SNMP Events

·        Configuration exports and backups

·        Change-management records

·        FortiAnalyzer, syslog, or SIEM telemetry

·        File-integrity monitoring

·        Connected-system logs

·        Cloud audit logs

Detection Use

These artifacts support detection when an unauthorized actor changes FortiSandbox identities, authentication, logging, notifications, reporting, analysis controls, networking, integrations, updates, certificates, or other security-relevant controls.

Investigation Use

Investigators should identify the exact object changed, actor, source, prior value, new value, outcome, approval record, and surrounding request, native-event, execution, network, or integration activity.

Non-Coverage Conditions

A configuration change alone is not sufficient.

A logging, notification, report, profile, VM, verdict, or network change alone is not sufficient.

These artifacts require affected-control classification, actor attribution, approved-workflow evaluation, event ordering, or corroborating evidence.

Appliance-Originated Network and Egress Artifacts

Relevant Artifacts

FortiSandbox source IP, source interface, destination IP, domain, port, protocol, DNS query, TLS metadata, source service or identity, connection start, duration, bytes, destination ASN, geography, reputation, first-seen state, rare destination, high-entropy DNS, raw-IP communication, repeated callback, beaconing, tunneling, transfer behavior, proxy action, firewall action, NDR anomaly, detonation-traffic classification, and event timestamp.

Useful Log Sources

·        NDR / Network Behavioral Analytics telemetry

·        Firewall, proxy, DNS, IDS, flow, and packet telemetry

·        SentinelOne or EDR network telemetry where available

·        Threat-intelligence enrichment

·        SIEM-normalized network telemetry

Detection Use

These artifacts support detection when FortiSandbox communicates with rare, newly observed, unapproved, or high-risk destinations after suspicious request, native-event, execution, identity, credential, configuration, or analysis-control activity.

Investigation Use

Investigators should determine whether the destination is associated with Fortinet updates, licensing, reputation services, DNS, NTP, mail, storage, cloud, logging, management, support, malware detonation, or an approved integration.

Non-Coverage Conditions

Outbound communication alone is not sufficient.

Destination reputation alone is not sufficient.

TCP 443 alone is not sufficient.

Detonation traffic must be separated from appliance or service traffic.

Administrative-Workstation, Remote-Management, and Credential Artifacts

Relevant Artifacts

Administrative workstation, jump host, remote-management platform, administrator identity, credential-access event, browser session, password-store access, API-key access, scripting, PowerShell, SSH, remote desktop, file transfer, clipboard transfer, process lineage, VPN session, privileged-access session, session recording, and endpoint alert.

Useful Log Sources

·        SentinelOne or EDR telemetry

·        Privileged-access management logs

·        VPN, SSH, remote desktop, browser, and PowerShell logs

·        Credential-protection telemetry

·        SIEM-normalized administrative-endpoint telemetry

Detection Use

These artifacts support detection when a managed endpoint or administrative platform accesses FortiSandbox and performs suspicious credential, script, process, transfer, or remote-management activity.

Non-Coverage Conditions

Remote administration alone is not sufficient.

PowerShell or SSH use alone is not sufficient.

Reliable source-to-appliance, identity, and behavioral linkage is required.

Downstream Integration and Connected-System Artifacts

Relevant Artifacts

Integration name, connected system, API identity, service account, certificate, token, source system, destination system, authentication event, administrative action, policy change, trust change, alert suppression, quarantine change, logging change, workflow execution, automation execution, report or indicator delivery, file submission, storage access, credential creation, configuration modification, and event timestamp.

Useful Log Sources

·        FortiSandbox integration logs

·        Connected Fortinet product logs

·        SIEM and SOAR audit logs

·        Email, endpoint, firewall, cloud, storage, and management-platform logs

·        API gateway logs

·        Connected-system administrative logs

Detection Use

These artifacts support detection when suspicious FortiSandbox activity is followed by unauthorized administrative, automation, policy, trust, logging, quarantine, credential, configuration, or data-access activity in a connected system.

Non-Coverage Conditions

Connected-system activity alone is not sufficient.

Reliable FortiSandbox integration, identity, source, action, and time-window linkage is required.

AWS Control-Plane Artifacts

Relevant Artifacts

AWS account ID, Region, resource ARN, EC2 instance ID, network interface, security group, IAM role, instance profile, principal, source IP, event source, event name, request parameters, security-group change, metadata-option change, IAM-policy change, access-key activity, CloudTrail change, EventBridge change, log-group deletion, S3 bucket-control change, instance termination, volume action, snapshot deletion, and event timestamp.

Detection Use

These artifacts support detection when unauthorized AWS control-plane changes affect an identified FortiSandbox deployment.

Non-Coverage Conditions

AWS control-plane telemetry does not directly detect command injection, native FortiSandbox manipulation, or guest-operating-system execution.

Azure Control-Plane Artifacts

Relevant Artifacts

Subscription ID, resource group, resource ID, caller, caller IP, operation name, activity status, network-security-group change, public-IP change, network-interface change, route change, role assignment, managed-identity change, monitoring or diagnostic-setting change, Key Vault change, storage-control change, virtual-machine deallocation, resource deletion, and event timestamp.

Detection Use

These artifacts support detection when unauthorized Azure Resource Manager changes affect an identified FortiSandbox deployment.

Non-Coverage Conditions

Azure Activity Log does not directly detect command injection, native FortiSandbox manipulation, or guest-operating-system execution.

GCP Control-Plane Artifacts

Relevant Artifacts

Project ID, resource name, principal email, caller IP, service name, method name, Compute Engine instance, metadata, service account, service-account key, firewall rule, route, network, subnetwork, address, forwarding rule, IAM policy, logging sink, exclusion, logging bucket, alert policy, Cloud Storage bucket, KMS key, authorization data, request data, and event timestamp.

Detection Use

These artifacts support detection when unauthorized Google Cloud control-plane changes affect an identified FortiSandbox deployment.

Non-Coverage Conditions

Google Cloud control-plane logs do not directly detect command injection, native FortiSandbox manipulation, or guest-operating-system execution.

YARA Artifact Disposition

YARA has no deployable primary-rule artifact set for this EXP report.

YARA is not viable as a primary artifact model because the report’s detection surface is behavioral, sequence-based, appliance-event driven, analysis-pipeline based, identity-context based, administrative-control based, network-correlation based, SIEM-correlation based, and downstream integration-correlation based rather than stable malicious file content.

YARA may become useful only if a validated malicious binary, script, exploit artifact, encoded payload, archive, memory artifact, command-execution utility, persistence mechanism, or reusable malware family is recovered and independently linked to the incident.

Final YARA Outcome

No YARA rules survive.

S28 — Detection Strategy and SOC Implementation Guidance

Figure 5

Purpose

This section provides implementation guidance for operationalizing the S25 rule set and S26 traceability model across NDR / Network Behavioral Analytics, SentinelOne, Splunk, Elastic, QRadar, SIGMA, YARA, AWS, Azure, GCP, FortiSandbox, FortiCloud IAM, endpoint, network, SIEM, SOAR, cloud, connected-system, and incident-response environments.

The detection strategy is sequence-based. It prioritizes correlated behavior over single-event alerting and avoids treating a CVE identifier, vulnerable-version observation, command string, request path, file path, source IP, user agent, administrator identity, native-event fault, verdict difference, cloud event, scanner finding, or static indicator as proof of compromise.

Implementation Strategy

Deploy the detection model in layered stages:

·        FortiSandbox appliance, cluster, node, PaaS instance, tenant, region, management interface, service interface, API, exposure, ownership, integration, and business-criticality context first

·        Administrator, remote user, FortiCloud IAM user, API identity, integration identity, service account, certificate, token, session, role, privilege, and approved-access context second

·        Management request, source, protocol, path, parameter, encoding, request behavior, authentication outcome, and network-path context third

·        Native Input and System Event normalization fourth

·        Job, VM, Threat, Database, Report, Performance, Resource, HA, Notification, and SNMP Event normalization fifth

·        Submission, file, URL, sample, job, VM, analysis-profile, rescan, threat, verdict, quarantine, report, notification, and result-delivery lineage sixth

·        FortiCloud IAM, PaaS account, mapped-profile, secondary-account, tenant, region, API, and service-setting context seventh

·        Conditional CLI, kernel, process, command-line, shell, interpreter, service, controller, file, archive, staging, persistence, and process-linked network context eighth

·        Configuration, logging, monitoring, report-retention, identity, authentication, network, integration, update, analysis-control, and security-control context ninth

·        Appliance-originated DNS, proxy, firewall, flow, destination, reputation, first-seen, transfer, callback, and detonation-traffic context tenth

·        Administrative-workstation, remote-management, credential, VPN, endpoint, and privileged-access context eleventh

·        Downstream integration, connected-system, policy, trust, alert, quarantine, credential, data-access, and security-control context twelfth

·        Supporting AWS, Azure, and Google Cloud control-plane context thirteenth

·        Alert promotion only after telemetry validation, false-positive baselining, suppression governance, query testing, and triage-playbook alignment

Telemetry Normalization Requirements

Implementation requires normalized entity and time correlation across FortiSandbox native events, administrative and authentication records, FortiCloud IAM, API, endpoint, EDR, NDR, DNS, proxy, firewall, VPN, privileged access, connected systems, AWS, Azure, Google Cloud, change management, SOAR, incident response, and SIEM telemetry.

Minimum Normalization Requirements

·        FortiSandbox appliance ID

·        Deployment type

·        Cluster and node ID

·        PaaS instance

·        FortiCloud account

·        Tenant and region

·        Management and service interface

·        Administrative, API, upload, reporting, and analysis endpoint

·        Asset owner and criticality

·        Source host and IP

·        Destination IP, domain, port, and protocol

·        HTTP method, path, parameter metadata, encoding indicator, response, and latency

·        Administrator, remote user, FortiCloud IAM user, API identity, integration identity, and service account

·        Role, access profile, privilege, session, and authentication result

·        Native event type and subtype

·        Native message and device identifier

·        Native user interface, action, status, and message

·        Input source and submission source

·        File, URL, sample, and hash identifiers

·        Job identifier, job state, scan-flow stage, processing result, and rescan state

·        VM identifier, assignment, state, reset, failure, and recovery

·        Analysis-profile identifier

·        Threat-finding identifier and classification

·        Verdict and quarantine action

·        Database action

·        Report identifier, action, and delivery state

·        Notification destination and outcome

·        SNMP action

·        Performance and resource state

·        HA node, role, synchronization, and failover state

·        Result-delivery state

·        FortiCloud mapped profile and secondary account

·        PaaS API and service setting

·        CLI command and kernel event where available

·        Process, parent process, command line, user, and working directory where available

·        File, archive, payload, staging, persistence, and transfer action where available

·        Configuration object, prior value, new value, and change result

·        Logging, forwarding, report-retention, notification, and monitoring state

·        Network, DNS, proxy, firewall, destination, novelty, reputation, and detonation-traffic classification

·        Connected-system, integration, action, destination, identity, credential, and resource

·        AWS account, Region, principal, and resource ARN

·        Azure subscription, resource group, caller, and resource ID

·        GCP project, principal, service, method, and resource

·        Approved-workflow, change, maintenance, support, and testing context

·        SOAR and incident-response case ID

·        Event timestamp and source

Correlation Requirements

Rules should use bounded correlation windows that reflect the relationship between suspicious FortiSandbox access, native events, probable execution, analysis-pipeline changes, configuration changes, outbound communication, credential misuse, connected-system activity, and cloud-control changes.

Recommended Starting Windows

·        Suspicious request to probable command, CLI, kernel, system, service, configuration, or execution-consistent network behavior within 10 minutes

·        Suspicious request to unexpected Input, System, Job, VM, Threat, Database, Report, Performance, Resource, HA, Notification, or SNMP activity within 60 minutes

·        Suspicious request or administrator activity to unexplained scan-flow, rescan, analysis-profile, VM, verdict, quarantine, report, notification, or result-delivery change within 4 hours

·        Probable command or state-change activity to script, payload, file, archive, staging, persistence, or transfer activity within 30 minutes

·        Probable execution or security-control change to rare or unapproved egress within 60 minutes

·        Identity or analysis change to logging, forwarding, report, notification, or SNMP degradation within 30 minutes

·        Analysis-profile, VM, threat, verdict, report, database, notification, or logging change to downstream defensive-control activity within 8 hours

·        FortiCloud IAM or PaaS administrative change to suspicious FortiSandbox service, analysis, configuration, or integration activity within 4 hours

·        Suspicious FortiSandbox activity to downstream integration activity within 4 hours

·        Similar suspicious behavior across multiple appliances, nodes, PaaS instances, tenants, regions, or connected systems within 8 hours

·        Suspicious FortiSandbox activity to AWS, Azure, or GCP control-plane changes within 24 hours

·        Continued activity after containment, patching, credential reset, service restart, or session invalidation within 24 hours

These windows should be tightened in high-volume environments and extended only when actor, source, appliance, PaaS instance, session, submission, sample, job, VM, profile, finding, report, process, configuration, destination, integration, cloud-resource, SOAR, or incident-response continuity supports the extension.

Alert Promotion Guidance

Do not promote a hunt or correlation search into alert mode until:

·        Required telemetry is present and normalized

·        FortiSandbox physical, virtual, clustered, and PaaS inventory is reliable

·        Interfaces, endpoints, exposure paths, trusted hosts, reverse proxies, VPNs, and management routes are mapped

·        Administrators, remote users, FortiCloud IAM users, mapped profiles, API identities, integration identities, service accounts, certificates, tokens, and roles are understood

·        Input, System, Job, VM, Threat, Database, Report, Performance, Resource, HA, Notification, and SNMP Event parsing is validated

·        Submission, sample, URL, job, VM, profile, threat, verdict, quarantine, database, report, notification, and result-delivery identifiers are normalized

·        Expected submission flow, scan flow, rescan behavior, VM lifecycle, threat findings, verdict distribution, report generation, quarantine actions, notification delivery, and result delivery are understood

·        Legitimate profile tuning, VM maintenance, content updates, database maintenance, report retention, failover, and notification administration are baselined

·        CLI-history, kernel, process, file, script, archive, staging, persistence, and network mappings are validated where available

·        Logging, forwarding, report-retention, notification, authentication, network, integration, update, and analysis controls are classified

·        Malware-detonation traffic can be distinguished from appliance-management and service traffic

·        Expected Fortinet, update, licensing, reputation, DNS, NTP, mail, storage, logging, management, cloud, and support destinations are mapped

·        Connected-system and integration identities are mapped

·        FortiCloud IAM users, profiles, secondary accounts, tenants, regions, APIs, and service settings are inventoried where applicable

·        Durable remote logging and external report preservation are configured

·        Approved workflows and false-positive sources are defined

·        AWS, Azure, and GCP resource attribution is validated

·        Query performance, analyst review, severity, routing, and triage guidance are tested

False-Positive Control

False-positive control should use approved-workflow baselines, scoped allowlists, administrator and source baselines, API and automation inventories, native-event baselines, malware-analysis workflow records, submission and rescan records, FortiSandbox update and content records, profile and VM maintenance records, database and report-retention schedules, HA and notification records, integration inventories, vendor-support records, cloud automation inventories, and incident-response context.

Common False-Positive Sources

·        Approved FortiSandbox administration

·        Approved API or integration automation

·        Approved FortiCloud IAM or PaaS administration

·        Approved administrator, role, certificate, token, SSH-key, or trusted-host changes

·        Approved authentication, logging, forwarding, notification, SNMP, or report-retention changes

·        Approved network, storage, mail, cloud, update, licensing, repository, or integration changes

·        Approved malware-analysis activity

·        Approved duplicate submission or rescan activity

·        Approved analysis-profile tuning

·        Approved VM assignment, reset, recovery, or maintenance

·        Approved threat reclassification

·        Approved verdict or quarantine modification

·        Approved database maintenance

·        Approved report generation, export, deletion, delivery, or retention

·        Approved performance or resource management

·        Approved HA failover or synchronization testing

·        Approved diagnostic activity, troubleshooting, vendor support, vulnerability validation, and security testing

·        Approved upgrade, content update, migration, backup, recovery, and incident response

·        Approved endpoint, cloud, and downstream-system administration

·        Infrastructure-as-code, CI/CD, break-glass, managed-service, and security-tooling activity

Triage Guidance

Initial triage should determine whether suspicious activity forms a coherent sequence rather than a single-event anomaly.

Triage Questions

·        Was unusual management, API, service, upload, reporting, analysis, or administrative access observed

·        Was the source, identity, session, protocol, path, parameter, encoding, timing, or authentication state unusual

·        Did Input or System Events show unusual submissions, users, administrators, services, daemons, controllers, updates, or system actions

·        Did Job Events show unexplained scan-flow changes, cancellation, rescan activity, processing failure, verdict generation, report creation, or result-delivery changes

·        Did VM Events show unexpected assignment, initialization, reset, interruption, failure, recovery, or lifecycle activity

·        Did Threat Events show unexplained finding disappearance, suppression, reclassification, or inconsistency

·        Did Database or Report Events show unexpected access, modification, deletion, export, suppression, failure, or delivery changes

·        Did Performance, Resource, HA, Notification, or SNMP Events align with suspicious request, administrative, configuration, or execution activity

·        Did CLI, kernel, shell, interpreter, service, controller, process, or system activity follow

·        Did script, payload, file, archive, staging, persistence, credential, certificate, token, or transfer activity occur

·        Was the activity part of an expected malware-analysis workflow

·        Were analysis profiles, VM assignments, detonation behavior, submission handling, verdicts, quarantine actions, reports, notifications, or result-delivery paths modified

·        Could verdict or report differences be explained by engine, content, profile, VM, timing, network, or submission differences

·        Did an administrator, remote user, FortiCloud IAM user, API identity, certificate, token, trusted host, logging control, or integration change

·        For PaaS, did IAM users, access profiles, secondary accounts, tenants, regions, APIs, or service settings change

·        Did rare or unapproved outbound communication follow

·        Was the traffic associated with malware detonation or the appliance management and service plane

·        Did downstream integration or connected-system activity follow

·        Did AWS, Azure, or GCP control-plane activity affect the deployment

·        Can the activity be linked by actor, source, appliance, node, PaaS instance, session, submission, sample, job, VM, profile, threat, verdict, report, process, configuration, destination, integration, cloud resource, SOAR case, or incident case

·        Is the activity explained by approved administration, malware analysis, rescanning, tuning, updates, support, maintenance, failover, testing, automation, cloud activity, or incident response

Escalation Guidance

Escalate when multiple behavior classes align in sequence, especially when suspicious FortiSandbox interaction is followed by native-event anomalies, probable execution, analysis-control manipulation, logging degradation, rare egress, credential misuse, downstream integration activity, or cloud-control changes.

Higher-Priority Escalation Conditions

·        An unexpected source, administrator, FortiCloud IAM user, API identity, or session accesses FortiSandbox

·        Suspicious request activity is followed by CLI, kernel, service, system, configuration, or execution-consistent network activity

·        Suspicious request or administrative activity is followed by unusual System, Job, VM, Threat, Database, Report, Performance, Resource, HA, Notification, or SNMP Events

·        Scan flow, rescans, profiles, VM assignments, threat findings, verdicts, quarantine actions, reports, notifications, or result delivery change outside an approved workflow

·        Threat findings, verdicts, reports, or quarantine outcomes conflict with duplicate submissions, independent analysis, endpoint detections, network detections, or threat-intelligence evidence

·        Identity or analysis changes occur with logging, forwarding, report, notification, or SNMP degradation

·        Probable execution is followed by scripts, payloads, archives, staging, persistence, credentials, or transfers

·        Probable execution or control modification is followed by rare or unapproved egress

·        A new administrator, API key, token, certificate, trusted host, role, or authentication exception appears

·        FortiCloud IAM or PaaS administrative changes align with suspicious FortiSandbox service, analysis, identity, configuration, or integration behavior

·        Suspicious FortiSandbox activity is followed by unauthorized connected-system policy, trust, logging, quarantine, credential, or administrative behavior

·        AWS, Azure, or GCP control-plane changes affect the same deployment

·        Similar suspicious behavior appears across multiple appliances, nodes, PaaS instances, tenants, regions, sessions, identities, or connected systems

·        Multiple systems independently show aligned behavior

Deployment Guardrails

Do not deploy these detections as fully automated blocking or containment logic without local validation.

Do not treat a CVE identifier, vulnerable version, request string, command string, CLI command, native event, Job or VM fault, verdict difference, report difference, temporary file, administrator identity, rare destination, configuration change, cloud event, scanner finding, or static indicator as proof of compromise.

Do not attribute endpoint-only, network-only, native-event-only, appliance-only, configuration-only, identity-only, integration-only, PaaS-only, or cloud-only anomalies to successful command injection, analysis manipulation, persistent compromise, credential theft, downstream compromise, or data exposure without reliable lineage.

Do not enable high-confidence alerting until platform-specific schemas, fields, FortiSandbox event mappings, native message identifiers, appliance and PaaS inventories, endpoint and network mappings, identity and integration mappings, cloud mappings, enrichment sources, exception lists, false-positive baselines, query performance, triage readiness, and escalation criteria have been validated.

S29 — Detection Coverage Summary

Coverage Summary

The S25 detection set provides broad behavior-led coverage for suspicious FortiSandbox management-plane interaction, probable command injection, appliance-local execution, unexpected native Input and System Events, Job and VM disruption, Threat, Database, and Report manipulation, Performance, Resource, HA, Notification, and SNMP anomalies, analysis-profile and result-delivery interference, suspicious script and file activity, unauthorized security-control modification, appliance-originated rare or unapproved egress, credential or session misuse, downstream integration activity, FortiCloud IAM and PaaS administration, and supporting AWS, Azure, and Google Cloud control-plane changes.

Coverage is strongest when FortiSandbox native event classes, administrative, authentication, API, PaaS, CLI-history, kernel, process, file, configuration, submission, job, VM, threat, database, report, performance, resource, notification, network, identity, endpoint, connected-system, cloud, and SIEM telemetry are normalized and correlated into bounded sequences.

The detection model intentionally avoids CVE-label-only matching, vulnerable-version-only matching, request-string-only matching, command-string-only matching, file-path-only matching, isolated source IPs, user-agent values, native-event-only conclusions, Job or VM fault conclusions, verdict-difference-only conclusions, administrator-identity-only conclusions, cloud-event-only conclusions, scanner findings, campaign names, actor names, tool names, and other single-event conclusions.

Strong Coverage Areas

·        Unusual FortiSandbox management, API, service, upload, reporting, analysis, or administrative access

·        Suspicious request activity followed by execution-consistent appliance or network behavior

·        Unexpected CLI, kernel, system, service, controller, configuration, or administrative activity

·        Script, payload, archive, staging, persistence, credential, certificate, token, or transfer activity associated with suspicious appliance behavior

·        Unexpected System Events involving users, administrators, services, daemons, controllers, updates, configuration, or privileged operations

·        Job Events showing unexplained submission, scan-flow, rescan, analysis, processing, verdict, report, or delivery changes

·        VM Events showing unexpected assignment, initialization, reset, interruption, failure, recovery, or lifecycle behavior

·        Threat, Database, and Report Events showing unexplained suppression, reclassification, modification, deletion, export, failure, or delivery interference

·        Performance, Resource, HA, Notification, and SNMP anomalies aligned with suspicious request, identity, configuration, or execution activity

·        Unauthorized analysis-profile, VM, detonation, verdict, quarantine, reporting, notification, or result-delivery changes

·        Unauthorized administrator, authentication, trusted-host, certificate, token, API, logging, network, update, integration, or security-control changes

·        FortiSandbox-originated communication to rare, newly observed, unapproved, or high-risk destinations

·        Suspicious use of administrative credentials, API identities, integration identities, sessions, certificates, tokens, or trusted access

·        Downstream policy, trust, alerting, quarantine, logging, credential, configuration, or administrative activity linked to suspicious FortiSandbox behavior

·        Unexpected FortiCloud IAM-user, access-profile, secondary-account, tenant, region, API, or service-setting changes

·        Supporting AWS, Azure, and GCP control-plane changes affecting identified deployments

Moderate Coverage Areas

·        Management-plane anomalies where request, identity, session, parameter, or source context is incomplete

·        Probable execution where CLI, kernel, process, command-line, service, or system context is partial

·        File or script activity where origin, purpose, execution state, or process lineage is incomplete

·        Native-event coverage where event classes or log-type-specific fields are incompletely parsed

·        Analysis-control coverage where sample, URL, job, VM, profile, threat, verdict, quarantine, report, notification, or result-delivery identifiers are incomplete

·        Verdict or report integrity analysis where duplicate-submission, independent-analysis, endpoint, network, or threat-intelligence comparison data is incomplete

·        Configuration changes where prior state, actor attribution, or approved-workflow context is incomplete

·        NDR visibility into suspicious request activity and rare egress without native-event, appliance, or identity enrichment

·        Administrative-workstation activity without reliable FortiSandbox session linkage

·        Connected-system activity where integration identity or action linkage is incomplete

·        PaaS coverage where FortiCloud IAM, tenant, region, profile, API, service-setting, or vendor-support telemetry is partial

·        SIGMA portability across SIEM backends

·        AWS, Azure, or GCP coverage where resource attribution is incomplete

Limited Coverage Areas

·        Command execution inside a closed appliance without CLI, kernel, process, native-event, configuration, or network evidence

·        In-memory or short-lived execution without durable artifacts

·        Management requests that lack source, session, parameter, identity, action, or result context

·        Activity performed with legitimate credentials from expected administrative systems

·        Low-volume activity that resembles normal maintenance, support, or malware analysis

·        Selective manipulation affecting only one submission, job, VM, threat finding, verdict, report, notification, or integration

·        Verdict or report manipulation indistinguishable from legitimate engine, content, profile, VM, timing, network, or submission differences

·        Native events that record resulting state changes without exposing the underlying command or execution path

·        PaaS activity where customer-accessible telemetry does not expose service-internal execution or diagnostic detail

·        Logs or reports lost through rotation or expiration before investigation

·        Logging, forwarding, notification, or auditing disabled before evidence is preserved

·        Credential or session theft performed on unmonitored systems

·        Downstream activity occurring after retention or correlation windows expire

·        Connected-system activity without reliable identity, credential, certificate, token, integration, or source linkage

·        Cloud guest activity that produces no AWS, Azure, or GCP control-plane event

·        Activity blending into approved administration, updates, tuning, support, monitoring, testing, automation, failover, or incident response

Non-Covered Areas

The S25 rule set does not directly prove:

·        Successful command injection

·        The exact command triggered by an exploit request

·        Persistent appliance or PaaS service compromise

·        Malicious manipulation of every verdict, report, finding, or result

·        Successful credential, certificate, token, or session theft

·        Unauthorized access to every connected system

·        Data theft

·        AWS, Azure, or Google Cloud guest compromise

·        Adversary attribution

·        Campaign attribution

These outcomes require investigation, corroborating telemetry, forensic evidence, and incident-specific validation.

System Coverage Summary

NDR / Network Behavioral Analytics

NDR provides three primary rules for suspicious FortiSandbox request activity followed by execution-consistent network behavior, outbound callback or command-and-control-like communication, and FortiSandbox-originated access to unusual internal security or management systems.

NDR supplies strong evidence for command-like request characteristics, abnormal source-to-appliance relationships, request-linked DNS, callbacks, downloads, rare destinations, beaconing, tunneling, and unusual downstream communication.

NDR does not independently confirm appliance-local execution, analysis manipulation, credential theft, or downstream compromise.

SentinelOne

SentinelOne provides three correlated rules for suspicious request activity followed by appliance-state change, analysis-control, identity, logging, and configuration manipulation, and outbound communication or downstream integration abuse.

Coverage includes normalized FortiSandbox native events, request telemetry, PaaS and FortiCloud IAM context, network telemetry, and connected-product records ingested into Singularity AI SIEM or Singularity Data Lake.

SentinelOne does not independently prove the exact command executed or that every native-event anomaly resulted from exploitation.

Splunk

Splunk provides three primary SIEM-correlation rules across suspicious requests, native appliance-state changes, administrators, FortiCloud IAM, analysis profiles, jobs, VMs, threats, verdicts, quarantine, databases, reports, notifications, logging, configuration, network activity, and downstream integrations.

Coverage depends on reliable normalization, appliance identity, event ordering, approved-workflow context, destination baselines, and separation of appliance traffic from detonation traffic.

Elastic

Elastic provides three primary sequence and correlation rules across suspicious requests, native events, identity activity, analysis controls, jobs, VMs, threats, databases, reports, performance, resources, notifications, configuration changes, network activity, and connected systems.

Coverage depends on ECS-compatible or locally normalized mappings, sequence construction, asset and identity enrichment, event ordering, exceptions, and approved-workflow context.

QRadar

QRadar provides three primary CRE correlation rules across suspicious requests, native Input, System, Job, VM, Threat, Database, Report, Performance, Resource, HA, Notification, SNMP, identity, configuration, network, cloud, and connected-system events.

Coverage depends on FortiSandbox DSM parsing, custom properties, building blocks, reference data, event ordering, approved-action context, and offense grouping.

SIGMA

SIGMA provides three portable event-level rules for suspicious FortiSandbox request and appliance activity, identity, administrative, logging, configuration, certificate, API, notification, and integration changes, and analysis-pipeline or operational-control disruption.

Production value depends on local field mappings, enrichment, backend translation, event-action normalization, exception handling, and any required temporal correlation.

YARA

YARA has zero deployable rules because no stable malicious binary, script, exploit artifact, archive family, command-execution utility, memory artifact, persistence mechanism, or reusable malware family is established.

AWS

AWS provides one supporting control-plane rule for unauthorized changes affecting an AWS-hosted FortiSandbox deployment.

AWS does not directly detect command injection, native FortiSandbox analysis manipulation, or guest execution.

Azure

Azure provides one supporting control-plane rule for unauthorized changes affecting an Azure-hosted FortiSandbox deployment.

Azure does not directly detect command injection, native FortiSandbox analysis manipulation, or guest execution.

GCP

GCP provides one supporting control-plane rule for unauthorized changes affecting a Google Cloud-hosted FortiSandbox deployment.

Google Cloud does not directly detect command injection, native FortiSandbox analysis manipulation, or guest execution.

Coverage Conclusion

The detection set provides strong practical coverage for observable enterprise behavior associated with suspicious FortiSandbox access, probable command execution, native appliance and analysis-pipeline events, job and VM disruption, threat, verdict, database, report, notification, and result-delivery manipulation, security-control modification, unusual appliance-originated communication, credential or session misuse, downstream integration activity, PaaS administration, and supporting cloud-control changes.

It is strongest when multiple telemetry classes align in sequence and weakest where execution, analysis manipulation, persistence, credential misuse, or downstream activity occurs without observable request, native-event, appliance, endpoint, file, process, configuration, submission, job, VM, threat, database, report, network, identity, integration, PaaS, or cloud anomalies.

S30 — Intelligence Maturity Assessment

Maturity Assessment Summary

The intelligence maturity level for this report is high for behavior-led detection strategy and moderate for direct compromise confirmation.

The detection model is mature because it focuses on durable behavioral relationships: suspicious FortiSandbox management interaction, probable command execution, native appliance events, analysis-job and VM behavior, threat and verdict state, database and report activity, notification and logging health, security-control modification, unusual outbound communication, credential or session misuse, downstream integration activity, FortiCloud IAM and PaaS administration, and supporting cloud-control changes.

Direct compromise confirmation remains limited because enterprise telemetry may not expose the exact exploit request, command-injection result, in-memory execution, malicious verdict or report manipulation, credential theft, persistence, or attacker intent directly.

Behavioral Intelligence Maturity

Behavioral maturity is high.

The report identifies repeatable behavior that can be detected across FortiSandbox, FortiCloud IAM, endpoint, EDR, NDR, DNS, proxy, firewall, VPN, privileged access, SIEM, SOAR, connected systems, AWS, Azure, and Google Cloud.

The behaviors are durable across CVE identifiers, exploit names, proof-of-concept names, request paths, command strings, file paths, source infrastructure, user agents, scanner results, campaign names, actor names, tooling changes, and cloud-provider variation.

Strong Behavioral Anchors

·        Unusual FortiSandbox management, API, service, upload, reporting, or analysis access

·        Suspicious request activity followed by CLI, kernel, system, service, configuration, or execution-consistent network behavior

·        Unexpected execution followed by scripts, payloads, archives, staging, persistence, credentials, or transfers

·        Unexpected Input or System Events involving submissions, users, administrators, services, daemons, controllers, updates, configuration, or privileged activity

·        Job or VM Events showing unexplained scan-flow changes, rescan behavior, assignment changes, interruption, failure, reset, or recovery

·        Threat, Database, or Report Events showing unexplained finding suppression, reclassification, state changes, deletion, export, failure, or delivery interference

·        Performance, Resource, HA, Notification, or SNMP anomalies aligned with suspicious request, identity, configuration, or execution behavior

·        Unauthorized analysis-profile, VM, detonation, verdict, quarantine, report, notification, or result-delivery changes

·        Unauthorized identity, authentication, logging, network, update, certificate, token, API, or integration changes

·        Probable execution or security-control modification followed by rare or unapproved egress

·        Suspicious use of administrators, FortiCloud IAM users, API identities, integration identities, certificates, tokens, sessions, or trusted access paths

·        Suspicious FortiSandbox behavior followed by downstream policy, trust, logging, quarantine, credential, configuration, or administrative behavior

·        Unexpected FortiCloud IAM-user, access-profile, secondary-account, tenant, region, API, or service-setting changes

·        Supporting AWS, Azure, or GCP control-plane changes affecting the same deployment

Telemetry Maturity

Telemetry maturity is moderate to high.

FortiSandbox Input, System, Job, VM, Threat, Database, Report, Performance, Resource, HA, Notification, and SNMP Events; administrative and authentication logs; API and PaaS telemetry; CLI-history and kernel evidence where enabled; NDR telemetry; endpoint telemetry; process and file telemetry where available; configuration records; network telemetry; administrative-workstation telemetry; connected-system logs; and cloud audit logs provide strong coverage where appliance, actor, source, session, submission, sample, URL, job, VM, profile, threat, verdict, database, report, notification, process, file, configuration, destination, integration, cloud resource, and timestamp fields are available and normalized.

Telemetry maturity decreases when the deployment operates as a closed appliance, native event classes are unavailable or incompletely parsed, process telemetry is unavailable, management requests are incompletely logged, configuration history is unavailable, sample-to-job-to-VM-to-verdict lineage cannot be reconstructed, reports have expired, PaaS telemetry is limited, integration identities are not preserved, or approved-workflow baselines are weak.

Appliance and Management-Plane Maturity

Appliance and management-plane maturity is moderate to strong.

FortiSandbox administrative, authentication, API, request, and configuration telemetry provides useful evidence when appliance identity, source, administrator, session, endpoint, action, affected control, and result context can be reconciled.

Maturity increases when all appliances, nodes, PaaS instances, interfaces, endpoints, remote-management paths, administrators, APIs, trusted hosts, and integrations are inventoried.

Management telemetry may establish suspicious access or unauthorized changes without independently proving command injection.

Native-Event and Analysis-Control Maturity

Native-event and analysis-control maturity is moderate to strong.

FortiSandbox Input, System, Job, VM, Threat, Database, Report, Performance, Resource, HA, Notification, and SNMP Events provide durable evidence when submission, sample, URL, job, VM, analysis profile, threat finding, verdict, database, report, notification, appliance, node, action, status, and timestamp relationships can be reconstructed.

Maturity increases when all native event classes are forwarded to durable storage, message and object identifiers are preserved, report retention is extended externally, verdicts and findings can be compared with duplicate submissions and independent telemetry, and approved analysis, maintenance, failover, database, reporting, and notification workflows are baselined.

Native events may identify suspicious analysis-control or operational changes without exposing the underlying command, process, or request that caused them.

PaaS and FortiCloud IAM Maturity

PaaS and FortiCloud IAM maturity is moderate.

FortiCloud IAM, mapped access-profile, secondary-account, tenant, region, API, administrative, service-setting, integration, service-status, and vendor-support evidence provides useful context for FortiSandbox PaaS.

Maturity decreases when customer-accessible telemetry does not expose service-internal execution, low-level diagnostics, complete administrative history, or sufficient tenant and region attribution.

PaaS telemetry can support suspicious access, administrative change, and service-impact conclusions but does not independently prove appliance-local command execution.

Endpoint and Execution Maturity

Endpoint and execution maturity is moderate.

CLI-history, kernel, process, command-line, file, script, persistence, and network telemetry can provide strong evidence of probable execution when available through appliance logging, diagnostics, infrastructure monitoring, EDR, hypervisor telemetry, or vendor assistance.

Maturity decreases when FortiSandbox does not expose direct execution telemetry, execution occurs in memory, command-line data is unavailable, or the attacker uses expected utilities and service functions.

Execution telemetry can support probable command execution but may not identify the exact request that triggered it.

Network Maturity

Network maturity is high for suspicious request, callback, egress, and downstream-access correlation and moderate for compromise confirmation.

NDR, DNS, proxy, firewall, IDS, flow, and packet telemetry provide durable evidence for command-like requests, unusual management paths, request-linked DNS, callbacks, downloads, raw-IP communication, tunneling, rare destinations, and unusual internal access.

Network maturity depends on separating appliance and service traffic from malware-detonation traffic.

Network telemetry does not independently prove appliance-local execution, analysis manipulation, credential theft, or downstream compromise.

Integration and Downstream Maturity

Integration and downstream maturity is moderate.

Connected-system logs provide useful evidence when FortiSandbox activity can be linked to the same integration identity, API identity, certificate, token, service account, source, destination, action, or affected resource.

Maturity decreases when integrations use shared identities, source context is lost, event timestamps are inconsistent, or downstream platforms do not preserve originating FortiSandbox context.

Cloud Maturity

Cloud maturity is moderate.

AWS, Azure, and Google Cloud provide useful supporting control-plane visibility when FortiSandbox deployments and associated resources are reliably inventoried.

Cloud platforms do not directly prove command injection, native FortiSandbox analysis manipulation, or guest-operating-system compromise.

AWS maturity depends on reliable resource attribution and CloudTrail coverage.

Azure maturity depends on subscription, resource-group, resource-ID, caller, and Activity Log coverage.

Google Cloud maturity depends on project, principal, resource, method, and Admin Activity coverage.

Adversary-Resilience Maturity

Adversary-resilience maturity is high for behavior-led detection and moderate for high-confidence compromise confirmation.

The detection model is resilient because it avoids brittle indicators and focuses on relationships an adversary may create when converting suspicious interface access into appliance activity, analysis manipulation, identity changes, logging degradation, unusual egress, trusted-integration abuse, or downstream security-control changes.

The model is less resilient when adversaries use expected administrators, familiar sources, trusted management paths, approved identities, standard utilities, normal business hours, expected destinations, ordinary malware-analysis behavior, or low-volume selective manipulation.

It is also less resilient when execution occurs in memory, native events are incomplete, logging is disabled before forwarding, reports expire, downstream activity is delayed beyond retention windows, or connected systems do not preserve identity and integration context.

Operationalization Maturity

Operationalization maturity is moderate.

The S25 rules are implementation-ready detection patterns, but production deployment requires local validation of schemas, source types, DSM fields, custom properties, ECS mappings, FortiSandbox event fields, native message identifiers, appliance and PaaS mappings, identity mappings, job and VM fields, threat and report fields, endpoint mappings, network mappings, integration mappings, cloud mappings, enrichment sources, exception lists, false-positive baselines, query performance, triage logic, and alert routing.

Operational maturity increases when detection owners validate telemetry quality, forward native events remotely, preserve reports externally, inventory appliances and PaaS services, baseline approved administration and analysis workflows, separate detonation traffic, and test realistic benign and suspicious sequences.

Attribution Maturity

Attribution maturity is low to moderate.

The rule set supports detection of behavior consistent with suspicious FortiSandbox access, probable command execution, native-event anomalies, analysis-control compromise, identity or logging manipulation, unusual egress, downstream integration abuse, and cloud-control changes.

It should not be used by itself to attribute activity to a specific adversary, campaign, exploit developer, infrastructure provider, malware family, or named threat group without external evidence and incident-specific validation.

Attribution requires corroborating evidence such as exploitation timelines, FortiSandbox logs, native event history, CLI or kernel evidence, process history, file artifacts, configuration history, source infrastructure, administrator activity, submission and job history, VM activity, verdict and report evidence, connected-system activity, cloud activity, victimology, tradecraft, and external intelligence reporting.

Maturity Limitations

Primary Maturity Limitations

·        Limited direct visibility into successful command injection

·        Limited visibility into the exact command triggered by an exploit request

·        Limited direct process visibility on appliance and PaaS deployments

·        Limited visibility into in-memory or short-lived execution

·        Variable FortiSandbox administrative, authentication, API, CLI, kernel, and request logging

·        Variable Input, System, Job, VM, Threat, Database, Report, Performance, Resource, HA, Notification, and SNMP Event availability

·        Variable native-event parsing and message-identifier normalization

·        Variable submission, sample, URL, job, VM, profile, threat, verdict, quarantine, report, notification, and result-delivery lineage

·        Variable configuration-history retention

·        Variable local-log retention and external forwarding

·        Variable local-report retention and external report preservation

·        Variable verdict and report integrity comparison data

·        Variable FortiCloud IAM and PaaS administrative visibility

·        Limited customer visibility into PaaS service internals and diagnostics

·        Native events may expose state changes without exposing the execution mechanism

·        Variable process, file, archive, staging, persistence, and transfer telemetry

·        Variable administrative-workstation and privileged-access visibility

·        Variable integration identity, certificate, token, and session preservation

·        Variable separation of appliance traffic from detonation traffic

·        Variable AWS, Azure, and GCP resource attribution

·        Variable approved-workflow baselines

·        High false-positive potential when detections are deployed without local tuning

Maturity Improvement Priorities

Priority Improvements

·        Maintain authoritative physical, virtual, clustered, and PaaS FortiSandbox inventories

·        Map every management, API, service, upload, reporting, analysis, and administrative interface

·        Improve FortiSandbox administrative, authentication, API, configuration, system, request, CLI-history, and kernel logging

·        Enable, forward, normalize, and retain Input, System, Job, VM, Threat, Database, Report, Performance, Resource, HA, Notification, and SNMP Events

·        Preserve native message identifiers, device identifiers, users, actions, statuses, interfaces, types, subtypes, and log-type-specific fields

·        Preserve submission, file, URL, sample, job, VM, analysis-profile, threat, verdict, quarantine, database, report, notification, and result-delivery relationships

·        Configure durable remote logging because local logs rotate at the supported capacity limit

·        Configure local report retention deliberately and preserve high-value reports externally

·        Baseline submission flow, scan flow, rescan behavior, VM lifecycle, threat findings, verdict distribution, report generation, quarantine actions, notification delivery, and result-delivery behavior

·        Compare suspicious verdicts and reports with duplicate submissions, independent sandboxes, endpoint detections, network detections, and threat-intelligence evidence

·        Inventory administrators, remote users, FortiCloud IAM users, mapped profiles, secondary accounts, PaaS instances, tenants, regions, APIs, service settings, certificates, tokens, trusted hosts, and integrations

·        Improve process, command-line, parent-process, shell, interpreter, service, script, file, archive, staging, persistence, and process-linked network telemetry where technically available

·        Improve administrative-workstation, jump-host, VPN, remote-management, and privileged-access telemetry

·        Improve NDR, DNS, proxy, firewall, IDS, flow, packet, destination-reputation, destination-first-seen, ASN, geography, and rare-egress normalization

·        Maintain approved destination inventories for Fortinet updates, licensing, reputation, DNS, NTP, mail, storage, logging, management, cloud, and support services

·        Separate malware-detonation traffic from appliance-management and service traffic

·        Improve FortiSandbox integration identity, certificate, token, service-account, source, destination, action, and resource logging

·        Improve connected-system policy, trust, alerting, quarantine, logging, configuration, and administrative telemetry

·        Improve AWS tagging and CloudTrail coverage

·        Improve Azure resource-group, resource-ID, caller, and Activity Log mappings

·        Improve Google Cloud project, principal, resource, method, and Admin Activity mappings

·        Build approved-workflow baselines for administration, PaaS activity, malware analysis, rescans, profile tuning, VM changes, database maintenance, reports, notifications, updates, support, monitoring, failover, testing, automation, and incident response

·        Test detections against realistic benign and suspicious sequences before alert promotion

Final Intelligence Maturity Assessment

The report’s intelligence maturity is strong for behavior-led detection engineering, strong for executive risk framing, moderate to strong for telemetry-driven operational detection, moderate to strong for FortiSandbox management, native-event, analysis-pipeline, endpoint, network, configuration, identity, SIEM, and sequence correlation, moderate for PaaS, downstream integration, and AWS, Azure, and Google Cloud control-plane correlation, and low to moderate for direct command-injection, persistence, credential-theft, malicious-result-manipulation, or attribution confirmation.

The S25 through S30 detection model is best used as an implementation-ready threat-to-detection framework that identifies suspicious FortiSandbox access, probable command execution, native appliance and analysis-pipeline anomalies, job and VM disruption, threat, verdict, database, report, notification, and result-delivery manipulation, unauthorized security-control modification, unusual appliance-originated communication, credential or session misuse, downstream integration activity, PaaS administration, and supporting cloud-control changes.

It should not be used as a standalone proof model for successful command injection, persistent appliance or PaaS compromise, malicious verdict or report manipulation, credential theft, downstream compromise, data theft, or adversary attribution without corroborating telemetry, forensic evidence, and incident-specific validation.

S31 — Telemetry Dependencies

FortiSandbox command injection and security-control compromise require telemetry capable of determining whether suspicious interface activity remained limited to scanning, malformed requests, failed exploitation, approved administration, expected malware-analysis behavior, service instability, or configuration drift, or progressed into probable unauthorized command execution, appliance or service compromise, analysis-control manipulation, logging degradation, credential or integration-secret access, persistent access, sensitive-submission exposure, or downstream security-control compromise. The central dependency is the ability to correlate FortiSandbox inventory, interface exposure, request telemetry, appliance-native events, CLI and kernel evidence, process and file activity where available, administrator and FortiCloud IAM activity, configuration and service state, analysis jobs, sandbox virtual machines, threat findings, verdicts, reports, notifications, databases, network behavior, cloud-control activity, connected-system activity, change-control evidence, incident-response records, and business context into one request-to-execution-to-defensive-control-compromise investigation model.

FortiSandbox Asset, Deployment, and Integration Context

·        Asset telemetry must identify FortiSandbox physical appliances, virtual appliances, cluster nodes, HA members, cloud-hosted systems, PaaS instances, tenants, regions, management interfaces, service interfaces, APIs, upload functions, reporting functions, analysis services, administrative paths, and externally reachable endpoints.

·        Integration telemetry must identify FortiGate, FortiManager, FortiAnalyzer, FortiAnalyzer Cloud, FortiMail, FortiWeb, SIEM, SOAR, endpoint-security, email-security, cloud-security, storage, identity, hypervisor, backup, orchestration, deployment, code, and administrative platforms connected to each FortiSandbox deployment.

·        Required fields include canonical asset identifier, serial number or instance identifier, deployment type, appliance role, cluster identifier, node identifier, tenant, region, interface type, management IP, service IP, hostname, software version, administrative owner, integration owner, business owner, business criticality, regulated-data exposure, customer dependency, cloud dependency, connected-product inventory, and remediation status where available.

·        This telemetry is required to determine which systems depend on FortiSandbox output and whether suspected appliance compromise could create broader defensive-control or enterprise-management risk.

·        Current configuration must not replace historical state because interfaces, trusted hosts, administrators, integrations, profiles, virtual machines, logging settings, certificates, credentials, or connected systems may have changed after suspicious activity.

Interface, Request, Proxy, and Application Telemetry

·        Interface telemetry must capture requests to FortiSandbox management, API, service, upload, reporting, analysis, diagnostic, administrative, and service-to-service functions.

·        Required fields include source IP, source port, destination IP, destination port, hostname, interface, endpoint, URI path, method, parameter name, normalized parameter value where policy permits, content type, content length, response code, response size, response time, user agent, authenticated identity, session identifier, API client, reverse-proxy identifier, load-balancer identifier, firewall action, web-application-firewall action, request timestamp, and request identifier where available.

·        Request inspection should preserve evidence of shell metacharacters, command delimiters, substitutions, redirection operators, encoding, malformed structures, repeated parameter variation, functionally inconsistent values, unusual methods, unexpected content types, anomalous request sizes, and timing behavior without treating those conditions as proof of execution.

·        Reverse-proxy, web-application-firewall, load-balancer, firewall, VPN, and API-gateway records must preserve source continuity and indicate whether request values were normalized, decoded, rewritten, blocked, forwarded, or truncated.

·        This telemetry is required to connect suspicious interface activity to later CLI, kernel, service, configuration, file, process, network, job, VM, report, or connected-system behavior.

·        Request strings or response codes alone must not be used to prove command execution.

FortiSandbox Native Event, CLI, Kernel, and System Telemetry

·        FortiSandbox native telemetry must capture Input, System, Job, VM, Threat, Database, Report, Performance, Resource, HA, Notification, SNMP, administrator, authentication, configuration, update, integration, logging, CLI-history, and kernel activity where supported.

·        Required fields include deployment, appliance, node, tenant, region, event category, event type, severity, administrator, IAM user, session, source IP, action, object, status, result, message identifier, job identifier, VM identifier, sample identifier, URL identifier, threat identifier, report identifier, database object, service, process where available, command where available, destination, timestamp, and event-forwarding status.

·        CLI telemetry should capture command execution, command source, administrator context, remote-session context, privilege context, and timestamp where available.

·        Kernel and low-level system telemetry should capture unexpected faults, service interaction, module or process anomalies, networking behavior, file activity, resource changes, and logging-state changes where available.

·        This telemetry is required to determine whether suspicious requests were followed by execution-consistent appliance behavior.

·        Native event, CLI, or kernel evidence must be interpreted against normal analysis, update, maintenance, support, cluster, HA, job, VM, content-processing, and recovery behavior.

Process, File, Service, and Persistence Telemetry

·        Process telemetry should capture process creation, parent-child relationships, command line, executable path, user or service context, working directory, integrity or privilege context, start time, stop time, file interaction, network connection, and exit status where supported.

·        File telemetry should capture creation, access, modification, rename, permission change, archive, staging, transfer, deletion, and execution involving configuration files, service files, startup files, scripts, temporary directories, reports, database files, credentials, certificates, keys, and exported artifacts.

·        Service telemetry should capture service creation, modification, restart, disablement, startup changes, scheduled execution, cron or equivalent scheduling, daemon changes, helper changes, update-service changes, and persistent service behavior where supported.

·        Required visibility includes command interpreters, native utilities, download tools, transfer tools, archive tools, network tools, configuration utilities, database utilities, service-control functions, startup mechanisms, and administrative helpers.

·        This telemetry is required to connect probable command execution to appliance or service compromise, persistence, staging, credential access, or outbound activity.

·        Absence of process or file telemetry must not be used to rule out execution where the deployment does not expose those sources.

Administrator, Authentication, FortiCloud IAM, and Credential Telemetry

·        Administrator telemetry must capture successful and failed authentication, local and remote administrator activity, account creation, account deletion, role changes, privilege changes, trusted-host changes, authentication-source changes, session creation, session termination, password changes, MFA changes where supported, and administrative API use.

·        FortiCloud IAM telemetry must capture user creation, deletion, role assignment, mapped access-profile changes, secondary-account activity, tenant access, region access, service access, API activity, session activity, and security-setting changes.

·        Credential telemetry should capture access to API keys, tokens, certificates, SSH keys, service-account credentials, mail credentials, storage credentials, cloud credentials, update credentials, integration secrets, trusted-host configuration, and authentication mappings where available.

·        Required fields include administrator or IAM identity, role, privilege, authentication source, source IP, device, session, API client, tenant, region, operation, object, result, timestamp, and approved workflow context.

·        This telemetry is required to determine whether probable execution progressed into identity compromise, persistent administration, credential theft, or trusted downstream access.

·        Administrator or IAM activity alone must not be attributed to compromise without request, execution, change, source, session, and workflow context.

Configuration, Update, Certificate, Database, and Service-State Telemetry

·        Configuration telemetry must capture changes to system settings, interfaces, routes, DNS, NTP, proxy, trusted hosts, logging, notifications, SNMP, mail, storage, analysis profiles, virtual machines, integrations, users, authentication, APIs, certificates, updates, and services.

·        Update telemetry must capture content updates, software updates, package changes, update source, update failures, update timing, signature or content version, and administrative approval.

·        Certificate and key telemetry must capture certificate addition, replacement, deletion, export, trust changes, SSH-key changes, API-certificate changes, and service-certificate changes.

·        Database telemetry must capture access, modification, deletion, record changes, schema changes, maintenance, report-related activity, finding-related activity, verdict-related activity, and unusual administrative queries where supported.

·        Required fields include configuration object, old value, new value, actor, source, session, process where available, change method, service, database object, certificate identifier, update source, result, timestamp, and approved change record.

·        This telemetry is required to distinguish ordinary maintenance from attacker-driven appliance or analysis-control modification.

·        Historical configuration, certificate, service, and database state must be preserved for comparison.

Analysis Job, Virtual Machine, Submission, and Threat-Finding Telemetry

·        Submission telemetry must capture submitted file or URL, submission source, submitting system, customer or tenant, submission method, analysis profile, timestamp, and sensitivity where available.

·        Job telemetry must capture job creation, queueing, assignment, execution, failure, retry, rescan, cancellation, completion, duration, worker, VM, profile, engine, result, and related administrative action.

·        VM telemetry must capture VM assignment, image, state, availability, start, stop, reset, failure, configuration change, network behavior, and relationship to the submission or job.

·        Threat telemetry must capture engine findings, threat identifiers, behavioral findings, classifications, severity, verdict, confidence, rule or signature source, content version, analyst override, and change history.

·        Required fields include submission identifier, file hash, URL identifier, job identifier, VM identifier, analysis profile, engine, content version, threat record, original verdict, final verdict, override actor, override reason, report identifier, timestamp, and downstream delivery status.

·        This telemetry is required to determine whether appliance compromise progressed into selective or broad analysis manipulation.

·        Job failure, VM failure, rescan differences, or verdict differences must not be treated as compromise without configuration, actor, timing, profile, content-version, and prior compromise context.

Report, Quarantine, Notification, and Result-Delivery Telemetry

·        Report telemetry must capture report creation, modification, deletion, export, access, reconstruction, retention, and delivery.

·        Quarantine telemetry must capture quarantine decision, release, override, deletion, destination, actor, reason, timestamp, and downstream action.

·        Notification telemetry must capture email, SNMP, syslog, SIEM, FortiAnalyzer, API, webhook, orchestration, and connected-product result delivery.

·        Required fields include report identifier, sample or URL identifier, threat identifier, verdict, actor, recipient, destination, delivery channel, delivery status, notification type, quarantine action, timestamp, and retention state.

·        This telemetry is required to determine whether analysis results were altered, suppressed, delayed, redirected, or distributed incorrectly.

·        Missing reports or notifications must be interpreted against retention, delivery failure, maintenance, configuration, and approved deletion context.

Network, DNS, Proxy, Firewall, Flow, and NDR Telemetry

·        Network telemetry must capture communication involving FortiSandbox management interfaces, service interfaces, analysis networks, cluster nodes, PaaS services, reverse proxies, load balancers, connected products, cloud resources, storage systems, update services, vendor services, and suspected source systems.

·        Outbound telemetry should identify rare destinations, newly observed domains, raw-IP communication, cloud storage, file transfer, tunneling, repeated callbacks, unusual transfer volume, downloads, DNS anomalies, and communication following suspicious requests or appliance changes.

·        Required fields include source appliance, source node, source interface, source IP, source process where available, destination domain, destination IP, port, protocol, direction, timestamp, action, bytes, duration, session count, first-seen status, reputation, ASN, geography, proxy chain, NAT context, tenant, region, and approved destination context.

·        Telemetry must distinguish appliance-management, service, update, integration, and administrative communication from expected malware-detonation traffic.

·        This telemetry is required to connect suspicious request activity, probable execution, tool transfer, credential use, staging, command and control, or downstream access into one timeline.

·        Network activity must not be used as standalone proof of command execution or appliance compromise.

Connected-System, Cloud, and Downstream Security Telemetry

·        Connected-system telemetry must capture authentication, API use, administrative actions, rule changes, policy changes, allowlist changes, exclusion changes, logging changes, alert suppression, credential creation, service-account activity, integration changes, report ingestion, indicator ingestion, quarantine actions, and automation triggered by FortiSandbox.

·        Cloud telemetry must capture IAM changes, role assignments, service-identity changes, security-group changes, firewall changes, network changes, storage access, logging changes, secret access, virtual-machine changes, API activity, and security findings in AWS, Azure, and Google Cloud environments supporting FortiSandbox.

·        Required fields include connected platform, tenant, account, subscription, organization, project, FortiSandbox source identity, API client, certificate, token, source IP, operation, resource, result, timestamp, and approved workflow context.

·        AWS correlation depends on reliable canonical session and source binding.

·        Azure correlation depends on reliable tenant, identity, source-qualified activity, resource, and finding enrichment.

·        Google Cloud correlation depends on reliable organization, project, identity, source-qualified activity, resource, and Security Command Center enrichment.

·        Downstream activity alone cannot prove FortiSandbox compromise and must be linked through identity, API client, certificate, token, source, integration, destination, resource, or bounded time window.

Change-Control, Incident Response, Remediation, and Business Context

·        Change-control telemetry must capture approved maintenance, patching, upgrades, support activity, content updates, analysis-profile changes, VM changes, database maintenance, report administration, integration changes, credential rotation, cloud changes, migration, backup, recovery, testing, and incident-response activity.

·        Incident-response records must capture affected deployment, appliance, node, tenant, region, interface, endpoint, request, source, administrator, IAM user, session, service, process, file, configuration object, job, VM, submission, finding, verdict, report, credential, integration, destination, connected system, containment action, action owner, timestamp, evidence source, validation status, and closure rationale.

·        Business context must identify platform owner, service owner, integration owner, cloud owner, data owner, regulated-data status, customer dependency, business criticality, outage tolerance, recovery priority, and downstream decision dependency.

·        This telemetry is required to determine whether suspicious behavior was attacker-driven, analyst-driven, administrator-driven, maintenance-related, support-related, update-related, analysis-related, testing-related, or incident-response-related.

·        Remediation must not be considered complete until appliance integrity, administrator integrity, credential state, analysis-profile integrity, VM integrity, job and finding integrity, report integrity, logging health, integration trust, connected-system state, and post-remediation behavior have been explicitly validated.

S32 — Detection Limitations

Detection of FortiSandbox command injection and security-control compromise is limited by whether the organization can reconstruct the relationship between suspicious interface activity, probable command execution, appliance or service changes, administrator and FortiCloud IAM activity, analysis-profile and VM changes, job and threat-record behavior, verdict or report manipulation, credential access, logging degradation, outbound communication, connected-system activity, cloud-control changes, and remediation evidence. Environments that rely only on vulnerable-version status, CVE references, request strings, command-like input, response codes, service faults, administrator activity, VM or job anomalies, verdict differences, missing reports, rare destinations, or cloud events will not have enough evidence for high-confidence compromise or impact determination.

Primary Limitations

·        Missing FortiSandbox inventory may prevent identification of affected appliances, nodes, clusters, PaaS instances, tenants, regions, interfaces, administrators, profiles, VMs, integrations, and connected systems.

·        Missing historical interface and exposure state may prevent validation of whether the affected function was externally reachable, internally trusted, reverse-proxied, VPN-accessible, API-enabled, or restricted at the time of suspicious activity.

·        Reverse proxies, load balancers, VPNs, firewalls, and web-application firewalls may alter, decode, normalize, truncate, or omit request values.

·        Missing request bodies, parameters, request identifiers, sessions, or source continuity may prevent request-to-execution correlation.

·        A command-like request may be recorded without proving that the vulnerable function processed or executed it.

·        Blind, delayed, fragmented, or asynchronous execution may produce no direct response or interactive shell.

·        Missing process, shell, command-line, file, syscall, or memory telemetry may prevent direct validation of command execution.

·        Physical, virtual, clustered, cloud-hosted, and PaaS deployments may expose different evidence and may not provide equivalent low-level visibility.

·        FortiSandbox native events may show system, job, VM, threat, database, report, performance, resource, HA, notification, or SNMP activity without proving attacker control.

·        Missing CLI history may prevent reconstruction of native command execution.

·        Disabled or unavailable kernel logging may prevent review of low-level appliance behavior.

·        Local logs may rotate before suspicious activity is identified.

·        Reports and job history may expire before analysis manipulation is suspected.

·        Shared NAT, proxying, cloud routing, cluster architecture, and PaaS service boundaries may obscure the exact source appliance, node, tenant, or execution context.

·        Malware-detonation traffic may resemble attacker-controlled callbacks, downloads, file transfer, tunneling, DNS activity, or command-and-control behavior.

·        Missing separation between management-plane, service-plane, analysis-plane, and detonation-plane traffic may prevent accurate attribution.

·        Missing administrator, IAM, session, and API-client attribution may prevent validation of whether changes were approved or attacker-driven.

·        Shared administrative accounts may prevent reliable actor attribution.

·        Missing historical configuration, service, certificate, update, database, profile, VM, notification, logging, and integration state may prevent change reconstruction.

·        Analysis-profile changes may be legitimate and may not prove malicious manipulation.

·        Job failure, VM failure, rescan differences, content-version differences, engine updates, environmental differences, or analyst overrides may explain verdict changes.

·        Missing threat-finding and verdict history may prevent determination of whether results were altered after analysis.

·        Missing report lineage may prevent validation of whether a report was generated, modified, deleted, exported, or delivered correctly.

·        Missing remote-forwarding and downstream-ingestion records may prevent confirmation that events or reports were suppressed.

·        Credential access may occur through configuration, files, databases, memory, exports, backups, administrative functions, or service settings that are not fully logged.

·        FortiCloud PaaS investigations may depend on vendor-managed or customer-limited evidence.

·        Missing connected-system logs may prevent determination of whether stolen credentials or trusted integrations were used downstream.

·        AWS canonical session and source binding may be incomplete or unreliable.

·        Azure identity, source-qualified activity, resource, and finding enrichment may be incomplete.

·        Google Cloud organization, project, identity, source-qualified activity, resource, and finding enrichment may be incomplete.

·        Short retention may prevent reconstruction when request activity, execution, manipulation, and downstream use are separated by hours, days, or weeks.

·        Poor timestamp normalization may break correlation among proxies, firewalls, FortiSandbox, cloud, SIEM, connected products, and incident-response records.

·        Incomplete normalization of asset, interface, request, endpoint, administrator, IAM user, session, job, VM, submission, finding, verdict, report, credential, integration, destination, and cloud-resource fields may prevent reliable joins.

·        Missing change-control, maintenance, support, update, testing, migration, recovery, analyst-override, and incident-response records may prevent reliable false-positive control.

Detection Boundary

·        A vulnerable or unpatched FortiSandbox deployment is not proof of compromise.

·        A CVE match, KEV status, public exploit, proof-of-concept release, scanner finding, source IP, user agent, hash, filename, request string, command string, or actor name is not proof of compromise by itself.

·        A malformed, encoded, or special-character-bearing request is not proof of command injection.

·        A successful HTTP response is not proof that command execution occurred.

·        A failed response, timeout, or service error is not proof that command execution failed.

·        An isolated CLI, kernel, System, Job, VM, Threat, Database, Report, Performance, Resource, HA, Notification, or SNMP event is not proof of attacker control.

·        Service restart, resource pressure, VM failure, job failure, queue delay, update error, database maintenance, or notification failure may be operationally benign.

·        A verdict difference is not proof of manipulation without profile, engine, content-version, rescan, sample, VM, analyst, and timeline context.

·        A missing report or notification is not proof of suppression until retention, delivery, forwarding, and configuration have been validated.

·        Rare outbound communication is not proof of appliance compromise because malware detonation may create similar traffic.

·        Administrator or FortiCloud IAM activity is not proof of compromise without source, session, request, change, and workflow linkage.

·        Credential or certificate access should not be attributed to compromise without actor, source, method, object, session, and timeline context.

·        Cloud or connected-system activity should not be attributed to FortiSandbox compromise without identity, API client, certificate, token, source, integration, resource, or bounded time-window linkage.

·        Persistent accounts, roles, policies, or integrations should not be attributed to FortiSandbox compromise without source, actor, operation, resource, and sequence correlation.

·        Legitimate maintenance, upgrades, content updates, vendor support, troubleshooting, malware analysis, rescans, VM administration, database maintenance, report administration, cloud operations, security testing, automation, and incident response can create overlapping signals.

·        Detection logic must not depend on another CyberDax alert, DRI score, TCR score, or post-alert analyst judgment as an input.

·        High-confidence conclusions should require validated multi-signal correlation across suspicious interface activity, execution-consistent appliance behavior, unauthorized state change, analysis manipulation, evidence degradation, credential use, downstream activity, and approved workflow evidence where applicable.

Operational Impact of Limitations

Detection coverage should be reduced, converted to hunt-only logic, or withheld when interface exposure, request telemetry, source continuity, native events, CLI or kernel evidence, configuration history, job and VM records, threat-finding history, report lineage, administrator attribution, FortiCloud IAM records, network separation, connected-system logging, cloud correlation, approved-workflow baselines, or bounded sequence correlation are unavailable or unreliable. Suspicious activity may remain analytically important but unsuitable for high-confidence command-execution, appliance-compromise, analysis-manipulation, credential-theft, security-control-degradation, or downstream-compromise determination when the organization cannot validate the complete request-to-defensive-control sequence.

S33 — Defensive Control & Hardening Improvements

Defensive improvement should focus on making FortiSandbox exposure, command execution, appliance state, analysis integrity, administrator activity, credential use, logging health, trusted integrations, downstream actions, and trust restoration measurable, governed, and recoverable. The objective is not only to patch FortiSandbox or block one crafted request, but to prove that privileged functions are restricted, suspicious requests can be investigated, unauthorized execution can be identified, analysis results remain trustworthy, credentials and integrations are protected, connected systems can be assessed, and the defensive environment can return safely to operation.

FortiSandbox Asset, Interface, and Integration Governance

·        Maintain complete inventory of FortiSandbox physical appliances, virtual appliances, cluster nodes, HA members, cloud-hosted systems, PaaS instances, tenants, regions, interfaces, APIs, upload functions, reporting functions, analysis services, administrators, FortiCloud IAM users, analysis profiles, VMs, submission sources, credentials, certificates, and connected systems.

·        Maintain authoritative interface exposure, trusted-host, reverse-proxy, firewall, VPN, API-gateway, service-to-service, and administrative-path mappings.

·        Maintain authoritative integration inventories for Fortinet products, SIEM, SOAR, endpoint, email, cloud, storage, identity, hypervisor, backup, orchestration, deployment, code, and management systems.

·        Classify deployments and integrations by business criticality, privilege, submission sensitivity, customer dependency, regulated-data exposure, and downstream decision impact.

·        Require ownership, periodic review, exception approval, remediation closure, and emergency-change documentation.

Interface Exposure and Access Hardening

·        Restrict management, API, service, upload, reporting, analysis, diagnostic, and administrative interfaces to approved networks, hosts, identities, clients, and workflows.

·        Remove unnecessary Internet exposure and require VPN, privileged-access, administrative-network, reverse-proxy, or trusted-host controls where feasible.

·        Use web-application-firewall, API-gateway, reverse-proxy, rate-limiting, request-size, method, content-type, and parameter validation controls where supported.

·        Preserve sufficient request telemetry to reconstruct source, endpoint, method, parameter, session, client, response, and timing.

·        Enforce separate management-plane, service-plane, analysis-plane, and malware-detonation-plane network paths where architecture permits.

·        Require periodic external and internal exposure validation.

Administrator, FortiCloud IAM, and Privileged-Access Hardening

·        Enforce least privilege for appliance administrators, remote-authentication users, FortiCloud IAM users, API identities, integration identities, service accounts, support accounts, and maintenance accounts.

·        Require MFA, privileged-access approval, dedicated administrative workstations, jump hosts, management VPNs, and session recording where supported.

·        Remove shared administrator accounts and require named identities.

·        Restrict trusted hosts, source networks, API clients, mapped access profiles, secondary accounts, tenant access, and region access.

·        Review administrator, IAM, role, session, and API activity regularly.

·        Require rapid suspension and rotation procedures for compromised or potentially exposed administrative identities.

Appliance, Service, Configuration, and Update Hardening

·        Maintain known-good baselines for system configuration, services, startup behavior, schedules, trusted hosts, certificates, routing, DNS, NTP, proxy, logging, notifications, SNMP, mail, storage, updates, databases, analysis profiles, VMs, and integrations.

·        Restrict command-line, diagnostic, service, database, update, configuration-export, certificate, and low-level system access.

·        Protect startup files, schedules, service definitions, configuration files, database files, update settings, and administrative scripts from unauthorized modification.

·        Validate update sources, signatures, content versions, software versions, update timing, and failure handling.

·        Require change approval and post-change validation for high-risk system, service, update, database, certificate, and integration operations.

·        Compare production state against approved baselines after suspicious activity.

Analysis Profile, Virtual Machine, Job, and Verdict Hardening

·        Maintain authoritative inventories and approved baselines for analysis profiles, VM images, VM assignments, engines, content versions, submission routes, scan flows, rescan behavior, job handling, threat findings, verdict logic, quarantine behavior, report generation, and result delivery.

·        Restrict profile, VM, engine, verdict, report, quarantine, notification, and result-distribution changes to approved administrators and workflows.

·        Require auditable approval and reason codes for analyst overrides, verdict changes, quarantine releases, report deletion, and profile modification.

·        Preserve original and revised findings, verdicts, reports, profiles, and change history.

·        Independently validate high-risk or disputed submissions through secondary analysis where feasible.

·        Periodically test that malicious and benign submissions receive expected analysis, verdict, reporting, quarantine, and notification outcomes.

Credential, Certificate, API, and Integration-Secret Hardening

·        Inventory administrator credentials, service accounts, API keys, tokens, certificates, SSH keys, mail credentials, storage credentials, cloud credentials, update credentials, and integration secrets accessible to each deployment.

·        Restrict credential export, display, backup, storage, configuration access, API access, database access, and administrative retrieval.

·        Use dedicated, least-privileged identities for every integration.

·        Avoid shared secrets across multiple products, tenants, regions, or environments.

·        Rotate credentials, certificates, tokens, keys, and integration secrets after suspected compromise.

·        Monitor use of FortiSandbox-associated identities from new sources, clients, regions, tenants, or platforms.

Logging, Report, Notification, and Evidence Hardening

·        Enable and validate FortiSandbox Input, System, Job, VM, Threat, Database, Report, Performance, Resource, HA, Notification, SNMP, administrator, authentication, configuration, API, CLI-history, kernel, and integration telemetry where supported.

·        Forward relevant logs and events to remote, protected, and independently administered storage.

·        Preserve report history, finding history, verdict history, job history, VM history, configuration history, and administrator activity for periods aligned to incident-detection and investigation requirements.

·        Protect logging, CLI history, kernel logging, notification, SNMP, report, syslog, FortiAnalyzer, and SIEM settings from unauthorized change.

·        Monitor for forwarding gaps, ingestion gaps, timestamp inconsistencies, event-volume changes, report deletion, retention changes, and notification failures.

·        Preserve evidence before patching, rebooting, restoring, replacing, or isolating affected systems where operationally safe.

Network Separation and Egress Hardening

·        Separate FortiSandbox management, service, update, integration, and malware-detonation traffic where feasible.

·        Restrict appliance and management-plane egress to approved destinations, protocols, services, and update sources.

·        Maintain destination baselines for vendor services, reputation services, update services, DNS, NTP, proxy, mail, storage, cloud, logging, and integration endpoints.

·        Monitor rare destinations, new domains, raw-IP communication, cloud storage, tunneling, file transfer, callbacks, downloads, and unusual transfer volume.

·        Preserve NAT, proxy, firewall, VPN, flow, and DNS context needed to distinguish appliance-originated activity from sample-originated activity.

·        Block direct management-plane communication to unnecessary Internet destinations.

Connected-System and Cloud Hardening

·        Reduce the privilege of FortiSandbox integrations with Fortinet products, SIEM, SOAR, endpoint, email, cloud, storage, identity, backup, deployment, and management systems.

·        Restrict integrations to the minimum required operations, resources, tenants, subscriptions, projects, policies, and data.

·        Require strong logging for FortiSandbox-originated authentication, API use, policy changes, rule changes, alert suppression, credential creation, integration changes, report ingestion, and automated action.

·        Monitor AWS, Azure, and Google Cloud control-plane activity supporting FortiSandbox.

·        Require independent validation before connected systems automatically trust high-impact verdicts, quarantine actions, allowlist decisions, exclusions, or policy changes.

·        Maintain emergency procedures to suspend integrations without losing essential visibility.

Incident Response and Defensive-Trust Restoration

·        Create response procedures for suspicious interface activity, probable command execution, unauthorized appliance state change, analysis manipulation, verdict or report integrity loss, credential exposure, logging degradation, unusual egress, FortiCloud IAM compromise, and downstream connected-system activity.

·        Require responders to validate deployment, appliance, node, tenant, region, interface, endpoint, request, source, administrator, IAM user, service, process, file, configuration, job, VM, finding, verdict, report, credential, integration, destination, cloud resource, and remediation status.

·        Prepare decision paths for evidence preservation, interface restriction, privileged-access suspension, appliance isolation, emergency patching, service shutdown, appliance replacement, credential rotation, certificate rotation, integration suspension, report reconstruction, independent reanalysis, connected-system investigation, cloud restriction, legal review, compliance escalation, cyber-insurance coordination, communications planning, customer or partner review, and executive reporting.

·        Treat suspected FortiSandbox compromise as a malware-analysis trust and enterprise defensive-control incident, not only as a vulnerability-management or appliance-maintenance event.

·        Require post-event validation that unauthorized execution, modified administrators, persistence, manipulated profiles, altered VMs, false verdicts, deleted reports, logging degradation, stolen credentials, connected-system changes, or downstream activity did not continue after remediation.

S34 — Defensive Control & Hardening Architecture

Figure 6

The defensive architecture should treat FortiSandbox appliances, virtual systems, clustered deployments, PaaS instances, management interfaces, service interfaces, APIs, analysis profiles, sandbox virtual machines, jobs, findings, verdicts, reports, credentials, integrations, cloud resources, and connected defensive systems as one governed malware-analysis and defensive-trust system rather than isolated security products. The architecture must connect inventory, exposure control, request visibility, privileged-access governance, appliance-state validation, analysis-integrity monitoring, logging protection, credential protection, network attribution, downstream monitoring, incident containment, independent reanalysis, and executive trust restoration into one request-to-enterprise-impact assurance model.

Architecture Layer One — FortiSandbox Asset and Dependency Governance

FortiSandbox asset and dependency governance establishes which appliances, virtual systems, cluster nodes, PaaS instances, tenants, regions, interfaces, APIs, profiles, VMs, submission sources, administrators, credentials, integrations, cloud resources, and connected systems exist; who owns them; and which business processes depend on them. This layer captures inventory, deployment type, ownership, business criticality, regulated-data exposure, customer dependency, interface exposure, integration privilege, and remediation status.

Architecture Layer Two — Interface Exposure and Request Control

Interface exposure and request control determine which sources, networks, clients, identities, proxies, VPNs, APIs, and service-to-service paths can reach privileged FortiSandbox functions. This layer captures endpoint, method, parameter, session, API client, source, reverse proxy, load balancer, firewall, WAF, VPN, normalization, response, and approved access policy.

Architecture Layer Three — Privileged Administration and FortiCloud IAM Governance

Privileged administration and FortiCloud IAM governance determine which local administrators, remote users, IAM identities, mapped profiles, secondary accounts, service accounts, support identities, and API clients can change appliance or service state. This layer captures identity, role, privilege, source, device, session, tenant, region, authentication method, administrative action, and approval context.

Architecture Layer Four — Appliance, Service, Configuration, and Update Integrity

Appliance, service, configuration, and update integrity determine whether system state, services, startup mechanisms, schedules, trusted hosts, certificates, routing, DNS, NTP, proxy, logging, notifications, SNMP, updates, databases, and integrations remain aligned with approved baselines. This layer captures historical state, current state, actor, source, process, service, change method, update source, and change record.

Architecture Layer Five — Command Execution and Host-Level Visibility

Command execution and host-level visibility determine whether suspicious requests were followed by shell activity, native utility execution, process creation, file modification, service changes, startup changes, downloads, staging, transfer, or process-linked networking. This layer captures CLI history, kernel events, process ancestry, command line, file activity, service activity, network connections, working directory, privilege context, and timestamps where supported.

Architecture Layer Six — Analysis Profile, VM, and Job Integrity

Analysis profile, VM, and job integrity determine whether submitted content was routed, detonated, rescanned, and processed through approved profiles, engines, VMs, workers, queues, and job workflows. This layer captures profile state, VM image, VM assignment, engine version, content version, submission source, job state, rescan behavior, failure, override, and administrative change.

Architecture Layer Seven — Threat Finding, Verdict, Report, and Quarantine Integrity

Threat finding, verdict, report, and quarantine integrity determine whether analysis results were created, changed, suppressed, deleted, delayed, redirected, or delivered as intended. This layer captures original and final findings, verdict history, confidence, analyst override, report history, quarantine action, notification delivery, downstream distribution, and retention state.

Architecture Layer Eight — Credential, Certificate, and Integration-Trust Protection

Credential, certificate, and integration-trust protection determine whether administrator credentials, API keys, tokens, certificates, SSH keys, service accounts, mail credentials, storage credentials, cloud identities, update credentials, or integration secrets were accessed or misused. This layer captures credential inventory, privilege, storage, access, export, rotation, source, client, session, downstream use, and trust relationship.

Architecture Layer Nine — Network Attribution and Egress Monitoring

Network attribution and egress monitoring determine whether communication originated from the management plane, service plane, update plane, integration plane, analysis plane, or malware-detonation environment. This layer captures source appliance, node, interface, process where available, NAT, proxy, flow, DNS, destination, protocol, bytes, duration, first-seen status, reputation, tenant, region, and approved destination.

Architecture Layer Ten — Connected-System and Cloud Monitoring

Connected-system and cloud monitoring determine whether FortiSandbox-associated identities, integrations, certificates, tokens, APIs, findings, reports, or automated actions were used to modify Fortinet products, SIEM, SOAR, endpoint, email, cloud, storage, identity, backup, deployment, code, or management systems. This layer captures authentication, API use, policy changes, rule changes, exclusions, allowlists, credential creation, cloud IAM changes, security-control changes, resource access, and findings.

Architecture Layer Eleven — SOC Correlation and False-Positive Control

SOC correlation joins deployment, interface, request, source, administrator, IAM user, session, service, process, file, configuration, job, VM, submission, finding, verdict, report, credential, integration, destination, cloud resource, connected-system action, change record, and approved workflow context. This layer distinguishes attacker-driven activity from vulnerability scanning, maintenance, upgrades, content updates, vendor support, troubleshooting, malware detonation, VM administration, report administration, cloud operations, security testing, automation, and incident response.

Architecture Layer Twelve — Incident Response and Executive Trust Workflow

Incident response and executive trust workflow connects technical evidence to containment and business decisions. This layer captures incident severity, affected deployments, submissions, findings, verdicts, reports, credentials, integrations, connected systems, cloud resources, containment actions, appliance replacement, reanalysis, report reconstruction, credential rotation, integration suspension, legal review, compliance review, customer or partner impact, communications planning, executive reporting, and confirmation that defensive trust can be restored.

Architecture Outcome

The architecture should enable the organization to answer seven questions during a FortiSandbox command-injection and security-control-compromise incident:

·        Which deployment, appliance, node, tenant, region, interface, endpoint, request, source, administrator, IAM user, service, process, file, configuration object, job, VM, submission, finding, verdict, report, credential, integration, destination, cloud resource, connected system, business owner, or remediation action was affected?

·        Did the activity align with approved maintenance, patching, upgrade, support, content update, malware analysis, rescan, VM administration, database maintenance, report administration, cloud operation, testing, automation, or incident response?

·        Did suspicious interface activity progress into probable unauthorized command execution?

·        Did probable execution progress into appliance or service compromise, persistence, credential access, logging degradation, or analysis-control manipulation?

·        Were threat findings, verdicts, reports, quarantine actions, notifications, integrations, or connected defensive systems altered or misused?

·        Can the organization preserve evidence, isolate or replace affected systems, rotate credentials, suspend integrations, independently reanalyze submissions, reconstruct reports, investigate connected systems, remove persistence, and restore trusted operation without false closure?

·        Can leadership make defensible decisions about malware-analysis integrity, defensive-control reliability, sensitive-submission exposure, customer or partner impact, regulatory obligations, operational disruption, and return-to-service approval?

S35 — Defensive Control Mapping Matrix

Preventive Controls

·        Maintain complete inventory of FortiSandbox appliances, virtual systems, cluster nodes, PaaS instances, tenants, regions, interfaces, APIs, administrators, IAM users, profiles, VMs, submissions, credentials, integrations, connected systems, owners, business criticality, and regulated-data dependencies.

·        Restrict management, API, service, upload, reporting, analysis, diagnostic, and administrative interfaces to approved networks, hosts, identities, clients, and workflows.

·        Remove unnecessary Internet exposure and require privileged-access, VPN, administrative-network, reverse-proxy, firewall, WAF, or trusted-host controls where feasible.

·        Enforce least privilege for appliance administrators, FortiCloud IAM users, API identities, service accounts, support accounts, integration identities, and connected-system permissions.

·        Require MFA, named identities, dedicated administrative workstations, jump hosts, management VPNs, session approval, and recording where supported.

·        Maintain known-good baselines for appliance configuration, services, startup behavior, schedules, certificates, updates, databases, profiles, VMs, logging, notifications, and integrations.

·        Restrict configuration export, diagnostic access, command-line access, database access, certificate access, credential access, update changes, and service changes.

·        Use dedicated, least-privileged credentials and identities for every integration.

·        Separate management, service, update, integration, analysis, and malware-detonation traffic where feasible.

·        Protect remote logging, CLI history, kernel logging, report history, verdict history, notification settings, and event forwarding from unauthorized change.

·        Maintain tested emergency interface restriction, appliance isolation, credential rotation, integration suspension, independent reanalysis, report reconstruction, and replacement procedures.

Detective Controls

·        Monitor suspicious interaction with validated management, API, service, upload, reporting, analysis, diagnostic, and administrative interfaces.

·        Monitor suspicious requests for encoded metacharacters, delimiters, substitutions, redirection, malformed structures, repeated variation, unexpected methods, unusual content types, and timing anomalies.

·        Correlate suspicious requests with CLI, kernel, process, file, service, configuration, system, and execution-consistent network activity.

·        Monitor administrator creation, deletion, role changes, authentication changes, trusted-host changes, FortiCloud IAM changes, mapped-profile changes, secondary-account activity, and administrative API use.

·        Monitor service, startup, schedule, configuration, update, certificate, database, logging, notification, and integration changes following probable execution.

·        Monitor analysis-profile changes, VM assignment changes, job disruption, rescan changes, threat-finding changes, verdict changes, report changes, quarantine changes, and notification changes.

·        Compare original and final findings, verdicts, reports, profiles, content versions, engine versions, VM assignments, and analyst overrides.

·        Monitor local log deletion, remote-forwarding interruption, CLI-history disablement, kernel-logging disablement, SNMP changes, retention changes, report deletion, notification suppression, and timestamp inconsistencies.

·        Monitor access to credentials, API keys, tokens, certificates, SSH keys, service accounts, mail credentials, storage credentials, cloud credentials, and integration secrets.

·        Monitor rare destinations, new domains, raw-IP communication, cloud storage, file transfer, tunneling, callbacks, downloads, and unusual transfer volume from the appliance or management plane.

·        Monitor FortiSandbox-associated accounts, APIs, certificates, tokens, and integrations for unexpected use in connected Fortinet, SIEM, SOAR, endpoint, email, cloud, storage, identity, backup, deployment, code, and management systems.

·        Require multi-signal correlation before high-confidence command-execution, appliance-compromise, analysis-manipulation, credential-theft, or downstream-compromise determination.

Responsive Controls

·        Preserve FortiSandbox, proxy, firewall, WAF, VPN, DNS, flow, cloud, administrator, IAM, CLI, kernel, process, file, service, configuration, job, VM, threat, database, report, notification, and connected-system evidence before remediation.

·        Restrict affected interfaces and suspend suspicious administrative or API access.

·        Isolate affected appliances, nodes, tenants, or integrations when compromise cannot be ruled out.

·        Patch, rebuild, or replace affected deployments according to validated incident scope.

·        Rotate exposed or potentially exposed administrator credentials, API keys, tokens, certificates, SSH keys, service accounts, mail credentials, storage credentials, cloud credentials, and integration secrets.

·        Suspend or restrict connected-product integrations until trust is restored.

·        Validate analysis profiles, VM images, VM assignments, engines, content versions, job workflows, findings, verdicts, reports, quarantine actions, notifications, and result delivery.

·        Independently reanalyze high-risk submissions processed during the suspected compromise period.

·        Reconstruct or compare reports and verdicts against endpoint, email, network, threat-intelligence, and secondary sandbox evidence.

·        Investigate Fortinet products, SIEM, SOAR, endpoint, email, cloud, storage, identity, backup, deployment, code, and management systems for downstream activity.

·        Perform legal, compliance, privacy, cyber-insurance, communications, customer, partner, executive, and board-level review when security-control failure, sensitive-submission exposure, malicious-content escape, connected-system compromise, or incomplete containment is suspected.

·        Confirm that appliance state, administrator state, credential state, analysis integrity, logging health, report integrity, integration trust, connected-system state, and post-remediation monitoring support closure.

Governance Controls

·        Maintain approved inventories for FortiSandbox deployments, interfaces, administrators, IAM users, profiles, VMs, submissions, credentials, integrations, cloud resources, connected systems, owners, and control owners.

·        Maintain approved workflows for maintenance, patching, upgrades, content updates, vendor support, troubleshooting, profile changes, VM changes, database maintenance, report administration, integration changes, credential rotation, cloud operations, testing, automation, and incident response.

·        Require change control for administrator changes, IAM changes, trusted-host changes, configuration changes, profile changes, VM changes, verdict overrides, report deletion, logging changes, notification changes, integration changes, and cloud-control changes.

·        Maintain escalation criteria for suspicious interface activity, probable execution, appliance-state change, analysis manipulation, verdict or report integrity loss, credential access, logging degradation, rare egress, FortiCloud IAM compromise, and downstream connected-system activity.

·        Track unresolved FortiSandbox exposure, telemetry, attribution, retention, analysis-integrity, credential, integration, cloud, connected-system, and recovery gaps in the enterprise risk register.

Control Mapping Summary

The strongest control posture combines prevention of unauthorized access to privileged FortiSandbox functions, detection of request-to-execution-to-analysis-manipulation sequences, and response workflows that restore appliance integrity, analysis confidence, report integrity, credential security, integration trust, connected-system assurance, and business continuity. Controls should be prioritized for FortiSandbox deployments supporting email or endpoint enforcement, broad Security Fabric relationships, sensitive submissions, customer-facing analysis, regulated workloads, cloud environments, SIEM or SOAR automation, privileged management, backup or storage systems, and business-critical incident-response decisions.

S36 — CyberDax Intelligence Maturity Assessment

Current Intelligence Maturity

Moderate to High

Maturity Rationale

FortiSandbox command injection and security-control compromise form a mature behavior-led intelligence model because the assessment is not dependent on one CVE, exploit name, vulnerable version, proof-of-concept repository, request string, command string, source IP, hash, file path, actor, or static indicator. Organization-specific maturity depends on whether interface activity, probable execution, appliance state, administrator and FortiCloud IAM activity, analysis profiles, VMs, jobs, findings, verdicts, reports, credentials, integrations, network behavior, cloud changes, and connected-system activity can be correlated across deployment, source, request, identity, session, service, process, file, configuration, job, VM, submission, finding, report, credential, destination, resource, and time.

Strengths

·        The governing behavior is durable across changing vulnerabilities, interfaces, deployment models, access paths, command syntax, exploit implementations, cloud environments, and campaign branding.

·        The core sequence is analytically clear: suspicious interface activity, probable command execution, appliance or service compromise, analysis-control manipulation, security-control degradation, and conditional downstream expansion.

·        Detection opportunities are strong where request, native event, CLI, kernel, process, file, service, configuration, job, VM, threat, report, administrator, IAM, network, cloud, and connected-system telemetry can be correlated.

·        S25 provides behavior-led coverage across NDR, SentinelOne, Splunk, Elastic, QRadar, SIGMA, YARA, AWS, Azure, and GCP according to platform-native implementation viability.

·        Defensive controls map directly to interface restriction, privileged-access governance, appliance baselining, analysis-integrity protection, logging preservation, credential protection, network attribution, integration restriction, and defensive-trust restoration.

·        Blocks 1 through 5 remain aligned to the EXP behavior model without reverting to a single-CVE, request-string-only, patch-only, verdict-only, administrator-only, or rare-destination assessment.

Maturity Gaps

·        FortiSandbox inventory may not reliably identify every appliance, node, cluster, PaaS instance, tenant, region, interface, administrator, profile, VM, integration, connected system, owner, or business dependency.

·        Historical interface exposure and trusted-path state may be unavailable.

·        Request bodies, parameters, request identifiers, sessions, source continuity, and proxy normalization may be incomplete.

·        Direct visibility into successful command execution may be limited.

·        Process, shell, command-line, file, syscall, memory, CLI, or kernel telemetry may be unavailable.

·        Native FortiSandbox events may lack sufficient process, actor, request, or source attribution.

·        Local logs may rotate before investigation.

·        Report, job, VM, and threat-finding history may be retained for insufficient periods.

·        Malware-detonation traffic may be difficult to separate from appliance-originated adversary activity.

·        Shared NAT, proxying, cloud routing, clusters, PaaS boundaries, and vendor-managed infrastructure may weaken attribution.

·        Administrator, FortiCloud IAM, API-client, session, and trusted-host attribution may be incomplete.

·        Shared administrator accounts may prevent reliable actor attribution.

·        Historical configuration, service, update, certificate, database, profile, VM, logging, notification, and integration state may be incomplete.

·        Verdict differences may be difficult to interpret when engine versions, content versions, profiles, VMs, rescans, samples, and analyst overrides are not preserved.

·        Report lineage and downstream-delivery evidence may be incomplete.

·        Credential access may occur through sources that are not logged.

·        PaaS investigations may depend on customer-limited or vendor-provided evidence.

·        Connected products may not retain the originating FortiSandbox identity or request context.

·        AWS canonical session and source binding may be unreliable.

·        Azure identity, source-qualified activity, resource, and finding enrichment may be incomplete.

·        Google Cloud organization, project, identity, source-qualified activity, resource, and finding enrichment may be incomplete.

·        Change-control and approved-workflow baselines may be insufficient to distinguish malicious activity from maintenance, support, updates, analysis, cloud operations, or incident response.

·        Organizations may over-rely on vulnerable versions, request strings, command strings, response codes, job faults, VM faults, administrator changes, verdict differences, missing reports, or rare destinations.

Maturity Improvement Priorities

·        Maintain authoritative FortiSandbox deployment, appliance, node, cluster, PaaS, tenant, region, interface, administrator, IAM, profile, VM, integration, cloud, connected-system, and business-owner inventories.

·        Preserve historical interface exposure, trusted-host, proxy, firewall, VPN, API, and service-to-service mappings.

·        Improve source, endpoint, method, parameter, session, API-client, proxy, response, request-identifier, and timestamp retention.

·        Improve CLI, kernel, process, file, service, configuration, and execution-consistent network visibility where supported.

·        Ingest and normalize Input, System, Job, VM, Threat, Database, Report, Performance, Resource, HA, Notification, SNMP, administrator, authentication, configuration, update, integration, and logging telemetry.

·        Improve administrator, FortiCloud IAM, API-client, session, source, device, role, tenant, and region attribution.

·        Preserve historical configuration, service, update, certificate, database, profile, VM, job, finding, verdict, report, logging, notification, and integration state.

·        Improve submission, job, VM, engine, content-version, finding, verdict, override, report, and delivery correlation.

·        Improve separation and attribution among management-plane, service-plane, update-plane, integration-plane, analysis-plane, and malware-detonation traffic.

·        Improve NAT, proxy, firewall, DNS, flow, NDR, VPN, source-process, tenant, and region correlation.

·        Improve credential, certificate, token, API-key, SSH-key, service-account, cloud-identity, and integration-secret access monitoring.

·        Improve FortiSandbox-originated identity and API attribution across Fortinet products, SIEM, SOAR, endpoint, email, cloud, storage, identity, backup, deployment, code, and management systems.

·        Improve AWS canonical session and source binding.

·        Improve Azure tenant, identity, source-qualified activity, resource, finding, and approved-workflow mappings.

·        Improve Google Cloud organization, project, identity, source-qualified activity, resource, Security Command Center, and approved-workflow mappings.

·        Build approved-workflow baselines for maintenance, patching, upgrades, content updates, vendor support, troubleshooting, malware analysis, profile changes, VM administration, database maintenance, report administration, cloud operations, automation, security testing, and incident response.

·        Test detection and response logic against realistic benign and suspicious sequences before alert promotion.

Maturity Outlook

Maturity can improve quickly when the organization prioritizes interface inventory, request retention, command-execution visibility, appliance-state baselining, analysis-integrity history, administrator attribution, network-plane separation, credential monitoring, connected-system correlation, PaaS evidence access, and defensive-trust-restoration capability. The highest-value improvements are those that prove whether suspicious requests resulted in unauthorized execution, whether execution progressed into analysis or security-control manipulation, and whether the organization can restore trusted malware-analysis and defensive operation without relying on patching or appliance replacement alone.

S37 — Strategic Defensive Improvements

Strategic improvement should focus on reducing the probability that access to a FortiSandbox interface can become privileged command execution and reducing the amount of enterprise defensive trust exposed if appliance or analysis control is lost. The organization should treat FortiSandbox compromise as a cross-functional resilience problem spanning security architecture, network security, malware analysis, security operations, incident response, identity, cloud security, endpoint security, email security, storage, vulnerability management, platform engineering, business continuity, legal, compliance, cyber insurance, communications, customer management, and executive governance.

Priority One — Establish FortiSandbox Trust-Tier Governance

·        Classify FortiSandbox deployments and integrations by business criticality, submission sensitivity, regulated-data exposure, customer dependency, enforcement role, integration privilege, cloud dependency, and recovery complexity.

·        Apply stronger interface, privileged-access, logging, retention, credential, integration, and recovery requirements to high-trust deployments.

·        Treat deployments supporting email or endpoint enforcement, customer-facing analysis, SIEM or SOAR automation, Security Fabric relationships, cloud control planes, regulated workloads, backup systems, management platforms, and critical incident response as elevated trust tiers.

·        Require explicit ownership and trust-restoration criteria for every elevated-trust deployment and integration.

Priority Two — Reduce Interface and Privileged-Function Exposure

·        Remove unnecessary Internet exposure, open management paths, broad trusted-host rules, unrestricted APIs, diagnostic access, and service-to-service permissions.

·        Restrict privileged interfaces through approved networks, VPNs, reverse proxies, WAFs, firewalls, administrative workstations, jump hosts, API clients, and trusted identities.

·        Require periodic attack-surface validation and exposure review.

·        Preserve request evidence sufficient to support source, endpoint, parameter, session, and execution correlation.

Priority Three — Reduce Administrator and Integration-Identity Risk

·        Remove shared administrators and broad IAM roles.

·        Use named identities, MFA, time-bounded access, privileged-access approval, dedicated administrative workstations, management VPNs, and session recording where supported.

·        Use dedicated, least-privileged accounts, API identities, certificates, and secrets for every integration.

·        Maintain rapid administrator, IAM, API, token, certificate, SSH-key, service-account, and integration-secret suspension and rotation capability.

Priority Four — Make Analysis Integrity Measurable

·        Maintain authoritative baselines and history for profiles, VMs, engines, content versions, submission routes, jobs, findings, verdicts, reports, quarantine actions, notifications, and result delivery.

·        Preserve original and modified findings, verdicts, reports, overrides, and administrative changes.

·        Require approval and reason codes for high-impact analysis or verdict changes.

·        Periodically validate FortiSandbox output through independent reanalysis and controlled test submissions.

Priority Five — Build Sequence-Based Detection and Response

·        Detect the durable sequence rather than isolated artifacts: suspicious interface activity, execution-consistent appliance behavior, unauthorized state change, analysis manipulation, evidence degradation, credential use, and downstream connected-system activity.

·        Preserve deployment, request, source, administrator, session, service, process, file, configuration, job, VM, submission, finding, verdict, report, credential, integration, destination, resource, and time context.

·        Route detections according to trust tier and business criticality without weakening evidence requirements.

·        Require investigation playbooks to distinguish exposure, attempted exploitation, probable execution, appliance compromise, analysis-control compromise, security-control compromise, and downstream compromise.

Priority Six — Separate Management, Analysis, and Detonation Activity

·        Architect separate management-plane, service-plane, update-plane, integration-plane, analysis-plane, and malware-detonation communication where feasible.

·        Maintain distinct routing, NAT, proxy, firewall, DNS, and logging context for each plane.

·        Restrict management and service egress to approved destinations.

·        Ensure investigators can attribute suspicious outbound activity to the appliance, service, job, VM, sample, or integration responsible.

Priority Seven — Make Appliance Replacement and Trust Restoration Routine

·        Predefine when an appliance, node, PaaS instance, tenant, or integration must be isolated, rebuilt, replaced, or suspended because compromise cannot be ruled out.

·        Maintain tested procedures for evidence preservation, patching, replacement, configuration validation, profile and VM validation, credential rotation, certificate rotation, integration suspension, independent reanalysis, report reconstruction, connected-system investigation, and return to service.

·        Do not treat patching, service restart, administrator-password reset, or appliance replacement as sufficient trust restoration.

·        Require explicit validation of appliance state, administrator state, credential state, analysis integrity, report integrity, logging health, integration trust, connected-system state, and post-remediation behavior.

Priority Eight — Reduce Downstream Defensive-Trust Concentration

·        Limit the number of privileged, high-impact, regulated, customer-facing, and business-critical systems reachable through one FortiSandbox integration.

·        Reduce the ability of one verdict, report, API identity, certificate, token, or integration to trigger broad automated change without independent validation.

·        Separate customer, tenant, region, and environment integrations where feasible.

·        Require downstream trust review whenever FortiSandbox compromise cannot be ruled out.

Priority Nine — Improve PaaS and Cloud Evidence Readiness

·        Define customer-accessible and vendor-provided evidence requirements for FortiSandbox PaaS.

·        Preserve FortiCloud IAM, API, tenant, region, job, integration, service-status, administrative, support, cloud-control, network, and storage evidence.

·        Define escalation and evidence-preservation procedures with Fortinet and cloud providers.

·        Track visibility gaps that could prevent command-execution, analysis-integrity, credential, or downstream-impact determination.

Priority Ten — Integrate Executive and Business Decisioning

·        Define escalation thresholds for suspected FortiSandbox compromise affecting email or endpoint enforcement, regulated submissions, customer-facing analysis, Security Fabric integrations, SIEM or SOAR automation, cloud control planes, backup systems, management systems, sensitive intellectual property, or critical incident response.

·        Maintain decision paths for interface shutdown, appliance isolation, integration suspension, independent reanalysis, credential rotation, customer impact, partner impact, legal review, compliance review, privacy review, cyber-insurance coordination, communications planning, and board reporting.

·        Track unresolved exposure, telemetry, attribution, retention, analysis-integrity, credential, integration, cloud, connected-system, and recovery gaps in the enterprise risk register.

·        Require leadership assurance that malware-analysis and defensive trust have been restored before normal reliance on affected FortiSandbox outputs or integrations resumes.

Strategic Outcome

The target state is an environment in which unauthorized access to FortiSandbox privileged functions is less likely, command execution is more observable, analysis manipulation is harder to perform and easier to reconstruct, credentials and integrations expose less downstream privilege, management and detonation traffic can be attributed accurately, affected submissions and reports can be independently validated, compromised systems can be isolated or replaced rapidly, and leadership can make defensible decisions about defensive-control integrity, sensitive-submission exposure, connected-system impact, operational disruption, customer or partner consequences, and return to trusted operation.

S38 — Attack Economics & Organizational Impact Model

Figure 7

FortiSandbox command injection and security-control compromise change intrusion economics by allowing an adversary who reaches one trusted malware-analysis platform to convert unauthorized interface access into privileged command execution, appliance control, analysis manipulation, credential or integration-secret access, evidence degradation, and possible influence over multiple connected defensive systems. A compromised FortiSandbox deployment may allow the adversary to alter how files and URLs are submitted, detonated, classified, reported, quarantined, distributed, or acted upon without separately compromising every endpoint, email platform, network control, cloud environment, SIEM, SOAR, storage system, or management platform that depends on FortiSandbox output.

When suspicious interface activity, probable command execution, unauthorized appliance-state changes, administrator or FortiCloud IAM activity, analysis-profile modification, VM or job anomalies, threat-finding or verdict changes, report manipulation, logging degradation, credential access, unusual outbound communication, or connected-system activity align within one investigation window, the adversary can create disproportionate enterprise uncertainty. The organization’s cost expands when responders must determine whether activity remained limited to scanning or attempted exploitation, whether unauthorized execution occurred, which appliance or service functions were affected, whether analysis results remained trustworthy, which credentials or integrations were exposed, which submissions require reanalysis, which downstream systems acted on manipulated output, and whether malware-analysis and defensive trust can be restored safely.

Adversary Economic Advantage

·        A single FortiSandbox compromise may provide influence over multiple security workflows because connected products may trust its findings, verdicts, reports, indicators, quarantine actions, notifications, APIs, or integration identities.

·        The adversary may not need to compromise each endpoint, email gateway, network control, cloud workload, SIEM, SOAR platform, or management system individually when those systems rely on FortiSandbox-derived decisions.

·        Command injection may provide privileged execution through an application, worker, helper, daemon, queue, analysis service, or administrative function without requiring a conventional interactive login.

·        Blind, delayed, fragmented, short-lived, or asynchronous execution may reduce the attacker’s need to maintain an obvious shell or long-running process.

·        Selective manipulation may affect one file, URL, job, VM, profile, threat finding, verdict, report, notification, customer, tenant, or integration while the broader platform appears operational.

·        False-safe findings may allow malicious content to bypass downstream controls, receive trusted distribution, avoid quarantine, or remain deprioritized during investigation.

·        False-malicious findings may create operational disruption, consume analyst time, block legitimate content, and reduce confidence in automated security decisions.

·        Appliance administrators, FortiCloud IAM users, API identities, service accounts, certificates, tokens, SSH keys, mail credentials, storage credentials, cloud credentials, or integration secrets may provide reusable access beyond the originating FortiSandbox deployment.

·        Trusted FortiSandbox source addresses, certificates, APIs, protocols, service accounts, and integrations may reduce initial defender suspicion when activity reaches connected systems.

·        Malware-detonation traffic may conceal adversary callbacks, downloads, file transfer, DNS activity, cloud access, or command-and-control behavior within traffic the platform is expected to generate.

·        Shared NAT, reverse proxies, cloud routing, cluster architecture, multi-tenant services, and PaaS boundaries may reduce attribution and delay identification of the exact compromised appliance, node, tenant, region, service, or job.

·        Logging reduction, report deletion, forwarding interruption, CLI-history disablement, kernel-logging disablement, notification suppression, or timestamp manipulation may extend adversary dwell time by weakening reconstruction.

·        The adversary benefits when defenders cannot rapidly distinguish malicious appliance activity from approved maintenance, vendor support, updates, rescans, VM administration, report administration, automation, cloud operations, or incident response.

·        Persistent accounts, modified services, startup changes, scheduled execution, stolen credentials, altered integrations, cloud roles, API access, or downstream persistence may preserve access after patching, restart, password reset, isolation, or appliance replacement.

·        One manipulated malware-analysis decision can create disproportionate downstream exposure when it influences email delivery, endpoint enforcement, network blocking, cloud controls, automated response, incident prioritization, or customer-facing security services.

Defender Cost Expansion

·        The organization must investigate both the suspected interface exploitation and the reliability of the request, proxy, firewall, appliance, CLI, kernel, process, file, service, configuration, administrator, IAM, job, VM, finding, verdict, report, notification, network, cloud, connected-system, and remediation evidence needed to confirm or disprove impact.

·        Response teams may need to reconstruct interface exposure, suspicious requests, source continuity, administrator sessions, command-execution evidence, appliance-state changes, service changes, configuration history, credential access, analysis-profile changes, VM assignments, job processing, findings, verdicts, reports, quarantine actions, notifications, and result delivery.

·        Mitigation may require interface restriction, privileged-access suspension, appliance isolation, emergency patching, service shutdown, appliance rebuilding or replacement, administrator and credential rotation, certificate replacement, integration suspension, cloud restriction, independent reanalysis, report reconstruction, and extended monitoring.

·        Internal exposure scoping may be required across every FortiSandbox appliance, cluster node, PaaS instance, tenant, region, reverse proxy, firewall, load balancer, VPN, administrative system, FortiCloud account, cloud resource, analysis profile, VM, report store, submission source, and connected product associated with the affected deployment.

·        Response cost increases when request bodies, parameters, source continuity, native events, CLI history, kernel logs, process data, configuration history, job history, VM history, verdict history, report lineage, administrator attribution, or connected-system records are incomplete.

·        Business impact increases when defenders must determine whether malicious content was misclassified, legitimate content was disrupted, submissions were exposed, reports were altered, credentials were accessed, integrations were misused, or downstream controls acted on manipulated output.

·        Investigation scope expands when one FortiSandbox deployment supports broad Security Fabric relationships, email or endpoint enforcement, SIEM or SOAR automation, customer-facing analysis, regulated workloads, cloud control planes, backup systems, storage platforms, or privileged management functions.

·        Operational disruption increases when FortiSandbox must be isolated, integrations suspended, automated enforcement reduced, submissions queued for manual review, high-risk files and URLs reprocessed, or prior verdicts treated as untrusted.

·        Independent malware analysis may be required for submissions processed during the suspected compromise period when original findings, verdicts, reports, profiles, VM assignments, or engine state cannot be trusted.

·        Connected-system review may require validation of policies, allowlists, exclusions, quarantine actions, alerts, automation, credentials, accounts, roles, logging settings, cloud resources, and administrative changes across multiple platforms.

·        FortiSandbox PaaS investigations may require vendor coordination to obtain IAM, API, service-status, job, administrative, support, cloud-control, network, storage, or service-level evidence unavailable directly to the customer.

·        Legal, compliance, privacy, customer, partner, cyber-insurance, communications, executive, and board-level costs increase when sensitive-submission exposure, malicious-content escape, defensive-control failure, connected-system compromise, or incomplete containment cannot be ruled out.

·        Trust-restoration cost may continue after patching or appliance replacement because manipulated verdicts, distributed reports, created credentials, modified integrations, active sessions, downstream changes, and previously released malicious content must still be identified and remediated.

Organizational Impact Model

FortiSandbox Infrastructure and Interface Impact

The organization must determine which physical appliances, virtual appliances, cluster nodes, HA members, cloud-hosted deployments, PaaS instances, tenants, regions, management interfaces, service interfaces, APIs, upload functions, reporting functions, analysis services, reverse proxies, load balancers, firewalls, VPNs, trusted hosts, and administrative paths were exposed, accessed, modified, dependent on affected services, or included in remediation.

Command-Execution and Appliance-Control Impact

The organization must determine whether suspicious activity remained limited to scanning, malformed requests, blocked attempts, failed exploitation, service faults, or approved administration, or progressed into probable command execution, unauthorized service activity, configuration modification, administrator changes, persistence, file activity, database access, logging changes, or sustained appliance control.

Analysis Profile, Virtual Machine, and Job Impact

The organization must determine whether analysis profiles, VM images, VM assignments, detonation settings, submission routes, scan flows, rescans, queues, workers, engines, content versions, job states, failures, retries, cancellations, or completion paths were changed, disrupted, bypassed, or rendered unreliable.

Threat-Finding, Verdict, and Report Impact

The organization must determine whether threat findings, classifications, confidence, verdicts, analyst overrides, reports, quarantine actions, notifications, indicators, or result-delivery workflows were suppressed, reclassified, altered, deleted, delayed, redirected, or distributed incorrectly.

Submission and Sensitive-Content Impact

The organization must determine which files, URLs, email attachments, documents, archives, scripts, executables, cloud objects, customer samples, regulated information, credentials, intellectual property, internal tools, or incident evidence were submitted, accessed, exported, altered, reprocessed, exposed, or associated with untrusted analysis results.

Administrator, FortiCloud IAM, and Credential Impact

The organization must determine whether appliance administrators, remote users, FortiCloud IAM users, mapped access profiles, secondary accounts, API identities, service accounts, support accounts, passwords, certificates, tokens, SSH keys, mail credentials, storage credentials, cloud credentials, update credentials, or integration secrets were created, modified, accessed, exported, stolen, rotated, or misused.

Logging and Evidence-Reliability Impact

The organization must determine whether local logs, remote syslog, FortiAnalyzer forwarding, SIEM ingestion, CLI history, kernel logging, administrator auditing, report retention, job history, VM history, threat history, notifications, SNMP delivery, timestamps, or other evidence sources were stopped, altered, deleted, degraded, restored, or rendered unreliable during the event window.

Connected Security-System Impact

The organization must determine whether FortiGate, FortiManager, FortiAnalyzer, FortiMail, FortiWeb, SIEM, SOAR, endpoint, email, cloud-security, storage, identity, hypervisor, backup, deployment, code, orchestration, or management systems accepted manipulated findings, trusted compromised identities, received altered reports, performed unsafe automated actions, or experienced unauthorized administrative changes.

Cloud and PaaS Impact

The organization must determine whether FortiCloud IAM, PaaS tenants, regions, APIs, service settings, AWS accounts, Azure subscriptions, Google Cloud projects, cloud networks, virtual machines, storage resources, service identities, IAM roles, logging services, security groups, firewall rules, secrets, or management planes were exposed, changed, degraded, destroyed, or used for persistence.

Malware-Analysis and Defensive-Decision Impact

The organization must determine whether email, endpoint, network, cloud, storage, incident-response, or security-management decisions were based on manipulated, incomplete, delayed, or untrustworthy FortiSandbox analysis and whether malicious content escaped enforcement or legitimate content was disrupted.

Customer, Partner, and External-Service Impact

The organization must determine whether customer submissions, partner systems, managed-service environments, externally hosted integrations, customer-facing analysis services, third-party security platforms, or contractual security functions relied on affected FortiSandbox outputs and whether coordination, notification analysis, evidence preservation, or corrective action is required outside the organization.

Operational Availability and Business-Continuity Impact

The organization must determine whether appliance isolation, service shutdown, integration suspension, credential rotation, cloud restriction, manual analysis, submission reprocessing, report reconstruction, connected-product validation, or incomplete trust assurance disrupted email protection, endpoint security, network defense, cloud operations, customer services, incident response, administrative workflows, or other business-critical functions.

Containment and Defensive-Trust-Restoration Impact

The organization must restore appliance integrity, administrator confidence, credential security, analysis-profile integrity, VM integrity, job and finding integrity, verdict and report reliability, logging health, integration trust, connected-system assurance, cloud-control integrity, and business continuity through evidence preservation, isolation, patching, rebuilding or replacement, credential and certificate rotation, integration suspension, independent reanalysis, report reconstruction, downstream investigation, persistence removal, legal assessment, compliance review, cyber-insurance coordination, executive reporting, and post-remediation monitoring.

Governance Impact

Leadership may need to treat confirmed or strongly suspected FortiSandbox compromise as an executive-level malware-analysis trust and enterprise defensive-control incident because one affected deployment may support email or endpoint enforcement, broad Security Fabric relationships, SIEM or SOAR automation, sensitive or regulated submissions, customer-facing analysis, cloud environments, backup systems, management platforms, security operations, incident response, and other business-critical defensive decisions.

Economic Impact Summary

FortiSandbox command injection and security-control compromise create economic advantage for adversaries because one compromised malware-analysis platform may provide privileged execution, access to reusable credentials or integrations, influence over multiple security decisions, and a trusted path into connected defensive systems without requiring separate compromise of every dependent platform. The organization’s financial exposure grows when it cannot quickly determine whether suspicious requests resulted in unauthorized execution, whether appliance or analysis state was altered, which submissions and verdicts remained trustworthy, which credentials or integrations were exposed, which connected systems acted on affected output, whether sensitive content was accessed, whether evidence remained reliable, and whether malware-analysis and enterprise defensive trust can be restored without continued operational uncertainty.

S39 — Economic Impact & Organizational Exposure

FortiSandbox command injection and security-control compromise expand organizational exposure by creating uncertainty over whether trusted malware-analysis infrastructure remained secure, whether suspicious requests produced unauthorized command execution, whether appliance or service functions were modified, whether analysis profiles or sandbox virtual machines were manipulated, whether findings, verdicts, reports, quarantine actions, or notifications remained trustworthy, and whether credentials, integrations, connected defensive systems, cloud resources, sensitive submissions, customer environments, regulated workloads, or business-critical security operations were affected.

The governing risk is not limited to CVE-2026-39808, CVE-2026-26083, CVE-2026-25836, CVE-2026-25089, one FortiSandbox interface, one crafted request, one command string, one appliance version, one deployment model, one administrator account, one analysis job, one altered verdict, one outbound destination, one exploit implementation, or one adversary. The material question is whether exposed, vulnerable, or trusted FortiSandbox functionality was converted into unauthorized command execution, appliance or service compromise, analysis-control manipulation, credential or integration-secret access, logging degradation, persistent access, suspicious outbound communication, trusted-integration abuse, or downstream enterprise compromise before containment.

Economic exposure rises when affected FortiSandbox infrastructure supports email or endpoint enforcement, network-security decisions, cloud workloads, SIEM or SOAR automation, broad Security Fabric relationships, customer-facing analysis, regulated submissions, sensitive intellectual property, malware investigations, backup or storage systems, privileged management, or business-critical incident-response decisions. Exposure is highest when defenders cannot distinguish scanning from exploitation, command-like requests from successful execution, ordinary malware-detonation behavior from attacker-controlled communication, approved administration from unauthorized appliance changes, legitimate analysis variation from malicious verdict manipulation, or expected integration activity from downstream misuse.

Estimated Economic Exposure

Estimated exposure should be treated as scenario-based rather than fixed. The most defensible enterprise estimate depends on whether activity remains limited to vulnerable state, exposed interfaces, scanning, malformed requests, blocked attempts, service faults, failed exploitation, or approved administration; progresses into suspicious request handling, probable command execution, limited appliance-state change, analysis anomalies, credential access, logging degradation, or constrained connected-system activity; or results in persistent appliance control, broad analysis manipulation, false-safe verdict distribution, credential or integration-secret theft, sensitive-submission exposure, security-control degradation, downstream compromise, ransomware enablement, destructive activity, or widespread defensive failure.

Economic exposure increases when the organization cannot quickly determine whether suspicious requests reached the affected FortiSandbox function, whether command injection or another unauthorized-access path produced execution, whether application or service contexts performed unexpected actions, whether profiles, VMs, jobs, findings, verdicts, databases, reports, or notifications were modified, whether credentials or integrations remained trustworthy, whether outbound activity originated from the appliance or a detonated sample, and whether FortiSandbox, proxy, firewall, native-event, CLI, kernel, endpoint, network, cloud, connected-system, change-control, incident-response, and remediation evidence can be joined into a reliable sequence.

Low Impact Scenario

Estimated $500K - $3M

This scenario applies when rapid investigation confirms vulnerable, exposed, misconfigured, or targeted FortiSandbox infrastructure, suspicious scanning, malformed requests, command-like input, application faults, blocked attempts, failed exploitation, or limited approved administrative activity without evidence of successful unauthorized command execution, appliance-state modification, analysis-control manipulation, credential access, logging degradation, persistence, suspicious appliance-originated outbound communication, or downstream integration abuse.

Available evidence supports a failed, contained, approved, or non-impacting event. Response remains limited to emergency patch validation, exposed-interface scoping, request and native-event preservation, focused appliance and network hunting, administrator review, configuration validation, credential review, destination analysis, short-term enhanced monitoring, and executive assurance that malware-analysis and security-control integrity were not materially affected.

Moderate Impact Scenario

Estimated $5M - $35M

This scenario applies when confirmed or strongly suspected unauthorized command execution affects one or more FortiSandbox appliances, virtual systems, cluster nodes, cloud-hosted deployments, PaaS instances, application services, administrative paths, or trusted integrations and produces limited appliance-state modification, analysis-profile or VM changes, job disruption, report modification, finding or verdict inconsistency, logging degradation, credential access, unusual egress, or constrained connected-system activity.

Evidence may include suspicious requests followed by unexpected CLI, kernel, process, service, file, configuration, administrator, database, job, VM, report, notification, or network behavior. The organization cannot immediately determine whether execution was transient or persistent, which submissions or analysis results were affected, whether credentials or certificates were exposed, whether false-safe or false-malicious outcomes were distributed, or whether connected systems remained trustworthy.

Response may require appliance or service containment, configuration comparison, administrator and FortiCloud IAM review, credential and certificate rotation, profile and VM validation, report and analysis reconstruction, independent reanalysis of high-risk submissions, integration validation, connected-system investigation, cloud and infrastructure review, logging restoration, legal and compliance assessment, cyber-insurance coordination, business-owner engagement, executive reporting, and extended post-remediation monitoring.

High Impact Scenario

Estimated $40M - $200M+

This scenario applies when confirmed or strongly suspected FortiSandbox compromise becomes an enterprise-impact event involving sustained appliance control, persistent access, broad analysis manipulation, false-safe verdicts, malicious-content escape, credential or integration-secret theft, sensitive-submission exposure, connected-system compromise, cloud-control changes, security-control degradation, ransomware enablement, destructive activity, customer or regulated-data exposure, or widespread defensive failure.

The organization may need to treat affected FortiSandbox systems, administrators, FortiCloud IAM identities, profiles, VMs, jobs, findings, verdicts, databases, reports, quarantine actions, notifications, credentials, integrations, cloud resources, connected security platforms, and security decisions as exposed or unreliable until evidence proves otherwise.

Response may require emergency interface restriction, broad appliance isolation or replacement, credential and certificate rotation, integration suspension, reanalysis of historical submissions, reconstruction of findings and reports, connected-product shutdown or restriction, cloud-role limitation, forensic investigation, persistence removal, customer or partner notification analysis, privacy and regulatory escalation, cyber-insurance engagement, communications planning, executive and board reporting, and formal restoration of malware-analysis and defensive trust.

Annualized Risk Exposure

Estimated annualized exposure of $6M - $45M+ for materially exposed enterprise environments where FortiSandbox supports high-volume malware analysis, email or endpoint enforcement, cloud workloads, sensitive submissions, regulated environments, customer-facing services, broad Security Fabric relationships, SIEM or SOAR automation, privileged management, or business-critical incident-response decisions.

Exposure may exceed $40M - $200M+ when FortiSandbox compromise results in manipulated malware findings, distribution of unsafe results, broad security-control degradation, persistent credential or integration abuse, connected-system or cloud compromise, sensitive-submission exposure, ransomware or destructive activity, customer or partner impact, prolonged defensive disruption, incomplete containment, legal escalation, regulatory reporting, cyber-insurance review, communications response, or board-level intervention.

Operational Dependency

Operational dependency is high where FortiSandbox provides malware analysis, file or URL classification, email-security support, endpoint-security support, network-security intelligence, cloud-workload analysis, incident-response evidence, threat findings, verdicts, quarantine recommendations, indicators, reports, or automated security actions.

One affected appliance, cluster node, PaaS instance, tenant, region, analysis profile, VM, job-processing path, report store, API identity, or integration can create broad investigation and recovery requirements when multiple business units, security products, cloud environments, customers, submissions, or automated workflows depend on the affected deployment.

Dependency increases when FortiSandbox cannot be isolated, patched, rebuilt, replaced, or disconnected from integrations without disrupting malware analysis, email or endpoint enforcement, incident response, security automation, customer services, regulated operations, or other business-critical defensive functions.

Control Trust

Control trust is reduced when the organization cannot prove that FortiSandbox appliances, cloud services, PaaS instances, administrators, APIs, services, analysis profiles, VM assignments, submission routes, jobs, findings, verdicts, databases, reports, quarantine actions, notifications, credentials, integrations, or connected-system actions remained reliable during the exposure window.

Trust is further reduced when suspicious activity cannot be reconciled with approved scanning, maintenance, patching, content updates, vendor support, troubleshooting, malware detonation, VM administration, report administration, cloud operations, automation, or incident response; when altered findings or reports cannot be attributed; or when administrator, identity, configuration, service, credential, or integration activity remains unexplained after containment.

Visibility Confidence

Visibility confidence is highest when reverse-proxy, WAF, load-balancer, firewall, VPN, FortiSandbox Input, System, Job, VM, Threat, Database, Report, Performance, Resource, HA, Notification, SNMP, administrator, authentication, configuration, API, CLI-history, kernel, DNS, proxy, flow, NDR, cloud, connected-system, change-control, incident-response, and remediation records can be correlated through stable appliance, node, tenant, region, request, session, administrator, identity, service, process, job, VM, submission, finding, verdict, report, integration, destination, resource, and timestamp mappings.

Visibility confidence is reduced when request bodies or parameters are not retained, source continuity is lost through proxies or NAT, native events lack request or actor attribution, low-level execution telemetry is unavailable, local logs rotate, report history expires, analysis and detonation traffic cannot be separated, PaaS evidence is customer-limited, connected systems do not preserve the originating identity, or retention is insufficient to connect initial interface activity with delayed execution or downstream use.

S25 depends on validated FortiSandbox asset identity, request and source continuity, native-event normalization, administrator and FortiCloud IAM attribution, analysis-job and VM history, finding and report lineage, destination baselines, connected-system mapping, approved workflow context, bounded-time correlation, and reliable normalization across interface, appliance, identity, network, cloud, and downstream telemetry. It does not depend on CVE strings, exploit names, fixed request paths, payload strings, commands, hashes, source IPs, user agents, response codes, native-event anomalies, verdict differences, or rare destinations as standalone detection inputs.

Change-Control Confidence

Change-control confidence is high when administrator changes, IAM changes, service modifications, configuration changes, updates, certificate operations, analysis-profile changes, VM changes, database maintenance, report administration, logging changes, notification changes, integration changes, credential rotation, cloud operations, testing, support activity, and incident-response actions are recorded with validated actors, sources, approvals, affected objects, timestamps, and post-change verification.

Confidence is reduced when shared administrators, undocumented integrations, emergency changes, vendor-support activity, untracked automation, incomplete maintenance records, missing profile history, absent report lineage, or weak cloud-change attribution prevent defenders from distinguishing authorized activity from attacker-driven modification.

Downstream Dependency

Downstream dependency is high when FortiSandbox has approved connections to FortiGate, FortiManager, FortiAnalyzer, FortiMail, FortiWeb, SIEM, SOAR, endpoint-security, email-security, cloud-security, storage, identity, hypervisor, backup, deployment, code, orchestration, or management systems.

The organization must distinguish suspicious FortiSandbox-originated activity from confirmed downstream compromise. Authentication events, API use, policy changes, rule changes, exclusions, allowlists, credential creation, cloud activity, storage access, alert suppression, logging degradation, or administrative behavior become materially relevant only when telemetry ties them to an affected FortiSandbox identity, API client, certificate, token, source, integration, session, resource, destination, or investigation window.

Customer and Regulatory Exposure

Customer, partner, workforce, and regulatory exposure increases when FortiSandbox compromise affects customer submissions, employee content, partner files, regulated information, credentials, intellectual property, internal tools, incident evidence, security reports, email attachments, cloud objects, or other content subject to notification, contractual, privacy, audit, litigation, or sector-specific obligations.

Exposure also increases when telemetry gaps prevent timely confirmation of whether submitted content was accessed, copied, altered, deleted, exported, misclassified, or distributed; whether malicious content escaped enforcement; whether legitimate content was disrupted; whether credentials or integrations were misused; whether connected systems were changed; or whether containment was complete.

Residual Economic Risk

Residual economic risk remains after patching, interface restriction, service restart, appliance isolation, system rebuilding or replacement, administrator-password reset, credential rotation, certificate replacement, integration suspension, profile validation, VM validation, report reconstruction, submission reanalysis, connected-system review, or incident-response cleanup when the pre-remediation activity window cannot be reconstructed.

Applying a FortiSandbox update or removing external exposure reduces future vulnerability risk but does not prove that unauthorized command execution, credential access, analysis manipulation, report alteration, evidence suppression, persistence, or downstream integration abuse did not occur before remediation. Replacing an appliance does not prove that stolen credentials, modified integrations, manipulated results, active sessions, or downstream persistence were removed.

Residual risk should remain elevated until historical request, appliance, CLI, kernel, process, file, configuration, administrator, IAM, job, VM, finding, verdict, database, report, notification, network, cloud, connected-system, change-control, incident-response, and remediation evidence has been assessed and the organization can demonstrate that malware-analysis and defensive trust have been restored.

Proof-of-Concept Behavioral Coverage Assessment

CVE-2026-39808 is directly covered where unauthenticated exploitation of the FortiSandbox API produces suspicious request-to-execution behavior, native appliance-state changes, service activity, configuration modification, file or process evidence where available, outbound communication, credential access, or downstream security-control activity.

CVE-2026-27316 requires adaptation because credential disclosure through the LDAP configuration interface may expose reusable authentication material without producing command execution. S25 supports investigation when disclosure is followed by credential use, administrator or IAM activity, configuration changes, connected-system access, unusual network behavior, or another aligned post-compromise sequence.

CVE-2026-26083 is directly covered where unauthenticated exploitation of missing authorization within the FortiSandbox, FortiSandbox Cloud, or FortiSandbox PaaS web interface produces unauthorized code or command execution through crafted HTTP requests. The S25 model applies when that activity produces suspicious request-to-execution behavior, native appliance-state changes, service or configuration modification, analysis-control activity, credential access, logging degradation, outbound communication, cloud-control activity, or downstream security-control behavior.

CVE-2026-25836 is directly covered where authenticated abuse of the FortiSandbox Cloud or FortiSandbox PaaS VM-image update function produces suspicious HTTP activity, unexpected CLI or service behavior, VM or update-state changes, configuration activity, credential access, logging degradation, cloud-control changes, or connected-system activity.

CVE-2026-25691 requires adaptation because arbitrary directory deletion through the VM-image deletion function may damage files or appliance state without following the report’s core command-execution pathway. S25 supports detection when deletion produces native events, configuration or VM changes, file or service disruption, analysis degradation, report loss, logging impact, destructive activity, or post-remediation anomalies.

CVE-2026-25089 is directly covered by the S25 behavioral model when exploitation through the FortiSandbox, FortiSandbox Cloud, or FortiSandbox PaaS web interface produces suspicious crafted-request activity followed by execution-consistent appliance events, CLI or kernel activity, service or configuration changes, analysis-control modification, logging degradation, credential access, unusual outbound communication, or downstream integration activity.

CVE-2025-53949 and CVE-2025-53679 are directly covered where authenticated exploitation of FortiSandbox GUI endpoints produces suspicious request activity, command execution, appliance-state change, administrator or service activity, configuration modification, report or analysis-control changes, credential access, logging degradation, outbound communication, or trusted-integration abuse.

CVE-2024-54018, CVE-2024-52961, CVE-2024-27778, and CVE-2023-47540 are directly covered where exploitation of FortiSandbox administrative, VM-download, GUI, request-processing, or CLI functionality produces observable command execution, system or service changes, configuration activity, analysis disruption, credential access, evidence degradation, outbound communication, persistence, or downstream access.

CVE-2026-39808 and CVE-2026-25089 are included in the CISA Known Exploited Vulnerabilities Catalog. Their KEV status establishes active-exploitation urgency and accelerated remediation priority but does not independently prove compromise in a particular environment.

Known exploitation, KEV inclusion, public proof-of-concept availability, vendor priority, scanner findings, and vulnerable-version state remain urgency, remediation, and exposure-management inputs. They are not proof that exploitation occurred in a particular environment.

Detection Engineering Coverage Interpretation

The S25 detection content provides direct behavioral coverage when activity produces one or more of these implemented outcomes:

·        Suspicious interaction with a FortiSandbox management, API, service, upload, reporting, analysis, diagnostic, or administrative interface followed by execution-consistent appliance behavior

·        Unexpected CLI, kernel, process, file, service, configuration, system, database, report, job, VM, or network behavior associated with the same FortiSandbox deployment

·        Unauthorized administrator, authentication, FortiCloud IAM, mapped-profile, secondary-account, API, certificate, token, trusted-host, logging, notification, update, or integration modification

·        Analysis-profile, VM-assignment, job-flow, rescan, finding, verdict, database, report, quarantine, notification, or result-delivery manipulation

·        Access to administrator credentials, API keys, tokens, certificates, SSH keys, service accounts, mail credentials, storage credentials, cloud credentials, or integration secrets

·        Local log deletion, report deletion, forwarding interruption, CLI-history disablement, kernel-logging disablement, notification suppression, SNMP change, retention change, or timestamp inconsistency

·        Rare, newly observed, suspicious, raw-IP, cloud-storage, file-transfer, tunneling, download, callback, or command-and-control-like communication attributable to the appliance or management plane

·        FortiSandbox-associated identities, certificates, tokens, APIs, or integrations performing unexpected activity in connected security, cloud, storage, email, endpoint, identity, backup, deployment, code, or management systems

·        Conditional AWS, Azure, or Google Cloud activity where identity, source, session, account, subscription, project, organization, resource, or incident-case lineage ties the activity to the affected FortiSandbox deployment

Detection coverage is behavior-led rather than vulnerability-led. The rules do not identify a specific CVE, exploit implementation, command string, actor, campaign, or tool by name. They identify observable request, execution, appliance-state, analysis-control, identity, evidence-degradation, network, cloud, and downstream behavior.

Named-CVE coverage is procedure-led. S25 can detect a documented exploitation procedure when that procedure produces behavior observable within the report’s detection model. It cannot identify the vulnerability from those behaviors alone.

Direct Coverage

Direct coverage applies where documented exploitation or post-compromise procedures produce behavior already implemented inside the S25 model.

Directly Covered CVEs

·        CVE-2026-39808 — Unauthenticated OS command injection through a FortiSandbox API endpoint

·        CVE-2026-26083 — Unauthenticated execution of unauthorized code or commands through missing authorization in the FortiSandbox web interface

·        CVE-2026-25836 — Authenticated OS command injection through the FortiSandbox Cloud or PaaS VM-image update function

·        CVE-2026-25089 — Second-order OS command injection through FortiSandbox web-interface JSON input

·        CVE-2025-53949 — Authenticated OS command injection through multiple FortiSandbox endpoints

·        CVE-2025-53679 — Authenticated OS command injection through FortiSandbox GUI backup options

·        CVE-2024-54018 — Authenticated OS command injection through FortiSandbox administrative interfaces

·        CVE-2024-52961 — Authenticated OS command injection through the FortiSandbox VM-download function

·        CVE-2024-27778 — Authenticated OS command injection through crafted FortiSandbox requests

·        CVE-2023-47540 — Privileged FortiSandbox CLI command injection

These CVEs are directly covered at the behavioral level when exploitation produces suspicious request activity, unauthorized command execution, native appliance-state changes, service or configuration activity, analysis-control manipulation, credential access, evidence degradation, outbound communication, persistence, or downstream trusted-system activity. Direct coverage does not mean every exploitation attempt will be detected or that an alert identifies the specific CVE.

Coverage With Adaptation

Coverage with adaptation applies where related activity falls near the FortiSandbox command-injection and security-control-compromise model but requires additional credential-disclosure, file-deletion, cloud, application, identity, or destructive-impact logic.

·        CVE-2026-27316 requires LDAP-configuration access and credential-disclosure telemetry. The existing model applies when exposed credentials are subsequently used or when disclosure aligns with administrator, configuration, identity, network, cloud, or connected-system activity.

·        CVE-2026-25691 requires VM-image deletion, directory-deletion, file-integrity, service-impact, VM-state, analysis-disruption, report-loss, or destructive-impact visibility.

·        Command execution that occurs entirely through an established encrypted administrative session without observable request, native-event, configuration, identity, file, network, or downstream change requires stronger session, forensic, memory, or destination-platform evidence.

·        Transient or memory-resident execution without retained request, CLI, kernel, process, file, network, or downstream evidence requires forensic, crash, hypervisor, infrastructure, or connected-system evidence.

·        PaaS activity requires customer-accessible or vendor-provided FortiCloud IAM, API, tenant, region, job, service, support, cloud-control, network, or storage evidence.

·        Credential or integration-secret theft that occurs through unlogged memory, database, configuration, export, backup, or service access requires additional credential-access or downstream-use telemetry.

·        Cloud activity requires canonical linkage between the affected FortiSandbox deployment, identity, source, API client, session, account, subscription, project, organization, resource, and cloud event.

·        Ransomware, destructive activity, specialized malware, actor, campaign, or tool procedures require payload-, impact-, infrastructure-, and attribution-specific evidence beyond the FortiSandbox compromise model.

Non-Coverage Conditions

Non-coverage applies where activity does not produce observable suspicious FortiSandbox request behavior, execution-consistent appliance activity, unauthorized state change, analysis manipulation, credential use, evidence degradation, outbound communication, cloud linkage, connected-system activity, or post-remediation evidence.

Non-coverage applies when activity remains limited to:

·        Vulnerable, exposed, misconfigured, or unpatched FortiSandbox state

·        CVE identifiers, KEV status, scanner findings, patch findings, advisory references, or exposure-management records without behavioral evidence

·        Public proof-of-concept availability, exploit names, command strings, filenames, hashes, source IPs, user agents, request paths, actor names, or campaign names without local behavior

·        Malformed, encoded, or special-character-bearing requests without execution, appliance-state, identity, file, network, analysis, or downstream corroboration

·        Successful responses, failed responses, timeouts, service errors, application faults, resource spikes, job failures, VM failures, or service restarts without corroborating evidence

·        Command execution that leaves no retained request, native-event, CLI, kernel, process, file, service, configuration, network, cloud, or downstream effect

·        Administrator, FortiCloud IAM, API, CLI, configuration, update, certificate, report, or integration activity that cannot be distinguished from approved operations

·        Analysis-profile changes, job anomalies, VM anomalies, finding differences, verdict differences, report changes, or notification failures that cannot be distinguished from normal analysis, updates, rescans, content-version differences, maintenance, or analyst action

·        Outbound communication that cannot be distinguished from approved Fortinet services, updates, reputation services, DNS, NTP, mail, storage, logging, cloud, integrations, vendor support, or malware-detonation traffic

·        Connected-system activity that cannot be tied to an affected FortiSandbox identity, source, API client, certificate, token, integration, destination, resource, session, or bounded investigation window

·        Cloud anomalies that cannot be tied to the affected account, subscription, project, organization, identity, source, resource, or FortiSandbox deployment

·        Malware, ransomware, destructive-activity, actor, campaign, tool, or CVE attribution based solely on behavior covered by S25

·        Environments where required asset mapping, request retention, native-event ingestion, administrator attribution, job and VM history, report lineage, network-plane separation, destination baselines, connected-system logging, approved-workflow context, timestamp alignment, or retention is unavailable

Current Coverage Count

Directly Covered CVEs

10

·        CVE-2026-39808

·        CVE-2026-26083

·        CVE-2026-25836

·        CVE-2026-25089

·        CVE-2025-53949

·        CVE-2025-53679

·        CVE-2024-54018

·        CVE-2024-52961

·        CVE-2024-27778

·        CVE-2023-47540

Covered With Adaptation CVEs

2

·        CVE-2026-27316

·        CVE-2026-25691

Not Covered CVEs

0

Current KEV Count

2

·        CVE-2026-39808

·        CVE-2026-25089

The counts apply only to the specifically assessed FortiSandbox CVEs listed in this section. Directly covered and adaptation counts remain separate because they represent different coverage dispositions. Two directly covered CVEs are currently included in the CISA Known Exploited Vulnerabilities Catalog. No combined coverage total should be used.

Coverage Qualification

Coverage is strongest where suspicious FortiSandbox request handling can be joined with execution-consistent CLI, kernel, process, file, service, configuration, system, database, job, VM, report, identity, network, cloud, or connected-system behavior.

Coverage is weaker for exploit attempts without observable appliance effects, request values that are not retained, blind or asynchronous execution, short-lived or memory-resident activity, deleted artifacts, incomplete native-event logging, missing CLI or kernel evidence, weak administrator attribution, unmonitored credential access, shared NAT, inseparable detonation traffic, familiar destinations, approved administrative utilities, customer-limited PaaS evidence, incomplete cloud identity lineage, short retention, and environments where interface, appliance, analysis, identity, network, cloud, change-control, incident-response, and remediation evidence cannot be joined.

The report does not claim universal FortiSandbox command-injection detection, universal appliance-compromise detection, universal analysis-manipulation detection, universal credential-theft detection, universal PaaS detection, universal cloud detection, complete detection of every affected interface or version, universal KEV coverage, or standalone CVE, actor, campaign, malware, or tool attribution.

Detection confidence depends on telemetry completeness, FortiSandbox asset validation, interface and request mapping, native-event normalization, administrator and IAM attribution, job and VM history, finding and report lineage, management-versus-detonation traffic attribution, destination and integration baselines, cloud correlation, approved-workflow mapping, timestamp alignment, retention, query validation, performance testing, false-positive testing, and SOC triage readiness.

Executive Exposure Statement

The organization’s economic exposure is highest when FortiSandbox activity creates uncertainty over whether appliance integrity, administrator access, analysis profiles, VMs, jobs, findings, verdicts, reports, quarantine decisions, notifications, credentials, integrations, submitted content, connected systems, cloud resources, regulated information, customer services, and business-critical defensive workflows remained intact.

The strategic risk is not only that CVE-2026-39808, CVE-2026-26083, CVE-2026-25836, CVE-2026-25089, another FortiSandbox vulnerability, a public exploit, or a known adversary exists. The material risk is that an adversary may have converted trusted malware-analysis infrastructure into unauthorized execution, persistent access, analysis manipulation, credential or integration abuse, evidence suppression, sensitive-submission exposure, downstream security-control compromise, ransomware enablement, destructive activity, operational disruption, or broader enterprise compromise before containment.

S40 — References

Vendor / Platform Documentation

·        Fortinet PSIRT — OS Command Injection through API endpoint

hxxps://fortiguard[.]fortinet[.]com/psirt/FG-IR-26-100

·        Fortinet PSIRT — Incorrect global authorization

hxxps://fortiguard[.]fortinet[.]com/psirt/FG-IR-26-136

·        Fortinet PSIRT — OS command injection on vmimages update feature

hxxps://fortiguard[.]fortinet[.]com/psirt/FG-IR-26-096

·        Fortinet PSIRT — Second-Order OS Command Injection via JSON Input on start vnc feature

hxxps://fortiguard[.]fortinet[.]com/psirt/FG-IR-26-141

·        Fortinet PSIRT — Credential disclosure in LDAP configuration web page.

hxxps://fortiguard[.]fortinet[.]com/psirt/FG-IR-26-113

·        Fortinet PSIRT — Arbitrary directory delete on vmimages delete feature

hxxps://fortiguard[.]fortinet[.]com/psirt/FG-IR-26-115

Vulnerability Records

·        NVD Record — CVE-2026-39808 vulnerability details

hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-39808

·        NVD Record — CVE-2026-27316 vulnerability details

hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-27316

·        NVD Record — CVE-2026-26083 vulnerability details

hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-26083

·        NVD Record — CVE-2026-25836 vulnerability details

hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-25836

·        NVD Record — CVE-2026-25691 vulnerability details

hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-25691

·        NVD Record — CVE-2026-25089 vulnerability details

hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2026-25089

·        NVD Record — CVE-2025-53949 vulnerability details

hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2025-53949

·        NVD Record — CVE-2025-53679 vulnerability details

hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2025-53679

·        NVD Record — CVE-2024-54018 vulnerability details

hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2024-54018

·        NVD Record — CVE-2024-52961 vulnerability details

hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2024-52961

·        NVD Record — CVE-2024-27778 vulnerability details

hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2024-27778

·        NVD Record — CVE-2023-47540 vulnerability details

hxxps://nvd[.]nist[.]gov/vuln/detail/CVE-2023-47540

Known Exploited Vulnerabilities

·        CISA Known Exploited Vulnerabilities Catalog

hxxps://www[.]cisa[.]gov/known-exploited-vulnerabilities-catalog

Threat Tradecraft and Intrusion Patterns

·        MITRE ATT&CK Framework — Enterprise Matrix

hxxps://attack[.]mitre[.]org/