Honeypots y deception:

trampas baratas que avisan antes que el SIEM

Serie Blue Team  |  unfantasmaenelsistema.com

Un SIEM tiene que distinguir la señal del ruido: mira millones de eventos legítimos y trata de encontrar entre ellos los pocos que no lo son. Por eso genera falsos positivos, por eso hay que afinar reglas durante meses y por eso un analista pasa buena parte del turno cerrando alertas que no eran nada. Un honeypot invierte el problema. En lugar de vigilar lo que la gente hace de forma legítima, coloca algo con lo que nadie tiene motivo para interactuar y espera. Cualquier toque es, por definición, sospechoso.

Esa es toda la idea: un recurso sin valor real, sin uso legítimo, puesto donde solo tropezaría con él alguien que está husmeando. No necesita firmas, ni modelos, ni entrenamiento. Y montar los más sencillos cuesta una tarde y cero euros. Este artículo repasa qué tipos hay, cuánto trabajo dan, dónde se colocan, qué hacer cuando uno salta y qué límites legales tiene la cosa.

1. La idea de fondo: la alerta que no miente

La deception —engaño defensivo— parte de una asimetría a favor del defensor. El equipo de seguridad sabe qué recursos existen y para qué se usan; un intruso, no. Si sembramos el entorno con recursos falsos que ningún proceso ni ninguna persona legítima tiene por qué tocar, cualquier interacción con ellos delata a alguien que está explorando a ciegas: leyendo comparticiones de red, listando cuentas del dominio, probando credenciales encontradas, abriendo ficheros que prometen contraseñas.

El resultado práctico es una alerta con una tasa de falsos positivos cercana a cero. No hay que preguntarse «¿esto es actividad normal?»: no existe actividad normal contra un honeypot. Eso lo convierte en una alerta de altísima prioridad y en un complemento —no un sustituto— del EDR, el SIEM y la segmentación. El honeypot no previene nada; avisa, y suele avisar antes, porque el atacante lo encuentra en fase de reconocimiento interno, mucho antes de llegar a su objetivo.

2. Niveles de interacción

Los honeypots se clasifican por cuánto dejan que el atacante «haga» antes de chocar con el final del decorado. Más interacción significa mejor inteligencia sobre las técnicas del adversario, pero también más superficie que mantener y más riesgo si el aislamiento falla.

2.1 Baja interacción

Emulan un servicio lo justo para registrar el intento: aceptan una conexión, presentan un banner, quizá piden credenciales, y lo apuntan todo. No hay un sistema operativo real detrás, así que el atacante no puede usarlos como trampolín. Ejemplos habituales: Cowrie (emula SSH y Telnet y graba la sesión), Dionaea (servicios tipo SMB/HTTP/FTP para capturar malware), Honeytrap o OpenCanary (abanico de servicios falsos: RDP, MSSQL, VNC, SIP…). Son la opción por defecto para la mayoría de organizaciones: bajo riesgo, poco mantenimiento, buena señal.

2.2 Media interacción

Ofrecen más profundidad —un shell falso con un sistema de ficheros simulado, respuestas más realistas— sin llegar a ser una máquina completa. Cowrie en su modo de emulación de shell entra aquí. Dan mejor visibilidad de qué comandos ejecutaría el atacante tras entrar, con un riesgo todavía contenido.

2.3 Alta interacción

Son sistemas reales —una VM con Windows o Linux de verdad, servicios de verdad— deliberadamente expuestos y monitorizados hasta el último paquete. Producen la mejor inteligencia (TTP completas, herramientas que sube el atacante, tráfico de mando y control) pero son un compromiso real: si el aislamiento de red falla, acabas de regalar un punto de apoyo. Solo tienen sentido con una red de gestión separada, reglas de salida muy estrictas, snapshots y un equipo que pueda vigilarlos de cerca. Frameworks como T-Pot empaquetan varios honeypots en contenedores para facilitar el despliegue y la recogida.

3. Tokens canario: la trampa sin infraestructura

Un token canario (canary token) es un recurso normal y corriente al que se le ha incrustado un disparador: al abrirlo, resolverlo o usarlo, genera una petición a un servidor que tú controlas y te llega un aviso con la hora, la IP de origen y algo de contexto. No hay servicio que mantener ni puerto que abrir: el token vive dentro del propio fichero, DNS o clave. El proyecto abierto Canarytokens de Thinkst permite generarlos gratis (o autoalojarlos), y algunos EDR y suites de deception los integran de serie.

• Documento Word/Excel/PDF: incrusta un recurso remoto que se solicita al abrir el fichero. Colócalo con un nombre tentador («nóminas_2026.xlsx», «credenciales_vpn.docx») en un recurso compartido o en el escritorio de una cuenta señuelo
• URL única: un enlace que no está publicado en ningún sitio. Si alguien lo visita, es que lo ha sacado de un historial, un correo o una nota robada
• Registro DNS: un subdominio que nadie debería resolver. Cualquier consulta te llega — útil para detectar herramientas de reconocimiento que expanden nombres
• Clave AWS falsa: un par de credenciales sin permisos reales dejado en un fichero de configuración o un repositorio interno. Cualquier intento de usarlas dispara la alerta y confirma que alguien está minando tus secretos
• Carpeta de Windows (directorio canario): una carpeta que avisa cuando un proceso la enumera, gracias a un fichero con recurso remoto dentro; delata ransomware y rastreadores de ficheros
• Entrada de código QR, cadena de conexión, webhook de Slack falso: variantes de la misma idea para otros contextos

4. Honey accounts y honey SPN en Active Directory

Active Directory es el terreno natural de la deception interna porque casi todo ataque de dominio pasa por una fase de enumeración: consultar el LDAP, listar usuarios, buscar cuentas con privilegios o con contraseñas débiles. Sembrar objetos falsos en ese mismo directorio convierte esa enumeración en una alarma.

4.1 Honey account

Una cuenta de usuario que parece valiosa —nombre tipo «svc_backup_adm», descripción sugerente, miembro aparente de un grupo con poder— pero que ningún servicio ni persona usa. Se configura una contraseña larga y aleatoria, se deja habilitada y se audita a fondo. Cualquier intento de autenticación (Event ID 4625 fallido, 4624 con éxito, 4768/4769 de Kerberos) contra esa cuenta es actividad hostil, punto. Para que sea creíble conviene que tenga antigüedad, un LastLogon plausible y esté colocada en una OU normal, no en «OU=Honeypots».

4.2 Honey SPN

Registrar un Service Principal Name en esa cuenta señuelo la hace visible para quien busque cuentas «kerberoasteables». Cuando un atacante solicita el ticket de servicio de ese SPN para llevárselo a crackeo offline, el DC registra un Event ID 4769 para un servicio que nunca recibe peticiones legítimas. Es una de las señales más limpias que existen de Kerberoasting en curso. La cuenta debe tener una contraseña de 32+ caracteres para que, aunque alguien se lleve el ticket, no lo rompa.

5. Dónde se colocan los cebos

Un honeypot en el perímetro, expuesto a internet, solo recoge el ruido de fondo de la red: barridos masivos, botnets, escáneres académicos. Sirve para investigación de amenazas globales, pero no te dice nada sobre tu organización. El valor defensivo está dentro: en los segmentos donde un atacante ya ha puesto un pie y está buscando cómo moverse.

• En las VLAN de usuarios y de servidores, junto a los sistemas reales, para que aparezcan en cualquier barrido de la subred
• En los recursos compartidos que un atacante consultaría primero: un honey share con nombres atractivos enlazado desde un servidor de ficheros real
• En Active Directory, como se ha visto, para cazar la enumeración de dominio
• En estaciones de trabajo concretas: credenciales señuelo en el gestor de credenciales de Windows, entradas falsas en el historial de PowerShell, un fichero de «contraseñas» en el escritorio del CFO virtual
• En redes OT/IoT segmentadas, donde cualquier tráfico inesperado destaca mucho

6. Cuando salta la trampa

Una alerta de honeypot es un incidente hasta que se demuestre lo contrario. El procedimiento es el de respuesta a incidentes de siempre, con la ventaja de que ya tienes un indicador fiable y un punto de partida (la IP o el host de origen que tocó el cebo).

• Confirma que no es un falso positivo tuyo: ¿coincide el origen con un administrador, un escáner programado, una herramienta de inventario? Tu registro de cebos responde esto en segundos
• Acota: identifica el host de origen, la cuenta usada y la ventana temporal. Pivota a los logs reales (EDR, autenticación, Sysmon, proxy) para ver qué más ha hecho ese origen
• Contén según tu plan: aislar el host, deshabilitar la cuenta comprometida, cortar el segmento. El honeypot te ha dado tiempo; úsalo
• Preserva la evidencia (la propia alerta, los logs del honeypot, la memoria y el disco del host de origen si procede) por si hay que denunciar
• No «contraataques»: rastrear, escanear o intentar acceder al sistema de origen —aunque sea el portátil de un empleado— te saca del terreno legal y puede destruir evidencia. La respuesta es contención e investigación interna, y si hay delito, denuncia y fuerzas de seguridad

7. Marco legal y errores comunes

• Cebo poco creíble: nombres genéricos, cuentas recién creadas, todo agrupado en una OU llamada «Decoy». Un atacante con algo de experiencia los ignora
• Falsos positivos propios: escáneres de vulnerabilidades, herramientas de backup o de inventario que tocan el cebo cada noche y acaban entrenando al equipo para ignorar sus alertas
• Honeypot de alta interacción sin aislar: reglas de salida permisivas, misma VLAN que producción, sin snapshots. Deja de ser una trampa y pasa a ser una brecha
• Alertas a ninguna parte: el cebo dispara a un buzón que nadie revisa. Si no está cableado a la guardia, no existe
• Sin documentación: nadie recuerda dónde están los tokens seis meses después, y cada alerta arranca una investigación desde cero

Conclusión

Los honeypots no compiten con el SIEM ni con el EDR: cubren el hueco que esas herramientas peor resuelven, que es distinguir el reconocimiento interno silencioso del trabajo cotidiano. Un cebo bien puesto no tiene ese problema porque nadie legítimo lo toca, y por eso su alerta llega limpia y pronto.

La versión mínima —unos cuantos tokens canario, una honey account con su honey SPN, todo documentado y cableado a la guardia— cuesta una tarde y no añade riesgo. Es de las mejores relaciones señal/esfuerzo que hay en detección. Los honeypots de alta interacción son otra liga: dan una inteligencia excelente, pero solo si se aíslan y se vigilan con la seriedad de un sistema realmente comprometido, porque mientras están encendidos lo parecen.

unfantasmaenelsistema.com | Seguridad, sistemas y todo lo que no debería funcionar (pero funciona)