Method of detection

[Tita314 0]

Hi everybody!

 

does anybody know the detection method of Antivirus?

I explain my question.

I have a chance to test anything i want with a solution that allows provide automatical "pentest". And i found out that ESET cannot detect infected file, if they are not active (according to a test solution method malware put on PC folder for a 2 minutes, and after it must be deleted). during 2 minutes ESET cannot detect malware.

So, that's why i have a question - is it a way, how ESET detect malwares - only when it is acctive?

[Marcos 5,070]

If the malware is known or is relatively similar to known malware, it must be detected either by web access protection upon download or by real-time protection when saved to the disk or upon execution. Then there are other post-execution protection HIPS-based protection layers that monitor the behavior of running processes, such as the Advanced memory scanner, Exploit Blocker, Deep Behavior Inspection and Ransomware shield that are effective against re-packed or brand new malware.

You can drop me a personal message with more details about the sample and provide the SHA1 hash or a download link as well as logs collected with ESET Log Collector from the machine (to check ESET's config and logs) as well as the procedure how you carried out the test.

[itman 1,659]

16 hours ago, Tita314 said:

according to a test solution method malware put on PC folder for a 2 minutes, and after it must be deleted)

Just how were the malware samples created on the test device? Were they for example stored in a password protected archive and this archive downloaded from the Internet, copied from external media, or copied from another device in the local network?

Edited October 11, 2020 by itman

[Tita314 0]

4 hours ago, itman said:

Just how were the malware samples created on the test device? Were they for example stored in a password protected archive and this archive downloaded from the Internet, copied from external media, or copied from another device in the local network?

The solution create special folder in which it puts examples of malwares. The folder is not archved or locked with password.

[itman 1,659]

4 hours ago, Tita314 said:

The solution create special folder in which it puts examples of malwares.

Eset scans files using normal and advanced heuristics at file creation time.

However, some malware may have obfuscated or encrypted code that will not reveal itself until process execution time. As @Marcosnoted, Eset has additional mitigations to scan for malware after it has uncloaked in memory. However, these are post-execution mitigations. 

Eset also has a subscription option named Dynamic Threat Defense: https://help.eset.com/edtd/en-US/overview.html that will perform a full cloud sandbox analysis on executable's prior to their actual execution. It can be optionally set to block process execution until full sandbox analysis verdict is rendered.

It also needs to be explored in more detail just how this "solution" is creating these malware samples in this special folder. For example, what makes this folder/directory "special' from any other folder created on the device? If this folder is locked by the OS for some reason, Eset can't access what is being created in it.

Edited October 11, 2020 by itman

[Tita314 0]

Ok, let me make it clear. We create folder on disk C, without any password or some actions to hide. After that the "solution" put malware samples in this folder.

So, AV doesn't detect them.  

what information can be useful to you to help us to  investigate with it?

[Marcos 5,070]

Please email the undetected sample(s) in an archive encrypted with the password "infected" to samples[at]eset.com and a link to this topic enclosed.

[itman 1,659]

4 hours ago, Tita314 said:

So, AV doesn't detect them.  

Did you verify that the samples are not detected on VirusTotal by Eset? Note that only static scanning is performed by VT; i.e. signature detection.

If the samples on not detected on VT by Eset, they won't be detected on file creation on the local device in all likelihood.

[Tita314 0]

The thing is , ESET knows all this malwares ( according to Virus total)

Hash of malware examples

SHA-256  bceaa25d38775cf8ba6c21e77d62a1ea204b37bda59a25c0a4a56b97d97f0da4
SHA-1  e19cfa4a0b5e886f715d1ed86d4798d9b95e8b11
MD5 f2e4ac5d86d1ccbc322746a0f4d03f36
 NAME 2018-08-21-downloaded-Word-doc-with-Macro-for-Hancitor_mail.doc

But as I find ESET cannot recognise files as "infected" untill:

1) it is not used in some process 

or

2) user dont expoite the folder with this malwares.

And I cannot understend why it is so? why AV allows existence of the infective files.

[Marcos 5,070]

No problem with detection of the file:

C:\test\bceaa25d38775cf8ba6c21e77d62a1ea204b37bda59a25c0a4a56b97d97f0da4 - VBA/TrojanDropper.Agent.AEP trojan

Documents are a special case. Did you have real-time protection enabled when the document was saved to the disk?

 

[itman 1,659]

I will also add that documents; i.e. .docx, files externally are downloaded on a device in commercial environments especially via client e-mail software download. Eset's e-mail scanner would be scanning these files as they are downloaded and upon attempted file creation on the local disk. There are real-time scan; i.e. ThreatSense, settings that control how e-mail files are handled.

As far as web mail .docx attachments, processing of these would be controlled via the browser in use. In most cases, this would entail the browser asking what process should open; let's say a .docx, attachment. I just ran the following test using Firefox.

I attached a Microsoft based .docx test file and e-mailed it to myself. Now this .docx file contains a macro that if allowed to run via Enabling Content, will spawn cmd.exe. Now there is no malicious or otherwise script associated with this activity. Hence nothing for Eset to detect. The test .docx file purpose would be to test for example, a user created Eset HIPS rule to detect a cmd.exe startup from winword.exe. When I opened this e-mail via web mail and then opened the attachment via browser asking to open using winword.exe, this attachment was not downloaded to the disk. All processing of this .docx file was done from the browser memory cache area.

-Correction- the macro did create a folder in my user temp directory. In a real malware instance, that folder would have contained the script the macro would have executed if cmd.exe child process creation would have succeeded. As such if Eset did not have a sig. for the specific .docx file, it would have detected upon script creation/execution if it had a sig. for that.

The bottom line here is it is imperative that malware samples be tested via the way they are normally delivered to a device.

Edited October 12, 2020 by itman

[Tita314 0]

So, i don say thay ESET is bad. I was suprised to see such a results, knowing that ESET shows best record in AV test and so on.

AV policy configuration is "max protection" ( so, there is continuous real-time protection). 

I hope we can solve this task and find what is the matter

[Marcos 5,070]

The file is detected, that's a matter of fact. The question is how the file made it to the disk; was it downloaded from the Internet or received by email? Was web access / email protection enabled? Was real-time protection enabled when the file was saved to the disk? These are questions that have not been answered yet.

[Tita314 0]

On 10/11/2020 at 4:17 PM, itman said:

Just how were the malware samples created on the test device? Were they for example stored in a password protected archive and this archive downloaded from the Internet, copied from external media, or copied from another device in the local network?

Marcos, I will send you a report, where all methods are described. 

we set the exception to the folder for the "Solution"  and its agents. I hope it will be more clear when you read the document.

 

[Marcos 5,070]

I'm not familiar with Cymulate but looking at some scenarios it can test behavior blocking, however, that will not tell anything about how a particular AV will perform in real life. The thing is these methods is just a very small portion of methods employed by ransomware. Moreover, detection is typically not triggered only when one suspicious operation is detected, otherwise the AV could produce a lot of false positives.

[itman 1,659]

Cymulate is a Enterprise class breech detection and automated pen-tester solution. It costs $$$$. Therefore, it is not in the class of many of the free web based ransomware simulators that Eset for the most part ignores since all their ransomware techniques are flawed and do not simulate a real ransomware attack.

Some info on Cymulate here:  https://azuremarketplace.microsoft.com/en-us/marketplace/apps/cymulate.cymulate-breach-and-attack-simulation?tab=Overview . This contains a number of links for further details on the product.

I really believe the problem here is how the software is being used.

Referring to the .docx sample mentioned, it is assumed it is an e-mail attachment containing malicious ransomware code. To realistically simulate this attack, an e-mail must be created with the .docx file attached. The e-mail must then be delivered to the installation's e-mail server. The e-mail must be accessed and downloaded to the endpoint device via e-mail client software. The e-mail must opened along with the .docx attachment. Lastly, the use of macros must be enabled and allowed for the MS Word document.

A detection of the malicious .docx can be had at any off the above steps. However, Eset Endpoint protections would only be applicable when downloading the e-mail to the endpoint device via e-mail client software. If not detected then, it is a "mixed bag" if Eset detections would be had for any malicious code running from the embedded macro code.  A lot would depend of if the code was known to Eset. If not, then how the malicious code was run and the encryption code deployed.

Again, this .docx file is detected by Eset at VirusTotal.  This implies;

1. The way Cymulate is being used to test this file is not being done properly.

2. The endpoint device where Eset is installed is not properly configured to scan e-mail via its built-in client e-mail protections.

Edited October 13, 2020 by itman

[Marcos 5,070]

Could you confirm that no exclusions were enforced and real-time protection was enabled all the time while the test was running? Could you also try disabling Smart optimization in the real-time protection setup if it makes a difference?

[itman 1,659]

I will also add this comment in regards to detection upon file creation on a device. It is problem done with many amateur  pen-testers.

The malware samples need to be loaded to an Internet accessible file sharing service or equivalent. The samples then downloaded from that file sharing service. If the samples already exist in some fashion on the device's disk prior to testing, there is a high likelihood that they won't be properly detected by the security product being tested. This has happened repeatedly by amateur testers in the Eset forum.

The exception to the above would be when testing for malware detection from external media devices.

The other legit resident local malware test scenario would be testing for file share base malware. Assumed here is there is an unprotected device; e.g. Win XP, somewhere on the local network that is infected with malware. 

[peteyt 393]

5 hours ago, Tita314 said:

Marcos, I will send you a report, where all methods are described. 

we set the exception to the folder for the "Solution"  and its agents. I hope it will be more clear when you read the document.

 

Sorry I'm maybe reading this wrong as I've just skimmed through the posts but you mentioned exception which makes me think the malware was put into an exception to begin with.

I could be reading this wrong but I've seen a lot of YouTube tests doing things like this - They put an exception on a piece of malware then remove it - the problem is that the exception shouldn't be there - in a real life scenario there would be no exception and possibly esets web protection and other techniques would detect the malware depending on how it was delivered.

[Tita314 0]

I would like to add about cymulate and AV.

 

No matter, how much does it cost, it has a special mode to detect how AV works. The first part of the test (the behaviour analysis) ESET passes excellent. But with the second one - smth goes wrong. Because I know exactly, that ESET knows this malware, and know more signaturs then another testing solution. 

I want ESET helps me to produce the second part of testing according to thier oppotunities. To proove thier high results of independent labs. 

It will be great if ESET have an hour to investigate this case with me.

 

And we can publish the true results. 

Edited October 13, 2020 by Tita314

[itman 1,659]

There's a way to get to the bottom of this.

Send the .docx file sample, the one Eset detects at VirusTotal, to a zipped folder using Win Explorer. Then private message me here in the forum with the zipped file attached.

In reality if Eset is properly configured on your device, it should detect the .docx file when moved to the zipped folder.

[itman 1,659]

Found a sandbox analysis of this .doc malware here: https://app.any.run/tasks/38c472c8-7e2f-421e-9b98-3fe62cfcce74/ .

Additional analysis here: https://www.malware-traffic-analysis.net/2018/04/18/index2.html

Actual posting of someone infected by the bugger:

Quote

I received a email that I got a fax message. I opened the link and there was a word doc with macros but no content.

Too late I entered the first part of the link (http://naemura-fuel.co.jp) in google and found the following: http://www.malware-traffic-analysis.net/2017/02/07/index.html

Since in this description is exactly decribed what I did, I am infected with hancitor and mypony, I think.

https://www.bleepingcomputer.com/forums/t/639505/downloaded-worddoc-with-hancitorpony-malspam/

The any.run analysis reveals that the malicious .doc file was dropped to the C:\Users\Admin\ Temp directory. Then it appears winword.exe was run via script, whatever, with the command line options pointing to the malicious .doc file.

Additionally, the any.run analysis shows the initial dropper might be fax software based since a .cvr file is referenced first in the analysis but it noted it did not have a copy of that file.

Edited October 13, 2020 by itman

[itman 1,659]

Per the above any.run analysis, refer to the below screen shot. There is front end processing that in effect "staged" this malware to run on the targeted device. This front-end processing in this attack as follows;

1. It created a file that externally would appear to be the MS Word default template, Normal.dotm, which controls how blank documents are displayed in Word: https://support.microsoft.com/en-us/office/change-the-normal-template-normal-dotm-06de294b-d216-47f6-ab77-ccb5166f98ea . It embedded the malicious macro code there. -EDIT- Actually what was created  in the Microsoft template directory was a application/octet-stream file named ~$Normal.dotm:

Quote

A MIME attachment with the content type "application/octet-stream" is a binary file. Typically, it will be an application or a document that must be opened in an application, such as a spreadsheet or word processor. If the attachment has a filename extension associated with it, you may be able to tell what kind of file it is. A .exe extension, for example, indicates it is a Windows or DOS program (executable), while a file ending in .doc is probably meant to be opened in Microsoft Word.

https://kb.iu.edu/d/agtj

2. It then copied the ~$Normal.dotm file to the C:\Users\Admin\ Temp directory saving it as .doc file.

3. It then opened this .doc file via script execution;

C:\Program Files\Microsoft Office\Office14\WINWORD.EXE" /n "C:\Users\admin\AppData\Local\Temp\2018-12-11-downloaded-Word-doc-with-macro-for-Hancitor.doc

Bottom line - the malicious payload was actually created on the targeted device and not downloaded externally.

-EDIT- Also of note and significant is the .dotm and the .doc files are not the same although care was taken not to change their file sizes:

Edited October 14, 2020 by itman

[itman 1,659]

I did a bit more research on this Hancitor trojan sample the Cymulate pen-tester tool is using.

This sample dates to the last half of 2017 and the first half 2018. Note that Hancitor has been around in some fashion since 2014. Attackers just keep find new ways to deploy it.

This specific sample exploited a vulnerability that existed in MS Word MIME processing; i.e. Active-X, that was discovered in the last half of 2017. Microsoft promptly patched the vulnerability and this type of Hancitor attack dropped off rapidly. Again, note that this attack would only succeed on an unpatched MS Word device.

This particular attack is a multiple stage event.

A phishing e-mail is sent to the target. This e-mail when opened, stages the first phase of the attack by creating the macro based MIME. Also note that if the target had disabled active content in MS Word, this attack would have failed at this point.

Stage two occurs when the user clicks of the phish link in the e-mail. This connects to the attacker's C&C server which promptly downloads basically the same original MIME minus the macro code to the user's temp directory as a .doc file. The attacker then runs this download by starting MS Word remotely. When this .doc file opens, I believe cross-scripting was employed to run the macro base MIME.

Note that the above is a rough approximation of the attack. More files are being dropped/created/modified including an .exe in the user temp directory; registry mods. being made; etc..

This gets us to what Cymulate is simulating here. This specific Hanictor attack will fail on a patched device. It also requires that an e-mail be received and opened that contains the macro laced MIME.

Edited October 15, 2020 by itman

[Tita314 0]

So, that's the point. I try to find, for example, such a configuration of settings of AV, that can react to the threats to ESET's capabilities!