|
Introduction Researchers should review their spam filters to see what malware is getting caught. Security professionals should be aware of current practices used by criminals pushing malware, even if it has little chance of infecting anyone in their organizations. Reviewing the spam filters keeps provides a clearer picture of our cyber-threat landscape. In today's trip through the spam filters, I found two emails with malicious attachments. These attachments are Word documents with malicious macros designed to infect a vulnerable Windows host with Gozi-ISFB.
Unfortunately, I cannot share the emails. Both emails appear to contain legitimate correspondence. They each include a chain of previous messages, and I could not easily redact the information like I normally do with other examples of malicious spam. Therefore, this diary will focus on the attachments, follow-up malware, and network traffic. What is Gozi-ISFB? Gozi-ISFB is a variant of Ursnif, and today's traffic looked like an example shared by @DynamicAnalysis in a blog post on malwarebreakdown.com. I generated two infections using each of the Word documents. In today's activity, about 8 to 10 minutes after the initial infection, the infected Windows host downloaded follow-up malware. Here's what I saw:
The first infection followed-up with the Nymaim Trojan, and I've documented Nymaim traffic back in November and December of 2017.
Since I've covered Nymaim before, I'm far more insterested in the second infection where I couldn't identify the follow-up malware. The second infection The second infection follows the same patterns as the first. However, this time the follow-up malware is different. I saw encrypted traffic with no associated DNS requests or domains. Two of the IP addresses had interesting certificate data as shown in the images below.
Based on the network traffic and post-infection artifacts, I could not identify the follow-up malware. The follow-up malware is a malicious DLL named winmm.dll that's loaded by a legitimate Windows system file named presentationsettings.exe. Both were found in a newly-created directory under the infected user's AppData\Roaming folder. See the indicators section below for details. Indicators Artifacts from the 1st infection: SHA256 hash: febb37762a92bedad337d0489ac482e356e2787533d65a757c3375fb147ff0a8
SHA256 hash: 14284152d53c119ad04c986a2a115485ae480d8012603679bf28ec27e3869929
SHA256 hash: d254e82bdbfd16aa9f0037e2c536c3b9dddd6ec559d26a5af005d3a1f8199d59
SHA256 hash: f1c9544e8f1de92f60f13e29403fc459811b93a7a316d957cb30c1b4a61ba61d
SHA256 hash: 6e5faf4c3eb47a5218f173564fc1e5a8afc65a8126ff7f602e8dbfe98a2ba695
Artifacts from the 2nd infection: SHA256 hash: 044e86936bfc30cd0c07186b6e270650f896f6a42e9b8015abc184d161880090
SHA256 hash: f8bdb65d54ccab04a506e84f14bdbeef15f6266a7bd6e4e7dfde69de424dd10a
SHA256 hash: 208b94fd66a6ce266c3195f87029a41a0622fff47f2a5112552cb087adbb1258 (not malware)
SHA256 hash: 018084df00799387be61c5f849af8fce093aab8f73420a2ece7b47d0f45fa07e
1st run infection traffic:
2nd run infection traffic:
Of note, during the first infection, I rebooted the infected Windows host 3 or 4 times, which might account for multiple copies of what I assume are Nymaim. If you review the pcaps, the reboots are indicated any place you see an HTTP request to www.msftncsi.com. Malicious domains Indicators are not a block list. If you feel the need to block web traffic based on this diary, I suggest the following domains:
Final words Pcaps and malware for today's diary can be found here. Good spam filtering, proper Windows administration, and best security practices will ensure most people never see this malware. However, criminals are constantly tweaking their methods in an attempt to slip past our defenses. It pays to be aware of current malware indicators, so we're prepared if any ever make it into our network. --- |
Brad 351 Posts ISC Handler |
| Subscribe |
Jan 17th 2018 1 year ago |
|
Unfortunately this sometimes can be tricky to update filters to block preemptively in some organizations do not want to miss out on mail especially false positives. Many times security researchers are subjected to only employing filters reactively and specific to the malspam. These filters generally are very specific and only come after the fact of discovery which usually means someone opened the email and attachment. In todays business landscape businesses need to stand strong with their security policies and do due diligence to ensure that if false positives are caught, they have a process in place to allow audit of these emails and releasing of them. All to often the reaction is to turn off the filters because the emails get held up and impacts sales. Unfortunately this happens at the cost of security. Just my 2 cents.
|
ShadowITGroup 1 Posts |
| Quote |
Jan 17th 2018 1 year ago |
|
So how did the malware get attached to legitimate emails?
|
SasK 12 Posts |
| Quote |
Jan 18th 2018 1 year ago |
Quoting SasK:So how did the malware get attached to legitimate emails? That's a very good question. If they are in fact legitimate emails, this implies a host used by the other email account (or perhaps the email account itself) communicating the with recipient is compromised. It's possible an infected host is using a local cache of an email client to send these messages. Unfortunately, without having access to the host at the other end of the conversation, I don't know how this is being done. It's also possible these long email chains are completely fake, but what little I've seen indicates they are not. For example, signature blocks used by the recipient in previous correspondence from the email chain make me think these are legitimate conversations, and the host at the other end is somehow compromised. How this happened? I don't know. |
Brad 351 Posts ISC Handler |
| Quote |
Jan 18th 2018 1 year ago |
Sign Up for Free or Log In to start participating in the conversation!
