We have detected evidence of a malware distribution campaign using messages masquerading as UPS delivery notification emails. These campaigns attempt to deceive the targets into thinking they are receiving mail from a trusted sender in order to dupe the recipient into installing malware, possibly for financial gain. Once the initial attack vector is installed, further malware may be distributed.
This appears to be part of the same campaign seen by MalwareMustDie (http://pastebin.com/n244xN32) and uses the email subject “UPS Delivery Notification Tracking Number”. We have seen a limited number of customers receiving this spam starting yesterday (Tue Nov 5), suggesting that this is a fairly low volume campaign (at the moment). The message contains an attachment with a filename such as “invoiceU6GCMXGLL2O0N7QYDZ” and extension .txt or .doc which is a disguised rtf file.
According to our analysis the malware attempts to download additional files by exploiting CVE-2012-0158 affecting old versions of Microsoft Office, which is detected by Cisco IPS signature 1131 and is available as a Metasploit module. In this case the malware being distributed seems to be a form of ransomware. Ransomware typically encrypts files on an infected machine and requires the user to pay for the release of their data. This particular piece of ransomware appears to be distinct from the samples we have been seeing as part of the Cryptolocker campaign, but comes in the wake of increased interest and discussion of this kind of attack.
As ever, users should remain vigilant when opening email links and attachments, and be wary of a message purporting to be an automated order confirmation from a company such as FedEx and UPS, as this is a common tactic which has also been identified as a possible method for distributing Cryptolocker.
Additional analysis of this attack can be found here: http://bartblaze.blogspot.com/2013/11/latest-ups-spam-runs-include-exploits.html
Malicious rtf: 7c2fd4abfe8640f8db0d18dbecaf8bb4
Downloaded exe: e5e1ee559dcad00b6f3da78c68249120
Thanks to Cisco researchers Craig Williams and Martin Lee for assistance with this post.