BPFDoor: The Linux Backdoor Behind the SK Telecom Breach (And What Your Server Can't See)

I read the SK Telecom post-mortem and the first thing I did was open a terminal on our Railway worker. I ran one command I'd never thought to run before. The output was clean — but the fact that I'd never checked was the uncomfortable part.

SK Telecom is South Korea's largest mobile carrier. In April 2025, they disclosed a breach that exposed USIM data — SIM card authentication credentials — for approximately 27 million subscribers. The attacker had been inside their infrastructure for an extended period before anyone noticed. What kept them invisible wasn't a zero-day in a web app. It was a piece of BPFDoor malware that hides inside the Linux kernel itself.

BPFDoor has no open network port. It spoofs the name of a legitimate system process. Traditional antivirus doesn't see it. And there's a real chance the monitoring tools you're running right now don't either.

What is BPF, and why does a backdoor use it?

BPF stands for Berkeley Packet Filter. It's a kernel subsystem originally designed in 1992 to let tools like tcpdump and Wireshark capture network packets efficiently.

The key word is "kernel." BPF doesn't operate at the application layer where your web server lives. It operates below everything — before your firewall rules, before your app code, before your logging middleware even touches a packet.

When you run tcpdump -i eth0, you're attaching a BPF filter to a network interface. The kernel gives that filter access to every packet flowing through the interface. It's fast, it's precise, and it's been in Linux for three decades.

Modern Linux extended this with eBPF (extended BPF), which powers tools like Cilium, Datadog's network monitoring, and Cloudflare's DDoS mitigation. It's a legitimate, heavily-used feature of the kernel — and that legitimacy is exactly what makes it so useful as an attack surface.

BPFDoor weaponizes the original BPF mechanism. Instead of capturing packets for diagnostics, it uses BPF to passively read all network traffic and watch for a specific signal from the attacker — without opening any port of its own.

How BPFDoor actually works

Here's the sequence without the threat-analyst jargon.

Step 1 — Installation. The attacker gets initial access through a vulnerability, a stolen credential, or a misconfigured service. They drop the BPFDoor binary, give it a process name that looks like a system daemon, and set it to persist across reboots.

Step 2 — Passive listening. BPFDoor attaches a BPF filter to the server's network interface. It reads all incoming traffic at the kernel level. No new port opens. From the outside, nothing changed.

Step 3 — Waiting for the magic packet. The attacker sends a specially crafted packet — a magic packet containing a specific byte sequence that BPFDoor recognizes. This packet can arrive on any port, even one your firewall blocks for regular connections. BPFDoor intercepts it before firewall rules apply.

Step 4 — Activation. When BPFDoor sees the magic packet, it opens a reverse shell or executes commands encoded in the packet. Your server starts talking outbound to the attacker's infrastructure.

Step 5 — Going quiet. Between activations, there's no outbound connection, no anomalous traffic, nothing to flag. The attacker can wait days or weeks between sessions without leaving a trace.

The result: persistent, reactivatable access to your server with no visible footprint during idle periods. No listening port. A process named httpd or sshd. No network connection to block until it's already too late.

Why your monitoring tools don't see it

This is the part that matters most for most developers. Let's go through what you're probably running and what it actually covers.

netstat and ss -tulpn show you which ports have active listeners. BPFDoor has no listening port, so it doesn't appear. You run ss -tulpn, everything looks normal, and you move on. That check just failed silently.

ps aux shows you running processes. BPFDoor spoofs a legitimate process name — httpd, sshd, udevd, whatever fits the environment. You see a familiar name, your brain pattern-matches it as expected, you don't investigate further. A process list check also just failed silently.

Traditional antivirus scans files on disk against known signatures. BPFDoor can be packed, obfuscated, and modified between deployments. More importantly, AV has no visibility into which BPF programs are loaded at the kernel level. It's looking in the wrong place.

Log-based SIEM and application logging only capture what applications choose to report. BPFDoor operates below the application layer. It doesn't touch your app, doesn't write to your logs. If your SIEM ingests Nginx access logs and application events, it has zero visibility into kernel-level activity.

Cloud provider security dashboards — AWS GuardDuty and similar — are largely network-traffic-anomaly-based. They might flag the outbound connection when BPFDoor activates. But the idle-state implant is invisible here too.

This isn't a failure of these tools. They do exactly what they were designed to do. The problem is assuming they cover everything.

What this means if you run Linux servers

SK Telecom had a full security team. They had monitoring infrastructure. The attacker still had extended dwell time — meaning they were inside, undetected, long enough to exfiltrate USIM data for 27 million subscribers.

The lesson isn't "their team was incompetent." The lesson is that BPFDoor specifically targets the gap between what most organizations monitor and what's actually happening at the kernel level. That gap exists at SK Telecom-scale. It also exists on your Railway worker and your $20/month VPS.

Am I saying you're about to get hit by a nation-state APT? No. BPFDoor is associated with sophisticated, targeted attackers — not opportunistic script kiddies. The direct probability for a small project is low.

But the techniques spread. Commodity malware eventually adopts what advanced malware pioneered. The kernel-level evasion playbook that BPFDoor uses today will show up in more common attack toolkits in the coming years. And the honest question isn't "am I being targeted by the same group that hit SK Telecom?" It's "do I know what layer my monitoring covers, and am I honest about what it doesn't?"

One layer worth covering before anything else: your application code. Exposed secrets, unpatched dependencies, and misconfigured auth are the most common initial access vectors — and that's where BPFDoor's journey starts. An attacker who can't get in through your code can't install anything. Data Hogo scans your repos for exactly those issues — free, no card needed.

Commands that actually help

After reading the SK Telecom post-mortem, I ran these on our own infrastructure. Here's what they do and what they don't.

List all loaded BPF programs:

# Shows every BPF program currently loaded in the kernel
# On a clean server, you'll see only kernel-internal entries
# An unexpected user-space entry here is a red flag
bpftool prog list

On our Railway worker, I got back a handful of kernel-internal programs — the kind Linux loads for its own housekeeping. No unexpected entries. But I'd never run this command before. That's the part that bothered me: I had no idea what was normal.

Check socket bindings — use ss, not netstat:

# -t: TCP  -u: UDP  -l: listening  -p: show process  -n: no DNS lookup
# ss is the modern replacement for netstat — more accurate on current kernels
ss -tulpn

This won't catch BPFDoor (no open port), but it's your baseline. Know what's supposed to be listening. Anything unexpected is worth investigating.

Enable kernel-level auditing for BPF syscalls:

# Log every use of the bpf() syscall — the call that loads BPF programs
# -a always,exit: log on syscall exit, always
# -F arch=b64: 64-bit syscalls only
# -S bpf: target the bpf syscall
# -k bpf_activity: tag these events for easy filtering
auditctl -a always,exit -F arch=b64 -S bpf -k bpf_activity

This tells auditd to log every time anything calls the bpf() syscall — the call used to load a BPF program. If BPFDoor loads after this rule is active, you'll have a record. You need auditd running and this rule made persistent via /etc/audit/rules.d/.

Check for process name spoofing — compare process names against actual binary paths:

# A process named "sshd" should run from /usr/sbin/sshd
# If it's running from /tmp or a home dir, investigate immediately
ls -la /proc/*/exe 2>/dev/null | grep -v "Permission denied"

A familiar process name pointing to /tmp/something or a home directory is a serious red flag.

Tools that actually catch kernel-level threats

Here's an honest comparison of what's available:

Falco is the realistic starting point for most independent developers. It's open source, runs as a daemon, and ships with rules that catch common attack patterns — unexpected processes spawning shells, connections to unusual IPs, BPF program loads outside of known tools. The learning curve is real but manageable.

Cilium Tetragon is more powerful but more infrastructure. If you're on Kubernetes, evaluate it seriously. If you're on a single VPS, start with Falco.

auditd is already on most Linux systems. The problem is nobody configures it. The BPF syscall rule above is a concrete starting point that costs nothing and takes ten minutes.

The honest answer: there's no tool that gives you perfect kernel-level visibility without operational cost. The goal isn't perfection. It's raising your detection floor.

The real lesson: detection depth, not just patching

Most developers have a mental model of security that goes roughly: patch dependencies, use HTTPS, don't expose your .env, enable 2FA. That covers a lot. It doesn't cover this.

BPFDoor represents a threat category that operates beneath the layer where most security advice lives. The attacker doesn't exploit a CVE in your application. They get in through something else — a phishing credential, an exposed management port, a supply chain compromise — and then they drop something your monitoring was never designed to see.

The SK Telecom breach didn't happen because developers wrote bad code. It happened because the attacker found a foothold, deployed a tool that evaded their monitoring stack, and had time to operate before anyone noticed.

The practical implication: understand what your defenses actually cover — concretely, not theoretically.

Application logs capture app-layer events. Network monitoring captures traffic anomalies, usually only on outbound connections. File integrity monitors catch changes to files they were configured to watch. None of those cover kernel-level BPF program loads. That's not a reason to panic. It's a reason to be specific about what you're relying on and what you're not.

A server with auditd configured with a BPF syscall rule and Falco running is meaningfully more defensible than one running only a WAF and an app-layer SIEM. You don't need to replicate SK Telecom's security team. You need to stop assuming your current tools cover layers they were never designed to cover.

Start with your application layer — that's where most attackers get initial access. Then work down. One layer at a time.

TL;DR

• BPFDoor malware uses the Berkeley Packet Filter — the same kernel subsystem as tcpdump — to passively intercept traffic with no open network port.
• It spoofs legitimate process names like httpd or sshd and waits silently for a "magic packet" before activating a reverse shell.
• The SK Telecom breach exposed USIM data for 27 million subscribers. BPFDoor's kernel-level evasion gave the attacker extended, undetected dwell time.
• netstat, ps aux, and traditional AV don't see it. They're not broken — they're looking at the wrong layer.
• Run bpftool prog list and enable auditd BPF syscall logging as a baseline. It's free and takes ten minutes.
• Falco is the realistic open source option for runtime behavioral detection on Linux servers.
• The lesson isn't panic — it's precision: know exactly what your monitoring covers and be honest about what it doesn't.
• Your application code is still the most common initial access vector. Lock that down first. Scan your repo with Data Hogo →