[Threat] VBA/TrojanDownloader.Agent.MUV

[pronto 6]

Servus Comminity,

yesterday at 11:00am we had a false negative detection on our Exchange Server, which accepts the email from outside and is the first instance to check for viruses. This server then forwards the mails to the internal servers, which host the databases of a two-node DAG. At about 15:00pm the virus scanner on the internal Exchange servers has detected and deleted an infected attachment.

Due to the delay of four hours I first assumed that this was a zero-day exploit and unfortunately we were among the first to receive this virus. However, further research has shown that ESET has known this virus, or at least a virus with the same name as this one, since 20.01.2020 and would therefore be far away from a zero-day exploit.

In the logfile of the virus scanner there are some updates of the detection engine for yesterday, on all three mail servers. How is it possible that the first mail server missed the email and the other two did not have a reaction within four hours? Is this a generic name, as there is no version number in the threat name, are there more detailed information about the found virus? If the name is not specific and is used multiple times, how can you take adequate action in case of an infection?

Thx & Bye Tom

[Marcos 5,070]

There have been several variants of VBA/TrojanDownloader.Agent.MUV, the first one was added on Feb 20, 2019, the last one on Jan 29, 2020 (engine 20752).

[pronto 6]

8 minutes ago, Marcos said:

There have been several variants of VBA/TrojanDownloader.Agent.MUV, the first one was added on Feb 20, 2019, the last one on Jan 29, 2020.

Servus Marcos,

is there a public database where you can view more detailed information about specific malware? Such as the history or other useful information to make your own investigations if an infection is suspected...

Thx & Bye Tom

Edited January 30, 2020 by pronto

[Marcos 5,070]

Unfortunately no. It is not possible to check the history of changes in particular detections except internal tools used by malware analysts.

[pronto 6]

10 minutes ago, Marcos said:

Unfortunately no. It is not possible to check the history of changes in particular detections except internal tools used by malware analysts.

Hm, that's not good. ESET tells me they've found a virus, but they won't tell me exactly what virus it was. We had the same situation this week with the analysis of the spam detection values in the header of an email, they were not public either. This is really a pity, it was looking so good...

Bye Tom

[Marcos 5,070]

VBA/TrojanDownloader.Agent.MUV is a detection of a specific malware. If malware is slightly changed, repacked or whatever, the detection name remains because it's the same malware although not 100% binary identical.

If you provide me with a particular file, I will be able to tell when exactly the detection was added. Even then, it would be different for those who use EDTD since it can recognize new malware (and especially that in malicious documents) almost instantly without any delay.

[pronto 6]

3 minutes ago, Marcos said:

VBA/TrojanDownloader.Agent.MUV is a detection of a specific malware. If malware is slightly changed, repacked or whatever, the detection name remains because it's the same malware although not 100% binary identical.

I understood. It would be interesting to know which versions of a virus are covered by which patterns and which version of the virus you are dealing with. This would help to understand what happened and help to take countermeasures.

I can remember earlier times where other vendors listed exactly if this or that DLL is found with a size of so many bytes, there is an infection, otherwise with certain listed sizes and version numbers they are unsuspicious original files, depending on the patch level. This way or something similar. This may be a bit much information but for those who need it, it is definitely invaluable.

But that's probably not a problem we are solving tonight... 😉

Bye Tom

[itman 1,659]

This is not 0-day malware although Eset detection log entry data might lead one to believe this is the case.

If you refer to the line titled "First seen here:", no information is present. Coupling this with the VirusRadar database detail for VBA/TrojanDownloader.Agent.MUV leads to the conclusion this is a new variant detected by Eset DNA signatures.

Are you stating that your border edge Exchange server which has Eset Mail Security installed (?) did not detect this malware?

Edited January 30, 2020 by itman

[pronto 6]

11 hours ago, itman said:

Are you stating that your border edge Exchange server which has Eset Mail Security installed (?) did not detect this malware?

Servus Itman,

yes, the email arrived on wednesday at 10:50, at that time the two internal mail servers had installed pattern 20750, the border edge mail server even had installed pattern 20751 for a few minutes. The two internal servers both found the virus at 15:01, half an hour after the update to pattern 20752.

Thx & Bye Tom

[itman 1,659]

15 hours ago, pronto said:

Servus Itman,

yes, the email arrived on wednesday at 10:50, at that time the two internal mail servers had installed pattern 20750, the border edge mail server even had installed pattern 20751 for a few minutes. The two internal servers both found the virus at 15:01, half an hour after the update to pattern 20752.

Thx & Bye Tom

VBA/TrojanDownloader.Agent.MUV appears related to macro detection which might explain this delayed detection after subsequent sig. update.

Case in point. A tester did find a 0-day .vbs script in the wild. Eset initially didn't detect on Win 7 until the script had run for a while. The script contained a packed obfuscated PowerShell script. Strongly suspect the PowerShell script would have been detected on Win 10 via AMSI pre-execution scanning. Anyway within a few hours Eset had a new full sig. specific to this .vbs script that detected it upon file creation.

However in your case, Eset subsequent detection was via an existing sig. detection which is odd. As noted above, Eset would usually great a new sig. for the detection. Since this VBA/TrojanDownloader.Agent.MUV  appears to be macro related, I am wondering if the initial non-detection has something to do with the way Eset File Mail Security is configured in regards to scanning of incoming Office based e-mail. Again, I don't believe Eset updated its existing sig, since this, as explained, is not something they normally do. However, macro sigs. might be an exception to this. This sounds right to me since macros are almost impossible to detect until they actually run within the context of an Office document/spreadsheet/etc..

Edited February 1, 2020 by itman

[itman 1,659]

Per Eset Mail Server documentation: https://download.eset.com/com/eset/apps/business/ems/exchange/latest/eset_emsx_7_userguide_enu.pdf  , are you scanning macros?

[Marcos 5,070]

4 minutes ago, itman said:

Per Eset Mail Server documentation: https://download.eset.com/com/eset/apps/business/ems/exchange/latest/eset_emsx_7_userguide_enu.pdf  , are you scanning macros?

This is actually not about scanning macros, documents with macros are scanned like any other file. A transport agent rule can be created to take a specific action on emails that contain a document with macro in attachment regardless of whether it's detected or not.

[pronto 6]

1 hour ago, Marcos said:

This is actually not about scanning macros, documents with macros are scanned like any other file. A transport agent rule can be created to take a specific action on emails that contain a document with macro in attachment regardless of whether it's detected or not.

Servus Marcos and Itman,

we have discussed this issue with our management, even though we have deactivated the execution of macros in Microsoft Office by group policy but it would be worse if we would forward such an e-mail to a business partner who does not have that many security levels available. This was our biggest concern in this particular case. Our management has classified this as a serious incident, not least because an encryption Trojan recently caused a business partner to suffer significant financial damage.

Our preferred configuration would be to remove all macro code from every Office document but still deliver it, but of course if no virus was found or the email was not detected as spam. That's how we had configured it earlier and had actually made good experiences with it.  But ESET can't do that in this form as far as I know. But it would be great if it could.

If this is not possible, we would be interested in a procedure to collect data about how many Office documents with macro code we receive and how many of them might have been detected as false positives, if we decided to generally reject such documents in a later step.

This was the result of our meeting with our management. Do you have any ideas on how we could best solve this? Any suggestions would be welcome.

Thx & Bye Tom

[itman 1,659]

3 hours ago, Marcos said:

A transport agent rule can be created to take a specific action on emails that contain a document with macro in attachment regardless of whether it's detected or not.

Will this detect obfuscated macro code as noted here: https://null-byte.wonderhowto.com/how-to/create-obfuscate-virus-inside-microsoft-word-document-0167780/ that will also bypass Office built-in macro checking?

Quote

This would work, however, from my testing, if you leave the code un-obfuscated, Microsoft Word provides an extra warning to the user which won't show up if the code is obfuscated:

Plus, anybody could easily glance at the macro for a second and tell that it is malicious. That's where obfuscation comes in.

 

 

Edited February 1, 2020 by itman

[Marcos 5,070]

Have you already tried ESET Dynamic Threat Defense to see how it would increase the effectiveness of blocking malicious attachments? I assume there should be no problem providing you with a trial license.

Quarantining emails with attachments containing Office documents with macros is not a viable solution?

[itman 1,659]

Then there are other methods to hide macros such as password protected Excel macros. Eset might be able to detect the existence of the macro but could not scan it other than opening the attachment in a sandboxed Excel environment.

So I agree with @Marcos that EDTD or temporarily quarantining Office mail based files containing macros with further secure sandbox analysis, appear to be the most viable solutions.

Edited February 1, 2020 by itman

[itman 1,659]

I also don't understand this concern:

59 minutes ago, pronto said:

but it would be worse if we would forward such an e-mail to a business partner who does not have that many security levels available.

This can be accomplished by simply opening those e-mail on your own installation and then forwarding the e-mail to your partners. Are you functioning as some type of e-mail proxy provider to these partners? Their e-mail is sent to you and you then forward it unread to them?

Edited February 1, 2020 by itman

[pronto 6]

42 minutes ago, Marcos said:

Have you already tried ESET Dynamic Threat Defense to see how it would increase the effectiveness of blocking malicious attachments? I assume there should be no problem providing you with a trial license.

Quarantining emails with attachments containing Office documents with macros is not a viable solution?

Servus Marcos,

ist the ESET Dynamic Threat Defense feature included in an ESET Secure Business license? It isn't listed in the feature list of any product:

 

[Marcos 5,070]

It's a separate product (service), currently available for bigger customers. It's likely that a light version of it will be available also to smaller customers later. As I wrote, I assume it should not be a problem to provide you with a trial license next week.

[itman 1,659]

Here's what I do to "bullet proof" by e-mail client.

1. All active content is disabled.

2. E-mails display in text only format.

3, Attachments are not displayed in-line meaning they don't open automatically when the e-mail is opened.

Edited February 1, 2020 by itman

[itman 1,659]

Here's one way to test e-mail content using Win 10 sandbox feature: https://blog.tallan.com/2019/10/18/testing-suspicious-emails-using-windows-sandbox/

Note that I believe Win 10 sandbox feature is still a bit buggy. Also each e-mail would have to be manually tested.

[itman 1,659]

I am still puzzled over the events that transpired in this incident. @Marcos can interject as he sees fit.

Taking everything at face value as to what has been posted, I am left with the following assumptions. When the e-mail was scanned by Eset upon arrival at the border edge e-mail server, something suspicious was detected and the e-mail submitted to LiveGrid for analysis. Eset subsequent server analysis determined that indeed the e-mail was malicious and updated an existing sig. to reflect this new malicious code. Then at next scheduled update time, this update sig, was pushed to all mail servers at the OP's installation. The e-mail now residing on the internal mail servers was detected by the updated sig. and promptly quarantined.

So is not the solution here to offer an option to immediately quarantine all LiveGrid submitted e-mail? Then auto release from quarantine the e-mail when Eset servers have reached the decision that the e-mail is benign? I assume this would require that existing quarantine processing be updated to show a pending analysis status. All e-mails in this status would be "locked" from user action such as removal/deletion from quarantine. In other words, EDTD like behavior less the quick response time offered from EDTD. After all, this is e-mail and a few hours delay in access to it should not be a critical concern.

[Marcos 5,070]

I will recap what happened. The malware was first seen on Jan 29, 10:45. A detection was created 15 min. later and was included in update 20752 which was released at about 13:50. Your ESET for Exchange updated to this engine at 14:22. So there was a gap of about 3,5 hours. With EDTD, the malware would have been recognized at about 11:00 or even sooner, depending on the behavior of the malware.

[itman 1,659]

I will also add that macro based attacks are becoming increasingly more sophisticated. Case in point is this recent Win 10 AMSI bypass one detailed in this Kaspersky blog posting: https://threatpost.com/advanced-obfuscation-info-stealing-campaign/152468/

The only 100% way to protect against macro based malware is to disable macro processing in all applicable MS office software. Also ensure that sandbox protected view mode is enabled in these products. Finally, ensure all employees are properly trained on how to respond from opened e-mail attempts to override these protections if not they are not permanently disabled via Group Policy/SRP means.

-EDIT- To the above, add this "tidbit" many are not aware of in regards to older MS Office Pro versions.

I use Office 2010. If this version is installed in default 32 bit mode, its apps will run in AppContainer mode. However if installed in 64 bit mode, the apps run at medium integrity level significantly decreasing your security protection capability.

Edited February 2, 2020 by itman

[itman 1,659]

Since I mentioned the Win 10 AMSI bypass above, here's a link to the details on that. Most notably:

Quote

Introducing AMSI_BYPASS2, the C# Version

With the new AmsiScanBuffer bypass approach determined, we made a new version of the bypass tool that does not require a native unmanaged dynamic-link library (DLL) to be loaded (as in the previous AMSI bypass). We converted the native unmanaged DLL code (that performs the memory patching) to a simple C# code that can be loaded by using the Add-Type Cmdlet or by compiling the C# code to a managed DLL and loading the compiled DLL to the PowerShell console via the [System.Reflection.Assembly]::LoadFile() function.

https://www.cyberark.com/threat-research-blog/amsi-bypass-redux/

And again courtesy of Kaspersky, is another malware employing this via MS Office macro use: https://threatpost.com/azorult-campaign-encryption-technique/152508/

Edited February 3, 2020 by itman