Hackers Exploit FortiGate SSL-VPN Flaw to Breach Thai ISP and Deploy MeshCentral Backdoor

Threat actors exploited the critical FortiGate SSL-VPN vulnerability CVE-2024-21762 to target the Thai broadband provider Triple T Broadband (3BB). They gained access to its internal environment and deployed MeshCentral remote management agents for persistent control.

Hunt.io uncovered the operation after AttackCapture identified an internet-accessible directory hosted on a server in Thailand. This directory contained exploitation tools, credential-harvesting scripts, VPN material, session cookies, and an inventory of compromised devices.

When first captured on June 3, 2026, the directory, located at 92.63.180[.]133:8888, reportedly held 298 files across 30 subdirectories.

FortiGate Exploitation Chain

The recovered tools indicated that the attackers initially focused on the FortiGate 60F SSL-VPN appliance at mail.3bb.co[.]th:10443.

Scripts named forti1.sh through forti8.sh performed device fingerprinting, checked the SSL-VPN interface for several known FortiGate vulnerabilities, and tested organization-specific credentials against the VPN login endpoint.

The attackers ultimately selected CVE-2024-21762, an out-of-bounds write vulnerability in FortiOS SSL-VPN that allows unauthenticated remote code execution on affected devices.

Their toolkit included proof-of-concept, validation, and exploitation scripts designed to identify a vulnerable service, trigger controlled crashes, and optimize payloads for the FortiGate 60F platform.

The full exploit chain reportedly sent crafted requests against /remote/hostcheck_validate to prepare memory and execute a return-oriented programming (ROP) payload.

This payload launched a Node.js-based reverse shell that connected back to the staging server at 92.63.180[.]133 over port 9443.

Additionally, the attackers attempted to download the corresponding FortiOS firmware image, likely to identify device-specific ROP gadgets and enhance exploitation reliability.

One script included the target appliance’s serial number, FGT60FTK2209FY0V, to impersonate the device while requesting firmware.

After gaining access, the threat actors deployed MeshCentral, a legitimate open-source remote monitoring and management platform, as a backdoor.

The recovered meshagent.msh configuration identified a device group named TH-3BB and directed agents to www.ayuthayatech[.]com, using the MeshCentral WebSocket endpoint /agent.ashx.

A devices.json file contained an inventory of enrolled systems, including hostnames, internal and public IP addresses, operating system details, connection statuses, and agent privilege levels.

Several entries were reportedly active, with agents running as root, indicating that the attackers had established administrative control over multiple systems.

The attackers used deployment scripts such as mesh_fix.sh, mi2_vps.sh, and ghost_mesh.sh to automate installation, test outbound connectivity, and check for endpoint security products before deploying the MeshCentral agent.

The exposed toolkit included scripts targeting 3BB’s internal 10.11.x.x environment and systems associated with the triplet.co.th domain. Recovered network configuration data suggested that some commands were executed from an already compromised internal host.

Post-compromise tooling included SSH password-spraying utilities, MySQL enumeration scripts, web shell deployment routines, and credential harvesting scripts. The cred_hunt.sh script searched for SSH private keys, PHP configuration files, database credentials, SNMP community strings, and shell history.

Concerningly, the db_creds.sh script targeted RADIUS databases named radius_corp, radiusinfo, and job_radius. These systems may contain subscriber authentication data and network device information, making them high-value targets for attackers seeking to expand access or collect credentials.

The attackers also targeted an internal Pentaho/Tomcat server at 10.11.152[.]4:8009 using CVE-2020-1938, known as Ghostcat. Hunt.io reported evidence of root-level command execution on a compromised Linux application server.

A cleanup script, cleanup_target.sh, was designed to remove exploit files, clear Linux logs, erase shell histories, and delete web shells. However, it deliberately preserved the MeshCentral agent and a hidden SUID backdoor at /usr/local/bin/.rc, allowing the attackers to retain access while destroying evidence.

Organizations should immediately patch FortiGate appliances, inspect VPN logs for suspicious authentication or SSL-VPN activity, search for unauthorized MeshCentral agents, and rotate VPN, SSH, database, RADIUS, and application credentials where a compromise is suspected.

Ioc

Type	Indicator	Description
Attacker infrastructure	92.63.180[.]133	Staging server hosting exploit tooling
Open directory	92.63.180[.]133:8888	Publicly accessible attacker directory
Reverse shell	92.63.180[.]133:9443	Callback listener used by FortiGate exploit
MeshCentral C2	www.ayuthayatech[.]com	Remote-management server used for persistence
MeshCentral path	/agent.ashx	WebSocket agent communication endpoint
Mesh group	TH-3BB	Actor-defined MeshCentral device group
FortiGate target	mail.3bb.co[.]th:10443	Targeted FortiGate SSL-VPN endpoint
Web portal target	agent.3bb.co[.]th	Targeted internal 3BB agent portal
F5 BIG-IP target	110.164.192[.]228	Management interface probed for vulnerabilities
VPN endpoint	110.164.129[.]67:443	Jasmine OpenVPN endpoint in recovered configuration
Internal target	10.11.152[.]4:8009	Pentaho/Tomcat host targeted via Ghostcat
Persistence	/usr/local/bin/.rc	Hidden SUID backdoor path
MeshCentral artifact	meshagent.msh	Agent configuration file
Device inventory	devices.json	List of MeshCentral-enrolled systems
Web shell	/var/www/html/info.php	PHP web shell created through MySQL abuse

Note: IP addresses and domains are intentionally defanged (e.g., [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.

Keep your SOC up to date on active malware & phishing within 24h of their emergence. Try ANYRUN to prevent incidents with early detection.