Jump to content

0xDEADBEEF

Most Valued Members
  • Posts

    361
  • Joined

  • Days Won

    3

Posts posted by 0xDEADBEEF

  1. I think ESET's lightweight is from dynamic binary translation and extensive caching and whitelisting.

    Generally in-product sandbox (and heuristics) can hardly be lightweight as there are pre-exec unpacking analysis. However, with some engineering effort, one can optimize for common cases. Most users will not generate tons of new binary/archive in a short period of time, therefore by skipping known good files, the performance impact can be reduced significantly. I noticed ESET recently has further optimization on this by caching the DBT-ed data of binary to further accelerate the scanning. https://support.eset.com/ca6626/

    However, if you hit the "corner case", like doing huge compilation job, ESET is no longer the lightest weight product (perhaps this is the case in AV-TEST). The lightest weight solution is -- not to scan anything, so no extra instructions to execute :rolleyes:

  2. 1 hour ago, Marcos said:

    Re. 19eee9336a4527eb76cd2ac69321727f159ad057,  0xDEADBEEF reported in on Nov 10. The detection was added indeed on Nov 10 in update 16388 which was the next update after he reported the sample if I remember correctly. Moreover, it's a jar archive, ie. Java needs to be installed in order for the file to run and therefore jar files have lower potential to do harm. Also the jar file in question has been seen on 5 computers worldwide so far.

    Nov 10 is the date I submitted to the forum. The initial day I spotted the file and right click submit to ESET was around Nov. 8. This implies the livegrid/background submission has very low priority or even be ignored sometimes.

    For malware spread in small-scale, yes, one generally cannot put hope on antivirus software to deal with them as vendors put more resources on "main stream" stuffs. However, during my test I also see some top-tier vendors blacklist so-called "rare" malware very rapidly upon first exposure on their cloud, or block the sample with behavior shield. This is much rarer in ESET. I have to keep email submitting the samples and get virus definition updated.

    I don't want to blame anything here, as I understand how hard it is to balance FPs and detection rate. However, I still would like to see that ESET can perform better. 

  3. I am opposed to the attitude of saying everything one doesn’t  want to see as “not helpful”

    And I don’t think simply averaging different viruslab results is appropriate as they can have drastically different testing methodology.

    I believe that AVC real world test can better reflect the real world cyber attack and defense because the test is performed on a daily basis with fresh new samples. All products are tested throughly across all protection layers with cloud enabled. In contrast, I don’t think tests which perform on monthly basis and perhaps only does scanning of a large number of sample or offline detection is still helpful nowadays. In most cases, the life cycle of a particular sample has been severely shortened because of better reaction speed of security vendors. And to be honest, the eset ranking in this test is about right when cross compared with my own testing experience

    In addition, their detailed report indicates that most product’s fps are from url tests instead of local binaries. ESET sometimes also has FPs in URL blacklisting. Of course AVC’s local binary fp testing methodology is way too limited and perhaps overlap with the white training set of “nextgen” vendors:rolleyes: 

  4. 1 minute ago, Marcos said:

    It's a password-protected gzip. I was unable to find the correct password and scan the exe file inside.

    hmm, alright I will submit it if I get a unzipped sample

    Plus I hope ESET can consider putting coinminer detection in potentially unwanted category. "Potentially unsafe" is sometimes too annoying but "potentially unwanted" is tolerable. There are a lot of users who don't want to have detection as strict as "potentially unsafe" but still want to block miner scripts.

  5. 5 minutes ago, Marcos said:

    1, Most likely because it's also used for legitimate purposes with user's consent.

    2, I don't know of such limitation. If it's there, then it's not possible to remove it other than by installing another language version.

    I really hope zh-cn clients can detect flystudio.packed (or at least provide a switch if FP is a concern). Threat of this category is very popular in China but zh-cn and zh-tw version clients don't detect this category in PUA. Legitimate software using flystudio is so few that detecting all of them as PUA as english version does shouldn't be a big deal for ordinary users.

    BTW, another MBR locker ESET missed.

    SHA256: c050c6122d1ac7a59e0735b646a2543ebd13bbd8e2a602cafc13eaea0df341c8

    I don't have this sample but I assume ESET might be able to get it. https://www.virustotal.com/#/file/c050c6122d1ac7a59e0735b646a2543ebd13bbd8e2a602cafc13eaea0df341c8/detection

  6. 7 minutes ago, Marcos said:

    We don't guarantee providing a feedback but we usually let the user know the verdict. For instance, no feedback would likely be provided if somebody sent a clean file without any further description.

    As for large files, I reckon that even 10-15 MB files should go through alright. Submit only sample in an email unless more samples are related to each other.

    cool.

    Two unrelated questions:

    1) why currently ESET puts coinminer scripts in potentially unsafe application category that is by default to be off?

    2) is there a way to enable PUA flystudio.packed detection on a zh-cn language endpoint client?

  7. 25 minutes ago, Marcos said:

    Instructions for proper submission of samples are available at https://support.eset.com/kb141/. Only samples (not jar files) submitted this way are replicated and blocked automatically if malware is matched / detected.

    Although it's possible to submit samples via gui, the most of such samples are junk, multimedia files, other clean files, etc.  They are not processed with as high priority as samples submitted to samples[at]eset.com.

    Alright, now I know how low the priority of GUI submission is. Thanks for the clarification.

    If the submitted sample through email is clean, will I get a feedback? How about very large samples that cannot be sent through email?

  8. 27 minutes ago, Marcos said:

    I've checked samples that we have received and the jar file in question was not submitted to samples[at]eset.com. I submitted it on 10. 11. 2017, 12:37 and a detection engineer replied 20 minutes later that the detection would be added in the next update.

    Does it mean the right click submission will not work???? I submitted the sample through right click menu with my email and description around Nov 8 11:00pm CST and it said the sample was submitted to eset.

  9. 47 minutes ago, John Alex said:

    ESET is always behind in detecting new malwares, at least 2-3 days, compared with other major players

    There is a sampling bias here: the thing I have posted here is sort of uncommon case for ESET (<5% of the fresh new samples I collected personally)

    My personal experience is that, the more popular the threat is, the less likely it will slip through ESET's defense (assuming no glitches on their cloud backend :rolleyes:). Perhaps the LiveGrid and human analysis prioritize more popular threats first. For the sample in this thread, the reputation in LiveGrid is still unknown when I first got the sample, so I assume the exposure is still low to other endpoints. But of course, the reaction speed of this sample is way too slow from my personal view. 

    In ordinary cases, the fresh samples I have encountered are usually at least blocked by LiveGrid. I have also seen cases that after ~20mins of my running of certain samples that bypassed the ESET, the LiveGrid started to blacklist the sample, which cannot be reflected on virustotal.

    But as you can see, no security solution is perfect. A false sense of being 100% secured will be disastrous when one encounter brand new samples which can quickly replicate to other machines (e.g. wannacry), unpopular samples (e.g. threats targeting countries where ESET has few endpoints deployed), custom made samples for specific targets (which are nearly impossible to exhibit malicious behavior in auto analysis pipeline), and other special cases which nearly no one can avoid (e.g. CCleaner incident)

    Since sometimes it is hard to know whether you are on the majority or minority side, the general guideline is to always be cautious when treating unknown files, mails, and websites, even with top tier antivirus products installed.

     

    And, my personal suggestion to ESET is that, I would like to see at least some feedback for the sample submission. I have never got feedback for my submission and sometimes felt frustrated. For the samples that are not flagged by ESET days after my submission, I was sometimes not sure if it is indeed clean, or simply didn't catch enough attention like the one in this thread.

  10. 4 hours ago, itman said:

    Well, McAfee, Microsoft, Sophos, Symantec, Vipre, and Webroot to name a few are still not detecting it. Add none of the Next Gen/AI solutions since they don't scan .jar files.

    Well at the same time BD and KIS reacted very rapidly after the initial exposure. ESET should be compared with top tier products. I would understand the slow response if there are some nuances in this sample though. Otherwise, two days after receiving the phishing mail is not very responsive anyway. It is even after the source of the malicious file, Mediafire, withdrawing the file from sharing due to malicious content.

  11. 3 hours ago, persian-boy said:

    What about the dynamic detection?

    Unfortunately no. I have tested the sample with ESET before submitting it, but it doesn't block anything during the whole execution. After submission I repeatedly scan the sample about every 8 hours but it is only after this afternoon does it start to detect this sample.

  12. 14 hours ago, Daedalus said:

    I think it is safe to say that the file is not clean:
    https://www.virustotal.com/en/file/67a241d4845bd929b6345059c030f9392477d2179bde86d2109bd5371ad1f004/analysis/

    Looks like ESET is running a bit behind on this one.

    If you got the file you can also upload it on the following site to see what is does:
    https://www.hybrid-analysis.com/ (P.S. website does not work in Chrome)

    This originally comes from a potentially phishing mail (so social engineering wise, it is already suspicious enough)

    It is exhibiting some very suspicious behavior, like vbs drop, add autostart, query security products and UUID, and write files to sensitive paths... But I am not sure about if these are enough to be categorized as "malicious". Most detections of this file on VT are either machine learning/heur and generated by auto pipeline, no concrete signature detections so far though.

    On VT, the first detection is by Kaspersky, Bitdefender and Cyren, and then followed by avast and avira. I was waiting ESET's verdict for two days and we will see.

  13. 2 hours ago, Enrico said:

    Hello. I used your product NOD32 in the past, and I heard that a new version has been released recently. I am currently concerned with ransomware protection, so I am very interested in capabilities of the ransomware shield component. I don't want to lose my data to something like bad rabbit :(.

    So, I've decided to check if NOD32 is the product that I need. As I understand it, ransomware outbreaks happen because it takes time to add malware signatures to antivirus database, so most antivirus products have good dynamic analysis. I wanted to test how ESET deals with "unknown" ransomware. To do it, I've disabled real-time file system protection and advanced memory scanner, leaving ransomware shield enabled. After that I launched a WannaCry sample, and it successfully encrypted my test files. In my understanding, ransomware shield must have been sufficient to stop a well-known sample. What am I doing wrong? Should I enable some additional settings?

    My test experience showed that for some threats that can be block in early layers (like scanning or AMS), the later layers might not block it. The ransomware shield is restricted to certain families. In my tests, locky family is the one that is more likely to be blocked. Also, enabling livegrid might be necessary

  14. 7 hours ago, itman said:

    Would not be surprised if Eset's UEFI BIOS scanner is based on a tool developed by Intel Security. You can read about that here: https://www.scmagazineuk.com/intel-security-responds-to-efi-rootkit-malware-updates-detection-tool/article/643799/ .

    Intel released it as open source and is loaded at GitHub as part of Chipsec: https://github.com/chipsec/chipsec . Chipsec documentation here: https://github.com/chipsec/chipsec/blob/master/chipsec-manual.pdf

    Warning: Don't fool around with Chipsec on other than a test PC and read thoroughly all warnings associated with the software.

     

    Yes I also saw this when reading ESET's blog post. Just not sure what the limitation will be using this technique

×
×
  • Create New...