4 Análise dos Emails

4.1 Pretextos

Os atacantes usaram técnicas psicológicas de engenharia social como urgência, ao tratar de assuntos sensíveis como acesso indevido e inativação de conta, e autoridade ao se direcionar ao alvo como RH (primeira tentativa de phishing, março-2025 Figura 1), e como o suporte da própria plataforma de email da empresa (segunda tentativa, junho-2025, Figura 2).

Figura 1: Pretexto do primeiro email

Figura 2: Pretexto do segundo email

4.2 Páginas Clonadas

Neste tópico veremos as páginas clonadas do primeiro e do segundo ataque, em contraste com a página oficial.

Na página oficial, logo abaixo, podemos notar que a URL está correta e o site usa https.

Figura 3: Página original

No primeiro clone, nota-se uma URL completamente diferente da original, e o email do usuário já está populado. Os idiomas abaixo também estão mal escritos. No segundo clone, o atacante usou um provedor de sites web, nota-se o mesmo problema na apresentação dos idiomas, além das caixas de input não parecerem profissionais.

Figura 4: Primeiro clone

Figura 5: Segundo clone

4.3 Objetivo do Atacante

Com base no clone das páginas de login e na análise feita com o software BurpSuite, o phishing tinha como objetivo coletar as credenciais do alvo. O spoofing do email e seu uso como remetente facilita a exposição de credenciais e possível vazamento de dados em cadeia, comprometendo tanto a privacidade do alvo, quanto a dos clientes para os quais o alvo fornece serviços.

Na Figura 7, observa-se que, ao clicar no botão Log in, as credenciais são enviadas em um request do tipo POST para um servidor malicioso, também identificado na imagem. Detalhe que as informações são enviadas em plaintext, ou seja, completamente sem criptografia.

Figura 6: Exemplo de inserção de credenciais.

Figura 7: Resquest POST.

5. Análise do Source Code - Primeira Tentativa de Phishing

Aqui será analisado o source code da primeira tentativa de phishing, onde será feita uma análise mais aprofundada das partes relevantes do header.

5.1 Cadeia de Recebimento - Received Chain

A cadeia de recebimento (received chain) é formada pelos servidores que manipularam o e-mail, incluindo o servidor do destinatário. Podemos fazer um rastreamento percorrendo o source code do e-mail na direção top -> bottom.

No top está a conexão mais recente (geralmente o servidor do destinatário), enquanto que no bottom está a conexão mais antiga, ou seja, a do servidor que originou a comunicação.

A importância destes elementos reside no fato de que todos os endereços de IP dos servidores estão no source code, o que nos permite analisar o caminho feito pelo e-mail. Porém, isso nos dará apenas uma ideia do que pode ter ocorrido, já que os IPs não são uma fonte confiável de intel.

No primeiro bloco do email temos o último ponto de contato (servidor mais recente): cpanel-003-fra.hostingww.com, usando o protocolo LMTP. Este contato é o servidor do provedor de email do cliente.

1
2
3
4
5
6
7
8
9
10
11
12
  X-Mozilla-Status: 0001
  X-Mozilla-Status2: 00000000
  Return-Path: <hr@corridorconstructioniowa.cam>
  Delivered-To: ceo@msolutions.com
  Received: from cpanel-003-fra.hostingww.com
    by cpanel-003-fra.hostingww.com with LMTP
    id EGKZEk+WC2jNvzYA2p0M4Q
    (envelope-from <hr@corridorconstructioniowa.cam>)
    for <ceo@msolutions.com>; Fri, 25 Apr 2025 14:03:59 +0000
  Return-path: <hr@corridorconstructioniowa.cam>
  Envelope-to: ceo@msolutions.com
  Delivery-date: Fri, 25 Apr 2025 14:03:59 +0000

No segundo bloco temos outro servidor, de IP 148.113.172.133 e URL vps-58680c2d.vps.ovh.ca. Neste bloco o servidor de envio vps-58680c2d.vps.ovh.ca se anuncia ao servidor de recebimento usando o helo=mail.corridorconstructioniowa.cam, e o servidor do cliente aceita receber o email. O helo funcionaria como um “handshake” e é uma parte essencial no protocolo SMTP, já que ele verifica a saúde dos servidores.

Neste caso, a ferramenta Virus Total não sinalizou o domínio nem o IP, porém a ferramenta retorna um achado importante relacionado ao IP 148.113.172.133:

Aqui temos três pontos interessantes:

1. O CN está associado a um site duvidoso;
2. As autoridades certificadoras não são confiáveis;
3. O certificado está vencido.

Além disso, o email passou por outro país antes de chegar no servidor final, o WHOIS indica que o hosting está sendo feito no Canadá.

Outro achado é que o subdomínio que aparece no CN não retorna nenhuma flag maliciosa na inspeção com o Virus Total, porém se fizermos uma busca pelo domínio, teremos algumas flags associadas aos IPs reconhecidos pelo pDNS (passive DNS, que é uma gravação histórica das resoluções DNS do domínio).

Figura 8: IPs reconhecidos pelo pDNS.

No terceiro bloco, e último contendo a tag Received, temos o primeiro servidor, o servidor que provavelmente gerou o email. O virustotal não tem nenhuma informação sobre a URL ip-134-38.dataclub.info, porém temos informações sobre o IP 84.38.134.38. O servidor está na Latvia, porém nenhum vendor sinalizou o IP nem como malicioso nem como não malicioso, o que é estranho.

Também temos estas informações na aba DETAILS do Virus Total, associadas ao IP:

1
2
3
4
5
  role: DATCLUB SIA 
  address: Kraslavas iela 14 - 2 
  address: LV1003 
  address: Riga, Latvia 
  phone: +371 60-00-77-98 

Uma breve pesquisa OSINT usando google maps nos retorna o seguinte:

Figura 9: Busca OSINT do local.

Lembrando que não é possível dar certeza do endereço do servidor, pois o atacante poderia estar usando uma VPN, Tor, etc.

Ainda sobre o IP 84.38.134.38, temos uma informação importante: foram detectados mais de 10 arquivos incorporando este IP. Na aba RELATIONS do site virustotal temos 23 arquivos que fazem referência ao IP, sempre relacionados a arquivos de email, como mostra a imagem abaixo.

Todos os arquivos estão relacionados à detecção de trojan. Infelizmente não podemos ter certeza de qual trojan estaria sendo usado, pois as flags abaixo são generalistas, são flags levantadas quando um arquivo possui um comportamento parecido a um trojan. Também não podemos inferir que algum malware está associado ao link do e-mail.

5.2 Caminho de Retorno - Return-path

O caminho de retorno (Return-path) é o endereço usado para enviar o email. Podemos vê-lo no primeiro bloco do source code, em verde. ___

O e-mail hr@corridorconstructioniowa.cam pode até existir, mas o site corridorconstructioniowa.cam não. O interessante é que a empresa existe e é legítima, mas parece que sofreu um TLD-squatting e estão usando o domínio de forma maliciosa.

Figura 12: Empresa legítima.