BPFDoor: El Backdoor de Linux Detrás de la Brecha de SK Telecom (Y Lo Que Tu Servidor No Puede Ver)

Leí el post-mortem de SK Telecom y lo primero que hice fue abrir una terminal y correr un comando en nuestro worker de Railway. No porque pensara que estábamos comprometidos. Sino porque me di cuenta de que nunca había verificado eso antes — y eso ya es un problema.

SK Telecom es la empresa de telecomunicaciones más grande de Corea del Sur. En abril de 2025, confirmaron una brecha que expuso datos USIM de aproximadamente 27 millones de usuarios. El vector de ataque inicial todavía está bajo investigación, pero el malware encontrado en sus servidores Linux fue BPFDoor — una herramienta que lleva años en circulación, atribuida a actores de amenaza de estado-nación, y que la mayoría de los setups de monitoreo convencionales simplemente no detectan.

El nombre te dice algo: BPFDoor. Usa BPF — Berkeley Packet Filter — para mantenerse activo sin abrir ningún puerto. Sin conexiones salientes. Sin procesos que llamen la atención. Si trabajas en backend y corres servidores Linux, esto te importa más de lo que crees.

Qué es BPF y por qué un backdoor lo usa

BPF — hoy conocido como eBPF en su versión extendida — es un mecanismo dentro del kernel de Linux que permite a los programas adjuntar código directamente al stack de red. Es la misma tecnología detrás de tcpdump, Wireshark, y herramientas modernas de observabilidad como Cilium.

La idea original era simple: en vez de copiar todo el tráfico de red al espacio de usuario para analizarlo, BPF te deja ejecutar pequeños programas de filtrado dentro del kernel, antes de que las aplicaciones siquiera vean los paquetes. Más eficiente, más rápido, menos overhead.

Eso lo hace extremadamente poderoso. Y extremadamente atractivo para un backdoor.

Un programa BPF opera por debajo del stack de red estándar. Antes de que tu firewall procese el tráfico. Antes de que tus reglas de iptables entren en juego. Antes de que cualquier proceso de espacio de usuario vea el paquete. Si adjuntas un filtro BPF malicioso al kernel, puedes monitorear pasivamente todo el tráfico que pasa por la interfaz de red — y actuar sobre él — sin abrir un solo puerto.

Así es exactamente como funciona BPFDoor.

Cómo funciona BPFDoor realmente

La mayoría del malware es ruidoso. Abre un puerto. Hace una conexión saliente. Crea un proceso con nombre raro. BPFDoor hace lo contrario — está diseñado para ser invisible dentro de un servidor comprometido.

Sin puerto de escucha. Corres ss -tulpn o netstat -tlnp y no ves nada sospechoso. BPFDoor no necesita un puerto porque no escucha conexiones TCP o UDP de la manera convencional. En vez de eso, usa un filtro BPF que monitorea el tráfico de red pasivamente a nivel de kernel.

Suplantación de proceso. Cuando ves la lista de procesos con ps aux, BPFDoor aparece con un nombre legítimo — típicamente algo como httpd, sshd, o udevd. Cualquier cosa que no llame la atención en un servidor Linux. Esta técnica se llama process name spoofing y es trivial de implementar a nivel de código.

El magic packet. El atacante envía un paquete especialmente diseñado a la máquina comprometida. Puede ir por cualquier protocolo — TCP, UDP, o incluso ICMP. BPFDoor tiene un filtro BPF adjunto al kernel que está revisando pasivamente todo el tráfico en busca de este paquete específico. Cuando lo detecta, se activa.

Activación y reverse shell. Una vez activado, BPFDoor puede abrir una shell hacia el atacante, ejecutar comandos, o establecer un túnel cifrado. Todo esto sucede después de recibir el magic packet — lo que significa que no hay tráfico anómalo saliente hasta que el atacante decide actuar.

La secuencia completa se ve así:

Atacante                    Servidor comprometido
   │                                │
   │── magic packet ──────────────>│  (kernel lo intercepta via filtro BPF)
   │                                │  BPFDoor se activa
   │<─── reverse shell ────────────│  (ahora hay conexión saliente)
   │                                │
   │  ejecuta comandos              │
   │  exfiltra datos                │

No hay actividad observable entre la instalación y la activación. El servidor puede estar comprometido por meses — y en el caso de SK Telecom, probablemente lo estuvo — sin que nadie lo note.

Por qué tus herramientas de monitoreo no lo ven

Esto es lo que más me preocupa cuando lo analizo desde una perspectiva de builder.

La mayoría de nosotros tenemos alguna capa de seguridad. Un antivirus, logs de acceso, quizás alertas de CloudWatch o Datadog para anomalías. Esas herramientas están diseñadas para amenazas que operan de una manera que asumimos como normal: procesos que abren puertos, conexiones que salen hacia IPs desconocidas, archivos que aparecen en directorios sensibles.

BPFDoor evade cada una de esas capas deliberadamente:

El AV tradicional no lo ve. El antivirus escanea firmas en archivos del disco y comportamiento conocido. BPFDoor puede residir en memoria, suplanta procesos del sistema, y opera en una capa (el kernel) donde el AV convencional no tiene visibilidad. ESET y Trend Micro publicaron análisis en 2022 detallando exactamente cómo evade la detección — y el malware seguía activo años después.

Los escaneos de puertos no lo encuentran. nmap, ss, netstat — ninguno muestra BPFDoor porque genuinamente no tiene un puerto de escucha abierto. No es que se esté ocultando del escáner. Es que la premisa del escáner ("busca puertos abiertos") no aplica.

Los logs de red son inútiles hasta la activación. Si solo estás buscando tráfico saliente sospechoso, no vas a ver nada hasta que el atacante decida actuar. Para entonces ya llegaron, exfiltraron lo que necesitaban, y probablemente ya se fueron.

Los listados de procesos son engañosos. Ver httpd en ps aux no te dice nada si el proceso real de Apache también está corriendo. Un administrador razonable asume que el nombre de proceso es legítimo.

Si tu modelo de seguridad depende exclusivamente de "busco cosas raras en logs y escaneos de puertos", BPFDoor no es raro para tus herramientas. Es invisible.

Qué significa esto si corres servidores Linux

Quiero ser directo: si corres un servidor de producción en Linux — ya sea en AWS, Railway, DigitalOcean, o cualquier VPS — esto te aplica. No como hipótesis de threat modeling empresarial. Como realidad operativa.

Algunos puntos concretos:

El vector de entrada no es BPFDoor. BPFDoor es el payload persistente que queda después de que el atacante ya entró. La entrada inicial fue otra vulnerabilidad — probablemente una app web, credenciales expuestas, o una dependencia comprometida. Eso sí está dentro del alcance de lo que tú puedes controlar con buenas prácticas de código.

La ventana de exposición puede ser enorme. SK Telecom tardó meses en detectar la brecha. BPFDoor está diseñado exactamente para eso: persistencia larga sin actividad ruidosa. Si no tienes detección a nivel de kernel, no sabes cuánto tiempo llevas comprometido.

Los servidores de infraestructura son el objetivo real. No tu app de Next.js directamente — sino el servidor Linux donde corre tu worker, tu base de datos, tu cola de mensajes. Son esos los que BPFDoor infecta.

Después de leer el análisis de SK Telecom, corrí esto en nuestro worker de Railway:

# Enumerar todos los programas BPF cargados en el kernel
bpftool prog list

Encontré solo programas BPF internos del kernel — herramientas del sistema operativo, nada inesperado. Pero la parte incómoda es que nunca lo había verificado antes. No sabía qué era normal. No tenía una baseline.

Esa es exactamente la trampa: no es que no sepas si tienes BPFDoor. Es que no sabes qué debería verse "normal" en tu servidor para poder detectar cuando algo cambia.

Data Hogo escanea tu código, no tu kernel — pero asegurar la capa de aplicación es el primer paso para que los atacantes no lleguen al servidor. Escaneo gratis, sin tarjeta.

Herramientas que realmente detectan amenazas a nivel de kernel

No voy a decirte que hay una solución perfecta. Pero hay herramientas que elevan tu capacidad de detección significativamente respecto a tener solo un AV tradicional y logs de red.

# Verificar bindings de sockets inesperados (usar ss, no netstat)
ss -tulpn
 
# Habilitar regla de auditd para registrar actividad de syscall BPF
auditctl -a always,exit -F arch=b64 -S bpf -k bpf_activity
 
# Revisar los logs de auditd para actividad BPF
ausearch -k bpf_activity

El primero no va a encontrar BPFDoor directamente — porque ya explicamos que no tiene puertos abiertos. Pero establece una baseline de qué procesos escuchan en qué puertos, y cualquier cambio es una señal.

auditctl sí puede capturar cuando un proceso carga un programa BPF via syscall, que es exactamente lo que BPFDoor hace al instalarse. No te dice que es malicioso — te dice que algo cargó BPF, y puedes investigar cuál proceso fue.

Falco es probablemente la opción más accesible para la mayoría. Es un proyecto CNCF, corre como daemon en Linux, y tiene reglas preconfiguradas para detectar comportamiento anómalo de procesos y syscalls. No es perfecto — necesita que instales kernel headers y las reglas generan ruido si no las afinas — pero es infinitamente mejor que nada.

Cilium Tetragon es más poderoso pero más complejo. Si ya usas Kubernetes y Cilium como CNI, Tetragon se integra y te da visibilidad profunda de eventos de proceso y red a nivel eBPF-nativo. Para setups más simples puede ser demasiado.

osquery es útil para construir una baseline. Puedes ejecutar queries SQL contra el estado de tu sistema — procesos activos, conexiones de red, programas BPF cargados — y programar esas queries para detectar cambios. No es tiempo real, pero es mucho mejor que revisar manualmente.

La lección real: profundidad de detección, no solo parches

El análisis técnico de BPFDoor es fascinante, pero la lección operativa para builders es más simple.

La seguridad en capas no es un cliché. Es la única defensa real contra amenazas como BPFDoor. Una capa protege la entrada (tu código, tus dependencias, tus configuraciones). Otra protege el runtime del servidor. Otra monitorea el comportamiento anómalo. Cuando una capa falla — y alguna siempre falla — las otras la compensan.

No saber qué es normal es tan peligroso como no tener seguridad. Corrí bpftool prog list en nuestro worker después de leer sobre SK Telecom. Encontré cinco programas BPF. ¿Son legítimos? Sí, son del kernel. ¿Cómo lo sé? Los busqué. ¿Lo sabía antes de buscarlo? No. Ese gap entre "tengo servidores corriendo" y "sé qué estado normal se ve en esos servidores" es donde los atacantes viven.

El vector de entrada importa. BPFDoor no apareció mágicamente en los servidores de SK Telecom. Alguien entró primero — probablemente a través de una vulnerabilidad en una aplicación, credenciales comprometidas, o una dependencia con una falla conocida. Esas son exactamente las cosas que se pueden prevenir con buenas prácticas en la capa de aplicación.

Si tu código tiene secretos expuestos, dependencias sin parchear, o configuraciones inseguras — eso es la puerta que abre el camino al resto. Cerrar esa puerta no te protege de todo, pero elimina la clase de vectores de entrada más comunes.

Desde que estamos escaneando repos en Data Hogo, el patrón más consistente que vemos es que las brechas no empiezan con exploits sofisticados de kernel. Empiezan con un API key en el código, una dependencia con CVE conocido, o una regla de RLS mal configurada. Cosas simples. Cosas que se pueden detectar y arreglar antes de que alguien llegue lo suficientemente adentro como para deployar BPFDoor.

TL;DR

• BPFDoor es el malware de Linux encontrado en los servidores de SK Telecom después de la brecha que expuso datos USIM de 27 millones de usuarios.
• Usa Berkeley Packet Filter para monitorear el tráfico de red pasivamente a nivel de kernel — sin abrir puertos, sin conexiones salientes, sin procesos con nombres raros.
• Tu AV no lo detecta. Tus escaneos de puertos no lo encuentran. Tus logs de red no muestran nada hasta que el atacante actúa.
• Para detectarlo necesitas herramientas a nivel de kernel: bpftool prog list, auditd con reglas de syscall BPF, Falco, o Cilium Tetragon.
• BPFDoor no es el vector de entrada — es lo que queda después de que alguien ya entró. El vector inicial son vulnerabilidades de aplicación: secretos expuestos, dependencias sin parchear, configuraciones inseguras.
• Cerrar la puerta de entrada — la capa de código y configuración — es lo que está dentro de tu control directo como developer.
• Revisa bpftool prog list en tus servidores Linux y establece una baseline de qué es normal. Si nunca lo has hecho, hoy es un buen momento.