0xDEADBEEF

MSE is indeed impressive with their new cloud system. It blacklist threats very quickly with recent updates. But it also generates way more false positives. I personally tend to interpret the FP test in such 3rd party test as: if one product performs poorly in such FP test, it is indeed bad (and there is actually a sensible gap betwen 1~2 FPs and 4~5 FPs in such test when using the product in real life). On the other hand, if one product performs well in such FP test, it doesn't necessarily mean it is indeed low in FPs in real life. For some "low FP" product in such test, one can easily make it generate an FP using simple tools and innocent code (like hello world). And for some static ML engines with low FPs in such test, one can easily trigger an FP by randomly padding zeroes and ones at the end of a benign file. Such product is susceptible to "pool pollution" attack and can be bypassed with clever social engineering. So there is a trade off here: you can do conservative detection in favor of less FPs, and leave aggresive detection to IT administrators; or you can be more aggressive in detection and optimize 3rd party FP test scores using certain white samples in the training set (e.g. a majority of AVC's FP test samples are software in top download category from software distribution sites). But if the optimization in the latter case is good enough to suppress FPs in real life is questionable There is no free lunch here, and my personal experience indicates that ESET tend to favor less FPs over a more aggressive detection in consumer products.

True. Originally I thought it was for accelerating the realtime memory monitoring, later found out it was not (it can hardly be the case due to the memory coherence issue across CPU and GPU domain). But I think it might be helpful for accelerating yara-like string matching workloads. Interestingly, they only talked about offloading the work, but barely talked about the runtime benefit.

Apparently Intel's GPU accelerated memory scan is on all kinds of tech news today... Interestingly, the scanner they demonstrated is also called AMS (accelerated memory scanning) Engine https://www.intel.com/content/www/us/en/security/hardware/threat-detection-technology-demo-video.html Though this is idea is neither exciting nor new, and I don't know what ESET's detection algorithm is, it'd be interesting to see if ESET will adopt this in future products

Yes, this one is a bit tricky from my view because it doesn't show many suspicious behaviors (not a installer anyway), more of a social engineering malware. Another sample: e728ff3f0a1a3f1658c6c9d8757c10eb9981dc4cbb9c0901d5124ffe46b7f47d I was amazed by how some vendors were able to detect this at the very early phase, if you are able to see the scan result on VT at different time points. Of course this might be simply due to the fact that some vendors collect samples from VT but ESET (seems) doesn't... Collecting such sample from user computer seems hard because petya immediately destroys the endpoint. Some new observations in the later post

Seems to me there are certain malware types that always fall in ESET sample collection's "long tail", i.e. they can be kept undetected for days unless someone manually submit them to the ESET viruslab. For example, the sample SHA1: AA32D03E383A9C843DBA9E591321858349127790, apparently a password stealer, appeared a day ago and now around half of the engines on VT detected it. However ESET didn't detect it even for now (the PUA detection doesn't count). From other detection names, apparent some are on the aggressive detection side though

I think so. Though I am not an autocad user, some answers on the Internet suggested that mnl is a lisp script file that will be autoloaded when load other files with the same name: hxxp://help.autodesk.com/view/ACD/2017/ENU/?guid=GUID-E65A2A24-CFF7-4AB6-95DD-FFEF802846F8 (see "Table: Automatically loaded LSP files")

https://knowledge.autodesk.com/search-result/caas/CloudHelp/cloudhelp/2015/ENU/AutoCAD-AutoLISP/files/GUID-3B8EDFF1-A130-434F-B615-7F2EC04322EE-htm.html I think this article makes it clear that both lsp and mnl may contain AutoLISP language.

I don’t think ams or other layer will detect this because the particular sig seems to be extracted on the lisp script level. I also tried to load the mnl using autocad and no detection was shown, as I expected. Since I’m not familiar with CAD malware, I might be wrong about eset detection mechanism of cad virus here.

that image... an easter egg or april fool's joke?

I was wondering if this can become a vulnerability. The virus distributor can simply use another extension to avoid the file being detected... Other vendors do not have the same issue on this specific sample. And since I don't have many other CAD malware samples, I am not sure if the same can happen on other CAD malware

Recently I found a sample with *.mnl extension that cannot be detected by ESET scan. However, when I change the file extension to *.lsp the scan engine detects it as ALS/Bursted.AD virus. Is this expected? Both are valid CAD extensions.

Just out of curiosity... Is there a reason that ESET didn't participate in recent VB100's RAP test? The latest one for ESET was on 2017-04.

Mine is a Thinkpad X1 Tablet with core m5-6y57 processor. The official requirements for modern standby as I remembered are 1) network adapter with pattern match capability, generally intel adapters >= AC7260 2) soldered memory module 3) firmware support. That is to say, most mainstream windows 10 tablet should support modern standby and may reproduce the issue I mentioned (e.g. Microsoft Surface Pro, hp elite x2 1012 g1, thinkpad tablet...). One can press the power button when the tablet is on to enter the "modern standby" mode. During this mode, the wifi adapter is still connected so the tablet can still get push notification, but the machine will work in low power mode so battery drains much slower. The official power recommendation is <5% battery drain after a night of sleep. Though UWP activities can be managed by Windows to save power, other win32 application may frequently wake up the machine in the background and drain excessive battery. A sleep study report entry will be generated for each modern standby session that is roughly >10 mins. So one can run "powercfg sleepstudy" as admin after a standby session to export the power consumption stats and diagnose the source of battery drain. And yes, I will also use the support system to generate a ticket.

It is equivalent to windows 10 laptop with an extra low-power state. Many AV vendors didn't quite follow Microsoft's guideline for modern standby and have battery issues more or less. ESET Endpoint Security performs quite well (nearly no extra battery consumption), but ERA Agent is problematic. I sincerely hope this issue can be addressed.

For Windows 10 tablets that support Modern Standby, seems that the ERA Agent significantly drains more battery during the computer standby, even with reporting interval adjusted to a large value (e.g. per 2 hrs) Using system built-in sleep study tool, I compared the standby power consumption without/with ERA Agent: In usual cases, the reference tablet consumes about 458mW during the standby, and HW/SW idle rates are >90% With ERA Agent installed, the draining rate increases by more than 100%. The HW idle rate is only about 19%. The red "SoC Subsystems" usually indicates high processor activity during computer standby. Is there any fix or workaround to address this issue?

The only difference is I selected "Exclude from detection" while the video has "Exclude signature from detection" selected Selecting "Exclude from detection" will add a rule specifying both the path and the threat type, while selection "Exclude signature from detection" specifies the threat type only. If I select "Exclude signature from detection", the exclusion works I also tried to modify the working rule generated by selecting "Exclude signature from detection". I tried to modify the path wildcard "*" into a specific path like "D:\*" and the exclusion no longer works. Generally I feel like the exclusion will work if you specify either the path or the threat type, but will not work if you specify both. Let me know if you need more information.

OK so I successfully reproduce it on another machine running the same EIS version on same type of system (Windows 10 x64). My steps: 1) disable EIS and download bitcomet installer from official website 2) enable EIS protection, copy the installer to some path (in my case, D:\c\bitcomet_setup.exe) This will trigger ESET yellow prompt 3) select "Exclude from Detection" and click ignore A rule is confirmed to be added to the exclusion list with correct path 4) simply right click the file again, the yellow prompt shows again Detection log: The similarity of the two machines I reproduced the issue is that they both run ESET upgraded from a previous v11 version, instead of a fresh install. As indicated by the original author of this thread, he/she got rid of this issue after a fresh reinstall. So perhaps this is a factor you need to consider.

well, the entry shown in the attached screenshot is the one created by the yellow alert window. But I still get yellow prompt after adding this exclusion

I can confirm this issue on version 11.0.159.0 EIS if you specify both the path and threat type (like the one auto-generated by selecting exclude threat in the threat prompt), the exclusion will not work if you only specify the path (enable "exclude all threats"), the exclusion will work

Interesting.. this make me wondering why my updated ESET at the time didn't get Packed.VMProtect.M verdict (it's not on virustotal either) BTW, RiskWare.GameHack.CB means it is not doing actual damage to the system as typical malware (categorized into PUA)?

Are you referring to the sample: 295c16a5179255058c98d35b6915bf963e47f0c76406bf3ffb96288381fb4bf2 ? At least at the time I posted this thread, it is not detected as any threat (I've turned on PUA and suspicious detection) upon a scanning. The observation is that running it will have AMS detected one dropped dll in memory as SMSBomber.L, but there are still some side effects remaining.

I have uploaded the sample (filename is the SHA256 hash), let me know if you need more info In addition, I have uploaded another sample with SHA256 hash: 0b22c637cdd4da733aa159a0e4d754c35d94b01ec98d37e6c04324eb5f545de0 Thanks

SHA256: 295c16a5179255058c98d35b6915bf963e47f0c76406bf3ffb96288381fb4bf2 the file is too large to be submitted through email

could you elaborate more on this?

What are these acronyms?