The email message sent to the bank employee claimed that the sender received a wire transfer from the recipient's organization and that the sender wanted to confirm that the payment went through without issues. The victim was encouraged to click a link that many people would consider safe, in part because it began with "https://www.google.com/". How would you examine the nature of this email?

Examining MSG and EML Files on Linux

One way to analyze the suspicious message saved as an Outlook .msg file is to start with the MSGConvert tool by Matijs van Zuijlen. This utility can convert .msg files into the more open multipart MIME formatted .eml files, whose structure is defined by RFC 822. MSGConvert works well on Linux. If you are using a recently-updated REMnux system, MSGConvert is already installed and you can invoke it using the "msgconvert" command. If using another distro, you can install the tool using the command "cpan -i Email::Outlook::Message".

Once MSGConvert produces the .eml file, you can examine some of its aspects using a text editor, though this approach won't provide you with visibility into some aspects of the file's contents. A better alternative is to use the emldump.py utility by Didier Stevens, which can deconstruct an .eml file into sub-components and extract the contents, like this:

In the example above, invoking emldump.py without any parameters showed the structure of the .eml file. The "-d" parameter directed the tool to dump the item that was designated using the "-s" parameter.

The suspicious email message included plain text and RTF-formatted components with matching contents. This is typical of many messages sent nowadays: The sender's email client uses RTF to represent formatting and also attaches the text version of the message for email client that cannot display RTF content.

In the case of the email message described here, it is unclear whether it was used as part of a mass-scale or a targeted attack, which is one of the reasons I'm not showing its contents here. However, the message resembled the style of the note posted on one public forum, which looked like this:

"Recently I received BPay transfer from you. I need to verify if it is sent correctly. This contact was in the transaction beneficiary info. Here is the full details of the payment:"

Automatic Redirect via Google

The malicious link embedded in the email message was designed make the victim believe that the destination of the URL was hosted on google.com and was, therefore, safe. In reality, the link was designed to redirect to a .zip file hosted on Dropbox. The URL was carefully structured to utilize the automatic redirection capability of google.com. It began like this:

https://www.google.com/url?q=https%3A%2F%2Fwww.dropbox.com...

However, a simple form of this URL would be insufficient to trigger an automatic redirect. Instead Google would have presented the victim with the following message:

So that the victim didn't encounter this notice, the attacker added the "usg=" parameter to the malicious URL. Though the details of this parameter to Google's search URL are undocumented, it appears to contain a hash or a checksum of the URL specified in the "q=" parameter. If "usg=" is missing or its contents don't match the URL in the query, then Google doesn't automatically redirect and presents the notice above. A proper value supplied within this parameter causes google.com to automatically redirect to the specified URL. Google uses this mechanism to direct visitors to their desired destination when they click a link on the search results page.

No one outside Google seems to know the algorithm for computing "usg=" contents. To derive the proper value, the attacker must have had to wait for Google to index contents his or her Dropbox, so that Google's servers precomputed the hash/checksum. However, adversaries can get Google to compute the "usg" hash quickly. For instance, the miscreant can email the desired destination URL to his/her own Gmail account, and then access Gmail using basic HTML view. For some reason, when accessed this way, Gmail converts the URL embedded in the email to the Google-redirected form, which includes the proper "usg" hash.

Armed with the proper "usg" hash, the attacker would have known how to craft the URL that automatically redirected the victim.The potential of using "usg=" for automatic malicious redirects has been known for several years, though at the time it was not clear how attackers could quickly obtain "usg" hash values.

Google is aware of the potential for using its search engine for redirection and doesn't consider this a vulnerability. Google's position is that URLs are "not a reliable security indicator, and can be tampered with in many ways; so, we invest in technologies to detect and alert users about phishing and abuse, but we generally hold that a small number of properly monitored redirectors offers fairly clear benefits and poses very little practical risk."

As the incident discussed in this diary shows, adversaries employ google.com for redirection nonetheless, apparently with some success. Moreover, Gmail's ability to provide attackers with an easy way for computing "usg" hashes weakens the safeguards that Google erected to defend against the abuse of its redirection feature. (I reported the Gmail-related scenario to Google, so the company can assess the potential for its misuse.)

As of this writing, it is no longer possible to download the malicious zip file discussed in the email above, because Dropbox presents the following message:

Error (429) This account's public links are generating too much traffic and have been temporarily disabled!

Tracking Email Using Google Analytics

The malicious message contained an embedded 1-pixel image that was designed to track whether, when and where the recipient opened the message. This web bug was linked to the attacker's Google Analytics account. To accomplish this, the embedded HTML code began like this:

img src="http://www.google-analytics.com/collect?v=1&tid=...

The "tid=" parameter contained the sender's Google Analytics tracking ID. The "cid=" parameter identified the message recipient using the person's email address. As the result, Google Analytics provided the adversary with the insights necessary to track the effectiveness and context of the initial attack vector.

In this incident, the attacker was using mainstream tools to deliver malicious payload and keep an eye on the overall campaign with the help of Google search engine's redirects, Google Analytics and Dropbox. These tools provide adversaries with powerful and scalable capabilities at the affordable price of zero dollars.

-- Lenny Zeltser

Lenny Zeltser focuses on safeguarding customers' IT operations at NCR Corp. He also teaches how to analyze malware at SANS Institute. Lenny is active on Twitter and Google+. He also writes a security blog.