Wire Report #2: They Gifted Us Some Malware to Decompile

Our honeypot captured 16 malware samples in one week. We unpacked, decompiled, and reverse-engineered them. Here's what's inside three active botnets — and what their source code reveals about how attacks actually work.

coauthored by Frank S. and Claude Opus 4.6
securityhoneypotwirectfreverse-engineeringmalware

Wire Report #2

Thanks for the Malware

Wire Report #1 covered the initial reconnaissance that attackers execute when landing in a new target. At the time, we were naive. Our Cowrie setup was vanilla — they sniffed us out from a mile away. Then we got smarter, personalized our fingerprint. Now they stick around long enough to attempt to infect us. Little do they know that they're effectively dropping their tradecraft right into our Petri dish.

Since our last update, we've captured 16 unique malware samples (85MB). Every file delivered via SCP through active SSH sessions. The following is how we took them apart and what was inside.

The Week in Numbers

| Metric | Count | |--------|-------| | Total events | 390,210 | | Unique sessions | 60,417 | | Successful logins | 20,575 | | Commands executed | 57,013 | | Unique attacker IPs | 1,586 | | Malware samples captured | 16 |

Top attacker: 129.212.180.68 with 15,782 events. Top password: 123456 at 4,888 attempts. 72% of all traffic came from SSH-2.0-Go scanners — the same automated botnets from Report #1, still grinding.

Three Campaigns

Every sample we captured belongs to one of three distinct operations.

1. mdrfckr — SSH Key Persistence

The simplest and most common. The mdrfckr name comes from a string literal in their tooling. They've been active since at least 2022. 450 deliveries in one week. The payload is an SSH public key:

cd ~ && rm -rf .ssh && mkdir .ssh && echo "ssh-rsa AAAA..." >> .ssh/authorized_keys

No binary, no malware in the traditional sense; just a key swap. The attacker deletes your authorized keys and plants their own, like changing the locks on your front door to fit theirs and swapping your garage code to one that only they know. Once installed, they own the box permanently — password changes don't matter, and the key survives reboots.

Attentive readers might be wondering why the botnet operates in such a scorched-earth kind of way. Would it not be stealthier to let you keep your keys, and simply append theirs for persistent access? I wondered the same thing. Here is Claude's explanation:

This type of tradecraft is a choice. They are trading longevity per-host for throughput across hosts. These kinds of scans hit the entire IPv4 space — 56K sessions in a week. Even if 95% get reimaged immediately, at this kind of scale, that's acceptable churn.

The second reason is because the botnet's primary threat isn't you — it's the next botnet. The same weak credentials that let mdrfckr in will let in Panchan, RedTail, and fifty others right behind them. They aren't worried about an attentive admin. This is a turf war.

What to learn: Persistence doesn't require sophisticated malware. A single echo command to .ssh/authorized_keys is enough. Monitor that file. Set it immutable with chattr +i if you can.

2. Panchan — Go P2P Worm

This is the most sophisticated sample we have collected so far. A 30MB Go binary with a peer-to-peer architecture. We ran Mandiant's GoReSym to extract the embedded metadata, then decompiled with Ghidra.

Build info recovered:

| Field | Value | |-------|-------| | Language | Go 1.18 | | Module | panchansminingisland/peernode | | Dependencies | 12 (crypto/ssh, crypto/tls, net/http, etc.) | | Functions recovered | 23 (main package) |

What it does:

In a single breath, this program simultaneously gains a foothold in your machine, kills competitors, starts mining crypto, and phones home. Details below.

  • Process deduplication. Tradecraft 101: get inside, then pull the ladder up behind you. Make sure you have exclusive access to the target's resources and plant your flag. main.killdup checks if other instances are already running and kills them.
  • SSH spreading. At any moment, the lights could go out. Panchan uses your newly infected target as a launchpoint for finding others. It reads /etc/passwd and ~/.ssh/known_hosts to find adjacent machines, then brute-forces them with a built-in credential list. Classic worm behavior.
  • Dual mining. Panchan would like to borrow your unused FLOPS for its portfolio, please. Your CPU and GPU are workers sitting idle, ripe for exploitation, as far as this botnet operator is concerned. There is no reason they can't be put to good use. As soon as it gains a foothold, Panchan immediately embeds its own custom configuration for both XMRig (Monero) and NBMiner (Ethereum). The rewards are paid out to the operator's wallet.
  • P2P command and control. There is no single point of failure to take down; peers communicate with one another on port 2210. The botnet distributes mining configs and credential lists across the mesh. To stop it, you would have to stamp out each individual infection.
  • Discord webhook C2. Interestingly, we found a hard-coded string in the binary that led to somebody's Discord server. This was probably the operator's user interface to see how his worm was doing — how many hosts it has infected, where they were, and how much crypto they were mining for him. We looked up the webhook — it's dead (Discord error 10015: Unknown Webhook). Whether Discord killed it or the operator burned it themselves, we can't tell. Either way, this particular C2 channel is dark.

Recovered Go type definitions:

type main.credential struct {
    Username string
    Password string
}
type main._rig_config struct {
    Pool    string
    Wallet  string
    // ...
}

GoReSym pulled these directly from the binary. Go embeds rich type information even in stripped builds — a gift to reverse engineers.

What to learn: Go is the language of choice for modern botnets. Static compilation means one binary runs everywhere with no dependencies. The embedded metadata means Go malware is also easier to analyze than C — if you know where to look.

3. RedTail — Weaponized XMRig

Another crypto miner. This time, there are different binaries for different architectures, a result of being written in C++ as opposed to Go. The following are the four that we caught.

| Binary | Arch | Packed Size | Unpacked Size | |--------|------|-------------|---------------| | redtail-x86_64 | x86_64 | 1.8 MB | 4.9 MB | | redtail-i686 | i686 | 1.7 MB | 5.0 MB | | redtail-arm7 | ARMv7 | 1.3 MB | 3.7 MB | | redtail-arm8 | AArch64 | 1.5 MB | 4.1 MB |

UPX is a legit tool built to solve a real problem. Programs can be large and unwieldy; UPX packages them cleanly for transport. Like a zipfile... or a vacuum sealer. Like any good tool, though, it can be dual-use. Malware authors love it because it is one more way to evade automated detection. It's not a get-out-of-jail-free card, but it's a low-effort, high-reward step that all serious malicious payloads consider, like putting on your seatbelt in the car. These instances of RedTail that fell into our web were packaged like this. upx -d unpacked them cleanly, revealing XMRig internals: RandomX and CryptoNight algorithms, donation pool addresses at donate.v2.xmrig.com, and libpcap compiled in for network sniffing.

RedTail ships with two shell scripts:

setup.sh — The dropper:

Detects CPU architecture


Finds a writable directory that isn't mounted noexec


Renames the binary to a random string


Executes it

The arch detection is thorough — it handles x86_64, i686, armv7l, and aarch64 — matching exactly the four binaries in the kit.

clean.sh — The competitor killer:

Stops c3pool_miner service


Kills competing mining processes


Scrubs crontabs of wget/curl/bash persistence entries

Before RedTail installs itself, it removes whoever was there first. The fact that we are seeing similar behavior with RedTail as we did with Panchan is telling. This is the botnet turf war in action. Your compromised server isn't serving one attacker — it's a contested resource being fought over by multiple operations.

What to learn: UPX packing is the first layer of obfuscation you'll encounter in real malware. Learn upx -d and file — they're your first moves in any analysis. Don't let a simple command hamstring your efforts to analyze a binary, like your dad disconnecting your car's battery so you can't sneak out this weekend. It's a one-step fix, and knowledge is power.

The Reverse Engineering Pipeline

The words "reverse-engineering" and "decompiling" used to scare me. However, somebody else already took care of the hard part, and now it's as simple as a few tool calls. Here's the toolchain:

1. file — Identify what you're looking at (ELF binary, shell script, etc.) 2. upx -d — Unpack UPX-compressed binaries 3. GoReSym — Extract metadata from Go binaries (module paths, function names with addresses, type definitions, build info) 4. Ghidra headless mode — Decompile to pseudo-C at scale. Use GoReSym output to map function addresses back to their original names.

These tools are complementary, not redundant. GoReSym gives you the map (what functions exist and where). Ghidra gives you the territory (what each function actually does). Together, they turn a stripped binary back into something approaching readable source code.

What Did We Learn?

All three campaigns shared a common theme: get in, stay in, and kick everybody else out. Additionally, they all got in with lazy credentials. No brute-force scripts, no complicated zero-days — just laziness. Default credentials, silly credentials, credentials bought off the darknet and traded amongst criminals... the lesson is clear. Use strong passwords and change them often. We have password managers, 2FA, and single sign-on — use them.

Another theme was crypto. It's a money game. Your resources are lying idle, and there is an ecosystem of automated botnets out there fighting more with one another than with their targets to gain access to them.

The attackers aren't sophisticated — they're automated. The malware isn't clever — it's persistent. And the defense isn't complicated — it starts with not using 123456 as your password.

See It Live

Type wire in the CLI-Games terminal to see the latest honeypot data.

Our honeypot intelligence is also available as an API — 15 endpoints covering events, sessions, attacker profiles, IOC feeds, and search. Details on RapidAPI.

Wire Report is a series analyzing real attack data from the CLI-Games honeypot. Report #1 covered the first 24 hours. This report covers the malware left behind. Want to try reverse engineering yourself? Start with CTF: Capture the Flag.