Spicing up phishing attacks

Phishing is often regarded as old hat. From a technical perspective, it’s a case of ‘been there, done that’.

Sometimes however, we come across attacks that are just a little bit more interesting (or at least different) from the norm. In this post I am going to take a quick look at one of the techniques used in some phishing attacks we have seen in recent months.

Most phishing attacks that we see fall into one of two camps:

1. Spam email containing a link to the phish site within the email message body. In some cases, the link in the message body may point to an initial web page (normally hosted on a compromised web site), which redirects the user to the phish site. Either way, clicking on the link results in the user ending up at the phish page.
2. Spam email containing a HTML attachment which itself is the phish page. Sophos products block these attachments as Mal/Phish-A.

For the second type, to create the HTML attachments most attacks use the same technique:

• Take a copy of the HTML source for the web page that is being faked (e.g. bank login page).
• Optionally, obfuscate this code (perhaps deliver via some obfuscated JavaScript).
• Modify the relevant HTML form such that submitted data is sent to the attacker’s web server.

The other week I was alerted to a PayPal login page that was being spammed as an HTML attachment (nothing new there). However, in this case the HTML forms within the page all referenced legitimate PayPal servers.

Odd. So how is harvested data sent back to the attacker?

Closer inspection revealed quite a cunning way of ex-filtrating the user data.

The spam message itself was what you expect – social engineering being used in an attempt to trick the recipient into opening the attachment.

If the user opens the attachment, they are presented with what looks to be a PayPal login page. Inspection of the HTML source confirmed that the various forms within the page referenced legitimate PayPal resources.

The page did load suspicious JavaScript content from a non-PayPal server however. Furthermore, there was a suspicious (or at least unexpected) empty iframe within the page.

The remote JavaScript revealed the key to how the attack worked. The script was being used to validate user input entered into the various PayPal forms.

Data from the customer signup form was serialized and stored in the variable cus_data.

Then, data from the subsequent billing form was also serialized, and stored in the variable cc_data.

These variables were then sent back to the attackers by dynamically populating the empty iframe element (see above).

Cunning! So by hooking the form submission process, and then dynamically populating the iframe, the attackers are able to send the form data back to their server. This included all of the following:

• Email
• Password
• First name
• Last name
• Date of birth
• Citizenship
• Address
• Telephone number
• Credit card number
• Cvv number
• Expiry date
• Sort code
• Social security number
• Customer id

So why bother with all this? Why not stick to the basics and just edit the target of the HTML form?

There are probably 2 advantages to the technique used in this attack:

1. The spammed web page will raise less suspicion. Seeing forms pointing to unexpected remote servers is a giveaway sign of the page being a phish.
2. The mechanism enables them to include data from multiple forms. Ideal for complex sites where customers may enter data in different steps.

I guess the moral of the story is not to entirely dismiss ‘old hat’ attacks. They can still throw up surprises from time to time!

_{Feeding fish, net and phishing text images from Shutterstock.}