One Click to Kingdom Come

Trust is the foundation of the MSP model, and when that trust is compromised, the impact rarely stops at a single environment. A recent response by the Blackpoint SOC brought that reality into sharp focus after an intrusion moved from initial access into the administrative fabric of an MSP and, from there, into the environments that depended on it. One of the more important findings during the investigation was the discovery of a Node.js based reverse tunnel, dubbed RoadK1ll by the Blackpoint SOC, which gave the threat actor a flexible way to move traffic out of the environment, pivot internally, and operate beyond the limits of a single compromised system. 

This tunnel was not just another tool in the intrusion chain. It was the mechanism that turned a foothold into freedom of movement, giving the actor room to search for higher-value access and identify secrets tied to NinjaOne. Once that access was uncovered, the intrusion shifted from local compromise to platform abuse, allowing trusted remote management infrastructure to be repurposed as a channel for expansion, persistence, and downstream control. What made this case stand out was not the use of a rare capability or unusual tooling, but the practical way familiar access paths, internal tunneling, and administrative trust were combined to widen the scope of the breach. 

The indicators associated with this activity are not present on VirusTotal or other public repositories, which serves as an important reminder that these sources are reference points, not a complete record of what is active, dangerous, or operationally relevant in real environments. Too often, visibility is mistaken for prevalence, and the absence of public reporting can create a false sense of safety around activity that has already proven effective in the field.  

For MSPspartners, and IT leaders, the larger lesson is not simply that an attacker got in. It is that once trusted infrastructure and centralized management platforms come within reach, the path to broader compromise becomes much shorter. This intrusion reflects a familiar pattern applied in a setting where the consequences are amplified, showing how quickly a reverse tunnel, administrative access, and inherited trust can be woven together into a scalable intrusion model. 

Key Takeaways 

  • A single compromise at the MSP layer can create downstream risk across every customer environment that inherits that trust. 
  • Trusted administrative platforms remain high-value targets because they allow threat actors to scale access faster than traditional hands-on compromises. 
  • Perimeter access still matters, especially when exposed services such as SSL VPNs can become the first step toward broader operational control. 
  • Internal visibility is critical, because post-compromise tunneling and proxying can give threat actors the freedom to move quietly while they search for management secrets and privileged access. 
  • RMM security cannot stop at deployment alone, and MSPs must understand who can access the platform, how credentials are stored, and what controls exist to detect malicious activity. 
  • Seemingly routine administrative actions, such as creating support-themed accounts or deploying legitimate forensic tools, can carry outsized risks when they occur outside expected windows. 
  • MSPs that understand their threat landscape, reduce implicit trust, and monitor abuse of legitimate tooling are far better positioned to contain a breach before it becomes a multi-customer incident.  

Observed Kill Chain 

How the Attacker Moved from One MSP to Multiple Customer Environments 

The Blackpoint Response Operations Center (BROC) recently responded to a breach that likely began with the compromise of an SSL VPN, giving the threat actor a foothold inside the internal server environment of the MSP. On its own, that access may have appeared limited, but in practice it placed the actor on trusted infrastructure close to the systems that mattered most. That distinction is important, because the intrusion did not stop at perimeter access. It quickly took on the shape of a broader post-compromise operation, where internal reach mattered more than the initial entry point itself. With access into the MSP’s internal environment, the actor was no longer operating at the edge. They were operating within the same administrative space where centralized management, privileged access, and downstream opportunity were already within reach. 

This shift became clearer after the operator dropped a node.zip archive within ProgramData, a location that often blends easily into normal system activity while giving an operator a practical staging point for follow-on tooling. Once extracted, the archive resulted in the deployment of RoadK1ll, a Node.js based reverse tunnel that gave the actor a practical way to tunnel traffic out and proxy themselves through the MSP network.  

For more information on how this implant works in detail, please see our additional blog breaking down RoadK1ll.  

This was more than simple tool placement. It was the introduction of infrastructure designed to make internal movement easier, more flexible, and less dependent on the original point of access. With RoadK1ll in place, the intrusion gained a new level of mobility, giving the actor the ability to move beyond a single compromised system and operate with the kind of reach needed to pursue higher-value access across the environment. 

With RoadK1ll in place, the intrusion moved beyond simple access retention and into access expansion. What began as a tunnel for internal reach quickly became a practical mechanism for lateral movement, allowing the operator to move through the MSP environment, identify secrets tied to NinjaOne, and convert that access into direct control over the organization’s RMM platform. 

As the actor traversed the MSP’s internal network, they were able to locate and obtain NinjaOne-related secrets that materially changed the scope of the breach. Rather than remaining dependent on the original foothold and the covert tunnel that supported it, the operator used those recovered secrets to create and authenticate a rogue technician account within NinjaOne. This was a meaningful escalation because it shifted the actor from an external intruder moving covertly through a compromised environment to a malicious administrator operating through the MSP’s own remote management plane. 

NinjaOne logs showing creation of malicious technician account using API 

That change in access also changed the scale of risk. A compromised endpoint can provide a foothold, but a compromised RMM platform provides reach, legitimacy, and operational leverage. At that point, the intrusion was no longer limited to movement inside the provider’s internal environment. Instead, the attacker had crossed into the management layer, where platform access translated into direct remote reach across multiple customer organizations. 

NinjaOne Logs showing Remote Management and Ninja Remote sessions created via the Threat Actor 

Using that illicit NinjaOne access, the operator obtained remote access to a mix of servers, workstations, and domain controllers spanning several customer environments. The inclusion of servers and domain controllers is especially significant because it suggests the operation was aimed at high-value infrastructure rather than general exploration alone. Workstations may provide user context or staging opportunities, but remote access to servers and DCs carries far greater operational weight, including opportunities for privilege escalation, credential access, directory interaction, and deeper persistence. 

The observed executions through NinjaOne reflect both the progression and scaling of the breach. Through RMM-mediated access, the operator staged external tooling with curl, transferred PSTools.zip to temp[.]sh, and invoked command-line utilities from an administrative context. The transfer of a legitimate Sysinternals archive to temp[.]sh, the use of curl.exe –help, and repeated upload attempts suggest a brief period of operator troubleshooting while validating syntax and confirming that native tooling could be used successfully through the remote management channel.  

During this investigation, no direct signs of data exfiltration to temp[.]sh were identified beyond the observed tool-transfer activity. Even so, this behavior is important because it shows the intrusion unfolding interactively, with the operator adapting in real time rather than relying exclusively on a rigid prebuilt script. That interactivity is consistent with a hands-on-keyboard intrusion in which the actor is actively testing and refining post-compromise actions after gaining management-layer access. 

Pushing PS Tools to Temp[.]sh as well as Curl Troubleshooting 

From there, the activity progressed into high-impact domain operations. KAPE is a widely used DFIR triage tool designed to rapidly collect and process forensic artifacts from Windows systems. The use of KAPE against the ActiveDirectoryNTDS target indicates a clear focus on collecting Active Directory database material associated with NTDS, underscoring the operator’s interest in domain credential access within affected client environments.  

Dumping of NTDS using KAPE and addition of rogue “Support” account 

Access to this material could support follow-on authentication, facilitate re-entry through legitimate remote access channels such as SSL VPNs, or enable further pivoting within those customer networks. In parallel, the operator created a new user account named Support in several environments and quickly added that account to the Domain Admins group, establishing a rogue administrative identity inside the domain. This sequence is significant because it shows the attacker combining credential-focused collection and privilege operations in the same workflow: one path aimed at obtaining directory-backed credential material, and another aimed at preserving privileged access through native account management. The use of both net.exe and net1.exe variants is also consistent with hands-on operator tradecraft, whether for redundancy, execution reliability, or slight variation in command invocation. 

The final commands show how Go Simple Tunnel (GOST) was interwoven with the broader access model that RoadK1ll had already established. GOST is a network tunneling and proxy utility designed to facilitate traffic forwarding across networks, and its use here reflects deliberate follow-on access engineering rather than opportunistic command execution. Using sc.exe create, the operator installed services masquerading as legitimate Windows components, with binPath values pointing to C:\Windows\System32\*\svchost.exe.  

Creation of malicious service for Go Simple Tunnel (GOST) 

In this case, the referenced svchost.exe was not the legitimate Windows binary, but a GOST payload placed to blend into the surrounding filesystem and service naming conventions. Across compromised client environments, the operator repeatedly created two separate services on a variety of devices. One service configured a local SOCKS listener, while the other established a reverse TCP relay path, allowing the actor to chain local and remote forwarding together into a more durable pivoting mechanism. 

This is where the relationship between RoadK1ll and GOST becomes especially important. RoadK1ll provided the initial reverse tunnel and internal mobility that allowed the operator to move through the MSP, identify NinjaOne secrets, and obtain trusted access to the RMM platform. GOST then appeared as a follow-on tunneling layer deployed deeper in downstream customer environments, where it provided a more formalized, service-backed pivot mechanism on systems the actor had already reached through NinjaOne. In effect, RoadK1ll enabled the transition into the MSP’s management plane, while GOST helped operationalize sustained access, proxying, and post-exploitation within the customer environments themselves. 

As the investigation widened beyond endpoint and RMM activity, the Blackpoint SOC identified additional infrastructure-linked artifacts that helped clarify the threat actor’s broader operating environment. One of the more useful findings was a YAML configuration file associated with a Nezha monitoring agent. Nezha is an open-source server and uptime monitoring platform, but in this case its presence was notable because it pointed to monitoring infrastructure under actor control and aligned with broader evidence of unauthorized remote access. Review of the associated panel further supported that the actor had deployed Nezha early in the compromise and was using it as part of their remote access tooling during what became a prolonged intrusion. 

Nezha Monitoring Panel 

Additional hunting uncovered an operational security failure on the actor’s staging infrastructure. The threat actor had left directories publicly exposed on an Apache server, which provided visibility into portions of the tooling staged there. That exposure offered useful insight into the utilities and supporting components leveraged throughout the intrusion, including executables associated with GOST and Nezha. This was significant because it allowed the investigation to move beyond activity observed solely on compromised hosts and into the external infrastructure supporting the operation, giving Blackpoint a clearer view of the actor’s tooling choices, staging practices, and gaps in operational discipline. 

GOST and Nezha executables within the exposed directory 

The broader intrusion also showed a deliberate progression in both access and capability. RoadK1ll gave the actor the internal reach needed to move laterally and obtain NinjaOne secrets. NinjaOne then provided trusted administrative access into managed customer systems. From there, the intrusion expanded through hands-on remote operations, tool transfer, NTDS-focused collection, rogue domain admin creation, and the deployment of GOST as an additional tunneling layer. These actions were not isolated events, but part of a structured access strategy in which each stage increased the attacker’s reach, resilience, and ability to operate at scale across the environment. 

How Should MSPs Defend Against These Types of Attacks 

  • Harden SSL VPNs with phishing resistant MFA, strict access controls, and rapid patching.  
  • Monitor for unusual Node.js execution, reverse tunnels, and long-lived outbound connections. 
  • Treat RMM platforms as high-risk assets and tightly control technician privileges. 
  • Alert on new technician accounts, privilege changes, and logins from unfamiliar infrastructure. 
  • Protect RMM secrets by reducing access, removing plaintext storage, and rotating credentials often. 
  • Watch for benign-looking admin accounts, unexpected remote execution, and off-hours tool deployment. 
  • Increase visibility on domain controllers and alert on NTDS access or KAPE-like collection activity. 
  • Rely on local telemetry and audit trails, not public repositories alone, to drive detection and response. 

The Bigger Picture: Why MSP Trust Is a High-Value Attack Surface 

The most dangerous breaches are rarely defined by novelty. They are defined by how effectively trust is converted into reach. That is what gives this breach its weight. The significance was never confined to the individual tools, accounts, or actions identified during the response, but to the way trusted access, centralized information, and inherited control were combined into a scalable path for compromise. Once an attacker reaches the systems that sit closest to operational trust, the impact is no longer limited to a single foothold or a single environment. It begins to follow the same pathways built to deliver access, support, and operation continuity at scale. 

There is also an important defensive lesson how activity like this presents itself. Public reporting and repository presence can help inform analysis, but they do not define what is active, dangerous, or operationally relevant in live environments. Some of the most consequential intrusion activities may never appear with broad public visibility yet still carry immediate and far-reaching impact. That reality makes it critical to focus less on whether an intrusion looks familiar in public sources and more on how familiar the techniques continue to succeed against the systems organizations rely on most.  

The broader pattern is difficult to ignore. Efficiency, scale, and administrative trust are operational strengths, but they also create concentrated points of failure when not defended with the same rigor attackers bring to exploiting them. Once that trust is compromised, the path from localized access to wider operational impact becomes shorter, quieter, and far more scalable than many environments are prepared to withstand.  

Indicators of Compromise (IOCs) 

Type Indicator Context / Notes 
Domain Temp[.]sh File Hosting 
IP 149.28.244[.]152 Command and Control (C2) 
IP 45.76.233[.]211 Command and Control (C2) 
IP 149.28.253[.]247 Command and Control (C2) 
IP 216.128.134[.]133 Command and Control (C2) 
IP 45.63.39[.]209 RoadK1ll C2 
IP 194.87.125[.]253 IP leveraged to access RMM 
IP 142.248.80[.]106 IP leveraged to access RMM 
IP 104.238.29[.]81 IP leveraged to access RMM 
File name / Path SHA256 Context / Notes 
Index.js b5a3ace8dc6cc03a5d83b2d85904d6e1ee00d4167eb3d04d4fb4f793c9903b7e RoadK1ll 
Svchost.exe 32ade1df0b89c5922fbb8a1e11a581e887d95db184fe51e02c68c02c2cb63efa  Go Simple Tunnel 
Node.zip cc9c37382669520418db2f953adcbc23b5890a319f662ee8bc8d7840b0809c50 Archive containing RoadK1ll 
Nezha d3abd4bae082d4c9918447fe82c521567cc7f9b0e5f2d55999a6e5c40fa7fd54  Nezha Monitoring 
DATE PUBLISHEDMarch 20, 2026
AUTHORNevan Beal & Sam Decker