Antigamente, os mineradores levavam um canário em uma gaiola para dentro dos túneis. Se o passarinho parasse de cantar, significava que havia gás no ar e que era hora de fugir daquele lugar.
Temos um problema semelhante em segurança. Muitas intrusões são descobertas semanas ou meses depois, quando o invasor já percorreu a rede, copiou o que queria e foi embora. Os canary tokens propõem algo muito simples: deixar pequenas armadilhas em locais tentadores e esperar que alguém as pise.
Neste artigo, veremos o que são, como funcionam, como implantá-los em poucos minutos e em quais casos eles podem nos ajudar.
(Acesso livre, não requer assinatura)
O que é um canary token?
Um canary token é um recurso isca: pode ser um arquivo, uma credencial, uma URL ou um nome de domínio que não possui nenhum uso legítimo. Ninguém deveria abri-lo ou usá-lo. Por isso, quando alguém o faz, o token dispara um alerta que nos fornece evidências do acesso, com pouquíssima margem de dúvida.
É a mesma ideia de um honeypot, mas muito mais leve. Não é necessário configurar um servidor complexo ou simular um serviço. Basta colocar a isca onde um atacante procuraria e configurar o destino do alerta.
Como funciona?
Cada token possui um identificador único que executa uma ação quando ativado. Essa chamada pode ser uma consulta DNS, uma solicitação HTTP ou o uso de uma credencial em um serviço na nuvem.
O que é um canary token?
Um canary token é um recurso isca: pode ser um arquivo, uma credencial, uma URL ou um nome de domínio que não possui nenhum uso legítimo. Ninguém deveria abri-lo ou usá-lo. Por isso, quando alguém o faz, o token dispara um alerta que nos fornece evidências do acesso, com pouquíssima margem de dúvida.
É a mesma ideia de um honeypot, mas muito mais leve. Não é necessário configurar um servidor complexo ou simular um serviço. Basta colocar a isca onde um atacante procuraria e configurar o destino do alerta.
Como funciona?
Cada token possui um identificador único que executa uma ação quando ativado. Essa chamada pode ser uma consulta DNS, uma solicitação HTTP ou o uso de uma credencial em um serviço na nuvem.
Por exemplo, um documento do Word pode incluir uma referência a um recurso remoto hospedado em uma URL única. Ao abri-lo no Microsoft Office, o programa tenta carregar esse recurso e o servidor do token registra o IP, a data, a hora e o agente de usuário. Segundos depois, o alerta chega por e-mail ou webhook.
O token DNS funciona inclusive em redes que bloqueiam o acesso à Internet, porque a consulta viaja através do resolvedor recursivo até o servidor autoritativo do domínio do token.
Como implantá-los
A ferramenta mais conhecida é Canarytokens, desenvolvida pela empresa Thinkst. Pode ser usado gratuitamente em canarytokens.org, sem necessidade de cadastro, e, como seu código é aberto, qualquer organização pode subir sua própria instância usando Docker.
Criar um token leva apenas alguns minutos:
Basta escolher o tipo: documentos do Office ou PDF, URL, DNS, códigos QR, chaves de API (como AWS ou SendGrid), bancos de dados SQL Server, executáveis de isca ou páginas de login falsas, entre outros.
Definir para onde o alerta é enviado, seja um e-mail ou um webhook que a encaminhe para o Slack, Teams ou SIEM.
Escrever um lembrete descritivo, no estilo “folha de pagamento no servidor de arquivos do RR. HH.”. Quando o alerta chegar, esse texto indicará precisamente o que foi tocado e onde.
Baixar o token e posicioná-lo onde um invasor realmente procuraria: repositórios de código, arquivos de configuração, pastas compartilhadas ou variáveis de ambiente dos pipelines de CI/CD.
Algumas boas práticas fazem toda a diferença. É recomendável usar um token diferente para cada local, pois assim, quando um deles for ativado, saberemos por onde o atacante entrou. Também ajuda dar nomes críveis (AWS_CREDENCIAIS suscita menos suspeitas do que CANARY_AWS) e testá-los uma vez instalados para confirmar que o alerta chega. Se um token for acionado, o ideal é preservá-lo para análise forense e substituí-lo por um novo.
A técnica funciona no mundo real: em 2025, o Grafana Labs detectou uma intrusão quando um atacante que havia roubado segredos de seus repositórios do GitHub tentou validar uma chave de AWS que era, na verdade, um canary token. O alerta chegou instantaneamente e o incidente foi contido em minutos.
Casos de uso
Detecção de intrusos: credenciais falsas em um arquivo ~/.aws/credentials, na configuração de um aplicativo ou em algum lugar de um repositório de código-fonte. Um atacante que as encontra quase sempre tenta testá-las.
Filtragem de documentos: um PDF ou um documento de Word com um nome chamativo alerta você quando alguém o abre, mesmo fora da nossa rede.
Acessos internos indevidos: um arquivo com um nome tentador em uma pasta compartilhada que só deveria ser acessada por uma área específica.
Sites clonados para phishing: um trecho de código em nosso site que alerta se a página for copiada e publicada em outro domínio.
O caso mais citado é o de Grafana Labs. Em abril de 2025, um atacante aproveitou um workflow do GitHub Actions mal configurado para roubar segredos. Entre eles havia uma chave de AWS isca. Quando o atacante validou essa chave com uma ferramenta automática, o alerta chegou na hora e a equipe conteve a invasão em questão de minutos.
O que é preciso levar em conta:
Os canary tokens não substituem outros controles. Quando um deles é ativado, alguém já está do lado de dentro. Seu valor reside em reduzir o tempo entre a intrusão e a detecção.
Também têm os seus limites. Os tokens dos serviços públicos usam domínios conhecidos, e certas ferramentas de atacantes já conseguem identificá-los sem disparar o alerta. Instalar uma instância própria com um domínio exclusivo reduz esse risco, embora alguns tipos, como as chaves de AWS, exijam infraestrutura adicional.
Por último, um alerta só serve se alguém o ler. É importante enviá-lo para um canal que a equipe realmente acompanhe e definir com clareza o protocolo de resposta quando o alerta for disparado. Poderia ser um dashboard próprio no nosso SIEM ou sistema de monitoramento.
Considerações finais
Os canary tokens partem de uma ideia quase ingênua: se algo não deveria ser tocado, visto ou executado, qualquer interação é um sinal. Essa simplicidade é sua maior força. Com poucos minutos de trabalho e sem custo, podemos espalhar pela nossa rede, pequenos alarmes que quase não geram falsos positivos e exigem pouquíssima manutenção.
A técnica também não é nova. É a mesma tecnologia usada pelos pixels ocultos nos e-mails de marketing para saber se alguém abriu uma mensagem. A diferença é que, aqui, nós a colocamos a serviço da defesa.
Eles não impedem um ataque nem substituem outros controles, mas mudam algo fundamental: em vez de descobrirmos meses depois, eles nos avisam quando ainda dá tempo de agir. Tal como o canário nas minas, esses tokens não eliminam o perigo, mas nos concedem o tempo necessário para reagir antes que seja tarde demais.
Um bom ponto de partida é criar hoje mesmo um token de credenciais de AWS e deixá-lo em um repositório interno. É a armadilha mais simples e, como mostrou o caso do Grafana Labs, uma das mais eficazes.
