Qué es un backdoor: tipos, ejemplos reales y métodos de detección

Un backdoor es un mecanismo oculto que permite a un atacante acceder a un sistema saltando los controles de autenticación normales. No depende de credenciales válidas, no aparece en los flujos de login auditados y, bien implementado, ni siquiera es visible para los administradores legítimos. Es la pieza que convierte un compromiso puntual en presencia persistente: el atacante entra una vez, planta el backdoor y vuelve cuando quiere sin volver a explotar nada.

Esta guía explica qué es un backdoor, en qué se diferencia de un troyano o un rootkit, los siete tipos en investigaciones forenses (software, firmware, hardware, criptográfico, supply chain, cuenta, código fuente), casos públicos documentados (SolarWinds Sunburst, NotPetya, XZ Utils), su encaje en MITRE ATT&CK y qué medidas de detección y hardening funcionan en entornos corporativos en 2026.

Lo esencial

• Un backdoor es cualquier mecanismo (código, configuración, cuenta o hardware) que permite acceso saltando los controles de autenticación oficiales.
• No siempre es malware: puede ser una cuenta olvidada, una clave SSH residual o un servicio sin documentar.
• Los tipos relevantes para la defensa son siete: software, firmware, hardware, criptográfico, supply chain, cuenta y código fuente.
• Casos públicos documentados (SolarWinds, NotPetya, XZ Utils) muestran que el canal de distribución firmado no es garantía de integridad.
• La detección requiere EDR con behavioral baselines, SIEM con queries específicas y threat hunting periódico; ningún antivirus por firma resuelve esto en solitario.

Qué es un backdoor: definición técnica precisa

Un backdoor es cualquier mecanismo (código, configuración, hardware o credencial) que permite acceder a un sistema o servicio evitando los controles de autenticación y autorización previstos. El término viene del desarrollo: en los años setenta y ochenta era habitual que programadores dejasen una "puerta trasera" en sistemas grandes para depurar sin pedir credenciales nuevas. El caso documentado más conocido es la trusting trust attack de Ken Thompson en su discurso de Turing de 1984, donde mostró cómo un compilador podía contener un backdoor invisible incluso en su código fuente.

La distinción legítimo frente a malicioso depende del contexto. Un backdoor introducido por un desarrollador con fines de mantenimiento, sin documentación ni rotación de credenciales, es un riesgo aunque la intención inicial fuera benigna. En la práctica forense la diferencia es irrelevante: si existe un canal de acceso oculto que no pasa por los controles oficiales, es un backdoor.

Los backdoors no son malware en sentido estricto. Pueden serlo (un implante de troyano deja un backdoor de tipo RAT), pero también pueden ser una cuenta de administrador olvidada, una clave SSH en authorized_keys, un servicio escuchando en un puerto alto o un certificado de firma robado. Lo común es la propiedad funcional: acceso sin pasar por la puerta legítima.

Cómo se instala un backdoor

Los vectores se repiten:

• Phishing más dropper. El usuario ejecuta un adjunto o enlace, el dropper despliega el backdoor y configura persistencia.
• Supply chain. El atacante compromete a un proveedor y el backdoor llega firmado por el canal legítimo.
• Insider. Empleado o contratista con acceso introduce el backdoor de forma deliberada antes de salir.
• Compromiso de firmware. Modificación de BIOS, UEFI, BMC o firmware de periféricos por interdicción física o vulnerabilidades de actualización.
• Post-explotación. Tras un compromiso por exploit (web shell, RCE en un servicio interno, abuso de credenciales), el atacante deja el backdoor como mecanismo de retorno antes de retirarse del sistema visible.

El patrón en auditorías post-incidente es que el backdoor inicial no es el más sofisticado. El atacante deja varios mecanismos redundantes (cuenta nueva, tarea programada, servicio, clave SSH, web shell) para que la respuesta defensiva limpie unos y deje otros activos.

Tipos de backdoor

Backdoor en software

La categoría más común. Incluye RAT (Remote Access Trojan), web shells, módulos maliciosos cargados por aplicaciones legítimas y bibliotecas troyanizadas. Un web shell típico es un fichero PHP, ASPX o JSP subido a un servidor vulnerable que recibe comandos por HTTP y los ejecuta con los privilegios del proceso web. Familias documentadas: China Chopper, Behinder, Godzilla.

Los RAT incluyen control remoto interactivo (shell, file manager, captura de pantalla) y son la base de muchas campañas APT. La detección con EDR es razonable si el RAT toca disco o red observablemente, pero variantes en memoria, con abuso de procesos (process hollowing, reflective loading) o C2 cifrado sobre HTTPS son más difíciles.

Persistencia típica: claves Run, tareas programadas, servicios Windows, cron jobs, LaunchAgents en macOS, hooks WMI.

Backdoor en firmware

Implantes en BIOS, UEFI, BMC, firmware de discos o de tarjetas de red. La ventaja para el atacante es radical: sobreviven a reinstalación del sistema operativo, a cambio de disco si el implante está en BIOS, y operan por debajo del nivel donde se ejecutan antivirus y EDR.

Casos documentados públicamente: LoJax (atribuido a APT28, 2018), MoonBounce (2022) y MosaicRegressor (2020). La detección requiere herramientas específicas como CHIPSEC (Intel), análisis de hash de firmware y atestación de plataforma con TPM y Measured Boot. Superficie pequeña, impacto alto, remediación difícil sin sustitución física.

Backdoor en hardware

Modificaciones físicas: chips añadidos a placas base, cables USB con microcontrolador (USB Rubber Ducky, O.MG Cable), implantes en periféricos. El caso más mediático fue la denuncia de Bloomberg en 2018 sobre chips en placas Supermicro, rechazada por las empresas implicadas y nunca confirmada técnicamente en público.

Lo que sí está documentado son los catálogos NSA filtrados en 2013 (programa ANT) con implantes para interceptación de teclado, exfiltración por radiofrecuencia y modificación de firmware. La detección requiere análisis físico (rayos X, comparación con muestras de referencia) y solo es viable en entornos con modelo de amenaza específico.

Backdoor criptográfico

El más sutil: una implementación criptográfica deliberadamente débil que parece correcta a inspección superficial pero permite recuperar claves o predecir salidas. El caso académicamente más estudiado es Dual_EC_DRBG, generador de números aleatorios estandarizado por NIST con parámetros que, conocidos por un atacante, permitían predecir su salida. NIST lo retiró en 2014.

La kleptografía es la disciplina formal: técnicas para implantar backdoors en sistemas criptográficos de forma que la salida siga siendo indistinguible de la correcta sin la clave maestra. La defensa: implementaciones auditadas, parámetros verificables (brainpoolP256r1 frente a curvas opacas) y diversificación de entropía.

Backdoor en supply chain

El atacante compromete a un proveedor cuya actualización legítima llega firmada a miles de clientes. El caso paradigmático es SolarWinds Sunburst en 2020. Otros documentados: NotPetya (M.E.Doc, 2017), CCleaner (2017), ASUS Live Update (2019) y XZ Utils (2024).

La defensa pasa por controles de supply chain de software: SBOM, firma reproducible, atestación de build (SLSA), monitorización post-instalación y segmentación de red para software actualizado recientemente.

Backdoor en cuenta

Una cuenta legítima creada o modificada por el atacante para mantener acceso. En Active Directory: cuenta nueva en Domain Admins, golden ticket Kerberos, ACL sobre AdminSDHolder, delegación constrained mal configurada, máquina con SPN propiedad del atacante. En Linux: usuario UID 0 con nombre poco llamativo, clave SSH en authorized_keys, sudoers modificado.

Uno de los backdoors más infravalorados porque no hay binario malicioso, solo configuración, y los antivirus no lo detectan. La defensa: auditoría continua de cuentas privilegiadas, alertas sobre creación de cuentas y cambios de membresía, revisión de claves SSH y sudoers.

Backdoor en código fuente

Commits maliciosos en repositorios open source o internos. El atacante introduce código que parece legítimo (refactor, fix, optimización) pero contiene una vulnerabilidad funcional o funcionalidad oculta. El caso XZ Utils en 2024 es el ejemplo más estudiado: un contribuidor introdujo durante años commits útiles para ganar confianza y, en una versión concreta, código que permitía bypass de autenticación SSH a quien tuviera la clave correcta.

La defensa: revisión de código rigurosa, firmas en commits, restricciones sobre quién puede aprobar y mergear cambios en ramas protegidas, análisis estático sobre patrones sospechosos (manipulación de tablas de funciones, evaluación dinámica de strings) y diversidad de revisores. Un commit aprobado por una sola persona en un proyecto crítico es un riesgo estructural.

Casos públicos relevantes

SolarWinds Sunburst (2020). Atacantes comprometieron el sistema de build de SolarWinds e insertaron código malicioso en una versión de Orion Platform. La actualización, firmada legítimamente, se distribuyó a miles de organizaciones. Sunburst contactaba a un dominio C2 y, en objetivos seleccionados, descargaba payloads adicionales. La investigación pública atribuyó la operación a APT29.

NotPetya (2017). Presentado como ransomware, operaba como wiper. Vector inicial: compromiso de la actualización de M.E.Doc, software de contabilidad usado en Ucrania. El daño económico estimado en informes públicos fue uno de los más altos atribuidos a un único incidente cibernético hasta esa fecha.

XZ Utils (2024). Un contribuidor con identidad probablemente falsa introdujo durante meses commits útiles en XZ Utils. En las versiones 5.6.0 y 5.6.1 introdujo código que, cargado por sshd a través de liblzma, permitía bypass de autenticación a quien tuviera la clave privada correcta. Un ingeniero de Microsoft detectó el comportamiento por una diferencia de latencia y reportó el hallazgo antes de que las versiones afectadas llegaran a distribuciones estables ampliamente desplegadas.

Lo que comparten: la confianza en el canal de distribución (build firmado, repositorio oficial, mantenedor reputado) fue la palanca. Ninguno se habría evitado solo con antivirus, EDR o firewalls.

Encaje con MITRE ATT&CK

Los backdoors aparecen en varias técnicas de MITRE ATT&CK:

• T1505 Server Software Component. Sub-técnicas como Web Shell (T1505.003), Transport Agent (T1505.002), IIS Components (T1505.004). Cubre backdoors plantados sobre servidores legítimos abusando de sus extensiones.
• T1542 Pre-OS Boot. Implantes en bootkit, firmware (BIOS, UEFI), bootloader, component firmware. LoJax, MoonBounce y similares encajan aquí.
• T1556 Modify Authentication Process. Modificación del proceso de autenticación para aceptar credenciales mágicas o saltar comprobaciones: Domain Controller Authentication (T1556.001), Pluggable Authentication Modules (T1556.003), Network Provider DLLs (T1556.008).

Otras técnicas asociadas: T1078 Valid Accounts, T1136 Create Account, T1098 Account Manipulation, T1547 Boot or Logon Autostart Execution.

Detección con EDR, SIEM y threat hunting

La detección de backdoors no se resuelve con una firma. Lo que funciona es combinar varias capas:

Behavioral baselines. Un EDR bien configurado alerta sobre comportamientos anómalos: svchost abriendo conexión a un dominio no reputado, lsass escribiendo a disco, servicio Windows creado fuera de ventana de cambio, modificación de claves de registro de persistencia.

Indicadores típicos:

• Cuentas creadas fuera del proceso de provisioning.
• Modificaciones de authorized_keys, sudoers, /etc/pam.d/.
• Servicios escuchando en puertos altos no documentados.
• Tareas programadas con triggers inusuales (logon, idle, evento específico).
• Tráfico saliente a dominios sin reputación fuera de horario.
• Procesos firmados con líneas de comando atípicas (rundll32 con exports inusuales, PowerShell encoded).
• Binarios firmados modificados (hash distinto del catálogo).

Queries útiles en SIEM para alertas o threat hunting periódico:

• Eventos 4720 (creación de cuenta) y 4732 (adición a grupo privilegiado) en controladores de dominio fuera de horario.
• Eventos 7045 (instalación de servicio) con ServiceFileName apuntando a rutas temporales.
• Procesos hijo de w3wp.exe, httpd, nginx ejecutando cmd, powershell, sh, bash.
• Modificación de runkeys en HKLM\Software\Microsoft\Windows\CurrentVersion\Run y equivalentes HKCU.
• Conexiones salientes desde procesos del sistema (lsass, winlogon, services) a IPs externas.

Network analytics. Patrones de beaconing (intervalo constante), DNS tunneling, uso de protocolos legítimos para C2 (HTTPS sobre CDN, DoH a resolvers públicos). Zeek, Suricata y EDR con telemetría de red dan visibilidad básica; el análisis serio requiere baseline propio.

Prevención y hardening

Code signing y supply chain controls. Firma de todos los binarios y artefactos internos, verificación obligatoria antes de ejecución, SLSA como marco de niveles de garantía de build, sigstore o equivalentes para firmas verificables. SBOM por artefacto desplegado y monitorización contra vulnerabilidades conocidas.

MFA hardware-backed. Llaves físicas FIDO2 para cuentas privilegiadas, evitando MFA por SMS o aplicaciones que el atacante pueda interceptar (phishing, SIM swap). Cuentas de administrador de dominio: hardware key obligatorio sin excepciones.

Secure Boot y attestation. Habilitar Secure Boot, configurar Measured Boot y atestación remota con TPM 2.0 para detectar cambios en firmware o bootloader. En entornos sensibles, atestación contra servicio centralizado en cada arranque.

Threat hunting periódico. Ejercicios mensuales o trimestrales buscando indicadores documentados, no solo esperando alertas. Revisar cuentas privilegiadas, persistencia, modificación de autenticación, beaconing.

Segmentación de red. Limitar movimiento lateral. Si un backdoor entra en un endpoint, segmentación efectiva impide alcanzar controladores de dominio, sistemas de build o repositorios sin controles adicionales.

Hardening de pipelines CI/CD. Pipelines aislados, secretos rotados, builds reproducibles, revisión humana obligatoria sobre cambios críticos, integridad de runners.

Diferencia con malware genérico, rootkit y RAT

Un mismo implante puede ser varias cosas. Un RAT tras explotación deja backdoor; un rootkit suele contener backdoor. La distinción importa para describir el incidente, no como categorías exclusivas.

Preguntas frecuentes

Un backdoor siempre es malware

No. Puede ser una cuenta de administrador olvidada, una clave SSH añadida con buena intención y nunca rotada, un servicio de mantenimiento sin documentar. Lo que define al backdoor es su propiedad funcional (acceso saltando controles), no su origen.

El gobierno puede exigir backdoors

Depende de jurisdicción y de cómo se interprete la legislación de interceptación legal. La posición técnica de la comunidad criptográfica es estable: un backdoor accesible a una autoridad legítima es matemáticamente accesible a quien obtenga la clave por otros medios. No existe diseño conocido que garantice acceso solo a un actor confiable manteniendo el sistema seguro frente al resto.

Se puede detectar backdoor en firmware

Sí, pero requiere herramientas específicas: CHIPSEC para BIOS/UEFI Intel, comparación de hash contra valores del fabricante, atestación con TPM y Measured Boot. No es algo que un antivirus convencional cubra.

Qué hago si encuentro un backdoor

Contener (aislamiento de red, no apagar para preservar memoria), preservar evidencia (memoria, disco, logs), identificar alcance, erradicar todos los mecanismos de persistencia (suelen ser varios), rotar credenciales y secretos comprometidos, hacer retesting para confirmar erradicación completa.

Open source es seguro frente a backdoors

No automáticamente. XZ Utils demuestra que un atacante paciente puede ganar acceso a proyectos open source si la base de mantenedores es pequeña. La ventaja del open source es que la auditoría es posible; convertir esa posibilidad en seguridad efectiva requiere que alguien audite con rigor, algo que solo ocurre en proyectos críticos con financiación adecuada.

Retesting tras eliminar backdoor

Imprescindible. La erradicación parcial es uno de los errores más caros en respuesta. Un atacante competente deja varios mecanismos redundantes. El retesting debe incluir búsqueda activa de los mismos TTPs, revisión de cuentas privilegiadas, validación de integridad de binarios y firmware y, si el incidente fue serio, monitorización reforzada durante meses.

Recursos relacionados

• Tipos de malware: clasificación y ejemplos reales
• Qué es MITRE ATT&CK: tácticas y técnicas
• Qué es threat hunting: metodología y ejemplos
• Qué es EDR: detección y respuesta en endpoint
• Ataques a la cadena de suministro de software y DevSecOps
• Qué es un troyano: tipos y eliminación
• Qué es un CVE y cómo se gestionan las vulnerabilidades

Threat hunting y respuesta con Secra

En Secra hacemos auditoría post-incidente cuando un equipo defensivo sospecha que un compromiso ha dejado backdoors persistentes y necesita verificación independiente. Incluye threat hunting retrospectivo sobre telemetría disponible (EDR, SIEM, logs de red), revisión de cuentas privilegiadas y mecanismos de autenticación, búsqueda activa de los TTPs del incidente y validación de erradicación.

También trabajamos hardening de supply chain: pipelines CI/CD, controles de firma e integridad, segmentación de la red de build, planes de respuesta ante compromiso de proveedor.

Si tu organización ha sufrido un incidente reciente o necesita validar que no quedan accesos residuales, contacta con nosotros para una primera evaluación.