0xDEADBEEF
-
Posts
361 -
Joined
-
Days Won
3
Posts posted by 0xDEADBEEF
-
-
2 hours ago, itman said:
So in reality is there a vulnerability here? I say no since the script would have been scanned again at PowerShell execution time via the Win 8/10 AMSI interface which would have revealed the actual script code after removal of the obfuscation characters.
Nope, I think I've found some issues already. But will not post here for now...
-
8 hours ago, itman said:
When we discussed this via PM and I suggested uploading to a fileshare and subsequent downloading from it, Eset appeared to detect the malware each time at attempted file creation time.
Sometimes I got batches of samples (in zip) for analysis. I agree that it is slightly different from web download distribution.
Anyway, I've recorded the case I was mentioning here: https://imgur.com/a/hGcPdsl
Note the two zip files have exactly the same file, except that the one with _ps1 contains .ps1 extension
-
1 minute ago, Marcos said:
I'm unable to reproduce it since ps.txt is immediately detected by real-time protection. I thought it would be detected after renaming the extension to ps1 but that doesn't seem to be the case.
This is very weird. I am running on latest EES with all settings set to default (except for the exclusion list). This has been reproduced on more than one machines on my side (I've not tested EIS but itman confirmed it)
This is not the first time I've experienced this. Previously another javascript malware sample has the same issue (it lost its .js extension hence ESET on-demand didn't detect it, though it could if the extension was correct)
Other users are welcome to try and see if this is reproduce-able on their side, however I don't think I can provide a sample link for them to download here...
Another thing to note is that even though such case may "slip through" the realtime protection, when actually executing it, the engine will anyway inspect it again. So if this is indeed something unexpected, at least it is not something really bad so far. I will try some other types of scripts and see how it goes.
-
53 minutes ago, Marcos said:
Please provide me with the file for internal debugging. Do you mean that it was not detected neither by real-time protection nor on-demand scanner after renaming the extension?
yes. So if the script is landed on disk as .txt file for the first time, the realtime protection won't detect it, neither does on-demand scan. If I later rename it to .ps1 the on-demand scan still does not detect it.
However if the script is landed on disk as .ps1 file for the first time, the realtime protection will immediately detect and quarantine it.
It is very likely that in the first case the file is cached as "benign" due to .txt extension initially, and later got exempted from being scanned again by the right-click scanner even with .ps1 extension.
The attached sample's password is "infected"
-
2 hours ago, itman said:
Is your sample PowerShell script packed, encrypted, or obfuscated?
yes it is obfuscated
-
51 minutes ago, itman said:
Had a similar experience a few months back. Except in my case , Eset originally didn't detect the PowerShell code.
Well over a year ago, I found this nifty .NET based PowerShell global keylogger. Nothing earth shattering code-wise since the code had been available since 2015 on the pen-tester web site I found it on. In fact, I used the code to create a .ps1 script to run the keylogger to verify that Eset's B&PP does actually scramble keystokes and actual data could not be intercepted with this keylogger. The thing to note here is the .ps1 file code was not subsequently in time detected by any Eset on-demand scanning. Most likely since the file had been previously marked as scanned and clean.
Two months ago, I opened the same .ps1 script using notepad to copy the code to later paste into another forum. No modification to the original script code or anything. The minute I closed the .ps1 file, Eset caught it and quarantined it. Of note was that the detection signature date was the very same date!
My conclusion was that Eset's protections had subsequently updated to detect global keylogger code characteristics. Eset's realtime heuristics detected these characteristics upon file close and suspended the file. It was submitted via LiveGrid which promptly created a sig. for this specific code. The file was then promptly quarantined showing this new signature in the Eset log file.
Something I've noticed is that seems ESET is spending a huge effort since last year to optimize the real-time monitoring performance. A side indicator is that its performance score in AV-TEST has improved significantly (5.5/6.0 recently in business test, in the past it was usually 3~4 out of 6.0 for home products). I can feel the real-time monitoring has become less sensitive (not in a bad way, though)
Still I was wondering why the scanner is detecting some files solely by extension. Though detecting a text file and infer its language/content may not be straightforward, many other vendors do. I am not seeing a vulnerability in doing so, but sometimes it is a bit confusing
-
The EES version is 7.1.2045.5
There is a malicious powershell script sample that is detected by ESET's database for some time. It originally has .txt extension. By default it doesn't seem that ESET realtime/on-demand scan will detect the sample when the extension name is .txt (same for javascript and CAD files, if the extension of .js is missing the scan engine won't detect it).
Now that since the scan engine shows clean, I rename the file extension from .txt to .ps1, and I rescan it, the result is still clean.
However, if I open the script, add a white space, and save it, it is immediately detected and quarantined by the scan engine.
Later I found that even I don't modify the file, upon the next signature update the file that was once marked as clean will be detected.
Therefore I assume this is due to ESET scan's caching mechanism, as changing the filename doesn't change the file hash, the clean result will be cached and the scan will be directly skipped the next time. Upon the next update, the cache will be invalidated so the file is redetected again.
Just wondering if this is expected. I can see this is effective as a performance enhancement trick, because even the right click scan may "trust" such malicious file, executing it will anyway trigger the inspection again and detect it.
A side question: why is ESET's context menu scan still single threaded? Any plan to extend it to multi-thread scan (I mean emulate multiple files at a time)
-
10 minutes ago, itman said:
I assume with the inclusion of the "advanced machine learning" module, they are introducing established and proven AI algorithms into the Augur engine.
yeah I was referring to this new module in the module list (though I believe it is in v12 for quite some time, just was not shown in the module list).
So generally I am curious about this newly added detection module. Will it be also detecting things during ordinary scanning and monitoring? Is it static engine? Will there be new detection names? etc.
-
Just wondering if the newly added machine learning module has been integrated to the scanner and realtime file monitoring or it is just effective for some of the protection layer?
-
9 hours ago, MichalJ said:
Maybe, just maybe, this might be related to the fact that you have a very short update interval set for ESMC modules. I know I had experience such behavior once, when I applied too short server setting for module updates. After module updates, if I recall correctly we restart server service, and therefore sessions are invalidated. But that´s just a guess.
I have nearly everything in the ESMC set to default values except that I use my own cert for the webconsole. I will try to modify those timeout knobs and see if the issue can get resolved.
-
12 minutes ago, Marcos said:
I assume he is not logged as the ESMC Adminsitrator (the default admin account). If he's logged under another administrator account, most likely this user has a shorter autologout set:
Hmm.. However I am sure it is the default Admin account. The upper right corner is showing >9MIN. Also I've verified the autologout for the default admin is set to 10min
-
Currently using the latest ESMC with Chrome 75.0.3770.100
The Admin user by default will logout 10 min after the last activity in the session. However it seems it is always auto logging out much sooner (less than 3 minutes). The setting is showing 10min logout. Is this a bug?
-
Wow I didn't know that MS made such report. Thanks for sharing.
-
Noticed that the pre-release has added a new machine learning module in the module list. Is that local Augur integration?
-
2 hours ago, itman said:
Bottom line, I really don't see a problem here.
The only reason I was mentioning this is because web protection has more sensitive heuristics than on-demand scan or realtime scan, as Marcos has stated in this thread.
This means though the realtime scan or AMS will anyway catch the malware if the file is extracted to disk or memory, it might missed the more sensitive heuristic in the web protection layer, if my understanding is correct. As for how much more sensitive the web protection is compared to normal scanner, I've no idea
-
16 minutes ago, zamar27 said:
Also, what is the purpose to inspect regular archives? They can be inspected at extract time to save resources. How would Eset differ an encrypted archive from not?
Agree with the VPN part. the only reason I am asking is because of the more sensitive download heuristic ESET has in the web protection. For differentiating encrypted archive, common file format should be handled (ESET scan log will show such detail)
-
56 minutes ago, zamar27 said:
As to VPN plugin, it allows to encrypt browser traffic including file "downloads", so it all comes to the sequence, whether the traffic is decrypted by the plugin before Eset checks it.
It depends on where ESET intercepts the traffic. Essentially when the file is landed on the disk, it is not encrypted, so ESET will have a chance to inspect it using more aggressive heuristic. However I guess so far because this is handled by realtime monitoring and it doesn't scan archives by default, such more sensitive detection won't be activated.
The way ESET scans SSL traffic seems to be different from some other vendors (e.g. bitdefender). ESET will install its own CA to intercept the traffic (thus the https website in the browser shows ESET CA). I am not sure at this level will ESET be able to inspect the traffic. I guess it should because the data received is likely to be decrypted by VPN first and then decrypted by HTTPS, so inspecting at HTTPS will not be affected. Also I've heard other people saying ESET won't inspect archives downloaded by IDM or other download software.
-
13 hours ago, Marcos said:
It depends. When you click a link in a browser to download a malicious file, it looks like as follows
Wondering if you have confirmed my observation. If so, is there a plan to fix it? (along with VPN plugin issue)
-
8 hours ago, itman said:
Eset SSL/TLS protocol scanning can't scan the encrypted FireFox send files because it has no access to the public key used to unencrypt the files.
if this is the case, it seems to be a security vulnerability that can bypass the web protection heuristics.
-
4 minutes ago, Marcos said:
Also web protection blocks known sites that distribute malware so even if there's a new unrecognized variant, the download would be blocked
For this kind of detection, will it be shown as some specific malware name? or it will just redirect the browser to the ESET warning page?
BTW, I am not a web dev pro, but I suspect the reason why ESET cannot detect firefox send is due to its HTML5-based download system (similar to mega.co.nz). I did the same test on mega.co.nz and ESET cannot detect it as expected.
-
12 hours ago, Marcos said:
scans archives utilizing more sensitive detections
does this mean web protection may detect something that on-demand scan cannot detect?
-
12 hours ago, Marcos said:
If you come across an undetected archive, send it to me via a personal message please.
After some more tests, I feel like this is website dependent. For the same archive that contains malware, downloading from dropbox is fine (ESET detects it), but downloading from firefox send doesn't work.
My test results (On windows 10 1903 Edge + EES 7.1.2045)
Dropbox Firefox Send
Eicar zip: detected detected (after some delay)
malware zip: detected not detected
I've sent u the zip I used to test this through private msg
BTW, VPN plugin also affect this. For example my main browser is Chrome + surfshark VPN plugin. When the VPN plugin is enabled, the zip won't be detected. Disabling the plugin will have ESET detect it. I don't know if this is considered a bug...
The test I had on Edge is orthogonal to this though, it is a barebone Edge browser with no plugin
-
Does ESET web protection/realtime scan malware inside an archive (e.g. zip)? The reason I am asking this is because in most cases the zip containing malware (no password) I downloaded doesn't trigger any detection from ESET until I unzip it. These archives are small (<512KB). However, for the eicar test zip file ESET will detect it immediately. This is a bit confusing.
I tried both on Edge and Chrome, and the results are the same.
-
20 minutes ago, Marcos said:
Does it occur when egui is not running (only egui proxy is) and a detection is triggered?
OK I think I find out how to reproduce it precisely.
In normal case it won't happen, it only happens when you have a manual scan result in the Computer scan tab (see below)
in such case a popup trigger will bring up the main GUI. If I click dismiss, this issue will disappear. Guess there is a logic bug in the code.
ESET Smart Caching Questions
in ESET Endpoint Products
Posted
@Marcos I've PM-ed you the PoC sample. Could you evaluate if it is indeed a vulnerability?