Look, based on the Black Lotus Labs reporting and cross-referencing with other sources, here's my breakdown across your four areas.
1. Modular Architecture vs BPFdoor
The "rootkit-like" label is vendor marketing. From the technical details available, Showboat uses a hide command that fetches code from Pastebin dead drops — likely via LD_PRELOAD hijacking or /proc manipulation. That's fundamentally different from BPFdoor, which actually implants eBPF programs into the kernel and activates only when triggered by crafted packets.
The modular loader appears to use dlopen() for shared objects or memfd_create + execve for in-memory ELF execution. Core capabilities — SOCKS5 proxy, LAN scanning, remote shell — are built-in, not dynamically loaded. The Pastebin retrieval is the stealth play: pulling shellcode from external sites avoids static detection entirely.
Compared to BPFdoor: BPFdoor is kernel-level, portless, and packet-triggered. Showboat is userland, persistent, and C2-connected. Different threat models entirely. BPFdoor is for deep, silent access. Showboat is for post-exploitation activity after you're already inside.
2. IOCs and Detection Signatures
The Black Lotus Labs report is frustratingly light on hard IOCs. What I can extract:
- File names: Masquerades as
kworker (legitimate kernel thread name)
- Network: C2 infrastructure traced to Chengdu, China
- Behavioral: HTTPS connections to Pastebin for code retrieval
- Process: Creates processes with names matching legitimate system services
For detection, focus on:
- Memory artifacts from in-memory ELF loading
- Unusual
kworker processes with network connections
- HTTPS traffic to Pastebin from server processes
LD_PRELOAD activity on production Linux systems
YARA rules should target the loader stub and any hardcoded Pastebin URLs or decryption routines. Memory scanning is your best bet — the disk footprint is minimal by design.
3. Telecom-Specific TTPs
The victimology tells the story: Afghanistan ISPs, Azerbaijan telecom, potential US/Ukraine targets. These aren't random.
Once inside, they're doing:
- LAN scanning and lateral movement — the malware can "scan and infect LAN devices without direct internet connectivity." That's critical for air-gapped or segmented telecom infrastructure.
- SOCKS5 proxying — pivoting through compromised hosts to reach deeper network segments
- Credential and file access — standard espionage, but in telecom that means subscriber databases, billing systems, lawful intercept interfaces
The four-year evasion window makes sense when you look at the targeting. Telecom networks are complex, Linux-heavy, and notoriously under-monitored compared to Windows endpoints. The kworker process name blending is simple but effective — how many SOC analysts are scrutinizing kernel thread names on Linux servers?
4. Why 4 Years of Evasion?
Three factors:
First, Linux blind spots. Most enterprise security stacks are Windows-centric. Linux servers in telecom infrastructure often run with minimal endpoint detection.
Second, legitimate process masquerading. kworker is a real kernel thread. Seeing it in process lists doesn't trigger alerts. The malware lives in plain sight.
Third, Pastebin for code retrieval. This is actually clever — instead of embedding malicious code in the binary, it fetches from external sites. Static analysis of the binary shows minimal suspicious content. The malicious payload only exists in memory after retrieval.
The JFMBackdoor Windows companion suggests this is a cross-platform operation — they adapt the implant to whatever OS the target environment runs. That's disciplined tradecraft, not opportunistic crimeware.
Bottom line: This is a mature, modular post-exploitation framework purpose-built for long-term persistence in telecom networks. The four-year run isn't surprising — it's exactly what happens when you target Linux infrastructure with Windows-centric detection tools.