Ataques da ARTEX a bancos sul-coreanos expõem o risco de agentes de pentest com IA

Os ataques da ARTEX a bancos sul-coreanos teriam permitido que um único operador visasse várias instituições financeiras em poucos dias, transformando uma estrutura de testes defensivos em infraestrutura ofensiva. A CrowdStrike afirma que a campanha ocorreu do fim de setembro ao início de outubro de 2026 e resultou em roubo de dados. As evidências ligam ARTEX, vários modelos de linguagem de grande porte e sessões do Claude Code a uma infraestrutura associada à operação.

O incidente não é apenas mais um caso de um hacker pedindo código malicioso a um chatbot. ARTEX é uma estrutura de testes de penetração agêntica, o que significa que pode organizar várias tarefas assistidas por IA em torno de um alvo definido. Essas tarefas podem incluir a coleta de informações, a identificação de fragilidades, o planejamento de vetores de ataque, a execução de ferramentas de segurança e a verificação de que uma vulnerabilidade pode ser explorada.

A CrowdStrike encontrou os históricos de sessão do próprio operador, arquivos de configuração e arquivos de memória de IA em diretórios expostos. Esses registros deram aos pesquisadores uma visão incomumente detalhada de como ferramentas ofensivas convencionais e agentes de IA trabalharam em conjunto.

Essas evidências também criam uma distinção importante. Um agente de IA não decidiu atacar os bancos de forma independente. Um operador humano teria selecionado os alvos, implantado a infraestrutura, configurado modelos e buscado os dados roubados. A IA parece ter ampliado o alcance e a velocidade operacional dessa pessoa.

O conflito central é, portanto, entre capacidade e controle. A mesma automação que ajuda equipes de segurança a testar sistemas pode ajudar um invasor a examinar muitos serviços expostos de uma só vez. O caso ARTEX sugere que um único operador pode montar uma estrutura de ataque capaz usando software de código aberto, ferramentas comerciais de IA e servidores alugados.

No entanto, fatos importantes continuam indefinidos. Os investigadores não confirmaram publicamente a identidade do invasor, a lista completa de organizações afetadas nem o volume total de informações roubadas. As evidências públicas também não comprovam que a ARTEX concluiu cada invasão de forma autônoma.

O que a CrowdStrike encontrou nos ataques da ARTEX a bancos sul-coreanos

A evidência mais forte não é o nome ARTEX em um servidor. É o conjunto de registros operacionais encontrado ao lado da ferramenta implantada.

Os primeiros relatos se baseavam fortemente em um título HTML contendo uma referência em chinês a um console autônomo de testes de penetração. Essa pista mostrou que uma interface ARTEX existia em uma infraestrutura suspeita. Ela não estabelecia como o software era usado nem se havia invadido algum banco específico.

A análise da campanha da CrowdStrike, de 7 de outubro, acrescentou evidências consideravelmente mais robustas. Os pesquisadores disseram ter encontrado um diretório exposto contendo um arquivo de instruções do Claude Code em um servidor que hospedava a ARTEX. Esse documento incluía um prompt em chinês descrevendo como o modelo deveria conduzir atividades de testes de penetração.

O arquivo de instruções levou os pesquisadores a uma infraestrutura separada baseada em Hong Kong. A CrowdStrike afirmou que diretórios abertos ali continham arquivos de configuração da ARTEX, históricos de sessões do Claude Code e arquivos de memória do Claude. A atividade registrada se sobrepunha a organizações financeiras sul-coreanas identificadas em relatos locais sobre as violações.

A CrowdStrike descreveu uma arquitetura de dois servidores. Um servidor hospedava a instância da ARTEX, enquanto o servidor em Hong Kong funcionava como a infraestrutura principal do operador. A implantação da ARTEX teria usado DeepSeek v4.1-flash como seu backend principal de modelo.

O operador também usou GLM-5.3 e Grok 4.6 durante sessões adicionais do Claude Code, segundo os pesquisadores. Um backend de modelo fornece raciocínio linguístico e orientação de tarefas, enquanto a ARTEX coordena atividades de testes de segurança em torno dessa saída.

Esse arranjo importa porque nenhum produto isolado precisou executar toda a operação. O operador podia usar uma estrutura para testes de penetração automatizados e outros modelos para pesquisa, planejamento ou tarefas de apoio. Essa estrutura modular se assemelha mais à integração comum de software do que a uma arma cibernética autônoma.

A CrowdStrike afirmou que os sistemas visados incluíam um serviço de consulta de empréstimos usado por corretores financeiros e um sistema móvel de suporte ao trabalho usado por funcionários. Eram serviços de apoio, e não plataformas bancárias centrais identificadas publicamente.

Essa distinção ajuda a explicar tanto a exposição de dados quanto a ausência de interrupções relatadas nos serviços bancários comuns. Uma aplicação auxiliar pode conter informações pessoais valiosas sem controlar depósitos, pagamentos ou saldos de contas on-line.

As informações afetadas incluíam, segundo relatos, nomes de clientes, números de telefone, renda anual, limites de empréstimo e dados relacionados a financiamentos. O Shinhan Bank afirmou que informações ligadas a cerca de 25.000 clientes foram comprometidas. O KB Kookmin Bank relatou 119 clientes afetados, enquanto o Hana Bank informou 89.

Outras instituições financeiras sul-coreanas também divulgaram incidentes ou atividades suspeitas. Ainda assim, a relação entre todos os incidentes permanece sob investigação. Infraestrutura e cronologia compartilhadas sustentam uma conexão em nível de campanha, mas não estabelecem automaticamente uma única causa para cada violação relatada.

A CrowdStrike afirmou que o número de organizações afetadas permanecia não confirmado quando publicou sua análise. Essa cautela é importante porque os relatos públicos usam totais diferentes. Alguns contam apenas violações de dados confirmadas, enquanto outros incluem tentativas malsucedidas e instituições que ainda investigam atividades suspeitas.

A pesquisa também revelou um aparente motivo comercial. Registros do Claude Code mostraram o operador perguntando onde dados coreanos roubados costumam ser vendidos. A pessoa também buscou ajuda para encontrar grupos do Telegram relacionados à venda de dados coreanos.

Essas consultas não estabelecem que uma venda ocorreu. Elas sustentam a avaliação da CrowdStrike de que o agente provavelmente tinha motivação financeira, em vez de conduzir espionagem ou interrupções com motivação política.

Como a ARTEX funciona com modelos de linguagem de grande porte

O risco de um agente de pentest com IA vem da automação coordenada, não de um modelo de linguagem que de repente adquire intenção independente.

Entender como a ARTEX funciona começa por sua finalidade pretendida. O teste de penetração é uma tentativa autorizada de encontrar e validar fragilidades de segurança antes que um adversário as explore. Os testes tradicionais exigem que especialistas selecionem ferramentas, interpretem resultados e decidam qual caminho investigar em seguida.

Uma estrutura agêntica pode automatizar partes dessa sequência. Ela pode coletar informações sobre um alvo, identificar serviços expostos, sugerir fragilidades prováveis, acionar ferramentas de teste e avaliar os resultados retornados. O operador ainda define o escopo e fornece a infraestrutura.

Esse fluxo de trabalho pode reduzir o tempo entre a descoberta de um serviço exposto e o teste de possíveis caminhos de acesso. Também pode permitir que uma pessoa examine mais alvos do que um processo totalmente manual permitiria.

A ARTEX não substitui todas as competências técnicas envolvidas em uma invasão. Os modelos podem interpretar sistemas de forma equivocada, gerar comandos inválidos ou seguir caminhos improdutivos. A exploração ainda pode exigir conhecimento sobre autenticação, lógica de aplicação, sistemas operacionais e armazenamento de dados.

Ainda assim, confiabilidade perfeita não é necessária para que um invasor obtenha vantagem. Uma estrutura que lida com descobertas e testes repetitivos pode reservar a atenção do operador para resultados promissores. Tentativas fracassadas se tornam mais baratas quando o software consegue gerá-las e avaliá-las rapidamente.

Esse é o risco prático de agentes de pentest com IA exposto pela campanha sul-coreana. O operador teria combinado a ARTEX com vários modelos, em vez de depender de um único chatbot. Essa abordagem cria redundância e oferece ao invasor ferramentas diferentes para tarefas diferentes.

O uso do Claude Code merece uma contextualização cuidadosa. Claude Code é um agente de codificação com IA projetado para auxiliar em trabalhos de software. A CrowdStrike encontrou seus históricos de sessão e arquivos de memória em infraestrutura conectada à campanha.

Essa descoberta não significa que o Claude Code tenha selecionado ou invadido um banco de forma independente. Significa que o operador utilizou um ambiente de codificação com IA como parte de um fluxo de trabalho mais amplo. As sessões expostas se tornaram evidências porque preservaram prompts e contexto operacional.

A segurança operacional deficiente do operador também moldou o que os pesquisadores puderam descobrir. Diretórios abertos expuseram arquivos que invasores normalmente protegeriam. Esses arquivos incluíam, segundo relatos, históricos de modelos, dados de configuração, detalhes de alvos e informações pessoais inseridas em um pedido de currículo.

Em uma sessão, o usuário pediu um currículo de pesquisador de segurança que mencionava resultados da atividade da ARTEX. O prompt incluía idade, histórico educacional, localização em Guangdong, um número de telefone e um identificador do Telegram.

A CrowdStrike afirmou que esses detalhes provavelmente pertenciam ao operador, mas não pôde estabelecer essa associação de forma definitiva. A idade informada também entrava em conflito com uma data de nascimento incluída anteriormente no prompt. Essas inconsistências tornam uma identificação conclusiva especialmente arriscada.

Os registros expostos demonstram outra troca. Agentes de IA criam logs, arquivos de memória, artefatos de configuração e históricos de prompts que podem ajudar operadores a manter o contexto. Esses mesmos artefatos podem se tornar evidências forenses valiosas quando são armazenados de forma descuidada.

Essa é uma das razões pelas quais explicar invasões bancárias com IA apenas como “IA autônoma” ignora a realidade operacional. A campanha envolveu uma estrutura escolhida por humanos, infraestrutura hospedada, endereços de proxy, software de código aberto e fragilidades de segurança convencionais. A IA conectou e acelerou partes desse sistema.

A cadeia de ferramentas relatada também complica a atribuição de culpa em nível de produto. ARTEX é um software de código aberto destinado a testes autorizados. Claude Code e os modelos de linguagem mencionados são sistemas de uso geral. O suposto uso indevido surgiu da forma como um operador os montou e orientou.

A Reuters informou que os materiais do projeto ARTEX limitavam seu uso pretendido ao aprendizado, à pesquisa de código e à verificação técnica local. Seus desenvolvedores teriam alertado contra testes não autorizados em sistemas on-line reais.

Esses alertas estabelecem o uso pretendido, mas não conseguem impor esse limite depois que o software se torna publicamente disponível. A distribuição de código aberto oferece transparência e personalização aos defensores. Ela também permite que invasores obtenham o mesmo código de orquestração sem aprovação do fornecedor.

O verdadeiro ponto fraco estava fora do núcleo bancário

A campanha pressionou sistemas de suporte negligenciados, mostrando por que o perímetro de segurança de uma organização se estende além de sua principal aplicação voltada ao cliente.

Os serviços violados descritos publicamente não foram identificados como mecanismos centrais de transações. Um dava suporte a consultas de empréstimos para corretores financeiros. Outro ajudava funcionários a concluir trabalhos por dispositivos móveis.

Esses sistemas podem receber menos escrutínio do que plataformas de internet banking porque atendem a públicos menores ou mais especializados. Ainda assim, podem expor registros sensíveis e se conectar a fontes internas de dados.

A Comissão de Serviços Financeiros da Coreia do Sul respondeu ordenando que instituições financeiras inspecionassem todos os serviços de TI acessíveis externamente. Sua diretriz de emergência, de 2 de outubro, incluiu explicitamente sistemas que não eram voltados ao cliente.

O regulador também orientou as instituições a examinar controles de autenticação e acesso, reduzir a exposição desnecessária de informações e compartilhar rapidamente dados sobre ameaças. Essas instruções apontam para fragilidades na gestão de ativos e no desenho de acesso, e não apenas para uma nova capacidade de IA.

Uma organização não pode defender um serviço que esqueceu, classificou incorretamente ou excluiu de revisões rotineiras de segurança. A automação de ataques torna esses pontos cegos mais caros porque o software pode varrer repetidamente muitos sistemas públicos.

Por isso, os bancos enfrentam pressão em dois prazos. A tarefa imediata é investigar os sistemas afetados, notificar clientes e bloquear a infraestrutura relacionada. A tarefa de longo prazo é garantir que cada serviço exposto receba controles de segurança adequados aos seus dados.

A segunda tarefa é mais difícil. Grandes organizações financeiras operam portais de funcionários, ferramentas para corretores, conexões com fornecedores, sistemas de suporte móvel, ambientes de desenvolvimento e aplicações web mais antigas. A responsabilidade pode estar distribuída entre unidades de negócio e provedores externos.

Um programa de segurança centrado apenas no aplicativo bancário principal pode deixar de fora esses pontos de entrada menores. Os atacantes não precisam começar pelo sistema mais protegido. Podem iniciar por um serviço periférico que contenha informações valiosas ou ofereça um caminho para dentro.

O resumo do incidente sul-coreano informou que o Woori Bank e o NH NongHyup Bank detectaram tentativas de ataque sem confirmar vazamentos de dados. Essa diferença mostra por que a detecção e a contenção continuam importantes, mesmo quando os atacantes usam ferramentas assistidas por IA.

A automação não elimina as vantagens defensivas. Autenticação forte, exposição pública mínima, serviços corrigidos, redes segmentadas e monitoramento útil podem interromper um ataque independentemente de quem gerou as solicitações.

No entanto, os defensores agora precisam assumir que o reconhecimento repetitivo pode ocorrer mais rapidamente e em mais ativos. Um acúmulo de serviços expostos que seria administrável manualmente se torna perigoso quando um sistema automatizado pode revisitar cada alvo.

Os ataques ARTEX contra bancos sul-coreanos também desafiam a classificação convencional de incidentes. Um vazamento restrito de dados de um portal de suporte pode parecer menos grave do que uma interrupção do sistema bancário central. Ainda assim, informações expostas sobre renda, empréstimos e contatos podem viabilizar fraudes subsequentes.

Criminosos podem usar um contexto financeiro preciso para tornar mensagens de phishing mais críveis. Podem se passar por credores, mencionar detalhes plausíveis de empréstimos ou abordar vítimas quando elas esperam comunicação de um corretor.

Não há evidência pública de que esse tipo de fraude secundária tenha resultado diretamente desta campanha. Continua sendo um risco previsível que bancos e clientes devem monitorar.

A lição defensiva não é simplesmente que os bancos precisam de seus próprios agentes de IA. A detecção automatizada pode ajudar a analisar eventos, priorizar anomalias e acelerar a resposta. Ela não pode compensar autenticação ausente ou acesso descontrolado a registros sensíveis.

Adicionar automação defensiva sem corrigir sistemas expostos cria outra camada de alertas. Os bancos primeiro precisam de um inventário confiável, uma definição clara de responsáveis pelos serviços e controles que se apliquem aos ambientes centrais e de suporte.

Isso transforma o risco de agentes de pentest com IA em um problema de governança. As equipes de segurança precisam saber quais ferramentas são permitidas, onde a atividade de agentes pode ocorrer, quais logs são retidos e quais sistemas estão aprovados para testes.

As mesmas políticas devem abranger equipes internas de red team e fornecedores externos. Caso contrário, os defensores podem ter dificuldade para distinguir uma avaliação automatizada autorizada de um reconhecimento hostil até que os dados já tenham deixado o sistema.

As Evidências Sustentam Assistência de IA, Não um Hacker Totalmente Autônomo

O registro público sustenta uma campanha assistida por IA, mas não respalda todas as alegações sobre invasão autônoma ou atribuição nacional.

A CrowdStrike avaliou, com confiança moderada, que o agente era falante de chinês e motivado financeiramente. Baseou essa avaliação em prompts em língua chinesa, no framework ARTEX desenvolvido na China e em registros operacionais encontrados em infraestrutura vinculada.

Confiança moderada não é atribuição definitiva. Ferramentas em língua chinesa podem ser baixadas e operadas em qualquer lugar. Atacantes também usam servidores proxy, identidades roubadas, detalhes biográficos falsos e configurações de idioma enganosas.

Um relatório sobre a violação bancária citou a CrowdStrike dizendo que a atividade não havia sido atribuída a um adversário identificado. A extensão total das violações e o volume de dados roubados também permaneceram sem confirmação.

A possível evidência de identidade da CrowdStrike veio de um prompt para redigir currículo. Esse prompt incluía uma localização em Guangdong e um histórico educacional na South China University of Technology. Pesquisadores também vincularam seu identificador no Telegram a outras atividades relacionadas à segurança.

Um interlocutor por telefone contatado pela Reuters negou conhecimento sobre o assunto. Autoridades chinesas disseram não estar familiarizadas com o caso e reiteraram sua oposição geral à invasão de sistemas. A polícia sul-coreana e a Anthropic não haviam comentado à Reuters até o momento da publicação.

Essas lacunas não são meras ressalvas editoriais. Elas definem a diferença entre evidências sobre infraestrutura e provas sobre uma pessoa.

A infraestrutura pode mostrar que determinadas ferramentas foram executadas em um servidor. Históricos de sessões podem revelar prompts e tarefas pretendidas. A sobreposição de alvos pode conectar a atividade às vítimas relatadas. Nenhum desses elementos identifica automaticamente a pessoa que operava o teclado.

A mesma cautela se aplica à autonomia. A CrowdStrike descreveu ferramentas agênticas trabalhando ao lado de capacidades ofensivas tradicionais. Sua avaliação enfatizou como a IA pode aumentar o ritmo operacional de um atacante e a capacidade de conduzir várias invasões rapidamente.

Adam Meyers, vice-presidente sênior de operações contra adversários da CrowdStrike, caracterizou o caso como um adversário humano usando agentes de IA. Seu relato sobre agentes de IA enfatizou que uma pessoa poderia atingir muitas organizações em pouco tempo.

Essa descrição é mais precisa do que afirmar que um sistema de IA invadiu os bancos de forma independente. Ela preserva a responsabilidade humana e corresponde às evidências de ferramentas configuradas, alvos escolhidos e consultas sobre a venda de dados roubados.

Ela também impede que a conversa defensiva se desvie para cenários de ficção científica. As organizações já enfrentam um problema concreto: atacantes podem usar IA para automatizar fluxos de trabalho ofensivos conhecidos contra fraquezas de segurança comuns.

A incógnita mais importante é quais etapas o ARTEX executou com sucesso. As reportagens públicas não fornecem uma cadeia completa, comando a comando, para cada vítima. Elas não mostram que o framework descobriu, explorou e exfiltrou dados sem intervenção.

Os registros expostos oferecem visibilidade direta sobre os métodos do operador, mas não são idênticos aos dados forenses privados dos bancos. Uma reconstrução confiável deve comparar os dois lados.

Os investigadores precisam determinar quais solicitações chegaram a cada serviço, quais controles falharam, quais credenciais ou vulnerabilidades estavam envolvidos e quais informações deixaram o ambiente. Essas conclusões estabelecerão o papel real da automação.

Essa distinção afeta a regulamentação e a responsabilidade legal. Se um agente executou ações selecionadas e supervisionadas por uma pessoa, os princípios existentes de crimes cibernéticos ainda fornecem um agente humano claramente identificável. Uma execução mais autônoma pode complicar questões sobre supervisão, salvaguardas e distribuição de software.

Ainda assim, a autonomia não remove a responsabilidade dos operadores. Uma pessoa que emprega um sistema de testes de penetração contra um alvo não autorizado não pode tratar de forma plausível a invasão resultante como um acidente imprevisível.

Desenvolvedores de ferramentas e provedores de modelos enfrentam uma questão diferente. Eles precisam decidir quanta prevenção contra uso indevido é tecnicamente viável sem bloquear pesquisas legítimas em segurança.

Frameworks de código aberto não podem depender da aplicação centralizada por contas. APIs de modelos podem aplicar monitoramento e restrições, mas os atacantes podem trocar de provedor, usar revendedores ou executar modelos de pesos abertos localmente.

Essa realidade limita soluções baseadas nos controles de segurança de uma única empresa. A resposta também precisa se concentrar em defesas do lado do alvo, monitoramento de infraestrutura, investigações coordenadas e na economia das informações roubadas.

Três Sinais Mostrarão se o ARTEX Muda os Ciberataques

As próximas evidências devem mostrar se este foi um experimento isolado de um operador ou um modelo de ataque repetível que se espalha pelo setor financeiro.

O primeiro sinal é um relato forense detalhado das autoridades sul-coreanas ou das instituições afetadas. Os investigadores precisam conectar solicitações específicas, vulnerabilidades, caminhos de acesso e transferências de dados à infraestrutura identificada pela CrowdStrike.

Essa evidência reforçaria a avaliação atual se mostrasse o ARTEX coordenando ações bem-sucedidas contra várias vítimas. Enfraqueceria as alegações de invasão conduzida por agentes se a ferramenta aparecesse apenas durante o reconhecimento ou em infraestrutura não relacionada.

O National Office of Investigation da Coreia do Sul formou uma equipe dedicada depois que as violações chamaram a atenção presidencial. Os reguladores também iniciaram revisões presenciais e pediram às empresas financeiras que relatassem os resultados das inspeções internas.

A divulgação pública pode permanecer limitada porque a investigação envolve dados de clientes e fraquezas de segurança ativas. Até mesmo uma linha do tempo cuidadosamente censurada ajudaria a distinguir etapas de ataque confirmadas de inferências.

O segundo sinal é a reutilização de configurações do ARTEX, prompts, padrões de infraestrutura ou táticas em outras campanhas. Um caso demonstra viabilidade. Casos repetidos demonstrariam adoção.

As equipes de segurança devem observar serviços ARTEX expostos, arquivos de instrução reconhecíveis, sondagens automatizadas incomuns e padrões de comandos assistidos por modelos. Não devem tratar o nome de um produto, por si só, como prova de atividade maliciosa.

Equipes de segurança autorizadas podem implantar o mesmo software de código aberto. A detecção deve combinar indicadores da ferramenta com escopo do alvo, momento, credenciais, comportamento e contexto de rede.

O uso por imitadores reforçaria o argumento de que frameworks agênticos de testes de penetração reduziram o custo de atividades ofensivas amplas. A ausência de reutilização sugeriria que esta campanha dependeu fortemente da configuração e dos erros de um único operador.

O terceiro sinal é se reguladores e instituições financeiras fecham as lacunas nos sistemas de suporte destacadas pelas violações. O resultado relevante não é quantos bancos anunciam projetos de defesa com IA.

Uma medida melhor é verificar se as instituições identificam todos os serviços acessíveis externamente, aplicam autenticação de forma consistente, reduzem a exposição desnecessária de dados e encurtam os tempos de correção. Indicadores compartilhados também precisam chegar às instituições antes que a mesma infraestrutura tenha sucesso novamente.

Os ataques ARTEX contra bancos sul-coreanos expuseram uma incompatibilidade entre plataformas bancárias altamente protegidas e serviços operacionais menos visíveis. Fechar essa lacuna reduziria o valor da descoberta automatizada de alvos.

Os bancos também devem preservar evidências forenses relacionadas a agentes. Históricos de prompts, logs de orquestração, registros de API e arquivos de memória podem revelar intenção e progressão de tarefas. A telemetria tradicional de endpoints e redes continua essencial.

O caso dá a desenvolvedores e compradores empresariais um motivo para examinar como a atividade de agentes é registrada. Sistemas que executam ferramentas precisam de limites claros de autorização, registros duráveis de auditoria e históricos de tarefas compreensíveis para humanos.

Líderes de segurança devem perguntar se um agente pode acessar credenciais de produção, se seu escopo é imposto tecnicamente e quem revisa as ações antes da execução. Também devem testar se os registros sobrevivem após o encerramento de uma sessão.

Uma explicação precisa sobre invasões bancárias com IA é menos dramática do que a imagem de uma máquina rebelde atacando as finanças por conta própria. Também é mais urgente. Um ser humano teria reunido software acessível e vários modelos em um fluxo de trabalho que alcançou várias organizações rapidamente.

A questão decisiva agora é se os defensores conseguem eliminar caminhos expostos mais rápido do que os invasores conseguem automatizar sua descoberta. Revise todos os serviços de suporte voltados para a internet, compare seu acesso a dados com sua autenticação e preserve evidências de sessões automatizadas incomuns.

Se os reguladores publicarem uma cadeia de ataque verificada, os defensores identificarem padrões ARTEX em outros lugares e os bancos documentarem uma remediação mais rápida, esta campanha marcará uma mudança mensurável. Até lá, trate-a como um alerta bem fundamentado, com alegações não resolvidas sobre atribuição, escopo e autonomia.