zerotoroot - My Journey to Becoming a Hacker

zerotoroot - My Journey to Becoming a Hacker


Follow the path to becoming a hacker!

Julius
Author

Share


Subscribe to zerotoroot - My Journey to Becoming a Hacker


Subscribe to my newsletter to receive article notifications and regular updates.

Tags


Fishing for a Phisher – An Email Tale

A couple of weeks ago, I got this email.

JuliusJulius

A couple of weeks ago, I got this email.

You got to love phishing emails!

It's as professional as only a phishing email could be.

But it did get my attention! Because I started to ask myself: Who is the person behind this email? What is the origin of it? Is it possible to tell? And how much can I find out, from looking at it in detail?

Those were all questions I thought worth pursuing. So that's where it started.

How to Identify the Source of that Email

Since the sent email is all we have, the only option we have is to dig into the raw source file.

Each email client offers the possibility to do this. You just have to know how – I'll show you how to do it on a Mac.

In the macOS Mail app, select an email, go under File and Save as... and save the email. It will be saved as an .eml file, which is what you want. Then open it in your favorite text-editor.

Alternatively, you should be able to see the header via Cmd + Shift + H in Mail.
The raw email file containing the headers, needed for analysis.

The result is the raw email ready to be analyzed. Let's go!

Digging into Email Header Analysis

Any email client does not display 95% of the email header. Thus, one tends to think that it's not there. But it is.

Email header analysis is the practice of looking at the email header in order to figure out additional information. So that's what we are going to do.

Retracing the Email Send Path

In order to quickly get the relevant headers, we simply grab the lines between the first Received: and From: line:

$ cat reimbursement-funds.eml | awk '/Received:/,/From:/'
Received: from smtp-server.unlp.edu.ar (smtp-server.unlp.edu.ar. [163.10.***.***])
        by mx.google.com 
        Sat, 01 Sep 2018 13:40:53 -0700 (PDT)
        
Received-SPF: neutral (google.com: 163.10.***.*** is neither permitted nor denied by domain of info@yahoo.com) client-ip=163.10.***.***;

Received: from localhost (unknown [163.10.***.***])
	by smtp-server.unlp.edu.ar (Postfix) with ESMTP id DA7CAE3C9;
	Sat,  1 Sep 2018 17:40:05 -0300 (-03)
    
Received: from smtp-server.unlp.edu.ar ([163.10.***.***])
	by localhost (mailfilter.unlp.edu.ar [163.10.***.***]) (amavisd-new, port 10026); Sat,  1 Sep 2018 17:40:05 -0300 (-03)
    
Received: from [192.168.43.46] (unknown [197.210.***.***])
	(Authenticated sender: user@unlp.edu.ar)
	by smtp-server.unlp.edu.ar (Postfix);
	Sat,  1 Sep 2018 17:35:20 -0300 (-03)
    
Subject: Reimbursement Funds
To: Recipients <info@yahoo.com>
Reply-To: compensation****@gmail.com
From: "Compensation Committe Board" <info@yahoo.com>

The bottom most Received line, the one closest to the Subject header, is the one that indicates the source of the email.

Received: from [192.168.43.46] (unknown [197.210.***.***])
	(Authenticated sender: user@unlp.edu.ar)
	by smtp-server.unlp.edu.ar (Postfix);
	Sat,  1 Sep 2018 17:35:20 -0300 (-03)

By closely looking at it, we can gather the following five details:

  1. the email was sent from the IP address 197.210.***.***
  2. the first outgoing SMTP server was smtp-server.unlp.edu.ar
  3. the authenticated user who sent the email was user@unlp.edu.ar.
  4. 192.168.43.46 is the private IP of the user's internal network, which was used to connect to the SMTP server.
  5. Sat, 1 Sep 2018 17:35:20 -0300 (-03) is the timestamp when the email was first received by a mail server. We can gather that the email has been sent from a UTC - 3 timezone.

Now that we have the rough outline, we can start to fill the blanks using different techniques.


Filling in the Blanks

First, let's find out where the first IP address 197.210.***.*** belongs to. Getting a physical location linked to an IP address isn't too difficult. We can simply call the ipstack API (requires an account):

$ curl http://api.ipstack.com/197.210.***.***?access_key=api-key
{
  "country_name": "Nigeria",
  "city": "Lagos"
}

Turns out, the user was from Lagos, Nigeria📍.

Next we figure out where the domain unlp.edu.ar is situated and to whom it belongs –and yes, we could simply do this by entering the domain in our browser, but let's try it another way.

Gathering the Information Manually via Command Line

Using dig to create a simple DNS request we can find out the domain's IP address. Through the IP we can get a rough physical location.

$ dig unlp.edu.ar
...
unlp.edu.ar.		5363	IN	A	163.10.95.67

$ curl http://api.ipstack.com/163.10.95.67?access_key=api-key
{
  "country_name": "Argentina",
  "city": "La Plata"
}

Turns out the server, as one might have guessed by looking at the domain name, is in Argentina.

To find out who is behind the IP address, let's turn to whois. For whois queries, I typically use whois.com in my browser. So I did.

It turns out, it didn't work. It returned no record.

If you look at the page, it seems that Whois.com queries APNIC by default. APNIC is responsible for IP addresses in the Asia-Pacific region, and our IP address is not within its address range.

If you closely read the response, it suggests to query other databases. Judging by the hostname, we can guess that the IP address is in South America, and the whois responsible for that region is whois.lacnic.net.

Wanting to go all command line, I chose to try myself with the whois command. I just needed to figure out how to query a specific whois server. A quick man whois provided the following:

whois -h <host> allows you to query specific whois databases.

With both the above information, we can put together our query.

$ whois -h whois.lacnic.net 163.10.95.67

% LACNIC resource: whois.lacnic.net

inetnum:     163.10/16
status:      assigned
owner:       Universidad Nacional de La Plata
...

The domain unlp.edu.ar, thus, belongs to the University de la Plata, Argentina.

Having uncovered the domain, we have examined all of the information available to us, thus, concluding our search.

Wrap up

Let's quickly rehearse what we learned by looking at the email above:

The email was sent by the user user@unlp.edu.ar from the SMTP server smtp-server.unlp.edu.ar of the University de la Plata, Argentina. The internal IP address, used to connect to the SMTP server, was 192.168.43.46. The public IP address of the user who connected to the account was 197.210.***.***, which turns out to originate from Lagos, Nigeria.

Limitations - Or, can you always trace an email?

All the above will probably make you believe that the information you get from an email trace is 100% correct. And it some cases, that's absolutely true. It can be a 100% correct. But it doesn't need to be.

The header information can be manipulated by each mail server on the send-path.

An MTA [mail server] could even receive an email, strip all the received headers from it, decide not to bother adding one of its own, or add some fake ones, and then forward on to another MTA [mail server] if it really wanted to.
- Mike Cardwell

The SMTP protocol, in itself, simply offers no guarantee as to the authenticity of the header information.

So, no, you cannot always trace and trust an email. At least not by only looking at its header.

Soon

In the next post, I will actively find out the IP address of the phisher using a simple tracking technique used by email marketing companies. Let's see what the result will be!


Thanks

My thanks goes to Mike for his help in answering my many questions about emails, SMTP, mail transfer agents and the like. Be sure to check out his projects on ParseMail and EmailPrivacyTester.

Julius
Author

Julius

View Comments