top of page

XWorm RAT Resurfaces: Technical Analysis of V6, Plugins, and Evasion

  • danielmiddlemass0
  • 7 days ago
  • 4 min read

XWorm is a widely distributed Remote Access Trojan that has resurfaced with renewed momentum following the release of its latest iteration, V6. Originally emerging from underground forums in 2022, the malware has grown in popularity due to widespread distribution of cracked builds and uncertainty surrounding its current maintainer. Despite limited changes to core functionality, XWorm V6 introduces notable improvements in command‑and‑control communication and modular deployment that significantly impact detection efforts.


In this threat report, we examine the technical characteristics of XWorm V6, focusing on its encrypted C2 communications, plugin architecture, and built‑in evasive behaviour. We also outline practical detection opportunities across network and endpoint telemetry, supported by example Sigma rules that defenders can adapt for threat hunting and monitoring.


Background


XWorm a Remote Access Trojan first sold via Underground forums in 2022, disappeared temporarily after its developer, a threat actor named Xcoder, deleted their online presence. Xworm has seen a major upswing in popularity on the back of a new version V6. Any Run shows this tool as the most uploaded RAT on their platform, indicating its popularity. Usage of this malware has likely increased as "cracked" versions of the software have been widely distributed. Many of these cracked versions, funnily enough, being themselves infected with malware.


Interestingly the intelligence community is unsure if V6 was released by the original maintainer or if development has been taken over by a new threat actor.


Top 3 malware trends tracker
Any.run malware trend tracker

This new release of XWorms has changed little in it's functionality, with the major update being on C2 communication. This still being handled by a custom TCP protocol but now behind 256bit AES encryption, encrypted with a key set by threat actors at creation time. This change renders network detection detection for XWorms RAT less effective. 


flow chart of XWorm C2 packet
XWorm C2 Packet

New plugins have been added to XWorms' portfolio . Plugins being specific "modules" that extend functionality of the server and implant. These can range from allowing threat actors to control a victims remotely via hVNC( Hidden VNC) to implementing ransomware capabilities. These modules are kept server-sided and get transfered over to the victims upon threat actor execution. This reduces the footprint and visibility of attacks.


Detection


To write detection for this version, we choose to analyze the "stub". The stub being implant code that is configured and compiled before spreading. The stub in this instance contains necessary mechanisms for plugin/module support, persistence, C2 communication and anti-analysis. We've identified all built in "commands" available in all XWorms V6 implants.

pong

Urlopen

StartReport

rec

Urlhide

StopReport

CLOSE

PCShutdown

Xchat

uninstall

PCRestart

Hosts

update

PCLogoff

Shosts

DW

RunShell

DDos

FM

StartDDos

plugin

LN

StopDDos

savePlugin

$Cap

OfflineGet

RemovePlugins

Network Detection


Analysis of functionality present in XWorms' "implant" by default, revealed some detectable heuristics that could be use to identify XWorms' behaviour in network traffic. The first being, how XWorm detects against being ran in online sandboxes. This configurable options opens a rather unique non-HTTPS connection against a service that provides intel on IP addresses. This request being:


Method: GET

Host: ip-api[.]com

URI: /line/

Data: fields=hosting


The purpose of this request is determining if the external ip of the victim on which the implant is being ran has been deemed as a "hosting" provider. As most vendors run their infrastructure in scale-able systems this would likely be true for Sandbox provides like any.run, VirusTotal, Hybrid-analys and others.


Another unique heuristic is in the Application Layer "DDoS" functionality. Xworm uses POST requests with hard-coded headers and other unique properties that could be used to fingerprint infections. These requests being the following:


Method: POST

URI: /

Content-Type Header: application/x-www-form-urlencoded

Content-length: 5235User-Agent: "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:66.0) Gecko/20100101 Firefox/66.0" OR "Mozilla/5.0 (iPhone; CPU iPhone OS 11_4_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/11.0 Mobile/15E148 Safari/604.1" OR "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36"


This functionality would result in a victim sending many HTTP POST requests with a hardcoded length of 5235 bytes towards an host with a combination of the 3 user-agents described above.


Endpoint Detection


Analysis into how XWorm stores, verified, updates the various modules that extend its functionality revealed predictable patterns against which NTT Security could build detection for, given the right log sources. These heuristics being in how XWorm stores these modules in the Windows registry. More specifically these modules are stored in a GZIP format in a "binary" type value in predictable locations and key names. This pattern is shown below:


Location: HKEY_CURRENT_USER\Software\ + (20 Uppercase Hexadecimal Characters)Key: 64 Uppercase Hexadecimal Characters

Type: Binary


These 2 values consisting of uppercase hexadecimal characters are calculated from the hash of the modules and the custom "Hardware ID" algorithm that Xworm uses to differentiate victims. 


XWorm Sigma Rules

title: Xworm Anti-Analysis Module
id: cb42109e-9c68-4ae6-bac2-1b8224b60f3d
description: Detects XWorm anti-analysis module. More specifically when Xworm makes a call towards a IP Intelligence service and check whether the external ip address is deemed as hosting.
status: experimental
author: Leandro Ferreira
date: 2025-12-12
modified: 2025-12-12
logsource:
  category: proxy
detection:
  selection:
    http_method: 'GET'
    url_host: 'ip-api.com'
    uri_path: '/line/'
    uri_scheme: 'http'
    uri_query: 'fields=hosting'
    http_user_agent: null
  condition: selection
falsepositives:
- 'Legitimate binaries that legitimately use the service'
level: high

GitHub link to rule:  



title: Xworm Application Layer DDoS Feature
id: c3225cc7-66a1-435a-a093-26be8655b2cd
description: Detects HTTP DDoS feature built into Xworm. Based on hardcoded characteristics of these requests.
status: experimental
author: Leandro Dinis Ferreira
date: 2025-12-12
modified: 2025-12-12
logsource:
  category: proxy
detection:
  selection:
    http_method: 'POST'
    http_content_type: 'application/x-www-form-urlencoded'
    uri_path: '/'
  useragents:
    http_user_agent:
      - 'Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:66.0) Gecko/20100101 Firefox/66.0'
      - 'Mozilla/5.0 (iPhone; CPU iPhone OS 11_4_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/11.0 Mobile/15E148 Safari/604.1'
      - 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36'
  condition: selection and 1 of useragents
falsepositives:
- 'As of this moment Content Length is not parsed and this can therefore trigger some false positives. The hardcoded useragents are old so hopefully not.'
level: medium

GitHub link to rule:


title: Xworm Storage of Modules in registry
id: 2ce3df91-81c7-4327-92ef-dd748957dbcb
description: Detects Xworm registry operations in relation to the storage of implant
  plugins
status: experimental
author: Leandro Dinis Ferreira
date: 2025-12-12
modified: 2025-12-12
logsource:
  category: endpoint
detection:
  selection:
    registry_key|re: '(?i)Software\\[A-F0-9]{20}\\[A-F0-9]{64}$'
    registry_value: 'Binary Data'
    change_type: 'CREATE'
  condition: selection
falsepositives:
- 'Legitimate applications that so happen to make use of this pattern'
level: high

GitHub link to rule:

 
 
bottom of page