FortiGate Implant in Telecom Intrusion: Detecting and Evicting Stealthy Persistence on Fortinet Firewalls

SecurityWeek reports that a persistent, stealthy implant deployed directly on FortiGate firewalls has been linked to the exploitation of a Fortinet vulnerability in an intrusion against a telecommunications organization. That combination — edge appliance, telecom sector, and an implant engineered for quiet long-term persistence — should get every defender's attention immediately.

This is the threat pattern we have been warning clients about for years, and it keeps proving itself out: adversaries, particularly state-aligned operators, have shifted their attention to network edge devices precisely because they sit outside the reach of traditional endpoint detection. Your EDR agents do not run on a FortiGate. Your Sysmon rules do not fire on FortiOS. If an attacker lands an implant on the firewall itself, they gain a position that is both privileged and effectively invisible to most security stacks — and in a telecom environment, that position can mean interception, manipulation, and observation of traffic at scale.

Every organization running FortiGate appliances — which, given Fortinet's market share, is a very large number of you — should treat this as an active-threat scenario and begin hunting now, not after your vendor ticket gets answered.

Technical Analysis

What We Know

Based on the reporting:

• Target: A telecommunications organization — consistent with ongoing state-aligned interest in telecom infrastructure for surveillance and pre-positioning.
• Entry point: An exploited vulnerability in a Fortinet product, used as the initial access vector against FortiGate appliances.
• Payload: A persistent implant installed on the FortiGate itself, described as stealthy — meaning it was engineered to survive reboots where possible, blend into normal system processes, and avoid generating obvious log artifacts.
• Objective: Long-term covert access at the network edge, not smash-and-grab disruption.

Why FortiGate Implants Are So Dangerous

From an IR practitioner's perspective, an implant on a FortiGate is close to a worst-case foothold:

1. No EDR coverage. FortiOS is a proprietary, hardened OS. You cannot deploy CrowdStrike, Defender, or an osquery fleet to it. Detection depends entirely on logs the device emits and external network telemetry — and a competent implant operator will tamper with local logging.
2. Trusted traffic position. The firewall sees decrypted SSL-VPN sessions, administrative credentials, and internal traffic flows. An implant here can harvest credentials passively without generating lateral-movement noise.
3. Persistence survives patching. This is the critical lesson of the past several years of edge-device intrusions: patching closes the vulnerability, it does not remove the implant. Attackers routinely use the exploit window to establish persistence (added admin accounts, modified startup scripts, injected packages, rogue firmware-level changes) that survives firmware updates.
4. Forensic acquisition is hard. There is no "pull the disk and image it" workflow for most FortiGate deployments. Integrity checking requires vendor-specific commands and, in serious cases, factory reset and reimaging from known-good firmware.

Likely Post-Exploitation Behaviors to Hunt

Based on how FortiGate implants documented in prior campaigns (and consistent with this reporting) typically operate, defenders should assume the following TTPs and hunt for their artifacts:

• Rogue administrator accounts created after exploitation, often with names mimicking legitimate service accounts (e.g., fortinet-support, admin_backup, names resembling existing admins with subtle variation).
• Admin logins from unusual source IPs, particularly WAN-side interfaces or IP ranges with no history of administrative access.
• Configuration exports (execute backup config) initiated by unexpected accounts or at unusual times — a precursor to credential harvesting from config files.
• Unexpected processes or injected files on FortiOS, including binaries placed in writable filesystem paths and persistence hooks in startup routines.
• SSL-VPN authentication anomalies — sessions from accounts that no longer exist in IdP, or logins bypassing MFA due to locally created accounts.
• Outbound connections from the firewall itself to uncommon destinations — C2 from the device, not through it.

Detection & Response

The core problem: a stealthy implant will suppress or avoid local logging. Your strongest telemetry is therefore off-device — syslog/CEF forwarded to your SIEM, NetFlow, and DNS. If your FortiGates are not forwarding logs off-box in near real time, fix that today. An implant operator cannot tamper with a log that has already left the device.

SIGMA Detections

These rules assume FortiGate logs are ingested via syslog and normalized. Field names may need mapping to your pipeline, but the detection logic is sound and tuned to fire on genuinely anomalous behavior rather than routine administration.

---
title: FortiGate Administrator Account Created
description: Detects creation of new administrator accounts on FortiGate devices. Rogue admin accounts are a primary persistence mechanism observed in FortiGate implant campaigns. Any new admin account should be a change-controlled, ticketed event.
references:
  - https://attack.mitre.org/techniques/T1136/
  - https://attack.mitre.org/techniques/T1098/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.persistence
  - attack.t1136.001
logsource:
  product: fortigate
  service: event
detection:
  selection:
    logdesc|contains: 'Admin'
    msg|contains:
      - 'Add admin'
      - 'added a new administrator'
      - 'admin user'
  filter_legitimate_action:
    action: 'login'
  condition: selection and not filter_legitimate_action
falsepositives:
  - Legitimate admin provisioning through change management
level: high
---
title: FortiGate Admin Login From Untrusted External Source
description: Detects successful administrator logins to FortiGate devices where the source IP is external/untrusted. Admin interfaces exposed to WAN are the exploitation and post-exploitation management path of choice for edge-device intrusions.
references:
  - https://attack.mitre.org/techniques/T1078/
  - https://attack.mitre.org/techniques/T1133/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.initial_access
  - attack.persistence
  - attack.t1078
logsource:
  product: fortigate
  service: event
detection:
  selection:
    logdesc: 'Admin login successful'
  filter_rfc1918_src:
    srcip|startswith:
      - '10.'
      - '192.168.'
      - '172.16.'
      - '172.17.'
      - '172.18.'
      - '172.19.'
      - '172.2'
      - '172.30.'
      - '172.31.'
      - '127.'
  condition: selection and not filter_rfc1918_src
falsepositives:
  - Emergency remote administration without VPN (itself a finding)
  - Out-of-band management networks on public addressing
level: critical
---
title: FortiGate Configuration Export or Backup Initiated
description: Detects full configuration backups/exports from FortiGate devices. Implant operators export configurations to harvest SSL-VPN user credentials, RADIUS/LDAP secrets, and network topology. Baselining which accounts perform backups makes this high-fidelity.
references:
  - https://attack.mitre.org/techniques/T1005/
  - https://attack.mitre.org/techniques/T1552/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.collection
  - attack.t1005
logsource:
  product: fortigate
  service: event
detection:
  selection:
    msg|contains:
      - 'backup'
      - 'Backup config'
      - 'execute backup'
  filter_known_config:
    action: 'restore'
  condition: selection and not filter_known_config
falsepositives:
  - Scheduled automated backups to FortiManager or TFTP — tune by srcip/user allowlist
level: medium

KQL Hunt — Microsoft Sentinel (CEF/Syslog Ingestion)

If your FortiGates forward CEF to Sentinel, this query surfaces the highest-signal behaviors associated with implant establishment and operation: new admin creation, external admin logins, and config exports. Run it over a 30–90 day lookback — stealthy implants mean the initial compromise may predate any alert.

// FortiGate implant hunt: rogue admin creation, external admin logons, config exports
// Requires FortiGate CEF ingestion via CommonSecurityLog (or Syslog table as fallback)
let Lookback = 90d;
let TrustedAdminSources = dynamic(["10.0.0.0/8", "192.168.0.0/16", "172.16.0.0/12"]); // adjust to your mgmt ranges
CommonSecurityLog
| where TimeGenerated > ago(Lookback)
| where DeviceVendor =~ "Fortinet"
| extend Msg = coalesce(Message, AdditionalExtensions)
| extend Behavior = case(
    Msg has_any ("Add admin", "added a new administrator", "admin user"), "AdminAccountCreated",
    Msg has_any ("backup", "Backup config", "execute backup"), "ConfigExport",
    DeviceEventClassID =~ "32001" or Msg has "Admin login successful", "AdminLogin",
    "Other")
| where Behavior != "Other"
| extend IsExternalSrc = not(ipv4_is_in_any_range(SourceIP, TrustedAdminSources))
| summarize Events = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated),
    Sources = make_set(SourceIP), Users = make_set(SourceUserID), Samples = make_set(Msg, 3)
  by Behavior, DeviceName, IsExternalSrc
| extend RiskScore = case(
    Behavior == "AdminLogin" and IsExternalSrc, 10,
    Behavior == "AdminAccountCreated", 9,
    Behavior == "ConfigExport" and IsExternalSrc, 8,
    Behavior == "ConfigExport", 5,
    1)
| order by RiskScore desc, FirstSeen asc

For SSL-VPN anomalies tied to locally created backdoor accounts, also hunt authentication where the account does not resolve against your IdP:

// FortiGate SSL-VPN logins by accounts not present in Entra ID / AD sign-in telemetry
let VpnLogons =
  CommonSecurityLog
  | where TimeGenerated > ago(30d)
  | where DeviceVendor =~ "Fortinet"
  | where Message has "sslvpn" and Message has_any ("login succeeded", "tunnel-up")
  | summarize by VpnUser = tostring(SourceUserID), SourceIP, DeviceName;
let DirectoryUsers =
  SigninLogs
  | where TimeGenerated > ago(30d)
  | summarize by DirectoryUser = tolower(UserPrincipalName);
VpnLogons
| where tolower(VpnUser) !in~ (DirectoryUsers)
| project VpnUser, SourceIP, DeviceName
| order by VpnUser asc

Velociraptor VQL — Admin Workstation Forensics

You cannot run Velociraptor on the FortiGate itself, but you absolutely should hunt the administrator workstations that manage them — implant operators who own a firewall frequently pivot back to harvest the admin's session tokens, saved SSH keys, and PuTTY/WinSCP configurations. This artifact hunts for network device management tooling executing from anomalous paths and unexpected outbound connections to firewall management ports.

-- Hunt admin workstations for anomalous network-device management activity
-- Rogue copies of SSH/telnet clients from odd paths + connections to mgmt ports
LET mgmt_ports = '(22|23|443|8443|541)' -- FortiGate admin/SSH/telnet/FMG ports

SELECT Pid,
       Name,
       Exe,
       CommandLine,
       Username,
       CreateTime
FROM pslist()
WHERE Name =~ '(?i)(ssh|plink|putty|telnet|winscp|filezilla|pscp|kitty|mremote)'
  AND NOT Exe =~ '(?i)(Program Files|Windows\\System32|OpenSSH|Putty\\\\|WinSCP)'

-- Identify unexpected hosts initiating SSH to network infrastructure
-- Baseline first: legitimate admin hosts should be a small, known set
SELECT Pid,
       Name,
       ProcessName,
       LocalAddress,
       RemoteAddress,
       RemotePort,
       Status
FROM netstat()
WHERE RemotePort in (22, 23, 541, 8443)
  AND Status =~ 'ESTABLISHED'
  AND NOT RemoteAddress =~ '^(10\\.|192\\.168\\.|172\\.(1[6-9]|2[0-9]|3[01])\\.)'

Triage & Hardening Script (FortiOS CLI via Bash)

This script assumes you have CLI access (via SSH from a trusted jump host) and collects the highest-value triage artifacts. Run it against every FortiGate in scope. Do not pipe credentials in cleartext in production — use your vault's CLI injection or run interactively.

#!/usr/bin/env bash
# fortigate-triage.sh — collect implant-triage artifacts from FortiGate devices
# Usage: ./fortigate-triage.sh <firewall_ip> <admin_user>
set -euo pipefail
FW="${1:?firewall IP required}"; USER="${2:?admin user required}"
OUT="fgt_triage_${FW}_$(date +%Y%m%d_%H%M%S).txt"

ssh -o StrictHostKeyChecking=accept-new "${USER}@${FW}" 'bash -s' <<'EOF' > "${OUT}" 2>&1
# === Firmware & integrity posture ===
get system status

# === Admin accounts: review EVERY account, flag unknown/recently created ===
show system admin

# === Trusted hosts: admin access MUST be restricted to mgmt subnets ===
show system admin | grep -f trusthost

# === Admin interfaces: confirm NO admin access on WAN-facing interfaces ===
show system interface | grep -f allowaccess

# === Recent admin session & config-change history ===
execute log filter category event
execute log filter field subtype system
execute log display

# === Running processes: look for unfamiliar binaries, compare across fleet ===
diagnose sys top 5 40

# === Kernel/process list for injected or renamed binaries ===
fnsysctl ps

# === Filesystem check: list non-standard files in writable paths ===
diagnose filesystem flash list

# === Active sessions: identify unexpected admin/SSL-VPN sessions ===
diagnose firewall auth list
get system session list | grep -f admin

# === SSL-VPN settings: confirm auth tied to IdP, MFA enforced ===
show vpn ssl settings

# === SNMP/API: legacy vectors frequently abused for quiet persistence ===
show system snmp community
show system api-user
EOF

echo "[+] Triage complete: ${OUT}"
echo "[!] Review: unknown admins, WAN allowaccess, unexpected processes, odd API users"

Key things to look for in the output: admin accounts you did not create, allowaccess containing https ssh on WAN-facing interfaces, trusted-host lists that are empty or overly broad, API users with full profiles that no one recognizes, and processes that don't match a known-good baseline from an identical firmware build on another unit.

Remediation

1. Identify your exact exposure. Pull your FortiOS version inventory (get system status) across every unit — including HA secondaries, which are frequently forgotten and frequently the persistence location. Cross-reference against Fortinet's PSIRT advisories at https://www.fortiguard.com/psirt and Fortinet's support portal for your model/firmware train. Check CISA KEV (https://www.cisa.gov/known-exploited-vulnerabilities-catalog) for any Fortinet CVE applicable to your versions — KEV-listed entries carry federal remediation deadlines and should be treated as emergency-change items in any environment.

2. Patch — but understand patching is not eviction. Upgrade to the fixed firmware train per the applicable Fortinet advisory. Then, and this is the step most organizations skip: assume the pre-patch device was compromised and perform the post-patch compromise assessment. An implant installed before the patch survives the patch.

3. Audit every administrator account. Delete any account that cannot be tied to a named human and a change ticket. Rotate credentials for all remaining admin accounts, all SSL-VPN local users, LDAP/RADIUS bind accounts, SNMP community strings, and API tokens — in that order.

4. Lock down the management plane. Remove all administrative access from WAN-facing interfaces (allowaccess on WAN interfaces should contain nothing but ping at most). Enforce trusthost restrictions to your management subnets. Require MFA for all admin and SSL-VPN access. Disable telnet and HTTP management entirely.

5. Force off-box logging. Forward syslog to your SIEM over TLS with a dedicated, write-only destination. If an implant tampered with local logs, your only ground truth is what already left the device. Retain at minimum 12 months — telecom-targeting implants dwell long.

6. Verify firmware integrity. Use Fortinet's built-in integrity verification and compare running firmware hashes against Fortinet-published values. For any unit with confirmed or strongly suspected implant activity: factory reset, reflash from known-good firmware downloaded directly from Fortinet, and restore configuration from a pre-compromise backup — not the current config, which may carry the attacker's persistence artifacts.

7. Hunt wide, look back far. Run the KQL and Sigma logic above over at least 90 days of retained logs. Stealthy implants are discovered late by design; the compromise window almost certainly predates your first anomaly.

8. For telecom and critical-infrastructure operators specifically: treat edge-device compromise as a reportable incident under your sector obligations and engage your national CERT/CISA early. The strategic intent behind telecom targeting means your incident is likely one node in a broader campaign, and your telemetry matters to collective defense.

The Bottom Line

Edge devices are the new endpoint battleground, and FortiGate remains one of the most targeted platforms on the internet. The defensive doctrine is straightforward even if the execution is tedious: patch fast, but never trust that patching evicted anyone; audit accounts and configs against change records; force logs off-box; restrict the management plane to the bone; and verify firmware integrity rather than assuming it. The organizations that get hurt in these campaigns are not the ones that were vulnerable — everyone was vulnerable — they are the ones that patched and moved on without asking what the attacker did during the exposure window.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub