Agente de IA foi do WordPress ao disco de um executivo, e a defesa pegou 14 de 15 etapas

A defesa clássica vive de regras: viu uma ferramenta conhecida ou uma string no log, dispara um alerta. Um agente de IA atacante quebra esse modelo. Ferramentas, nomes de arquivos, portas e técnicas de ofuscação são para ele meras variáveis, e ele as troca na hora. Enquanto o analista escreve uma regra para um utilitário, o agente já pegou outro. Além disso, é difícil para as pessoas processar um fluxo de alertas no ritmo ditado pela máquina.

Os especialistas da Positive Technologies verificaram em uma bancada de laboratório se a abordagem comportamental funciona. Um agente RedTeam, que imita um invasor, recebeu um objetivo: chegar aos documentos de um executivo. A defesa não estava ajustada para o laboratório.

Como o agente percorreu a rede

A bancada parecia uma pequena rede corporativa: WordPress no perímetro, o e-mail Exchange, um controlador de domínio, um servidor de certificados ADCS e estações de trabalho. O operador dava dicas, mas os passos e as ferramentas eram escolhidos pelo agente. O ataque levou várias horas.

Ele começou por um plugin vulnerável do WordPress e pelo upload de um webshell PHP. Depois explorou um erro de configuração do sudo: o awk pode ser executado sem senha, e por meio dele qualquer comando roda como root. Assim surgiu o primeiro túnel. Em seguida, via ProxyLogon, tomou o Exchange, montou um segundo túnel, obteve um certificado por meio de um modelo ADCS vulnerável (ESC1), extraiu os hashes do domínio com DCSync e forjou um ticket Kerberos Golden Ticket. O controlador de domínio tornou-se o terceiro ponto de apoio, depois do que o agente percorreu seis estações de trabalho e examinou o disco do executivo.

A técnica central aqui são os pivôs: um servidor capturado vira um proxy SOCKS5, e o tráfego seguinte sai do seu endereço. Ao todo foram três. O perímetro de rede não se incomoda com esse tráfego, porque ele vem de dentro.

O que havia do lado da defesa

O esquema tem duas camadas. O MaxPatrol BAD, um módulo de ML dentro do SIEM, seleciona anomalias: desvios no comportamento de processos e usuários, independentemente da ferramenta. Elas se chamam indicadores de comportamento. É um pré-filtro, porque um LLM não consegue analisar sozinho o fluxo bruto de eventos do SIEM.

A segunda camada é a classificação, pois nem toda anomalia significa um ataque. O HackTracker recebe do BAD a descrição do comportamento e emite um veredito: malicioso ou legítimo. Ele não conhece ferramentas específicas e, de propósito, não dá explicações, em nome da precisão. As explicações vêm do PT Naira, um assistente de IA que analisa a cadeia de processos escolhida pelo analista, e de um agente de IA interno para o BAD, que recebe os alertas com eventos normalizados. O agente ainda não é um produto, mas uma demonstração.

O exemplo do Exchange mostra como funciona. O pool de aplicações do IIS gera powershell.exe com janela oculta e sem perfil, seguido de um bypass do AMSI, da desativação do registro de scripts e da remoção do atributo somente leitura do webshell. Cada ação isolada pode ser legítima, mas a cadeia forma um padrão de ataque. O túnel é pego da mesma forma: o certutil baixa um arquivo, que se disfarça de svchost32.exe e se conecta ao C2 com parâmetros SOCKS.

No host Unix com WordPress o cenário é diferente. O HackTracker por enquanto só trabalha com eventos do Windows, então ali o veredito foi construído pelos indicadores do BAD e pelo agente de IA: um shell a partir do apache2, reconhecimento a partir do www-data, download de um binário em /tmp, escalonamento via sudo por meio de um interpretador.

O que se conclui disso

A conclusão prática é simples: é preciso detectar cadeias de comportamento, não nomes de utilitários. Se a defesa se apoia em assinaturas de ferramentas específicas, um agente de IA a contorna apenas trocando de software. Ainda assim, analisar cada alerta continua sendo tarefa de uma pessoa, e o explicador baseado em LLM reduz o tempo até o veredito. Vale também verificar as coisas banais que o agente usou como degraus: sudo sem senha para o awk, um Exchange sem patch, modelos ADCS vulneráveis.

É preciso ter as limitações em mente. É um único cenário em um único laboratório, conduzido pelo próprio fornecedor. O resultado «14 de 15» não diz nada sobre a taxa de falsos positivos em uma rede real, com milhares de administradores e infraestrutura complexa. A cobertura de Unix no HackTracker ainda é incompleta, e o agente de IA ainda não foi lançado como produto. O teste mostra que um ataque de IA deixa rastro comportamental, mas não prova que a defesa funcionará da mesma forma na sua rede.