But what about all the poorly written phishing emails, off-putting malware names or their misspelled user agents?
Cybercriminals are able to write a program and orchestrate a maze of elaborate fraud schemes, but just can’t seem to get the wording right. If those criminals can put so much effort into creating phishing attempts that appear to be from a legitimate bank, why wouldn’t they also proofread emails or double check the user agent used in C&C communications.
Let’s take a look at some examples, starting with malware.
Upatre has been used as a dropper that installs banking malware like Zeus or Dyre. Those malware families typically attempt to capture banking credentials on a victim’s computer. Upatre is often delivered via a phishing email (which was probably misspelled).
When Upatre calls out, it attempts to look like legitimate traffic. The traffic has a HTTP GET request and a user agent, but the user agent is a bit off.This spelling oversight makes it much easier to detect and mitigate. The following IDS rule looks for exactly that misspelled user agent:
alert http $HOME_NET any -> $EXTERNAL_NET any (msg:”ET TROJAN Mazilla Suspicious User-Agent Jan 15 2015″; flow:established,to_server; content:”User-Agent|3a| Mazilla/”; http_header; fast_pattern:12,7; reference:url,malware-traffic-analysis.net/2015/01/15/index.html; classtype:trojan-activity; sid:2020235; rev:3;)
Another example isn’t actually malware. It’s a check-in for an LG brand smart TV.
The network traffic looks like it’s from a web browser. However, the user agent is misspelled. This would trigger an IDS alert if it was looking for unusual user agents with regex patterns, and it would probably be classified as a false positive after some quick incident response.
Let’s switch over to phishing. The following three samples were seen in the wild. They are either missing some words that are considered important when completing sentences in English, or they simply read as if a child wrote them.
This email is stating that the victim needs to upgrade an email account to an unlimited data plan:
In an attempt to guess at what’s going on, we’re going to create our own phishing email targeted at an English speaker, but written from the perspective of a phishing author who doesn’t speak English. The assumption is that the author would write a grammatically correct email in their language and then use Google translate to convert it to English.
Here’s our legitimate-sounding phishing email, written in English before using google translate:
Dear Card holder,
We have detected unusual login activity associated with your bank account.
Please re-confirm your account information and update your profile with us by visiting the following page:
Thank you for being a valued customer.
2014 American Express Account Security
Fraud Prevention Network.
Andrew Mei, one of our previous security research interns, wrote a grammatically correct version of this email in Cantonese. We then used Google translate to convert it to English. Here’s what we got:
Andrew mentioned that the term, “Dear CardHolders” is something one might say to a lord over a hundred years ago and there isn’t an equivalent term in English.
“If you are a club member” is odd since you should be a “member” if receiving the email, and what “club” is this?
And finally, the lack of punctuation creates a run-on sentence.
For the next version, Artsiom Holub, our Russian-speaking security analyst, wrote a grammatically correct version of the text in Russian, which was translated to English using Google translate:
This looks a little better than the Cantonese version, but still has errors. There’s a “(th)” between “Dear” and “card holder” and the signature line is messed up. However, it’s got the right punctuation and doesn’t mention anything about “club members.”
IDS signatures will catch malicious software with misspelled user agents and other attributes, but email is often not passed in the clear. Additionally, IDS signatures are fairly ineffective against bulk text seen in an email.
Since all phishing emails are going to be sent without end-to-end encryption (unless it’s some sort of advanced, targeted attack in which a private encryption key might already have been compromised), emails could possibly be analyzed on the wire using natural language processing.
OpenDNS already utilizes natural language processing along with other techniques to automatically classify unusual domain names seen being requested by users of OpenDNS. If a client is performing a DNS lookup for paypa1[.]com (notice the number 1 instead of the letter ‘L’), we will automatically use that information in classifying that domain as malicious.
With just a little effort from an enterprising system administrator, it could be possible to build a local system using similar techniques to analyze the clear text emails as they come into an email pooling system.
The errors in phishing are useful though. The emails that make it past spam filters have one final filter to pass through: the user. Vigilance in reading the email and noting where it originated and how it uses language are great steps in staying secure from phishing.