ANÁLISE DE CABEÇALHO DE E-MAIL

Estudo acerca de Crimes Digitais para fins de documentação e criação de acervo de conteúdo voltado â Segurança Cibernética e Forense Digital na Academia de Forense Digital.

Por FADRIQUE BRITO GONÇALVES

Orientador(a): Renan Cavalheiro.

FRUTAL – MG

2020

INTRODUÇÃO

Atualmente existe uma generosa lista com diversas opções para aplicações de mensagens, principalmente mensagens instantâneas, na internet. A praticidade que se tem na conversa, praticamente em tempo real, é valiosa.

Entretanto, o longevo e-mail ainda se faz fortemente presente na vida das pessoas, principalmente no meio corporativo. Grande parte de sua necessidade também se dá pelo fato da utilização deles para criação de conta em diversos sites, redes sociais, serviços, softwares, etc.

Seu uso, principalmente como mecanismo de autenticação em plataformas, faz com que a atenção de cyber criminosos seja atraída para eles.

Ademais, o fato de ser um receptor de mensagens em massa contribui para a atenção recebida, afinal, a caixa de entrada de e-mails é um portal aberto para diversas mensagens importantes de bancos, compras, questões profissionais, lazer, etc.

Um e-mail mal-intencionado, e devidamente camuflado, no meio de mensagens verídicas, pode ser o ponto crucial para um ataque ser bem realizado.

Além disso, não é raro um indivíduo que já cadastrou seu e-mail em, pelo menos, uma dezena de lugares na internet, ser bombardeado com outras dezenas de e-mails de lugares que não conhece.

Com efeito, o spam é uma inconveniência fortemente presente no serviço de e-mail e, ao que tudo indica, ainda se manterá por muito tempo.

Então, tem-se nos serviços de e-mail, uma presença demasiada grande, e hostil, de riscos em potencial durante a navegação na internet. Saber distinguir, tecnicamente, a origem da mensagem, vai muito além de analisar o verdadeiro endereço de e-mail do remetente e procurar por alguma contradição com seus dados reais no corpo do e-mail, embora isso seja um bom início.

Para uma investigação eficaz, é importante destacar que o e-mail é dividido em duas partes: corpo e cabeçalho. O corpo do e-mail é a parte na qual a mensagem é apresentada e, geralmente, tem-se por cabeçalho os campos “assunto”, “destinatário” e “remetente”. 

Apesar destes campos também fazerem parte do cabeçalho, eles são apenas a ponta do iceberg, pois com a análise técnica do cabeçalho, é possível encontrar muitas informações acerca da origem do e-mail, bem como características que podem evidenciar uma possível ilegitimidade da mensagem.

Como tudo na forense, a busca por dados no cabeçalho de e-mail pode encontrar dificuldades, ofuscamento e afins.

Entretanto, vários metadados são passíveis de serem achados, de modo que, abaixo, será esmiuçada a análise do cabeçalho de e-mail.

1 COMPREENDENDO O CABEÇALHO DE E-MAIL

Encontrar o cabeçalho de e-mail é muito simples, não sendo necessário nenhuma investigação aprofundada, tampouco uma escavação de bits.

Entretanto, interpretá-lo pode ser um desafio, pois, como vários outros artefatos na forense digital, o cabeçalho de e-mail nos é apresentado como um emaranhado de caracteres que, a priori, pode assustar. Ao entender os diversos campos e sua cronologia, no entanto, tudo se torna mais claro.

A fim de simplificar o texto, no restante do presente trabalho o cabeçalho de e-mail será, por vezes, tratado apenas pelo termo “cabeçalho”. Nesse mesmo sentido, o termo “mensagem” poderá aparecer referenciando um e-mail enviado/recebido.

Vale esclarecer, ainda, que neste trabalho iremos tratar, mais especificamente, dos serviços de e-mail Gmail e Microsoft Outlook. Entretanto, os principais campos, via de regra, estarão em qualquer mensagem transmitida através de qualquer outro serviço.

Para encontrar o cabeçalho no Gmail, basta abrir a mensagem, encontrar o ícone de três pontos, ao lado direito, acioná-lo e então clicar em “mostrar original”, e uma nova guia no navegador será aberta apresentando o cabeçalho. Já no Outlook, ao encontrar os três pontos, também ao lado direito na tela da mensagem, vá até a opção “exibir” e clique em “exibir origem da mensagem”, então irá aparecer uma janela flutuante contendo todo o cabeçalho.

No cabeçalho, é possível encontrar dados acerca da origem da mensagem, seu caminho durante diversos MTA’s[1] até o destino, criptografia utilizada, domínio do serviço de e-mail que foi realmente utilizado, endereços IP por onde a mensagem passou, receptores de possíveis respostas ao e-mail e uma série de outros dados que auxiliarão na investigação forense. É natural, assim como em praticamente toda análise forense digital, que o investigador se depare com possíveis ofuscamentos de artefatos e dados não palatáveis à leitura humana.

[1] Um MTA (Mail Transfer Agent) faz parte da engrenagem na retransmissão de um e-mail. Quando um e-mail é enviado, ele atravessa um ou mais MTA’s até chegar no seu destino. Eles servem de retransmissores entre o agente de serviço de e-mail do usuário que envia a mensagem até o agente de serviço de e-mail do usuário que recebe a mensagem. Basicamente, a mensagem faz “pulos”, entre MTA’s, até chegar ao seu destino.

Contudo, uma análise técnica bem feita apoiada em ferramentas disponíveis, com certeza, trará luz ao caso. A partir desses dados o investigador já está munido de informações para analisar, tecnicamente, todas as singularidades do e-mail recebido.

Logo, segue abaixo um exemplo de cabeçalho retirado do Gmail, com a única função de mostrar parte de um cabeçalho de forma legível, haja vista que uma única imagem de todo o cabeçalho, naturalmente, ficaria inviável para leitura. Ressalta-se, também, que o foco ainda não está na análise dos campos ou seu entendimento forense, e sim na demonstração da aparência de um cabeçalho de e-mail.

Figura 1 – Cabeçalho de e-mail de uma mensagem recebida no Gmail.

Fonte: print screen do cabeçalho no navegador web.

Para fins de praticidade neste trabalho, foi utilizado o editor Sublime Text 3 com o pacote “Email Header” que facilita a leitura dos campos do cabeçalho.

O pacote pode ser baixado através do link “https://packagecontrol.io/packages/Email%20Header”.

A imagem abaixo apresenta parte do cabeçalho que aponta informações como:

• To (linha 76): especifica o destinatário da mensagem;
• From (linha 75): especifica o endereço de e-mail do remetente da mensagem;
• Subject (linha 74): mostra o campo “assunto” que aparece na mensagem;
• Message-ID (linha 73): um identificador único seguido do domínio (ou IP) da origem da mensagem;
• Date (linha 64): especifica a data e hora do momento do envio da mensagem;
• MIME-Version (linha 62): especifica a versão da extensão MIME. Essa extensão permite que, no texto da mensagem, haja informações não ASCII e não textuais, podendo conter também imagens, áudios, vídeos e etc.

Figura 2 – Cabeçalho de e-mail no Sublime Text 3.

Fonte: print screen do cabeçalho no Sublime Text 3.

Também são indicados no cabeçalho dados que indicam os “pulos” da mensagem entre MTA’s até enfim ser entregue ao destinatário. A imagem abaixo mostra tais informações:

• Received (linha 29): especifica um receptor (MTA) que aceitou a mensagem para retransmiti-la. Esse campo é adicionado pelo SMTP do receptor, bem como o dado de data e hora que referencia quando ela foi recebida. É normal haver vários campos Received em um mesmo cabeçalho;
• Return-Path (linha 28): especifica para qual e-mail será enviada uma mensagem no caso de haver erro na entrega;
• Received (linha 2): basicamente igual à linha 29, mostrada acima;
• Delivered-To (linha 1): especifica a entrega definitiva ao destinatário.

Figura 3 – Cabeçalho de e-mail no Sublime Text 3.

Fonte: print screen do cabeçalho no Sublime Text 3.

O cabeçalho analisado neste tópico, como pode ser visto na figura 2, remete a um e-mail da plataforma YouTube. O e-mail é autentico e seus campos serviram de demonstração para um primeiro entendimento de como o cabeçalho é estruturado, porém, ainda não foi aplicada nenhuma análise forense.

Foram apresentados dados no cabeçalho que até podem servir de evidências em uma investigação, entretanto, algumas delas podem ser forjadas e outras tantas, não citadas, ajudariam em uma investigação.

Dessa forma, no próximo capítulo serão analisados os principais campos para a prática forense, através do entendimento de como cada campo é preenchido, comparações entre campos de e-mails autênticos e outros que sejam possíveis golpes ou spam.

2 ANÁLISE FORENSE DE UM CABEÇALHO DE E-MAIL

Um leitor atento já deve ter percebido que, no tópico anterior, foi destrinchado parte do cabeçalho de e-mail de baixo para cima, o que seria o fator principal para um início correto na análise do cabeçalho.

Fazendo uma leitura de baixo para cima, temos as linhas mais abaixo no cabeçalho como os processos mais pertos da origem da mensagem, enquanto as linhas mais acima são processos mais recentes, próximos ao destino. Valendo-se disso, toda e qualquer análise cronológica de um cabeçalho deve ter uma abordagem bottom-up (de baixo para cima).

Os seguintes tópicos irão abordar os principais campos de um cabeçalho, analisando-os do ponto de vista forense e fazendo comparações entre e-mails autênticos e possíveis e-mails falsos e/ou spam. A ordem dos tópicos foi construída de forma a ser mais fiel à abordagem bottom-up.

Entretanto, alguns campos não configuram artefatos importantes para a cronologia, podendo, então, divergir em sua localização em diferentes serviços de e-mail.

2.1 Return Path

O campo Return Path é utilizado para indicar para qual e-mail será enviada uma mensagem de “não-entrega”. No caso de um e-mail enviado não chegar ao destinatário, uma mensagem indicando tal acontecimento irá ser enviada para o endereço especificado neste campo.

Via de regra, o e-mail que consta no Return Path deve ser o mesmo do remetente, haja vista que, se João envia uma mensagem para Maria e essa mensagem não chega, seria natural entender que o próprio João gostasse de ficar sabendo de tal fato. No entanto, não é raro ver que o e-mail especificado no Return Path diverge do e-mail remetente. A imagem abaixo mostra um cabeçalho em que os campos From e Return Path coincidem.

Figura 4 – Campos From e Return Path coincidem.

Fonte: print screen do cabeçalho no Sublime Text 3.

Isso pode acontecer por alguns motivos, entre eles, em uma situação na qual o Return Path não específica exatamente o mesmo e-mail, mas ainda sim especifica um outro caminho dentro do domínio esperado.

Imagine que uma grande empresa envie milhares, ou até milhões, de mensagens de e-mails aos seus clientes, de modo que seria inviável ter todos os recibos de “não-entrega” chegando para o e-mail remetente. Portanto, empresas utilizam o Return Path para direcionar tais mensagens para outro local (ou locais), no qual poderão ser filtradas e tratadas. Na imagem abaixo é mostrado que os campos Return Path e From não coincidem exatamente, entretanto, percebe-se que no Return Path há uma referência ao domínio Google, o que, dentro do contexto deste e-mail, é totalmente plausível.

Figura 5 – Campos From e Return Path coincidem no tocante ao domínio.

Fonte: print screen do cabeçalho no Sublime Text 3.

Outra possibilidade para o campo From e Return Path não coincidirem é uma situação de spam ou tentativa de golpe. O praticante desse ato pode simplesmente alterar o campo Return Path para um e-mail totalmente aleatório.

Então, empresas que enviam mensagens inconvenientes, ou spam, podem fazer isso para não receber reclamações como resposta. A imagem abaixo mostra uma possível mensagem do banco Bradesco, entretanto, ao analisarmos o campo Return Path, é possível reconhecer que, no mínimo, há algo de errado, pois seria natural esperar encontrar, ao menos, um indício de um domínio que sugerisse o banco.

É importante destacar que o endereço especificado no campo de retorno pode ser de alguém que nem mesmo imagina que seu domínio está sendo usado para golpes.

Figura 6 – Campos From e Return Path divergem totalmente

Fonte: print screen do cabeçalho no Sublime Text 3.

Observa-se, assim, que o campo Return Path pode ser um grande aliado na hora de identificar se o e-mail recebido é de fonte confiável ou não.

2.2 Message-ID

Este campo especifica um identificar único, como uma impressão digital que, via de regra, apenas a presente mensagem terá, nunca sendo repetido, e serve para referenciar uma versão específica de uma mensagem específica.

A exclusividade do valor do campo deve ser garantida pelo host que o gera, sendo ele o servidor de e-mail ou o primeiro MTA que a mensagem atravessa. Mesmo que o e-mail seja passado por outros MTA’s e tenha outros campos do cabeçalho adicionados por esses, o identificador preserva-se o mesmo.

O identificador é uma combinação de duas partes, separados por um símbolo “@”. A primeira parte, à esquerda, deve ser um número aleatório, por exemplo, uma combinação de dados sobre data e hora do envio acrescidos de algum outro número único, como um número do ID do processo.

À segunda parte, à direita, deve constar uma informação acerca do domínio (ou o endereço IP) do host no qual a mensagem foi criada. A imagem abaixo mostra a comparação de três diferentes e-mails autênticos recebidos, sendo o primeiro uma mensagem recebida do serviço Gmail.

O segundo é uma mensagem do YouTube. Por fim, o terceiro representa uma mensagem recebida pelo LinkedIn. É possível analisar que, em todas elas, a informação depois do símbolo “@” no campo Message-ID correspondem ao domínio informado no campo From.

Figura 7 – Domínio no campo From e Message-ID são correspondentes.

Fonte: print screen do cabeçalho no Sublime Text 3.

Por outro lado, e-mails mal-intencionados podem conter a segunda parte do campo Message-ID divergindo do domínio especificado no campo From. Isso, por si só, não serve para afirmar que o e-mail é falso, entretanto, acrescido de outras informações acerca da origem, pode auxiliar na análise.

A imagem abaixo demonstra um exemplo de e-mail falso se passando por uma mensagem autêntica do Banco do Brasil, no qual a diferença entre o domínio no campo Message-ID e From chama a atenção. Podemos também perceber que o endereço no campo Return-Path é, no mínimo, estranho.

Figura 8 –  Domínio nos campos From e Message-ID são divergentes.

Fonte: print screen do cabeçalho no Sublime Text 3.

Para fins de comparação, a imagem abaixo demonstra o campo Message-ID de um e-mail autentico do Banco do Brasil. Pode-se ver que o domínio no campo Message-ID corresponde a algo mais natural e esperado se comparado à mensagem anterior.

Figura 9 –  Domínio no campo Message-ID corresponde à realidade esperada.

Fonte: print screen do cabeçalho no Sublime Text 3.

2.3 DKIM-Signature

DomainKeys Identified Mail, ou DKIM, é um mecanismo que serve de proteção contra falsos e-mails. O DKIM é usado há anos, auxiliando na verificação do domínio de e-mail do remetente através de uma Assinatura DKIM inserida na mensagem enviada.

Servidores autênticos de e-mail são configurados para anexar uma Assinatura DKIM junto à mensagem enviada. A assinatura viaja junto com a mensagem e pode ser verificada em cada “pulo” que o e-mail dá, entre MTA’s e servidores de e-mail, até chegar no destinatário. Há, na assinatura, informações necessárias para validação da autenticidade da mensagem e se ela foi modificada enquanto estava em trânsito.

Basicamente, o DKIM permite o anexo de uma “marca d’água” no e-mail, possibilitando que o destinatário verifique se aquele e-mail vem, realmente, de onde ele diz que vem. Além disso, esse campo vale até mesmo para mensagem encaminhadas, mantendo sua assinatura preservada.

A criptografia usada é através do método de chaves públicas e privadas. Naturalmente, o DKIM usa sua chave privada, que apenas aquele remetente possui, e então o destinatário utiliza a chave pública, conhecida publicamente, para verificar a mensagem. A combinação desse método, entre a chave pública e privada, é que traz a autenticidade ao caso.

A Assinatura DKIM é gerada antes do e-mail ser enviado, sendo criptografada pela chave privada, e, após isso, a mensagem é finalmente enviada. No campo DKIM-Signature há a informação acerca de qual domínio a assinatura se refere.

Através de outras variáveis dentro do campo, é possível o destinatário saber onde, exatamente, procurar a chave pública. Assim, após a chave pública ser encontrada (se for) ela será usada para descriptografar a Assinatura DKIM.

Caso a Assinatura DKIM não passe, durante a verificação, ainda sim pode se tratar de uma mensagem real, porém, que pode ter sido modificada enquanto transitava, ou então o remetente não anexou a Assinatura DKIM ao e-mail (o que seria um ponto a se analisar). Caso a verificação retorne uma mensagem positiva, a Assinatura DKIM é válida e o e-mail autêntico.

O campo DKIM-Signature contém algumas variáveis importantes que constroem a sintaxe do campo. São elas:

• v (versão): versão do padrão DKIM usado. Sempre definido em 1;
• a (algoritmo): algoritmo responsável para gerar a assinatura. Via de regra, usa-se RSA-SHA256;
• c (canonicalization): define quais mudanças, como quebra de linha, espaços em branco e afins, serão aceitos como mudanças no e-mail enquanto ele transitar;
• s (seletor): indica uma chave, definida pelo remetente, para localizar a chave pública no DNS do mesmo;
• d (domínio): indica o domínio do remetente. Usada em conjunto com a variável “s” para o destinatário encontrar a chave pública;
• h (cabeçalho): informações de cabeçalho, usados no algoritmo de assinatura que gera a assinatura (encontrado na variável “b”);
• bh: hash calculado do corpo da mensagem. Determinado pelo algoritmo (variável “a”);
• b (assinatura): Assinatura DKIM. São gerados através dos dados de hash apresentados na variável “h”.

A imagem abaixo apresenta um exemplo de campo DKIM-Signature, na qual é possível ver todas as variáveis citadas acima.

O fato de haver um campo DKIM-Signature é um fator importante na análise de um cabeçalho de e-mail, pois, geralmente, e-mails falsos e maliciosos nem mesmo apresentam tal campo.

Figura 10 –  Campo DKIM-Signature.

Fonte: print screen do cabeçalho no Sublime Text 3.

2.4 Received-SPF

O campo Received-SPF faz referência à técnica de autenticação SPF (Sender Policy Framework). O SPF determina específicos servidores/hosts autorizados a enviar e-mail a partir de um domínio. A autenticação é feita a partir de uma consulta que o servidor de e-mail destinatário faz no registro SPF, dentro do DNS, do domínio que está enviando o e-mail.

O campo From pode ser facilmente forjado, vide os vários exemplos dados até agora que enfatizam a divergência do campo From com outros dados confiáveis do cabeçalho. Isso acontece porque o campo From não faz parte do chamado “envelope” do e-mail. Com efeito, o e-mail pode ser comparado a uma carta convencional, que é colocada dentro de um envelope, e os serviços que irão transportar a carta irão adicionar dados, como nome, endereço e etc., do remetente real, no envelope, e se basearão nesses dados. Esses serviços não saberão o conteúdo da carta, apenas os dados do “envelope”.

Após aberta, a carta pode conter informações de outro remetente, como um nome e endereços falsos que a pessoa que a escreveu decidiu colocar. Os serviços de e-mail, via de regra, apresentam prontamente ao usuário apenas a “carta” e não o “envelope”, então, ao abrirmos um e-mail, a única informação que temos é exatamente aquela que o remetente quis nos dar.

Outros campos no cabeçalho fazem parte do “envelope” do cabeçalho, como o campo Return Path (que comumente é utilizado pelo SPF para a conferência junto ao registro SPF) e também um outro tipo de campo From que será abordado no tópico 2.6 (que faz parte, na verdade, dos campos “Received: from …”).

Após realizar a consulta no registro SPF, o servidor terá uma resposta indicando se o remetente é, ou não, autorizado a enviar aquela mensagem. Caso a resposta seja negativa, a mensagem será encaminhada para a caixa de spam (em alguns casos a mensagem pode até mesmo ser rejeitada e bloqueada nesse momento).

Vale ressaltar que, no caso de uma mensagem encaminhada (Fwd), o SPF não será tão útil, pois a pessoa que encaminhou a mensagem será o novo remetente, e então a consulta será baseada nela e não no remetente original da mensagem, o que provavelmente resultará em uma resposta falso-positivo.

A resposta da consulta SPF não é binária (autorizado ou não), e sim pode variar entre alguns tipos. Eles são:

• None: significa que nenhum registro SPF foi encontrado na busca;
• Neutral: significa que houve uma recusa na resposta referente à busca daquele determinado remetente dentro do registro SPF;
• Pass: significa que o remetente é autorizado a enviar e-mails daquele domínio;
• Fail: significa que o remetente não é autorizado a enviar e-mails daquele domínio;
• SoftFail: significa que o remetente pode ser autorizado ou não, e a consulta foi incapaz de resolver;
• TempError: significa que houve um erro no processo de consulta. Não sinaliza, necessariamente, que o remetente não seja autorizado;
• PermError: significa que o registro SPF não pode ser verificado, seja por erro de sintaxe, formato ou algum outro problema.

A imagem abaixo mostra respostas diferentes no campo Received-SPF em quatro cabeçalhos distintos. O primeiro é referente a um e-mail do YouTube; o segundo é referente a um e-mail falso se passando pela empresa Vivo; o terceiro é referente a um e-mail falso se passando pelo banco Bradesco (o mesmo da Figura 6); e o quarto é referente a um e-mail falso se passando pela empresa Walmart.

Figura 11 –  Respostas negativas no campo Received-SPF.

Fonte: print screen do cabeçalho no Sublime Text 3.

2.5 DMARC

. O campo DMARC, Domain-based Message Authentication Reporting and Conformance, é mais um aliado na prevenção contra e-mails maliciosos.

Ele, em si, não é um protocolo de autenticação, mas se baseia em dois dos principais fatores de autenticação, SPF e DKIM, os quais foram abordados nos tópicos anteriores.

Ele utiliza os dados obtidos pelo SPF e pelo DKIM, utilizando também o DNS, para gerar sua validação do e-mail. Os domínios estabelecem suas políticas de autenticação de e-mail, registrando isso em seu DNS, que servirá de consulta. Esse ato faz parte dos processos utilizados pelo SPF e DKIM, e O DMARC também o utiliza para gerar sua análise do e-mail.

Após um servidor de e-mail receber uma mensagem, ele irá utilizar o DNS para consultar a política DMARC empregada pelo domínio. Com tais informações, o servidor irá analisar se a Assinatura DKIM é válida (caso ela exista), se a origem da mensagem é permitida pelos registros SPF do domínio e se o cabeçalho do e-mail se mostra “alinhado” com o domínio.

Depois de tal análise, o DMARC decide se aceita, rejeita ou sinaliza a mensagem. Após isso, o servidor de e-mail que está fazendo a análise irá reportar ao proprietário do domínio qualquer informação necessária.

A imagem abaixo mostra duas diferentes respostas durante a análise DMARC. Na primeira, temos informações de que o DKIM e o SPF passaram positivamente na análise, portanto, vemos, também, que o DMARC aparece como “pass”.

Já na segunda análise, pode-se ver que nem o SPF nem o DKIM puderam comprovar autenticidade, portanto, o DMARC não pode ser confirmado. Além disso, após a informação do DKIM, podemos ver a frase “mensagem não assinada”, referenciando a Assinatura DKIM.

Figura 12 –  Comparação do campo DMARC entre e-mail autêntico e falso.

Fonte: print screen do cabeçalho no Sublime Text 3.

2.6 Received

Como já dito anteriormente, é normal haver mais de um campo Received no cabeçalho (não estamos nos referindo ao campo Received-SPF).

Esse campo auxiliará a determinar o “caminho” pelo qual a mensagem transitou, mas não trará nenhuma informação acerca da autenticidade da mensagem, pois, para isso, temos vários outros campos.

A quantidade de campos Received depende da quantidade de “pulos” entre MTA’s que a mensagem realizou, e é considerado um dos campos mais confiáveis de todo o cabeçalho, pois é adicionado por cada MTA que aceita a mensagem para retransmiti-la.

É principalmente na análise dos campos Received que a abordagem bottom-up deve ser adotada. O campo mais no topo do cabeçalho é o mais recente, ou seja, está mais perto do destinatário, enquanto o campo mais abaixo é o campo mais antigo, ou seja, está mais perto da origem da mensagem, do remetente.

Via de regra, em um campo Received, é mostrado de onde a mensagem veio e quem a recebeu. A imagem abaixo representa um cabeçalho de e-mail, originado do YouTube, no qual a mensagem passou por dois MTA’s.

Em cada um deles é possível colher informações acerca do endereço IP para fazer uma busca mais minuciosa dos endereços, e também nos são apresentadas a data e hora da retransmissão. Adiante, serão apresentadas ferramentas que podem auxiliar nessa tarefa.

Figura 13 –  Campo Received.

Fonte: print screen do cabeçalho no Sublime Text 3.

3 FERRAMENTAS

Nenhuma ferramenta substitui o conhecimento. Com efeito, em qualquer parte da forense digital, se valer de ferramentas com certeza trará ajuda na análise, entretanto, sem o conhecimento prévio de como a tecnologia analisada funciona, a ferramenta pode não ser de grande ajuda.

A análise de cabeçalho de e-mail segue esse mesmo raciocínio, uma vez que as ferramentas poderão ajudar, mas não as tenha como única forma de análise, mas sim apenas como suporte.

Tendo isso como premissa, abaixo serão apresentadas algumas ferramentas que podem auxiliar na análise.

3.1 Messageheader Analyzer

Essa não é o nome de um software específico, mas sim o tipo de software. Com uma busca na internet pelo termo “Messageheader Analyzer” é possível achar diversas opções de ferramentas web para automatizar a análise de um cabeçalho.

Via de regra, o resultado será mais limpo e claro do que o emaranhado de caracteres apresentado acima, quando a análise foi feita manualmente, porém, isso não significa que a análise pelas ferramentas é melhor, pois é importante lembrar de usá-las sempre apenas como suporte.

Um exemplo seria o G Suite Toolbox Messageheader, que simplifica a análise em alguns campos. Ao entrar no site, somos levados a simplesmente copiar e colar o cabeçalho todo em um campo de texto, e a ferramenta fará a análise e trará, resumidamente, uma resposta.

A imagem abaixo demonstra uma análise de um cabeçalho falso, passando-se pelo banco Bradesco (o mesmo usado na figura 6). Pode-se notar que a ferramenta traz, prontamente, as respostas para a análise SPF, DKIM e DMARC, o que já pode ser usado para determinar que o e-mail não é digno de confiança.

Figura 14 –  Análise de cabeçalho de e-mail com G Suite Toolbox Messageheader.

Fonte: print screen da ferramenta G Suite Toolbox Messageheader.

A ferramenta também traz uma relação dos “pulos” feitos no trânsito da mensagem, entre os MTA’s, baseados nos campos Received do cabeçalho. A imagem abaixo mostra a análise do trânsito da mensagem, ainda na ferramenta G Suite Toolbox Messageheader.

Figura 15 –  Análise do caminho percorrido pela mensagem com G Suite Toolbox Messageheader.

Fonte: print screen da ferramenta G Suite Toolbox Messageheader.

Como dito anteriormente, a internet está recheada de ferramentas como essas, com diferentes layouts, mudanças no modo de apresentar os dados, e etc., de modo que fica a critério do investigador usar aquela que melhor lhe aprouver.

3.2 Cisco Talos

É possível usar o serviço Talos, da Cisco, para verificar reputação de endereços IP’s no tocante a e-mails (a ferramenta também traz outras análises). Através do site “https://talosintelligence.com/” é possível colocar o endereço IP e realizar a pesquisa, e a imagem abaixo mostra como a resposta é apresentada.

Então, vale ressaltar que em nenhum dos e-mails falsos apresentados nos tópicos anteriores se obteve resposta negativa quanto à reputação, apenas uma resposta neutra (neutral).

Portanto, vale mais uma vez ressaltar que o investigador não deve se apoiar totalmente nas ferramentas, e sim na sua análise do cabeçalho manual.

Figura 16 –  Análise da reputação de um IP do Google no Cisco Talos

Fonte: print screen da ferramenta G Suite Toolbox Messageheader.

3.3 Whois

Uma ferramenta demasiadamente conhecida, o Whois é uma ferramenta de consulta de informações sobre entidades na internet. Através do link “https://whois.domaintools.com/” é possível pesquisar por um domínio, ou endereço IP, e obter respostas acerca dele.

Logo, essa ferramenta pode ser utilizada para realizar pesquisar sobre os endereços IP’s apresentados nos campos Received do cabeçalho e, portanto, traçar a rota que a mensagem percorreu.

A imagem abaixo mostra um exemplo de pesquisa, realizado com o endereço IP apresentado no primeiro campo Received de um cabeçalho de e-mail, supostamente enviado pela empresa VIVO.

Naturalmente, com a análise sobre outros campos, principalmente o SPF, DKIM e DMARC, é possível afirmar que tal e-mail seja falso.

Entretanto, ao analisar informações acerca do primeiro IP de origem constando no cabeçalho, temos mais uma informação que causa estranheza, pois um endereço IP originado na Irlanda não é exatamente o que se espera de uma empresa brasileira. Todavia, com tal informação não é possível predizer que se trata de um e-mail falso, de modo que a análise de todo o restante do cabeçalho tratará disso.

Figura 17 –  Informações acerca de um IP na ferramenta Whois.

Fonte: print screen da ferramenta Whois.

CONCLUSÃO

Ataques por e-mail configuram uma grande parcela dos riscos que acometem as empresas atualmente. O grande número de e-mails corporativos, enviando, recebendo, encaminhando mensagens e tratando de informações sensíveis pode agravar ainda mais o quadro.

Então, isso, somado à falta de preparo profissional acerca de segurança da informação, culmina em uma situação que beira o caos, mesmo que silencioso, dentro da empresa. O risco existe, está a todo momento rondando a empresa e poucas vezes há preocupação sobre ele.

Toda essa mazela atrai, ainda mais, cyber criminosos para esse tipo de ataque. Portanto, ser capaz de realizar uma análise completa em cabeçalhos de e-mail sempre auxiliará no comportamento a ser tomado sobre determinadas mensagens.

A análise de cabeçalho de e-mail, à primeira vista, pode parecer complexa, principalmente pelo cabeçalho nos ser apresentado de uma forma nada palatável.

Entretanto, ao ter entendimento de onde, e o que procurar, a análise será grandemente facilitada. Além disso, usar ferramentas como o Sublime Text 3 (configurado com o pacote Email Header), conforme foi utilizado ao longo do trabalho, deixará tudo ainda mais fácil para a leitura, enquanto mantém a análise manual e interpretativa, sem a necessidade de utilizar outras ferramentas.

Ademais, vale ressaltar que se valer de outras ferramentas, como as mencionadas no tópico 3, sempre ajudará, mas, como dito anteriormente, não é recomendável usá-las como único recurso, e, além disso, é importante procurar usar mais de uma. Com efeito, quem tem apenas uma ferramenta, acaba não tendo nenhuma.

BIBLIOGRAFIA

HUMMERT, Austin. Reviewing X Sender Headers: How to Prevent Email Spoofing From Fake Senders. AT&T, 20 fev. 2020. Disponível em: <https://cybersecurity.att.com/blogs/security-essentials/how-hackers-manipulate-email-to-defraud-you-and-your-customers>. Acesso em: 16 ago. 2020.

MAILXAMINER. Is Message-ID Helpful for Forensic Email Analysis? MailXaminer, 22 abr. 2020. Disponível em: <https://www.mailxaminer.com/blog/message-id-forensic/>. Acesso em: 14 ago. 2020.

MIMECAST. DKIM signature. Mimecast. Disponível em: <https://www.dmarcanalyzer.com/dkim/dkim-signature/>. Acesso em: 12 ago. 2020.

MIMECAST. Everything you need to know about SPF. Mimecast. Disponível em: <https://www.dmarcanalyzer.com/spf/>. Acesso em: 15 ago. 2020.

POLLARD, John. DKIM signature header detail. Validity. Disponível em: <https://help.returnpath.com/hc/en-us/articles/222438487-DKIM-signature-header-detail>. Acesso em: 12 ago. 2020.

POLLARD, John. How to interpret SPF authentication verification results. Validity. Disponível em: <https://help.returnpath.com/hc/en-us/articles/115000460632-How-to-interpret-SPF-authentication-verification-results>. Acesso em: 15 ago. 2020.

SPARKPOST. Understanding the Return-Path. SparkPost. Disponível em: <https://www.sparkpost.com/resources/email-explained/return-path-explained/>. Acesso em: 11 ago. 2020.

SPARKPOST. What Is DMARC? Domain-Based Message Authentication, Reporting and Conformance. SparkPost. Disponível em: <https://www.sparkpost.com/resources/email-explained/dmarc-explained/>. Acesso em: 15 ago. 2020.

TEAM ALYN. Email Headers: What can they tell the forensic investigator? Alyn, 10 nov. 2018. Disponível em: <https://www.alyninc.com/2018/11/10/email-headers-what-can-they-tell-the-forensic-investigator/>. Acesso em: 12 ago. 2020.