Sponsored by..

Thursday, 19 February 2015

Malware spam: "Maria Wilson" / "securigroup.co.uk" / "Statement"

This fake financial spam does not come from SecuriGroup, their systems have not been compromised in any way nor has there been any leak of information. Instead, this is a simple forgery with a malicious document attached.

From:    Maria Wilson [maria.wilson6870@securigroup.co.uk]
Date:    19 February 2015 at 09:10
Subject:    Statement

Please see attached up to date statement.

I would be grateful if you could confirm all due invoices have been processed for payment.

Many thanks

Maria Wilson | Credit Controller

T: 0141 285 3838


Think Sustainability - Do not print this email unless essential

This email and any attachments are confidential and intended for the addressee only.

If you are not the named recipient, you must not use, disclose, reproduce, copy or distribute the contents of this communication.

If you have received this in error, please contact the sender and then delete this email from your system.
The impact on this innocent company appears to be severe, with their website currently suspended.

I have only seen only sample of the attachment Statement 18 FEB 2015.xls although there are probably other variants. This contains a set of macros [password=infected] which are mostly crap, but the key parts are Modules 13 (the encrypted strings) and 27 (the decrypt function). These macros download a file from the following location:


This is saved as %TEMP%\FfdgF.exe which has a VirusTotal detection rate of 5/57. Various automated analysis tools [1] [2] [3] show attempted network connections to: (Hosteurope, Germany) (Microtech Tel, US) (World Internetwork Corporation, Thailand) (Tata Indicom, India) (Webazilla, US) (Chunghwa Telecom, Taiwan) (ITL Company, Bulgaria)

The Malwr report shows it dropper another version of the downloader (VT 3/57) and a malicious DLL (VT 6/57). Payload is probably Dridex.

Recommended blocklist:

1 comment:

Robin Norris said...

Interesting point: Though we had over 200 recipients with a nearly equal number of senders, each message was sent with the exact same Message ID over the course of an hour. This reuse of a Message ID by multiple senders flies in the face of the SMTP RFC. Makes one wonder what they are using to generate this crud, no?