PhishER

Triagem dos e-mails reais que seus colaboradores reportam como suspeitos, com auto-detecção das próprias simulações.

• De ferramenta de teste a plataforma de defesa
• Status de um report
• O diferencial: auto-detecção de simulação
• Como o colaborador reporta
  • 1. Ingestão por token (API)
  • 2. Encaminhamento por e-mail (forward)
• O que o SOC vê
• Ativar a entrada por e-mail (operacional)
• Roadmap
• Relacionado

De ferramenta de teste a plataforma de defesa

Simular phishing mede risco. O PhishER fecha o ciclo: quando um colaborador recebe um e-mail de verdade suspeito e o reporta, ele cai numa fila de triagem para o time de segurança classificar e agir. É o que transforma a qlture de “ferramenta de simulação” em plataforma de defesa.

Você encontra tudo na aba Triagem (Phishing reportado), dentro do módulo de Phishing (acesso TENANT_ADMIN / TENANT_MANAGER).

Phishing reportado: fila de triagem com contadores por status e o botão Configurar entrada.

Status de um report

Cada e-mail reportado passa por uma esteira:

Status	Significado
new	Recém-chegado, aguardando triagem
triaging	Em análise
malicious	Confirmado como malicioso
spam	Spam/lixo, sem malícia
safe	Falso alarme — e-mail legítimo
simulation	É uma simulação da própria qlture (auto-detectado)

O diferencial: auto-detecção de simulação

Quando um report chega, a qlture extrai os IOCs (URLs e domínios) e procura pelos tokens de rastreio das suas próprias campanhas (as rotas /c, /r, /o e /p). Se algum token casa com um alvo/campanha do seu tenant, o report é marcado como simulation automaticamente.

Resultado: o seu time não perde tempo triando os e-mails de treinamento que você mesmo enviou. Isso usa dados que já são seus, sem configuração extra.

flowchart TD
  E[Colaborador encaminha<br/>e-mail suspeito] --> IN[Ingestão qlture]
  IN --> X[Extrai IOCs + tokens de rastreio]
  X --> M{Casa com uma<br/>campanha sua?}
  M -->|Sim| SIM[Marca como simulação]
  M -->|Não| T[Fila de triagem do SOC]
  classDef hl fill:#c6ff00,stroke:#c6ff00,color:#070a0e;
  class T hl

Como o colaborador reporta

Há duas entradas, e ambas alimentam a mesma fila de triagem.

1. Ingestão por token (API)

Um endpoint recebe o e-mail reportado, autenticado por um bearer token por tenant. Guardamos apenas o hash do token (mesmo padrão do SCIM). Gere e rotacione o token na aba Triagem → Configurar entrada.

2. Encaminhamento por e-mail (forward)

O colaborador encaminha o e-mail suspeito para um endereço dedicado do seu tenant:

report-<código>@<seu-domínio-de-reports>

O roteador de e-mail do cliente (AWS SES inbound, Mailgun ou Cloudflare Email Routing) posta a mensagem para a qlture, que a desembrulha.

Peça para o colaborador encaminhar o suspeito COMO ANEXO (.eml). No encaminhamento inline o remetente original da isca se perde; como anexo, a qlture recupera o e-mail original e marca corretamente quem reportou.

O que o SOC vê

Na aba Triagem:

• Estatísticas por status, clicáveis para filtrar a lista.
• Lista dos reports.
• Detalhe em modal: os IOCs extraídos (URLs/domínios), o corpo do e-mail e os botões de classificação (malicious, spam, safe…).

Toda ação de triagem e rotação de token é registrada no log de auditoria.

Ativar a entrada por e-mail (operacional)

O código está pronto; ligar o roteamento inbound é uma configuração de infraestrutura. O caminho recomendado (stack AWS) é:

1. Verifique o domínio de reports no SES (reports.seu-dominio), numa região com inbound (us-east-1, us-west-2 ou eu-west-1).
2. Aponte o MX do domínio para inbound-smtp.<região>.amazonaws.com.
3. Crie uma regra de recebimento (receipt rule) que grava a mensagem crua num bucket S3 (com policy permitindo PutObject ao ses.amazonaws.com).
4. Uma função Lambda lê o e-mail cru do S3, extrai o código do endereço report-<código>@, e faz um POST para o endpoint de inbound da qlture com o segredo compartilhado no header.

Variáveis que ligam o recurso no backend:

REPORT_INBOUND_SECRET=<openssl rand -hex 32>
REPORT_INBOUND_DOMAIN=reports.seu-dominio

Se o seu DNS estiver na Cloudflare, há um caminho mais simples: Email Routing + um Email Worker que faz o mesmo POST — sem SES, S3 ou Lambda.

Quando o inbound está ligado no servidor, o card de configuração na tela de Triagem passa a exibir o endereço de report do seu tenant.

Roadmap

Itens planejados e ainda não disponíveis: add-in de 1 clique para Outlook/Gmail (alternativa ao encaminhamento), clawback (remoção do e-mail malicioso das caixas), e armazenamento de anexos.

Relacionado

• Simulação de phishing — o outro lado do ciclo.
• Provisionamento SCIM — mesmo padrão de token por tenant.

---

Remetentes, templates e páginas

← Anterior

Comunicados

Próximo →

Docs relacionados