Analyze malicious Linux ELF binaries — botnets, cryptominers, ransomware, and rootkits targeting Linux servers, containers, and cloud infrastructure — through static analysis, dynamic tracing, and reverse engineering of x86_64 and ARM samples. Use when investigating Linux malware, triaging a suspici

Analyzing Linux ELF Malware When to Use A Linux server or container has been compromised and suspicious ELF binaries are found Analyzing Linux botnets (Mirai, Gafgyt, XorDDoS), cryptominers, or ransomware Investigating malware targeting cloud infrastructure, Docker containers, or Kubernetes pods Reverse engineering Linux rootkits and kernel modules Analyzing cross platform malware compiled for Linux x86 64, ARM, or MIPS architectures Do not use for Windows PE binary analysis; use PEStudio, Ghidra, or IDA for Windows malware. Prerequisites Ghidra or IDA with Linux ELF support for disassembly and decompilation Linux analysis VM (Ubuntu 22.04 recommended) with development tools installed strace, ltrace, and GDB for dynamic analysis and debugging readelf, objdump, and nm from GNU binutils for static inspection Radare2 for quick binary triage and scripted analysis Docker for isolated container based malware execution Workflow Step 1: Identify ELF Binary Properties Examine the ELF header and basic properties: Step 2: Extract Strings and Indicators Search for embedded IOCs and functionality clues: Step 3: Analyze System Calls and Library Usage Identify what system calls and libraries the malware uses: Step 4: Dynamic Analysis with GDB Debug the malware to observe runtime behavior: Step 5: Reverse Engineer with Ghidra Perform deep code analysis on the ELF binary: Step 6: Analyze Linux Specific Persistence Check for persistence mechanisms: Key Concepts Term Definition ELF (Executable and Linkable Format) Standard binary format for Linux executables, shared libraries, and core dumps containing headers, sections, and segments Stripped Binary ELF binary with debug symbols removed, making reverse engineering more difficult as function names are lost LD PRELOAD Linux environment variable specifying shared libraries to load before all others; abused by rootkits to intercept system library calls strace Linux system call tracer that logs all system calls and signals made by a process, revealing file, network, and process operations GOT/PLT Global Offset Table and Procedure Linkage Table; ELF structures for dynamic linking that can be hijacked for function hooking Statically Linked Binary compiled with all library code included; common in IoT malware to run on systems without matching shared libraries Mirai Prolific Linux botnet targeting IoT devices via telnet brute force; source code leaked, leading to many variants Tools & Systems Ghidra : NSA reverse engineering tool with full ELF support for x86, x86 64, ARM, MIPS, and other Linux architectures Radare2 : Open source reverse engineering framework with command line interface for quick binary analysis and scripting strace : Linux system call tracing tool for observing binary behavior including file, network, and process operations GDB : GNU Debugger for setting breakpoints, examining memory, and stepping through Linux binary execution pyelftools : Python library for parsing ELF files programmatically for automated analysis pipelines Common Scenarios Scenario: Analyzing a Cryptominer Found on a Compromised Linux Server Context : A cloud server shows 100% CPU usage. Investigation reveals an unknown binary running from /tmp with a suspicious name. The binary needs analysis to confirm it is a cryptominer and identify the attacker's wallet and pool. Approach : 1. Copy the binary to an analysis VM and compute SHA 256 hash 2. Run file and readelf to identify architecture and linking type 3. Extract strings and search for mining pool addresses (stratum+tcp://) and wallet addresses 4. Run with strace in a sandbox to observe network connections (mining pool connection) 5. Import into Ghidra to identify the mining algorithm and configuration extraction 6. Check for persistence mechanisms (crontab, systemd service, SSH keys) 7. Document all IOCs including pool address, wallet, C2 for updates, and persistence artifacts Pitfalls : Running ldd on malware outside a sandbox (ldd can execute code in the binary) Not checking for ARM/MIPS architecture before attempting x86 64 execution Missing companion scripts (.sh files) that may handle persistence and cleanup Ignoring the initial access vector (how the miner was deployed: SSH brute force, web exploit, container escape) Output Format

analyzing-linux-elf-malware