The discovery of an exposed staging server linked to a breach at Thailand’s major broadband provider, 3BB, has provided a rare, unvarnished look into the operational playbook of a sophisticated threat actor. By analyzing the 298 files found at the attacker’s command-and-control hub, security professionals have been able to reconstruct a timeline that began with the exploitation of a critical edge vulnerability and transitioned into a deep, persistent intrusion within the core network. This session features Dominic Jainy, an expert in high-stakes incident response and threat intelligence, who breaks down the technical specifics of this campaign—from the mechanics of the initial memory corruption exploit to the anti-forensic measures used to mask long-term persistence. Through this lens, we examine how modern adversaries leverage both bespoke exploits and legitimate remote management tools to compromise critical infrastructure at scale.
The discovery of an open directory at 92.63.180.133 provided a massive cache of 298 files that essentially acted as a digital footprint of the entire operation. From your perspective, what does the specific composition of these 19 MB of data tell us about the attacker’s level of preparation and their methodology when targeting a major provider like 3BB?
The sheer variety of artifacts found in those 30 subdirectories reveals an adversary that is both disciplined and highly adaptable. We aren’t just looking at a few automated scripts; we are seeing a full-spectrum toolkit that includes 8 distinct reconnaissance scripts just for fingerprinting the VPN service, alongside database credential harvesters and live configuration files for MeshCentral. The fact that the toolkit occupied only 19 MB shows a focus on lightweight, portable tools that can be easily deployed across different segments of a network like Triple T Broadband. Seeing direct references to internal 10.11.x.x addresses and triplet.co.th domains within the staging server proves that this was a targeted campaign rather than a target of opportunity. This level of organization suggests the attackers had already moved past the “discovery” phase and were well into the “exploitation and maintenance” phase of their lifecycle by the time the server was recorded on June 3.
The initial entry point was a FortiGate 60F appliance targeted through a critical out-of-bounds write vulnerability known as CVE-2024-21762. Could you walk us through the technical nuances of how the attacker moved from sending malformed HTTP requests to achieving a functional reverse shell?
This specific exploit is a textbook example of how unauthenticated remote code execution can devastate an organization’s perimeter. The attacker utilized malformed chunked HTTP requests to trigger the out-of-bounds write condition in the SSL-VPN component, which carries a staggering CVSS score of 9.8. To stabilize the exploit, they employed heap spraying, a technique that saturates the system’s memory to ensure their malicious code lands in a predictable location. Following this, they utilized a return-oriented programming chain to bypass modern memory protections and ultimately launch a reverse shell back to their server at 92.63.180.133 on port 9443. Perhaps the most impressive detail was their attempt to impersonate the compromised device’s serial number to pull specific FortiOS 7.2.5 firmware directly from Fortinet, which allowed them to identify the exact ROP gadgets needed for that specific hardware model.
Once the perimeter was breached, the threat actor deployed MeshCentral to maintain access while simultaneously executing a cleanup script. How do these conflicting actions—maintaining a backdoor while deleting logs—complicate the task for incident responders trying to determine the full extent of the compromise?
The use of MeshCentral is a brilliant, if malicious, “living off the land” tactic because it is a legitimate open-source platform that often bypasses traditional endpoint detection systems. By assigning infected machines to a device group named TH-3BB and directing them to a specific domain like ayuthayatech.com, the attacker established a persistent, administrative foothold that looked like standard remote management. While MeshCentral provided the “open door,” the cleanup_target.sh script was designed to shut the windows behind them by deleting web shells, authentication logs, and shell histories. This creates a forensic vacuum where an administrator might see a running service but find no historical record of how it got there or what commands were executed through it. For a responder, this means the absence of evidence is not evidence of absence; you have to pivot from log analysis to live memory forensics to see those active agents running as root.
The toolkit included scripts for targeting internal Pentaho servers and the radius_corp database, suggesting an interest in much more than just a simple network breach. What are the broader risks when an attacker gains this level of access to subscriber authentication records and internal application servers?
When an attacker starts poking at RADIUS databases and internal Pentaho servers, they are moving toward the “crown jewels” of a broadband provider. Compromising the radius_corp or radiusinfo databases potentially exposes the authentication records and network access secrets for thousands, if not millions, of individual subscribers. This doesn’t just impact 3BB’s internal security; it compromises the privacy and digital safety of their entire customer base. Furthermore, the presence of the jasmine.ovpn profile with a valid certificate from the company’s public key infrastructure suggests the threat could bleed over into the wider Jasmine network. This highlights a critical cascading risk where a single vulnerable VPN appliance at the edge becomes the gateway to a total compromise of the provider’s regional ecosystem.
The attackers were seen testing a wide array of vulnerabilities like Ghostcat, Dirty COW, and PwnKit against internal Linux servers while also performing SSH password spraying across 55 internal addresses. In an environment this complex, what are the most effective defensive layers a provider can implement to stop this kind of lateral movement?
The key to stopping an adversary this persistent is a “zero trust” architecture where the internal network is treated with as much suspicion as the public internet. First, segmenting the 10.11.x.x network so that a breach in one department doesn’t allow a straight shot to the RADIUS databases is essential. Second, the fact that they used SSH password-spraying with 3BB-specific combinations suggests that credential hygiene is a major weak point; enforcing multi-factor authentication for all internal administrative traffic would have effectively neutralized those scripts. We also have to talk about proactive patching; vulnerabilities like Dirty COW and Ghostcat are older flaws, and their presence in the attacker’s toolkit shows they were counting on finding unpatched “ghost” systems deep within the infrastructure. Combining rapid patch management with behavioral monitoring that flags unusual outbound connections to sites like ayuthayatech.com would significantly shorten the attacker’s dwell time.
What is your forecast for the evolution of these types of edge-device exploitations over the next few years?
I expect we will see a significant shift toward “automated persistence,” where attackers use AI-driven scripts to immediately identify the hardware serial number and firmware version of a compromised appliance to generate custom ROP chains in real-time. We are already seeing the beginnings of this with the 3BB breach, where the actor attempted to automate the retrieval of model-specific firmware. As edge devices like SSL-VPNs become more complex, the window between a zero-day discovery and its weaponization across a global fleet of devices will likely shrink to just a few hours. Consequently, the defense will have to move toward “autonomous patching” and hardware-level root-of-trust protections, because by the time a human administrator reads a security bulletin, a sophisticated actor could already be sitting inside their RADIUS database. The era of manual perimeter defense is closing; the future belongs to those who can automate their resilience as fast as the adversary automates their aggression.