Spam. It has been a bane of network administrators, users, and phishing targets for as long as most users today have been alive (if you were born after the mid 1970s that is)... So how does one track the sender of an email message, or the source of a spam message?

Simple, we need to read the metadata within the email itself.

 

For example, I have recently received a phishing email. It was well written, but oddly formatted but claimed to be from Google telling me someone sent me a private message. Now I am curious to see where this email originated from so I can do my own recon on their setup.

This email is clearly from a spammy source, but has been sent from an email address belonging to billbraithwaite.co.uk - assumably this is a compromised web server or host which has been hijacked or appears to be operating an open email relay.

Google Phishing Email Example

To find the source of this interesting email, we will need to dig through the email source code (which for Mozilla Thunderbird we do through the More > View Source option).

From there we get a new notepad window with the complete html source of the email message, along with all of the status updates for each of the email servers this message traversed via. So the content toward the top of the email is the most recent server, with the entries further down being the oldest and closest to the phish author.

In this case the email was initially received by the Google Mail Exchanger from cl02.webspacecontrol.com (185.33.54.2) but reportedly by a domain known to the system billbraithwaite.co.uk. What is curious to know is that this domain does not exist, but was reportedly sent by a mail server which claimed that it did.

This behaviour is achieved through poor configuration of the Exim Mail Relayer, and the ability to create accounts on cPanel which do not exist or are not assigned to the system's nameservers. This opens a webhost up to the possibility of their servers being used as a spam host.

What we mostly likely know about this email, it was sent from 185.33.54.2 from a cPanel Hosting Server, yet the domain itself does not exist.

However... there may be more clues in the email itself. Since this is a Google phish there are links to an offsite URL which aims to collect information from a would be victim. The domain in this case is mjjsoftware.com, and the link points to http://mjjsoftware.com/contradicted.php so first up we need to recon the target site...

Registry Registrant ID: Not Available From Registry
Registrant Name: REDACTED
Registrant Organization:
Registrant Street: REDACTED
Registrant City: Milanowek
Registrant State/Province:
Registrant Postal Code: 05-822
Registrant Country: PL
Registrant Phone: +48.665344400
Registrant Phone Ext:
Registrant Fax:
Registrant Fax Ext:
Registrant Email: REDACTED@REDACTED>

As you can see here the domain itself is registered to an individual, and there is not a website to speak of fronting onto mjjsoftware.com, which leads to the possibility that this domain is intended as a phishing harvester.

The phishing domain mjjharvester.com appears to reside at 79.96.228.162, so now I will take a look through the payload itself at http://mjjsoftware.com/contradicted.php. Initially it appears to be a junk html page, but at the base there is a javascript payload (take note that this is a PHP script, and the payload may be  variable).

The Javascript acts as a decoder of sorts to decode a URL then redirect the user to another payload website:

palmsa=60;
palmsb=[164,176,176,172,118,107,107,163,171,171,160,168,165,170,161,175,175,105,112,162,157,176,158,177,174,170,175,106,179,171,174,168,160,107,123,157,121,112,108,109,111,111,114,98,159,121,159,172,159,160,165,161,176,98,175,121,108,112,109,110,110,108,109,115];
palmsc=""; 
for(palmsd=0;palmsd<palmsb.length;palmsd++) {
palmsc+=String.fromCharCode(palmsb[palmsd]-palmsa); 
}
// http://goodliness-4fatburns.world/?a=401336&c=cpcdiet&s=04122017

In this case the payload is redirecting to goodliness-4fatburns.world - which appears to be a legitimate website functioning as a redirection portal to funnel phishing victims to other websites. From here the methods of redirection have become more difficult to trace, but we end up in a redirection loop to end up at a target website - varying depending on a funnel script at some point in the chain.

So how do we prevent this from occuring?

Unfortunately users are not the smartest animal in the zoo, and will always click on the links where they feel the link is legitimate. Generally speaking however, re-occurences of this nature can be prevented through implementing the following controls:

  1. Least Privileges - Does the accounts department really need Administrator or Super User access?
  2. Anti-Virus - Comodo and TrendMicro offer some free options which are successful in detecting most threats
  3. Legitimate Software - Download legitimate software only. Illegally obtained software and key generators are often laced with malware.
  4. Secure your servers - Employ the services of a vulnerability assessment firm to regularly evaluate your system for susceptibility to exploitation.
  5. Don't click the links! - It speaks for itself.