Last Updated: 2015-06-30 01:47:25 UTC
by Lenny Zeltser (Version: 1)
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:
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. Armed with the proper "usg=" value, the attacker would have known how to craft the URL that automatically redirected the victim. (Do you have a better theory regarding this? If so, please leave a comment to this diary.)
The potential of using "usg=" for automatic malicious redirects has been known for several years.
As of this writing, it is no longer possible to download the malicious zip file from the specified location, 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:
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.