0xDEADBEEF

ESET Insiders
  • Content count

    162
  • Joined

  • Last visited

  1. Intel Threat Detection Technology

    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.
  2. 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
  3. Malware response speed

    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.
  4. 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
  5. CAD Malware Scan Based On Extension?

    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")
  6. CAD Malware Scan Based On Extension?

    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.
  7. CAD Malware Scan Based On Extension?

    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.
  8. that image... an easter egg or april fool's joke?
  9. CAD Malware Scan Based On Extension?

    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
  10. 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.
  11. VB100 RAP Test

    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.