¿Es legal desplegar un honeypot en España?

Sí, desplegar honeypots en infraestructura propia es legal. Sin embargo, deben respetarse la LOPDGDD y el RGPD respecto a datos personales capturados (direcciones IP de atacantes). También hay que evitar que el honeypot sea usado como plataforma para atacar a terceros. Se recomienda asesoramiento legal previo.

¿Los datos capturados por un honeypot sirven como prueba judicial?

Pueden servir como prueba si se mantiene la cadena de custodia y se documenta el despliegue. El perito debe acreditar que los logs no han sido manipulados, que el honeypot registraba fielmente las acciones y que su despliegue fue lícito. En el proceso penal la pericial se acuerda por el art. 456 LECrim, cuando hacen falta conocimientos técnicos; el art. 478 fija lo que debe contener el informe —incluida la relación detallada de todas las operaciones practicadas— y el art. 479 obliga a conservar parte del objeto si el análisis lo altera, que en digital se traduce en trabajar sobre la imagen forense y preservar el original.

Honeypot - Trampas Digitales Ciberseguridad

¿Qué es un honeypot?

El INCIBE gestionó 122.223 ciberincidentes en España durante 2025 —un 26 % más que el año anterior— y notificó además 237.028 sistemas vulnerables. En ese contexto los honeypots cumplen dos funciones distintas que conviene no mezclar: detectar amenazas temprano, y capturar evidencia utilizable después en un procedimiento.

Un honeypot (literalmente “tarro de miel”) es un sistema informático desplegado deliberadamente para parecer un objetivo atractivo y vulnerable para atacantes. No contiene datos reales de producción ni presta servicios legítimos: su único propósito es atraer, registrar y analizar actividades maliciosas. Cualquier interacción con un honeypot es, por definición, sospechosa o maliciosa.

Principio fundamental

En un sistema de producción, distinguir tráfico legítimo de malicioso es difícil. En un honeypot, toda actividad es sospechosa porque ningún usuario legítimo debería acceder a él. Esto simplifica enormemente la detección y el análisis forense.

Tipos de honeypots

Clasificación por nivel de interacción

Característica	Baja interacción	Media interacción	Alta interacción
Emulación	Solo servicios básicos (puertos, banners)	Shell simulado con comandos limitados	Sistema operativo real completo
Riesgo	Mínimo	Bajo	Alto (puede ser comprometido)
Información capturada	IPs, puertos escaneados, payloads básicos	Comandos ejecutados, credenciales	TTPs completas, malware, exploits
Mantenimiento	Bajo	Medio	Alto
Detectabilidad	Alta (atacantes expertos lo identifican)	Media	Baja
Ejemplo	Honeyd, Dionaea	Cowrie en modo shell	HoneyTrap, Cowrie en modo proxy, sistemas reales instrumentados

Honeypots de baja interacción

Emulan servicios de red básicos sin proporcionar un sistema operativo real. Capturan información inicial del atacante:

Dionaea: Emula servicios SMB, HTTP, FTP, MSSQL para capturar malware
Honeyd: Crea hosts virtuales con diferentes sistemas operativos simulados
Conpot: Especializado en sistemas de control industrial (SCADA/ICS)
Mailoney: Emula servidores SMTP para capturar campañas de spam/phishing

Honeypots de alta interacción

Proporcionan un sistema operativo real con el que el atacante interactúa sin restricciones:

HoneyTrap: Framework modular para captura de ataques
Sistemas reales instrumentados: Servidores con monitorización avanzada

Cowrie no está en un nivel: está en dos, y lo elige quien lo configura

Cowrie es el honeypot SSH más extendido y suele citarse tanto en la casilla de «media» como en la de «alta», lo que no es un descuido: su propio proyecto se describe como «a medium to high interaction SSH and Telnet honeypot» y aclara la diferencia — «In medium interaction mode (shell) it emulates a UNIX system in Python; in high interaction mode (proxy) it functions as an SSH and telnet proxy to observe attacker behavior on another system».

La distinción decide el riesgo y el valor probatorio a la vez. En modo shell no hay sistema real detrás: el atacante nunca llega a ejecutar nada, lo que hace el despliegue casi inofensivo y limita lo que se puede afirmar sobre lo que habría ocurrido. En modo proxy sí hay una máquina real al otro lado, con todo lo que eso implica —incluida la posibilidad de que se use para atacar a terceros—. En el informe pericial hay que decir en qué modo estaba, porque de ello depende si los comandos registrados se ejecutaron de verdad o solo fueron respondidos por una emulación.

Riesgo de alta interacción

Un honeypot de alta interacción puede ser comprometido y utilizado como plataforma para atacar a terceros. Es imprescindible aislarlo de la red de producción con firewalls estrictos y monitorizar todo el tráfico saliente.

Honeynet: Redes de honeypots

Un honeynet es una red completa de honeypots interconectados que simula un entorno de producción real. Según The Honeynet Project, permite observar:

Movimientos laterales: Cómo el atacante se mueve entre sistemas
Escalada de privilegios: Técnicas para obtener acceso de administrador
Exfiltración de datos: Métodos de extracción de información
Comunicación C2: Conexiones con servidores de comando y control
Propagación de malware: Cómo se distribuye ransomware o gusanos

Clasificación por propósito

Tipo	Propósito	Ejemplo de uso
Research honeypot	Investigación académica de amenazas	Universidades, CERT/CSIRT
Production honeypot	Detección de intrusiones en entorno corporativo	Empresas, SOCs
Spam honeypot	Captura de campañas de spam y phishing	ISPs, proveedores email
Database honeypot	Detección de inyección SQL y ataques a BBDD	Empresas con datos sensibles
Spider honeypot	Identificación de web crawlers maliciosos	Sitios web, APIs

Deception technology: Evolución del honeypot

La deception technology (tecnología de engaño) representa la evolución empresarial de los honeypots tradicionales. Las plataformas de este tipo despliegan automáticamente:

Decoys: Servidores, endpoints y servicios falsos integrados en la red real
Breadcrumbs: Credenciales falsas, archivos señuelo y registros DNS ficticios que guían al atacante hacia los decoys
Lures: Tokens y documentos trampa que alertan cuando son accedidos

La ventaja sobre los honeypots tradicionales es la integración transparente en el entorno de producción, que hace difícil distinguir sistemas reales de señuelos.

Los tres fabricantes que suelen citarse ya no existen como tales

La bibliografía sobre deception technology repite tres nombres —Attivo Networks, Illusive y TrapX— que hoy son productos dentro de suites mayores. Se comprueba en segundos siguiendo la redirección de su propio dominio: attivonetworks.com lleva a SentinelOne, illusive.com a una página de Proofpoint titulada «Illusive is now Proofpoint» y trapx.com a Commvault ThreatWise.

Importa por una razón práctica y no comercial: un informe pericial que nombre al fabricante equivocado se corrige en la sala, y la trazabilidad de la herramienta —qué producto, qué versión, quién lo mantiene— es parte de lo que sostiene el dictamen. Antes de citar un producto de seguridad conviene abrir su web, que además dice si sigue habiendo alguien detrás.

Valor forense de los honeypots

Evidencia capturada

Los honeypots proporcionan evidencia forense de alto valor:

Tipo de evidencia	Descripción	Herramientas de análisis
Logs de sesión	Comandos ejecutados, timestamps exactos	Splunk, ELK Stack
Capturas de red (PCAP)	Tráfico completo del atacante	Wireshark, NetworkMiner
Malware	Binarios descargados por el atacante	Sandbox, VirusTotal
Credenciales	Contraseñas utilizadas en ataques de fuerza bruta	Análisis de diccionarios
IOCs	IPs, dominios, hashes de malware	Plataformas de threat intelligence
TTPs	Tácticas, técnicas y procedimientos (framework MITRE ATT&CK)	MITRE Navigator

Proceso de análisis forense de un honeypot

Preservación de evidencia
Antes de cualquier análisis, asegurar la integridad:
- Crear imagen forense del sistema honeypot
- Exportar todos los logs con hashes SHA-256
- Capturar volcado de memoria RAM si el honeypot está activo
- Preservar capturas PCAP completas
Análisis de cronología (timeline)
Reconstruir la secuencia de eventos:
- Primer contacto (escaneo de puertos, reconocimiento)
- Intentos de explotación (vulnerabilidades probadas)
- Acceso inicial (credenciales, exploit exitoso)
- Post-explotación (movimientos laterales, persistencia)
Identificación del atacante
Correlacionar direcciones IP con:
- Geolocalización y ASN (proveedor de red)
- Reputación en bases de threat intelligence
- Patrones de horario (zona horaria del atacante)
- Fingerprinting de herramientas (Nmap, Metasploit, scripts custom)
Análisis de malware capturado
Todo binario descargado por el atacante se analiza:
- Hash y comparación con bases de datos de malware
- Análisis en sandbox para comportamiento dinámico
- Ingeniería inversa si es necesario
- Identificación de infraestructura C2
Documentación para informe pericial
Preparar evidencia para uso judicial:
- Cadena de custodia de todos los artefactos
- Logs originales con hashes de integridad
- Capturas de pantalla de sesiones del atacante
- Correlación temporal con el incidente investigado

Herramientas de honeypot

Despliegue y gestión

Herramienta	Tipo	Servicios emulados	Licencia
T-Pot	Plataforma multi-honeypot	20+ honeypots integrados	Open source
Cowrie	Media o alta, según el modo	SSH, Telnet, SFTP — no bases de datos ni web	Open source
Dionaea	Baja interacción	SMB, HTTP, FTP, MSSQL, MySQL	Open source
Conpot	ICS/SCADA	Modbus, S7comm, IPMI	Open source
HoneyDB	Agregador datos	Datos de honeypots globales	Servicio web
OpenCanary	Baja interacción	SSH, HTTP, FTP, SMB, MySQL	Open source

Monitorización y análisis

Kippo-Graph: Visualización de datos de Cowrie/Kippo
ELK Stack: Indexación y análisis de logs de honeypots
MHN (Modern Honey Network): Gestión centralizada de honeypots distribuidos
HHFW: Firewall específico para honeynet (controla tráfico saliente)

Caso práctico: Honeypot en investigación de intrusión corporativa

Contexto: Una empresa del sector financiero detecta accesos no autorizados a su base de datos de clientes. El equipo de seguridad sospecha de un insider threat pero no tiene evidencia concluyente. Se despliega un honeypot interno como parte de la investigación.

Escenario ilustrativo

El caso de esta sección es un escenario construido sobre una tipología real de la práctica pericial: explica cómo se comporta la evidencia de un honeypot interno, no relata un expediente concreto. La empresa, los identificadores, las horas y el desenlace no corresponden a un procedimiento identificable.

Antes de desplegarlo: la monitorización tiene que ser lícita para poder ser fiable

Un señuelo colocado dentro de la red corporativa para detectar a un empleado es un sistema de control laboral, y no deja de serlo porque los datos que contenga sean falsos. Rigen el art. 20.3 del Estatuto de los Trabajadores y los arts. 87 a 90 de la LOPDGDD: el 87 exige criterios de uso fijados con participación de la representación de los trabajadores, y el 90 impone informar «de forma expresa, clara e inequívoca».

Unos registros impecables obtenidos con un sistema del que nunca se informó no se sostienen por muy buena que sea la cadena de custodia — el mismo criterio que se detalla en evidencia laboral digital. Es la primera pregunta que hace la contraparte y conviene tener la respuesta documentada antes del despliegue, no después.

Despliegue del señuelo
Se colocó en el mismo segmento de red que producción un servidor con dos piezas, y la distinción importa porque determina qué puede registrar cada una:
- Cowrie atendiendo SSH, que registra la sesión: credenciales probadas, comandos y transferencias.
- Una instancia real de MySQL con datos fabricados de «clientes VIP» y el registro general de consultas activado. Un emulador de baja interacción como OpenCanary habría anotado el intento de conexión, pero no ejecuta consultas ni puede registrar cuáles se lanzaron: para eso hace falta un motor de verdad.
Configuración de señuelos (breadcrumbs)
Se distribuyeron credenciales falsas en:
- Archivo de texto en carpeta compartida de red
- Script de conexión “olvidado” en un repositorio interno
- Entrada en el gestor de contraseñas departamental
Detección de actividad
A las 72 horas se registró actividad, y en dos registros distintos que después hay que correlacionar por marca de tiempo:
```
cowrie.json        22:47:12  login exitoso  usuario=admin_bbdd  src=192.168.1.87
mysql general.log  22:47:45  SELECT * FROM clientes_vip LIMIT 100
mysql general.log  22:48:31  SELECT * FROM clientes_vip INTO OUTFILE '/tmp/…'
cowrie.json        22:49:02  SFTP  clientes_vip.csv  →  destino externo
```
Que las líneas vengan de dos ficheros no es un detalle de formato: el informe pericial tiene que declarar de dónde sale cada una, con qué reloj se escribió y cómo se comprobó que ambos relojes coincidían. Presentarlas como un registro único es la clase de simplificación que la contraparte usa para discutir toda la correlación.
Identificación del origen
La IP correspondía a una estación de trabajo del departamento de TI, y las credenciales usadas eran las ficticias plantadas como señuelo: no existían en el entorno real, de modo que solo pudieron obtenerse de uno de los tres lugares donde se sembraron.
Conviene ser preciso con lo que eso acredita y lo que no: identifica un equipo, no a una persona. Atribuir la conducta a quien tiene asignado ese puesto exige cerrar el vínculo con otros elementos —control de accesos físicos, sesión abierta, huella del navegador, turnos— y el informe debe decir qué parte de esa cadena está probada y cuál se infiere.
Correlación con el incidente original
Los logs del sistema de producción mostraron que la misma estación de trabajo había accedido a la base de datos real en fechas anteriores, con patrones similares de consulta y exportación.

Qué aporta un despliegue así: convierte una sospecha sin soporte en un registro contemporáneo y acotado —sesión completa, marcas de tiempo, comandos y fichero extraído— sobre datos que nadie tenía motivo legítimo para consultar, que es justamente lo que le da fuerza. Ese último punto es el que conviene explicar en el informe: sobre un servidor de producción siempre cabe discutir si el acceso formaba parte del trabajo; sobre un señuelo que no presta servicio a nadie, no.

Qué peso acabe teniendo es cosa del tribunal y depende de todo lo demás: de que el despliegue fuera lícito, de que la cadena de custodia aguante y de si el vínculo entre el equipo y una persona concreta llega a cerrarse.

Marco legal en España

Legalidad del despliegue

Aspecto legal	Normativa	Consideración
Despliegue en red propia	Lícito (derecho a proteger infraestructura)	No requiere autorización judicial
Captura de IPs	RGPD / LOPDGDD	Las IPs son datos personales; se requiere base legal (interés legítimo, art. 6.1.f RGPD)
Registro de comunicaciones	Art. 18.3 CE; Ley 25/2007	El secreto de las comunicaciones no se ve afectado mientras el honeypot registre lo que ocurre en el propio sistema y no intercepte comunicaciones ajenas. La Ley 25/2007 es ley ordinaria, no orgánica, y obliga a los operadores de telecomunicaciones: no es el título bajo el que una empresa registra su honeypot
Honeypot dentro de la red corporativa	Art. 20.3 ET; arts. 87 a 90 LOPDGDD	Es control laboral aunque los datos del señuelo sean falsos. Hay que informar «de forma expresa, clara e inequívoca» y fijar los criterios de uso con participación de la representación de los trabajadores
Uso como prueba	LECrim art. 456, 478 y 479	El 456 acuerda la pericial cuando hacen falta conocimientos técnicos; el 478 fija el contenido del informe, incluida la «relación detallada de todas las operaciones practicadas»; el 479 obliga a conservar parte del objeto si el análisis lo altera — en digital, trabajar sobre la imagen y preservar el original
Honeypot que simula ser un menor	Art. 183 CP	El tipo exige que la propuesta de encuentro «se acompañe de actos materiales encaminados al acercamiento». Un señuelo que da esos pasos deja de ser pasivo y entra en terreno de provocación delictiva, que anula la prueba. Es investigación reservada a la policía judicial con habilitación, no a un particular

Requisitos para validez probatoria

Para que la evidencia capturada por un honeypot sea admisible en procedimientos judiciales españoles:

Documentación del despliegue: Fecha, configuración, propósito del honeypot
Proporcionalidad: La medida debe ser proporcionada al riesgo investigado
Cadena de custodia: Logs preservados con hashes de integridad desde el inicio
No provocación: El honeypot atrae pero no incita a cometer delitos
Informe pericial: Un perito informático debe analizar y presentar la evidencia

Sobre la provocación

Un honeypot que simplemente simula ser un sistema vulnerable no equivale a provocación delictiva: no induce a nadie a delinquir, se limita a estar expuesto como lo estaría cualquier sistema mal configurado. Sin embargo, distribuir activamente “invitaciones” a atacar un sistema podría cuestionarse jurídicamente. El perito debe documentar que el honeypot era pasivo.

Preguntas relacionadas

¿Cuánto tiempo debe estar activo un honeypot para obtener resultados? Depende del entorno. En internet público, un honeypot expuesto recibe ataques automatizados en minutos. Para investigaciones internas (insider threats), pueden necesitarse semanas o meses. Lo habitual para investigaciones corporativas es un periodo de 30 a 90 días.

¿Puede un atacante detectar que está en un honeypot? Atacantes experimentados pueden detectar honeypots de baja interacción por la limitación de servicios, respuestas predecibles o fingerprinting de la herramienta. Los honeypots de alta interacción son más difíciles de detectar, pero un atacante sofisticado puede buscar indicadores como nombres de hardware virtual, latencias inusuales o falta de tráfico legítimo.

¿Se necesita autorización judicial para desplegar un honeypot? En España, desplegar un honeypot en tu propia infraestructura no requiere autorización judicial. Es análogo a instalar cámaras de seguridad en tus propias instalaciones. Sin embargo, si la investigación implica interceptación de comunicaciones de terceros, sí sería necesaria autorización del juez de instrucción.

Conclusión

Los honeypots son una herramienta de doble valor: proporcionan inteligencia sobre amenazas en tiempo real y generan evidencia forense de alta calidad para investigaciones judiciales. Su principio de “toda actividad es sospechosa” simplifica el análisis y fortalece la posición probatoria.

Para investigaciones de insider threats y ciberataques corporativos, un honeypot bien desplegado y documentado puede ser la diferencia entre una sospecha sin soporte y un registro contemporáneo que aguante ser examinado.

Con dos condiciones que no son técnicas y deciden igual: el despliegue tiene que haber sido lícito —dentro de una empresa, eso significa control laboral informado— y el informe tiene que declarar en qué modo operaba cada pieza, porque de ahí depende si lo registrado ocurrió o solo fue emulado. Ambas se resuelven antes de encender nada; después ya no. El análisis lo firma un perito informático forense, que es quien responde de esas dos declaraciones ante el tribunal.

Un registro de honeypot vale lo que valga su despliegue

Los logs de un señuelo se impugnan por dónde estaba, cómo se informó de él y en qué modo corría, antes que por su contenido. Análisis de intrusiones y evidencia de red con informe pericial y trazabilidad declarada.

Ver el servicio de informes periciales

Última actualización: Febrero 2026 Categoría: Ciberseguridad Código: SEC-001

Honeypot