- Sep 5, 2017
- 1,173
Edit: I also asked them, then why it wasn't detected by other modules like Ransomware shield? I'll post their response here if they reply.Unfortunately, the detection created by an automated system was removed during a purge of simple automated detections in 2018 after 2 years of no detection of the malware from 2016. We've created a smart generic detection for it and the file is already blocked.
Did you receive a reply later?ESET's response to this video,
Edit: I also asked them, then why it wasn't detected by other modules like Ransomware shield? I'll post their response here if they reply.
Not much really. Their response to any kinds of missed threats has always been that a malware simply doesn't arrive on the system. It either comes from a malicious sites or email attachments etc and in those case Eset would likely block the arrival of that ransomware in the first place before it would do any damage. Which is correct and I agree with them but still it shouldn't be an excuse to the failure of the Ransomware shield. But Eset has always been a signature focused, pre execution based detection type of AV. It's the best at detecting variants of known malware but if something brand new comes along Eset usually fails. Eset also has what I would say a "False positive phobia". They prioritize this over everything.Did you receive a reply later?
It's strange that they didn't see a detection (of this strain) in entire 2 years. Even stranger is that they purged their automatic detection because of that... to perhaps make it lighter, believing that signatures and other modules will do the job.
They could have added it to sig update before purging.
This small example shows that they chose to remove small but valuable assets from their sig-strong product.
I wish that they later changed their policy for good.
I agree with the first part that main source is always malicious website or attachment which will be blocked often by wen protection module (this is most effective real world scenario .also note that .py is python script which may drop another malware modules or payload and not be the main malicious file at the stage of dropping the real malware I expect it would be intercepted by eset unless it is file-less malware then it will be big problemNot much really. Their response to any kinds of missed threats has always been that a malware simply doesn't arrive on the system. It either comes from a malicious sites or email attachments etc and in those case Eset would likely block the arrival of that ransomware in the first place before it would do any damage. Which is correct and I agree with them but still it shouldn't be an excuse to the failure of the Ransomware shield. But Eset has always been a signature focused, pre execution based detection type of AV. It's the best at detecting variants of known malware but if something brand new comes along Eset usually fails. Eset also has what I would say a "False positive phobia". They prioritize this over everything.
Btw, this signature removal thing recently happened once again. In February in a malware pack from our malware hub one sample was missed by Eset. It was a .ps1 Powershell script. I submitted it to them and they added a signature. Few days ago I saw that Eset is not detecting that anymore, not even after executing with everything set to aggresive. I submitted it back to them and also wrote this used to be detected then the next day Eset started detecting it again. I don't know why this happened again! But by the looks of it, it seems it happens more than often.
Yes, in a real world scenario getting infected by a malware with Eset installed would be a very rare incident. Btw, it was a powershell script not python. But anyway it's true that a script itself can't do much and it always has some malicious payloads and it's more important to stop that. Btw, since you talked about python, the AMSI scanner that windows created to help all AVs detect script based malwares doesn't work for python scripts so it's more difficult to detect those but the good thing is it's not common yet.I agree with the first part that main source so alwayes mailcious website or attachment which will be blocked often by wen protection module (this is most effective real world scenario .also note that py is python script which may drop another malware modules or payload and not be the main malicious file at the stage of droping the real malware I except it would be intercepted by eset unless it is filess malware then it will be big problem
But it may be good new idea for cyber criminals. Btw, since you talked about python, the AMSI scanner that windows created to help all AVs detect script based malwares doesn't work for python scripts so it's more difficult to detect those but the good thing is it's not common yet.
also if you disabled powershell using hardconfigurator or trough Group policy editor the script will not able to be executed and will be blocked .also power shell scripts need administrative privilege so it need ti run in Administrator environment if you use SUA by default.which is more secure ,privilege escalation will be hard stage if it failed the script will not be executed.unless there are some social engineering or embed this script somehow in another file which need administrative right then dropped and executed when the main file executedYes, in a real world scenario getting infected by a malware with Eset installed would be a very rare incident. Btw, it was a powershell script not python. But anyway it's true that a script itself can't do much and it always has some malicious payloads and it's more important to stop that. Btw, since you talked about python, the AMSI scanner that windows created to help all AVs detect script based malwares doesn't work for python scripts so it's more difficult to detect those but the good thing is it's not common yet.
Yes home users don't need scripts in general so it's better to block those.also if you disabled powershell using hardconfigurator or trough Group policy editor the script will not able to be executed and will be blocked .also power shell scripts need administrative privilege so it need ti run in Administrator environment if you use SUA by default.which is more secure ,privilege escalation will be hard stage if it failed the script will not be executed.unless there are some social engineering or embed this script somehow in another file which need administrative right then dropped and executed when the main file executed