Interesting Samples

[Marcos 5,277]

9 minutes ago, itman said:

I must say it took a very long time for the AV's to create a sig for this. I checked yesterday and still no one was detecting it by sig..

We added a detection in update 16011 yesterday morning. In LiveGrid it was blocked at about 8:10 CEST. It wasn't blocked earlier because the file failed to run 6 times out of 10.

[itman 1,749]

17 minutes ago, Marcos said:

It wasn't blocked earlier because the file failed to run 6 times out of 10.

Did it have a built-in "kill switch?" If it was checking for Eset and shut down because of it, that is all that is needed.

[0xDEADBEEF 43]

9 hours ago, itman said:

I must say it took a very long time for the AV's to create a sig for this. I checked yesterday and still no one was detecting it by sig..

Per VT:

 

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).

 

[0xDEADBEEF 43]

9 hours ago, itman said:

I must say it took a very long time for the AV's to create a sig for this. I checked yesterday and still no one was detecting it by sig..

Per VT:

 

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

[itman 1,749]

9 hours ago, 0xDEADBEEF said:

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).

I believe you don't test using Win 10? If this sample was a .exe which I assume it was, what I would like to verify is if Win 10 native SmartScreen detected it as "unknown." In previous testing I have done if LiveGrid shows an unknown status for the process but allows the process to run, native SmartScreen will also trigger an  "unknown" status alert.

In any case, I am now using the free vers. of VoodooShield as supplemental anti-exec protection. Can't say I am impressed with the design of the product but it is effective at detecting any new non-whitelisted process startup.

[0xDEADBEEF 43]

10 hours ago, itman said:

I believe you don't test using Win 10? If this sample was a .exe which I assume it was, what I would like to verify is if Win 10 native SmartScreen detected it as "unknown." In previous testing I have done if LiveGrid shows an unknown status for the process but allows the process to run, native SmartScreen will also trigger an  "unknown" status alert.

In any case, I am now using the free vers. of VoodooShield as supplemental anti-exec protection. Can't say I am impressed with the design of the product but it is effective at detecting any new non-whitelisted process startup.

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?

[itman 1,749]

On ‎9‎/‎3‎/‎2017 at 8:42 PM, 0xDEADBEEF said:

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?

Also, Win 8/10 native SmartScreen only effective if the malware downloaded from the Internet i.e. it has the "Mark of the Web" associated with it e.g. browser or e-mail download. Since I suspect you're "harvesting" your samples from non-direct download sources, most will not have the MOTW associated with them.

VoodooShield is an anti-exec "for the masses." Extremely easy to use with a difficultly level one notch up from nob skill level.

Edited September 5, 2017 by itman

[0xDEADBEEF 43]

SHA256: 276c2887b3a9fd5265792be6a6d933b849d2d9707e1ce581dd84c1d283ed7169

 

Another ransom bypass both scan and AMS, with already 20 vendors in VT detected

[itman 1,749]

4 hours ago, 0xDEADBEEF said:

SHA256: 276c2887b3a9fd5265792be6a6d933b849d2d9707e1ce581dd84c1d283ed7169

 

Another ransom bypass both scan and AMS, with already 20 vendors in VT detected

Eset still not detecting it by signature. But as discussed previously, Eset takes a while to develop a sig.. Hopefully, it is now being blocked via LiveGrid blacklist which wouldn't show on a VT scan.

Test again and see if LiveGrid alerts on it.

[0xDEADBEEF 43]

32 minutes ago, itman said:

Eset still not detecting it by signature. But as discussed previously, Eset takes a while to develop a sig.. Hopefully, it is now being blocked via LiveGrid blacklist which wouldn't show on a VT scan.

Test again and see if LiveGrid alerts on it.

Yep, livegrid now blacklisted it

[0xDEADBEEF 43]

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.

Edited September 19, 2017 by 0xDEADBEEF

[itman 1,749]

1 hour ago, 0xDEADBEEF said:

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.

 

Kaspersky has a "System Watcher" feature that monitors for ransomware and exploit activities. It additionally does auto file backup to directories ransomware attacks. Believe its only available in the Endpoint ver. and is not enabled by default due to the alerts it generates.

I do believe "you're beating a dead horse" in regards to Eset ever deploying like feature. They just don't buy into the concept of user decision via alert.

Eset allows the user to create manual HIPS rules to do the same if the user so desires. They also have recommended rules for their endpoint users for ransomware protection and the like. I use them but have added additional processes to them in regards to child process startup and the like as ransomware attacks evolve. 

[0xDEADBEEF 43]

5 hours ago, itman said:

I do believe "you're beating a dead horse" in regards to Eset ever deploying like feature. They just don't buy into the concept of user decision via alert.

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. 

Edited September 19, 2017 by 0xDEADBEEF

[itman 1,749]

2 hours ago, 0xDEADBEEF said:

vendors like Kaspersky or Bitdefender have automated behavior blocking

Yes, they do. But as your VT screen shot notes, BD didn't detect it. Nor do I believe the Kapersky detection was from their behavior blocker. Additionally, Emsisoft which has one of the best behavior blockers also didn't detect the sample.

-EDIT- Here's a .pdf of Kaspersky System Watcher: https://media.kaspersky.com/pdf/Kaspersky_Lab_Whitepaper_System_Watcher_ENG.pdf. It interfaces with the behavior blocker. Also, it doesn't just backup files, it takes periodic system snapshots and can rollback when malicious activities are detected.

You can search the web on numerous issues with it; mainly serious impacts on system performance. Another one is it doesn't "play nicely" with a lot of software; especially if you run it in auto mode where it makes the decisions on what to allow or block.

Quote

it seems the AMS detection feature is limited a very small set.it seems the AMS detection feature is limited a very small set.

AMS is signature based. If Eset doesn't have the sig., it won't detect it in memory.

Edited September 19, 2017 by itman

[0xDEADBEEF 43]

2 hours ago, itman said:

Yes, they do. But as your VT screen shot notes, BD didn't detect it. Nor do I believe the Kapersky detection was from their behavior blocker. Additionally, Emsisoft which has one of the best behavior blockers also didn't detect the sample.

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.

Edited September 20, 2017 by 0xDEADBEEF

[itman 1,749]

On ‎9‎/‎19‎/‎2017 at 8:05 PM, 0xDEADBEEF said:

Kaspersky and Bitdefender's system impact result is pretty good from AVC's test (well again, if you believe in 3rd tester results).

I can't comment on BD's BB protection. Pertaining to Kaspersky's System Watcher protection, it is disabled by default on its retail versions as far as I am aware off. As such, tests of performance on those versions will show a favorable result.

As far as Eset's AMS goes I am posting Eset's write up on it below. The thing to note is not everyone who uses Eset is running Win 10. Win 10's AMSI feature performs for all practical purposes part of what AMS does; sandboxing encrypted, packed, and obfuscated scripts while they "unmask" in memory. Once unmasked, the script can be examined by AV's realtime scanners. Appears Eset's AMS scanning extends AMSI protection to examine all code in a processes memory after it "unmasks." As Eset notes, AMS is a post-execution mitigation which means not all malware might be detected that executed prior to AMS detection. The important thing to note is realtime hueristic analysis is performed prior process execution via sandboxing;  AMS analysis after that point.  Appears Eset's AMS is monitoring virtual memory API calls.
 

Quote

Advanced memory scanner

Advanced Memory Scanner is a unique ESET technology which effectively addresses an important issue of modern malware – heavy use of obfuscation and/or encryption. To tackle these issues, Advanced Memory Scanner monitors the behavior of a malicious process and scans it once it decloaks in memory.

Whenever a process makes a system call from a new executable page, Advanced Memory Scanner performs a behavioral code analysis using ESET DNA Detections. Thanks to implementation of smart caching, Advanced Memory Scanner doesn't cause any noticeable deterioration in processing speeds.

Moreover, there is a new trend in advanced malware: some malicious code now operates "in-memory only", without needing persistent components in the file system that can be detected conventionally. Only memory scanning can successfully discover such malicious attacks and ESET is ready for this new trend with its Advanced Memory Scanner.

Ref.: https://www.eset.com/int/about/technology/

Edited September 21, 2017 by itman

[itman 1,749]

@0xDEADBEEF there is a way to achieve absolute 0-day protection using Eset. Simple switch the HIPS to training mode for a while to learning all your apps and system processes. Then switch to either Policy or Interactive mode. In Policy mode, any app for which no existing HIPS rule exists will be auto blocked execution. In Interactive mode, an alert will be generated when no existing HIPS rule exists.

Obviously when installing new software you would have to first switch back to training mode. This is a "gotcha" for me since I trust no software these days. I would switch to Auto or Smart mode while installing, run the software for a while to ensure all is OK. Then switch to Training mode and run the installed software executing its functions. Then switch back to Policy or Interactive mode.

[0xDEADBEEF 43]

3 hours ago, itman said:

Win 10's AMSI feature performs for all practical purposes part of what AMS does; sandboxing encrypted, packed, and obfuscated scripts while they "unmask" in memory. Once unmasked, the script can be examined by AV's realtime scanners.

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.

Edited September 22, 2017 by 0xDEADBEEF

[0xDEADBEEF 43]

2 hours ago, itman said:

there is a way to achieve absolute 0-day protection using Eset. Simple switch the HIPS to training mode for a while to learning all your apps and system processes

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

Edited September 22, 2017 by 0xDEADBEEF

[itman 1,749]

11 hours ago, 0xDEADBEEF said:

I don't think this can be absolute, although it can filter out most threats.

My point of reference was preventing any non-whitelisted app from running. If a whitelisted app has a vulnerability, it can be exploited. Most exploiting is done against Internet facing apps such as browsers, .pdf readers, and e-mail clients. Plus Eset has exploit protection that is not conditioned by an particular HIPS mode setting.

[peteyt 396]

8 hours ago, itman said:

My point of reference was preventing any non-whitelisted app from running. If a whitelisted app has a vulnerability, it can be exploited. Most exploiting is done against Internet facing apps such as browsers, .pdf readers, and e-mail clients. Plus Eset has exploit protection that is not conditioned by an particular HIPS mode setting.

My knowledge is limited but would a whitelisting program have caused issues with the ccleaner incident e.g. because it is whitelisted it could ignore malicious activity

[itman 1,749]

1 hour ago, peteyt said:

My knowledge is limited but would a whitelisting program have caused issues with the ccleaner incident e.g. because it is whitelisted it could ignore malicious activity

Actually the issue is running any installer from a trusted app.. Using a HIPS or any anti-exec for that matter, it would have to be switched from policy or interactive mode to normal mode in the case of a HIPS or the anti-exec disabled to allow the installation to proceed unimpeded.

An infected installer from a trusted app that contains a backdoor will not be detected by an security solution I know of unless a previous signature has been developed for the backdoor. Of course for the signature to be created, the backdoor has to be discovered.

The point to note is all a backdoor does is establish a remote connection. That type of activity would be normal for any app that does auto updating for example. Additionally, the backdoor remote connection might not be established for days, weeks, or in a few documented cases, years later.  

Edited September 22, 2017 by itman