Análise forense de cabeçalho de e-mail

Os cabeçalhos de e-mail contêm informações importantes sobre a origem e o caminho percorrido por um e-mail antes de chegar ao seu destino final, incluindo o endereço IP do remetente, o provedor de serviços de Internet, o cliente de e-mail e até o local. As informações podem ser usadas para bloquear futuros e-mails do remetente (no caso de spam) ou para determinar a legitimidade de um e-mail suspeito. Uma revisão dos cabeçalhos também pode ajudar a identificar a “falsificação de cabeçalho”, uma forte indicação de que o e-mail foi enviado com intenção maliciosa.

A análise forense do cabeçalho do e-mail basicamente indica o exame realizado no corpo da mensagem de e-mail e a origem e o caminho seguidos por ele. Isso também inclui a identificação de remetente, horário ou destinatário genuíno dos e-mails. A análise forense do cabeçalho do e-mail pode trazer evidências francas de vários componentes incluídos na parte do cabeçalho. Vamos ver quais componentes são úteis para forense de cabeçalho;

Como é composto o e-mail?

Os e-mails são basicamente compostos pela junção de dois padrões, a RFC822/RFC2822 e MIME, sendo a RFC2822 o padrão para o formato de mensagens de texto na Internet ARPA, que especifica um conjunto padrão de cabeçalhos de mensagens que são seguidos pelo conteúdo da mensagem. O problema com o RFC2822 é que ele permite o conteúdo da mensagem que consiste apenas em texto ASCII. As “Multipurpose Internet Mail Extensions” ou MIME superam essa limitação e permitem que as mensagens contenham conjuntos de caracteres diferentes de ASCII, dados não textuais (anexos), mensagens com várias partes etc.

Neste artigo iremos considerar as duas RFCs, tanto a RFC822 quanto a RFC2822, visto que muitos autores ainda mantém a referência à RFC822 e não à mais atual que é a RFC2822, a qual atualiza a RFC anterior. Sendo assim, toda vez que falarmos de RFC neste contexto, estaremos abordando o mesmo assunto.

Compreendendo os campos do cabeçalho

Para a correta interpretação dos cabeçalhos de e-mails, o analista deverá ler a sua estrutura cronologicamente de baixo para cima. Estruturalmente, os cabeçalhos de e-mail podem ser divididos em três categorias principais:

  1. Informações da mensagem
  2. Cabeçalhos X e
  3. Informações de retransmissão do servidor.

Existe uma ferramenta excelente para analisar cabeçalhos disponíveis on-line em http://mxtoolbox.com/E-mailHeaders.aspx, como obter cabeçalhos de e-mails dos clientes mais comuns https://mxtoolbox.com/Public/Content/EmailHeaders/.

 

Junte-se à vanguarda da justiça

Não deixe que o mundo digital seja um campo aberto para criminosos.

Junte-se à vanguarda da justiça na era da informação com nosso curso de Computação Forense e Investigação Digital. Aprenda as habilidades necessárias para rastrear, analisar e apresentar evidências digitais que podem resolver casos e salvar vidas. Clique aqui para se inscrever agora e seja o herói cibernético que o mundo precisa!

RFC822 e RFC2822- Padrão para o formato de mensagens de texto da Internet ARPA

O padrão RFC2822 substitui o especificado na RFC 822 , “Padrão para o formato do texto da Internet ARPA Mensagens”[RFC822], atualizando-o para refletir as práticas atuais e incorporando alterações incrementais que foram especificadas em outras RFCs [ DST3 ].

Uma mensagem consiste em campos de cabeçalho e, opcionalmente, um corpo. O corpo é basicamente uma sequência de linhas contendo caracteres ASCII, sendo separado dos cabeçalhos por uma linha nula. Cada campo de cabeçalho pode ser visualizado como uma única linha lógica de caracteres ASCII, compreendendo um nome de campo seguido de dois pontos (“:”), seguido de um corpo de campo. Dependendo do nome do campo, o corpo do campo pode ser Estruturado ou Não Estruturado.

  • Estruturado – Para campos de endereço, como “To“, uma estrutura é predefinida. O corpo do campo deve estar em conformidade com a especificação.
  • Não estruturado – Para alguns campos, como “Subject” e “Comments“, nenhuma estrutura é assumida e eles são tratados simplesmente como texto.

Nem todos os campos de cabeçalho recebidos pelo destinatário podem ter sido especificados pelo remetente. Há uma distinção entre os cabeçalhos “mensagem” e “envelope“. Resumidamente, os cabeçalhos do “envelope” são realmente gerados pela máquina que recebe uma mensagem, e não pelo remetente. Os cabeçalhos do envelope são adicionados no início dos dados do correio. Os servidores de retransmissão SMTP que manipulam a mensagem no caminho para o destinatário final inserem alguns campos de cabeçalho no cabeçalho da mensagem. Por exemplo:

  • Quando o receptor-SMTP aceita uma mensagem para retransmissão ou entrega final, ele insere no início dos dados do correio uma linha de carimbo de data/hora (Received: cabeçalho). A linha do carimbo de data/hora indica a identidade do host que enviou a mensagem e a identidade do host que recebeu a mensagem (e está inserindo esse carimbo de hora) e a data e hora em que a mensagem foi recebida. As mensagens retransmitidas terão várias linhas de carimbo de data/hora. Quando o receptor-SMTP faz a “entrega final” de uma mensagem, ele insere no início dos dados do correio uma linha de caminho de retorno.
  • Alguns sistemas permitem que os destinatários de e-mail encaminhem uma mensagem. Este padrão suporta esse serviço, através do prefixo “Resent-” para nomes de campos. Sempre que a string ” Resent-” inicia um nome de campo, o campo tem a mesma semântica que um campo cujo nome não tem o prefixo. No entanto, supõe-se que a mensagem tenha sido encaminhada por um destinatário original que anexou o campo “Reenviar-“. Este novo campo é tratado como sendo mais recente que o campo equivalente, campo original.

Além do campo de cabeçalho predefinido, os usuários podem definir e usar seus próprios campos de cabeçalho. Esses campos podem ser usados ​​para transferir informações específicas do aplicativo. Esses campos devem ter nomes que ainda não estão sendo usados ​​na especificação atual. Os nomes dos campos definidos pelo usuário geralmente começam com “X-” porque é garantido que os campos predefinidos nunca terão nomes começando com essa sequência.

Alguns dos campos de cabeçalho especificados pelo padrão RFC822 estão listados abaixo:

  • Apparently-To: as mensagens com muitos destinatários às vezes têm uma longa lista de cabeçalhos no formato “Aparentemente para: [email protected]” (uma linha por destinatário). Esses cabeçalhos são incomuns no correio legítimo; eles normalmente são um sinal de uma lista de discussão e, nos últimos tempos, as listas de discussão geralmente usam software sofisticado o suficiente para não gerar uma pilha gigante de cabeçalhos.
  • Cco ou Bcc: (significa “Cópia oculta em carbono”) Se você vir esse cabeçalho nas mensagens recebidas, algo está errado. É usado como Cc: (veja abaixo), mas não aparece nos cabeçalhos. A ideia é poder enviar cópias de e-mail a pessoas que podem não querer receber respostas ou aparecer nos cabeçalhos. As cópias ocultas em carbono são populares entre os spammers, pois confunde muitos usuários inexperientes receberem e-mails que não parecem endereçados a eles.
  • Cc: (significa “Cópia em Carbono”, que é significativa se você se lembrar de máquinas de escrever) Este cabeçalho é uma extensão de “Para:”; especifica destinatários adicionais. A diferença entre “Para:” e “Cc:” é essencialmente conotativa; alguns usuários de mala direta também lidam com eles de maneira diferente na geração de respostas.
  • Comments: este é um campo de cabeçalho de formato livre não padrão. É mais comumente visto no formulário “Comentários: o remetente autenticado é <[email protected]>”. Um cabeçalho como este é adicionado por alguns usuários do correio (principalmente o popular programa freeware Pegasus) para identificar o remetente; no entanto, muitas vezes é adicionado manualmente (com informações falsas) por spammers. Trate com cuidado.
  • Content-Transfer-Encoding: esse cabeçalho refere-se ao MIME, uma maneira padrão de incluir conteúdo não textual em e-mail. Não tem relevância direta para a entrega de e-mail, mas afeta a maneira como os programas de e-mail compatíveis com MIME interpretam o conteúdo da mensagem.
  • Content-Type: outro cabeçalho MIME, informando aos programas de e-mail compatíveis com MIME qual o tipo de conteúdo esperado na mensagem.
  • Date: esse cabeçalho faz exatamente o que você esperaria: especifica uma data, normalmente a data em que a mensagem foi composta e enviada. Se esse cabeçalho for omitido pelo computador do remetente, é possível que ele seja adicionado por um servidor de correio ou mesmo por outra máquina ao longo do caminho. Não deve ser tratado como verdade do evangelho; falsificações à parte, há muitos computadores no mundo com seus relógios errados.
  • Errors-To: especifica um endereço para erros gerados pela mala direta, como mensagens de devolução de “nenhum usuário assim”, para acessar (em vez do endereço do remetente). Esse não é um cabeçalho particularmente comum, pois o remetente geralmente deseja receber erros no endereço de envio, que é o que a maioria (essencialmente todos) dos softwares de servidor de e-mail faz por padrão.
  • From (sem dois pontos) Este é o cabeçalho “envelope De” discutido acima. Este cabeçalho é derivado das informações no comando SMTP “MAIL FROM”. Este cabeçalho é adicionado pelo destinatário final da mensagem.
  • From: (com dois pontos) Esse é o cabeçalho “message From:”. Este cabeçalho é especificado pelo remetente no comando “DATA” do SMTP. O remetente pode especificar qualquer valor nesse cabeçalho para que não seja confiável.
  • Message-Id: (também Message-id: ou Message-ID:) O Message-Id é um identificador exclusivo mais ou menos atribuído a cada mensagem, geralmente pelo primeiro servidor de e-mail que encontra. Convencionalmente, é do formato “[email protected]”, onde a parte “sem sentido” pode ser absolutamente qualquer coisa e a segunda parte é o nome da máquina que atribuiu o ID. Às vezes, mas não frequentemente, o “jargão” inclui o nome de usuário do remetente. Qualquer e-mail no qual o ID da mensagem esteja malformado (por exemplo, uma sequência vazia ou sem sinal @) ou no qual o site no ID da mensagem não seja o site de origem real, provavelmente é uma falsificação.
  • In-Reply-To: Um cabeçalho Usenet que aparece ocasionalmente no correio, o cabeçalho In-Reply-To: fornece o ID da mensagem de alguma mensagem anterior que está sendo respondida. É incomum que esse cabeçalho apareça, exceto no e-mail diretamente relacionado à Usenet; Sabe-se que os remetentes de spam o utilizam, provavelmente na tentativa de evitar programas de filtragem.
  • Mime-Version: (também MIME-Version:) Ainda outro cabeçalho MIME, este apenas especificando a versão do protocolo MIME que foi usado pelo remetente. Como os outros cabeçalhos do MIME, esse geralmente é eminentemente ignorável; os programas de correio mais modernos farão a coisa certa com isso.
  • Newsgroups: esse cabeçalho aparece apenas no e-mail conectado à Usenet – cópias de e-mails das postagens da Usenet ou respostas por e-mail às postagens. No primeiro caso, especifica o (s) grupo (s) de notícias em que a mensagem foi postada; no segundo, especifica o (s) grupo (s) de notícias em que a mensagem que está sendo respondida foi postada. A semântica desse cabeçalho é objeto de uma guerra santa de baixa intensidade, que efetivamente assegura que os dois conjuntos de semânticas sejam usados ​​indiscriminadamente no futuro próximo.
  • Organization: um cabeçalho totalmente livre que normalmente contém o nome da organização através da qual o remetente da mensagem tem acesso à rede. O remetente geralmente pode controlar esse cabeçalho, e entradas tolas como “Sociedade Real por Colocar Coisas em Cima de Outras Coisas” são comuns.
  • Priority: um cabeçalho essencialmente de formato livre que atribui uma prioridade ao e-mail. A maioria dos softwares ignora isso. É frequentemente usado por remetentes de spam, geralmente na forma “Priority: urgent” (ou algo semelhante), na tentativa de obter suas mensagens lidas.
  • Received: Este cabeçalho é inserido pelo SMTP do receptor quando ele aceita uma mensagem para retransmissão ou entrega final. Este cabeçalho indica a identidade do host que enviou a mensagem e a identidade do host que recebeu a mensagem (e está inserindo esse cabeçalho) e a data e hora em que a mensagem foi recebida. As mensagens retransmitidas terão vários cabeçalhos.
  • References: O cabeçalho Referências: é raro no e-mail, exceto nas cópias das postagens da Usenet. Seu uso na Usenet é identificar as postagens “upstream” às quais uma mensagem é uma resposta; quando aparece no e-mail, geralmente é apenas uma cópia do cabeçalho da Usenet. Também pode aparecer nas respostas por e-mail às postagens da Usenet, fornecendo o ID da mensagem que está sendo respondida, bem como as referências dessa postagem.
  • Reply-To: especifica um endereço para respostas. Embora esse cabeçalho tenha muitos usos legítimos (talvez o seu software manipule o seu endereço De: e você queira que as respostas cheguem a um endereço correto), ele também é amplamente usado pelos remetentes de spam para evitar críticas. Ocasionalmente, um spammer ingênuo solicita respostas por e-mail e usa o cabeçalho Reply-To: para coletá-las, mas com mais frequência o endereço Reply-To: no lixo eletrônico é inválido ou é uma vítima inocente.
  • Sender: esse cabeçalho é incomum no e-mail (o X-Sender: geralmente é usado), mas aparece ocasionalmente, especialmente em cópias de postagens da Usenet. Deve identificar o remetente; no caso de postagens da Usenet, é um identificador mais confiável que a linha From:.
  • Subject: Um campo de formato completamente livre especificado pelo remetente, destinado, é claro, a descrever o assunto da mensagem.
  • To: O cabeçalho “message To:”. Isso é inserido pelo remetente nos dados do correio. Observe que o cabeçalho Para: não precisa conter o endereço do destinatário!
  • X-headers é o termo genérico para cabeçalhos que começam com um X maiúsculo e um hífen. A convenção é que os cabeçalhos X não são padrão e são fornecidos apenas para informação e que, inversamente, qualquer cabeçalho informativo não padrão deve receber um nome começando com “X-“. Esta convenção é frequentemente violada.
  • X-Confirm-Reading-To: Este cabeçalho solicita um aviso de confirmação automática quando a mensagem é recebida ou lida. Geralmente é ignorado; presumivelmente, algum software atua sobre ele.
  • X-Distribution: em resposta a problemas com spammers usando seu software, o autor do Pegasus Mail adicionou este cabeçalho. Qualquer mensagem enviada com o Pegasus para um número suficientemente grande de destinatários tem um cabeçalho adicionado que diz “X-Distribution: bulk”. É explicitamente planejado como algo para os destinatários filtrarem.
  • X-Erros-To: esse cabeçalho especifica um endereço para o qual os erros devem ser enviados. Provavelmente é menos amplamente obedecido.
  • X-Mailer: (também X-mailer:) Um campo de cabeçalho de forma livre destinado ao software de correio usado pelo remetente para se identificar (como publicidade ou o que for). Como muitos e-mails indesejados são enviados com malas diretas inventadas para esse fim, esse campo pode fornecer muito alimento para os filtros.
  • X-Priority: Outro campo prioritário, usado principalmente pelo Eudora para atribuir uma prioridade (que aparece como uma notação gráfica na mensagem).
  • X-Sender: o e-mail usual análogo ao cabeçalho Sender: nas notícias da Usenet, esse cabeçalho supostamente identifica o remetente com maior confiabilidade do que o cabeçalho From:. De fato, é quase tão fácil de forjar e, portanto, deve ser visto com o mesmo tipo de suspeita que o cabeçalho From:.
  • X-UIDL: Este é um identificador exclusivo usado pelo protocolo POP para recuperar e-mails de um servidor. É normalmente adicionado entre o servidor de e-mail do destinatário e o software de e-mail real do destinatário; se o correio chegar ao servidor de correio com um cabeçalho X-UIDL:, provavelmente será um lixo eletrônico (não há uso concebível para esse cabeçalho, mas, por algum motivo desconhecido, muitos remetentes de spam adicionam um).

MIME – Extensões Multi função para Mensagens de Internet

O MIME estende o formato de correio da Internet, conforme especificado pela RFC822 e RFC2822, para permitir mensagens de texto não-US-ASCII, não-textuais, corpos de mensagens com várias partes e informações não-US-ASCII nos cabeçalhos das mensagens. Especificamente, as mensagens com o padrão MIME podem conter texto, imagens, áudio, vídeo ou outros dados específicos do aplicativo.

Para permitir que os leitores de e-mail reconheçam as mensagens que usam MIME, foram definidos alguns novos campos de cabeçalho específicos para MIME. Isso permite que os aplicativos de e-mail façam a distinção entre mensagens MIME e não MIME, para que cada um possa ser processado adequadamente.

MIME define os seguintes novos campos de cabeçalho:

  1. O campo de cabeçalho MIME-Version, que usa um número de versão para declarar que uma mensagem está em conformidade com o padrão MIME.
  2. O campo de cabeçalho Content-Type, que pode ser usado para especificar o tipo e subtipo de dados no corpo de uma mensagem e para especificar completamente a codificação desses dados. O Tipo de Conteúdo também pode ter um subtipo associado.
    1. O valor Content-Type Text, que pode ser usado para representar informações textuais em vários conjuntos de caracteres e idiomas de descrição de texto formatado de maneira padronizada.
    2. O valor Content-Type Multipart, que pode ser usado para combinar várias partes do corpo, possivelmente de tipos diferentes de dados, em uma única mensagem.
    3. O valor Content-Type Application, que pode ser usado para transmitir dados de aplicativos ou dados binários.
    4. O valor Content-Type Message, para encapsular uma mensagem de e-mail.
    5. O valor Content-Type Image, para transmitir dados de imagens estáticas (imagem).
    6. O valor Content-Type Audio, para transmissão de dados de áudio ou voz.
    7. O valor Content-Type Video, para transmissão de dados de vídeo ou imagem em movimento, possivelmente com áudio como parte do formato de dados de vídeo composto.
  3. O campo de cabeçalho Content-Transfer-Encoding, que especifica como os dados são codificados para permitir a passagem de transportes de e-mail com limitações de dados ou de conjunto de caracteres. Como o SMTP foi projetado para transportar mensagens de texto US-ASCII, dados binários como áudio, vídeo, imagens etc. devem ser adequadamente codificados antes de serem transferidos. Os valores possíveis para o campo Content-Transfer-Encoding são:
    • BASE64
    • QUOTED-PRINTABLE
    • 8BIT
    • 7BIT
    • BINARY
    • x-EncodingName (codificação não padrão)
  4. Dois campos de cabeçalho que podem ser usados ​​para identificar e descrever mais os dados em um corpo da mensagem: os campos de cabeçalho Content-ID e Content-Description.

O padrão MIME permite que as mensagens contenham vários objetos e quando estão em uma mensagem MIME, eles são representados em um formulário chamado parte do corpo. Uma parte do corpo tem um cabeçalho e um corpo, por isso faz sentido falar sobre o corpo de uma parte do corpo. Além disso, partes do corpo podem ser aninhadas em corpos que contêm uma ou várias partes do corpo. O valor Tipo de conteúdo Multipart é usado para encapsular várias partes do corpo em um único corpo.

 

Junte-se à vanguarda da justiça

Não deixe que o mundo digital seja um campo aberto para criminosos.

Junte-se à vanguarda da justiça na era da informação com nosso curso de Computação Forense e Investigação Digital. Aprenda as habilidades necessárias para rastrear, analisar e apresentar evidências digitais que podem resolver casos e salvar vidas. Clique aqui para se inscrever agora e seja o herói cibernético que o mundo precisa!

Analisando cabeçalhos

Analisando as informações de retransmissão do servidor em ordem cronológica de baixo para cima, é possível obter uma imagem de onde a mensagem foi transmitida. Cada servidor de e-mail de recebimento adiciona o nome e o endereço IP do servidor que entregou a mensagem. O nome do servidor pode revelar o domínio da retransmissão do remetente e uma pesquisa Who-Is do IP pode fornecer uma localização geográfica. No caso de mensagens enviadas via Gmail e outros grandes provedores de serviços de e-mail, isso pode levar você de volta à localização dos servidores de e-mail ou mesmo à sede corporativa do provedor. Se você tiver sorte, os cabeçalhos incluirão um X-Originating-IP que poderá revelar o provedor de serviços de Internet do remetente e diminuir a localização do remetente.

Abaixo temos um exemplo completo de cabeçalho de e-mail.

Informações da mensagem:   Inclui campos de cabeçalho de e-mail geralmente reconhecidos, como To:, From:, Subject:, Date:, além de campos úteis como Message-ID:, Return-Path:, Reply-To: entre outros, sendo esses, os primeiros campos adicionados. Esses campos são facilmente falsificados porque são especificados pelo cliente de e-mail do remetente.

Figura 1: Cabeçalhos – Informações da mensagem

Cabeçalhos X:   esses campos são adicionados ao e-mail por dispositivos de segurança, como scanners antivírus de e-mail, que atravessam a Internet e as redes internas. Os cabeçalhos X podem não estar em ordem e geralmente são misturados nos cabeçalhos Informações da mensagem e Retransmissão do servidor. Nem todos os X-Headers estarão presentes em todos os casos.

Figura 2: Cabeçalhos – Cabeçalhos X

Informações de retransmissão do servidor:   Sempre que uma retransmissão do servidor recebe uma mensagem SMTP, ela adiciona uma nova linha Received: no início do bloco de cabeçalho. Um e-mail típico recebido por um usuário em uma rede corporativa mostrará muitas retransmissões de servidores antes e depois de serem entregues aos servidores de e-mail corporativos. Estes estarão em ordem cronológica, começando de baixo para cima.

Observando atentamente conforme marcado em vermelho, o primeiro Received: contém o hostname da máquina/PC que foi utilizada para o envio do e-mail, e mais à direita ainda na mesma linha, podemos notar o modelo TCP utilizado e a porta correspondente “IPv4:25”.

Figura 3: Cabeçalhos: retransmissão do servidor

Se você estiver analisando os cabeçalhos de e-mail de spam de uma perspectiva de segurança de rede, é importante identificar o endereço IP/domínio que entregou o e-mail ao seu servidor de e-mail da linha de frente, o dispositivo de segurança na frente do seu servidor de e-mail. Isso é chamado de “IP de origem” (não é o mesmo que X-Originating-IP). É o primeiro campo adicionado aos cabeçalhos que pode ser 100% confiável porque foi adicionado pelo seu próprio dispositivo/servidor de segurança. O cabeçalho de retransmissão do servidor exibirá “Received: from some.external.domain ([some.IP]) by your.company.device ([your.IP])”.

Potencialmente, tudo o que havia antes dessa entrada poderia ser falsificado, mas, como o servidor está relatando que recebeu um e-mail de some.external.domain ([some.IP]) e foi o que os adicionou aos cabeçalhos, você pode confiar nele.

Depois de saber qual IP externo entregou a mensagem, há um serviço gratuito de reputação fornecido pela Cisco em https://www.senderbase.org/, o serviço atribui aos endereços IP e domínios uma classificação de reputação (IPs e domínios conhecidos de spammer receberam reputações fracas ou “Poor“). Os IPs de origem podem ser bloqueados nos firewalls externos, caso a caso, por reputação ou ambos. A Figura 4 mostra um e-mail recebido por msg2.companyserver.com e o IP/domínio de origem é destacado. A Figura 5 mostra a classificação fraca ou “Poor” do IP recebido do SenderBase.org.

Figura 4: Cabeçalhos – IP de origem

Figura 5: SenderBase.org – Classificação da reputação

É importante procurar evidências de falsificação ou alteração dos dados do cabeçalho nos cabeçalhos de informações da mensagem. O remetente de spam pode alterar facilmente esses cabeçalhos no cliente de e-mail ou usando software especializado. O campo mais comum para falsificação é o campo From:.

Não é incomum que os spammers usem o nome e o endereço de e-mail do próprio destinatário no campo From: para aumentar as chances de o destinatário abrir o e-mail (“Por que enviei esse e-mail para mim mesmo?”). O remetente de spam usará qualquer truque que ele ou ela possa pensar para enganar o destinatário. Lembre-se de que o Return-Path: e o Reply-To: também podem ser falsificados, dependendo se o remetente de spam deseja receber as mensagens de resposta ou não. Às vezes, o campo To: também será alterado para ocultar o endereço do destinatário pretendido.

O Message-ID é outro bom lugar para identificar a falsificação. O ID da mensagem é um identificador exclusivo de mensagens digitais e é difícil de alterar, pois é adicionado pelo servidor de e-mail que processa o e-mail. Como precisa ser exclusivo, é comum que os sistemas de mensagens usem um carimbo de data/hora seguido pelo nome de domínio do remetente (exemplo: [email protected]). Se o domínio do remetente no campo From: não corresponder ao Message-ID, você poderá estar lidando com uma mensagem falsificada.

A maioria dos e-mails de spam é gerada por servidores capazes de produzir milhões de mensagens por dia. Às vezes, esses servidores estão executando programas que preenchem o campo “X-Mailer” com o nome do cliente de e-mail usado. Os e-mails legítimos geralmente incluem um cliente de e-mail conhecido (por exemplo, Microsoft Outlook 16.0, Outlook Express, iPad Mail), mas os clientes de spammer podem ser algo menos comum (veja a Figura 6) ou até obscurecidos por caracteres aleatórios e sem sentido.

Figura 6: Cabeçalhos – cliente de e-mail

Referências:

https://tools.ietf.org/html/rfc822

https://tools.ietf.org/html/rfc2822

https://www.xploreforensics.com/blog/e-mail-header-forensic-analysis.html

https://www.alyninc.com/2018/11/10/e-mail-headers-what-can-they-tell-the-forensic-investigator/

http://clweb.csa.iisc.ac.in/gaurav/np/rfcs/mailmime.html

Petter Anderson Lopes

Petter Anderson Lopes

Perito Judicial em Forense Digital, Criminal Profiling & Behavioral Analysis, Análise da Conduta Humana

Especialista em Criminal Profiling, Geographic Profiling, Investigative Analysis, Indirect Personality Profiling

CEO da PERITUM – Consultoria e Treinamento LTDA.

Criminal Profiler e Perito em Forense Digital | Criminal Profiling & Behavioral Analysis | Entrevista Investigativa | OSINT, HUMINT | Neurociências e Comportamento | Autor, Professor

Certified Criminal Profiling pela Heritage University(EUA) e Behavior & Law(Espanha), coordenado por Mark Safarik M.S., V.S.M. Supervisory Special Agent, F.B.I. (Ret.) e especialistas da Sección de Análisis del Comportamiento Delictivo (SACD - formada por expertos en Psicología y Criminología) da Guarda Civil da Espanha, chancelado pela CPBA (Criminal Profiling & Behavioral Analysis International Group).

Certificado em Forensic Psychology (Entrevista Cognitiva) pela The Open University.

Certificado pela ACE AccessData Certified Examiner e Rochester Institute of Technology em Computer Forensics. Segurança da Informação, Software Developer