Golpe de Phishing Sofisticado: E-mails que Parecem Vir do Google
Existe um golpe de phishing extremamente inteligente circulando, onde os criminosos conseguiram fazer com que o próprio Google enviasse e-mails fraudulentos. O detalhe mais alarmante é que esses e-mails parecem genuinamente originários de `no-reply@accounts.google.com`.
Embora o Google estivesse trabalhando em uma correção para essa falha específica, a técnica utilizada pelos golpistas pode ser aplicada futuramente, o que torna crucial entender como isso funciona.
Um relato descreveu como um usuário recebeu um e-mail alegando: “Uma intimação foi expedida contra a Google LLC exigindo que produzíssemos uma cópia do conteúdo da sua conta Google”, seguido de um link para um suposto “caso de suporte do Google”.
Ao clicar, a vítima era direcionada a um site que parecia extremamente legítimo, com o mesmo estilo visual que o Google costuma utilizar. Havia um botão “Visualizar Caso” que, previsivelmente, levava a um prompt de login falso, idêntico ao de login do Google, projetado para roubar credenciais.
### A Trilha do Engano: Por que o E-mail Parecia Genuíno
O aspecto mais traiçoeiro era que os golpistas não precisaram falsificar o endereço do remetente (From address). Ele de fato mostrava `no-reply@accounts.google.com`. Sem uma análise minuciosa, ou conhecimento do que procurar, o e-mail parecia autêntico.
Mais surpreendente ainda: mesmo ao verificar os cabeçalhos do e-mail e as verificações de autenticação padrão como SPF, DKIM e DMARC, as mensagens passavam em todos os testes. Isso é particularmente preocupante, pois verificar esses elementos costuma ser a primeira linha de defesa contra e-mails forjados.
### Como os Golpistas Executaram o Ataque
Os golpistas empregaram duas estratégias principais para enganar os sistemas de verificação:
#### 1. Utilização do sites.google.com
A primeira parte envolveu hospedar o site fraudulento em `sites.google.com`. O Google permite que usuários hospedem seus próprios websites nesse domínio. Se alguém não soubesse que qualquer pessoa pode criar uma página `sites.google.com`, poderia facilmente presumir que o site estava sendo hospedado diretamente pelo Google.
#### 2. O Ataque de “DKIM Replay”
A segunda e mais sofisticada tática foi o que se pode chamar de “DKIM Replay”. Os protocolos de verificação como SPF, DKIM e DMARC existem em grande parte para garantir que o conteúdo do e-mail (incluindo o endereço De e o corpo da mensagem) não tenha sido alterado após ser enviado.
Para entender isso, imagine a seguinte analogia complexa:
Imagine uma máquina mágica que verifica duas coisas em uma carta:
1. Se a carta tem uma assinatura válida da pessoa que alega ter enviado.
2. Se o texto da carta não foi alterado.
Agora, imagine que um golpista consegue uma carta oficial, assinada por um juiz, que deveria ir para um criminoso específico (ex: “Olá, canalha. Você está com sérios problemas…”). Esta carta, no entanto, não contém o nome do destinatário final no corpo, apenas no envelope externo.
O golpista retira a carta do envelope original e a coloca em um novo envelope endereçado a você, apresentando-se como um policial à paisana, dizendo: “Pague uma multa ou me dê seus dados de login, ou você vai para a cadeia.” Ao ler a carta, você vê que ela realmente foi assinada por um juiz e contém ameaças, fazendo você ceder ao que ele pede.
A realidade, neste cenário, é que **a carta interna era real, mas o envelope era falso**.
No contexto dos e-mails, o corpo da mensagem é como a carta, e alguns cabeçalhos (como o *envelope* de envio) são verificados. O que os golpistas exploraram foi que, embora o corpo e os endereços essenciais estivessem intactos (e, portanto, passassem na verificação DKIM), o destino final do e-mail estava sendo manipulado de uma forma não coberta por essas verificações.
Em essência, o Google realmente enviou um e-mail para *alguém* contendo o texto sobre a intimação, originado de `accounts.google.com`.
### Como o E-mail Chegou à Vítima
O mecanismo para que esse e-mail chegasse à caixa de entrada da vítima envolveu o uso de APIs do Google e serviços de retransmissão de e-mail:
1. **Criação de um Aplicativo Falso:** Os golpistas criaram um aplicativo que interage com a API do Google. Ao registrar o aplicativo, eles definiram o “nome” do aplicativo como todo o texto da mensagem de phishing, incluindo quebras de linha e espaços.
2. **Conta de Autorização:** Eles registraram um domínio não associado ao Google e criaram uma conta de e-mail usando esse domínio (ex: `me@seudominiofalso.com`).
3. **Autorização do Aplicativo:** Eles usaram essa conta fraudulenta para autorizar o aplicativo que acabaram de criar.
4. **E-mail de Confirmação do Google:** Como resultado da autorização, o Google enviou um e-mail de alerta de segurança para `me@seudominiofalso.com`, com o assunto: “Você concedeu acesso ao aplicativo [NOME LONGO DO TEXTO DO GOLPE] à sua conta”.
É exatamente esse e-mail de confirmação, enviado pelo Google, que é usado como corpo do golpe.
Para que esse e-mail chegasse à vítima, os golpistas utilizaram serviços de retransmissão de e-mail (forwarding services) que permitem a entrega do e-mail para um destinatário específico, mesmo que este não seja o endereço `To:` listado no cabeçalho original.
No e-mail recebido pela vítima, o endereço `To:` frequentemente mostrava `me@seudominiofalso.com` (ou apenas “me” como abreviação), pois o sistema do Google assume que o destinatário é quem está lendo o alerta de segurança. O ponto crucial é que as verificações de autenticação apenas checaram se o *conteúdo* e os endereços *De/Para originais* batiam, ignorando se a caixa de entrada receptora era a destinada originalmente.
### Como Identificar o Golpe (Mesmo com a Correção do Google)
Mesmo que o Google tenha corrigido essa vulnerabilidade específica, é importante saber identificar os sinais de alerta em e-mails suspeitos:
* **Endereço `To:` Incorreto:** Verificar o endereço `To:` no cabeçalho detalhado. Se o e-mail foi enviado para outra pessoa, mas chegou até você (e não é um CC ou BCC), isso é um forte indicativo de problema.
* **Domínio do Link:** O link no corpo do e-mail apontava para um domínio `sites.google.com`. Embora o Google não use ativamente essa plataforma para comunicações sérias, saber que qualquer um pode criar um site nela deve levantar suspeitas.
* **Detalhe “Mailed By”:** Mesmo que o e-mail diga ter sido enviado por `accounts.google.com` (o que é verdade no caso da notificação de API), a informação “Mailed By” (Enviado Por) pode apontar para o domínio do golpista, e não para os servidores legítimos do Google.
Relatos indicam que, inicialmente, ao ser notificado, o Google afirmou que o comportamento estava “funcionando como pretendido”, tratando-o como um recurso da API e não um bug. Após grande atenção da mídia, a empresa indicou que implementaria uma correção. Contudo, a técnica pode ser adaptada para outros serviços além do Google.
No cenário atual, a lição principal é que, mesmo que o endereço do remetente pareça legítimo, a desconfiança deve ser a regra, especialmente se o e-mail solicitar ações urgentes ou dados confidenciais.
Perguntas Frequentes
- Como os golpistas conseguiram a assinatura do Google?
Eles não falsificaram a assinatura direta. Eles usaram um recurso legítimo do Google (a notificação de autorização de aplicativos de terceiros) para fazer com que o próprio Google enviasse um e-mail com o corpo da mensagem fraudulenta. - O que é DKIM Replay neste contexto?
É a exploração da verificação DKIM, que garante que o conteúdo do e-mail não foi alterado. Os golpistas garantiram que o conteúdo (o corpo e os endereços De/Para originais) permanecesse o mesmo, fazendo com que os testes de autenticação fossem aprovados, embora o destinatário final do e-mail tenha sido alterado via um serviço de retransmissão. - É possível que outros serviços usem uma técnica similar?
Sim, a técnica explorada depende de como um serviço envia notificações de autorização de API. Se outros serviços permitem que o nome do aplicativo contenha texto longo ou customizado, um ataque análogo pode ser possível em outras plataformas. - Qual a melhor forma de verificar a autenticidade de um e-mail do Google?
Verifique sempre se o link de ação leva a um domínio oficial do Google (como google.com). Se o e-mail envolver um link para um site, desconfie se ele aponta para serviços de hospedagem gratuita, como sites.google.com, em contextos sensíveis. - Por que a verificação SPF, DKIM e DMARC falhou em detectar a fraude?
Essas verificações confirmam a integridade do e-mail desde o ponto de envio até o ponto de retransmissão. Como o e-mail foi genuinamente enviado por um servidor do Google para um intermediário, e o corpo da mensagem não foi modificado durante o trajeto, as assinaturas técnicas estavam corretas, mas o destino final foi redirecionado maliciosamente.
