0xDEADBEEF
-
Posts
361 -
Joined
-
Days Won
3
Posts posted by 0xDEADBEEF
-
-
1 hour ago, itman said:
Problem is it only applies to Intel processors. So if yours is AMD, you're out of luck.
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
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
-
On 04/17/2018 at 4:16 PM, itman said:
Bitdefender, Emsisoft, Symantec, and TrendMicro didn't detect at all
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
-
5 hours ago, Marcos said:
Are there any other regular and working mnl files than acad.mnl that are used by AutoCAD ?
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")
-
4 hours ago, itman said:
I was going to mention this. Assume the code is packed plus possibly encrypted and obfuscated. Also assume it is actually LISP code as you stated.
If the .mnl file version is loaded into memory by AutoCAD, is it actually executable code? My hunch is the malware behind this file actually renames the file to a .lsp ver. after the file is downloaded and possibly unencrypts, etc.. it at that time.
I think this article makes it clear that both lsp and mnl may contain AutoLISP language.
-
16 minutes ago, itman said:
Based on what I posted, it appears .mnl file execution is dependent upon LISP being loaded first in many cases. This might have a direct impact of any Eset heuristic scanning of the file; it may make the same assumption and defer scanning of it until it loads into memory.
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?
-
27 minutes ago, itman said:
Suspect this might have something to do with the frequency occurrence of the file 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
-
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.
-
6 hours ago, MartinK said:
Could you please provide more details of used hardware device (vendor, product type)?
I am not sure impact on battery on such devices is actually tested and I am not aware of any similar reports -> we will have to verify. I would also recommend to open support ticket or ask you local distributor to do so that this requirement is officially tracked.
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.
-
11 minutes ago, Marcos said:
I'm not sure if installation on tablets is possible and fully supported. I know we support installation on Android tablets, however.
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?
-
4 hours ago, Marcos said:
Please check the attached video and find out what you did differently.
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.
-
1 hour ago, Marcos said:
Please provide a complete record from the Detected threats log. Is the file detected upon an attempt to launch it or when copying it to the same location? I was unable to reproduce it.
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:
QuoteTime;Scanner;Object type;Object;Threat;Action;User;Information;Hash;First seen here
01/30/2018 1:37:13 PM;Real-time file system protection;file;D:\c\bitcomet_setup.exe;Win32/InstallCore.Gen.A potentially unwanted application;cleaned by deleting;Machine\User;Event occurred during an attempt to access the file by the application: C:\Windows\explorer.exe (1C975DFA73F8C9389975A2ECE34AD74B165DD1C6).;6BDFD84B166038D76E5C5ECAF0A1AB5F8D6B4EFE;01/30/2018 1:35:49 PMThe 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.
-
6 hours ago, Marcos said:
Please provide a screen shot of the exclusion list. Is the detection name prepended with "@NAME="? You can also try excluding a potentially unwanted or unsafe application right from the yellow alert window upon detection. Also note that this only works for pot. unwanted and unsafe applications, not for malware detections.
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
-
On 01/28/2018 at 2:21 PM, Marcos said:
Please provide:
- a screen shot of your exclusion list
- a complete record of the detection from the Detected threats logI 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
-
3 minutes ago, Marcos said:
Correct. I've scanned it with my Endpoint 6.6 and it's detected:
Log
E:\test\a9e11807f3cccd52f5476956f96d853e794ced2d - a variant of Win32/Packed.VMProtect.M suspicious applicationAs for the SMSBomber.L, it will be reclassified later. It's not malware.
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)?
-
12 minutes ago, Marcos said:
It is already detected as a variant of Win32/Packed.VMProtect.M suspicious application. After the next update it will be detected as Win32/RiskWare.GameHack.CB application.
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.
-
7 hours ago, Peter Randziak said:
Hello @0xDEADBEEF
you can send me a private message with a link to download or you can upload it to ftp://ftp.nod.sk/samples/ with a unique name, you can use the file hash and let me know once, the upload is complete, we will check it.
Thank you, P.R.
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
-
On 12/14/2017 at 5:15 AM, MichalJ said:
improve the cloud-based reputation (cloud based detections) by the means of adding "Dynamic Threat Defense" (fully controlled cloud sand-boxing)
could you elaborate more on this?
-
On 12/18/2017 at 12:03 PM, Marcos said:
ESMC, EDTD, ECMP, EIS, ECA, EBA, etc. will become more than just letters in the next few months
What are these acronyms?
ESET missing from AVTest , Feb2018
in ESET NOD32 Antivirus
Posted · Edited by 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.