Back hunt.io

Hunt.io's report

hunt.io • September 14, 2026

Thai Broadband Provider Targeted via FortiGate SSL-VPN and MeshCentral Persistence

Disclosure: Hunt.io notified all affected parties and the relevant CERT with a TLP:AMBER advance copy ahead of publication, and held the post per our standard disclosure process. This reflects our notifications only, not any action on their side.

Open directories are one of the most reliable windows into active threat actor operations. When an attacker misconfigures their staging server, everything they have been doing becomes accessible.

Hunt.io's AttackCapture™ discovered an open directory hosted at 92.63.180[.]133:8888 , a server on Bangmod Enterprise Co., Ltd . infrastructure in Thailand. The directory contained 298 files across 30 subdirectories totaling 19 MB , first captured on June 3, 2026, including exploitation scripts, privilege escalation tools, brute-force utilities, a live MeshCentral agent configuration, and a device inventory of already-compromised machines, all targeting 3BB (Triple T Broadband) .

Before going deeper, these are the findings that shaped the entire analysis.

The threat actor used CVE-2024-21762 to target a FortiGate 60F SSL-VPN at mail.3bb.co[.]th.

MeshCentral was configured as a persistent backdoor, with agents pointed at the actor's designated management server, under a device group explicitly named TH-3BB.

The devices.json export confirms multiple machines were already enrolled and actively connected at the time of discovery.

Brute-force scripts contain organization-specific passwords, suggesting the actor had knowledge of 3BB-specific credentials. The source of that knowledge is unconfirmed.

A valid OpenVPN certificate issued by Triple T Broadband's own PKI was found in the directory, that would provide VPN access to the Jasmine network if still valid.

The actor pre-staged a cleanup script to wipe logs and exploitation artifacts while deliberately preserving the installed MeshCentral agent.

The staging server at 92.63.180[.]133 also served as the reverse shell callback host for the CVE-2024-21762 RCE exploit.

Let's explore what we have found.

The Exposed Directory: A Complete Operational Picture

The exposed directory was hosted at 92.63.180[.]133:8888 on Bangmod Enterprise Co., Ltd. infrastructure in Thailand. At the time of capture on June 3, 2026, the server contained 298 files across 30 subdirectories totaling 19 MB , spanning exploitation scripts, privilege escalation tools, brute-force utilities, credential harvesting scripts, persistence mechanisms, captured server responses, cookie files, and configuration artifacts.

The files were tagged across operational categories such as Exploit, Victim, Config, and History, consistent with an active staging environment. The full set of exploits and scripts within the open directory has been mapped into a table to provide a comprehensive view of the attacker's arsenal.

With the infrastructure mapped, the question shifts to who was on the other end of these scripts.

Target Profile: 3BB and the Jasmine Connection

A second target is Jasmine . Triple T Broadband was formerly a subsidiary of Jasmine International, and the two remain linked through shared branding and infrastructure, including 3BB's registered headquarters in Jasmine International Tower.

The jasmine.ovpn file contains a functional OpenVPN client configuration pointing to 110.164.129[.]67:443, signed by a Certificate Authority with the subject openvpn.jasmine.com and the organization Triple T Broadband PCL. The embedded certificate and private key were issued to a client named bbclient, indicating the use of a corporate VPN credential rather than a generic client certificate. The certificate uses a jasmine.com domain but a Triple T Broadband PCL organization field, consistent with the shared infrastructure between the two companies.

Moreover, the additional artifacts, including ccs_c.txt , ccs_cookie.txt , isp_c.txt , and iw_cookies.txt , contain active PHP session tokens for ccs.jasmine.com and systems within the 110.164.131.x network, suggesting parallel operations against both 3BB and Jasmine.

The network configuration captured in dl_n1.txt shows the actor operating from a host with IP address 10.11.152.63 , a gateway of 10.11.152.254 , and a DNS domain of triplet.co.th , confirming that the recovered scripts were executed from a compromised host inside the 3BB internal network rather than from an external system.

To better understand the threat actor's objectives and operational capabilities, we analyzed the collection of scripts and utilities hosted within the exposed open directory.

FortiGate Fingerprinting and Initial Recon

Before attempting any exploit, the actor ran a careful fingerprinting campaign against mail.3bb.co[.]th:10443, a FortiGate SSL-VPN endpoint. Eight shell scripts (forti1.sh through forti8.sh) document this reconnaissance in sequence.

The reconnaissance sequence begins with forti1.sh , which performs comprehensive fingerprinting of the FortiGate SSL-VPN appliance. The script collects HTTP response headers, retrieves the SSL-VPN login page, probes the /remote/fgt_lang endpoint for version-specific artifacts, and queries /api/v2/cmdb/system/status to identify the target device. This information is used to determine the FortiGate firmware version, with characteristics such as the fgt_lang file size providing additional confidence in version identification.

Building on this initial fingerprinting, forti2.sh assesses the target for multiple known FortiGate vulnerabilities rather than focusing on a single exploit. The script probes for CVE-2022-42475 (heap overflow through /remote/hostcheck_validate), CVE-2023-27997 (XORtigate pre-authentication heap overflow), CVE-2018-13379 (path traversal via fgt_lang?lang=/../../../../etc/passwd), and CVE-2024-21762 , indicating that the actor evaluated several exploitation paths before proceeding with the vulnerability best suited to the target environment.

The actor refined the target fingerprinting through forti4.sh and forti5.sh , which download the fgt_lang.js file and identify the FortiOS version by counting version-specific strings, including references to ZTNA (introduced in FortiOS 7.0), CASB (introduced in FortiOS 7.2), and FortiToken components.

The embedded in forti7.sh indicate that this process was used to confirm the target firmware version before exploitation.

The actor also extracted the HTTP ETag value from the FortiGate login page in forti5.sh , using it to infer a firmware build date of June 22, 2023 . This build date falls within the vulnerable FortiOS 7.2.0-7.2.6 range affected by CVE-2024-21762 , providing additional confidence that the target was susceptible to exploitation.

The reconnaissance phase was followed by exploitation preparation and credential validation. The fw_get.sh script contains the FortiGate serial number FGT60FTK2209FY0V within a crafted Fortinet Distribution Network (FDN) request, indicating an attempt to impersonate the target appliance and download its corresponding firmware image for ROP gadget extraction.

In parallel, forti3.sh and forti7.sh perform targeted credential brute-forcing against the /remote/logincheck endpoint using 3BB-specific passwords and common VPN usernames.

CVE-2024-21762: From Vulnerability Validation to Remote Code Execution

Once the FortiGate firmware was identified as a vulnerable release, the actor transitioned from reconnaissance to exploitation. The open directory contains six Python scripts and three wrapper shell scripts that document a structured exploitation workflow.

Crash-Based Vulnerability Validation

The initial validation stage is implemented in crash_poc.py (invoked through crash_run.sh ). The script sends a carefully crafted chunked HTTP request designed to overwrite the return address at offset 0x202e, causing the sslvpnd process to crash and automatically restart. Before and after the crash attempt, the script performs liveness checks to determine whether the service recovers successfully. A restart within a few seconds confirms that the appliance is vulnerable to CVE-2024-21762 while avoiding permanent disruption of the device.

Progressive Vulnerability Detection

After confirming the vulnerability, the actor refined the detection process using forti_cve.sh , which deploys cve_test.py . The script gradually increases the size of the crafted payload through four phases, beginning with safe requests and progressively approaching the overflow threshold. The embedded also document model-specific buffer calculations for the FortiGate 60F, concluding that the target crashes reliably at approximately 4,167 zero bytes , indicating that the actor had already performed empirical testing against this hardware platform.

forti_final.sh (dropped cve_final.py ) further improves reliability by implementing the Bishop Fox detection technique. It sends an incomplete chunked HTTP request to determine whether the target waits indefinitely for additional data (vulnerable) or immediately rejects the malformed request (patched).

forti_verify.sh (dropped cve_verify.py ) repeats this validation across multiple SSL-VPN endpoints, including /remote/error, /remote/login, /remote/hostcheck_validate, and /remote/logincheck, ensuring that no individual endpoint has been patched differently.

Full Remote Code Execution

Once vulnerability validation was complete, the actor deployed cve_exploit.py (executed through exploit_run.sh ) to achieve remote code execution against mail.3bb.co[.]th:10443 .

The exploit follows a three-stage workflow:

It sprays the heap by repeatedly submitting crafted requests to /remote/hostcheck_validate, positioning a ROP chain across memory.

A second chunked HTTP request triggers the out-of-bounds write, redirecting execution to the sprayed payload.

The ROP chain launches /bin/node with an embedded JavaScript reverse shell, establishing a callback to the attacker's VPS at 92.63.180[.]133:9443 .

Firmware Acquisition for ROP Adaptation

The final stage of the workflow focused on obtaining the exact FortiOS firmware image required to adapt the ROP chain to the target device.

Eight supporting scripts (arch.sh, fw_dl.sh, fw_dl2.sh, fw_get.sh through fw_get3.sh, install.sh, and final.sh) attempt to retrieve the FortiGate 60F version 7.2.5 firmware from multiple sources, including Fortinet's update infrastructure, public mirrors, archived copies, and researcher repositories. One script ( fw_dl2.sh ) even emulates a web browser by handling cookies, referrers, and User-Agent headers to bypass download restrictions.

The fw_get.sh script impersonates the target appliance by embedding its serial number ( FGT60FTK2209FY0V ) in a crafted request to the Fortinet Distribution Network (FDN).

Foothold on agent.3bb.co[.]th: Deep Web Application Reconnaissance

In parallel with the FortiGate exploitation chain, the actor conducted extensive reconnaissance against agent.3bb.co[.]th , 3BB's internal sales agent portal running CodeIgniter 2 behind an F5 BIG-IP load balancer. The toolkit ( deep1.sh-deep11.sh ) demonstrates a systematic assessment of the application's authentication mechanisms, session management, file upload functionality, and underlying infrastructure.

The file agent_session.txt contains a serialized CodeIgniter ci_session cookie that decodes to an internal IP address ( 10.11.125.11 ) and a curl/7.68.0 user agent, suggesting automated interaction from within the 3BB network.

The actor subsequently attempted to forge authenticated sessions by targeting CodeIgniter's session validation mechanism. The script deep2.sh tests HMAC validation and brute-forces the application signing key using specific terms as shown in Figure 14 .

The script deep5.sh performed credential brute-force attempts against the agent portal while probing F5-specific endpoints, deep9.sh evaluated null-byte and Unicode path traversal techniques, and deep10.sh enumerated additional 3BB subdomains, including billing, selfcare, api-gateway, and sms. The script deep11.sh tested cookie-based authorization logic and explored the organization's SMS gateway for additional administrative interfaces.

The script deep4.sh targeted the F5 BIG-IP management interface and tested for SSRF, while deep7.sh assessed SQL injection, open redirect, and debug-mode exposure against the agent portal. The deep8.sh then implemented both CL.TE and TE.CL HTTP request smuggling attacks to exploit parser desynchronization between the F5 BIG-IP frontend and the backend application, demonstrating an attempt to bypass intermediary security controls.

Note : We have also found a file " idor_resp " that contains the complete HTML response from the authenticated register_report page, confirming that the actor successfully accessed internal portal functionality during the reconnaissance phase.

F5 BIG-IP Enumeration and CVE Probing

The actor treated the F5 BIG-IP appliance at 110.164.192[.]228 as a separate target. The scripts f5_test.sh and f5_2.sh probe multiple known vulnerabilities, including CVE-2021-22986 , CVE-2022-1388 , and CVE-2023-46747 , while also analyzing F5 persistence cookies captured from the agent portal to identify backend infrastructure and potential WAF bypass opportunities.

The script f5_2.sh further analyzes the TS013b7e0e persistence cookie, identifying it as an F5 Traffic-Shield cookie and attempting to decode the backend pool member IP address and port to communicate directly with the application server.

Post-Compromise Host Operations

Following initial access, the recovered toolkit reveals a comprehensive post-exploitation workflow targeting Linux systems. The actor prepared multiple local privilege escalation paths, including PwnKit (evil.c, evil2.c, evil3.c, launcher.c, launcher2.c), Dirty COW (dcow.c), and a dedicated SUID backdoor installer (install_suid.c), ensuring root access across different Linux distributions and kernel versions. The PwnKit payloads leverage the GCONV_PATH hijack to execute commands as root, while install_suid.c establishes persistent privileged access by deploying a hidden SUID binary.

Beyond privilege escalation, the toolkit includes ghostcat.py , a complete implementation of CVE-2020-1938 ( Ghostcat ) targeting an internal Pentaho BI server ( 10.11.152.4:8009 ) to retrieve configuration files, LDAP credentials, and Tomcat administrative secrets.

The accompanying ghost_mesh.sh verifies that the AJP service is accessible before exploitation. The evidence of successful post-compromise activity is captured in got63.txt , which records root-level command execution on the internal host vm-BCSWILDFLY_M63 , indicating successful compromise of a Linux application server.

Persistence and Remote Access via MeshCentral

After successful host compromise, the actor established persistent remote access using MeshCentral as a command-and-control (C2) platform for remote administration. The recovered meshagent.msh configuration identifies the mesh group as TH-3BB and designates as the management server, reached over WebSocket (/agent.ashx) on port 443. WHOIS history records show the domain was registered on January 27, 2026, roughly four months before the directory was captured, with its nameservers moving from Ultahost to Cloudflare on June 28, 2026.

A domain registered this recently, used only as the MeshCentral management host and then moved behind Cloudflare, fits purpose-registered C2 infrastructure rather than a compromised legitimate site.

The deployment was automated through mesh_fix.sh , with mi2_vps.sh providing a fallback installation method, while ghost_mesh.sh performed pre-installation checks for EDR products and verified outbound connectivity before agent deployment.

The recovered mc_cookies.txt and mc_headers.txt files further indicate that the actor maintained an authenticated session to the MeshCentral management console.

The devices.json file contains a MeshCentral device inventory listing enrolled systems, including hostnames, operating systems, internal and public IP addresses, connection status, and privilege level. Multiple devices were connected (conn:1) with agents running as root (agent.root:true), indicating active administrative control at the time of export.

The inventory also includes a second mesh group referencing a separate organization, indicating the same MeshCentral setup was intended to manage more than one target environment. The group label points to additional targeting, but on its own it does not confirm that organization was compromised.

Internal Reconnaissance, Credential Access, and Lateral Movement

Following establishment of persistence, the actor expanded operations across the internal 3BB environment using a collection of scripts designed for host discovery, credential harvesting, and remote access. The brute.sh , brute2.sh , and brute3.sh scripts performed large-scale SSH password spraying against more than 55 internal hosts using both common and organization-specific credentials.

These activities were complemented by multi_attack.sh , which combined SSH, FTP, and MySQL enumeration, while ftp_explore.sh assessed anonymous FTP access and writable directories on selected hosts.

The attacker uses a script " cred_hunt.sh " that searches compromised systems for SSH private keys, PHP configuration files, database credentials, SNMP community strings, and shell history.

The attacker also uses db_creds.sh , which extracts authentication data from the radius_corp , radiusinfo , and job_radius databases.

The actor further expanded access with deep_hunt.sh , which attempted passwordless MySQL authentication across internal database servers. Moreover, the attacker also used mysql_exploit.sh , mysql_rce.sh , and mysql_rce2.sh abused MySQL file operations to read sensitive files, deploy PHP web shells, inject SSH keys, and modify database privileges, providing multiple mechanisms for persistence and lateral movement across the environment.

Anti-Forensics and Cleanup

The final stage of the toolkit focuses on removing evidence of compromise while preserving long-term access. The cleanup_target.sh script deletes exploitation artifacts associated with PwnKit, Dirty COW, SUID backdoor installation, PHP web shells, and MeshCentral deployment scripts before clearing system logs (auth.log, syslog, nginx logs, and kern.log) and user shell histories.

The script concludes by verifying that persistence mechanisms remain operational, including checking the hidden SUID binary (/usr/local/bin/.rc) and confirming the MeshCentral service is still running. This demonstrates that the cleanup process was intended to conceal the intrusion while ensuring continued remote access to compromised systems.

Organizations operating FortiGate SSL-VPN appliances and similar enterprise infrastructure should consider the following actions:

Verify exposure to CVE-2024-21762 and ensure all FortiGate appliances are running supported, fully patched firmware versions.

Review VPN infrastructure for unauthorized accounts, configuration changes, abnormal authentication attempts, and unexpected administrative activity.

Audit MeshCentral deployments and investigate unauthorized MeshCentral agents, unexpected WebSocket connections, and communications with unapproved management servers.

Rotate privileged credentials , including SSH keys, database passwords, VPN certificates, RADIUS credentials, and application secrets that may have been exposed during compromise.

Review authentication infrastructure , particularly RADIUS servers, VPN services, and identity systems, for unauthorized access and credential extraction.

Hunt for persistence mechanisms , including hidden SUID binaries, unauthorized scheduled tasks, web shells, SSH key modifications, and newly installed remote management software.

Preserve forensic evidence before remediation where compromise is suspected, as cleanup scripts recovered during this investigation demonstrate deliberate attempts to erase logs and operational artifacts.

Indicators of Compromise (IOCs)

The evidence shows the attacker had moved well beyond initial access. A Pentaho BI server was compromised with root privileges, MeshCentral agents were connected across multiple machines at the time of discovery, and the recovered scripts cover credential harvesting and large-scale brute forcing across the network.

Organizations running edge devices and authentication infrastructure should audit for the indicators above, review MeshCentral deployments for unauthorized enrollment, and treat any unpatched FortiGate appliance as an immediate remediation priority.

AttackCapture surfaced this while the operation was still live, before the operator closed the directory. Want to track exposed directories and active attack infrastructure in real time? Book a demo and start hunting today.