Mirai Botnet Analysis: Deep Dive into System Calls
What is Mirai?
Mirai is a self-propagating botnet malware that primarily targets IoT devices running Linux. It gained notoriety for launching massive DDoS attacks and compromising millions of IoT devices worldwide by exploiting default credentials and vulnerabilities.
# Typical Mirai infection vector
telnet <target_ip>
# Login attempts with default credentials:
# admin:admin, root:xc3511, root:vizxv, etc.
The Story of Mirai
Originally discovered in 2016, Mirai became infamous for taking down major internet services including Twitter, Netflix, and Reddit through coordinated DDoS attacks. The malware spreads by scanning for vulnerable IoT devices, infects them, and adds them to a botnet controlled by command and control (C2) servers.
Timeline:
2016-08 → First Mirai attacks detected
2016-09 → Major DDoS against KrebsOnSecurity (620 Gbps)
2016-10 → Dyn DNS attack takes down Twitter, Netflix, Reddit
2016-10 → Mirai source code leaked on Hackforums
String Analysis Findings
During static analysis, several questionable strings were discovered embedded within the malware binary. These strings provide insight into the malware author's mindset and potential targeting preferences:
These embedded strings suggest the malware may contain additional functionality or targeting logic beyond the standard Mirai capabilities observed in the dynamic analysis.
System Call Analysis: A Journey Through Mirai's Execution
Process Initialization & Setup
Process Identification
getpid() -> returns current process ID
getppid() -> returns parent process ID (3887)
Resource Limits Configuration
ugetrlimit() -> queries stack size limits
setrlimit() -> reduces stack size from 8MB to 2MB
This unusual stack size reduction suggests memory optimization for embedded IoT devices.
Signal Handling Setup
rt_sigaction() -> sets up SIGPWR (signal 32) handler
rt_sigprocmask() -> blocks certain signals
The use of SIGPWR (power failure signal) is particularly interesting - this signal is rarely used in normal programs and likely serves as a custom communication mechanism or anti-debugging technique.
Memory Management
// Heap expansion observed
brk(0x8065000) = 0x8065000 // New heap boundary
// EAX: 0x8065000 (134631424)
The malware performs dynamic memory allocation, expanding its heap space as needed.
Network Operations
; Socket creation and immediate closure
socketcall(SYS_SOCKET) = 3 ; Creates socket descriptor 3
close(3) = 0 ; Immediately closes socket
; EAX: 0x3 → 0x0 (success)
This quick socket open/close pattern suggests network capability testing or fingerprinting.
Time-Based Operations
// Timestamp collection
time(NULL) = 1755178257 // 0x689de511
times(&tms_buf) = 429663940 // 0x199c26c4
Critical Observation: The malware uses time-based execution control, suggesting it operates on scheduled intervals or waits for specific time conditions before activating.
Process Forking Behavior
fork() -> creates child process with PID 5489 (0x1571)
Key Debugging Point: As you can see, Mirai uses fork()
at this critical juncture, spawning a child process with PID 5489. Use this PID to attach GDB to debug the child process - this is where the main malicious activity typically occurs.
Process Enumeration & System Reconnaissance
The malware systematically scans running processes by reading /proc/[PID]/cmdline
files:
Target Process Discovery:
-
/proc/1595/cmdline
- Initial process scanning -
/usr/bin/pipewire-pulse
- Audio service -
/usr/bin/dbus-daemon
- System message bus -
/usr/bin/gnome-keyring-daemon
- Credential management -
/usr/libexec/xdg-document-portal
- Document access service -
/usr/libexec/xdg-permission-store
- Permission management -
/usr/libexec/gdm-wayland-session
- Display manager session -
/usr/libexec/gnome-session-binary
- GNOME session manager -
/usr/libexec/gcr-ssh-agent
- SSH key management -
/usr/bin/gnome-shell
- Desktop environment
Pattern Analysis: The malware specifically targets GNOME desktop environment processes, suggesting it's designed to operate on Linux desktop systems rather than just embedded IoT devices.
Data Extraction Methodology
Each process enumeration follows this pattern:
# Pattern observed in GDB trace
open("/proc/1595/cmdline", O_RDONLY) = 4
read(4, "/usr/bin/pipewire-pulse\0", 4096) = 24
close(4) = 0
open("/proc/1596/cmdline", O_RDONLY) = 4
read(4, "/usr/bin/dbus-daemon\0--config-file...", 4096) = 106
close(4) = 0
GDB Debugging Technique:
# Set breakpoint on read syscalls
(gdb) catch syscall read
# When stopped, examine EBP register contents
(gdb) x/s $ebp
# Extract strings automatically with:
(gdb) python print(gdb.execute("x/s $ebp", to_string=True))
C2 Communication Indicators
The time-based operations combined with network socket creation suggest the malware communicates with its C2 server (103.19.163.174) using time-synchronized protocols:
# Observed communication pattern
C2_SERVER = "103.19.163.174"
timestamp = 0x689de511 # 1755178257
# Time-based authentication logic
if current_time >= target_timestamp:
connect_to_c2(C2_SERVER)
send_heartbeat()
The specific timestamp checking indicates it may:
-
Wait for specific time windows to connect
-
Use time as part of its authentication mechanism
-
Coordinate attacks based on synchronized timing
Key Technical Insights
-
Anti-Analysis Features: The signal handling and stack size manipulation suggest anti-debugging capabilities
-
System Profiling: Extensive process enumeration indicates the malware profiles its environment before execution
-
Time-Based Execution: The temporal controls suggest coordinated botnet behavior
-
Desktop Targeting: Process targeting reveals adaptation for desktop Linux environments
Conclusion
This Mirai variant demonstrates sophisticated system reconnaissance capabilities, using process enumeration to understand its execution environment. The time-based controls and C2 communication patterns reveal a well-orchestrated botnet architecture designed for coordinated attacks.
For researchers: Focus your analysis on the forked child process (PID 5489) and monitor the time-based execution triggers to understand the full attack lifecycle.
IOC
0dad0cc96ea8239f5e5c15a7b1e01db862c1bb93bf01d551324309ea1b628e9b/