In a previous post, I introduced the various techniques available to investigators to bring perpetrators of email crimes to justice. It is clear that it is not viable for investigators to perform most of the analyses on a day-to-day basis (with no real evidence in hand) due to their time and resource complexity and also the risk of not being able to gather evidence of real value. Due to this, in this post, I emphasise on email header (tracing) analysis in an effort to allow investigators to get to evidence of value in a timely manner.
E-mail analysis begins from the mailbox of the recipient which contains the e-mail message. The message is analysed to determine the source (originator and author). The analysis involves investigation of both control information (envelope and header) and message body.
E-mail message comprises of envelope that contains transit-handling information used by the Message Handling Service (MHS) and message content which consists of two parts namely Body and Header. The Body is text but can also include multimedia elements in Hyper Text Markup Language (HTML) and attachments encoded in Multi-Purpose Internet Mail Extensions (MIME). The Header is a structured set of fields that include ‘From’, ‘To’, ‘Subject’, ‘Date’, ‘CC’, ‘BCC’, ‘Return-To’, and do on. Headers are included in the message by the sender or by a component of the email system and also contain transit-handling trace information.
Email Cybercrime Techniques
Cybercriminals misuse SMTP to hoodwink recipients about their true identities by not only spoofing one or more headers in the envelope or header of the message but also by including misleading information in these headers. A tech-savvy spammer or phisher may also evade packet filters and spoof the source IP address of their packets to indicate that the message is from a trusted domain.
Senders can lie about their true identities in various ways by using or misusing different techniques that include:
- Spoofing - This is an attempt to conceal the source of an e-mail message by placing false information in its headers. E-mail spoofing may be combined with IP spoofing to make its detection very difficult.
- Unauthorized Networks - Wired or wireless networks that have been compromised by perpetrators to gain unauthorized access to the Internet can be used to disguise their identities while sending an e-mail.
- Open Mail Relays - An open mail relay is a mis-configured mail relay that accepts mail form any computer and forwards it to another computer which otherwise should have accepted mail for and from specific computers. Such a relay becomes vulnerable to spammers and phishers who hide their identities behind these relays.
- Anonymizers or Remailers - Re-mailers are websites that operate under the guise of protecting privacy of Internet users offering anonymous Internet surfing. They intentionally strip headers from e-mail and some even do not maintain server logs.
- Open Proxy - A proxy server is a machine that allows computers to connect through it to some other computer on the Internet. HTTP proxy server provided by ISPs, Corporate Proxy Server, transparent proxy server, and Open proxy server also called anonymous proxy server are different types of proxy servers which provide different levels of anonymity. Users connecting to Internet through these proxy servers share IP address. An Open proxy server does not maintain a strict log of user activities unlike others which maintain user logs synchronized with reliable time servers. Such open proxy servers provide anonymity and untraceable Internet activity.
- SSH Tunnel or Port Redirector - A Tunnel in Internet means a secure data path through an un-trusted network. Depending upon the software and techniques used, tunnelling can be accomplished through many ways. SSH also has a feature called SSH Port Forwarding, sometimes called SSH Tunnelling, which allows establishing a secure SSH session and then tunnelling arbitrary TCP connections through it. SSH Tunnel is an encrypted tunnel created using the SSH protocol connection. SSH Tunnels can be used by e-mail senders to hide their identities.
- A botnet is a logical collection of internet-connected devices, such as computers, smartphones or Internet of Things (IoT) devices whose security have been breached and control ceded to a third party. Each compromised device, known as a "bot," is created when a device is penetrated by software from a malware distribution. Botnets can be used to perform Distributed Denial of Service (DDoS) attacks, steal data, send spam, and allow the attacker to access the device and its connection. The owner can control the botnet using command and control (C&C) software. The word "botnet" is a portmanteau of the words "roBOT" and "NETwork".
- Untraceable Internet Connection - Public and corporate Internet access points like cyber cafe, university campus, business organization, etc. provide Internet access to its users by shearing Internet connection. If a proper log of activity is not maintained, its users can easily conceal their identity to do illegal cyber activities including e-mail fraud without any fear of being traced.
Fortunately, a detailed analysis of an email header can often help to detect incongruent information that might suggest a potentially fake email. For example, a mail-server which does not match the server of the email address; or, to detect a suspicious amount of extra fields, or indeed, unusually few fields in the header itself.
Forensic investigation of an e-mail message can be carried out by the use of various techniques and software tools. However, these techniques and tools may prove to be ineffective to identify the e-mail forgery or the actor responsible for it. This is because analysis through these various techniques can halt due to lack of co-operation between different service providers. Further, invention of new means and changing tactics of the cybercriminals make e-mail forensic an active area of research thereby making it necessary to analyse e-mail headers for any possible forgery.
Email Header Forensic Analysis
Since the focus of this post is on email header forensics, it is necessary to review common processes involved in this process. This is shown in the figure below:
Sample of Email Header
Delivered-To: meetjosephmoronwi@gmail.com
Received: by 2002:a05:6358:a015:b0:dc:2d37:22f4 with SMTP id e21csp3142494rwn;
Mon, 31 Oct 2022 07:50:05 -0700 (PDT)
X-Received: by 2002:a05:6512:a93:b0:4a2:6bd4:e9d9 with SMTP id m19-20020a0565120a9300b004a26bd4e9d9mr5233759lfu.100.1667227805241;
Mon, 31 Oct 2022 07:50:05 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1667227805; cv=none;
d=google.com; s=arc-20160816;
b=fmUTloHyodGu9ZejtxiMyjap3xM6PaYlZdLQ5jwG+34399z/HxLNvJaNrI14IqkVBu
bv0PmVIXSzepe2D1bNeTbTNG3Gx/ytvzOt8rwNwaH7JM7w8r7QMXFQy+I5dFoZO6v6NR
zLzd/cdI7v+TNQALfn4WJvpgf1OqljrNxSJ1gcu6NJXfdpdhApK/ZBJJVez22FpXl5wn
yOkIHHyk2iOI2c5QOXLjnvAy/kTqHo4+vuEIZtj+hTWaYqE1CwNDEtErAIcUwt22emiV
e4oWCJGXN/C4tiMMJ/20MO1jFf9T7+BmfCQHTDUEnDsNFL4Brmbjez5RuIExYxaWD4SG
m/Dw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
h=to:subject:message-id:date:from:mime-version:dkim-signature;
bh=YWBfoFLIef4LQDCFkYLx1oKCFFrBFBMC+jzh5dZYMLc=;
b=Ln8chY5rV9Chq4ZJcGCaprHwEppq2kGpzAdmauC+xRBczDNgjZV2GskP2mWP4srql/
eOyETcdYHQ1ENmZGDJyj0Vk1po0RBVVvEXEhFOL5V/VCCYYa9pF49rn92ibOiJ0cwKbO
Z72NPGNzuACV6yAYfgZDZGAsAudBmnfvdI2aSVEYmT9qDpsmsfNrZKc894l2VpJvsoc3
SJQ+pcoWGGP6KX/Bvt44Ln3AsZHyFwlpD6sIVEUXye6Ias8HBzURFM/q/JQcgb6CLIAj
ba9BI4XczNZXWNAEpO+Y9wlai5OSXPO989OBmr4RAFl02PYJr3XDKBCMjzS8xsmk2XvQ
W2WA==
ARC-Authentication-Results: i=1; mx.google.com;
dkim=pass header.i=@gmail.com header.s=20210112 header.b=m8QtanH1;
spf=pass (google.com: domain of edouarddiouf19@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=edouarddiouf19@gmail.com;
dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com
Return-Path: <edouarddiouf19@gmail.com>
Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41])
by mx.google.com with SMTPS id c36-20020a2ebf24000000b002771de17211sor1838573ljr.73.2022.10.31.07.50.04
for <meetjosephmoronwi@gmail.com>
(Google Transport Security);
Mon, 31 Oct 2022 07:50:05 -0700 (PDT)
Received-SPF: pass (google.com: domain of edouarddiouf19@gmail.com designates 209.85.220.41 as permitted sender) client-ip=209.85.220.41;
Authentication-Results: mx.google.com;
dkim=pass header.i=@gmail.com header.s=20210112 header.b=m8QtanH1;
spf=pass (google.com: domain of edouarddiouf19@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=edouarddiouf19@gmail.com;
dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20210112;
h=to:subject:message-id:date:from:mime-version:from:to:cc:subject
:date:message-id:reply-to;
bh=YWBfoFLIef4LQDCFkYLx1oKCFFrBFBMC+jzh5dZYMLc=;
b=m8QtanH1wj5V+JuZqnfNwo9D/Yh3y4spMaxbRSI5j7S/Ah7wgMeP9UTvbTeZRDtmY6
M7YLPh8rDJgGsDGRoxkWUm/wzolSfzPeBGhTWr2yiQZPtYnA306HWmPo0JFxmlnNdgeh
92P/8a97GmOiylyNpfhd6WHS5U5BfOvX2RcWepFyAHjHgRf0yGjhhdzBpkTlU7eEe54B
e1Gz4Al0zegZIdNR2aA0q23DkGXHLxd5LNBUnr0RJwv4X8ss2YRLkEi5cNfDc5e5S/lx
JPbNrvjeqoe7VNiq43IG6bvsjB8qClr/F6asOMpV/88RcKqZpR3xOnqIW5C+QQXU5PAL
32gA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=to:subject:message-id:date:from:mime-version:x-gm-message-state
:from:to:cc:subject:date:message-id:reply-to;
bh=YWBfoFLIef4LQDCFkYLx1oKCFFrBFBMC+jzh5dZYMLc=;
b=AYYs01VfOslCyiSOWhKN6o212C/oM72UBwLJ7QYF/57Nnc6T0lhEwUmIrua/GVkwMd
snyD6inYkblcdzhFk/RHoYly87ZB4OE4a9NAJ/bF7+9hppOaNb/WLj6nuFYo4PX8/s6f
dxjxHmlCiQ3btNGwO6jznVUtcrJ6lysL3HnZwDQ9NF9yRWyLThwcPs73pUjye0POGytH
4bXPeDNh+zUu+aQX7r0mb8Cz48sZd+f/jvyGWnk/LeXvBCWaOvKX3nn64dP4QR/ZPlgy
A/WSyxnpBeN2CGdDXolZJdjiOhP09rdmYObhMvDdaJi1LPy8g4bSXU+kQdI/dMWfhiPv
asUg==
X-Gm-Message-State: ACrzQf0o0ddgfTufGaMJPR8xxt8Wl2lGYZjkc5wl6pVxeqtIWK+oGtNd WuRx4Cy2JTe4+VmiXau1zCG/p69dzZAV/fnw0ic=
X-Google-Smtp-Source: AMsMyM5EccCAFitdHPvYwm1gzpeY6wJ1d5QQ29ZyvEMwW2VljyVoZ4OKqZZaLCQ7z6IP5ACcev1jsBx91TFgE4avpa0=
X-Received: by 2002:a2e:b60e:0:b0:277:728:e748 with SMTP id r14-20020a2eb60e000000b002770728e748mr5264420ljn.346.1667227804685; Mon, 31 Oct 2022 07:50:04 -0700 (PDT)
MIME-Version: 1.0
From: centikaya <centikayakozanogul8@gmail.com>
Date: Mon, 31 Oct 2022 14:49:47 +0000
Message-ID: <CAC343STRQps9s=mKxip8onADmafQQ026q7+t951C67suGALhiA@mail.gmail.com>
Subject:
To: undisclosed-recipients:;
Content-Type: multipart/alternative; boundary="0000000000000eda1205ec55b9eb"
Bcc: meetjosephmoronwi@gmail.com
--0000000000000eda1205ec55b9eb Delivered-To:
Delivered-To: meetjosephmoronwi@gmail.comThe Delivered-To: field contains the email address of the intended recipient. It is one of the major things to check during email analysis as it can provide details of phishing activities. If the email address in this field is not the same as the recipient's actual email address, then it can be a sign of message tampering that warrants an investigation.
Received:
Received: by 2002:a05:6358:a015:b0:dc:2d37:22f4 with SMTP id e21csp3142494rwn;
Mon, 31 Oct 2022 07:50:05 -0700 (PDT)This field contains the details of the last visited SMTP server. The following information can be gleaned.
- SMTP server IP address
- The ID of the SMTP server
- Date and Time the email was received by the server
X-Received:
X-Received: by 2002:a05:6512:a93:b0:4a2:6bd4:e9d9 with SMTP id m19-20020a0565120a9300b004a26bd4e9d9mr5233759lfu.100.1667227805241;
Mon, 31 Oct 2022 07:50:05 -0700 (PDT)Some email parameters are not defined in Internet Official Protocol Standards and are called non-standard headers. X-Received is a non-standard header added by the receiving server. Some mail transfer agents like the google mail SMTP server include this field to share non-standard information. The following information can be gleaned from this field.
- IP address of the receiving mail server
- ID of the SMTP server
- Date and time the email was received
Return-Path
Return-Path: <edouarddiouf19@gmail.com>When an email message does not make it to its intended recipient, the return-path indicate where non-delivery receipts or bounced messages are to be sent. Return-Path field is verified by the Sender Policy Framework (SPF). This address can also be spoofed, if no authentication mechanism is in place at the sending server.
This part should be compared to the From: field. If the Return-Path: field and the From: field do not match, it is a red flag indicative of spamming. Spammers do not want all the undelivered email to end up in their inboxes!
Return-Path: <edouarddiouf19@gmail.com>
From: centikaya <centikayakozanogul8@gmail.com> As can be seen, the values in my sample email header do not match.
Received
Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41])
by mx.google.com with SMTPS id c36-20020a2ebf24000000b002771de17211sor1838573ljr.73.2022.10.31.07.50.04
for <meetjosephmoronwi@gmail.com>
(Google Transport Security);
Mon, 31 Oct 2022 07:50:05 -0700 (PDT) The Received: header field contains trace information that includes originating host, Mediators, relays, and MSA host domain names and/or IP addresses. The Received: field has a syntax such as shown below
Received: from ? by ? via ? with ? id ? for ? ; date-timeSome mail servers may not include all the parts.
An email header may contain one or more "Received" header fields. Each SMTP server (along the delivery path) adds a Received header to the top of the incoming message. The delivery route can be ascertained by the sequence of Received headers.
Most SMTP servers refuse messages with ``too many'' Received fields. For example, sendmail is typically configured to refuse messages with more than 25 Received fields. qmail refuses messages with more than 100 Received or Delivered-To fields. Some messages legitimately have 20 or more Received fields.
The Received field lists each mail server that an email went through before arriving in the recipient’s inbox. It’s listed in a reverse chronological order — where the mail server on the top is the last server the email message went through, and the bottom is where the email originated. From the bottom, the first Received header field contains the IP address of the machine used to send the e-mail message. On tracking this IP address several cases as explained below are possible:
- The IP address in the Received header field maps to direct connection having a static IP address. In this case, this address is the address of the sender’s computer. However, if the IP address is dynamic then the logs of the proxy or SMTP server need to be obtained for continuing the e-mail tracking.
- The IP address contained in the Received header corresponds to some proxy server. In this case, proxy server’s log must be obtained to track the sender. Open proxy server may raise some issues for the investigators because they do not maintain a strict log of activities. In case SSL is used to log on to HTTP based e-mail server, proxy cannot be an issue because IP address of the client shall be recorded. Corporate proxy servers may not be strictly time synchronized as they may be using Network Time Protocol (NTP) and thus may impede the investigation. ISP proxy servers usually maintain a strict and time synchronized log (use STIME protocol) and have a clear devised policy to cooperate with the investigators.
- The tracked IP address maps to some tunnelling server. In this case, tracking source of e-mail will be difficult because tunnelling may be done in different ways, and some are not logged.
- The IP address in the Received header field maps to SMTP server. In this case, the SMTP server log must be obtained. IP address may map to SMTP server belonging to ISP, or some corporate or an open relay. In all cases, logs stored must be obtained. If the logs are strictly time synchronized, then the sender can be tracked easily. ISP and corporate SMTP servers can provide further details about the particular user such as his contact details and credit card number.
- The IP address contained in the Received field resolves to Anonymizers or re-mailers. In this case, investigators must obtain logs and original e-mail message from the anonymous SMTP or HTTP servers. Further, in case the anonymity is a paid service, user account details must also be obtained.
It is also possible to add one or more false Received headers in the data field of the message with an intention to freeze the investigation. Investigators must pay careful attention to all fields of the Received headers with respect to each other especially in terms of delivery methods and date & time. If the delivery methods vary or the time and date differ considerably, then false headers can be easily identified. Otherwise, the investigation shall have to investigate all IP addresses and request logs from all servers. It may be very difficult to track a sender from the IP address if the sender has tampered IP address at packet level. Once the source of the e-mail message under investigation has been determined or someone is strongly suspected of being the source, his or her computer, e-mail client software, web browser, etc. are investigated for traces of evidence.
The From: Field
From: centikaya <centikayakozanogul8@gmail.com>The address displayed as the Sender's address by the Receiver's mail application as specified by RFC 5322. The From: field identifies the author of the email. That is, the mailbox of the person or system responsible for writing the message. The From address is sometimes called the 5322.From address.
The To: Field
This shows the name and email address of the recipient, including all of the email addresses on the CC (carbon copy) and BCC (Blind Carbon Copy) fields. It is also known as the 5322.To address.
Received-SPF
Received-SPF: pass (google.com: domain of edouarddiouf19@gmail.com designates 209.85.220.41 as permitted sender) client-ip=209.85.220.41;
Authentication-Results: mx.google.com;Sender Policy Framework (SPF) is an email security protocol that is used to verify the sender. The system forwards the message only after the sender's identity is authenticated.
Here, the google.com MTA notifies its recipient through Received-SPF that domain of edouarddiouf@gmail.com (i.e., gmail.com) which has an IP address 209.85.220.41 is a permitted sender designated by Sender Policy Framework. The technique uses the domain address for authentication and adds the check status in the header field. The following are possible values:
- Pass - Email source is valid
- Softfail - Fake source possible
- Fail - Source is invalid
- Neutral - Source validity difficult to ascertain
- None - SPF record not found
- Unknown - SPF check can't be performed
- Error - An error occurring during SPF check
SPF uses a DNS TXT record to list authorized sending IP addresses for a given domain. Normally, SPF checks are only performed against the 5321.MailFrom address. The 5322.From address isn't authenticated when you use SPF by itself, which allows for a scenario where a user gets a message that passed SPF checks but has a spoofed 5322.From sender address.
Authentication-Results
Authentication-Results: mx.google.com;
dkim=pass header.i=@gmail.com header.s=20210112 header.b=m8QtanH1;
spf=pass (google.com: domain of edouarddiouf19@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=edouarddiouf19@gmail.com;
dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.comDKIM-Signature
The results of email authentication checks for SPF, DKIM, and DMARC are recorded (stamped) in the Authentication-results message header in inbound messages.
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20210112;
h=to:subject:message-id:date:from:mime-version:from:to:cc:subject
:date:message-id:reply-to;
bh=YWBfoFLIef4LQDCFkYLx1oKCFFrBFBMC+jzh5dZYMLc=;
b=m8QtanH1wj5V+JuZqnfNwo9D/Yh3y4spMaxbRSI5j7S/Ah7wgMeP9UTvbTeZRDtmY6
M7YLPh8rDJgGsDGRoxkWUm/wzolSfzPeBGhTWr2yiQZPtYnA306HWmPo0JFxmlnNdgeh
92P/8a97GmOiylyNpfhd6WHS5U5BfOvX2RcWepFyAHjHgRf0yGjhhdzBpkTlU7eEe54B
e1Gz4Al0zegZIdNR2aA0q23DkGXHLxd5LNBUnr0RJwv4X8ss2YRLkEi5cNfDc5e5S/lx
JPbNrvjeqoe7VNiq43IG6bvsjB8qClr/F6asOMpV/88RcKqZpR3xOnqIW5C+QQXU5PAL
32gA==
DomainKeys Identified Mail (DKIM) is an email authentication method designed to detect forged sender addresses in emails. DKIM uses the email headers and body to generate a signature. If the headers are rewritten or text is appended to the message body after it has been signed, the DKIM verification fails. DKIM is backward compatible with the DomainKeys system. When an email message is signed with DKIM, it will include a number of “tags” whose values contain authenticating data for the message being sent. The tags include:
- v= - This tag defines the version of this specification that applies to the signature record.
- a= - The algorithm used to generate the signature (plain-text; REQUIRED). It supports "rsa-sha1" and "rsa-sha256", Signers usually sign using "rsa-sha256".
- c= - It is the canonicalization algorithm i.e., the method by which the headers and content are prepared for presentation to the signing algorithm
- d= - It is the domain name of the signing domain.
- h= - It is a colon-separated list of header field names that identify the header fields presented to the signing algorithm.
- q= - It specifies the query method used to retrieve the public key which by default is dns.
- s= - It is the selector used in the public key.
- bh= - The signature data or public key, encoded as a Base64 string.
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=to:subject:message-id:date:from:mime-version:x-gm-message-state
:from:to:cc:subject:date:message-id:reply-to;
bh=YWBfoFLIef4LQDCFkYLx1oKCFFrBFBMC+jzh5dZYMLc=;
b=AYYs01VfOslCyiSOWhKN6o212C/oM72UBwLJ7QYF/57Nnc6T0lhEwUmIrua/GVkwMd
snyD6inYkblcdzhFk/RHoYly87ZB4OE4a9NAJ/bF7+9hppOaNb/WLj6nuFYo4PX8/s6f
dxjxHmlCiQ3btNGwO6jznVUtcrJ6lysL3HnZwDQ9NF9yRWyLThwcPs73pUjye0POGytH
4bXPeDNh+zUu+aQX7r0mb8Cz48sZd+f/jvyGWnk/LeXvBCWaOvKX3nn64dP4QR/ZPlgy
A/WSyxnpBeN2CGdDXolZJdjiOhP09rdmYObhMvDdaJi1LPy8g4bSXU+kQdI/dMWfhiPv
asUg==This contains the DKIM signature of messages, sent via Google mail servers (e.g. GMail).
DMARC
Domain-based Message Authentication, Reporting & Conformance works in combination with existing security mechanisms like SPF and DKIM to identify if the email message comes from a legitimate mail server or if it is spoofed. It is essentially a TXT DNS record which publishes a domain’s policy for how receiving mail servers should act on SPF or DKIM failure. Actions include ignoring the problem, sending the message to the spam folder, or outright bouncing the message. The DMARC record contains some other settings such as an email address for mail servers to report any non-conforming mail they receive.
The following graph illustrates the DMARC process.
It has a number of attributes that inform the mail recipient how to perform DMARC processing of emails received from the domain. Below you will find a description of the most common attributes. For a full description of all attributes please refer to RFC 7489, section 6.3.
|
Attribute |
Description |
Mandatory |
Default Value |
Sample Value |
|
v |
Version - must be set to "DMARC1" and must be the first tag in the list |
yes |
- |
v=DMARC1 |
|
p |
Requested policy that recipient should apply to email. Can be set to "none", "quarantine" or "reject" |
yes |
- |
p=none |
|
rua |
RUI (mail address) where to send aggregate reports |
No |
- |
rua=mailto:dmarc@company.com |
|
ruf |
RUI (mail address) where to send message-specific failure information |
No |
- |
ruf=mailto:forensic@company.com |
|
pct |
Percentage of messages subject to filtering, i.e. only check 10% of emails |
No |
100 |
pct=10 |
|
sp |
Policy to apply to subdomains |
No |
Same as top domain policy (value of p) |
sp=quarantine |
|
adkim |
Assigns strict or relaxed DKIM identifier alignment, "r" is relaxed, "s" is strict |
No |
r |
adkim=s |
|
aspf |
Assigns strict or relaxed SPF identifier alignment, "r" is relaxed, "s" is strict |
No |
r |
aspf=s |
|
ri |
Requested interval between aggregate reports in seconds |
No |
86400 |
ri=43200 |
Reply-To:
The Reply-To: header field is added when the Sender of the message wants any replies to the message to go to that particular email address rather than the one in the From: address. This is the address the sender of the e-mail wants recipient to use for sending reply in response to the e-mail message. Carefully crafted sender spoofing combined with fake Reply-To e-mail address can lead to serious information leaks. This usually shows up as a separate field in the email client. There is no technique (SPF, DKIM, DMARC, or any other technology) that protects the Reply-To header. In your investigations, the Reply-To: field should be compared with the From: field.
A mismatch of the Reply-To: field and the From: field is indicative of a potential email fraud.
Message-ID
Message-ID: <CAC343STRQps9s=mKxip8onADmafQQ026q7+t951C67suGALhiA@mail.gmail.com>In order to uniquely identify each email all mail transfer agents (MTAs) use some sort of unique identifier. This identifier is referred to as ‘Message-ID’. Message-ID field is inserted into a header either by mail user agent (MUA) or the first MTA. Even though the Message-ID is optional as per RF2822 it recommends using it.
Unlike spoofing other fields in the header, spoofing message-id needs special knowledge. Only tech-savvy spammers can spoof the message-id cleverly. So deep analysis on message-ids may reveal some sort of information that will open a window to trace the source of an email. Also the message-id will help to find a particular email log entry within a log file of email server.
RFC 2822 states that each email must have a globally unique identifier. This must be included into the header of an email. The RFC 2822 also defines the syntax of message-id. It should be like a legitimate email address and it must be included within a pair of angle brackets. According to RFC 2822, message-id can appear in three header fields. They are ‘message-id header’, ‘in-reply-to header’ and ‘references header’. But message-id of the present email must be included against the ‘message-id’ header.
Message-ID is always included within a pair of angle brackets. The FQDN makes the MTA globally unique. The date and time with the combination of process id and special random numbers make the message unique in a particular MTA. This combination makes message-ids globally unique.
In some email headers, an investigator may encounter a Message-ID of the format shown below
The section before the @ character of the message-ID contains the timestamp information - the date and time of the message when it was sent. This timestamp information can be traced after the first eight digits in the message-ID. The date pattern is followed in the following form: YYMMDDHHMM
In the above-defined message-ID: – 1505080910, that can be written as 15 05 08 0910, means – 2015 (Year) / May (Month) / 08 (Date) / 9 (Hours) / 10 (Minutes) UTC.
To trace the source of an email message from the Message-ID, the investigator should note the following:
- FQDN contains local host name, from where the email was originated or the first MTA, and other domain information. the first part, preceding the first dot is the local host or the first MTA server name. Right side of the first dot is other domain information. Once domain name is found then domain’s point of contact and other domain registration details can be found with readily available tools. Once the domain administrator is identified then forensic analysers can get her/his help to track the source with Message-ID.
- Time is a critical factor in forensic investigation. The time part of message-id provides when the message was handed over for delivery. This time information will help to solve some of the problem stated below.
- In order to conserve IP address space most ISPs provide dynamic IP addresses. During investigation if IP address of the sender is found to be dynamic then the time information will help to search in the billing server who used this particular IP address at the specified time. This will help to identify the email sender. Billing servers contain session information such as period of login and allocated IP address for billing purposes. If sender used company’s SMTP server then both SMTP log and DHCP log must be collected for analysis.
- Most MTAs record all SMTP communication between servers in a log file. By analysing the log file of source MTA, the expected record can be found. Time stamp and hostname/IP address found in the record can be verified with suspected email header so as to confirm the sender. The source MTA may be maintained by ISP, or it may belong to a company. Forensic analysers will require legal authorisation to access the log files.
- In-reply-to header holds message-id of original message to which it is replying to. Also, this may include comma separated several message-ids, as a reply to several emails. Checking this header will help to find other suspicious emails.
- In case of threaded emails, continuous correspondence between parties, the reference header holds all message-ids from the first email to the last email. Supposing the message-id of the interested email is spoofed the other message-ids will help to trace the email source.
X-Spam Ratio
The spam score calculated by the spam filtering software of the receiving server or MUA is contained in X-Spam-Ratio field. If this ratio exceeds certain pre-defined threshold, e-mail will be classified as spam. Different receiving servers and MUA’s used different X-Header fields to indicate spam score and classification decision taken with regard to the current message. These include X-Spam-Flag, X-Spam-Checker-Version, X-Spam-Level, X-Spam-Status, etc.
Conclusion
The header analysis is carried out on the content of e-mail message to determine its legitimacy. Spoofing, unauthorized networks open mail relays, anonymizers or re-mailers, open proxy, SSH tunnel or port-redirector, botnets and untraceable Internet connections are common approaches by which senders lie to recipients about their true identities.
It has been found that header fields of e-mail message (that can directly reveal the identity of sender) can be forged unless compatible security protocols are used at both sending and receiving servers. However, first received header of the message contains the original IP address of the computer used to send the e-mail message, which can be tracked to identify the sender. In case IP address contained in the first received field maps to some Internet resource, sender can be tracked by identifying its identity from the logs maintained by servers or various network devices.
Lastly, you may want to combine email header analysis with email address OSINT investigation to achieve more robust evidence gathering about the suspect.
Post a Comment