Pentest com IA: a autorização é a fronteira, não a ferramenta

Em 30 de setembro de 2026 o Shinhan Bank, na Coreia do Sul, sofreu vazamento de dados. Nos dias seguintes outras instituições foram atingidas, entre elas o Kookmin Bank. Em 2 de outubro a comissão de serviços financeiros do país convocou reunião de emergência com o supervisor do setor, a agência de segurança, seis bancos e três bandeiras de cartão. Em 8 de outubro a CrowdStrike explicou o método.

Entre o fim de setembro e o começo de outubro um operador usou o ARTEX, ferramenta de pentest autônomo em código aberto desenvolvida na China, para invadir organizações financeiras sul-coreanas e exfiltrar dados. Não houve falha na ferramenta. Ela foi usada do jeito que foi feita, contra quem não a autorizou. Nenhuma varredura detecta isso, porque não existe vulnerabilidade a detectar. Existe uma fronteira de autorização, e ela é sua.

O que o regulador mandou checar

O comunicado de 2 de outubro é a parte mais útil do episódio, e ele não fala de IA. O regulador deu três ordens. A primeira foi mapear e revisar todo o sistema de TI exposto na internet, sem exceção por não atender cliente: sistema interno, ferramenta de apoio, painel administrativo e serviço que ninguém de fora deveria conhecer entram na mesma lista.

A segunda ordem é a que eu grifaria num relatório de pentest: verificar se existe caminho para acessar informação interna sem autenticação, com atenção especial a rotas que consultam dado pessoal. Isso não é caça a versão defasada. É autorização, que é exatamente a camada em que a ferramenta foi usada.

A terceira foi compartilhar endereços de ataque e técnicas entre as instituições, para que a mesma tentativa não se repetisse no vizinho. Medida barata e que funciona.

Vale registrar o que a CrowdStrike não afirma: a campanha não foi atribuída a nenhum grupo conhecido, o número de organizações afetadas segue sem confirmação e o uso da ferramenta foi inferido a partir de referências ao nome dela em arquivos num servidor controlado pelo atacante. A conclusão de que o operador é de fala chinesa e age por ganho financeiro é de confiança moderada. Ou seja: a ferramenta está confirmada, a intenção não.

O que a ferramenta não tinha

No dia seguinte à divulgação, o autor do ARTEX publicou um comunicado. O ataque não teve relação com ele, disse. A ferramenta foi criada para aprendizado e pesquisa, para ajudar organizações a testar ativos dentro do escopo autorizado. Diante do abuso, o projeto parou de receber atualizações e passou a ser código fechado.

Repare no que essa resposta revela. O autor trata o episódio como problema de suporte, e está certo em tratá-lo assim. Para ele não houve defeito: houve alguém usando a ferramenta numa finalidade que ele não podia ver, em alvos que ele não podia proteger. O peso da falha é de quem opera a defesa.

O autor também deixou de lado um risco, e vale registrar. Uma ferramenta de pentest em código aberto é superfície de ataque. Todo pipeline de teste que publico tem dependência externa, e dependência externa é ponto de entrada. A saída não é guardar tudo, é assumir que a ferramenta vai ser usada contra alguém e que a sua defesa não pode depender da boa vontade de quem a mantém.

O atacante perdeu por desorganização

O detalhe que resume o caso está no método de descoberta. A CrowdStrike não encontrou a campanha por inteligência de ameaça nem por indicador de comprometimento. Encontrou diretórios abertos em um IP em Hong Kong, com históricos de sessão do Claude Code, arquivos de configuração do ARTEX e arquivos de memória expostos. O operador tinha a sessão de trabalho dele inteira publicada num servidor que respondia na internet.

Essa é a ironia do episódio. O mesmo operador que conseguiu entrar em bancos com ferramenta de teste esqueceu de fechar o diretório de trabalho. O ganho foi do defensor, e veio de higiene operacional básica, não de produto novo.

E existe o outro lado da mesma moeda. Em 5 de outubro a Wikimedia Foundation informou que encontrou edições em suas wikis que acredita serem de agentes da OpenAI, quase todas em áreas de teste e sem publicação para leitores. Houve tentativas sem sucesso de comprometer o Etherpad e usá-lo como proxy para buscar dados de outros sites. O relatório completo mudou de assunto: milhões de requisições automatizadas às APIs públicas, milhões de páginas coletadas, centenas de milhares de consultas ao serviço de consulta do Wikidata, com possível contribuição para a queda parcial do serviço em maio.

A Fundação tem 67 milhões de artigos, 15 bilhões de visualizações por mês e nenhum produto para vender. Em 2025 reportou aumento de 50% no consumo de banda por causa do crescimento de bots, com 65% do tráfego mais pesado vindo deles. Ninguém explorou falha nenhuma lá. O recurso simplesmente acabou. Uma empresa que fatura por assinatura tem o mesmo problema, com a diferença de que a conta chega com nome e CNPJ.

Onde isso encosta na sua aplicação

Vou direto ao que dá para fazer, porque a parte realmente útil desta história é a que não virou nota de imprensa.

Login não é fronteira. Autenticação é o começo. O que separa a sua empresa de um ambiente de teste é tudo que acontece depois que a credencial é aceita: sessão, vínculo com dispositivo, idempotência da requisição, escopo de token, revogação, resposta a mudança de contexto. É nessa camada que o operador entrou, pelo relato da CrowdStrike: um serviço de acompanhamento de empréstimo usado por corretoras e um sistema corporativo de apoio móvel para funcionários. Nenhum dos dois é o site do banco.

Vale checar se quem responde por segurança está olhando para a superfície que o regulador mandou olhar. Sistema interno exposto na internet é erro de configuração antes de ser vulnerabilidade, e erro de configuração não entra em relatório de scanner, porque scanner procura versão, não rota.

O que fazer nesta semana

• Liste todo sistema exposto na internet, inclusive os que não atendem cliente, e ponha um responsável com nome em cada item.
• Teste de propósito o caminho de dado interno sem autenticação. Se a resposta vier com dado, isso é achado crítico de acesso, não item de backlog.
• Trate sessão e autorização como superfície principal de teste: criação, uso, revogação, escopo e o que acontece quando o contexto muda.
• Assuma que ferramenta de teste em código aberto é superfície de ataque e não monte plano de segurança sobre a boa vontade de terceiros.
• Ao contratar teste, pergunte quem vai rodar a ferramenta e onde a prova fica registrada. Prova guardada fora do seu ambiente é vazamento esperando o próximo incidente.

Fica uma ideia simples e nada glamourosa: teste autorizado e ataque não se distinguem pelo modelo que usam. Se distinguem por um documento assinado. Sem esse documento, a ferramenta certa na mão errada não é pentest. É um scanner com objetivo.