Como o Amazon Bedrock detecta phishing gerado por IA

O phishing mudou — e os filtros antigos não acompanharam

Engenharia social por e-mail é uma das táticas mais antigas e persistentes no mundo da segurança cibernética. Mas o que mudou radicalmente nos últimos anos é a qualidade dos ataques. Graças à Inteligência Artificial Generativa (IA Generativa), criminosos conseguem criar milhares de mensagens únicas, com gramática impecável, contexto adequado e detalhes personalizados sobre a vítima — tudo de forma automatizada.

Pense no cenário clássico de detecção de phishing: erros de português, saudações genéricas, logotipos tortos, domínios estranhos. Essas eram as pistas que os filtros tradicionais aprenderam a capturar. O problema é que a IA generativa eliminou exatamente esses erros. Hoje, um e-mail de phishing sofisticado pode ser a mensagem mais bem escrita da sua caixa de entrada.

Além disso, os atacantes modernos usam técnicas de Inteligência de Fontes Abertas (OSINT — Open Source Intelligence) para mapear hierarquias organizacionais, relações entre funcionários e padrões de comunicação a partir de redes profissionais, sites corporativos e rastros digitais públicos. Com esse mapeamento, é possível gerar mensagens que se adaptam em tempo real conforme a vítima responde.

A pergunta que a AWS se propôs a responder é: como usar a mesma tecnologia de IA para detectar esses ataques antes que causem dano?

Amazon Bedrock como camada de defesa comportamental

O Amazon Bedrock é um serviço gerenciado que disponibiliza Modelos de Fundação (FMs — Foundation Models) de diversas empresas de IA por meio de uma API unificada. A proposta da AWS, detalhada em um artigo técnico recente, é usar esses modelos como uma camada adicional de análise sobre a infraestrutura de segurança de e-mail já existente.

O ponto central da abordagem é a mudança de paradigma: em vez de filtrar mensagens pelo que elas parecem (erros gramaticais, formatação suspeita), o Bedrock analisa o que elas sabem e pedem — ou seja, o comportamento implícito na mensagem comparado ao histórico do remetente.

Para isso, a solução é estruturada como um pipeline de análise em múltiplos estágios, onde cada e-mail passa por autenticação, análise comportamental e pontuação de risco antes de chegar à caixa de entrada do usuário.

As duas capacidades centrais do Bedrock nessa solução

A AWS descreve duas capacidades integradas que sustentam a defesa contra phishing com IA:

• Modelos de Fundação pré-treinados: oferecem compreensão sofisticada de linguagem natural, capazes de detectar manipulação sutil, anomalias contextuais e padrões de personificação que sistemas baseados em regras simplesmente não conseguem capturar.
• Amazon Bedrock Guardrails: camada de governança configurável que define os limites de operação dos modelos. Ela filtra tanto os prompts de entrada quanto as saídas geradas, impedindo que informações sensíveis sejam expostas durante a análise e garantindo que o sistema opere dentro das políticas de IA responsável da organização.

Um ponto importante sobre os Guardrails: a configuração exige calibração cuidadosa. Restrições excessivamente rígidas podem impedir que o modelo analise conteúdo suspeito que legitimamente precisa ser avaliado — como um e-mail que contém linguagem ofensiva justamente para tentar burlar filtros.

Como o pipeline funciona na prática

O fluxo de análise é dividido em cinco etapas principais:

Etapa 1 — Guardrails de entrada e pré-processamento

Antes de qualquer análise de IA, o e-mail passa pelos Guardrails do Bedrock, que verificam o conteúdo e sinalizam o que deve ir para revisão manual. Informações de Identificação Pessoal (PII — Personally Identifiable Information) descobertas durante a análise podem ser automaticamente redigidas, evitando que o modelo gere respostas que exponham dados confidenciais.

Etapa 2 — Construção do prompt com contexto

Após passar pela triagem inicial, o sistema constrói um prompt de análise combinando o conteúdo do e-mail com três elementos de contexto: o padrão de comunicação histórico do remetente, o contexto organizacional e exemplos conhecidos de phishing armazenados nas Amazon Bedrock Knowledge Bases. Dessa forma, o modelo não avalia a mensagem de forma isolada — ele compara com um quadro completo de referências.

Etapa 3 — Análise pelo modelo de fundação com Guardrails ativos

O modelo processa o e-mail usando o prompt construído, enquanto os Guardrails mantêm a análise dentro dos limites definidos. O modelo consegue examinar conteúdo suspeito com profundidade sem gerar saídas que exponham informações sensíveis no processo.

Etapa 4 — Pontuação de risco multifatorial

A partir da análise, o pipeline gera três pontuações independentes: anomalias de conteúdo, desvios comportamentais e alinhamento contextual. Essas três pontuações são combinadas em uma média ponderada que resulta em um score único de 0 a 100. Os limiares definidos no artigo são: abaixo de 30 é seguro, entre 30 e 70 é suspeito, e acima de 70 é perigoso.

Etapa 5 — Classificação e roteamento automatizado

Com base no score final, o e-mail é roteado automaticamente: mensagens seguras chegam normalmente à caixa de entrada, mensagens suspeitas vão para quarentena para revisão da equipe de segurança, e mensagens perigosas são bloqueadas com alerta imediato para o time responsável.

O rastreador de comportamento do remetente

Um componente-chave da solução é o que a AWS chama de sender baseline tracker — um perfil dinâmico de cada remetente que registra como aquela pessoa normalmente escreve: vocabulário, formalidade, tipos de solicitação e com quem costuma se comunicar.

Imagine um cenário concreto: um fornecedor que sempre manda e-mails curtos sobre notas fiscais de repente envia uma mensagem formal pedindo urgentemente a alteração de dados bancários. O pipeline detecta esse desvio comportamental e sinaliza para a equipe de segurança revisar — mesmo que a mensagem seja gramaticalmente perfeita e pareça legítima à primeira vista.

Esse é exatamente o tipo de ataque que os filtros tradicionais não conseguem pegar. E é exatamente o que o exemplo técnico do artigo original ilustra:

{
  "risk_score": 78,
  "risk_level": "DANGEROUS",
  "key_findings": [
    "Domain mismatch: 'example-website.com' vs 'example.com'",
    "First-ever payment change request from this sender",
    "Phone number doesn't match vendor records"
  ]
}

No exemplo, o modelo flagrou uma tentativa de personificação de fornecedor com score 78 (perigoso). Os três achados principais foram: incompatibilidade de domínio entre o endereço real e o usado no e-mail, uma solicitação de mudança de dados bancários que nunca havia ocorrido antes com aquele remetente, e um número de telefone que não bate com os registros do fornecedor.

O ciclo contínuo de aprendizado

O que diferencia essa abordagem de sistemas estáticos de detecção é o loop de feedback contínuo. A cada ciclo, o sistema fica mais preciso:

• Analisar (Analyze): o modelo avalia os e-mails recebidos usando prompts dinâmicos construídos com base em inteligência acumulada e no contexto do remetente.
• Pontuar (Score): um score de 0 a 100 é atribuído, e mensagens suspeitas são colocadas em quarentena para revisão.
• Revisar (Review): a equipe de segurança classifica as mensagens sinalizadas como phishing confirmado ou falso positivo.
• Aprender (Learn): essas classificações alimentam o sistema, atualizando a biblioteca de exemplos, os perfis comportamentais dos remetentes e o catálogo de padrões emergentes.
• Aprimorar (Enhance): os novos exemplos e padrões confirmados são incorporados aos prompts de análise, melhorando a precisão nas próximas rodadas.

Nos ciclos iniciais, a equipe de segurança precisará dedicar mais tempo classificando mensagens sinalizadas — é o período em que o sistema está construindo seu entendimento de base. Com o tempo, à medida que a biblioteca de exemplos e os perfis de remetentes crescem, o modelo se torna progressivamente mais preciso, e a atenção da equipe se desloca do ruído para as ameaças genuínas.

Engenharia de prompt dinâmica e few-shot learning

Dois conceitos técnicos importantes sustentam a melhoria contínua do sistema. O primeiro é a engenharia de prompt dinâmica: as instruções enviadas ao modelo são refinadas iterativamente com base nos resultados reais, incorporando o feedback da equipe de segurança diretamente nos prompts de análise.

O segundo é o few-shot learning: exemplos verificados de phishing e mensagens legítimas são catalogados e usados como demonstrações de referência nos prompts futuros. Quando um novo e-mail chega, o modelo não parte do zero — ele consulta exemplos reais e previamente validados que seguem padrões similares para embasar sua avaliação.

O que isso significa para equipes de segurança

A proposta da AWS não é substituir a infraestrutura de segurança existente nem o julgamento humano. Os protocolos de autenticação de e-mail — Estrutura de Política de Remetente (SPF — Sender Policy Framework), Correio Identificado por Chaves de Domínio (DKIM — DomainKeys Identified Mail) e Conformidade, Relatório e Autenticação de Mensagem Baseada em Domínio (DMARC — Domain-based Message Authentication, Reporting and Conformance) — continuam sendo a primeira linha de defesa. O Bedrock atua como uma camada analítica adicional, rodando em paralelo à infraestrutura existente.

A mensagem central do artigo é direta: a IA tornou o phishing mais difícil de detectar. A mesma tecnologia, aplicada defensivamente, pode torná-lo mais difícil de ter sucesso. Para equipes que queiram explorar essa abordagem, a AWS indica o console do Amazon Bedrock como ponto de partida para configurar os Guardrails e construir o pipeline de detecção.

Fonte

How Amazon Bedrock catches AI-generated phishing (https://aws.amazon.com/blogs/machine-learning/how-amazon-bedrock-catches-ai-generated-phishing/)