- CloudSEK analysed about 41 GB of exposed files from a botnet toolkit called Doorway. It holds 59 exploit modules for cameras, routers and Java services.
- The files include a brief that CloudSEK says runs the botnet like a site reliability team. It tracks output, shifts effort and escalates.
- Check internet-facing routers, cameras and Java servers for default logins and unpatched flaws. Flag unexpected outbound downloads from them.
Most of us picture an attack as a script that someone runs once. CloudSEK's analysis of a toolkit called Doorway shows something closer to an operations desk. It tracks output, spots what is underperforming and moves effort elsewhere. At least one operation managed its campaign the way a good team manages a service.
What CloudSEK found
CloudSEK says it found two identical open directories in October 2026. Together they held about 41 GB of operational data. The material included the source code of Doorway, a scanning and delivery engine written in Rust. CloudSEK puts it at about 21,870 lines of first-party code.
The toolkit has 59 exploit modules. They target cameras, routers, optical network units (the boxes that end a fibre line) and Java-based services. The files also held a credential database, victim logs and operating playbooks.
The records show real activity. CloudSEK counted 4,217 distinct IP addresses in 4,671 module-level join records. It also counted 7,369 successful MikroTik RouterOS logins across 4,923 device identities. It found 20 confirmed Jenkins remote code executions.
CloudSEK also found 1,060 subscriber records tied to one internet provider. Of 18 compromises of a router type called DARKLANTERN, eight were confirmed by beacon evidence. It mapped 1,772 victim IP addresses.
These are minimum counts, CloudSEK says, because of acquisition errors. It also says it did not run, build or modify any recovered file.
How the engine works
The design is cautious, not noisy. A module must first match a target. The engine then runs a read-only check called probe(), built to avoid changing the device. Only if that passes does it try to exploit the target.
The logs record each step on its own: found, credential leak, login, validated and cleaned. A device that merely answers is not counted as a victim.
The engine also tries to avoid traps. CloudSEK says the code drops a target that shows more than 12 distinct fingerprints or more than 10 Server headers. That pattern can signal a honeypot, which is a decoy device set up to watch attackers.
Delivery happens in stages. A short command first plants a small loader. The loader checks the device's processor type and fetches a matching client. Loader names run four to seven characters, so they fit in cramped input fields.
CloudSEK says each injection point tries every delivery method in turn: nc, wget, curl, TFTP, FTP and raw TCP. Character limits and egress controls can silently break any one chain. So the operators do not bet on one.
For MikroTik routers, the tooling centres on CVE-2023-30799. The script signs in through the WebFig interface as admin with an empty password. It then sends a crafted payload. CloudSEK adds that the engine learns which credentials work and ranks them for later use.
The file that matters most
CloudSEK calls the most unusual item not code but a document, WATCHER-BRIEF.md. It says the document runs the botnet like a site reliability team. Its first line reads: "This is the CONTEXT the watcher carries. It is not a dumb cron."
The brief sets a repeating monitoring cycle. When output falls, effort moves to target families that convert better. Exhausted families are swapped out.
If three cycles in a row produce nothing, the system sends one top-priority instruction to the keeper. CloudSEK says the sessions were tied to LLM tooling. Which AI tool the attacker used is unknown.
This operation shows attackers can run campaigns with a feedback loop, not only a toolkit. The operators track a path from scan to login to validation, and they tune it. Many defenders count alerts. This operation counted yield.
One case does not show how common this is. The source describes a single operation.
Where the evidence stops
CloudSEK is careful about limits, and readers should be too. A log of three attempts against RouterOS 6.48.6 recorded two timeouts and one bad result. It showed no beacons. The tooling is confirmed, but successful use of that branch is not.
The final client's control protocol and tasking are not in the recovered files. CloudSEK says the full command-and-control behaviour is unconfirmed. The cleanup stage does not prove every change is reversed.
What to ask your team
Start with inventory. Which routers, cameras, Jenkins, Openfire, Tomcat and ActiveMQ servers face the internet? Does any MikroTik device run RouterOS 6.48.6, one of the versions in the research? Is it patched against CVE-2023-30799? Does any device still accept the admin user with an empty password?
Then check outbound traffic. The delivery chains need devices to fetch files from outside. CloudSEK lists 45.90.13[.]169 as a payload server. Ask whether your network would flag a router or server pulling a binary from an unfamiliar address.
This attacker built a feedback loop and treated devices as a pipeline. The defence is the same discipline turned around: know what you expose, and watch what it does.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: CloudSEK.
