A segurança cibernética tradicional foi construída, em grande parte, para impedir que o atacante alcance aquilo que deseja comprometer. Firewalls controlam conexões, WAFs analisam requisições antes que cheguem às aplicações, EDRs monitoram endpoints e SIEMs correlacionam grandes volumes de eventos produzidos por diferentes tecnologias.
Todas essas camadas continuam essenciais. Porém, existe uma abordagem complementar que muda a relação entre atacante e defensor: em vez de apenas tentar esconder ou proteger todos os ativos reais, podemos deliberadamente apresentar ao adversário ativos criados especificamente para serem encontrados e atacados.
É nesse contexto que entram os honeypots modernos e as tecnologias de Cyber Deception.
Um honeypot pode se apresentar como uma aplicação Web, um painel administrativo, uma API, um servidor, um arquivo aparentemente sensível, uma credencial ou mesmo um produto corporativo específico. Para quem está atacando, aquilo parece uma oportunidade. Para a equipe de segurança, é um sensor cuidadosamente controlado.
A diferença é fundamental: enquanto um sistema de produção existe para ser utilizado legitimamente, um honeypot existe para observar quem tenta interagir com ele de maneira indevida.
Por que um honeypot produz um sinal tão valioso?
Um dos principais problemas de uma operação de segurança é o volume de dados. Aplicações recebem tráfego legítimo, bots de mecanismos de busca, integrações, APIs, health checks, usuários e automações. Um SOC precisa separar atividade normal de comportamento potencialmente hostil em meio a milhões de eventos.
Um honeypot trabalha com uma lógica diferente. Se determinado ativo foi criado exclusivamente como isca, uma tentativa de enumeração, autenticação ou exploração já possui um contexto muito mais significativo.
Uma requisição procurando um arquivo .env, por exemplo, pode ser apenas mais um evento em um servidor de produção. Em um sensor criado exclusivamente para deception, ela se torna parte de uma atividade deliberada de reconhecimento.
Esse contexto permite transformar interações aparentemente simples em informações de alto valor: quais caminhos estão sendo procurados, quais credenciais estão sendo testadas, quais CVEs estão sendo exploradas, quais ferramentas parecem estar sendo utilizadas e qual sequência de ações o adversário executa durante a interação.
O valor não está apenas em saber que houve um ataque, mas em compreender como ele aconteceu.
De honeypot para Cyber Deception
Honeypots tradicionais costumavam ser relativamente simples. Muitas vezes, bastava abrir um serviço, responder a algumas requisições e registrar quem interagia com ele.
Esse modelo ainda possui utilidade, mas adversários modernos e scanners mais sofisticados conseguem identificar ambientes artificiais através de pequenos detalhes. Headers HTTP, cookies, redirects, certificados TLS, páginas de erro, estrutura HTML, comportamento de paths inexistentes e até padrões de resposta podem denunciar uma implementação superficial.
Por isso, a Cyber Deception moderna precisa trabalhar com um conceito muito mais importante: coerência.
Se um sensor se apresenta como determinado produto, o comportamento daquele host precisa continuar fazendo sentido quando o atacante investiga mais profundamente. Não basta copiar uma tela inicial. O conjunto de respostas precisa sustentar a identidade que está sendo apresentada.
É nesse contexto que surgem conceitos como fachadas, personas e fidelidade de comportamento.
No XLabs Honeypot, fachada e persona possuem funções distintas. A fachada define como o ativo se apresenta inicialmente, enquanto a persona pode limitar o sensor a uma identidade tecnológica específica. Quando uma persona é utilizada, o ambiente evita responder simultaneamente como diferentes produtos incompatíveis, aumentando a coerência da superfície apresentada ao adversário.
O objetivo deixa de ser apenas disponibilizar uma URL vulnerável. O objetivo passa a ser fazer com que o adversário acredite que encontrou o sistema que estava procurando.
Simular vulnerabilidades sem transformar o honeypot em um risco
Existe uma diferença importante entre simular uma vulnerabilidade e realmente colocar um software vulnerável em produção.
Um honeypot mal projetado pode acabar se tornando infraestrutura do próprio atacante. Uma RCE real pode permitir execução de comandos, uma SSRF real pode atingir outros sistemas e um proxy falso mal implementado pode acabar funcionando como relay para ataques contra terceiros.
Por isso, uma arquitetura comercial de deception precisa separar cuidadosamente aparência de execução.
No XLabs Honeypot, diferentes classes de ataque podem receber respostas coerentes com uma exploração sem necessariamente executar o payload enviado pelo adversário. LFI pode retornar arquivos fictícios, SSRF pode ser simulada sem realizar conexões externas, command injection pode gerar uma resposta sintética e SQL Injection pode operar sobre um ambiente restrito e isolado.
O agente também foi desenvolvido com uma política explícita de contenção: não executa diretamente payloads de RCE, OGNL, JNDI, PHP ou outras linguagens enviadas pelo atacante; o objetivo é observar a intenção ofensiva sem entregar ao adversário uma máquina real para controlar.
Essa é uma das diferenças mais importantes entre um ambiente deliberadamente inseguro e uma verdadeira plataforma de Cyber Deception.
Entender a jornada do atacante
Analisar cada request individualmente é útil, mas não suficiente.
Imagine observar a seguinte sequência ao longo de alguns minutos: o atacante procura um .env, acessa uma página de login, tenta diferentes credenciais, enumera um componente da aplicação e posteriormente envia um payload relacionado a uma CVE.
Se cada ação for tratada como um evento isolado, parte importante do contexto é perdida.
Uma plataforma de deception pode correlacionar essas interações e reconstruir uma jornada ofensiva.
O XLabs Honeypot mantém sessões utilizando informações da origem, User-Agent e fingerprints de conexão, além de acompanhar o nível de engagement do atacante durante a interação. O comportamento pode evoluir de reconhecimento para probe, exploração e níveis mais profundos de interação.
Isso permite responder perguntas muito mais úteis para uma equipe de segurança: o atacante chegou por reconhecimento genérico ou já conhecia o alvo? Tentou várias tecnologias? Testou credenciais? Explorou uma CVE específica? Continuou interagindo depois de acreditar que obteve sucesso?
Essa visão transforma registros isolados em comportamento ofensivo observável.
Tarpit: quando o tempo do atacante também trabalha a favor da defesa
Nem toda técnica de deception precisa estar ligada à aparência do alvo. O tempo também pode ser utilizado como recurso defensivo.
Scanners automatizados dependem de velocidade. Para serem eficientes, precisam testar milhares ou milhões de combinações em pouco tempo.
Um tarpit altera essa dinâmica introduzindo atrasos controlados para origens que demonstram comportamento repetitivo ou agressivo.
O XLabs Honeypot possui um mecanismo de atraso progressivo por IP que pode reduzir a velocidade de scanners sem necessariamente encerrar a interação.
A finalidade não é simplesmente deixar uma ferramenta lenta. O objetivo é aumentar o custo da automação ofensiva enquanto o sensor continua coletando telemetria.
Em Cyber Deception, até o tempo desperdiçado pelo adversário pode ter valor.
Uma arquitetura distribuída de sensores
Um dos pontos mais interessantes de uma plataforma moderna de deception é que não existe uma única arquitetura válida.
O sensor deve ser colocado onde a organização deseja criar observabilidade e onde um adversário tenha probabilidade razoável de encontrá-lo.
O agente XLabs pode operar em Windows, Linux, macOS e Android, permitindo diferentes modelos de implantação e reduzindo a necessidade de infraestrutura dedicada em todos os pontos da rede.
A escolha da arquitetura depende principalmente da ameaça que se deseja observar.
| Arquitetura | Principal objetivo |
|---|---|
| LAN corporativa | Detectar reconhecimento e movimentação lateral |
| VLAN administrativa | Criar canários em redes sensíveis |
| Filiais | Distribuir presença de deception geograficamente |
| Wi-Fi corporativo/guest | Detectar comportamento ofensivo dentro do segmento |
| DMZ | Expor superfícies controladas próximas ao perímetro |
| Internet | Capturar scanners, botnets, mass exploitation e campanhas externas |
Sensores dentro da LAN
Dentro de uma rede corporativa, um honeypot funciona como um canário.
Ele não precisa observar passivamente todo o tráfego da rede. Sua função é existir em um local onde um usuário ou sistema legítimo normalmente não teria motivo para interagir.
Se uma estação começa a enumerar esse sensor, testar páginas administrativas, procurar arquivos sensíveis ou tentar explorar uma vulnerabilidade, esse comportamento ganha relevância imediata.
Esse tipo de arquitetura pode ajudar a identificar reconhecimento interno, movimentação lateral e equipamentos potencialmente comprometidos.
O sensor recebe as conexões dentro da própria rede e envia sua telemetria ao C2 através de HTTPS. O agente foi desenvolvido justamente como um sensor on-prem, mantendo a superfície de deception próxima ao ambiente que está sendo observado.
Sensores distribuídos em filiais
Empresas com várias unidades apresentam um desafio diferente.
Manter um appliance ou uma máquina virtual dedicada em cada filial pode aumentar significativamente o custo operacional de uma estratégia de deception.
Uma arquitetura de sensor leve permite distribuir pontos de observação utilizando a infraestrutura já existente.
Um computador antigo, um mini-PC, um equipamento ARM ou até um dispositivo Android dedicado podem assumir uma nova função.
O agente Android da XLabs utiliza o mesmo conceito de sensor e foi desenvolvido para funcionar como um canário dentro da LAN, mantendo o serviço em execução e enviando telemetria ao C2.
Isso cria uma possibilidade particularmente interessante: aumentar a densidade de sensores sem aumentar proporcionalmente o custo de hardware.
Em vez de perguntar quantos honeypots uma empresa possui, passa a fazer mais sentido perguntar quantas áreas da infraestrutura possuem algum ativo de deception.
Reutilização de hardware legado
A portabilidade do agente também abre uma possibilidade operacional importante.
Muitos dispositivos deixam de ser adequados para aplicações produtivas muito antes de perderem toda sua capacidade computacional.
Um notebook antigo talvez já não seja adequado para um usuário corporativo. Um tablet pode ter perdido sua função original. Um computador compacto pode ter sido substituído por hardware mais moderno.
Mas esses equipamentos ainda podem possuir recursos suficientes para receber conexões, responder superfícies simuladas, manter sessões e transmitir telemetria.
Nesse cenário, hardware que normalmente seria descartado pode ganhar uma segunda vida como infraestrutura defensiva.
Isso não significa que qualquer dispositivo antigo deva ser colocado indiscriminadamente em uma rede. Atualizações do sistema operacional, isolamento, estabilidade, disponibilidade de energia e políticas de rede continuam relevantes.
A vantagem está na possibilidade de utilizar hardware simples para uma função que tradicionalmente poderia exigir uma VM ou appliance dedicado.
Sensores em redes Wi-Fi
Redes Wi-Fi também podem se beneficiar dessa lógica.
Um sensor conectado a uma rede específica pode se apresentar como mais um ativo daquele segmento. Ele não precisa capturar o tráfego dos outros dispositivos nem substituir tecnologias de IDS ou NDR.
Sua função é ser encontrado.
Se alguém conectado àquela rede começa a varrer portas, acessar painéis administrativos, testar credenciais ou procurar vulnerabilidades, o sensor fornece um ponto adicional de detecção.
A estratégia pode ser particularmente útil em redes de visitantes, filiais e ambientes onde um comportamento de reconhecimento não deveria ocorrer.
O honeypot não precisa enxergar tudo.
Ele só precisa ser interessante o suficiente para que uma atividade ofensiva decida tocá-lo.
DMZ e perímetro
Outra possibilidade é colocar sensores em uma DMZ ou segmento de borda.
Nesse modelo, o honeypot pode representar um ativo aparentemente pertencente à organização, mas permanecer completamente separado dos sistemas reais.
A segmentação continua essencial. Um sensor criado para receber atividade hostil não deve possuir relações de confiança desnecessárias com ambientes críticos.
O ideal é que o ambiente de deception tenha regras específicas de entrada e saída, mantendo a interação restrita ao contexto para o qual foi construído.
Essa arquitetura permite criar superfícies deliberadamente atraentes próximas ao perímetro sem precisar colocar os verdadeiros sistemas de produção em risco.
Honeypot exposto diretamente à Internet
Embora o agente XLabs tenha sido desenvolvido principalmente para utilização em redes locais e ambientes on-premise, ele não precisa ficar restrito à LAN.
Com a arquitetura de rede correta, o listener pode ser publicado externamente através de um endereço IP público ou de regras de NAT e firewall.
A estrutura pode ser simples:
Internet → IP público → Firewall/NAT → segmento de deception → XLabs Honeypot
Enquanto a administração segue em sentido independente:
XLabs Honeypot → HTTPS → C2
O agente mantém comunicação com o C2 utilizando HTTPS, realizando heartbeat, recebendo configurações e transmitindo eventos coletados.
Quando exposto à Internet, o sensor passa a observar outro tipo de atividade: scanners globais, botnets, tentativas automatizadas contra CVEs, credential attacks, pesquisas por arquivos sensíveis e campanhas de mass exploitation.
Essa diferença de posicionamento produz dois tipos complementares de inteligência.
Um sensor interno ajuda a responder:
Quem está procurando coisas que não deveria procurar dentro da minha rede?
Um sensor externo ajuda a responder:
O que os atacantes da Internet estão procurando neste momento?
Ambos possuem valor, mas respondem a perguntas diferentes.
Deception como fonte de Threat Intelligence
Um único sensor produz eventos.
Uma rede distribuída de sensores pode produzir contexto.
Quando dezenas de sensores começam a observar o mesmo caminho, o mesmo payload ou a mesma sequência de reconhecimento em um intervalo curto, aquilo deixa de ser simplesmente uma coleção de requests.
Pode ser uma campanha.
Esse é um dos pontos em que Cyber Deception começa a se aproximar diretamente de Threat Intelligence.
Uma rede distribuída pode ajudar a identificar quando determinado vetor começou a aparecer, quais regiões estão recebendo a atividade, quais infraestruturas estão originando os ataques e quais tecnologias estão sendo pesquisadas com maior frequência.
Com o crescimento da base de sensores, cresce também a capacidade de comparar eventos entre diferentes organizações e contextos.
O ativo estratégico deixa de ser apenas o honeypot individual.
Passa a ser a rede de observação formada por todos eles.
Do honeypot para o WAF
Para a XLabs existe ainda uma possibilidade adicional.
A empresa também desenvolve tecnologias de proteção de aplicações Web.
Isso permite pensar na deception não como uma ferramenta isolada, mas como uma possível fonte de inteligência para outras camadas defensivas.
Um sensor observa um novo payload. Outros sensores começam a receber a mesma técnica. O comportamento é correlacionado e classificado. Essa inteligência pode posteriormente ser utilizada por operações de SOC, SIEM, automações e pelo próprio ecossistema de proteção Web.
Conceitualmente, o ciclo é:
Deception → observação → correlação → Threat Intelligence → proteção
O honeypot passa então a desempenhar também o papel de um radar antecipado.
Em vez de esperar que todas as técnicas apareçam primeiro contra as aplicações de produção, parte delas pode ser observada em superfícies que foram construídas exatamente para serem atacadas.
O honeypot não substitui as outras camadas de segurança
Cyber Deception não deve ser entendida como substituta de WAF, firewall, EDR, SIEM ou NDR.
Ela acrescenta uma capacidade diferente.
Um firewall tenta impedir determinada comunicação.
Um WAF tenta impedir que determinado payload chegue à aplicação.
Um EDR observa comportamento suspeito no endpoint.
Um honeypot faz algo diferente:
oferece deliberadamente um alvo que queremos que o adversário encontre.
Essa diferença é importante porque muda a lógica da interação.
Em produção, queremos interromper rapidamente o ataque.
Em um ambiente controlado de deception, pode ser interessante observar o adversário por mais tempo, desde que a interação permaneça segura.
Quanto maior a interação, maior pode ser a quantidade de informação obtida sobre ferramentas, técnicas, payloads, infraestrutura e objetivos.
Hack the Hackers
Na XLabs utilizamos a expressão Hack the Hackers para representar essa inversão de perspectiva.
Ela não significa hack-back, invasão do dispositivo do atacante ou qualquer ação ofensiva contra infraestrutura de terceiros.
Significa utilizar a atividade do próprio adversário como fonte de inteligência.
Quando ele faz reconnaissance, aprendemos o que procura. Quando envia um exploit, registramos o payload. Quando testa credenciais, observamos sua técnica. Quando utiliza scanners, identificamos padrões. Quando insiste em uma superfície falsa, acompanhamos sua jornada.
O atacante acredita estar estudando a infraestrutura.
Ao mesmo tempo, a infraestrutura está estudando seu comportamento.
XLabs Honeypot: da superfície de ataque para uma superfície de inteligência
O XLabs Honeypot foi desenvolvido como uma plataforma de Web Deception e Threat Intelligence, com sensores distribuídos, gerenciamento centralizado e superfícies capazes de simular diferentes tecnologias e classes de vulnerabilidades.
Esses sensores podem ser implantados dentro da rede corporativa, em filiais, redes Wi-Fi, DMZs ou, quando houver uma arquitetura adequada de endereçamento, NAT, firewall e isolamento, ser publicados para receber tráfego diretamente da Internet.
O princípio continua sendo o mesmo em qualquer dessas arquiteturas:
criar algo que o adversário queira encontrar e transformar cada interação em informação para a defesa.
Com personas mais fiéis, correlação de sessões, simulação controlada de vulnerabilidades, mecanismos de tarpit e uma arquitetura capaz de funcionar em diferentes plataformas, o honeypot deixa de ser apenas uma máquina esperando ataques.
Ele passa a fazer parte de uma estratégia distribuída de Cyber Deception.
E, quanto maior essa rede de sensores se torna, maior também pode ser a capacidade de transformar ataques individuais em inteligência sobre campanhas, técnicas e comportamentos ofensivos.
Eles procuram vulnerabilidades. Nós simulamos vulnerabilidades para eles encontrarem.
Conheça o XLabs Honeypot em https://honeypot.xlabs.com.br/.
XLabs Security — Hack the Hackers.
