Cyberdeception: como usar Honeytokens e SIEM para detectar atacantes
Detectar um ataque nem sempre significa encontrar uma atividade claramente suspeita. Em alguns casos, o invasor já conseguiu acesso à rede e utiliza credenciais legítimas para explorar permissões existentes e se movimentar pelo ambiente como um usuário comum faria.
Isso cria um desafio para as equipes de segurança, já que uma tentativa de login com uma credencial válida, por exemplo, pode não parecer diferente de tantas outras que acontecem diariamente. O problema está no contexto: entender quem está usando aquela credencial, por qual motivo e se esse acesso realmente deveria acontecer.
Uma das formas de responder a essas perguntas é utilizar o cyberdeception, uma estratégia que cria elementos falsos dentro do ambiente ativo para enganar e, logo, detectar quem está tentando explorá-lo.
Neste artigo, vamos entender mais a fundo essa prática de cyberdeception, especificamente os honeytokens, as iscas "doces" para enganar atacantes. Para transformar essa interação em uma informação útil para a segurança, ainda é preciso entender o que aconteceu antes, durante e depois do acesso com o auxílio de ferramentas de SIEM.
O que é cyberdeception e como funciona?
Cyberdeception é uma estratégia de defesa que utiliza informações, recursos, credenciais e até ambientes totalmente falsos para enganar, desviar ou detectar invasores.
Isso significa que, em vez de depender apenas da identificação de um comportamento suspeito, a organização cria um recurso que não deveria ser acessado por ninguém. Se alguém interagir com ele, essa atividade já passa a ser um sinal relevante de que algo está acontecendo fora do esperado.
Isso pode ser feito de diferentes maneiras. Um honeypot, por exemplo, é um sistema ou ambiente inteiro criado com o único intuito de atrair e observar a movimentação dos invasores. Já um honeytoken é um dado ou credencial falsa que funciona como uma espécie de armadilha digital. Ambos os termos brincam com a palavra "honey", já que essa técnica funciona como o "pote de mel" que atrai os atacantes.
Também existem os decoys, que imitam recursos legítimos do ambiente, e os canary tokens, que são elementos configurados para gerar um alerta quando são utilizados ou acessados.
Apesar das diferenças, todas essas técnicas trabalham com uma mesma ideia de criar algo que pareça interessante para um atacante, mas que a interação seja suspeita para a organização.
Em uma rede corporativa com centenas de contas de usuários, é de se esperar que algumas delas realizem centenas ou milhares de autenticações ao longo do dia. Se uma dessas contas apresentar um comportamento diferente, como várias tentativas de acesso, o caminho mais comum é analisar diversos eventos para determinar se existe realmente um problema.
Agora imagine uma conta chamada admin_financeiro que não pertence a nenhum funcionário, que não é utilizada por nenhuma aplicação e que foi criada exclusivamente para monitoramento. Uma tentativa de acesso com essa conta tem outro peso.
Ela existe somente para servir de isca, pois, em condições normais, ninguém deveria utilizá-la.
Essa é uma das principais características da deception: a possibilidade de gerar alertas de alta confiança. Em vez de procurar apenas algo que parece estranho em vários eventos, a equipe monitora uma interação que realmente não deveria acontecer.
Por que honeytokens podem revelar um atacante dentro da rede?
O monitoramento não deve parar no acesso. Um invasor que consegue acesso inicial a uma organização ainda precisa descobrir onde estão as informações e os sistemas que podem ser interessantes para seus objetivos.
Durante essa exploração, ele pode procurar usuários privilegiados, arquivos, credenciais, chaves de acesso e outros recursos. É durante essa ação que a organização continua monitorando, buscando entender qual a intenção e o destino final pretendido pelo invasor.
No último exemplo, falamos sobre a conta fictícia admin_financeiro, mas o mesmo princípio pode ser aplicado a outros elementos:
credenciais falsas;
tokens de autenticação;
chaves de API;
arquivos e documentos falsos;
registros falsos em bancos de dados;
URLs ou links que não deveriam ser acessados.
A escolha do elemento também precisa fazer sentido dentro do ambiente. Uma isca muito evidente pode ser ignorada por um atacante, enquanto um recurso que se parece com algo real pode ter mais chances de ser explorado.
Por isso, o objetivo não é simplesmente criar o maior número possível de honeytokens. É identificar quais recursos poderiam despertar o interesse de um atacante e, ao mesmo tempo, gerar um sinal relevante para a equipe de segurança.
Pesquisas experimentais já mostram como essa estratégia pode ser útil para as organizações. Em um estudo publicado pela USENIX, pesquisadores avaliaram o uso de decoys com profissionais de segurança em exercícios controlados. Quando os decoys estavam presentes, todos os participantes acionaram um alerta relacionado a eles antes de explorar um ativo real. Além disso, o principal objetivo da deception foi alcançado: os pesquisadores observaram uma redução nos ataques direcionados aos ativos reais.
Isso mostra que a deception cumpre seu propósito: ela pode criar obstáculos, atrasar o avanço do invasor e, principalmente, ajudar a revelar onde ele está.
Onde o SIEM entra na estratégia de cyberdeception?
Um honeytoken pode indicar que algo está errado, mas ele é apenas um ponto em toda a história que precisa ser contada.
Saber que alguém utilizou uma credencial falsa é importante, mas saber quem utilizou, de onde veio o acesso e o que aconteceu antes e depois pode ser ainda mais importante. É nesse ponto que o SIEM entra para complementar a estratégia de cyberdeception.
O fluxo pode começar com a criação do honeytoken. Quando um atacante interage com ele, o evento é registrado. O SIEM recebe essa informação e pode relacioná-la a outros acontecimentos registrados no ambiente, sem necessitar de um estudo e correlação manual de logs.
Por exemplo, se uma credencial falsa foi utilizada, os registros podem ajudar a identificar de onde veio a tentativa e qual endpoint estava envolvido. A partir daí, a investigação pode procurar outras atividades realizadas pelo mesmo dispositivo ou usuário.
Dependendo dos dados disponíveis, a equipe pode descobrir:
a origem do acesso;
a conta ou credencial utilizada;
o endpoint comprometido;
os recursos procurados;
possíveis tentativas de movimentação lateral;
os sistemas que despertaram interesse;
a sequência de ações realizadas.
Isso muda a função do honeytoken dentro de uma investigação.
Em vez de simplesmente informar que uma atividade suspeita aconteceu, ele pode ajudar a responder perguntas sobre o comportamento do atacante.
Assim, um evento que, isoladamente, já seria suspeito, passa a fazer parte de uma sequência de atividades que podem revelar ainda mais informações sobre o atacante.
Como aplicar cyberdeception sem criar novos riscos?
Cyberdeception não significa sair espalhando contas e arquivos falsos pela rede e esperar que alguém interaja com eles.
A estratégia precisa ser planejada para que os elementos criados sejam convincentes, seguros e realmente úteis para a detecção.
Um primeiro ponto é escolher recursos que façam sentido dentro do ambiente. Uma conta administrativa fictícia pode ser interessante em uma rede com várias contas privilegiadas. Da mesma forma, um arquivo falso pode fazer sentido em um servidor onde documentos semelhantes já existem.
Também é importante garantir que a armadilha não se transforme em uma porta de entrada real. Ela deve ser controlada e configurada de maneira que uma eventual interação não ofereça ao invasor uma oportunidade de comprometer outros sistemas.
Outro cuidado está na definição dos eventos que devem gerar os alertas. Se qualquer interação produzir notificações sem critério, a equipe pode acabar criando mais ruído do que informação realmente útil.
A centralização também faz diferença. Se o evento gerado pelo honeytoken fica em uma fonte de log e as informações sobre o endpoint estão em outra, a investigação pode depender de consultas manuais a diferentes sistemas. É nesse ponto que ferramentas de SIEM são essenciais para garantir a correlação de eventos de maneira prática.
Por fim, os elementos precisam acompanhar as mudanças do ambiente. Uma isca que fazia sentido quando foi criada pode deixar de parecer legítima depois de uma alteração na infraestrutura.
Por isso, deception deve ser tratada como uma camada adicional de segurança, e não como substituta para controles tradicionais. O próprio trabalho experimental publicado pela USENIX, citado anteriormente, aponta que a estratégia deve funcionar como um complemento para outras ferramentas de segurança, não funcionando de maneira isolada.
Como o ManageEngine Log360 apoia a detecção com cyberdeception?
O cyberdeception vai gerar alertas e o SIEM ajuda a transformá-los em contexto. Esse é o ponto de conexão entre os honeytokens e oManageEngine Log360.
Em uma estratégia de deception, o Log360 pode centralizar os eventos relacionados às interações com esses elementos e correlacioná-los com outras atividades registradas no ambiente.
A solução reúne logs de diferentes fontes e permite acompanhar atividades de usuários, correlacionar eventos, identificar comportamentos anormais, gerar alertas e centralizar a investigação.
Voltando ao exemplo da conta admin_financeiro, sabendo que houve uma interação com a armadilha, a equipe pode investigar o endpoint responsável pelo acesso, consultar as autenticações realizadas anteriormente, verificar outros recursos acessados e relacionar esses eventos a outras atividades suspeitas.
Assim, uma interação que poderia parecer pequena ganha importância quando analisada dentro do contexto maior do incidente.
Cyberdeception e SIEM, portanto, se complementam, cada estratégia com seu papel. A deception vai criar as armadilhas e o SIEM reunirá os eventos necessários para entender o que essa interação significa dentro do ambiente.
Conheça o ManageEngine Log360 e veja como centralizar a detecção, correlação e investigação de eventos de segurança no seu ambiente. Clique aqui e faça um teste grátis!
Nota: Encontre a revenda da ManageEngine certa. Entre em contato com a nossa equipe de canais pelo e-mail latam-sales@manageengine.com.
Importante: a ManageEngine não trabalha com distribuidores no Brasil.