How Malware Campaigns Employ Google Redirects and Analytics
Last Updated: 2015-06-30 23:59:53 UTC
by Lenny Zeltser (Version: 3)
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. 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:
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.
For that, I emailed myself http://Examining.MSG.and/EML/Files_on.Linux then I opened my gmail account with lynx. All in 30 seconds.
I got the same hash using another gmail account.
Jun 30th 2015
7 years ago
Jun 30th 2015
7 years ago
Second, Outlook has the ability to reveal the SMTP headers for emails. In Outlook 2003 and earlier, this was pretty easy - just rightmouseclick on the message in your inbox and select message properties. Later versions of Outlook (starting with 2010, and perhaps 2007, I never used the latter) require that you configure the Quick Access Toolbar above the menu bar. Click on the dropdown, select "More Commands", then in the "Choose commands from" dropdown select All Commands, and add "Message options..." to the toolbar. Now that you've done that, select the message in your inbox, and click on the Message Options icon in the Quick Access Toolbar, and up will pop the dialog containing the Internet headers field. You can peruse that field directly, or click in that field, then ctrl-a, ctrl-c, open your favorite text editor and paste it into there for your further investigation.
Jun 30th 2015
7 years ago