Performing Firmware Malware Analysis

Performing Firmware Malware Analysis

When to Use

• A compromised IoT device or router needs firmware analysis to identify implanted backdoors
• Investigating UEFI/BIOS rootkits that persist across OS reinstallations
• Analyzing firmware updates for supply chain compromise or malicious modifications
• Extracting and examining embedded Linux filesystems from IoT device firmware images
• Verifying firmware integrity after a suspected hardware or firmware-level compromise

Do not use for standard operating system malware; use PE/ELF analysis tools for OS-level malware on conventional systems.

Detection Gaps & Validation

• The #1 miss is analyzing vendor firmware instead of the device's actual flash. A clean image from the vendor site won't show the implant. Dump the live chip via UART/JTAG or SPI programmer (flashrom), and compare its hash against the vendor baseline — a mismatch is the starting point, not the conclusion.
• binwalk -e silently fails on encrypted/proprietary regions. A flat high-entropy band in binwalk -E (entropy ~0.99 with no recognized signatures) means encryption or a custom packer, not random padding. Look for the bootloader's decrypt routine, or dump the decrypted filesystem from RAM on a running device.
• Modifications hide outside the main rootfs. Backdoors live in the bootloader env (fw_printenv), NVRAM/config partitions, the second (backup) bank of dual-bank flash, and trojanized shared libraries (.so) that hook legitimate binaries — not just /etc/init.d/rcS.
• UEFI implants need the right lens. Carve modules with UEFITool/UEFIExtract, diff DXE drivers against a clean dump, and run chipsec for SPI lock / BIOS write-protect / Secure Boot state. LoJax/MoonBounce/CosmicStrand modify specific modules (e.g., CORE_DXE) rather than adding obvious files.
• Emulation gaps cause false negatives: firmadyne/FAT often can't bring up NVRAM-dependent services, so a backdoor that only listens after full boot looks absent. Confirm findings statically (Ghidra on the suspect ARM/MIPS binary) rather than trusting an emulated run.
• Benign-lookalike FPs: vendor debug/telnet daemons, hardcoded support credentials, and BusyBox nc are common in legitimate firmware — confirm intent via the binary's actual call-out target before flagging.

Prerequisites

• binwalk installed for firmware image analysis and extraction (pip install binwalk)
• Ghidra with ARM/MIPS architecture support for embedded binary reverse engineering
• UEFI Tool (UEFITool) for UEFI firmware parsing and analysis
• Firmware Analysis Toolkit (FAT) or EMBA for automated firmware analysis
• QEMU for emulating extracted firmware filesystems
• Cross-compilation toolchains for ARM, MIPS, and other embedded architectures

Workflow

Step 1: Extract and Identify Firmware Components

Analyze the firmware image structure and extract filesystems:

# Identify embedded filesystems and compressed data
binwalk firmware.bin

# Extract all identified components
binwalk -e firmware.bin

# Recursive extraction with signature scanning
binwalk -eM firmware.bin

# Output typically includes:
# - Bootloader (U-Boot, GRUB, custom)
# - Kernel image (Linux, RTOS)
# - Root filesystem (SquashFS, JFFS2, CramFS, ext4)
# - Configuration data
# - Digital signatures or checksums

# Entropy analysis to find encrypted or compressed regions
binwalk -E firmware.bin

# Identify specific filesystem types
file _firmware.bin.extracted/*

# For SquashFS filesystems
unsquashfs _firmware.bin.extracted/squashfs-root.img
ls squashfs-root/

Step 2: Analyze the Extracted Filesystem

Search for malicious modifications in the firmware filesystem:

# Directory structure analysis
find squashfs-root/ -type f | head -50

# Search for suspicious files
find squashfs-root/ -name "*.sh" -exec ls -la {} \;
find squashfs-root/ -perm -4000 -type f  # SUID binaries
find squashfs-root/ -name "*.so" -newer squashfs-root/bin/busybox  # Modified libraries

# Check startup scripts for backdoors
cat squashfs-root/etc/init.d/rcS
cat squashfs-root/etc/inittab
ls -la squashfs-root/etc/rc.d/

# Search for hardcoded credentials
grep -rn "password\|passwd\|secret\|key\|token" squashfs-root/etc/ 2>/dev/null
grep -rn "root:" squashfs-root/etc/shadow 2>/dev/null

# Check for unauthorized SSH keys
find squashfs-root/ -name "authorized_keys" -exec cat {} \;

# Network configuration backdoors
cat squashfs-root/etc/hosts
grep -rn "iptables\|nc\|netcat\|ncat" squashfs-root/etc/ squashfs-root/usr/bin/

# Check for reverse shells in cron
find squashfs-root/ -name "crontab" -o -name "cron*" | xargs cat 2>/dev/null

# Identify all ELF binaries for analysis
find squashfs-root/ -type f -exec file {} \; | grep ELF

Step 3: Reverse Engineer Suspicious Binaries

Analyze extracted binaries that may be backdoors:

# Identify architecture and format
file squashfs-root/usr/bin/suspicious_binary

# Extract strings for IOC discovery
strings squashfs-root/usr/bin/suspicious_binary | grep -iE "http|ip|port|shell|connect|exec"

# Cross-reference against known firmware binaries
# Compare SHA-256 hashes with known-good firmware
sha256sum squashfs-root/usr/bin/* > current_hashes.txt
# diff against baseline: diff baseline_hashes.txt current_hashes.txt

# Import into Ghidra for disassembly (select correct architecture)
# ARM:   ARM/AARCH64 (Little Endian for most IoT devices)
# MIPS:  MIPS/MIPS64 (Big or Little Endian depending on device)
# x86:   For UEFI modules

# Analyze with radare2 for quick triage
r2 -A squashfs-root/usr/bin/suspicious_binary
# Commands: afl (function list), pdf @main (disassemble main), iz (strings)

Step 4: UEFI/BIOS Firmware Analysis

Analyze system firmware for bootkits and implants:

# Extract UEFI firmware volumes with UEFITool
# GUI: UEFITool -> File -> Open -> Select firmware.rom
# CLI: UEFIExtract firmware.rom

# Analyze UEFI firmware with chipsec (requires hardware access)
python chipsec_main.py -m common.bios_wp     # BIOS write protection
python chipsec_main.py -m common.spi_lock     # SPI flash lock
python chipsec_main.py -m common.secureboot   # Secure Boot status
python chipsec_main.py -m common.uefi.s3bootscript  # S3 resume script

# Dump UEFI firmware from live system
python chipsec_util.py spi dump firmware_dump.rom

# Compare with known-good firmware
sha256sum firmware_dump.rom
# Compare against vendor-provided firmware hash

# Scan for known UEFI malware signatures
yara -r uefi_malware_rules.yar firmware_dump.rom

Known UEFI Malware Families:
━━━━━━━━━━━━━━━━━━━━━━━━━━
LoJax:         First in-the-wild UEFI rootkit (APT28/Fancy Bear)
               Modifies SPI flash to drop persistence agent
MosaicRegressor: Modular UEFI framework dropping multiple payloads
CosmicStrand:  UEFI firmware rootkit modifying kernel during boot
BlackLotus:    UEFI bootkit bypassing Secure Boot on Windows 11
ESPecter:      ESP (EFI System Partition) bootkit modifying boot manager
MoonBounce:    SPI flash implant modifying CORE_DXE module
FinSpy UEFI:  Surveillance software with UEFI persistence

Step 5: Emulate Firmware for Dynamic Analysis

Run extracted firmware in an emulated environment:

# Emulate ARM-based IoT firmware with QEMU
# Mount the extracted filesystem
sudo mount -o loop squashfs-root.img /mnt/firmware

# Chroot into the firmware with QEMU user-mode emulation
sudo cp /usr/bin/qemu-arm-static /mnt/firmware/usr/bin/
sudo chroot /mnt/firmware /bin/sh

# Or use firmadyne for automated firmware emulation
# https://github.com/firmadyne/firmadyne
python3 fat.py firmware.bin

# Network service analysis within emulated firmware
# Scan for open ports and services
nmap -sV localhost -p 1-65535

# Monitor network traffic from emulated firmware
tcpdump -i tap0 -w firmware_traffic.pcap

Step 6: Document Firmware Analysis

Compile comprehensive firmware analysis findings:

Analysis documentation should cover:
- Firmware image metadata (vendor, model, version, build date)
- Extraction results (filesystem type, kernel version, architecture)
- Modified files compared to known-good baseline
- Backdoor binaries discovered with reverse engineering findings
- Hardcoded credentials and unauthorized access mechanisms
- Network services and their security posture
- UEFI/BIOS integrity verification results
- Extracted IOCs (IPs, domains, file hashes, SSH keys)
- Remediation recommendations (reflash, replace, update)

Key Concepts

Tools & Systems

• binwalk: Firmware analysis tool for scanning, extracting, and analyzing embedded file systems and compressed data in firmware images
• UEFITool: Open-source UEFI firmware image parser and extractor for analyzing UEFI volumes, modules, and drivers
• chipsec: Intel's open-source framework for platform security assessment including SPI flash, Secure Boot, and UEFI analysis
• firmadyne: Automated firmware analysis and emulation platform for Linux-based embedded devices
• Ghidra: NSA's reverse engineering tool with ARM, MIPS, and other embedded architecture support for firmware binary analysis

Common Scenarios

Scenario: Investigating a Compromised Router with Persistent Backdoor

Context: A network router continues to exhibit suspicious behavior (unexpected DNS resolutions, traffic to unknown IPs) even after factory resets. Firmware-level compromise is suspected.

Approach:

1. Dump the firmware from the router using JTAG/UART debug interface or vendor management tools
2. Extract the filesystem with binwalk and identify the Linux distribution and kernel version
3. Compare file hashes against known-good firmware image from the vendor
4. Search startup scripts (rcS, inittab, crontab) for backdoor entries
5. Analyze any modified or new binaries with Ghidra (ARM/MIPS architecture)
6. Check for hardcoded credentials, unauthorized SSH keys, and reverse shell scripts
7. Emulate the firmware to observe network behavior and identify C2 communication

Pitfalls:

• Not dumping firmware from the actual device (downloading from vendor site gives clean version, not the compromised one)
• Ignoring modified shared libraries (.so files) that may hook system functions
• Missing firmware modifications stored outside the main filesystem (bootloader, configuration partitions)
• Not checking both the primary and backup firmware partitions (some devices have dual-bank flash)

Output Format

FIRMWARE MALWARE ANALYSIS REPORT
===================================
Device:           NetGear R7000 Router
Firmware Version: V1.0.11.116 (modified)
Architecture:     ARM (Little Endian)
Filesystem:       SquashFS (Linux 3.4.103)
Dump Method:      UART debug console

INTEGRITY CHECK
Vendor Firmware Hash:  aaa111bbb222... (clean V1.0.11.116)
Analyzed Firmware Hash: ccc333ddd444... (MISMATCH)
Modified Files:        14 files differ from vendor baseline

BACKDOOR FINDINGS
[!] /usr/bin/httpd_backdoor (new binary, not in vendor firmware)
    Architecture: ARM 32-bit
    Function: Reverse shell to 185.220.101[.]42:4444
    Persistence: Added to /etc/init.d/rcS

[!] /etc/shadow modified
    Root password changed to known hash
    New user 'admin2' added with UID 0

[!] /etc/crontab modified
    Added: */5 * * * * /usr/bin/httpd_backdoor

[!] /root/.ssh/authorized_keys (new file)
    Contains attacker's SSH public key

EXTRACTED IOCs
C2 IP:            185.220.101[.]42
C2 Port:          4444
SSH Key:          ssh-rsa AAAA... attacker@control
Backdoor Hash:    eee555fff666...

REMEDIATION
1. Flash clean vendor firmware via TFTP recovery mode
2. Change all device credentials
3. Update to latest firmware version
4. Enable firmware integrity checking if available
5. Monitor for re-compromise indicators