A WebSocket Remote Access Trojan is malware that uses the WebSocket protocol to maintain remote control of an infected system. It carries commands and responses over a persistent browser-friendly channel, which can help it bypass some network filtering while giving an attacker interactive access.
What a WebSocket RAT changes in the attack path
A WebSocket remote access trojan uses a persistent, browser-friendly channel to move commands and responses between the attacker and the infected host. That matters because the traffic can blend into normal application communication, especially where WebSocket use is already common.
The protocol itself is not malicious, but it is attractive to malware because it can keep a live interactive session without looking like a classic bulk transfer or a simple one-shot beacon. Malware Guide is useful background here because RATs are one family within broader malware behaviour, and the delivery or control channel often matters as much as the payload.
Why WebSocket transport is useful to an attacker
WebSocket gives the operator a bidirectional, long-lived path for tasking, staging, and data return. In practice, that can support interactive shell commands, file movement, clipboard or screenshot collection, and other live control functions while reducing the need for repeated connection setup.
This transport choice can also complicate filtering and inspection. Defenders may focus on obvious remote administration tools, while the abuse is hidden inside an application-layer protocol that many environments already permit for legitimate business use.
WebSocket Security Guide covers the defensive side of the same protocol, including handshake checks, authentication, per-message authorisation, validation, and testing.
How organisations detect and confirm exposure
Exposure is usually identified by combining network, endpoint, and application observations. Look for unusual WebSocket endpoints, sessions that stay open for long periods without a clear business function, abnormal message cadence, and browser-origin patterns that do not match the application’s normal behaviour.
On the host, analysts should look for process lineage, persistence artefacts, and child processes that indicate the malware is brokering operator commands. If the RAT also functions as a loader or backdoor, detection should extend beyond the network layer to payload execution and post-compromise activity.
Remote Access Trojans (RATs) Guide is the best adjacent reference for host detection signals, C2 patterns, and response considerations.
Containment and response after discovery
Once a WebSocket RAT is suspected, the immediate question is not only whether the malware is present, but whether the operator still has an interactive foothold. That means isolating the affected system, preserving telemetry, and checking for lateral movement, credential theft, browser session abuse, and any new persistence the attacker may have added.
Response should also account for the fact that RATs often arrive through trojanised software, fake installers, or other masquerading techniques. The first malicious session may be only one stage in a broader intrusion chain, so remediation should include scoping for additional payloads and re-entry paths, not just removing the visible binary.
Trojans Guide helps frame the delivery and response context for this malware class, while Remote Access Trojans (RATs) Guide adds the operator-behaviour angle.
Risk and Threat Considerations
A WebSocket RAT is risky because it turns ordinary web-friendly traffic into a remote-control channel. That can make command-and-control harder to spot, especially in environments where WebSocket is already allowed for legitimate applications and where outbound web traffic is broadly trusted.
Failure mechanism: The malware hides interactive attacker commands inside a persistent application-layer session, which can bypass simplistic filtering and delay detection until the attacker has already established control.
Impact: The attacker can maintain access, issue commands in real time, harvest data, stage additional tools, and potentially pivot into broader compromise if sessions, credentials, or internal trust boundaries are exposed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5, OWASP ASVS and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1219 — Remote Access Software | WebSocket RATs are a remote-access abuse pattern that ATT&CK classifies under remote access software. |
| Recommendation — Map WebSocket RAT activity to T1219 and hunt for unauthorized remote-control tooling on affected hosts. | ||
| NIST SP 800-53 Rev 5 | SI-3 — Malicious Code Protection | A RAT is malware, so this control family directly supports prevention and containment of malicious code. |
| AU-6 — Audit Review, Analysis, and Reporting | WebSocket RATs often require log correlation across network and host events to confirm compromise. | |
| Recommendation — Apply SI-3 to detect, block, and contain malware that establishes remote control channels. Use AU-6 to correlate WebSocket, proxy, and endpoint logs for remote-control activity. | ||
| OWASP ASVS | V4 — API and Web Service | WebSocket is a web service transport, and secure handling of authenticated interactive traffic is central to the subject. |
| Recommendation — Review WebSocket handling under V4 to enforce authenticated, authorized, and validated message flows. | ||
| CIS Controls v8 | CIS-10 — Malware Defenses | The subject is malware-driven remote access, so malware defence controls directly apply. |
| Recommendation — Use CIS-10 to detect and contain RAT payloads and their persistence mechanisms. | ||
Practitioner Guidance
Why practitioners should care: Treat WebSocket abuse as a network-and-endpoint problem, not just a malware signature problem. If your organisation allows browser-based real-time services, you need visibility into which applications legitimately use WebSocket and which hosts should never be initiating those channels.
What to watch for: Unexplained persistent WebSocket connections, unexpected remote-control processes, and browser traffic that does not align with the user’s role or the application’s expected behaviour are the main warning signs. A useful control point is to compare approved use cases against the system inventory rather than assuming all WebSocket traffic is benign.
Practitioner takeaway: The most reliable defence is to combine application allowlisting, endpoint detection, and protocol-aware monitoring so that WebSocket remains a normal transport for legitimate apps, not a hiding place for remote control.
Related resources from NHI Mgmt Group
- What happens when a fake installer drops a modular remote access trojan onto a workstation?
- What happens when a remote access trojan is delivered through a PDF link that downloads a hidden archive?
- What happens after attackers use government impersonation to deliver a remote access trojan or credential capture page?
- What is the difference between a remote access trojan and a banking trojan in operational terms?