Bank Phishing Incident Analysis

Everyone has received a phishing scam via email at one point or another. Thanks to modern anti-spam technology, most of these messages are blocked from ever reaching our inboxes.

I said most of them. Today I got one that was able to get through the bouncer:

The subject (in Brazilian Portuguese and poorly crafted) translates to a warning related to “premium” account holders of the Santander bank.

Typical phishing, right?

Email Attachment Leads to Phishing Page

In this case, the message content is attached to the email. Most of us know to treat attachments with suspicion and only open them if they can be verified by the sender. For security analysts, we like to dig deeper to see what the attachment contains and where the message really came from.

Inspecting the HTML source code we can see a pretty simple linked image:

The image it loads looks like a web page belonging to the Santander bank:

Again, it is written in Brazilian Portuguese, all contact numbers are correct, and the layout is similar to the one used by the bank to communicate with their clients. However, Brazilian banks will never send security alerts to their clients through email.

This message tells the victim that a security module on their computer is outdated, and if not updated to the newest version, the bank would issue a fine of $246.67 BRL (around $80.00 USD) to the user.

The whole image is clickable and leads to the phishing page. By the time I started the analysis, the site was already offline; likely removed due to blacklisting or suspension from the host.

Where Does Phishing Come From?

Phishing messages are rarely ever sent using the attacker’s own infrastructure. They often hack into a vulnerable site and use its server resources for their nefarious objectives. Let’s discuss that for a moment.

It’s important to understand phishing, blackhat SEO, and other website hacks for what they really are – profitable campaigns. Whenever an attacker gets into a site and takes control of it, the first thing they usually do is create a way to keep the site under their control, even if the original vulnerability is fixed by an update. This is done by installing backdoors. According to our Hacked Website Trend Report for Q3-2016, 72% of hacked sites contain at least one PHP-based backdoor. More often than not, there are multiple backdoors allowing attackers to regain access to hacked sites.

When the backdoor is in place and the attacker has ensured they can sustain their malicious campaign, the next phase of the attack will begin.

Analysing the Email Headers

It is possible to get some juicy information from the mail headers when you analyze it.

For example:

X-PHP-Originating-Script – Will tell us which script was used to send the message
Message-ID – Discloses the site hosting the script
X-Mailer – Shows what program was used

For those who noticed that there is no X-HEADER here, it’s because they are not actually required to make a valid SMTP transaction. These types of headers are added by programs to help with tracking and debugging.

In this case, we know that add-from-server.php sent the original message, and it used PHPMailer [version 1.73] to do it. 1.73 is a ten-year-old version of PHPMailer that is vulnerable to remote code execution.

Since Message-ID shows us the hacked website where the phishing attempt came from (pixelated in the image above), why not try scanning it with SiteCheck?

Scanning the Originating Website

And guess what? The site is infected with SEO spam:

And… it is also outdated and vulnerable according to the Website Details tab of SiteCheck:

It’s impossible to be sure that the same attacker who was responsible for injecting spam in the site also used it to send phishing messages, especially since Brazilian bank scammers are not known for being SEO spammers. However, we have seen cases of two attackers hacking the same site in the past, which is not surprising given that hackers share tools and tactics to find vulnerable websites.

How to Avoid Being the Victim

So now that we know we’re dealing with a site that was compromised, let’s turn back to the add-from-server.php file, which was used to send the message. This file belongs to the add-from-server plugin, which is vulnerable to Cross-Site Request Forgery. The vulnerability can be exploited by sending a malicious link to the administrator and uploading a backdoor to the site.

It is possible that the website owner or one of the admin users could’ve been the weak link in the chain – phishing leading to more phishing.

With the risk of sounding clichè, here are some tips to avoid infection: