Dmitry228
-
Posts
14 -
Joined
-
Last visited
Posts posted by Dmitry228
-
-
-
59 minutes ago, Marcos said:
Он не мог быть обнаружен LiveGuard, так как требовал от пользователя нажатия кнопки для запуска приложения.
I understood.
But then how did other technologies not work, heuristics? It seems to me that this is obvious malicious behavior of the program -
8 minutes ago, Dmitry228 said:
I think it was Melter.B, not "Virus_Destructive" from MalwareStudio as you say, and the video shows that it is undetectable by ESET...
But since I previously sent it to a virus lab for analysis, it was just recently entered into the databases. Now it is detected as MSIL/BadJoke.AJF
ESET could not detect it with any of its numerous technologies (including LiveGuard). And only manual submission to the lab helped to add to the databases -
21 hours ago, Marcos said:
That "Virus_Destructive" by MalwareStudio is detected as MSIL/KillFiles.BU trojan.
I think it was Melter.B, not "Virus_Destructive" from MalwareStudio as you say, and the video shows that it is undetectable by ESET...
But since I previously sent it to a virus lab for analysis, it was just recently entered into the databases. Now it is detected as MSIL/BadJoke.AJF -
1 hour ago, Dmitry228 said:
Hmm... Take, for example, Dr.Web Security Space antivirus. It by default prohibits low-level access to the disk, which prevents such malicious programs designed to destroy the MBR from destroying it. And with all that, the computer functions normally, everything boots up. You can even check it yourself. Or, for example, Kaspersky Standard/Plus/Premium antivirus - it has an "Intrusion Prevention" component with four groups of applications - "Trusted", "Weak Restrictions", "Strong Restrictions" and "Untrusted". So, if I prohibit low-level access to the disk and the file system for the last three groups and then reboot - nothing happens, everything works correctly (the "Trusted" group is excluded because unknown malware would fall into the "Weak Restrictions" group at most). Even if no such rule is added to HIPS, why doesn't ESET react to the fact that some unknown program changed the MBR? This is quite strange, I would like to see at least a detection of behavior analysis, as, for example, Kaspersky does when it sees an attempt to change the MBR by an unknown program. Oh, and by the way, why not make this rule only for unknown ESET programs? But for trusted applications (say, those with a trusted digital signature or those whose security has been confirmed by ESET LiveGrid) such actions would be allowed
this video is divided into two parts, where in the first video the ESET antivirus allowed the destruction of the MBR with default settings, and in the second video - Dr Web, which was able to prevent this
-
27 minutes ago, Marcos said:
Such default rule might cause users' machines unbootable. If it was that easy and reliable, HIPS would have such protection by default.
Hmm... Take, for example, Dr.Web Security Space antivirus. It by default prohibits low-level access to the disk, which prevents such malicious programs designed to destroy the MBR from destroying it. And with all that, the computer functions normally, everything boots up. You can even check it yourself. Or, for example, Kaspersky Standard/Plus/Premium antivirus - it has an "Intrusion Prevention" component with four groups of applications - "Trusted", "Weak Restrictions", "Strong Restrictions" and "Untrusted". So, if I prohibit low-level access to the disk and the file system for the last three groups and then reboot - nothing happens, everything works correctly (the "Trusted" group is excluded because unknown malware would fall into the "Weak Restrictions" group at most). Even if no such rule is added to HIPS, why doesn't ESET react to the fact that some unknown program changed the MBR? This is quite strange, I would like to see at least a detection of behavior analysis, as, for example, Kaspersky does when it sees an attempt to change the MBR by an unknown program. Oh, and by the way, why not make this rule only for unknown ESET programs? But for trusted applications (say, those with a trusted digital signature or those whose security has been confirmed by ESET LiveGrid) such actions would be allowed
-
6 minutes ago, Marcos said:
Такое правило по умолчанию может привести к тому, что компьютеры пользователей не будут загружаться. Если бы это было так просто и надежно, HIPS имел бы такую защиту по умолчанию.
If so, then it would be a good idea to detect KillMBR programs using heuristic analysis or the ESET cloud. Because when I sent a similar malware program for analysis through the Windows Explorer context menu, LiveGuard did not see it as a threat. Although in the sandbox it would have seen an attempt to destroy the MBR (I think so).
When I tried to run the same MBR destroying program on a machine with Kaspersky installed, its "System Watcher" component immediately noticed the malicious behavior and would not let the MBR be destroyed. -
5 minutes ago, Marcos said:
You can create a HIPS rule that will ask before or block direct disk access, however, it's said it's quite tricky since gui doesn't allow to enter volumes and you might also end up with unbootable system, requiring to temporarily remove ESET or at least HIPS rules in safe mode.
It seems to me (in my opinion) that such a rule should be initially configured in the HIPS system to prevent destruction/overwriting by malware unknown to ESET. It would be nice to have HIPS by default to prevent programs from destroying MBR.
-
17 minutes ago, Marcos said:
Сама Windows не должна допускать изменения MBR. Если вы знаете примеры, которые мы могли бы использовать для воспроизведения модификации MBR под Windows, пожалуйста, свяжитесь с samples[at]eset.com с информацией.
There's a reason why you and other anti-virus vendors have a separate malware category called "KillMBR", isn't there? I don't know if Windows is supposed to protect MBR from destruction/rewriting, but if it is, it's not doing a very good job... I've personally tested dozens of malware on a virtual machine, and ESET was unable to prevent the boot record from being erased. In addition, some malware left writings in it before Windows started, such as: "You are infected with Trojan <...name...>".
I sent all these files to the ESET lab via a special form. All of them were added to the signatures either as MSIL/BadJoke.AJE trojan or Win64/KillMBR.BZ trojan. The HIPS system failed to protect MBR destruction (removal).
Why not add such protection? At least a warning that a program on the computer is trying to modify the MBR. -
1 minute ago, Marcos said:
MBR заражается в процессе загрузки, когда даже Windows еще не запущена.
I'm talking a little bit about something else. There are malicious programs that do not infect, but completely destroy the MBR right while Windows is running, and the next time Windows is rebooted it will not boot. That is, they erase it.
Why doesn't ESET protect against this? -
why doesn't HIPS in ESET prevent MBR modification/destruction? Even if antivirus does not see any threat in the program (which is often the case with zero-day threats), you should at least block it from accessing the master boot record (or show a HIPS warning)
ESET's keyboard shortcut protection against screen blockers
in General Discussion
Posted
Hi! Why doesn't ESET have a function to close unknown blocker programs (like WinLocker) that have not been detected by ESET as malicious, but still block the user's screen and prevent using the computer, using a special key combination? Kaspersky has such a feature, which when you press such a special key combination (its default is "CTRL + Shift + ALT + F4"), automatically finds the blocker program, terminates its process and moves the program to quarantine.