Wiz CTF #6: Malware Busters!

No flags are included in this writeup.

Overview

Malware Busters was a clean reverse-engineering challenge. Instead of cloud IAM or Kubernetes, the task was to analyze an odd binary from a compromised environment, understand its behavior, locate the C2 flow, and decrypt enough of the protocol to recover the secret.

First Look

The binary was a Go ELF with packing and obfuscation in the way. The first blocker was UPX. A normal unpack attempt failed because the packing markers had been intentionally damaged.

That is a good anti-analysis trick because it wastes time if you trust the tool output too much. The better approach was to inspect byte patterns and repair the corrupted UPX magic values before unpacking.

Once unpacked, the binary was much easier to reason about. Go binaries are still noisy, but strings and decompiler output started showing useful structure.

Config And Environment

The malware expected a specific runtime habitat. That mattered. Running or analyzing it outside the intended environment could hide behavior or produce misleading results.

The useful artifacts were:

• a hidden configuration file path
• crypto-related imports
• encoded or encrypted configuration values
• C2 communication logic
• sequence-based responses

After unpacking, I focused on the config path and the functions around config parsing. The malware used a simple layer before the C2 crypto, so reversing the config gave the C2 endpoint and key material needed for the next stage.

C2 Protocol

The C2 traffic was not plaintext. The solve required identifying the correct encryption mode and response structure.

The key analysis loop was:

1. unpack the binary
2. recover the config location
3. decode/decrypt the local config
4. identify the C2 URL and crypto parameters
5. query the C2 sequence endpoint
6. decrypt responses and inspect the commands

The important lesson was not to overcomplicate the cryptography. When a more complex mode or algorithm does not fit the observed data, step back and test the simpler explanation.

Root Cause

As a challenge, Malware Busters showed a realistic analyst workflow:

• packer tampering delayed automated unpacking
• Go symbol noise slowed static analysis
• environment checks hid behavior outside the target system
• encrypted config and C2 protocol required crypto validation
• the interesting response was buried among normal-looking command output

Takeaways

My main notes from this one:

• failed unpacking does not mean “not packed”
• corrupted packer signatures are easy to miss
• strings still matter after unpacking, even in obfuscated Go binaries
• config paths and environment checks are often faster leads than random function browsing
• C2 sequence anomalies are worth investigating

This challenge was a good reminder that reverse engineering is not just staring at a decompiler. It is hypothesis testing with the binary, filesystem, runtime, and network behavior all at once.