SecurityWeek reports that a Thai broadband provider was compromised through a vulnerability in its Fortinet infrastructure. The post-compromise behavior is what should get every defender's attention: the attackers staged a full toolkit on the victim's environment — scripts for network reconnaissance, utilities for probing additional CVEs, brute-force tools, and privilege escalation utilities. This wasn't a smash-and-grab. It was a foothold being converted into a launchpad.
Telecom and ISP environments are high-value targets precisely because of this pattern. Compromise one edge device at a broadband provider and you gain a vantage point into subscriber traffic, downstream customer networks, and trusted peering relationships. Edge devices — FortiGate firewalls, SSL VPN concentrators, and similar appliances — sit at the perfect intersection: internet-exposed, infrequently patched relative to endpoints, poorly instrumented for EDR-style detection, and trusted implicitly by everything behind them.
The specific CVE exploited in this incident was not disclosed in the reporting, which is common when disclosure is coordinated with a vendor. What matters operationally is the playbook: initial access via an edge appliance vulnerability, followed by tooling staging for recon, further vulnerability probing, credential attacks, and privilege gain. That playbook is detectable, and it is preventable. This post walks through both.
Technical Analysis
Affected Products and Platforms
The reported entry point was a Fortinet vulnerability at a broadband provider, which in practice means one of the following product families, in rough order of likelihood for internet-facing exploitation:
- FortiGate / FortiOS — the flagship NGFW and SSL VPN platform, including the SSL VPN portal (
/remote/login), administrative GUI, and IPSec/SSL VPN daemons (sslvpnd) - FortiManager / FortiAnalyzer — centralized management and logging platforms, frequently reachable from management segments that bridge to the internet
- FortiProxy — explicit web proxy, less commonly deployed at ISPs but present in some environments
Fortinet edge vulnerabilities are disproportionately represented in real-world intrusion data. CISA's Known Exploited Vulnerabilities catalog has repeatedly listed FortiOS and related Fortinet flaws, and Fortinet SSL VPN components have been a favored initial-access vector for both ransomware affiliates and state-aligned operators over the past several years. When a vendor advisory for a Fortinet edge product drops, the exploitation window before in-the-wild abuse is routinely measured in days — sometimes hours after PoC publication.
Attack Chain: Defender's View
Based on the reported staging activity, the intrusion followed a pattern we've seen across dozens of edge-device IR engagements:
- Initial access — exploitation of a vulnerability in the internet-facing Fortinet appliance. Typical vectors include pre-authentication flaws in the SSL VPN daemon, authentication bypasses in the management interface, or command injection reachable through exposed admin ports (443, 10443, 8443).
- Tooling staging — scripts written to the appliance filesystem or a pivot host. On FortiGate specifically, attackers commonly abuse the fact that FortiOS is a hardened embedded Linux with limited logging by default: scripts are dropped into writable paths, executed via shell access obtained post-exploitation, and cleaned up afterward.
- Reconnaissance — scanning of internal segments reachable from the compromised appliance: DNS enumeration, service discovery against management subnets, subscriber infrastructure mapping. At an ISP, this means visibility into core routing, RADIUS/authentication infrastructure, and OSS/BSS systems.
- CVE probing — the attackers actively probed for additional vulnerabilities, indicating intent to expand laterally to other appliances and internal systems, or to build redundant access paths in case the initial vector was patched.
- Brute-force and privilege escalation — credential attacks against internal services (SSH, RDP, web admin portals) using the appliance as a launch point, plus local privilege-gain tooling to deepen control.
Why Edge Device Compromise Is Harder to Detect
There is no EDR agent on a FortiGate. There is no Sysmon equivalent on FortiOS. Your visibility into an edge appliance is exactly what the appliance chooses to tell you via syslog — and attackers who gain sufficient privilege can suppress, filter, or tamper with that telemetry. This asymmetry is why edge-device intrusions routinely dwell for weeks or months before discovery, and why your detection strategy must be built around exporting logs off the device immediately and analyzing them centrally, never trusting on-box log review alone.
Exploitation Status
While the specific CVE in this incident has not been publicly attributed, the broader class of Fortinet edge vulnerabilities is under sustained, active exploitation by multiple threat actor groups. Treat any internet-facing Fortinet component as a priority-one attack surface: assume scanning within hours of disclosure and weaponization within days. Check the CISA KEV catalog for the current list of actively exploited Fortinet CVEs and treat those entries as patch-or-mitigate mandates, not recommendations.
Detection & Response
The detections below target the behavioral pattern described in this incident — tool staging, recon, brute-force activity, and appliance-level anomalies — rather than a specific CVE signature. That's deliberate: behavioral detections survive across CVEs, and this actor playbook is consistent across Fortinet intrusions.
Sigma Rules
---
title: Brute-Force Utility Execution on Endpoint or Server
id: 8c2f4a71-6d3e-4b9a-a1f5-2e7c9d0b3a84
status: experimental
description: Detects execution of common brute-force and password attack utilities consistent with tooling staged after edge device compromise, as observed in the Thai broadband provider intrusion.
references:
- https://www.securityweek.com/thai-broadband-provider-hacked-via-fortinet-vulnerability/
- https://attack.mitre.org/techniques/T1110/
author: Security Arsenal
date: 2026/05/12
tags:
- attack.credential_access
- attack.t1110
logsource:
category: process_creation
product: linux
detection:
selection_tool_names:
CommandLine|contains:
- 'hydra'
- 'medusa'
- 'ncrack'
- 'patator'
- 'thc-pptp'
selection_spray_flags:
CommandLine|contains:
- '-P '
- '-U '
- '-C '
- 'ssh://'
- 'rdp://'
condition: selection_tool_names or (selection_spray_flags and 1 of selection_tool_names)
falsepositives:
- Authorized penetration testing engagements
- Password audit tooling run by security teams
level: high
---
title: Reconnaissance Script Staging in Temporary Directories
id: 3f7a9c52-1e84-4d6b-b2c9-5a1d8f0e6b47
status: experimental
description: Detects execution of shell scripts or scanning tools from temporary/world-writable directories, a common staging pattern after edge appliance compromise where attackers drop recon and CVE-probing scripts.
references:
- https://www.securityweek.com/thai-broadband-provider-hacked-via-fortinet-vulnerability/
- https://attack.mitre.org/techniques/T1059/
- https://attack.mitre.org/techniques/T1046/
author: Security Arsenal
date: 2026/05/12
tags:
- attack.discovery
- attack.t1046
- attack.execution
- attack.t1059.004
logsource:
category: process_creation
product: linux
detection:
selection_path:
Image|startswith:
- '/tmp/'
- '/dev/shm/'
- '/var/tmp/'
selection_recon:
CommandLine|contains:
- 'nmap'
- 'masscan'
- 'zmap'
- '/bin/bash'
- '/bin/sh'
- 'curl'
- 'wget'
- 'CVE-'
condition: selection_path and selection_recon
falsepositives:
- DevOps pipelines executing from /tmp (rare in production ISP infrastructure)
- System administrators running ad-hoc scans
level: high
---
title: FortiGate Administrator Anomaly - New Admin or Config Change from Unusual Source
id: 6b1e8d43-9a27-4c5f-8d3a-7f2b9e1c4a56
status: experimental
description: Detects FortiGate syslog events indicating new administrator account creation, admin login failures at scale, or configuration changes — key indicators of post-exploitation activity on the appliance itself.
references:
- https://www.securityweek.com/thai-broadband-provider-hacked-via-fortinet-vulnerability/
- https://attack.mitre.org/techniques/T1136/
- https://attack.mitre.org/techniques/T1078/
author: Security Arsenal
date: 2026/05/12
tags:
- attack.persistence
- attack.t1136
- attack.initial_access
- attack.t1078
logsource:
category: firewall
product: fortigate
detection:
selection_admin_create:
msg|contains:
- 'Add administrator'
- 'edit admin'
- 'new admin'
selection_login_fail:
action: 'login'
status: 'failed'
selection_config:
cfgpath|contains:
- 'system.admin'
- 'vpn.ssl.settings'
- 'system.interface'
condition: 1 of selection_*
falsepositives:
- Legitimate firewall administration by network teams (tune by known admin source IPs)
- Automated configuration management platforms (tune by service account)
level: medium
A note on the FortiGate rule: the value is not in the individual events — your network team does legitimately edit configs. The value is in correlation. A new administrator account created within hours of failed login bursts, or a config change sourced from an IP that has never touched the appliance before, is a high-fidelity signal. Tune the rule with an allowlist of known admin source IPs and service accounts, then alert aggressively on everything else.
KQL — Microsoft Sentinel / Defender
If your FortiGate logs flow into Sentinel via the Fortinet data connector (CEF over Syslog), the following hunts target the compromise pattern from this incident. Run these across a 14-day lookback first, then operationalize as analytics rules.
// Hunt 1: Admin account creation and suspicious configuration changes on FortiGate
CommonSecurityLog
| where DeviceVendor == "Fortinet"
| where TimeGenerated > ago(14d)
| where AdditionalExtensions has_any ("system.admin", "vpn.ssl")
or Message has_any ("Add administrator", "edit admin", "new admin")
| project TimeGenerated, DeviceName, SourceIP, SourceUserName, Message, AdditionalExtensions
| sort by TimeGenerated desc
;
// Hunt 2: Failed admin/VPN login bursts indicating brute-force against the appliance
CommonSecurityLog
| where DeviceVendor == "Fortinet"
| where TimeGenerated > ago(7d)
| where Message has "login" and Message has "failed"
| summarize FailedAttempts = count(), DistinctUsers = dcount(DestinationUserName) by SourceIP, DeviceName, bin(TimeGenerated, 10m)
| where FailedAttempts > 10
| sort by FailedAttempts desc
;
// Hunt 3: Successful logins from source IPs with prior failure history (possible brute-force success)
let FailedSources =
CommonSecurityLog
| where DeviceVendor == "Fortinet"
| where TimeGenerated > ago(7d)
| where Message has "failed"
| summarize FailCount = count() by SourceIP
| where FailCount > 20;
CommonSecurityLog
| where DeviceVendor == "Fortinet"
| where TimeGenerated > ago(7d)
| where Message has_any ("logged in successfully", "login successfully")
| where SourceIP in (FailedSources)
| project TimeGenerated, SourceIP, SourceUserName, DeviceName, Message
| sort by TimeGenerated desc
;
// Hunt 4: Outbound scanning from appliance/management segment (CVE probing behavior)
// Requires firewall traffic logs forwarded via CEF/Syslog
CommonSecurityLog
| where DeviceVendor == "Fortinet"
| where TimeGenerated > ago(3d)
| where DeviceAction in ("accept", "close", "timeout")
| summarize DistinctDestPorts = dcount(DestinationPort), DistinctDests = dcount(DestinationIP), Connections = count()
by SourceIP, bin(TimeGenerated, 15m)
| where DistinctDests > 50 or DistinctDestPorts > 20
| sort by DistinctDests desc
Hunt 4 is the one most SOCs skip, and it's the one that catches the CVE-probing behavior from this incident. A source inside your management or appliance VLAN suddenly touching hundreds of internal destinations across many ports is not normal operations — it's an attacker mapping your network from a beachhead. Baseline your legitimate scanners (vulnerability management platforms, asset inventory tools) and exclude them explicitly.
Velociraptor VQL
Where the intrusion pivots onto Linux infrastructure adjacent to the appliance — jump hosts, management servers, systems the attackers reached with their staged tooling — the following artifact hunts for the staged scripts and brute-force utilities described in the reporting.
-- Hunt for staged attack tooling in world-writable directories
-- Targets recon scripts, CVE probes, and brute-force utilities staged post-compromise
SELECT FullPath, Size, Mtime, Ctime,
upload(file=FullPath) AS Sample
FROM glob(globs=['/tmp/**', '/dev/shm/**', '/var/tmp/**', '/var/log/.*/**'])
WHERE NOT IsDir
AND (
FullPath =~ '\\.(sh|py|pl|elf)$'
OR FullPath =~ '(hydra|medusa|ncrack|nmap|masscan|scan|exploit|cve)'
)
AND Mtime > timestamp(epoch=now() - 60*60*24*14)
ORDER BY Mtime DESC
-- Hunt for active brute-force or scanning processes and their network connections
SELECT Pid, Name, CommandLine, Username, CreateTime
FROM pslist()
WHERE CommandLine =~ '(hydra|medusa|ncrack|patator|masscan|nmap.*-p|CVE-20)'
OR Name =~ '(hydra|medusa|ncrack|masscan)'
-- Correlate suspicious processes with established outbound connections
SELECT Pid, Name, CommandLine, Username,
netstat(Pid=Pid).RemoteAddress AS RemoteAddr,
netstat(Pid=Pid).RemotePort AS RemotePort,
netstat(Pid=Pid).Status AS ConnStatus
FROM pslist()
WHERE Username =~ 'root'
AND CommandLine =~ '(curl|wget|bash|sh|python|perl)'
AND NOT CommandLine =~ '(systemd|/usr/bin|/usr/sbin|/opt/)'
The third artifact hunts a quieter pattern: shells and scripting interpreters running as root from non-standard paths with network activity — exactly what an attacker's staged recon script looks like when it's executing.
Verification and Hardening Script
Run the following against your FortiGate estate to audit for compromise indicators and enforce baseline hardening. Execute from a management host with CLI access to the appliances, or adapt for FortiManager bulk execution.
#!/bin/bash
# FortiGate Compromise Assessment and Hardening Audit
# Run via: ssh admin@<fortigate> < audit.sh (or execute interactively in CLI session)
echo "=== FIRMWARE AND BUILD ==="
get system status | grep -E "Version|Build"
echo "=== ADMINISTRATOR ACCOUNTS (review for unauthorized additions) ==="
show system admin | grep -E "edit |set accprofile|set trusthost"
echo "=== ADMIN TRUSTED HOST RESTRICTIONS (should be configured) ==="
show system admin | grep -i trusthost
echo "=== SSL VPN CONFIGURATION (disable if not required) ==="
show vpn ssl settings 2>/dev/null | grep -E "set status|set port|set source-interface"
echo "=== ADMIN ACCESS ON INTERFACES (HTTP/HTTPS/SSH/TELNET exposure) ==="
show system interface | grep -E "edit |set allowaccess"
echo "=== RECENT CONFIG CHANGE LOG ==="
execute log filter category event
execute log filter field subtype config
execute log display | tail -50
echo "=== ADMIN LOGIN EVENTS (failures and successes) ==="
execute log filter category event
execute log filter field subtype system
execute log display | grep -i login | tail -50
echo "=== UNEXPECTED FILES IN COMMON STAGING PATHS ==="
fnsysctl ls -la /tmp 2>/dev/null
diagnose sys flash list 2>/dev/null
echo "=== ACTIVE SESSIONS AND CONNECTIONS ==="
get system session list | head -40
diagnose sys tcpsock | grep -i listen
echo "=== CRITICAL: VERIFY LOGGING IS FORWARDING OFF-BOX ==="
show log syslogd setting | grep -E "set status|set server"
Key interpretation guidance:
- Admin accounts: any account your team doesn't recognize is a breach indicator until proven otherwise. Cross-reference creation timestamps against your change management records.
- Trusted hosts: if
trusthostentries are absent or set to0.0.0.0/0, your admin plane is reachable from anywhere the interface allows. This is a hard failure in 2026. - SSL VPN: if the business doesn't require it,
set status disableremoves the single most exploited attack surface on FortiGate. - Syslog forwarding: if
show log syslogd settingreturns no active server, you have no off-box forensic record. An attacker with admin access can wipe on-box logs and leave you blind. This is the first thing to fix.
Remediation
Immediate Actions (24-72 Hours)
- Patch the edge. Identify the exact FortiOS/Fortinet firmware version running on every internet-facing appliance (
get system status) and upgrade to the current recommended release per Fortinet's advisory feed at https://www.fortiguard.com/psirt. If you are running an end-of-support FortiOS branch, treat migration to a supported branch as an emergency change — unsupported firmware does not receive fixes for newly exploited flaws. - Check CISA KEV. Cross-reference your deployed versions against the actively exploited Fortinet entries in CISA's Known Exploited Vulnerabilities catalog (https://www.cisa.gov/known-exploited-vulnerabilities-catalog). KEV-listed vulnerabilities carry mandated remediation deadlines for federal agencies; treat them with the same urgency regardless of your sector.
- Rotate all appliance credentials. Admin passwords, VPN user credentials (especially local accounts), API keys, SNMP community strings, and any pre-shared keys configured on the device. Assume that any credential stored on or transiting a potentially compromised appliance is in attacker hands.
- Audit for persistence. Fortinet intrusions have historically involved persistence mechanisms that survive firmware upgrades — modified system binaries, implants in the flash filesystem, rogue admin accounts. Review Fortinet's published IOC and integrity-check guidance for your product line;
diagnose sys flash listand Fortinet's file integrity tooling are your starting points.
Structural Hardening (30-90 Days)
- Remove the admin plane from the internet. Management GUI and SSH access must be bound to trusted host ACLs and reachable only via a dedicated management network or jump host. There is no defensible reason in 2026 for a FortiGate admin interface to answer from the public internet.
- Disable SSL VPN if unused; restrict it hard if used. Enforce MFA on all VPN access, restrict source geographies where operationally feasible, and move toward ZTNA-style replacement for legacy SSL VPN concentrators.
- Export logs off the device — now. Configure
log syslogdforwarding to your SIEM with event, traffic, and UTM log categories enabled. If an attacker owns the box, on-box logs are worthless; central log retention is the difference between a 72-hour investigation and a 6-week one. - Segment the appliance. The FortiGate at an ISP should not have unrestricted reachability into core routing, RADIUS, and OSS/BSS infrastructure. Apply management-plane ACLs so that a compromised edge device cannot pivot directly into crown-jewel systems. The Thai provider incident demonstrates exactly why: the attackers used their foothold to probe and attack internal infrastructure.
- Threat hunt retroactively. Pull 90+ days of historical FortiGate syslog data and run the KQL hunts above against it. If the appliance was reachable and unpatched during that window, assume probing occurred and look for the follow-on behaviors — the initial exploit is often silent; the staging and recon are not.
Lessons for ISP and Telecom Environments Specifically
Service providers carry obligations beyond their own perimeter. A compromised edge appliance at a broadband provider is a potential launch point into subscriber networks and peering partners. If you operate in this space: treat edge appliance patching as a same-week SLA, instrument management-plane access with step-up authentication, and pre-stage an IR retainer that includes network appliance forensics — most generalist IR firms are weak on FortiOS and embedded-device forensics, and you will not want to discover that gap mid-incident.
Related Resources
Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.