The email message sent to the bank employee claimed that the sender received a wire transfer from the recipients 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 considersafe, 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 utilitycan 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 REMnuxsystem, MSGConvert is already installed and you can invoke it using themsgconvert 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 wont provide you with visibility into some aspects of the files contents. A better alternative is to use the" />
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 designatedusing 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 senders email client uses RTF to represent formattingand also attaches the text version of the message for email client that cannot display RTFcontent.
In the case of the email message described here, it is unclear whether it was used as part of a mass-scale or a targetedattack, which is one of the reasons Im 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 messagewas designedmake 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 redirectto a .zip file hosted on Dropbox." />
So that the victim didnt encounter this notice, the attacker added the usg= parameter to the malicious URL. Though the details of this parameter to Googles 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 dont match the URL in the query, then Google doesnt 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 Googles 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 accounts 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 attackers Google Analytics account. To accomplish this, the embedded HTML code began like this:
img src=http://www.google-analytics.com/collect?v=1tid=...
The tid= parameter contained the senders Google Analytics trackingID. The cid= parameter identified the messagerecipient using the persons 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">Lenny Zeltserfocuses on safeguarding customers IT operations at NCR Corp. He also teaches how toanalyze malwareat SANS Institute. Lenny is activeon TwitterandGoogle+. He also writes asecurity blog.
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.