En el pasado, los mineros bajaban a los túneles con un canario en una jaula. Si el pájaro dejaba de cantar, había gas en el aire y era momento de escapar de ese lugar.
En seguridad tenemos un problema parecido. Muchas intrusiones se descubren semanas o meses después, cuando el atacante ya recorrió la red, copió lo que quería y se fue. Los canary tokens proponen algo muy sencillo: dejar pequeñas trampas en lugares tentadores y esperar a que alguien las pise.
En este artículo veremos qué son, cómo funcionan, cómo desplegarlos en pocos minutos y en qué casos nos pueden ayudar.
(Acceso libre, no requiere suscripción)
¿Qué es un canary token?
Un canary token es un recurso señuelo: un archivo, una credencial, una URL o un nombre de dominio que no tiene ningún uso legítimo. Nadie debería abrirlo ni usarlo. Por eso, cuando alguien lo hace, el token dispara una alerta que nos da evidencia del acceso, con muy poco margen de duda.
Es la misma idea que un honeypot, pero mucho más liviana. No hace falta levantar un servidor complejo ni simular un servicio. Alcanza con dejar el señuelo donde un atacante miraría y configurar a dónde debe llegar la alerta.
¿Cómo funciona?
Cada token lleva un identificador único que realiza una acción cuando se activa. Ese llamado puede ser una consulta DNS, una petición HTTP o el uso de una credencial contra un servicio en la nube.
¿Qué es un canary token?
Un canary token es un recurso señuelo: un archivo, una credencial, una URL o un nombre de dominio que no tiene ningún uso legítimo. Nadie debería abrirlo ni usarlo. Por eso, cuando alguien lo hace, el token dispara una alerta que nos da evidencia del acceso, con muy poco margen de duda.
Es la misma idea que un honeypot, pero mucho más liviana. No hace falta levantar un servidor complejo ni simular un servicio. Alcanza con dejar el señuelo donde un atacante miraría y configurar a dónde debe llegar la alerta.
¿Cómo funciona?
Cada token lleva un identificador único que realiza una acción cuando se activa. Ese llamado puede ser una consulta DNS, una petición HTTP o el uso de una credencial contra un servicio en la nube.
Por ejemplo, un documento de Word puede incluir una referencia a un recurso remoto alojado en una URL única. Al abrirlo en Microsoft Office, el programa intenta cargar ese recurso y el servidor del token registra la IP, la fecha, la hora y el agente de usuario. Segundos después llega la alerta por correo o webhook.
El token DNS funciona incluso en redes que bloquean la salida a internet, porque la consulta viaja a través del resolver recursivo hasta el servidor autoritativo del dominio del token.
Cómo desplegarlos
La herramienta más conocida es Canarytokens, desarrollada por la empresa Thinkst. Se usa gratis en canarytokens.org, sin necesidad de registrarse, y como su código es abierto, cualquier organización puede montar su propia instancia con Docker.
Crear un token lleva apenas unos minutos:
Elegir el tipo: documentos de Office o PDF, URL, DNS, códigos QR, claves de API (como AWS o SendGrid), bases de datos SQL Server, ejecutables señuelo o páginas de inicio de sesión falsas, entre otras.
Definir a dónde llega la alerta, ya sea un correo electrónico o un webhook que la envíe a Slack, Teams o al SIEM.
Escribir un recordatorio descriptivo, del estilo “planilla de sueldos en el servidor de archivos de RR. HH.”. Cuando llegue la alerta, ese texto indicará con precisión qué se tocó y dónde.
Descargar el token y ubicarlo donde un intruso realmente buscaría: repositorios de código, archivos de configuración, carpetas compartidas o variables de entorno de los pipelines de CI/CD.
Algunas buenas prácticas marcan la diferencia. Conviene usar un token distinto por ubicación, porque así, cuando uno se activa, sabemos por dónde entró el atacante. También ayuda darles nombres creíbles (AWS_CREDENCIALES despierta menos sospechas que CANARY_AWS) y probarlos una vez instalados para confirmar que la alerta llega. Si un token se dispara, lo ideal es conservarlo para el análisis forense y reemplazarlo por uno nuevo.
La técnica funciona en el mundo real: en 2025, Grafana Labs detectó una intrusión cuando un atacante que había robado secretos de sus repositorios de GitHub intentó validar una clave de AWS que resultó ser un canary token. La alerta llegó al instante y el incidente se contuvo en minutos.
Casos de uso
Detección de intrusos: credenciales falsas en un archivo ~/.aws/credentials, en la configuración de una aplicación o en algún lugar de un repositorio de código fuente. Un atacante que las encuentra casi siempre intenta probarlas.
Filtración de documentos: un PDF o un documento de Word con un nombre llamativo avisa cuando alguien lo abre, incluso fuera de nuestra red.
Accesos internos indebidos: un archivo con un nombre tentador en una carpeta compartida a la que sólo debería entrar un área específica.
Sitios clonados para phishing: un fragmento de código en nuestro sitio que alerta si la página se copia y se publica en otro dominio.
El caso más citado es el de Grafana Labs. En abril de 2025, un atacante aprovechó un workflow de GitHub Actions mal configurado para robar secretos. Entre ellos había una clave de AWS señuelo. Cuando el atacante la validó con una herramienta automática, la alerta llegó en el momento y el equipo contuvo la intrusión en minutos.
Lo que hay que tener en cuenta
Los canary tokens no reemplazan otros controles. Cuando uno se activa, alguien ya está adentro. Su valor está en acortar el tiempo entre la intrusión y la detección.
También tienen límites. Los tokens del servicio público usan dominios conocidos, y algunas herramientas de atacantes ya los reconocen sin activarlos. Instalar una instancia propia con un dominio propio reduce ese riesgo, aunque algunos tipos, como las claves de AWS, requiere infraestructura adicional.
Por último, una alerta sirve solo si alguien la lee. Es importante enviarla a un canal que el equipo realmente mire y tener claro qué hacer cuando llega la alerta. Podría ser un dashboard propio en nuestro SIEM o sistema de monitoreo.
Pensamientos finales
Los canary tokens parten de una idea casi ingenua: si algo no debería tocarse, verse o ejecutarse, cualquier interacción es una señal. Esa simpleza es su mayor fortaleza. Con unos minutos de trabajo y sin costo, podemos sembrar nuestra red de pequeñas alarmas que casi no generan falsos positivos y requieren muy poco mantenimiento.
La técnica tampoco es nueva. Es la misma que usan los píxeles ocultos en los correos de marketing para saber si alguien abrió un mensaje. La diferencia es que acá la ponemos al servicio de la defensa.
No detienen un ataque ni reemplazan otros controles, pero cambian algo clave: en lugar de enterarnos meses después, nos avisan cuando todavía estamos a tiempo de actuar. Como el canario de los mineros, no evitan el peligro, pero nos dan la oportunidad de reaccionar antes de que sea tarde.
Un buen punto de partida es crear hoy mismo un token de credenciales de AWS y dejarlo en un repositorio interno. Es la trampa más simple y, como mostró el caso de Grafana Labs, una de las más efectivas.
