QuickSilverST250

Yes, this can happen and even i would say is possilble from a NAS device or similar.

Yes, this makes sense if you have an environment where other devices comes into your network with free av or infected and might spread to your devices. If all all devices run ESET then this is something that ESET missed.

I've scanned the VM with XDR now after it updated to the latest engine, this is the screenshot, it seems it was black matter that infected:

We had the same notifications, again i could be wrong in which sample caused the infection but was working in XDR and this one stood out, it could have been any one of them that started with 0 "zero" in file name as it goes in sequence and it was around 06 when we noticed the infection

Could be as when the infection took place i could not really see in PE the payload or could be remote infection

The way we did this test was: From a server location, malware in protected zips, we extract the zips to a folder that has our script to execute the malware, we extract the malware to this folder with the protection ENABLED. We allow ESET to quarantine the malware as it's being extracted, once the extraction process is done, we then run our script to execute what's left and this will be windows, linux and android files. Once the test is done and the left over samples, we manually submit them just incase they weren't.

NO, Hyper-V for our testing VM's against malware.

Hi James, thank you for the reply. As mentioned, this is a VM for testing samples, we have everything up to date, detection engine was 29130 during the test we did a short while back. We are testing it now on a new VM with engine 29131 and seems fine now and looks like it's being detected, just a shame it took over 24hrs for this to be detected. I could be wrong in regarding the ransomware that might be responsible for the encryption as that's the only one we can see XDR flags as ransomware, once i upload the note and sample to id ransomware, says it's unable to determine the type. We did this on 2 x EES and 1 Eset home premium vm.

As mentioned, we use this vm to test malware so there are all kinds of samples being detonated, doubt as you might the machine is infected non the less.

Hi, we logged a ticket with our region support team and no one has come back to us. We tested new samples in our VM environment, and we have ransomware infection. We tested the same samples for our 24 hrs period and they keep getting infected, we submitted the samples but somehow ESET is still unable to stop this infection. As I'm making this post, the infection just happened again, please see below our info to tech support: Hi, Hope you are doing well. In our testing environment, on my VM I was testing some new samples, I noticed a text file drop on the desktop and immediately suspected ransomware. once I navigated to Documents/Pictures etc I noticed the file ext have changed to .TE8ZZUVLN I have made a recording on how the VM is currently looking and you can find the logs collected with the profile assigned to the endpoint: I did mention we will not shutdown so we can collect the logs, but the VM did shutdown on its own after I stopped the recording. The logs collected are from after the VM started up again. We then run the same test on our VM with XDR, here are the info for this VM: Here is the screenshot of our VM that has XDR on it: We collected logs from the VM also after a restart as it was nonresponsive, and we struggled over an hour to try and get the logs but no luck so we restarted it.. It looks like it’s this sample that’s caused the infection: 062683257386c9e41a1cd1493f029d817445c37f7c65386d54122fa466419ce1.exe Shows ESET on VT as detected but seems it’s not. We have the info in our XDR, we are investigating on our end but let us know what info you need from the XDR. We also runt the same malware hours later our other VM running ESET Smart Security Premium and suffered to the same fate. Please let us know what info is needed and how this infection was possible.

Here is the 2nd upload. Malicious APK 2.rar

We will be testing the behavior soon, only noticed other vendors are flagging them. We saw today that our EES detected some of them, so we restored them and copied to an android phone with endpoint protection on it, it detected now 3 of them, yesterday it detected nothing. We attached the other ones; they might not be malicious but can check them out if you want to ESET but you can check them out if you want. The ones left behind was scanned detected by surfshark antivirus on android, not all but only Malicious APK.rar

I have some apk files i want to check but to exceeds the limit so will email a wetransfer link for them

Thank I appreciate it. What is the best way to supply samples to ESET? To do it on a endpoint and submit auto/manually or send the samples to ESET?

Great thank you.

Thank you for helping I appreciate it.

Was referring to the zip files i uploaded with multipale files in them.

Did you see the other .exe etc ones. The .unknown ones we rename to .ps1

The only junk files are the ones i added by accident, but all the other ones should be fine but could be corrupted. I re-uploaded them again for you. ESET malware files.rar

Here is the 2nd samples Samples to ESET.rar

Hi Itman, thank you for the reply. Yes, we are aware of the deferent LiveGuards, ours are set to Suspicious->kill running process->block execution till verdict and set to 10min.

Hi, please see attached samples, they aren't the best as the techs did delete most samples as they are continuing to test, but i did add some samples. They are running on the machine in memory and the other ones are showing green/yellow as reputation but aren't being removed. For some of these samples we got the message the file was blocked due to analysis, after a short time it say the files are safe to use and not removed. The password is "suspicious" for the zip. Samples to submit to ESET.rar

Hello, Thank you for your reply. Let me clarify a bit more. We only use Endpoint Security and File server security (MSP). Thats why we asked is LiveGuard is supposed to block unknown files (regardless is clean or not), now we know it doesn't. Our policy states to submit all detected samples also. We have no issue if the manual submits stays on 10 if unknowns are submitted automaticlly for us, but with the inconsistency with files not being submitted or a very long time later is the issue. I have supplied the logs and necessary info to our ESET region with a video recording. It seems it might only submit the sample if it might detect some malicious code but needs further checking? Not submit it if detects it as clean maybe? We are aware LiveGuard does not take VT info into account, the purpose of mentioning it was to demonstrate that ESET is rating a lot of these files as safe, as many other vendors don't. I'm not referring that vendors are rating files as malicious and ESET has no rating yet, we are saying ESET says it's clean and other vendors say it's malicious. Thats the issue. Then we execute the malware and can see some strange behavior. I will provide the feedback form tech support once i have it. We will be doing new malware testing this weekend and will provide feedback here.

Hey guys. Not sure if this post is in the correct place, but we logged a ticket with our ESET region but though we will post it here as well. We do our own malware testing, now in our test environment we came across some questionable actions regarding LiveGuard/LiveGrid that we are concerned about and maybe we need better explanation or training maybe?. Below is the mail we sent to them, feel free to have a read: Our issue is that when we extract malware on our test VM, our concerns are: According to our knowledge, LiveGaurd as the zero-day component is supposed to blocks unknown files from being extracted/executed from a supported archiver, then submit the sample, after analysis then allowed or block according to the rating. Yet they are extracted and allowed to be executed and run in memory and then a couple seconds later detected and killed, some samples are missed and running in memory until we reboot the machine. So liveGaurd is not stopping unknowns from extracting nor executing. We did this with placing the zip files on the desktop and emailing it and extracting it. Why does LiveGaurd not submit unknown files/malware immediately and only hours/days later and mostly not even at all? Then we must submit them manually. We have samples that are on the VM for days on end, not submitted until we do it manually or randomly days later we will see the popup that a file or 2 was submitted. We see LiveGrid rating malware as clean, yet when we submit the samples to VT, many vendors will rate it as malicious. When we also scan the machines with other 3rd party tools like Malwarebytes, NPE, Emsisoft Emergency kit, they are detecting a good amount of the samples and strange startup items etc as we detonated the samples, then scanned the machine with ESET prior to the 3rd party scans, where ESET says the endpoint is clean. There is no way to object a rating from LiveGrid, it seems the final/only rating is from machine/AI and no human developer interaction to double check if Live Grid is correct and didn’t make a mistake. The 10 items only at a time to submit is very limiting, many other vendors allow unlimited submit of samples. There is also no way to submit a sample from the dashboard, further limiting the submitting process. This is raising some concerns for us and maybe it’s because we don’t understand fully how the product works/protects or this might be a bug/vulnerabily maybe. Please see our concerns as us trying to help and improve ESET as it’s a great product but really needs to make things more modern when submitting samples. Surely there are other MSP/IT departments using ESET and testing ESET in controlled environments and will greatly benefit of being able to submit unlimited samples manually that support a vast file extension and to do so from the cloud console and not only from and endpoint level. Also, to object rating and get a second opinion from a developer. LiveGaurd needs to be able to protect from all attack vectors, not just common ones and to be more of a cloud/local sandbox and stop all unknown files, be it exe, dll etc.

We were also advised to run ecos only, personally we run both MS365 and ECOS, but only standard security on MS 365 as a second layer incase eset misses something. W ceps domian spoofing enabled as when we disabled this our clients got some spoof mails so switched this back on for all clients. We found no issues in mail delivery, eset catches most but we do see now and then mail quarantined by defender. It does take to login in 2 systems, but this works for us.