Lab52 has published a technical analysis of DragonForce-linked backdoors that abuse legitimate relay infrastructure and MQTT messaging for command-and-control resilience. The important takeaway is not just “new ransomware tooling.” It is that ransomware operators are continuing to professionalize the access layer that comes before encryption.

Source: Lab52 — Backdoors in the Dungeon: TURN & MQTT Abused by DragonForce.

What Lab52 reported

According to Lab52, recent DragonForce activity used two backdoor patterns. One is an in-memory Go backdoor associated with TURN-based communications. The second is a more persistent backdoor that can communicate over TURN and also use MQTT as a fallback channel when TURN is unavailable.

The persistent variant is especially relevant for defenders because it combines several techniques that can look individually mundane:

  • Scheduled-task persistence left by an earlier stage.
  • DLL sideloading through a legitimate Java executable.
  • Encrypted payload staging, including DPAPI-bound content on the local host.
  • In-memory payload execution using Windows memory-protection changes and thread creation.
  • TURN and MQTT communication paths that can blend with legitimate collaboration or messaging traffic.
  • Sleep-and-encrypt behavior intended to make the implant harder to inspect while inactive.

Lab52 also noted overlap with prior reporting on DragonForce tooling, including abuse of legitimate Microsoft Teams TURN infrastructure to conceal malicious traffic. In plain English: defenders should not assume that traffic to a trusted cloud or collaboration service is automatically benign.

Why this matters

DragonForce is not only a ransomware brand. Like many modern ransomware-as-a-service operations, it depends on repeatable access, resilient command-and-control, and durable post-compromise footholds. Encryption may be the visible business-impact event, but the real fight usually happens earlier: initial access, persistence, credential theft, lateral movement, and data staging.

The TURN and MQTT details matter because they target a common blind spot. Many small and mid-sized organizations allow collaboration traffic, cloud communications, and outbound broker-style protocols with limited inspection. That is understandable: blocking legitimate productivity traffic can break the business. But attackers know this, and they increasingly hide inside traffic classes that defenders are reluctant to touch.

For government contractors, professional services firms, healthcare providers, and SMBs with limited security staff, this is a reminder that ransomware defense cannot rely on blocking known bad IPs alone. The defensive priority should be behavior correlation: which endpoint created the connection, which process made it, what persistence exists on the host, and whether that same identity or machine is also showing credential-access or lateral-movement signals.

What defenders should do now

1. Baseline TURN and MQTT usage

Most organizations do not have a clean inventory of where TURN, STUN, WebRTC relay traffic, or MQTT should appear. Build a short allowlist of expected applications, destinations, and device groups. Collaboration tools may need relay traffic; random workstations talking to unfamiliar brokers usually deserve scrutiny.

2. Hunt for suspicious Java sideloading

Lab52 described abuse of javaw.exe loading a suspicious jli.dll. Defenders should review endpoint telemetry for Java executables launched from unusual directories, Java processes that spawn scripting tools, and DLL loads from paths that do not match approved Java installations.

3. Treat scheduled tasks as persistence evidence

Scheduled tasks remain a common ransomware precursor. Review newly created or modified tasks, especially those invoking Java, PowerShell, temporary paths, user profile directories, or oddly named DLL/TXT payloads. If a scheduled task appears after a suspicious remote-access event, treat it as part of an intrusion until proven otherwise.

4. Correlate encrypted outbound traffic with process lineage

Encrypted C2 traffic is normal-looking by design. The useful signal is often the endpoint context: unexpected process parentage, unsigned DLLs, abnormal command-line arguments, rare destination infrastructure, repeated sleep intervals, and connections that begin shortly after persistence executes.

5. Do not stop at malware removal

If this class of backdoor is found, the response should include credential resets, remote-access review, privileged-account validation, cloud session revocation, and data-exfiltration assessment. Removing the binary without understanding how the operator arrived leaves the organization exposed to re-entry.

Bulwark Black assessment

This DragonForce reporting fits the broader ransomware trend: operators are investing in survivable access, not just faster encryption. TURN abuse helps hide in trusted collaboration pathways. MQTT gives operators another lightweight command channel. DLL sideloading and scheduled tasks give them persistence that can survive reboots and blend into noisy endpoint environments.

The practical lesson is that ransomware readiness needs to look more like intrusion-response readiness. Patch management and backups still matter, but defenders also need network egress visibility, endpoint process telemetry, identity containment procedures, and a plan for deciding when “one suspicious host” is actually “assume compromise until scoped.”

For SMB and government-contractor environments, the highest-value move is to tighten the path between endpoint alerts, firewall/proxy logs, identity logs, and backup/restore decisions. If those teams and tools are disconnected, an operator using legitimate relay paths can stay ahead of the response timeline.

Defensive checklist

  • Inventory approved collaboration tools and expected TURN/STUN relay destinations.
  • Alert on MQTT traffic from workstations or servers with no business need for broker communications.
  • Monitor java.exe and javaw.exe for unusual child processes, network connections, or DLL load paths.
  • Review scheduled tasks created after remote-access, phishing, or credential-theft alerts.
  • Preserve EDR, proxy, DNS, firewall, and identity logs before rebuilding affected systems.
  • Rotate credentials and revoke active sessions when persistence or C2 is confirmed.
  • Validate that backups are isolated and recovery accounts are not exposed to the same identity plane.

DragonForce’s use of redundant communication paths is a good reminder: the ransomware event is often the end of the operation, not the beginning. The earlier defenders can detect strange persistence and strange outbound traffic from legitimate-looking processes, the better chance they have of stopping the incident before the business-impact phase.