🎵 Humans Are Such Easy Prey — Perturbator

de The Uncanny Valley

Antes de que existiera el sensor de gas, existió el pájaro. En las minas de carbón, durante más de un siglo, bajaba un canario en una jaula: un animalito con un metabolismo tan acelerado que colapsaba ante el monóxido de carbono o el grisú mucho antes de que la concentración fuera letal para un humano. El pájaro no detectaba el peligro de una manera inteligente; simplemente estaba más expuesto, y su cuerpo llevaba la cuenta más rápido. Los mineros no vigilaban al canario para verlo cantar. Lo vigilaban para el momento en que dejara de hacerlo. La alarma no era un sonido: era un silencio, o una caída en el fondo de la jaula. Un centinela cuya única función era sufrir primero.

Reconstruimos ese pájaro en software, y lo llamamos —sin ninguna sutileza— canary token. Es una de las ideas más elegantes que tiene la defensa, y una de las pocas que me sigue gustando después de años de verla funcionar, porque invierte una premisa que casi nadie cuestiona: la de que detectar es buscar.

El pájaro de software#

Casi toda la detección que compra una organización está construida para buscar al atacante: firmas que reconocer, comportamientos que puntuar, anomalías que perseguir en un océano de tráfico legítimo. Es trabajo caro y ruidoso, porque el atacante se parece cada vez más al usuario normal, y ya escribí en Del alert al veredicto cuánto cuesta separar la señal del ruido cuando todo dispara alertas. El canary token hace lo contrario. No busca a nadie. Planta un objeto que no tiene ningún uso legítimo y espera. Un documento que nadie debería abrir. Una credencial que no da acceso a nada. Una entrada de base de datos que corresponde a un cliente que no existe. Y como nadie legítimo tiene motivo para tocar eso, cualquier interacción con el objeto es, por definición, sospechosa. La relación señal/ruido no se mejora: se vuelve casi perfecta, porque el universo de gente que abre el archivo llamado «credenciales_break_glass_AWS.docx» que estaba en un recurso compartido oscuro es, prácticamente, el universo de gente que no debería estar ahí.

Es una trampa, sí, pero una honesta con su naturaleza: no promete impedir la intrusión. Asume que el intruso ya entró —esa mentalidad de diseñar cómo se falla que es, para mí, la más madura que hay en seguridad, la misma que anima al warrant canary y al dead man’s switch de los que hablé en Paranoia preventiva— y se limita a garantizar que, cuando el intruso husmee donde no debe, grite por él.

Cómo grita#

La mecánica es más simple de lo que su efecto sugiere. Cada token lleva incrustado un identificador único, casi siempre codificado en un subdominio: algo como u1a2b3c4.canarytokens.com. Ese identificador se cablea dentro del artefacto de modo que tocar el artefacto obligue a la máquina del que lo toca a emitir una petición de red hacia la infraestructura del que plantó el token. Esa petición es el grito. Hay tres formas de provocarla:

flowchart LR
    A["El intruso toca el cebo
(abre el doc, usa la credencial,
resuelve el nombre)"] --> B{"Vía de disparo"}
    B -->|DNS| C["Consulta al servidor DNS
autoritativo del token"]
    B -->|HTTP| D["GET a la URL única
captura IP + User-Agent"]
    B -->|API cloud| E["Uso de la credencial
en la cuenta del que tiende la trampa"]
    C --> F["Evento registrado:
IP · hora · qué token · geolocalización"]
    D --> F
    E --> F
    F --> G["Defensor notificado
email · webhook · Slack"]

La vía DNS es la más robusta, y conviene entender por qué. El artefacto contiene un nombre de dominio único; abrirlo o ejecutarlo fuerza una resolución DNS, y el servidor autoritativo de ese dominio —controlado por quien tendió la trampa— ve la consulta, decodifica el subdominio para saber qué token se activó, y dispara la alerta. La gracia es que funciona aunque la máquina comprometida no tenga salida HTTP directa a internet, porque casi ninguna red del mundo bloquea la resolución DNS: incluso el host más enjaulado necesita resolver nombres, y esa consulta viaja, recursivo tras recursivo, hasta el autoritativo del atacante-cazador. La vía HTTP es más rica en datos —captura IP pública, User-Agent, hora, geolocalización aproximada, y algunas variantes hacen fingerprinting del navegador— pero exige que el host pueda salir por HTTP. La vía cloud es la más astuta: la «credencial» es real, en el sentido de que pertenece a una cuenta de AWS, Azure o GCP que controla el proveedor del token; cuando el intruso la valida o usa, la propia API de la nube registra el intento y avisa. No hace falta que la víctima tenga siquiera una cuenta en esa nube.

El zoológico de cebos#

La idea admite una variedad de formas que sorprende. El servicio que popularizó esto —canarytokens.org, gratuito y de código abierto, de la firma sudafricana Thinkst— ofrece hoy alrededor de treinta tipos. Una muestra representativa:

  • DNS y web bug (URL): el cebo mínimo. Un nombre o una URL que se planta en scripts, configuraciones, favoritos, y grita al resolverse o al cargarse.
  • Documentos (Word, Excel, PDF, Google Docs): al abrirse, el documento solicita un recurso remoto. Se lo nombra para que sea irresistible: «Estructura_de_bonos.xlsx», «Credenciales_VPN.docx».
  • Credenciales cloud (AWS API key, Azure, GCP, Slack): el caso estrella; grita al ser usada o validada. Se siembra en repos de Git, gestores de contraseñas, variables de CI/CD.
  • Carpeta de Windows: usa un desktop.ini que apunta a un recurso remoto, de modo que navegar la carpeta en el Explorador ya dispara. Sirve para monitorear rutas sensibles.
  • Kubeconfig, WireGuard, MySQL dump, SQL Server: configuraciones y volcados falsos que gritan al usarse.
  • Log4Shell: una cadena ${jndi:ldap://…} única; si un sistema vulnerable a CVE-2021-44228 la registra e intenta resolverla, el token detecta que alguien está escaneando o explotando Log4Shell.
  • Sitio clonado (JavaScript): detecta que el código de tu portal de login corre en un dominio que no es el tuyo — es decir, delata la copia de phishing.
  • Sensitive command: alerta cuando un proceso concreto se ejecuta en la máquina — whoami.exe, mstsc.exe, mimikatz.
El patrón que los unifica: el cebo se disfraza de lo que un atacante quiere encontrar en la fase en que ya está adentro y busca botín — credenciales, documentos jugosos, accesos. La calidad de un despliegue de canaries no se mide en cantidad de tokens, sino en dónde se plantan.

Dónde se plantan (y de dónde viene la idea)#

El placement lo es todo. Un token en un lugar donde el atacante nunca mira es plata muerta; uno en un lugar donde tropieza gente legítima es una fábrica de falsos positivos. Los buenos despliegues los ponen exactamente donde un intruso hurga después de entrar: secretos de repositorios, pipelines de CI/CD, el ~/.aws/credentials de la estación de un desarrollador, consolas cloud, recursos compartidos, wikis internas, subdominios sin uso. El marco MITRE Engage —la contraparte defensiva y proactiva de ATT&CK— cataloga esto como Decoy Credentials y Decoy Content, y los eventos que un canary detecta mapean a técnicas ofensivas concretas del ATT&CK: uso de cuentas cloud válidas, robo de credenciales sin proteger, robo de tokens de acceso.

La idea no es nueva; es más vieja que casi todo lo que usamos. En 1986, un astrónomo llamado Cliff Stoll administraba las computadoras del Laboratorio Lawrence Berkeley y le encargaron resolver un descuadre contable de 75 centavos en el uso de tiempo de cómputo. Tirando de ese hilo minúsculo terminó destapando a un intruso que vendía secretos a la KGB. Y para retenerlo conectado el tiempo necesario para rastrear la llamada telefónica internacional, Stoll hizo algo que hoy reconocemos al instante: fabricó documentos falsos —los papeles de un proyecto militar inventado— cuya única razón de existir era ser robados. El cebo delató al ladrón por el acto de robarlo. Stoll lo contó en The Cuckoo’s Egg; el intruso era Markus Hess, de Hannover. Diecisiete años después, en 2003, Lance Spitzner le puso nombre a la técnica —honeytoken— y una década más tarde Thinkst la convirtió en un producto que cualquiera puede usar gratis en cinco minutos.

Hay una propiedad de estos cebos que los vuelve especiales, y es que su valor sobrevive al robo. Una credencial trampa exfiltrada sigue trabajando: cuando el atacante la valida desde su propia infraestructura, revela su IP, su ubicación, su tooling — aunque la intrusión original nunca se haya detectado. El botín lleva un rastreador cosido. Es lo más cerca que está la defensa de convertir la exfiltración, su peor momento, en inteligencia.

El caso que lo volvió leyenda#

En abril de 2025, Grafana Labs contó públicamente cómo un canary token les ahorró meses de ceguera. La cadena de eventos es casi una fábula didáctica:

sequenceDiagram
    participant W as Workflow CI/CD
(mal configurado)
    participant R as Repos públicos
    participant A as Atacante
    participant T as TruffleHog
    participant K as Canary AWS
(cuenta de Thinkst)
    participant G as SOC de Grafana
    W->>R: expone secretos en 5 repos
    A->>R: forkea, inyecta exfiltración
de variables de entorno
    A->>A: borra el fork (cubre rastros)
    A->>T: valida las credenciales robadas
    T->>K: sts:GetCallerIdentity
    K->>G: alerta en minutos
    G->>G: invalida credenciales,
rechaza el rescate

Un workflow de GitHub Actions mal configurado filtró secretos de Grafana en cinco repositorios públicos. El atacante forkeó el repo, inyectó un comando para exfiltrar las variables de entorno, y borró el fork para cubrirse. Después hizo lo que hace cualquier atacante competente con un puñado de credenciales frescas: las validó, corriendo TruffleHog para ver cuáles servían. TruffleHog, al validar una clave de AWS, hace automáticamente una llamada sts:GetCallerIdentity — y una de esas claves era un canary token. La alerta se disparó en minutos, no en meses. Grafana invalidó todo, rechazó el rescate, y confirmó que no hubo impacto en clientes ni en producción. El cebo funcionó por la razón exacta por la que estos cebos funcionan: el tooling del atacante valida automáticamente lo que encuentra, y esa curiosidad refleja es el gas de la mina.

La grieta es semántica, no técnica#

Y acá tengo que hacer lo que en este blog ya es costumbre: auditar la herramienta que estoy elogiando, porque contarla sin su punto débil sería venderla, no explicarla. El punto débil del canary token no es que falle técnicamente. Es que se lo puede reconocer sin tocarlo, si está mal hecho.

El caso más instructivo es el de las AWS canary keys, y es delicioso porque el fallo está en un detalle de diseño de AWS que casi nadie mira: el número de cuenta de AWS va codificado dentro de la propia clave de acceso. La cadena que empieza con AKIA… no es aleatoria; contiene, ofuscado, el account ID de doce dígitos de la cuenta que la emitió. Y ese número se puede extraer sin hacer una sola llamada a AWS —cero riesgo de disparar nada— con pura aritmética:

# esquema del cálculo (según Truffle Security, 2023)
# de un AWS Access Key ID se recupera el account ID sin tocar la red
z = int.from_bytes(y, byteorder='big', signed=False)
mask = int.from_bytes(binascii.unhexlify(b'7fffffffff80'), byteorder='big')
account_id = (z & mask) >> 7

La consecuencia es que un atacante puede tomar la lista de account IDs conocidos del servicio de canaries y comparar, en frío, antes de tocar nada. Truffle Security publicó varios de esos identificadores de canarytokens.org:

052310077262   171436882533   534261010715   595918472158
717712589309   992382622183   819147034852

Y lo incorporó a TruffleHog: la misma herramienta que delató al atacante de Grafana puede, bien usada, detectar canaries estáticamente y esquivarlos. Grafana se salvó porque el atacante corrió TruffleHog en modo validar —el ruidoso—, no en modo chequear estáticamente. La diferencia entre que el canary funcione o no fue una opción de configuración en la máquina del intruso. Hay un segundo delator para quien sí valida a la vieja usanza: la respuesta de sts:GetCallerIdentity devuelve un ARN cuyo nombre de usuario contiene un dominio beacon del proveedor — un cartel de neón que dice «soy una trampa».

Las otras limitaciones, para no vender humo: el canary no previene nada —solo detecta, y si nadie mira la alerta o no hay plan de respuesta, es un adorno—; exige que el atacante lo toque, así que su cobertura es tan buena como su placement; y las vías DNS/HTTP dependen de que el host tenga salida de red. Un intruso que corta el egress antes de husmear evade los callbacks.

De acá sale la lección que de verdad importa, y es contraintuitiva: la carrera entre el cebo y el atacante no es de criptografía, es de verosimilitud. Un canary generado por plantilla es sintácticamente válido pero semánticamente hueco — le falta el contexto de la organización que finge pertenecer. El atacante entrenado, en su reconocimiento interno, compara la credencial contra los otros account IDs que ya vio, contra los ARN presentes, contra las convenciones de nombres de la casa; si no encaja, la descarta como decoy sin tocarla. Por eso el estado del arte —trabajos como el endurecimiento que propone Tracebit, o la investigación sobre honeytokens polimórficos que se adaptan al vocabulario interno de cada empresa— va todo en la misma dirección: hacer que el cebo mienta bien. Un canary que grita es inútil si el atacante lo huele antes de que grite. Y esto conecta con algo que ya dije sobre otro control de seguridad en El analista era el control: la diferencia entre un control real y un teatro no está en si existe, sino en si resiste el encuentro con un adversario que piensa. Un canary de plantilla comprado para poner una casilla en un checklist es teatro con plumas.

El otro canario (para no confundir)#

Una aclaración obligatoria, porque la palabra está sobrecargada. Si trabajas cerca de la explotación de binarios, «canary» suena a otra cosa: el stack canary, un valor centinela que el compilador coloca en la pila entre las variables locales y la dirección de retorno, y que verifica antes de que la función retorne. Si un buffer overflow lo sobrescribió, el programa aborta con un stack smashing detected en vez de saltar a donde el atacante quería. Lo inventó Crispin Cowan con StackGuard en 1998, y hoy vive en cualquier compilador como -fstack-protector. Comparte con el canary token la metáfora del pájaro de la mina —algo que muere primero para avisar— y absolutamente nada más: uno es una mitigación de corrupción de memoria, el otro es una técnica de engaño. Mismo apodo, universos distintos.

Lo que el cebo enseña#

Así que reformulo la pregunta con la que la mayoría llega a este tema. No es «¿cómo escondo mejor a mi organización del atacante?» — esa es la pregunta de la muralla, y las murallas se rodean. La pregunta que el canary contesta es otra: ¿cómo hago para que el atacante trabaje sobre un terreno que miente a mi favor? El cebo no fortalece el perímetro; envenena el interior contra el que lo recorre sin permiso. Convierte la curiosidad del intruso —su herramienta más confiable— en su delator. Es la única técnica defensiva que conozco donde el atacante se atrapa a sí mismo, con su propio reflejo de validar lo que encuentra.

Me gusta porque es humilde en su ambición y honesta en su alcance. No dice «no vas a entrar». Dice «si entras y tocas lo que no es tuyo, lo voy a saber, y vas a dejar tu dirección al hacerlo». El canario de la mina nunca impidió una explosión: solo compró los segundos entre el gas y la muerte, y esos segundos eran todo. El cebo de software compra la misma cosa —la diferencia entre enterarte hoy y enterarte cuando tus datos aparezcan a la venta— y la compra barato, a cambio de una condición que resulta ser la más difícil de cumplir: que la trampa sea lo bastante verosímil como para que valga la pena tocarla. Un pájaro que el minero reconoce como falso no salva a nadie. Todo el oficio está en que parezca vivo.

Fuentes#

commit ph0n3h0m3

Date: 2026-07-24 05:29 AM

touch the bait and you name yourself