Incident Response Report (redacted sample)
This is a redacted sample, published with the client's permission. Names, dates, places, financial institutions, addresses, network indicators and evidence files were removed. Times are shown relative to the first unauthorized sign-in ("Hour 0"). The client's own report keeps all of them.
1. Executive summary
An attacker who already had the password signed in to the client's personal email and created a hidden rule that sent a copy of every incoming message to an outside address. The rule kept working for about three days and survived two password changes, because email rules are not removed when the password changes.
Through that copy, the attacker received verification codes, purchase alerts and bank messages. We proved that a bank notice about a charge issued in the client's name was forwarded to the attacker. The attacker also changed the junk-mail settings to hide the trail.
On the day of the engagement we removed the rule, shut the extra access the attacker had opened, turned on two-step verification and gave the client a prioritized plan to protect their identity and finances.
9countries in under 24 hours (sign-ins and attempts)
2password resets survived by the rule
4provider blocks, then back in 2 hours later
Same dayleak stopped
2. Scope, method and limits
Scope: the email account (mailbox, mail settings, sign-in activity, recovery methods, app activity and connected cloud storage). Out of scope: forensic analysis of the client's devices and their accounts at other companies; those received recommendations instead.
Method:
- Evidence captured before any change, each file fingerprinted with SHA-256 so it can be shown unaltered later.
- Technical headers of the delivery-failure notices analyzed.
- Sign-in log, headers and received messages correlated into one timeline (UTC).
- Containment, then hardening.
Limits we state openly: personal email accounts do not keep a full audit log (rule creation is not recorded), and how the attacker first got the password cannot be proven from the account's data. The report separates what is proven from what is probable.
3. Timeline
| When | Event | Source |
|---|---|---|
| Hour 0 | First unauthorized sign-in, successful on the first try (the password was already known) | Sign-in log |
| Hours 0–15 | Sign-ins and "unusual activity" from several countries: an "impossible travel" pattern, consistent with proxies or VPNs | Sign-in log |
| Hour 15 | A bank notice about a charge issued in the client's name arrives and is forwarded 4 seconds later by the mailbox's own rule engine | Message headers |
| Hours 17–19 | The provider blocks 4 sign-ins and flags the account as compromised | Sign-in log |
| Hour 21 | Attacker signs in successfully again, including from a cloud data center | Sign-in log |
| Hour 21 and Day 4 | Client resets the password twice; the rule keeps forwarding | Sign-in log, mailbox |
| Days 2–4 | Fraud signals reach the client: new-device alert at a marketplace, notice of a new card being shipped, a credit score change, targeted phishing | Mailbox |
| Day 4 | Engagement: rule found active, now pointing to a second address; removed. Extra access closed. Two-step verification on | Analyst |
4. Key findings
| Severity | Finding |
|---|---|
| Critical | Active forwarding rule: "if a message arrives, forward it to an outside address and stop processing other rules". Nearly every message in the inbox showed the forwarded icon. |
| Critical | Proof it was automatic: the headers carry generated-message-source: Mailbox Rules Agent, Inbox-Rules-Loop and auto-submitted: auto-generated, and the provider's DKIM signature shows they left the account itself. |
| Critical | Sign-ins and attempts from 9 countries in under 24 hours; the first one succeeded with no failed attempts before it. |
| High | The attacker got back in after the provider blocked the account as compromised, once from a cloud server address. |
| High | Sender lists manipulated to hide the trail: a financial company's real addresses and the delivery-failure notices were blocked; look-alike domains imitating that company were marked as trusted, one using an accented letter that looks identical at a glance. Blocked mail is deleted without reaching the trash. |
| High | POP download turned on (off by default), allowing a copy of the whole mailbox. |
| High | A draft holding the client's full personal and ID data sat in the mailbox, enough to attempt accounts or credit in their name. |
| Medium | Targeted phishing using real government programs as bait, from the same sender pattern. |
| Checked | Recovery methods legitimate and unchanged; no global forwarding, no sweep rules, no file sharing or deletions in cloud storage. |
5. Proven, probable, hypothesis
| Statement | Level |
|---|---|
| Unauthorized access starting at Hour 0 | Proven |
| A rule forwarded all incoming mail to the attacker | Proven |
| A bank notice about a charge in the client's name reached the attacker | Proven |
| Real senders were blocked and impostors trusted | Proven |
| The rule survived the password resets | Proven |
| The attacker turned on POP | Probable |
| The password was obtained by phishing, a reused leaked password or info-stealing malware | Hypothesis (no data in the account tells them apart) |
| The goal was financial and identity fraud | Strong hypothesis |
6. Containment and hardening
| Item | Before | After |
|---|---|---|
| Forwarding rule | Active, forwarding everything | Removed |
| POP / IMAP access | On | Off |
| Blocked and trusted senders | Manipulated | Cleanup guided with the client |
| Two-step verification | Off | On, with an authenticator app |
| Recovery methods | Not checked | Checked: all legitimate |
| App passwords | — | None created |
| Cloud storage and lists | Not checked | Checked: no damage found |
7. Recovery plan delivered to the client
The biggest remaining risk was no longer the mailbox but the use of the client's identity outside it. The plan was ordered by urgency:
- Today: check the national credit registry for accounts or loans not recognized; report the charge and any card not requested to the bank through its app or official number (never through email links); turn on identity-use alerts at the credit bureau; set a new, unique password, sign out everywhere and generate a new recovery code.
- This week: secure the marketplace account and dispute the purchase; contact the financial company about a possible account opened in the client's name; file a police report with this report attached; review the phone's cloud account; ask the person who is the account's recovery contact to turn on two-step verification; change any reused passwords.
- Devices and habits: check the phone for management profiles and updates; scan any computer offline before typing passwords on it; never approve a sign-in request you did not start; do not keep full ID data in email drafts.
8. What the full report also includes
- Indicators of compromise (addresses, domains, IPs) ready to report to the email provider, banks and police.
- The header transcripts and the list of evidence files with their SHA-256 fingerprints.
- Open items that could change a conclusion, each with who must confirm it.
Why this matters for a business: a hidden forwarding rule is how most business email fraud starts. Attackers read your invoices, then send your customers new payment details. Changing the password does not remove it. Talk to us if you want your email checked.
Relatório de Resposta a Incidente (amostra anonimizada)
Esta é uma amostra anonimizada, publicada com autorização do cliente. Nomes, datas, lugares, instituições financeiras, endereços, indicadores de rede e arquivos de evidência foram removidos. Os horários aparecem em relação à primeira entrada não autorizada ("Hora 0"). O relatório entregue ao cliente mantém tudo isso.
1. Sumário executivo
Um invasor que já tinha a senha entrou no e-mail pessoal do cliente e criou uma regra oculta que enviava uma cópia de toda mensagem recebida para um endereço externo. A regra funcionou por cerca de três dias e sobreviveu a duas trocas de senha, porque regras de e-mail não são apagadas quando a senha muda.
Por essa cópia, o invasor recebeu códigos de verificação, avisos de compra e mensagens de banco. Provamos que um aviso de banco sobre uma cobrança emitida no nome do cliente foi encaminhado ao invasor. O invasor também alterou as configurações de lixo eletrônico para esconder os rastros.
No dia do atendimento removemos a regra, fechamos os acessos extras abertos pelo invasor, ativamos a verificação em duas etapas e entregamos ao cliente um plano por prioridade para proteger sua identidade e suas finanças.
9países em menos de 24 horas (entradas e tentativas)
2trocas de senha que a regra sobreviveu
4bloqueios do provedor, e nova entrada 2 horas depois
Mesmo diavazamento contido
2. Escopo, método e limites
Escopo: a conta de e-mail (caixa, configurações, atividade de entrada, métodos de recuperação, atividade de aplicativos e armazenamento em nuvem ligado à conta). Fora do escopo: perícia nos aparelhos do cliente e nas contas dele em outras empresas; para esses itens houve recomendações.
Método:
- Evidências capturadas antes de qualquer alteração, cada arquivo com impressão digital SHA-256 para provar depois que não foi alterado.
- Análise dos cabeçalhos técnicos dos avisos de falha de entrega.
- Log de entradas, cabeçalhos e mensagens recebidas cruzados numa única linha do tempo (UTC).
- Contenção, depois reforço da conta.
Limites declarados: contas de e-mail pessoais não guardam log de auditoria completo (a criação de regras não é registrada), e como o invasor obteve a senha não pode ser provado com os dados da conta. O relatório separa o que está provado do que é provável.
3. Linha do tempo
| Quando | Evento | Fonte |
|---|---|---|
| Hora 0 | Primeira entrada não autorizada, bem-sucedida na primeira tentativa (a senha já era conhecida) | Log de entradas |
| Horas 0–15 | Entradas e "atividade incomum" de vários países: padrão de "viagem impossível", compatível com proxies ou VPNs | Log de entradas |
| Hora 15 | Chega um aviso de banco sobre cobrança emitida no nome do cliente, encaminhado 4 segundos depois pelo próprio mecanismo de regras da caixa | Cabeçalhos |
| Horas 17–19 | O provedor bloqueia 4 entradas e marca a conta como comprometida | Log de entradas |
| Hora 21 | O invasor entra de novo, inclusive a partir de um data center em nuvem | Log de entradas |
| Hora 21 e Dia 4 | O cliente troca a senha duas vezes; a regra continua encaminhando | Log de entradas, caixa |
| Dias 2–4 | Sinais de fraude chegam ao cliente: alerta de novo aparelho num marketplace, aviso de um cartão novo a caminho, mudança no score de crédito, phishing direcionado | Caixa |
| Dia 4 | Atendimento: regra encontrada ativa, já apontando para um segundo endereço; removida. Acessos extras fechados. Verificação em duas etapas ativada | Analista |
4. Principais achados
| Gravidade | Achado |
|---|---|
| Crítico | Regra de encaminhamento ativa: "se chegar uma mensagem, encaminhar para um endereço externo e parar de processar outras regras". Quase toda mensagem da caixa mostrava o ícone de encaminhada. |
| Crítico | Prova de que era automático: os cabeçalhos trazem generated-message-source: Mailbox Rules Agent, Inbox-Rules-Loop e auto-submitted: auto-generated, e a assinatura DKIM do provedor mostra que as mensagens saíram da própria conta. |
| Crítico | Entradas e tentativas de 9 países em menos de 24 horas; a primeira deu certo sem nenhuma falha antes. |
| Alto | O invasor voltou a entrar depois que o provedor bloqueou a conta como comprometida, uma vez a partir de um servidor em nuvem. |
| Alto | Listas de remetentes manipuladas para esconder rastros: os endereços reais de uma empresa financeira e os avisos de falha de entrega foram bloqueados; domínios que imitam essa empresa foram marcados como confiáveis, um deles com uma letra acentuada que parece idêntica à primeira vista. E-mail bloqueado é apagado sem passar pela lixeira. |
| Alto | Acesso POP ligado (vem desligado por padrão), permitindo baixar a caixa inteira. |
| Alto | Um rascunho com os dados pessoais e de documento completos do cliente estava na caixa, o suficiente para tentar abrir contas ou pedir crédito no nome dele. |
| Médio | Phishing direcionado usando programas reais do governo como isca, com o mesmo padrão de remetente. |
| Verificado | Métodos de recuperação legítimos e sem alteração; sem encaminhamento global, sem regras de limpeza, sem compartilhamento ou exclusão de arquivos na nuvem. |
5. Provado, provável, hipótese
| Afirmação | Nível |
|---|---|
| Acesso não autorizado a partir da Hora 0 | Provado |
| Uma regra encaminhava todo e-mail recebido ao invasor | Provado |
| Um aviso de banco sobre cobrança no nome do cliente chegou ao invasor | Provado |
| Remetentes reais foram bloqueados e impostores liberados | Provado |
| A regra sobreviveu às trocas de senha | Provado |
| O invasor ligou o POP | Provável |
| A senha foi obtida por phishing, senha reutilizada vazada ou malware ladrão de senhas | Hipótese (nenhum dado da conta distingue entre elas) |
| O objetivo era fraude financeira e de identidade | Hipótese forte |
6. Contenção e reforço
| Item | Antes | Depois |
|---|---|---|
| Regra de encaminhamento | Ativa, encaminhando tudo | Removida |
| Acesso POP / IMAP | Ligado | Desligado |
| Remetentes bloqueados e confiáveis | Manipulados | Limpeza orientada com o cliente |
| Verificação em duas etapas | Desligada | Ligada, com app autenticador |
| Métodos de recuperação | Não verificados | Verificados: todos legítimos |
| Senhas de aplicativo | — | Nenhuma criada |
| Nuvem e listas | Não verificadas | Verificadas: sem dano |
7. Plano de recuperação entregue ao cliente
O maior risco restante já não era a caixa de e-mail, e sim o uso da identidade do cliente fora dela. O plano foi ordenado por urgência:
- Hoje: consultar o registro nacional de crédito em busca de contas ou empréstimos desconhecidos; informar ao banco a cobrança e qualquer cartão não pedido pelo app ou número oficial (nunca por links de e-mail); ativar alertas de uso do documento no birô de crédito; criar senha nova e única, sair de todos os lugares e gerar novo código de recuperação.
- Nesta semana: proteger a conta do marketplace e contestar a compra; avisar a empresa financeira sobre possível conta aberta no nome do cliente; registrar boletim de ocorrência com este relatório anexo; revisar a conta de nuvem do celular; pedir ao contato de recuperação da conta que ative a verificação em duas etapas; trocar senhas reutilizadas.
- Aparelhos e hábitos: conferir perfis de gerenciamento e atualizações no celular; verificar qualquer computador offline antes de digitar senhas nele; nunca aprovar uma entrada que você não iniciou; não guardar dados completos de documentos em rascunhos de e-mail.
8. O que o relatório completo também traz
- Indicadores de comprometimento (endereços, domínios, IPs) prontos para denúncia ao provedor de e-mail, aos bancos e à polícia.
- A transcrição dos cabeçalhos e a lista de arquivos de evidência com as impressões digitais SHA-256.
- Pendências que podem mudar uma conclusão, cada uma com quem deve confirmá-la.
Por que isso importa para uma empresa: uma regra de encaminhamento oculta é como começa a maioria das fraudes por e-mail corporativo. O invasor lê suas faturas e depois manda aos seus clientes novos dados de pagamento. Trocar a senha não a remove. Fale com a gente se quiser verificar seu e-mail.