Executive Summary

A recent CloudSEK investigation uncovered a mature IoT exploitation and proxy-building operation, identified as “Doorway”, through two exposed identical open directory workspaces identified in October 2026. The identical workspaces contained approximately 41 GB of operational data, including the source code of doorway, a modular Rust-based scanning and delivery engine comprising approximately 21,870 lines of first-party code and 59 exploit modules targeting cameras, routers, optical network units (ONUs), and Java-based services. The recovered material included a credential database, victim logs, beacon captures, and operational playbooks, revealing a coordinated workflow built around automated reconnaissance, exploitation, payload delivery, and persistent device recruitment. Shared infrastructure and identical key artifacts establish that the mirrors supported a single operation with redundant staging capabilities.

The evidence demonstrates substantial exploitation activity and a systematic approach to expanding and maintaining a compromised device fleet. Analysis identified 4,671 module-level join records covering 4,217 distinct IP addresses, 7,369 successful MikroTik/RouterOS authentications across 4,923 device identities, 1,060 PPPoE subscriber records associated with a single ISP, 20 Jenkins remote code execution confirmations, 16 Openfire plugin uploads, and 18 DARKLANTERN router compromises, including eight independently confirmed through beacon evidence. The operator's internal ledger further reports 11,363 joins and 58,920 fetches within a 60-minute window. Collectively, the source code, operational records, and execution evidence indicate a structured, metrics-driven campaign with capabilities spanning credential harvesting, remote exploitation, and proxy infrastructure development. Acquisition errors mean the observed figures represent minimum confirmed counts; no recovered files were executed, built, or modified during analysis.

Modus Operandi Overview:

The operation's measured outcomes in the mirror are substantial:

The image below showcases the geographic distribution of victims. In the workspace we identified a total of 1772 IP addresses of victim devices mapped with the associated geolocation.

‍

Key Findings

• During our investigation, we observed the operation to be still active. Upon analyzing the files present in the workspace we identified that the attacker ran scan from 2026/09/19 to 2026/10/19 to identify new victims. During this run the scan engine recorded the compromise of 11,363 IOT devices and 58,920 recorded instances of second stage payload download events.
• Single Operation with Redundant Infrastructure: The staging mirrors at 16.5.0[.]225 and 16.5.0[.]226 belong to the same six-address source-IP pool. The files were byte-identical, confirming a single operation with redundant staging.

‍

• Exploitation Engine: Rust-based 'doorway' contains ~21,870 lines of first-party code, 59 run modules, 60 registry entries, two payload build modes, and a Go-compatibility layer. Its credential store tracks positive/negative outcomes, ranks passwords by distinct-device support, filters malformed entries, and includes 34 default credential pairs.
• Payload Delivery and Validation: Uses netcat, wget, curl, TFTP, FTP, NFS, short-domain, and form-encoded delivery chains, with IP-bound HMAC signatures and architecture-aware loaders. The ~3,500-byte MIPS32 'stage2.so' beacons to '45.205.1[.]9' and opens an interactive shell on TCP/4444. ICMP beacons confirm execution beyond successful downloads and prevent inflated success counts from repeated beacon loops.
• Managed Operations and Enterprise Targeting: 'WATCHER-BRIEF.md' documents five concurrent agent sessions, production thresholds, continuous activity checks, and automated replanning. Exploitation yielded 20 Jenkins hosts with confirmed RCE and 16 non-lab Openfire plugin uploads across 20 targets, extending activity beyond consumer IoT devices.
• Detection and Disruption: The infrastructure comprises six scanning addresses, one payload fileserver, one NFS export, and one primary beacon receiver. The distinctive 'User-Agent: Hello World', ICMP beacons, and exploit-specific telemetry offer actionable detection and disruption opportunities.

Analysis

The image below showcases the type of devices and infrastructure doorway botnet is capable to target:

The image below showcases the attack flow followed by doorway botnet:

Build and Deployment: The doorway engine is a Rust Cargo package (doorway 0.1.0, edition 2021) that uses tokio, libc, and a native TLS stack. The source supports three documented build configurations, separating production exploitation from execution validation and capability testing.

The image below showcases how the doorway was designed to operate in different modes, allowing the crew to deploy real payloads or test specific parts of its exploitation and delivery workflow without using the full payload set.

The operational playbook directs operators to compile the engine on a workstation rather than on staging servers, run deployments within tmux sessions, increase the open-file descriptor limit using ulimit -n 999999, and use a dedicated termination script instead of issuing inline SSH kill commands. These procedures indicate deliberate separation of build and execution environments, support for high-concurrency scanning, and structured process management. The distinct validation builds also demonstrate that the operators can test execution and delivery-tool availability independently of the full payload deployment workflow.

Transport and fingerprinting: Every target begins with a bounded GET /:

• User-Agent: Hello World and Connection: close are hard-coded in src/net/transport.rs:226 and :313-315.
• Connect timeout is 10 seconds, read timeout 15 seconds, write timeout 10 seconds, first-byte deadline 10 seconds, and idle gap 3 seconds.
• The response is capped at 8 MB (MAX_RESPONSE = 8 << 20, transport.rs:11).
• TLS fallback to the same port occurs only if the TCP connect succeeded, so a filtered port does not trigger a second connection.

The banner is ASCII-folded and matched against per-module fingerprints without per-target allocation. Modules can declare AND fingerprints - additional strings that must all be present - specifically to reject lookalike devices that share a bare Server: header. The honeypot gate is deliberately conservative: more than 12 distinct fingerprints, or more than 10 Server: headers, and the target is dropped (runner.rs:17-18). The code comment explains the high threshold: legitimate Boa-family banners match many fingerprints, so the distinct-fingerprint signal is a backstop rather than the primary tell.

The image below showcases how the doorway does not simply run every exploitation module against every supplied IP address. It uses a controlled initial request, module-specific response matching, and heuristic filtering to narrow the target pool before proceeding.

Execution Stages and Read-Only-First Design: The doorway engine uses a staged execution model in which a module must match the target before the engine invokes probe(), a read-only identification step designed to avoid state changes. If the probe fails, the engine skips run() and does not proceed to exploitation. For matching targets, the documented workflow follows five stages:

This staged design is reflected in the operational logs, which distinguish found, credential leak, login, validated, and cleaned events rather than treating every responsive device as a confirmed compromise. Read-only probing also reduces unnecessary interaction with non-matching targets, while staged execution helps operators distinguish discovery from successful authentication and exploitation. However, the presence of a cleanup stage does not establish that every modification is reliably reversed.

Credential Learning and Storage: The threat actor has implemented a persistent credential-learning mechanism without a conventional database. It stores dictionary entries in line-indexed text files and represents authentication outcomes through compact integer keys.

The image below showcases the credential sets present in the files named ‘credstore.rs’ and ‘learned-creds.creds’.

The image below showcases credential inputs, outcome tracking, compact storage, and the ranking feedback loop.

Tiered Payload Delivery: 

The doorway engine uses a multi-stage delivery architecture rather than relying exclusively on direct deployment of a final binary. A sink-specific command or dropper first introduces a lightweight token loader. The loader identifies the target architecture and retrieves the corresponding binary, which either functions as the final client or downloads the next-stage payload. The recovered mirrors preserve artifacts from each delivery tier, providing evidence of the transition from initial command execution to architecture-specific payload deployment and client installation. This separation allows the operation to accommodate differences in target utilities, processor architectures, and delivery constraints across the supported device families.

The image below showcases the details on the multi-stage payload delivery system used by doorway rather than sending a complete malware binary directly through the initial exploit.

The loader names are short, four to seven characters; so they fit CGI fields and character-limited injection points. The three concrete stage-2 forms,  the Openfire JAR, the wtg83 shell/PowerShell/XML chain, and the RouterOS ‘stage2.so’  are detailed in the next subsection.

The image below showcases Doorway’s staged delivery process, showing how initial access can lead to final-client execution and group assignment, while separating the general loader chain from the distinct RouterOS reverse-shell path.

Transports are equally redundant:

The image below showcases how the doorway engine used multiple payload-delivery methods to improve the chances of reaching a target despite differences in device capabilities, command restrictions, and network filtering. Rather than relying on one download mechanism, the engine attempted several transport options for each injection sink

Every injection sink fires every chain in order. The rationale is explicit in the engine and the playbook: character limits, filtered binaries, and egress controls kill individual chains silently, so a single "best" chain is not reliable. The chain set includes:

nc variants (with and without -e), wget, curl, TFTP, FTP, and raw TCP.

• A short-domain variant through fd6[.]eu for sinks with tight character limits; later operator notes record fd6[.]eu as NXDOMAIN, so direct-IP and 19z[.]in variants coexist.
• Form-encoded variants for CGI endpoints that accept a URL parameter.
• An NFS mount path through 45.90.13[.]11:/srv/nfs.
• A staged printf dropper (util/dropper.rs) that splits a binary into printf '<chunk>' > /tmp/d commands, for devices with no download tool at all.

Stage-2 Payload Architecture: The corpus uses the term stage 2 to describe two distinct but related components: a lightweight loader deployed after initial access that retrieves an architecture-matched client, and a RouterOS-specific shared object that establishes a reverse shell. Both components are preserved in the recovered artifacts, allowing their respective roles to be established from source code and binary analysis rather than inferred from filenames alone. This evidence distinguishes the client-deployment stage from the RouterOS payload responsible for interactive access.

‘ofvalid.jar’: the Openfire stage-2 plugin: 

The image below showcases how ofvalid.jar marks plugin execution, attempts Linux and Windows ICMP beacons, and initiates Java-based payload retrieval and execution.

‍

‍

‍

‍

‍

‍

‍

‍

‍