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.

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

Term	Definition
Firmware	Software permanently stored in device hardware (flash memory, EEPROM) controlling low-level device operations and boot process
UEFI (Unified Extensible Firmware Interface)	Modern system firmware replacing legacy BIOS; provides boot services, runtime services, and a modular driver architecture
SPI Flash	Serial Peripheral Interface flash memory chip storing UEFI/BIOS firmware; can be read and modified for persistence
Secure Boot	UEFI feature verifying digital signatures of boot components to prevent unauthorized code execution during startup
SquashFS	Read-only compressed filesystem commonly used in embedded Linux firmware for space-efficient storage
Bootkit	Malware infecting the boot process (MBR, VBR, UEFI) to load before the operating system and evade OS-level security
Firmware Emulation	Running extracted firmware in a virtual environment (QEMU, firmadyne) to analyze behavior without physical hardware

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

Verification Criteria

Confirm successful execution by validating:

• [ ] All prerequisite tools and access requirements are satisfied
• [ ] Each workflow step completed without errors
• [ ] Output matches expected format and contains expected data
• [ ] No security warnings or misconfigurations detected
• [ ] Results are documented and evidence is preserved for audit

Compliance Framework Mapping

This skill supports compliance evidence collection across multiple frameworks:

• SOC 2: CC7.2 (Anomaly Detection), CC7.4 (Incident Response)
• ISO 27001: A.12.2 (Malware Protection), A.16.1 (Security Incident Management)
• NIST 800-53: SI-3 (Malicious Code Protection), IR-4 (Incident Handling)
• NIST CSF: DE.CM (Continuous Monitoring), RS.AN (Analysis)

Claw GRC Tip: When this skill is executed by a registered agent, compliance evidence is automatically captured and mapped to the relevant controls in your active frameworks.

Deploying This Skill with Claw GRC

Agent Execution

Register this skill with your Claw GRC agent for automated execution:

# Install via CLI
npx claw-grc skills add performing-firmware-malware-analysis

# Or load dynamically via MCP
grc.load_skill("performing-firmware-malware-analysis")

Audit Trail Integration

When executed through Claw GRC, every step of this skill generates tamper-evident audit records:

• SHA-256 chain hashing ensures no step can be modified after execution
• Evidence artifacts (configs, scan results, logs) are automatically attached to relevant controls
• Trust score impact — successful execution increases your agent's trust score

Continuous Compliance

Schedule this skill for recurring execution to maintain continuous compliance posture. Claw GRC monitors for drift and alerts when re-execution is needed.