Honeytokens:

trampas baratas que te avisan cuando ya han entrado

Serie Blue Team  |  unfantasmaenelsistema.com

La detección clásica vigila lo que hace todo el mundo y trata de encontrar entre millones de eventos legítimos los pocos que no lo son. Un honeytoken invierte el planteamiento: coloca entre los recursos reales un artefacto falso que nadie tiene motivo para tocar y espera. Cualquier interacción con él es, por definición, sospechosa. No hay que preguntarse si es actividad normal, porque no existe actividad normal contra un cebo.

Un honeytoken no es un sistema ni un servicio: es un único artefacto —un documento, una credencial, un nombre de DNS, una fila de una base de datos, un enlace— 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. Este artículo repasa los tipos que hay, por qué su tasa de falsos positivos es casi nula (y cuándo no lo es), dónde sembrarlos, cómo montarlos con canarytokens.org o con tu propio servidor, cómo conectarlos al SIEM y qué cuidados de OPSEC necesitan para que funcionen.

1. Honeypot y honeytoken: dos formas de engañar

Ambos son deception —engaño defensivo— y parten de la misma asimetría: el equipo de seguridad sabe qué recursos existen y para qué se usan; un intruso, no. La diferencia está en qué se coloca.

• Un honeypot es un sistema o servicio falso completo: escucha en un puerto, ocupa una IP, emula SSH, RDP o SMB, y hay que desplegarlo y mantenerlo. Añade superficie a la red.
• Un honeytoken es un solo artefacto falso sembrado entre los reales. No escucha nada: el disparador viaja dentro del propio fichero, registro DNS o clave. Cero infraestructura, cero puertos nuevos, y se pueden poner a cientos.

El mecanismo del disparador es siempre el mismo. El artefacto lleva incrustado un recurso remoto —una imagen, un enlace, un nombre a resolver, unas credenciales— apuntando a un servidor colector. Cuando alguien abre el documento, resuelve el subdominio o intenta usar la clave, ese servidor recibe la petición y dispara la alerta: fecha y hora, IP de origen, user-agent y, según el tipo, el usuario o el equipo. El proyecto abierto Canarytokens de Thinkst genera casi todos gratis; algunos, como la fila trampa en una base de datos o la cuenta señuelo en el dominio, se montan a mano. Los honeypots los cubrimos en un artículo aparte de esta serie; aquí nos centramos en los tokens.

2. Catálogo de tokens

Cada tipo de token está pensado para saltar ante una acción concreta del atacante. Elegir bien es cuestión de pensar qué haría alguien que acaba de poner un pie en la red.

La regla que los hace útiles a todos es la misma: el token solo sirve si nadie legítimo lo toca nunca. En cuanto un proceso normal lo roza, deja de ser una señal limpia y se convierte en una fuente de falsos positivos que entrena al equipo para ignorarlo.

3. Por qué el falso positivo es casi cero (y cuándo no)

Contra un token no hay actividad normal: ningún proceso ni ninguna persona tiene motivo para abrir un fichero que promete contraseñas, resolver un subdominio inventado o usar una clave que no aparece en ninguna documentación. Por eso una alerta de honeytoken es accionable sin triaje: no hay que decidir si cuenta, solo actuar. Es lo contrario de una regla de SIEM, que nace ruidosa y se afina durante meses.

Hay, sin embargo, un puñado de procesos automáticos que sí tocan los cebos y hay que neutralizar antes de desplegarlos:

• Pasarelas de seguridad de correo que «detonan» los adjuntos en un sandbox: un documento-token enviado por correo se dispara solo desde la IP del gateway.
• Antivirus y EDR que abren o analizan ficheros al escribirlos en disco.
• Indexadores: Windows Search, Spotlight, el indexado de contenido de SharePoint.
• Copias de seguridad y DLP que recorren todos los ficheros de un recurso compartido.
• Comprobadores de enlaces: el «unfurl» de Outlook, Teams o Slack visita cualquier URL que se pegue en un mensaje.
• Escáneres de vulnerabilidades y herramientas de inventario que enumeran cuentas y objetos de Active Directory cada noche.

4. Dónde sembrarlos

Un token en el perímetro solo recoge el ruido de fondo de internet. El valor defensivo está dentro, en los sitios que un atacante consulta cuando ya está buscando cómo moverse:

• Recursos compartidos: junto a los ficheros reales, con nombres atractivos («nominas_2026.xlsx», «credenciales_vpn.docx») y enlazados desde un servidor de ficheros de verdad.
• Active Directory: una cuenta señuelo sin privilegios ni uso real, con un SPN registrado para que aparezca en cualquier búsqueda de cuentas kerberoasteables; el DC registra el Event ID 4769 cuando alguien pide su ticket. Es una de las señales más limpias de Kerberoasting en curso.
• Estaciones de trabajo: una credencial señuelo en el Administrador de credenciales de Windows, una línea falsa en el historial de PowerShell, un fichero de claves canario en el perfil del usuario.
• Repositorios internos y CI/CD: una clave canario en un commit antiguo o en una variable de un pipeline, para cazar a quien mina el código en busca de secretos.
• Gestor de contraseñas y notas: una entrada «VPN administración» que en realidad es un token.
• Bases de datos: una fila trampa en la tabla de usuarios, con un trigger o una vista auditada que avisa al leerla.
• Código de aplicaciones web: un comentario HTML con una URL token o un endpoint oculto, que salta cuando alguien revisa el fuente o pasa un escáner.

5. Montaje: alojado o propio

La vía rápida es canarytokens.org: se elige el tipo de token, se pone un correo o un webhook de destino, se descarga el artefacto y se coloca. Es gratuito y no pide cuenta. El inconveniente es que el dominio del token pertenece a Thinkst (canarytokens.com), un nombre reconocible: un atacante que inspeccione el documento puede identificar el cebo, y las peticiones salen hacia infraestructura de un tercero.

Si eso no encaja con tu modelo de amenaza, el servidor es autoalojable con Docker sobre tu propio dominio, y las alertas van directas a tu SIEM. Para los tokens de DNS necesitas delegar un subdominio (un registro NS) al host que ejecuta el servidor.

# Servidor propio de Canarytokens (resumen)
git clone https://github.com/thinkst/canarytokens-docker
cd canarytokens-docker
cp switchboard.env.dist switchboard.env
cp frontend.env.dist frontend.env
#   CANARY_DOMAINS=tokens.midominio.net     (subdominio con NS delegado a este host)
#   CANARY_ALERT_EMAIL_ENABLED / CANARY_WEBHOOK ...  -> destino de las alertas
docker compose up -d
 
# Comprobar un token DNS ya creado: esta consulta debe generar 1 alerta
dig +short a1b2c3d4e5.tokens.midominio.net
 
# Token de clave AWS: dejar el par en ~/.aws/credentials de una cuenta senuelo.
# Cualquier 'aws s3 ls' con esa clave dispara la alerta con la IP de origen.

6. Integración con el SIEM y respuesta

Canarytokens entrega las alertas por correo, webhook o syslog. Lo aconsejable es enviar el webhook a un índice del SIEM con severidad crítica y una regla que abra caso automáticamente: un toque de token no debería esperar en un buzón. La alerta trae IP de origen y user-agent; correlacionando con DHCP, proxy y EDR se resuelve el host y el usuario reales.

Para los tokens que viven en Active Directory o en un endpoint, la señal fuerte no la da Canarytokens sino tus propios registros de Windows, que ya van por el pipeline normal: el Event ID 4769 del SPN señuelo, los 4624 y 4625 de la cuenta señuelo, y el 4663 sobre el fichero canario si le has puesto una SACL de auditoría. Conviene tener reglas dedicadas para esos identificadores contra esos objetos concretos.

A partir de ahí, la respuesta es la de cualquier incidente, con la ventaja de partir de un indicador fiable: confirmar que el origen no es un sistema propio, acotar el host y la cuenta, pivotar a los logs reales para ver qué más ha hecho ese origen, contener según el plan y preservar la evidencia. Lo que no se hace es rastrear, escanear o intentar acceder al sistema de origen: eso saca del terreno legal y puede destruir pruebas.

7. OPSEC: que no cante y que no se dispare solo

Un token mal montado no atrapa a nadie o, peor, satura de ruido al equipo. Los cuidados son pocos pero innegociables:

• Credibilidad: nombre y ubicación plausibles, metadatos coherentes, algo de antigüedad. Nada de ficheros llamados «canarytoken.docx» ni cuentas en una unidad organizativa «Honeypots».
• Un token por ubicación: si el mismo cebo está en diez sitios, la alerta no te dice en cuál picaron.
• Sin datos reales dentro: el contenido del documento o la fila trampa no debe filtrar nada aprovechable.
• Credenciales sin valor: la clave AWS o la contraseña de la cuenta señuelo no dan acceso a nada y son largas y aleatorias; si la fuga es real, el premio es cero.
• Colocación fuera del alcance de procesos automáticos: nada de pegar la URL token en un chat corporativo ni de dejar el documento en una carpeta que el backup recorre cada noche.
• Dominio propio para los tokens de mayor valor: el autoalojado evita la firma reconocible de canarytokens.com.
• Los tokens son una capa, no la detección: complementan al EDR, al SIEM y a la segmentación; no los sustituyen.

Conclusión

Los honeytokens cubren el hueco que el SIEM y el EDR peor resuelven: 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, pronta y sin necesidad de triaje.

La versión mínima —unos cuantos tokens en los recursos compartidos, una cuenta señuelo con su SPN, un documento canario en un par de endpoints, todo anotado en un registro y cableado al SIEM con prioridad máxima— cuesta una tarde, no añade riesgo y ofrece de las mejores relaciones señal/esfuerzo que existen en detección. Lo único que exige es disciplina: que los cebos sean creíbles, que estén documentados y que nadie legítimo llegue a rozarlos.

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