RoadK1ll: A WebSocket Based Pivoting Implant
During analysis of a recent intrusion, the Blackpoint Response Operations Center (BROC) identified a Node.js based implant deployed within the compromised environment which the BROC is tracking as RoadK1ll. At a glance, it might not look like your typical piece of malware, as there are no large command sets or obvious operator tooling built in. Instead, RoadK1ll is built to solve a very specific problem for the attacker: maintaining reliable, flexible access into an internal network after initial compromise.
RoadK1ll is a Node.js-based reverse tunneling implant that establishes an outbound WebSocket connection to attacker-controlled infrastructure and uses that connection to broker TCP traffic on demand. Unlike a traditional remote access trojan, it carries no large command set and requires no inbound listener on the victim host. Its sole function is to convert a single compromised machine into a controllable relay point, an access amplifier, through which an operator can pivot to internal systems, services, and network segments that would otherwise be unreachable from outside the perimeter.
What makes this especially effective is how quietly it fits into real environments. By relying on outbound web-style traffic and avoiding the need for inbound listeners, RoadK1ll blends into normal network activity while still giving the attacker a high degree of control. The result is not just persistence on a single system, but a reusable access path that supports broader movement throughout the environment.
How RoadK1ll Communicates: Custom WebSocket Protocol and Message Framing
To understand how RoadK1ll operates, it’s worth starting with how it communicates. Rather than relying on standard tunneling frameworks or off the shelf tooling, RoadK1ll implements a simple, custom protocol designed to move multiple streams of traffic over a single WebSocket connection.
Early in the source code, RoadK1ll imports two key Node.js modules: net for raw TCP socket handling and ws for WebSocket communication. This pairing is important because it shows the malware is designed to sit between two worlds, on one side: an outbound WebSocket session to attacker infrastructure, and on the other, local TCP connections that can be opened on demand. In practical terms, this is the foundation of the implant. RoadK1ll is preparing to receive instructions from a remote server and broker traffic through the compromised host to other destinations.
Importing the net and ws modules
The next block of code defines the operator-controlled infrastructure and connection settings. VPS_HOST and VPS_WS_PORT identify the remote relay server; TUNNEL_SECRET provides a basic authentication token and RECONNECT_INTERVAL shows that the implant is designed to re-establish its tunnel if the connection drops.
Defining connection settings
One of the most important pieces of the implementation is a comment defining the message format used for communication over the tunnel. Each message begins with a 4-byte channel identifier, followed by a 1-byte message type, with the remaining bytes representing the payload.
Defining custom framing protocol
This structure allows RoadK1ll to multiplex multiple logical connections over a single WebSocket session. Rather than opening a new connection for every action, the operator can manage several independent channels at once, all riding over the same outbound tunnel. This design makes the implant far more flexible and scalable during post-compromise operations.
After defining the message format, RoadK1ll establishes a small but effective command vocabulary that drives how the tunnel operates. These message types act as the control layer for the implant, allowing the remote operator to manage connections and move traffic through the compromised host.
The message types are defined as follows:
- DATA – Represents raw traffic being forwarded through an active channel
- CONNECT – Instructs the implant to establish a new TCP connection
- CONNECTED – Confirms that the requested socket was successfully established
- CLOSE – Signals that a channel should be terminated
- ERROR – Provides failure feedback to the operator
Defining message types for this custom protocol
How RoadK1ll Manages Multiple Concurrent Connections
With the message structure and command types defined, RoadK1ll implements a message handling layer to reliably process traffic moving through the tunnel. This is where the protocol transitions from a defined format into something the implant can actively use.
The encodeMessage function is responsible for building outbound messages. It constructs a fixed 5-byte header, writing the channelId into the first four bytes and the message type into the fifth. If no payload is present, the header alone is returned, which is sufficient for control messages such as connection requests or status updates. When a payload is included, it is appended to the header, with string data converted into UTF-8 bytes before transmission.
Outbound Message Handling Layer of RoadK1ll
The companion decodeMessage function performs the reverse operation on inbound traffic. It first validates that enough data is present to form a complete header, then extracts the channel identifier, message type, and payload. This ensures that each incoming WebSocket frame can be interpreted correctly before being acted on.
Inbound Message Handling Layer of RoadK1ll
Together, these functions form the core of RoadK1ll’s custom wire protocol. They provide a consistent way to package and interpret both control instructions and raw network traffic, regardless of whether the data being transmitted is binary network data or a text-based status message.
In addition to message handling, RoadK1ll maintains runtime state to track active connections. A Map structure is used to associate each channelId with a corresponding TCP socket, allowing the implant to manage multiple concurrent sessions at once. Supporting variables track the active WebSocket connection and handle reconnection timing if the tunnel is interrupted.
Mapping active connections
This combination of structured message handling and connection tracking is what allows RoadK1ll to function as more than a simple relay. It enables the implant to manage multiple independent channels simultaneously, turning a single outbound connection into a scalable and controllable pivoting mechanism.
How RoadK1ll Establishes Its Outbound C2 Tunnel
With message handling and state management in place, RoadK1ll next establishes its primary outbound control path to attacker infrastructure. This is handled through the connect function, which is responsible for building and maintaining the WebSocket tunnel that all communication flows through.
Establishing Outbound WebSocket C2 / Tunnel Session
The implant constructs a WebSocket URL using the configured VPS host, port, and shared tunnel secret. Once built, the line ws = new WebSocket(…) is where the tunnel is created. At this point, the malware reaches back to attacker-controlled infrastructure and establishes the WebSocket session that will carry all subsequent control messages and proxied traffic.
One detail worth noting is the presence of the commented option rejectUnauthorized: false. While not active during analysis, it suggests the developer accounted for environments where TLS certificate validation could interfere with connectivity, reinforcing the implant’s focus on reliability across varied network conditions.
Creation of the Tunnel
Following initialization, the session is configured with ws.binaryType = ‘nodebuffer’, instructing the WebSocket to treat incoming data as raw Node.js buffers rather than strings or browser-style blobs. This is important as it highlights that RoadK1ll is designed to transport arbitrary binary traffic, not just simple text-based commands.
Session Configuration for Node.js buffer
After the connection is established, RoadK1ll transitions into its primary tasking loop by listening for inbound messages from the relay. Each message is decoded and processed according to its type, allowing the operator to dynamically create connections, forward traffic, and manage sessions through the compromised host.
How Operators Control RoadK1ll Remotely
Once the WebSocket tunnel is established, RoadK1ll transitions into its active control phase. At this point, the implant is no longer just maintaining a connection; it is actively receiving and acting on instructions from the remote operator.
Incoming messages are handled through a listener tied to the WebSocket session. Each message is first passed through the decoding routine to extract the channel identifier, message type, and payload. If decoding fails or the message is malformed, it is ignored, helping maintain stability within the tunnel.
Listening and Decoding inbound messages
From there, RoadK1ll uses a simple switch-based control flow to determine how each message should be handled. Rather than implementing complex command logic, the implant maps each message type directly to a corresponding handler function:
- CONNECT → handleConnect
- DATA → handleData
- CLOSE → handleClose
Main Operator Control Path within RoadK1ll
The most important transition occurs when a CONNECT message is received. This signals the implant to establish a new outbound TCP connection to a target specified by the operator. At this point, the malware is no longer acting as a passive relay; it is actively creating new network paths on demand.
From an operational perspective, this is what turns RoadK1ll into a true pivoting tool. The operator can dynamically instruct the implant to open connections to internal systems, forward traffic through those connections, and close them when no longer needed, all through the single WebSocket tunnel.
This control flow effectively gives the attacker a structured and reliable way to interact with the internal network, using the compromised host as a controllable relay point for broader movement.
How RoadK1ll Enables Lateral Movement Through Compromised Networks
The pivoting capability within RoadK1ll is implemented through the handleConnect function, which is triggered when the implant receives a CONNECT instruction from the remote operator. This marks the transition from control logic into active network interaction.
Parsing inbound data payloads
When invoked, the function first attempts to parse the incoming payload, which is expected to be structured data containing a target host and port. This reflects a deliberate design choice, rather than sending raw connection strings, the operator provides well-formed connection parameters, allowing RoadK1ll to reliably interpret and act on each request. If parsing fails, the implant responds with an ERROR message, providing immediate feedback to the operator.
Once the payload is successfully processed, RoadK1ll calls net.createConnection({ host, port }). This is the critical moment where the compromised system initiates a new outbound TCP connection to the specified destination. At this point, the host is no longer just maintaining a tunnel back to attacker infrastructure; it is actively reaching into the internal network or other accessible systems on behalf of the operator.
The Pivoting Mechanism with RoadK1ll
If the connection is successfully established, the implant sends a CONNECTED message back through the WebSocket tunnel, confirming that the channel is ready to carry traffic. This acknowledgement allows the operator to immediately begin interacting with the target system through the established connection.
This is what enables lateral movement via the implant. The attacker can instruct RoadK1ll to open connections to internal services, management interfaces, or other hosts that are not directly exposed externally. Because these connections originate from the compromised machine, they inherit its network trust and positioning, effectively bypassing perimeter controls.
This mechanism transforms RoadK1ll from a simple tunneling implant into a functional pivot point. A single compromised host becomes a gateway into the broader environment, allowing the operator to explore, access, and interact with internal systems that would otherwise be out of reach.
How RoadK1ll Forwards Traffic Between the Attacker and Internal Systems
With a channel successfully established, RoadK1ll shifts into its data-forwarding role. This is handled through the handleData function, which is responsible for taking traffic received from the remote relay and writing it into the correct live socket on the compromised host.
Data Forwarding Function within RoadK1ll
To do that, the implant looks up the active connection in its connections map using the supplied channelId. This ties each inbound WebSocket message to a specific TCP session, reinforcing that RoadK1ll is designed to manage multiple concurrent connections rather than a single monolithic tunnel. Each channel is tracked independently, allowing the operator to interact with several destinations at once through the same outbound session.
Once the correct socket is located, RoadK1ll performs a basic validation check to confirm the connection still exists and has not already been destroyed. If the socket is valid, the implant writes the payload directly into that connection. In practical terms, this is the mechanism that allows operator-supplied traffic to be injected into whatever internal host or service the tunnel has been pointed at.
The reverse direction is handled through sendToVps, which acts as the return path for the implant. This function packages status messages, errors, and data received from active sockets, then sends them back across the WebSocket tunnel to the remote relay. Before transmitting, it verifies that the WebSocket session is still active, helping avoid attempts to send data over a closed or invalid connection.
Outbound Relay Transport with RoadK1ll
Together, these two functions complete the relay loop. Traffic received from the operator is forwarded into the appropriate TCP connection, while responses from that connection are sent back through the attacker-controlled WebSocket channel. This bidirectional flow is what makes RoadK1ll a true tunnel rather than a one-way proxy or simple callback mechanism.
From an intrusion perspective, this relay logic is what gives the implant real operational value. Once a connection is established, the compromised host can transparently pass traffic between the attacker and internal systems, effectively serving as an access broker for follow-on movement throughout the environment.
How RoadK1ll Maintains Access: The Reconnection Loop
The final component of RoadK1ll’s design focuses on maintaining access, even when the underlying connection is interrupted. This behavior is implemented through the scheduleReconnect function, which is responsible for restoring the WebSocket tunnel if it is lost.
Reconnect Loop within RoadK1ll
If the connection drops, RoadK1ll does not terminate or require manual reinitialization. Instead, scheduleReconnect first checks whether a reconnect timer is already active, preventing multiple overlapping reconnection attempts. If no timer is running, the function logs that it will retry after the configured interval and uses setTimeout to delay execution.
Once the timer expires, the function clears the existing timer reference and calls connect() again, re-establishing the outbound WebSocket session to attacker infrastructure. This creates a simple but effective reconnection loop that allows the implant to recover from transient network issues or disruptions without operator involvement.
From an operational standpoint, this adds a layer of resiliency that reduces the attacker’s dependency on a perfectly stable foothold. As long as the process remains running, RoadK1ll will continue attempting to restore its tunnel, allowing the compromised system to return to service as a relay point once connectivity is re-established.
It’s important to note that this mechanism does not represent persistence in the traditional sense, there are no registry run keys, scheduled tasks, or service installations observed within this component of the implant. Instead, RoadK1ll’s persistence is conditional, it maintains access as long as the process remains active and focuses on preserving connectivity rather than re-establishing execution.
Methodology and Attribution
While tunneling itself is not new, RoadK1ll shows a more modern and purpose-built implementation of that tradecraft. Rather than behaving like a traditional, feature-heavy remote access trojan, RoadK1ll is narrowly focused on turning a compromised system into an attacker-controlled network relay. By using a lightweight WebSocket connection back to the attacker infrastructure and a simple channel-based design, it allows an operator to open and manage multiple TCP connections through the victim without exposing an inbound listener to the host. This is what makes RoadK1ll operationally efficient, easier to deploy, and better aligned with contemporary intrusion workflows that prioritize flexibility and low host overhead.
RoadK1ll’s functionality is unique as it packages tunneling as a modular post-compromise capability with a larger purpose. Its role is to expand the value of an initial foothold by giving the attacker a reliable path to internal systems, local-only services, and segmented network resources that would otherwise be difficult to reach. RoadK1ll serves as an access amplifier as it takes one compromised machine and turns it into a reusable pivot point for follow-on activity.
Host Based Indicators of Compromise
| File name / Path | SHA256 | Context / Notes |
| Index.js | b5a3ace8dc6cc03a5d83b2d85904d6e1ee00d4167eb3d04d4fb4f793c9903b7e | RoadK1ll |
Network IOCs
| IP | 45[.]63[.]39[.]209 | RoadK1ll C2 |