Qué es un honeypot: deception technology y detección de intrusos 2026

Un honeypot es un sistema o recurso deliberadamente vulnerable diseñado para atraer atacantes, registrar su actividad y permitir su detección temprana. No produce valor de negocio: cualquier interacción con él es sospechosa por construcción. Esa señal limpia lo convierte en una de las herramientas defensivas con mejor relación coste-eficacia cuando se despliega bien.

La deception technology es la evolución empresarial. En lugar de un servidor aislado, una plataforma siembra cebos creíbles por toda la red: cuentas falsas en Active Directory, ficheros con tracking embebido, claves AWS marcadas, endpoints simulados en VLANs internas. El atacante que se mueve acaba interactuando con uno de esos cebos y se delata antes de alcanzar activos reales.

Esta guía cubre tipos (low-interaction, high-interaction, pure, honeytokens), casos de uso, plataformas, encaje con MITRE Engage y MITRE Shield, y cómo plantear un despliegue sin convertir el honeypot en una vulnerabilidad propia.

Lo esencial

• Un honeypot es un sistema o recurso sin valor de negocio cuya única función es ser tocado por un atacante para generar señal de detección.
• Las cuatro categorías operativas son low-interaction, high-interaction, pure honeypots y honeytokens.
• El valor defensivo real está en la detección de movimiento lateral, insider threat y robo de credenciales, no en "estudiar al atacante".
• Thinkst Canary domina el mercado comercial; T-Pot, Cowrie y Dionaea son la base open source más extendida.
• MITRE Engage y MITRE Shield formalizan la deception como disciplina defensiva con técnicas catalogadas.
• Un honeypot mal segmentado se convierte en trampolín hacia la red real: la ubicación y el aislamiento importan tanto como el cebo.

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

Un honeypot es un recurso informático cuyo valor reside exclusivamente en ser sondado, atacado o comprometido. La definición clásica viene de Lance Spitzner con el Honeynet Project a principios de los 2000. No tiene usuarios legítimos, no expone servicios necesarios para el negocio y cualquier paquete que llegue es por definición anómalo.

Esa propiedad genera detección con muy bajo ratio de falsos positivos. Un SIEM corporativo recibe millones de eventos diarios y exige reglas complejas para destilar señal. Un honeypot dispara una alerta cuando alguien intenta autenticarse o lee un fichero marcado, y es accionable casi siempre.

Los honeypots de investigación buscan capturar malware y generar inteligencia para la comunidad. Los honeypots de producción, foco de esta guía, sirven para detección temprana dentro de una organización. Las arquitecturas y los proveedores difieren.

Honeypot vs honeynet vs deception platform

Honeypot. Un único sistema o recurso señuelo. Puede emular un servicio (SSH expuesto, página de login falsa) o ser un sistema completo aislado.

Honeynet. Una red de honeypots interconectados que simula un segmento corporativo. El Honeynet Project popularizó el término. En entornos empresariales la honeynet pura ha quedado relegada a investigación y red team interno; en producción ha sido sustituida en gran parte por plataformas de deception.

Deception platform. Producto comercial que despliega cebos distribuidos por toda la infraestructura: cuentas, ficheros, endpoints simulados, registros DNS, secretos en repositorios. Integra recolección de alertas, integración con SIEM y EDR, y mantenimiento automatizado de credibilidad. Thinkst Canary y, en su día, Illusive Networks o Cymmetria son ejemplos.

La diferencia operativa es la escala. Desplegar un honeypot aislado es un ejercicio de fin de semana. Mantener doscientos cebos creíbles repartidos por una red corporativa, sin que envejezcan ni generen falsos positivos por escaneos del propio equipo de IT, exige una plataforma o un equipo dedicado.

Tipos de honeypots

Low-interaction honeypots

Emulan servicios sin proporcionar un sistema operativo real. Un honeypot SSH low-interaction acepta conexiones, devuelve un banner convincente y simula un shell con respuestas preconfiguradas, pero no permite ejecutar comandos reales contra el host. Ejemplos: Cowrie en modo emulación, Dionaea, Honeyd.

Ventajas. Despliegue rápido, riesgo residual bajo, bajo consumo, fácil de replicar.

Limitaciones. Un atacante con experiencia detecta la emulación en minutos por respuestas estereotipadas y sistema de ficheros incompleto. Sirven para detectar escaneos automatizados, no para capturar TTPs de un actor avanzado.

High-interaction honeypots

Un sistema operativo real, con servicios reales, instrumentado para registrar toda actividad. El atacante obtiene un shell genuino y puede ejecutar binarios, modificar configuración, instalar malware. Cowrie en modo proxy hacia un contenedor real, máquinas virtuales en una honeynet o appliances comerciales encajan aquí.

Ventajas. Fidelidad muy alta, captura de TTPs reales, malware vivo, comportamientos post-explotación auténticos.

Limitaciones. Riesgo operativo significativo. Si el honeypot se compromete sin aislamiento estricto, el atacante puede pivotar hacia la red real o usarlo como punto de exfiltración. Exige segmentación rigurosa, monitorización continua y procedimientos de contención y reset.

Pure honeypots

Sistema completo en producción que parece operativo pero no presta servicio real. Servidor web con contenido plausible, base de datos cargada con registros generados, integración aparente con otros sistemas. Costoso de construir y mantener creíble, reservado a entornos con modelo de amenaza muy específico (banca, defensa, infraestructura crítica). Lo característico es que está pensado para resistir un análisis de coherencia, no solo una interacción superficial.

Honeytokens

No son sistemas sino recursos digitales marcados: una credencial AWS, una entrada en una tabla de base de datos, un fichero clientes.xlsx en un share, una URL embebida en una página interna, una cuenta Office 365 sin uso real, un registro DNS específico. Cualquier uso del recurso genera una alerta.

Ventajas. Coste mínimo, riesgo prácticamente nulo, detección de robo de credenciales y acceso no autorizado a datos, despliegue masivo trivial.

Limitaciones. Detectan uso, no intento. Y dependen de un canal de telemetría: la clave AWS marcada solo sirve si se consulta CloudTrail buscando su uso. Aun así, son la categoría con mejor ratio coste-detección en 2026 para organizaciones que aún no han desplegado deception completa.

Casos de uso defensivos donde aporta valor

Detección de movimiento lateral

Tras el compromiso inicial, el atacante hace reconocimiento interno: enumera shares, lista usuarios del dominio, escanea segmentos. Un honeypot en VLAN de servidores o cuentas señuelo en AD disparan alerta antes de que alcance bases de datos o DCs reales. El EDR detecta lo que pasa en endpoints, el honeypot lo que pasa entre ellos.

Insider threat early warning

Empleados con acceso legítimo que exploran más allá de su perímetro. Una cuenta señuelo donde el usuario no tiene motivos para estar, o un nominas_2025.xlsx en un share al que no debería acceder, generan señal sin monitorizar comportamiento general.

APT signaling

Atacantes avanzados invierten tiempo en reconocimiento. Honeytokens en repositorios de código, wikis y shares aumentan la probabilidad de que el atacante toque uno durante esa fase, a coste marginal bajo.

Credential theft detection

Un honeytoken en forma de clave AWS embebida en código, credencial RDP en connections.rdp o cuenta de servicio sin uso real es uno de los métodos más eficaces para detectar robo de credenciales por phishing, infostealer o compromiso de desarrollo. Cuando la credencial aparece usada desde una IP no esperada, la alerta es inequívoca.

Cloud honeypots

Plataformas como Thinkst Canary despliegan en cuentas cloud instancias que simulan buckets S3 con nombres atractivos (backups, customers-export), EC2 con servicios expuestos o Lambda. La detección de reconocimiento dirigido en cloud, donde el perímetro tradicional desaparece, es uno de los huecos donde la deception aporta más valor.

Plataformas y proveedores

Thinkst Canary. Dominante en el segmento empresarial. Appliances físicos y virtuales que simulan SMB, RDP, SSH, HTTP y bases de datos, más servicio gestionado de canary tokens. Bajo mantenimiento, integración SIEM, alertas accionables. Precio por número de canarios.

Illusive Networks. Plataforma de deception centrada en distorsionar la fase de reconocimiento. Adquirida por Proofpoint en 2023.

Cymmetria. Pionera en deception comercial con MazeRunner ("deception paths"). Cesó operaciones hace años; la mencionamos por contexto.

T-Pot. Distribución open source mantenida por Deutsche Telekom. Pila completa (Cowrie, Dionaea, Honeytrap, ConPot, Glastopf, ElasticPot y más) sobre Docker con Kibana. Punto de partida más rápido para investigación o piloto.

Cowrie. Honeypot SSH y Telnet, fork moderno de Kippo. Estándar de facto en exposición SSH.

Dionaea. Honeypot para servicios Windows (SMB, MSSQL, HTTP, FTP, TFTP). Útil para captura de malware de red.

HoneyDB. Servicio que agrega datos de honeypots distribuidos y publica indicadores. Más cerca de threat intel que de despliegue propio.

Canarytokens. Servicio gratuito de Thinkst para generar honeytokens (URLs, ficheros, claves AWS, DNS). Punto de entrada antes de adoptar un producto.

Honeytokens específicamente

Los honeytokens son la palanca más barata para introducir deception en una organización en 2026.

Claves AWS marcadas. Genera una clave con permisos nulos o restringidos a un bucket inexistente. Embédela en un repositorio interno, un fichero .env, un wiki o un share. Configura CloudTrail para alertar sobre cualquier llamada API hecha con esa clave. Detecta robo de repositorio, exfiltración por insider y compromiso de desarrollo.

Cuentas Office 365 o Google Workspace falsas. Cuentas con nombres atractivos (finanzas.admin, ceo.assistant) sin actividad real. Cualquier intento de login dispara alerta y captura phishing dirigido o reutilización de credenciales filtradas.

Documentos con tracking pixel. Un salarios_directivos.docx en un share interno con imagen embebida apuntando a un dominio controlado. Al abrir el documento, la petición HTTP llega al servidor de tracking con metadata (IP, hora, user agent).

Registros DNS canary. Subdominio específico (internal-backup.example.com) sin servicio real. Cualquier consulta llega a un resolver controlado y detecta enumeración interna y DNS tunneling.

Entradas en base de datos. Registros con datos ficticios pero verosímiles. Cualquier consulta o exportación que los devuelva indica acceso anómalo.

Honeyusers en Active Directory. Cuentas sin login real con descripciones plausibles. Cualquier autenticación, consulta de Kerberos o adición a grupos genera alerta. Combinado con detección de ataques Kerberos, da señal muy limpia de Kerberoasting o AS-REP Roasting dirigidos.

Cómo desplegar honeypot empresarial

Ubicación en la red. DMZ (reconocimiento externo), VLAN interna (movimiento lateral tras compromiso) y cloud (reconocimiento dirigido en cuentas IaaS). La opción con mejor relación valor-detección en entornos modernos es la interna: el perímetro está roto desde hace años.

Naming convincente. srv-backup-fin01, dc-aux02, db-payroll-old. Nombres que un atacante leería como objetivos. Evitar honeypot01 y respetar la convención de nombres de la organización.

Servicios coherentes con la VLAN. Un honeypot en VLAN Windows expone SMB y RDP; en VLAN Linux expone SSH; en DMZ expone HTTP. Servicios incoherentes levantan sospecha.

Aislamiento estricto. El honeypot no debe poder iniciar conexiones a la red real. Firewall que permite entrante pero bloquea saliente excepto a un servidor de logging dedicado. En high-interaction, contención adicional con sandboxing o NAT controlado.

Monitorización centralizada. Cualquier interacción se envía a SIEM con metadata (puerto, comando, hash). Alertas de prioridad alta: por construcción no hay falsos positivos sistemáticos.

Mantenimiento de credibilidad. Un honeypot sin cambios y sin parches con uptime de meses es detectable. Plataformas comerciales rotan configuración periódicamente; en despliegues caseros, reset trimestral.

Documentación interna. IT y SOC deben saber que existe para no responder a sus propias alertas como incidente real; el resto de la organización no. Si todo el mundo lo conoce, deja de ser honeypot.

Encaje con MITRE Engage y MITRE Shield

MITRE ATT&CK describe lo que hacen los atacantes. MITRE Engage y MITRE Shield describen lo que el defensor puede hacer en términos de deception.

MITRE Shield. Marco original publicado en 2020. Define tácticas defensivas (Channel, Collect, Contain, Detect, Disrupt, Facilitate, Legitimize, Test) y técnicas como Decoy Account (DTE0010), Decoy Content (DTE0011), Decoy Credentials (DTE0012), Decoy Network (DTE0014), Decoy System (DTE0017).

MITRE Engage. Sucesor formal de Shield, publicado en 2022. Estructura el ciclo en cinco objetivos: Prepare, Expose, Affect, Elicit, Understand. Define matrices de actividades y mapea cada una contra técnicas ATT&CK que pretende detectar o disrumpir.

Para una organización que despliega deception, mapear cada cebo contra técnicas Engage o Shield ayuda a articular el caso defensivo ante dirección. Un honeyuser en Active Directory cubre Decoy Account y se relaciona con T1078 Valid Accounts y T1110 Brute Force; un honeytoken AWS cubre Decoy Credentials y T1078.004 Cloud Accounts.

Riesgos y consideraciones legales

Pivoteo desde honeypot comprometido. Riesgo más serio en high-interaction. Si el atacante obtiene shell real y la segmentación falla, el honeypot se convierte en plataforma de ataque interno. Mitigación: aislamiento estricto, monitorización continua, kill switch ante actividad saliente.

Responsabilidad ante terceros. Un honeypot comprometido que pivota hacia internet y participa en botnet o DDoS expone a reclamaciones. La diligencia documentada es esencial.

Privacidad y monitorización. En honeytokens internos que capturan actividad de empleados, el RGPD y la AEPD exigen información y proporcionalidad. Una política interna sobre medidas técnicas de detección suele ser suficiente; consultar con asesoría jurídica antes de despliegues amplios.

Logs como evidencia legal. Para uso en procedimiento legal, los logs deben tener integridad demostrable: timestamp confiable, hash, custodia documentada. Integración con SIEM y proceso formalizado de preservación.

Compliance dataset. En sectores regulados (financiero, sanitario, infraestructura crítica) los marcos ISO 27001, NIS2 y DORA reconocen la deception como medida de detección válida y exigen documentarla.

Preguntas frecuentes

Un honeypot es suficiente sin EDR ni SIEM

No. El honeypot detecta interacción con el cebo, pero no cubre la actividad sobre sistemas reales antes o después. Funciona como capa complementaria: el EDR detecta lo que ocurre en el endpoint, el SIEM correla eventos, el honeypot delata movimiento entre sistemas.

Canary frente a T-Pot para uso empresarial

Canary es la elección típica si la organización quiere bajo mantenimiento, integración SIEM lista, soporte y modelo de despliegue probado. T-Pot es la elección si hay equipo técnico interno para operar la pila, presupuesto limitado para licencias y caso de investigación además de detección. T-Pot exige mantenimiento real, no es "instalar y olvidar".

Los honeytokens son legales

Sí, siempre que el cebo no infrinja normativa (no embedar datos personales reales de terceros, no suplantar a personas reales). Son medidas técnicas defensivas comparables a logs de acceso o alertas SIEM. En entorno laboral aplica la política de monitorización y las obligaciones de información correspondientes.

Generan falsos positivos

Muy pocos, por construcción. Las fuentes habituales son escaneos de la propia organización (vulnerability scanners, inventario, monitorización ITSM) y administradores que descubren el honeypot sin saber qué es. La mitigación es excluir los rangos IP de herramientas internas autorizadas y documentar la existencia del cebo en IT y SOC.

Integración con SIEM

Estándar en plataformas comerciales: Syslog, JSON, CEF, conectores nativos para Splunk, QRadar, Sentinel, Elastic. En T-Pot, la salida va a Elastic y desde ahí a Logstash u otro forwarder hacia el SIEM corporativo. La regla operativa es que la alerta llegue al mismo equipo que opera el resto del SOC con el mismo runbook.

El ROI de un honeypot es medible

Imperfectamente. La métrica más usada es tiempo de detección comparado con escenarios sin deception. Los informes públicos de Verizon DBIR muestran tiempos medios de meses en muchos incidentes; una alerta de honeypot reduce esa ventana a horas en escenarios de movimiento lateral. La comparación rigurosa exige ejercicios de red team antes y después del despliegue.

Recursos relacionados

• Qué es threat hunting: metodología y ejemplos
• Qué es EDR: detección y respuesta en endpoint
• Qué es MITRE ATT&CK: tácticas y técnicas
• Qué es SIEM y cómo funciona
• Qué es un backdoor: tipos y detección
• EDR vs XDR vs MDR: comparativa

Deployment de honeypots y deception con Secra

En Secra ayudamos a equipos defensivos a diseñar y desplegar honeypots y honeytokens en entornos corporativos: selección de ubicaciones, definición de cebos coherentes, integración con SIEM, validación mediante ejercicios de red team y revisión periódica de credibilidad.

También evaluamos despliegues existentes para detectar puntos donde el honeypot pierde valor (cebos envejecidos, alertas sin destinatario, segmentación insuficiente) y proponemos ajustes.

Si tu organización quiere introducir deception como capa complementaria a EDR y SIEM, contacta con nosotros para una primera evaluación.