AWS Security Agent: Pentesting Automatizado do AWSGoat (Serverless)

Visão Geral

AWS Security Agent é um “frontier agent” movido por IA que automatiza testes de segurança ao longo de todo o ciclo de vida de desenvolvimento de software. Ele se tornou geralmente disponível para pentest on-demand em 31 de março de 2026, após um public preview lançado no re:Invent 2025 em dezembro. É um serviço standalone, separado do AWS Inspector, GuardDuty ou Security Hub, com seu próprio web app e console.

A ferramenta oferece três capacidades: pentest on-demand ($50/task-hour), revisões de design seguro (gratuito, até 200/mês) e revisões de código seguro (gratuito, até 1.000/mês). A capacidade de pentesting é o recurso principal. Ao invés de contratar uma empresa para um engagement de $15.000 a $50.000 que leva semanas para agendar e concluir, você aponta o Security Agent para a sua aplicação e ele roda um pentest autônomo que normalmente termina em horas. Ele usa uma arquitetura multi-agente com agentes “swarm” especializados cobrindo 13 categorias de risco, incluindo vulnerabilidades do OWASP Top 10 e falhas de lógica de negócio. Ele entrega scores CVSS, caminhos de exploração reproduzíveis e orientações de remediação.

Neste post, eu passo pelo setup e execução de um pentest contra o AWSGoat da INE Labs, fazendo deploy do Module 1 (uma aplicação blog serverless) manualmente via Terraform a partir do meu laptop. O pentest terminou em 5 horas e 20 minutos de wall time (21.82 task-hours, cerca de $1.091 no preço de tabela) e produziu 17 findings: 2 Critical, 6 High, 9 Medium. Eu forkei o AWSGoat upstream no repositório complementar e customizei o Module 1 para fazer deploy atrás de um domínio customizado no API Gateway. O domínio customizado é pré-requisito para o AWS Security Agent, que exige um target HTTPS com domínio verificado. Também apliquei alguns workarounds menores. Por fim, incluo uma comparação de ambientes de referência para pentesting para leitores que queiram testar o Security Agent por conta própria.

Como Funciona o Pentesting On-Demand

O Security Agent usa agentes de IA especializados para descobrir, validar e reportar vulnerabilidades em aplicações em execução. Diferente de scanners DAST tradicionais, que procuram por padrões conhecidos, o Security Agent lê o código-fonte, especificações de API e documentação para construir um plano de ataque customizado. Ele então executa cenários de ataque em múltiplos passos, valida findings através de exploração real e reporta os resultados com scores CVSS, análise de impacto e orientação de remediação.

A arquitetura multi-agente funciona em fases:

1. Autenticação: Um componente inteligente de sign-in localiza as páginas de login, tenta credenciais e mantém sessões autenticadas
2. Baseline scanning: Varreduras estáticas para estabelecer a cobertura inicial
3. Reconhecimento: Mapeia a superfície da aplicação e descobre endpoints
4. Exploração guiada: Um planner baseado em LLM gera um plano de pentesting contextual, identificando recursos inexplorados e cadeias potenciais de vulnerabilidade
5. Swarm de agentes especializados: Despacha o trabalho para agentes configurados para tipos específicos de risco, equipados com code executors, web fuzzers, ferramentas do banco de vulnerabilidades NVD e toolkits específicos por vulnerabilidade
6. Validação: Os findings passam por validação determinística e tentativas de exploração via LLM, com scoring CVSS conduzido por LLM

O principal diferencial em relação a ferramentas DAST tradicionais como Burp Suite ou OWASP ZAP é a consciência de contexto. O Burp Suite sonda uma aplicação em execução em busca de vulnerabilidades. O Security Agent lê o seu código e entende a sua arquitetura, o que permite encontrar falhas de lógica de negócio que scanners baseados em padrão deixam passar.

O principal diferencial em relação ao AWS Inspector é o escopo. O Inspector escaneia por CVEs conhecidos em pacotes de software e exposição de rede. O Security Agent faz pentest ativo em aplicações buscando vulnerabilidades exploráveis, incluindo bypass de autenticação, ataques de injeção e falhas de lógica. Eles são complementares.

Preço: $50/task-hour, medido por segundo. Veja a seção de Preços abaixo para a quebra completa, incluindo o free trial de dois meses.

Suporte multi-cloud: O Security Agent pode testar aplicações em AWS, Azure, GCP, on-premises e ambientes SaaS. A aplicação não precisa estar hospedada na AWS.

Opções de Alvo para Pentesting

Antes de rodar o demo, eu avaliei vários ambientes AWS “vulneráveis por design”. Essas são aplicações e infraestruturas intencionalmente inseguras, desenhadas para testes de segurança e aprendizado. Aqui estão as principais opções:

App	Criador	Arquitetura	Deploy	Stars	Última Atualização	Melhor Para
OWASP DVSA	OWASP	Lambda + API GW + DynamoDB + S3 + Cognito	CloudFormation / Serverless App Repo	544	Set 2023	Vulnerabilidades específicas de serverless (10 lições mapeando para OWASP Serverless Top 10)
CloudGoat	Rhino Security Labs	Multi-cenário (IAM, EC2, Lambda, S3, ECS, Bedrock)	Terraform (CLI customizada)	3.534	Abr 2026	Cenários estilo CTF de IAM e escalada de privilégio (24+ cenários)
AWSGoat	INE Labs	Module 1: Lambda + S3 + API GW + DynamoDB	Terraform + GitHub Actions	1.999	Mai 2025	OWASP Top 10 amplo com cenários de app realistas
CloudFoxable	Bishop Fox	Configurações incorretas modulares de AWS (18 desafios)	Terraform	441	Fev 2026	Enumeração em nuvem e caminhos de pós-exploração
IAM Vulnerable	Bishop Fox	31 caminhos de escalada de privilégio em IAM	Terraform	561	Mar 2026	Testes de escalada de privilégio específicos de IAM
OWASP DVSA (Serverless)	OWASP	Loja de videogames (Lambda)	CloudFormation	544	Set 2023	Event injection, broken auth, funções com privilégio excessivo

Eu escolhi o AWSGoat Module 1, a aplicação blog serverless, como target do pentest para este post:

• Module 1: aplicação blog serverless. Frontend React mais um Lambda Node.js 18.x atrás de API Gateway, com DynamoDB e S3. Ele entrega de forma deliberada problemas do OWASP Top 10 (2021): XSS refletido e persistente, SQL injection, SSRF, IDOR em leituras de perfil de usuário, configuração incorreta de CORS e roles de execução Lambda com permissão excessiva. Esse é o equivalente direto do que o DVSA costumava testar.

O AWSGoat também entrega um segundo módulo (app de folha de pagamento de RH hospedado em ECS com RDS, ALB, credenciais hardcoded e caminhos de escalada de privilégio em IAM) que exercita a superfície de ataque de container. Não cubro ele aqui.

Escolhi AWSGoat ao invés de OWASP DVSA por três razões. Primeiro, manutenção: o último push do AWSGoat é de maio de 2025, enquanto o DVSA não é tocado desde setembro de 2023 e fixa runtimes de Node 8.x e Python 2 que são dolorosos na AWS atual. Segundo, escopo: o Module 1 sozinho cobre a superfície OWASP Top 10 serverless que eu queria colocar na frente do Security Agent, e o Module 2 está disponível como uma execução separada para quando a angulação de container e RDS importar. Terceiro, ergonomia de deploy: o AWSGoat vem como Terraform limpo que eu consigo dar apply a partir do meu laptop. O AWSGoat também foi apresentado na BlackHat USA 2022 e DEF CON 30, então os caminhos de ataque estão bem documentados.

O Demo: Fazendo Pentest no AWSGoat

Pré-requisitos

Para o Security Agent:

• Uma conta AWS em uma região suportada. As seis regiões GA são: US East (N. Virginia), US West (Oregon), Europe (Ireland), Europe (Frankfurt), Asia Pacific (Sydney) e Asia Pacific (Tokyo). Eu usei us-east-1.
• Permissões IAM para criar recursos do Security Agent.
• Um domínio público que você possui, com uma hosted zone pública no Route 53 na mesma conta AWS. O Security Agent verifica a posse do domínio alvo antes que um pentest possa começar, e o hostname bruto *.execute-api.amazonaws.com que o AWSGoat emite por padrão não pode ser verificado.

Para o target AWSGoat:

• Terraform instalado.
• AWS CLI configurado com credenciais de admin (aws configure). O Module 1 espera us-east-1.

Configurando o Security Agent

Configurar o Security Agent é direto. O processo é parecido com o setup do DevOps Agent, mas usa um console diferente.

Passo 1: Criar um Agent Space

Navegue até o console do AWS Security Agent e clique em Set up AWS Security Agent. Um Agent Space é a fronteira organizacional para cada aplicação ou projeto que você quer proteger. Ele isola configurações, escopos, revisões e findings enquanto compartilha requisitos de segurança de toda a organização.

Preencha um nome e uma descrição opcional. Eu usei awsgoat-demo. A AWS recomenda um Agent Space por aplicação ou projeto.

Passo 2: Escolher o Método de Acesso

Você tem duas opções:

• IAM Identity Center (SSO): Gerenciamento centralizado de usuários com acesso direto ao web app. Exige IAM Identity Center na mesma região do seu Agent Space.
• Acesso apenas IAM: Setup mais simples, acesso via link de admin no console.

Escolha com cuidado. A decisão é permanente até você deletar e reiniciar o setup. Eu escolhi acesso apenas IAM para este demo: setup mais simples, e eu não precisava de gerenciamento centralizado de usuários para um walkthrough de operador único.

Passo 3: Configurar Permissões

Opcionalmente, crie uma IAM role default ou use uma role existente. A role criada automaticamente fornece as permissões que o Security Agent precisa para operar.

Passo 4: Acessar o Web App

Após o setup concluir, você pode acessar o web app do Security Agent através do console. O web app é onde você configura pentests e revisa findings.

Fazendo Deploy do AWSGoat Module 1

O repositório do AWSGoat inclui um workflow do GitHub Actions, mas eu queria controle total a partir do meu laptop. O Module 1 vem como um stack Terraform autocontido, então o caminho manual é limpo.

O repositório complementar estende o AWSGoat upstream com uma opção de domínio customizado no Route 53 (para que o target tenha um hostname verificável que o Security Agent aceite) e desliga o router do React de URLs baseadas em hash para que o caminho de login seja um path real que o agente consegue atingir diretamente. Ele também inclui algumas correções menores de build para macOS.

Repositório complementar: o walkthrough abaixo clona o repositório complementar do my2cents.ai, que vendora o AWSGoat com a extensão de domínio customizado descrita acima.

Clone uma vez, depois aplique o Module 1. Os valores route53_zone_name e custom_domain_name abaixo são placeholders. test.thingsnotfound.com é a hosted zone no meu próprio domínio, e m1.test.thingsnotfound.com é o subdomínio que usei. Substitua pela sua hosted zone e pelo subdomínio escolhido:

git clone https://github.com/fabiodouek/my2centsai-blog-samples.git
cd my2centsai-blog-samples/aws-security-agent-demo

# Module 1: serverless blog (Lambda + API Gateway + DynamoDB + S3)
cd modules/module-1
terraform init
terraform plan \
  -var route53_zone_name=test.thingsnotfound.com \
  -var custom_domain_name=m1.test.thingsnotfound.com
terraform apply -auto-approve \
  -var route53_zone_name=test.thingsnotfound.com \
  -var custom_domain_name=m1.test.thingsnotfound.com
# Capture the custom_app_url output (https://m1.test.thingsnotfound.com/react)

Apply complete! Resources: 358 added, 0 changed, 0 destroyed.

Outputs:

app_url = "https://v7usimip14.execute-api.us-east-1.amazonaws.com/prod/react"
custom_api_url = "https://m1-api.test.thingsnotfound.com"
custom_app_url = "https://m1.test.thingsnotfound.com/react"
s3_bucket_dev = "dev-blog-awsgoat-bucket-111111111111"
s3_bucket_production = "production-blog-awsgoat-bucket-111111111111"
s3_bucket_temp = "ec2-temp-bucket-111111111111"
s3_website_url = "https://production-blog-awsgoat-bucket-111111111111.s3.us-east-1.amazonaws.com/build"

O Module 1 termina em 3 a 4 minutos e roda a aproximadamente $0,0125/hr fora do free tier.

Após o apply, abra a URL no navegador e confirme que você vê o blog React. Se a primeira requisição retornar um erro Forbidden / 403, espere alguns minutos e tente de novo. O registro no Route 53 e o domínio customizado do API Gateway apoiado por ACM podem levar um ou dois minutos para propagar antes que o hostname customizado comece a resolver.

Registre um usuário de teste. Você vai precisar dessas credenciais depois, ao configurar a autenticação do Security Agent. A execução do pentest faz login como esse usuário para exercitar a superfície autenticada do app, que é onde vivem a maioria das vulnerabilidades interessantes do AWSGoat.

Faça login com esse usuário e confirme que o dashboard renderiza corretamente. Deve corresponder ao screenshot abaixo. Se o dashboard carregar vazio ou retornar 401, as chamadas XHR autenticadas de /list-posts, /get-dashboard e outras não estão chegando ao backend, e o Security Agent vai recorrer apenas à superfície não autenticada.

Habilitando o Pentest

No Console web do Security Agent, navegue até o seu Agent Space e habilite o penetration test.

A partir do Agent Space, clique em Set up penetration testing para abrir o formulário de configuração. Essa é a tela única onde você declara tudo que o Security Agent precisa para atacar um alvo: o domínio verificado, Secrets, CloudWatch Logs, S3 Buckets, VPCs.

1. Verificação de domínio: Verifique a posse do target AWSGoat via DNS ou verificação HTTP. Vamos fazer a validação via DNS. Esse é um mecanismo de segurança para garantir que você só faz pentest em aplicações que possui.
2. Contexto da aplicação: Opcionalmente, conecte-se ao seu repositório no GitHub onde está o código-fonte da sua aplicação.
3. Logging no CloudWatch: Habilite o logging no CloudWatch para capturar a atividade de teste na sua conta.

O Passo 1 é a razão pela qual estendi o Terraform para colocar um domínio customizado na frente de cada módulo em primeiro lugar. Porque a hosted zone do Route 53 (test.thingsnotfound.com) vive na mesma conta AWS que o Agent Space, o Security Agent consegue verificar a posse direto contra o Route 53. Sem registros TXT de DNS para criar, sem arquivo HTTP para subir. Clique em Verify, e ele vira verified em um segundo.

Além do formulário acima, o Security Agent pede para você declarar os recursos AWS em escopo para o teste. É assim que o agente correlaciona findings na aplicação em execução com a infraestrutura subjacente que ele tem permissão para inspecionar. Para o AWSGoat Module 1, selecionei todo grupo de logs do CloudWatch, bucket S3 e função Lambda que o módulo referencia: o raio de alcance completo do Terraform do Module 1, e nada fora dele.

Para o passo 2 (Contexto da aplicação), conecte um repositório no GitHub para que o Security Agent possa ler o código-fonte em paralelo com o app em execução. Isso é o que o eleva acima de um scanner DAST black-box: os agentes com consciência de código conseguem rastrear uma requisição desde a superfície HTTP até o handler Lambda ou o arquivo PHP que a serve. Você autoriza o GitHub App uma vez por Agent Space, depois escolhe o repositório e a branch que correspondem ao target implantado. No meu caso é fabiodouek/my2centsai-blog-samples na main, então o agente vê a mesma árvore do AWSGoat vendorada que o Terraform acabou de implantar.

Configurando o alvo do pentest

Um detalhe no final deste fluxo: autorizar o GitHub App não é o mesmo que anexar um repositório. Depois que a instalação do app te devolve para a view de pentest do Agent Space, você ainda precisa clicar no botão Add no painel de repositórios do GitHub e selecionar o repo e a branch. Se você pular isso, o Security Agent mostra a integração do GitHub como “connected”, mas os agentes com consciência de código não têm nada para ler e silenciosamente caem de volta para modo black-box. Eu deixei isso passar na primeira vez.

Clicar em Add abre o wizard Connect GitHub em dois passos. O Passo 1 lista todo repositório ao qual o GitHub App tem acesso. Marque aquele que corresponde ao target implantado (my2centsai-blog-samples no meu caso) e clique em Next.

O Passo 2 é Manage capabilities. Para cada repo selecionado, você escolhe o que o Security Agent tem permissão para fazer com o código: Code review em pull requests (não suportado neste repo público nesta conta, então o toggle fica greyed out) e Pentest remediation, que deixa o agente abrir PRs de remediação contra o repo depois que um pentest termina. Deixei Pentest remediation desabilitado (não quero que o agente abra PRs de remediação contra este repo automaticamente) e mantive as configurações de Code review em Security vulnerability findings (o default, que limita a análise de PR a padrões comuns de vulnerabilidade em vez de regras customizadas da organização). Clique em Connect para finalizar o wiring do repo no Agent Space.

Iniciando o pentest a partir do web app

Com o Agent Space configurado, volte para a visão geral do Agent Space no console do Security Agent. O tile Penetration testing agora mostra o status Ready. Clique em Start in web app para pular para o web app do Security Agent, onde você inicia a execução e acompanha os findings chegando.

Criando um pentest

O web app te leva para a view de Penetration tests do Agent Space. Em um Agent Space novo, a lista está vazia. Clique em Create your first penetration test (ou Create a penetration test abaixo da lista vazia) para começar uma nova execução.

O formulário Create penetration test abre no Passo 1, Penetration test details. Aqui é onde você define o escopo de uma única execução de pentest. Eu estou mirando no Module 1, o blog serverless Lambda/API Gateway/DynamoDB, então nomeei a execução como Serverless-module1 e configurei o escopo assim:

• Testing scope (as URLs que o agente tem permissão para atacar):

  • https://m1.test.thingsnotfound.com/react, o blog React por trás do domínio customizado
  • https://m1-api.test.thingsnotfound.com, o domínio customizado do API Gateway que suporta as chamadas REST do app

  Apenas domínios verificados são aceitos aqui, que é por que o setup do Route 53 mais cedo era pré-requisito. Listar o domínio customizado da API explicitamente dá ao agente um ponto de entrada direto para o backend, ao invés de fazê-lo inferir a superfície da API a partir do bundle React.

• Accessible URLs (endpoints que o agente pode ler, mas não atacar):

  • https://production-blog-awsgoat-bucket-111111111111.s3.us-east-1.amazonaws.com/* e https://production-blog-awsgoat-bucket-111111111111.s3.us-east-1.amazonaws.com, o bucket S3 que serve o build React de produção, tanto na forma wildcard quanto na forma bare-host, para que o agente consiga resolver todo asset estático referenciado pelo app
  • https://s3.us-east-1.amazonaws.com/* para requisições S3 em formato path-style que o bundle React emite para o mesmo bucket
  • https://m1-api.test.thingsnotfound.com, redeclarado como acessível para que o agente possa seguir respostas da API que linkam de volta para o host da API (ele já está no testing scope acima)
  • https://fonts.googleapis.com e https://fonts.gstatic.com para Google Fonts, puxados pelos arquivos de CSS e fontes do app React; autorizá-los evita que o agente sinalize ruído de recurso inalcançável
  • https://github.com/*, para que os agentes com consciência de código possam buscar o repo complementar como contexto adicional

Exclusões de tipo de risco e URLs fora de escopo ficam vazias: eu quero a varredura OWASP completa contra o AWSGoat, sem recortes de URL.

O Passo 2 é VPC Resources (opcional). Escolher uma VPC, subnet e security groups permitiria ao Security Agent executar probes de pentest de dentro da rede do target, o que é útil quando o app tem endpoints privados acessíveis apenas de dentro da VPC. O Module 1 é totalmente serverless (Lambda, API Gateway, DynamoDB, S3), então não há VPC para anexar. Deixei esse passo vazio.

O Passo 3 é Authentication Resources (opcional). Sem credenciais, o agente só vê a superfície não autenticada; adicionar um ator deixa ele fazer sign-in e exercitar os fluxos logados, que é onde vivem a maioria das vulnerabilidades interessantes do AWSGoat. Adicionei um único ator (Credential1) usando Input credentials. Usuário e senha são digitados no formulário e, nos bastidores, o Security Agent os armazena em uma nova entrada no AWS Secrets Manager ao invés de mantê-los no config do pentest. 2FA fica em branco (a auth do AWSGoat é apenas por senha). A Access URL aponta para a raiz do app (https://m1.test.thingsnotfound.com/react), que é a página que o agente navega primeiro. O caminho de login real vive dentro do prompt de login abaixo. Em Agent Space login prompt, dei ao agente uma descrição curta em linguagem natural de como o fluxo de auth do AWSGoat realmente funciona:

This actor should use the following domains for authentication: https://m1.test.thingsnotfound.com/react/login

The React app POSTs credentials to https://m1-api.test.thingsnotfound.com/login and stores the returned JWT in localStorage under token; include Authorization: Bearer <token> on subsequent /* calls.

Sem essa dica, o agente de autenticação teria que inferir o padrão de tratamento de token observando o tráfego de rede do navegador. Explicitar isso antecipadamente economiza as primeiras iterações de tentativa e erro e mantém a credencial com escopo nos hosts certos.

Porque as credenciais agora vivem no Secrets Manager, a IAM role do agente precisa de secretsmanager:GetSecretValue nesse secret. O painel do Passo 3 mostra a declaração de policy inline exata que você precisa anexar. Até que essa permissão seja concedida, o agente de autenticação não consegue recuperar a senha em runtime e a navegação de login falha silenciosamente, o que mata todo caminho de ataque logado no teste.

O Passo 4 é Additional learning resources (opcional). Aqui é onde você entrega ao agente contexto extra (arquivos feitos upload, links S3 ou repositórios GitHub) para melhorar cobertura e precisão. O repositório GitHub que foi ligado ao Agent Space antes aparece aqui como my2centsai-blog-samples com o badge Integrated repository; deixei ele anexado como único learning resource para essa execução, para que os agentes com consciência de código possam correlacionar findings de runtime contra a árvore vendorada do AWSGoat. Daqui, Create pentest salva o config sem iniciar (útil quando você quer revisar ou ajustar antes de gastar task-hours), enquanto Create and execute commita o config e dispara a execução em um clique.

Clicar em Create pentest (salvar sem executar) te leva para a página de detalhes do pentest. A execução Serverless-module1 agora está configurada e ociosa: a aba Penetration test runs está selecionada, Latest run está vazia e All runs reporta (0), sem nenhuma task-hour consumida ainda. Três abas no topo deixam você detalhar em Penetration test runs (histórico e status ao vivo), Penetration test configurations (o formulário que você acabou de preencher, editável) e Penetration test learning resources (o contexto do repo GitHub). O botão verde Start run no canto superior direito (ou o equivalente abaixo da tabela All runs vazia) é o que efetivamente gasta dinheiro. Clique nele quando estiver pronto para disparar o swarm de agentes.

Rodando o Pentest

Clique em Start penetration test. O agente começa a trabalhar através do seu pipeline multi-fase: autenticando, escaneando, reconhecendo, planejando e despachando agentes especializados.

O timeline de investigação atualiza conforme o agente progride. Você consegue ver quais endpoints ele descobriu, que vetores de ataque está testando e findings preliminares conforme são validados.

A página de preço da AWS mostra um pequeno teste de API em cerca de 3.5 task-hours ($173) e uma aplicação padrão em cerca de 24 task-hours ($1.200). Minha execução do Module 1 ficou em 21,82 task-hours ao longo de 5 horas e 20 minutos de wall time, muito mais próximo do perfil “aplicação padrão” do que do “pequena API”, apesar do Module 1 ser um único Lambda com poucos endpoints.

O que o Security Agent Encontrou

O Security Agent completou as quatro fases (Preflight, Static Analysis, Penetration Testing, Finalizing) sem intervenção manual e produziu um relatório com 17 findings ao longo da superfície do Module 1: 2 Critical, 6 High, 9 Medium.

Todo finding no relatório inclui severidade, categoria OWASP, um vetor CVSS v3.1, rating de confiança, reprodução passo a passo, análise de impacto e orientação de remediação. O agente também pode gerar PRs de remediação automatizados contra o repositório GitHub conectado.

Os dois criticals

Local File Inclusion via file:// em /save-content (CVSS 9.9). O endpoint busca uma URL fornecida pelo usuário com o urllib.request.urlopen() do Python e não faz nenhuma validação de schema, então file:///proc/self/environ vaza as credenciais IAM temporárias do Lambda e o JWT_SECRET. A role de execução do Lambda carrega wildcards s3:*, dynamodb:* e lambda:*, o que transforma um único GET autenticado em comprometimento total da conta AWS. A exploração não precisa nada além de um JWT de baixo privilégio (authLevel=200).

Dump de banco de dados não autenticado em /dump (CVSS 9.1). Um único GET anônimo retorna ambas as tabelas do DynamoDB (47 KB de JSON), incluindo hashes bcrypt de senhas, respostas em texto plano de perguntas de segurança e PII. As respostas secretas alimentam direto o /reset-password para tomar conta de qualquer conta, incluindo os admins authLevel=0.

Highs e mediums em um relance

Severidade	Endpoint / Vetor	Finding	Impacto
High	POST /change-profile	IDOR via email no body, sem checagem de posse	Qualquer usuário autenticado reescreve o perfil de qualquer outro usuário
High	POST /change-password	IDOR via email no body, sem checagem de posse	Qualquer usuário autenticado reseta a senha de qualquer outra conta
High	POST /change-auth	Bypass de authLevel via body	Escalada vertical de privilégio para admin
High	Múltiplos endpoints	authLevel fornecido pelo cliente é confiado por cima do JWT	Bypass de autorização ao longo da API
High	JWT	Segredo HMAC fraco e hardcoded, quebrado em runtime	Forjar tokens para qualquer usuário e qualquer authLevel
High	GET /save-content	SSRF (a mesma validação de schema ausente do LFI)	HTTP(S) de saída arbitrário a partir do Lambda
Medium	/user-details-modal	IDOR	Vaza posts cross-user, incluindo conteúdo pendente e rejeitado
Medium	/save-post	IDOR via campo email	Atribui posts a outros usuários
Medium	POST /search-author	Injection de PartiQL	Extração completa do DB
Medium	JWT	Revogação ausente	Usuários banidos e deletados retêm acesso
Medium	/search-author	Vazamento de informação via stack trace	Vazamento de detalhe server-side
Medium	/save-post	Crash de serialização com surrogates Unicode	Caminho de crash do servidor
Medium	/get-dashboard	502 em todos os formatos de requisição	Caminho de crash do servidor

Cobertura versus a superfície intencional do Module 1

O AWSGoat Module 1 entrega XSS, SQLi (PartiQL), SSRF, IDOR, CORS e roles de Lambda com permissão excessiva de propósito. O Security Agent pegou todos eles, exceto os casos de XSS. Ele exercitou a categoria de task XSS exaustivamente (múltiplos probes stored, reflected e DOM-based ao longo de postTitle, postContent, getRequestImageData e campos de perfil), mas não promoveu nenhum finding de XSS para o conjunto Active de alta confiança que entra no relatório final. A role IAM com permissão excessiva apareceu como amplificador do CVSS do finding de LFI, em vez de finding standalone, o que é razoável. O raio de alcance do IAM é exatamente onde o impacto vive.

Mapeamento para os manuais de ataque do Module 1 do AWSGoat

O AWSGoat entrega seus próprios manuais de ataque para o Module 1 enumerando sete ataques canônicos. O relatório cobre 5 de 7 diretamente, 1 parcialmente, deixa 1 como gap real (Reflected XSS) e 1 como fora de escopo (escalada de privilégio IAM via pivot EC2). Em cima da baseline, ele produz 10 findings adicionais, a maioria de falhas de JWT e autorização mais variantes de IDOR que o manual não documenta. Dois ataques no manual (SQLi e Sensitive Data Exposure) são correspondidos por equivalentes mais fortes no relatório.

#	Ataque do manual	Cobertura	Finding(s) do relatório	Notas
1	Reflected XSS (campo de search, <img src=x onerror=...>)	❌ Gap	(nenhum)	O XSS refletido do manual no input de search não é reproduzido no relatório. O auto-escape do React é a razão provável, e vale a pena rodar de novo com o payload exato do manual. Separadamente, a tabela de metodologia do relatório (PDF p.8, linha de Cross-Site Scripting) declara textualmente “While postContent uses dangerouslySetInnerHTML (confirmed XSS)…” e descreve uma cadeia de exfiltração de session theft por aquele sink, mas nenhum finding correspondente foi registrado. Isso é um finding faltando no relatório em si, ortogonal ao manual #1.
2	SQL Injection (search com ' or '1'='1)	✅ Coberto (mais forte)	F12: Injection de PartiQL em POST /search-author via value	Equivalente DynamoDB/PartiQL do cenário RDBMS do manual. Extração completa de DB confirmada.
3	IDOR em change-password via id controlado pelo usuário	✅ Coberto (mais forte)	F4: IDOR em /change-password	Correspondência exata. O relatório também mostra que currentPassword não é validado. Mais 3 findings adicionais de IDOR (F3, F9, F10).
4	Sensitive Data Exposure (fuzz list-posts)	✅ Coberto (mais forte)	F2: Dump de DB não autenticado via /dump	O manual fala de dados de usuário vazados via um endpoint específico. O relatório encontra um endpoint /dump não autenticado que retorna o scan inteiro do DynamoDB blog-users e blog-posts (47 KB, hashes bcrypt, secretQ/A em texto plano, PII).
5	SSRF Parte 1 (file:// via upload de imagem)	✅ Coberto	F1: LFI via file:// em GET /save-content	Mesma causa raiz (urllib.request.urlopen sem validação de schema). O relatório adiciona /etc/passwd, código-fonte completo do Lambda e confirma que /proc/self/environ é alcançável (credenciais IAM AWS mais JWT_SECRET).
6	SSRF Parte 2 (IMDS → credenciais IAM → insert admin no DynamoDB)	⚠️ Parcial	F6: SSRF via /save-content para URLs arbitrárias	O corpo da F6 só demonstra SSRF para URLs externas arbitrárias. No entanto, a PDF p.13 lista duas tasks de SSRF como Completed cujos resultados não estão na F6. A primeira é “Test SSRF via GET /save-content targeting AWS instance metadata service to extract IAM role credentials” atingindo 169.254.169.254/latest/meta-data/iam/security-credentials/<role>. A segunda é “targeting the Lambda Runtime API at the internal IP discovered through LFI (169.254.100.1:9001)”, o mesmo caminho localhost:9001 que o AWSGoat Manual #6 usa canonicamente (/2018-06-01/runtime/invocation/next). Tasks concluídas, resultados não reportados. Isso não é simplesmente “apenas capability”.
7	Escalada de Privilégio IAM (EC2 → anexar policy *:* → admin hacker)	🚫 Fora de escopo	(nenhum)	Esse ataque exige um pivot via EC2 através de uma chave .pem vazada em um bucket S3 de dev. Os ativos em escopo no relatório são apenas o web app e a API, sem host EC2 listado. Não tentado.

Preço

Fonte: página de preço do AWS Security Agent e FAQs de preço.

Capacidade	Custo	Free Tier
Pentesting on-demand	$50/task-hour (medido por segundo)	Free trial de 2 meses: 200 task-hours/mês
Revisões de design seguro	Grátis	Até 200/mês por conta
Revisões de código seguro	Grátis	Até 1.000/mês por conta

Custo do Pentest

Minha execução do Module 1 consumiu 21,82 task-hours ao longo de 5 horas e 20 minutos de wall time. As task-hours são medidas por segundo ao longo do swarm multi-agente, então o total de task-hours roda mais alto que o wall time quando vários agentes especializados trabalham em paralelo.

Custo no preço de tabela: 21,82 task-hours × $50/task-hour ≈ $1.091

A execução ficou abaixo do cap de 200 horas/mês do free trial, então o custo de bolso foi $0. No preço de tabela, a execução fica próxima do exemplo “aplicação padrão” da AWS ($1.200), ao invés de “pequena API” ($173), apesar da pequena área de superfície do Module 1. O planejamento de custo real deve assumir economia de aplicação padrão mesmo para targets modestos.

Você também paga a infraestrutura do próprio AWSGoat enquanto o target está rodando (cerca de $0,0125/hr para o Module 1), o que é desprezível ao lado do gasto do pentest.

Para comparação:

• Um pentest manual de uma aplicação similar custaria $5.000 a $15.000 e levaria 1 a 2 semanas
• Rodar Burp Suite DAST exige uma assinatura mínima de $6.995/ano
• OWASP ZAP é grátis, mas exige configuração manual significativa e não tem análise com consciência de contexto

Se você está testando durante o free trial de 2 meses (200 task-hours/mês, começando a partir do seu primeiro pentest), o custo é $0.

Veredito

O que Funciona

O preço é genuinamente disruptivo. Um pentest padrão a $1.200 contra $15.000 a $50.000 de um engagement manual é uma redução de custo de 10x a 40x. Isso torna o teste contínuo viável para organizações de qualquer tamanho.

A arquitetura multi-agente é sofisticada. O pipeline de autenticação até exploração guiada até swarm de agentes especializados é bem desenhado. Teste com consciência de contexto que lê código-fonte e documentação, ao invés de apenas sondar endpoints, é um diferencial real em relação às ferramentas DAST tradicionais.

O setup é mínimo. Dez minutos do zero até rodar pentests. Sem agentes para instalar, sem infraestrutura para gerenciar. Se você já está na AWS, pode começar a testar imediatamente.

O suporte multi-cloud é uma surpresa. O agente pode testar aplicações em AWS, Azure, GCP, on-premises e SaaS. Não é apenas uma ferramenta só de AWS.

O Que Pode Ser Melhorado

Processo de troubleshooting lento. O Security Agent lança sua própria infraestrutura em um sandbox antes de cada execução, o que pode levar um tempo. Durante minhas execuções iniciais, deixei de colocar em allow-list algumas URLs das quais a aplicação realmente depende, e em outros casos a IAM role estava sem as permissões que o agente de autenticação precisava (notavelmente secretsmanager:GetSecretValue no secret de credenciais criado automaticamente). Corrigir o problema e começar de novo foi, em alguns casos, um ciclo de 40 minutos. Seria uma vitória real de quality-of-life se um release futuro deixasse você corrigir a má configuração e retomar do último ponto de falha, ao invés de reiniciar o sandbox inteiro, e alguma validação inicial fail-fast (checagens de alcançabilidade nas URLs em escopo, dry-runs de permissão IAM nos secrets configurados, etc.) pegaria a maioria disso antes mesmo do pentest começar.

Quem Deve Usar

Sim: Times rodando aplicações web que podem pagar $1.200 por teste. Se você hoje faz zero pentesting porque avaliações manuais são caras demais, isso muda a equação inteira.

Talvez: Times pequenos com aplicações simples. O free trial vale a pena testar, mas se você tem uma aplicação e testa uma vez por ano, a economia em relação a um pentest manual pode não justificar aprender uma nova ferramenta.

Ainda não: Times com requisitos rigorosos de compliance (PCI DSS, CBEST) que precisam de relatórios de pentest assinados por humano. Times em regiões não suportadas.

O Panorama Maior

A AWS está posicionando o Security Agent como parte de uma mudança de pentesting periódico e caro para testes de segurança contínuos e acessíveis. A economia suporta isso: se um pentest custa $1.200 ao invés de $15.000, você pode testar toda aplicação após todo release, ao invés de testar suas 5 aplicações principais uma vez por ano.

A pergunta mais difícil é quanto confiar em pentesting conduzido por IA. A taxa de sucesso de 80% sem assistência (não os 92,5% assistidos que são marketing) significa que aproximadamente 1 em 5 vulnerabilidades pode ser perdida. Para falhas novas de lógica de negócio específicas da sua aplicação, a taxa de erro provavelmente é maior. A natureza não determinística dos findings adiciona outra camada de incerteza.

Minha opinião: use como baseline. Rode o Security Agent continuamente para pegar os 80% de vulnerabilidades que o teste automatizado consegue encontrar. Coloque em camadas com Prowler ou Inspector para scanning de infraestrutura. E mantenha pentesting manual na rotação para aplicações críticas e requisitos de compliance. A $1.200 por teste, o custo de rodar isso ao lado de pentesters humanos ainda é dramaticamente menor do que depender apenas de teste manual.

Limpando

Quando terminar o demo, derrube o Module 1 com Terraform:

cd my2centsai-blog-samples/aws-security-agent-demo/modules/module-1
terraform destroy --auto-approve

Você também pode deletar o Agent Space do console do Security Agent se não precisar mais dele. O relógio do free trial começa a partir do seu primeiro pentest, não da criação do Agent Space.