ARTEX Lidera uma Nova Onda de Frameworks Ofensivos Agentes
Detection stack
- AIDR
- Alert
- ETL
- Query
Resumo
Os atores de ameaças estão cada vez mais armando frameworks impulsionados por LLMs, como ARTEX, PentAGI e CAIRN, para automatizar ciclos de vida de ataques complexos. Esses sistemas multi-agentes habilitam reconhecimento rápido, movimento lateral e escalonamento de privilégios em velocidade de máquina. Esta evolução marca uma transição para intrusões altamente automatizadas e escaláveis que colocam pressão adicional sobre as estratégias de defesa tradicionais.
Investigação
Mandiant e GTIG observaram esses frameworks durante engajamentos reais de resposta a incidentes, incluindo atividades vinculadas a grupos como UNC7228 (STORM-0940). Investigações documentaram explosões de alta velocidade, incluindo 27 eventos em 23 segundos, junto com correção automática de erros usada para implantar webshells. Pesquisadores também destacaram como essas ferramentas abusam de permissões na nuvem e APIs de aplicativos legítimos para alcançar os objetivos dos atacantes.
Mitigação
Os defensores devem adotar uma estratégia de defesa em cinco camadas: proteger planos de controle, restringir identidades e chaves com credenciais de vida curta, endurecer configurações, proteger recursos do aplicativo contra abusos e monitorar anomalias comportamentais e volumétricas. Reduzir a superfície de ataque externa e limitar a exposição administrativa desnecessária continuam sendo medidas defensivas críticas.
Resposta
Quando atividade suspeita é detectada, as organizações devem priorizar a resposta centrada em identidade, pois muitas ações dependem de credenciais válidas. Monitore explosões incomuns de chamadas de API de gerenciamento, origens de autenticação inesperadas e mudanças súbitas em padrões de acesso ao plano de dados. Revogar rapidamente identidades comprometidas e investigar o escopo total do movimento lateral automatizado é essencial.
Fluxo de Ataque
Ainda estamos atualizando esta parte.
Detecções
Possível Ataque DCSync (via auditoria)
Possível Atividade de Kerberoasting [correlacionar/bucket_span_10m/por src_user] (via auditoria)
Possível Atividade de Kerberoasting [correlacionar/bucket_span_10m/por src_ipaddr] (via auditoria)
Filtros de Pesquisa LDAP Comuns Suspeitos (via serviço de diretório)
40* Picos de Resposta de Código de Status HTTP Para Único IP (via servidor web)
Possível Infiltração / Exfiltração de Dados / C2 via Serviços / Ferramentas de Terceiros (via proxy)
Possível Distribuição de Malware via Endpoints WebsiteHook (via proxy)
Possível Distribuição de Malware via Endpoints WebsiteHook (via dns)
Possível Enumeração de Usuário AWS Identificada por Códigos de Erro da API (via cloudtrail)
Detectar Probing de Reconhecimento do Framework ARTEX em Diretórios da Web [Servidor Web]
Detecção de Atividades de Reconhecimento do ARTEX no Azure [Logs de Atividades do Azure]
Detecção de Atividades de Reconhecimento do Framework ARTEX [AWS Cloudtrail]
Execução de Simulação
-
Narrativa & Comandos do Ataque: Um adversário implantando o framework ARTEX busca mapear as permissões do ambiente de nuvem. Para verificar as capacidades de escrita/exclusão no Azure, o framework executa uma sequência rápida de criação de um blob chamado
TinyTestBlobseguido imediatamente por sua exclusão. Simultaneamente, no ambiente AWS, o adversário tenta listar ou modificar instâncias EC2 usando o--dry-runflag. Isso lhes permite confirmar se seu papel IAM atual tem privilégios suficientes sem acionar mudanças de estado reais ou gerar logs de “sucesso”, em vez de se basear no código de erroDryRunOperationpara confirmar o status “negado” ou “permitido”. -
Script de Teste de Regressão:
# Script de Simulação do Framework ARTEX Write-Host "[!] Iniciando Simulação de Reconhecimento do ARTEX..." # --- Parte 1: Reconhecimento de Azure Blob --- Write-Host "[*] Simulando escrita/exclusão de Azure TinyTestBlob..." $azureAccount = "artex_test_account" $container = "recon-container" $blobName = "TinyTestBlob" $testFile = ".temp_recon.txt" "recon_data" | Out-File $testFile # Simular o padrão rápido de escrita/exclusão try { Set-AzStorageBlobContent -File $testFile -Container $container -Blob $blobName -Context $ctx -ErrorAction Stop Write-Host "[+] Escrita no Azure Bem-Sucedida" Remove-AzStorageBlob -Blob $blobName -Container $container -Context $ctx -ErrorAction Stop Write-Host "[+] Exclusão no Azure Bem-Sucedida" } catch { Write-Error "Falha na Simulação do Azure: $_" } # --- Parte 2: Reconhecimento AWS EC2 DryRun --- Write-Host "[*] Simulando verificação de permissões AWS EC2 DryRun..." # Este comando é projetado para falhar com um erro DryRunOperation se as permissões estiverem presentes ou ausentes aws ec2 describe-instances --dry-run --region us-east-1 if ($LASTEXITCODE -ne 0) { Write-Host "[+] Verificação DryRun da AWS Concluída (Erro Esperado)" } Remove-Item $testFile Write-Host "[!] Simulação Completa." -
Comandos de Limpeza:
# Limpeza de artefatos de simulação Remove-Item -Path ".temp_recon.txt" -ErrorAction SilentlyContinue # Nota: O blob do Azure já é excluído pelo script de simulação.