From: Maria Wilson [maria.wilson6870@securigroup.co.uk]The impact on this innocent company appears to be severe, with their website currently suspended.
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
Maria Wilson | Credit Controller
T: 0141 285 3838
www.securigroup.co.uk
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.
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:
http://hazardcheck.de/js/bin.exe
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:
83.169.4.178 (Hosteurope, Germany)
66.110.179.66 (Microtech Tel, US)
202.44.54.5 (World Internetwork Corporation, Thailand)
14.99.146.242 (Tata Indicom, India)
78.140.164.160 (Webazilla, US)
220.143.5.92 (Chunghwa Telecom, Taiwan)
217.12.203.34 (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:
83.169.4.178
66.110.179.66
202.44.54.5
14.99.146.242
78.140.164.160
220.143.5.92
217.12.203.34
1 comment:
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?
Post a Comment