Resumen

  • LACNIC publicó el 7 de octubre la guía de Guillermo Pereyra sobre canary tokens. El caso de Grafana de 2025 ilustra cómo una clave señuelo puede alertar cuando alguien intenta validarla.
  • La transcripción de Grafana separa un evento de ataque a las 04:30, la activación del canario durante una validación de TruffleHog a las 06:15, una respuesta a las 08:00 y la revisión de registros a las 11:00. No indica la zona horaria ni establece que el primer horario sea el momento del acceso inicial.

Una alerta no marca el comienzo de la intrusión

Un secreto puede haber sido robado antes de que alguien toque el señuelo. Esa diferencia aparece en el caso que LACNIC eligió para explicar su nueva guía. El 7 de octubre, el Blog de LACNIC publicó la nota de Guillermo Pereyra sobre canary tokens: archivos, credenciales, URL o dominios señuelo que generan una alerta cuando reciben una interacción específica. La página aclara que las opiniones de sus autores no necesariamente representan a LACNIC. Es material educativo, no evidencia de que LACNIC haya desplegado estos tokens ni de que haya sufrido un incidente relacionado.

La guía presenta a Grafana como una advertencia rápida: después de extraer secretos de repositorios de GitHub, un atacante intentó validar una clave de AWS que era un canario. LACNIC dice que la alerta llegó de inmediato y que la intrusión se contuvo en minutos. Los propios registros públicos de Grafana muestran varias etapas que ese resumen comprime.

En su aviso de seguridad de 2025, Grafana Labs explicó que un flujo de GitHub Actions mal configurado expuso una cantidad limitada de tokens. El acceso no autorizado quedó circunscrito a sistemas de automatización; no afectó los entornos de producción ni los artefactos de publicación. Grafana invalidó los tokens expuestos, rotó credenciales, auditó los flujos y examinó registros de acceso. Cuando publicó el aviso, la investigación seguía abierta y la empresa decía tener alta confianza en que la intrusión se había limitado a cinco repositorios afectados.

Una transcripción posterior de GrafanaCON precisa para qué sirvió el canario. Los ponentes describen TruffleHog, una herramienta de búsqueda de secretos, como un sistema capaz de verificar credenciales contra servicios activos. Sitúan un evento de ataque a las 04:30, la activación del canario durante una comprobación de TruffleHog a las 06:15, la respuesta a las 08:00 y la investigación de registros en Loki a las 11:00. La transcripción no especifica la zona horaria.

Son marcas de la presentación, no un reloj normalizado del incidente: la primera no demuestra cuándo comenzó el acceso y el token registra la validación posterior de un secreto robado.

En el reloj de esa presentación transcurre 1 hora y 45 minutos entre la activación a las 06:15 y la marca de respuesta de las 08:00. La transcripción no define si esa hora corresponde a la primera acción operativa o a una escalada formal, ni cuándo se consiguió contener el incidente. Esa secuencia no refuta la afirmación de la guía de que la contención ocurrió en minutos, pero tampoco la demuestra por sí sola. Sí muestra por qué hay que registrar por separado la alerta, la respuesta y la contención.

Así se entiende mejor la palabra «inmediata». El token puede alertar en cuanto alguien interactúa con ese señuelo concreto. Por sí solo no dice cuándo se vulneró el flujo, quién obtuvo la credencial, hasta dónde llegó el acceso ni si el riesgo ya está contenido. En la charla, la alerta reveló el intento de validación; los registros y el resto del trabajo de respuesta sirvieron para delimitar el incidente.

Las medidas posteriores que describieron los ponentes no consistieron solo en colocar más señuelos. Trasladaron los secretos a una bóveda, hicieron obligatorios los análisis de Zizmor y TruffleHog, ampliaron la cobertura de canarios, redujeron permisos demasiado amplios de las aplicaciones de GitHub y reforzaron la capacitación. Son controles sobre la exposición, el alcance de los permisos y la posibilidad de repetir la falla. El canario aporta una señal dentro de ese sistema, pero no lo sustituye.

La guía de LACNIC también advierte que algunas herramientas pueden reconocer servicios públicos de tokens y que una alerta sirve de poco si nadie vigila el canal que la recibe. Los ponentes de Grafana dieron un ejemplo acotado: TruffleHog reconoce y omite los tokens gratuitos de Thinkst que conoce. Eso no describe todas las herramientas ni todos los tokens, pero significa que el silencio de un canario no prueba que nadie haya buscado el secreto. LACNIC también afirma que los falsos positivos son escasos, aunque no publica una tasa medida ni el denominador correspondiente.

La señal depende del tipo de token, de cómo se distribuye y de qué otros programas pueden interactuar con él.

La conclusión práctica no es que un canario descubra la intrusión desde su primer paso. Un secreto señuelo bien ubicado puede revelar rápidamente una interacción posterior, siempre que la alerta llegue a alguien, las trazas se conserven y el equipo pueda invalidar la credencial y reducir sus permisos.

Fuentes