0xDEADBEEF

hmm didn't find this page. Thanks for the info! But just wondering if the UEFI scan will be subject to some hijack, since the firmware itself lies on lower level, will it be able to simply return the fake "normal" firmware?

Glad to see that ESET11 is finally available in multiple languages. Just wondering what's the fundamental changes compared to v10 (for both detection techniques and perhaps low level architecture/engineerings)? Also, can someone elaborate more about the UEFI scan/protect mechanism that is mentioned in blog several days ago?

In an IO bounded application, suppose copying a large set of files takes up 5% of CPU utilization without a security product. Now that with a security product, the CPU utilization is 30% due to realtime monitoring, but since the task itself is IO bounded, the time it takes compared to the baseline will not change much. This is a simple case that using a timer might fail to capture the extra utilization of a security product. In a heavily multi-threaded context, this will start to be an issue since there is no enough processing power headroom for extra realtime scanning task. If you look at VB100's CPU and Memory util evaluation, ESET's number is OK but not the best. Measuring the real resource utilization under multiple use scenario is a better metric. Actually, in a power-bounded scenario, the power doesn't even reflect the antivirus overhead. One needs to profile the energy consumption also to count in extra execution time overhead. I didn't see a comprehensive evaluation like this available online. Passmark eval's memory usage, but I am not sure if they count in the mem swap tricks some vendors use to create an illusion that their products are at least small in mem footprint. VB100 measures some CPU and DRAM utilization, but it is limited to idle and scan. Those web browser vendors actually do better job in this kind of evaluation. Like what Microsoft did for Edge. They profile GPU and CPU utilization to optimize the power consumption. https://blogs.windows.com/msedgedev/2016/06/20/edge-battery-anniversary-update/#53vsYzRc1K8CcPMB.97 One thing I can say for sure is that ESET is doing really well in computer standby scenario since last year. The generated sleepstudy report shows that ekrn consumes nearly 0 energy during idle. This is in contrast to some other products I have tested before, which are also among "good rankings" in AVC's performance test.

Large compilation task (e.g. compiling a gcc toolchain) under windows linux subsystem can easily raise ekrn CPU utilization and slow down the compilation process significantly, especially when compiled in multi-thread. Excluding the linux root folder in ESET settings ("C:\Users\Username\AppData\Local\lxss\*") will rosolve the issue. Could you take a look at this issue to see if it is expected or not? I think it is due to file monitoring. Disabling advanced memory scanner doesn't help.

This contrasts with AV-TEST's performance ratings on ESET products: https://www.av-test.org/en/antivirus/home-windows/ ESET is pretty lightweight usually, but under certain circumstances it is really performance hungry, which might explain the distinction between results of different 3rd party testers. I personally think AVC should at least do some profiling on memory (swapping) behaviors and CPU utilization, or do energy consumption analysis, instead of just using a timer to do the test.

reminds me of the talk Cylance gave in VB conf this year: https://www.virusbulletin.com/conference/vb2017/abstracts/have-you-scanned-your-bios-recently Plus this blog post, worth reading: https://www.cylance.com/en_us/blog/black-hat-vegas-where-the-guardians-of-the-bios-are-failing.html

Perhaps I missed something.. But I didn't find an option to auto select block/deny when there is a HIPS prompt (say, the anti-ransom module prompts a warning). If the game mode is enabled, seems the prompt is auto allowed by default. Can someone help me with this issue?

sure, will do. Thanks for the answer.

BTW, what are DNA and XDNA (and their differences)?

Thanks for the explanation. This explains why sometimes I can see few FPs in Generik detections but nearly none in Kryptik detections

Just out of curiosity, I noticed that the most common malware name assigned by ESET are "Kryptik" and "GenKryptik", with some letter suffixes. Is there any meaning associated with these detection name? What's the difference between these family names and ESET Generik.XXXXXX detections? I also saw sometimes for the same sample, with different ESET virus definitions, it will be detected in different names (one example I saw is the change from GenKryptik.AUBU to Kryptik.LAL), so perhaps there are some matching priority as new definitions are added to the database?

I noticed that for some samples, ESET detected it as Win32/Beh.A Is this sort of a generic behavior detection? since I didn't find it in the VirusRadar

Some interesting thing I saw today.. I gathered two malicious CCleaner samples and tested both ESET and Cylance. I tested their old snapshot with no internet (Sept.15, before the news reveals the truth) and the latest snapshot (both connected to the internet). So without any surprise, ESET and Cylance both failed to detect the malicious CCleaner in the old snapshot.. Latest ESET detected both samples without surprise. But interestingly, the latest Cylance only detected one of the two samples. What is more surprising is that, after I slightly modified the MD5 of the Cylance originally detected sample (by simply appending some zeroes at the end of the PE), Cylance no longer detect it. So this means their "unsafe" verdict is purely based on the hash blacklisting, at least on this CCleaner incidence This is a really awkward result for the next-gen solution perhaps, and perhaps this is the Achilles' Heel of statistics-based engine. When something malicious is embedded inside a benign software, it is likely to blind these engines. In addition, modifying the detection model to fit a minority sample is also hard. Using automated behavioral detection of CCleaner is also hard because the benign version also exhibits many suspicious activities. I start to see the difficulty of detecting this particular piece of malware here.

I don't think this can be absolute, although it can filter out most threats. If there are security flaws in the program you have whitelisted (say, flawed input check or weak dll check, and these can exist in very popular software you have to whitelist), this process/binary based identification will be in vain as long as the attack vector do not spawn separate entity. Exploit detection is still necessary. Plus, based on the CCleaner incidence recently... I think manually maintaining a whitelist can still be limited

Sounds interesting. I have seen AMSI for some times but didn't have a chance to have a detailed look into that. Two things I care about are: if "sandboxed", can it be reversely detected; how long/secure will it be "sandboxed" so as to avoid timing attack.

I am not sure how Kaspersky performs, but BD detected this at the first time. VT only shows scan results anyway, so I believe EMSI should have detected it before the signature is added. As of performance impact, things might not be that intuitive. Kaspersky and Bitdefender's system impact result is pretty good from AVC's test (well again, if you believe in 3rd tester results). And although ESET is pretty light in performance impact in most cases, it is eating up the CPU in tasks like IO intensive compilation or linux subsystem runs, perhaps due to its advanced heuristics. I have to exclude all linux work folders to recover the performance. So who impacts more? heuristic? or rule/scoring-based behavior hooking? I start to understand why AVTEST score ESET's performance impact as mediocre, which contrasts with AVC's "best" rating. So for mentioning AMS, I am pointing out a potential limitation of in-memory sig detection: regardless of other twisted tricks, it seems AMS has to keep its definition size small enough so as not to impact critical path in system performance. This means old malware sigs might be expelled out to fit in new ones. In such case, what if I reuse the old malware and obfuscate it to bypass initial scan? Will the new definition detect it in the memory? Things that bypass AMS will not likely to be captured by HIPS module anyway. I feel like this is a flaw of sig detection compared to a universal model (like BD's behavior scoring system). Of course, as I am not sure about the detailed concept of "sig" in AMS detection, correct me if my statement is wrong.

correct me if I were wrong... but AFAIK, vendors like Kaspersky or Bitdefender have automated behavior blocking. K has auto blocking + file backup for roll back purpose, while B (like its active threat control) is fully automated without any user input. I think ESET concerns more about FP perhaps. But both B and K have low FP in tests also (well, if one trust 3rd party FP evaluation) Another observation is, it seems the AMS detection feature is limited a very small set. It seems some old AMS detection features are being kicked out as the time goes on. Perhaps this is due to performance concern.

ransom SHA256: b3901e5a23ea0ce6d0b05533959ecd5446178680ab969edb4e3085a9f1c00683 Seems it is doing some antidebug tricks? (like parent process detection?). Anyway, ESET missed the sample Again, "next-gen" vendors (regardless of their potentially higher FP and less user base) catch this kind of sample first. Some "traditional" vendors block it by behavior blocking layer.

Yep, livegrid now blacklisted it

SHA256: 276c2887b3a9fd5265792be6a6d933b849d2d9707e1ce581dd84c1d283ed7169 Another ransom bypass both scan and AMS, with already 20 vendors in VT detected

I start to get frequent prompt of this today: seems the connection is initiated by the Microsoft's Onedrive.exe, is it an FP?

From my perspective, it is really really hard to distinguish ransomware from normal software (without proper use of a reputation system). A misused archive software can easily act much like a ransomware, imagining a user zipping a batch of photos in a document folder with password and delete original files. Ironically, some big vendors ransom protection are tuned to be sooo sensitive that even these legitimate software and actions will also be blocked and quarantined automatically. Current I just use custom HIPS file access rules to serve as the last defense against these attacks. But it is annoying. Users hate to be asked frequently and sometimes even if antivirus ask the question, users might still give the wrong answer. The default settings are merely a balance between security and usability for normal users.

No, I used win7 x64. Will add the smartscreen test once I get a proper win10 license. Hmm, is VoodooShield sort of anti-exec protection software?

Actually, I am more curious about ESET's attitude towards the detection of FlyStudio PUA.

Yes, I was a bit surprised when I saw ESET didn't even block this in the livegrid in a timely manner. My sandbox scored this sample malicious in the first run. This is pretty unusual as the malicious behaviors are very "explicit" and yet LiveGrid didn't respond as quickly as those Feodo samples mentioned below (still no detection until hours later). And interestingly, I have resubmitted the samples several times later, and every time it is scored the same (as very malicious, and captures the injection behavior). I indeed saw some anti sandbox feature in this sample though I have several other Feodo Botnet samples that ESET failed to detect, but after about 10~20 minutes, the LiveGrid start to block these samples (perhaps because the botnet protection detect the connection and trigger LiveGrid to block the sample).