Protection against MBR modification/destruction in ESET

[Dmitry228 1]

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)

[Marcos 5,069]

MBR gets infected during the boot process when even Windows is not running yet.

[Dmitry228 1]

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?

[Marcos 5,069]

Windows itself should not allow MBR modification. If you know samples that we could use to reproduce MBR modification under windows, please contact samples[at]eset.com with the info.

[Dmitry228 1]

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.

[itman 1,659]

1 hour ago, Marcos said:

IWindows itself should not allow MBR modification. If you know samples that we could use to reproduce MBR modification under windows

I believe the OP is referencing system "destroyers" that fall into this category;

Quote

Arrival Details

This Trojan arrives on a system as a file dropped by other malware or as a file downloaded unknowingly by users when visiting malicious sites.

Installation

This Trojan drops the following files:

• %All Users Profile%\log.txt → Log File.

(Note: %All Users Profile% is the common user's profile folder, which is usually C:\Documents and Settings\All Users on Windows 2000(32-bit), XP, and Server 2003(32-bit), or C:\ProgramData on Windows Vista, 7, 8, 8.1, 2008(64-bit), 2012(64-bit) and 10(64-bit). )

Other Details

This Trojan does the following:

• It wipes data from the following:
  • Enumerated PhysicalDrives
  • Enumerated Logical Drives

 

https://www.trendmicro.com/vinfo/us/threat-encyclopedia/malware/trojan.win32.killmbr.yecca

As long as Eset has a sig. for the malware payload, you're covered. Otherwise, you're "nailed."

Edited April 26, 2023 by itman

[Marcos 5,069]

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.

[Dmitry228 1]

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.

[itman 1,659]

Actually, one should always have Win installation media present and updated to current Win release, or create Win recovery media. The MBR can be recreated in Win Recovery mode from either.

However if the MFT or disk partition table is trashed, "you're up the river without any oars." As such, periodic creation of a Win image backup is a mandatory practice. Or minimally, off-line backup of data files and apps that can be restored after a Win reinstallation.

[Marcos 5,069]

18 minutes ago, Dmitry228 said:

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.

Such default rule might cause users' machines unbootable. If it was that easy and reliable, HIPS would have such protection by default.

[Dmitry228 1]

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.

[Dmitry228 1]

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

Edited April 26, 2023 by Dmitry228

[Dmitry228 1]

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

[itman 1,659]

Since we are having this MBR protection discussion ..........again, first review prior forum postings on the issue. I will repeat again what wrote in those prior postings.

At the height of the Petya and subsequent NotPetya attacks in 2016 - 2017, Cisco created an open source MBRFilter device driver to protect anyone who chose to use it against MBR modification. Here's Cisco's article on it: https://www.talosintelligence.com/mbrfilter. The driver can be downloaded from Github here: https://github.com/Cisco-Talos/MBRFilter . I used the driver for about 6 months on Win 10 with Eset installed and encountered no issues. Of note is this was back in 2017.

Now for the "fine print" in regards to this driver; most important if you wish to use it. The driver is totally unsupported by Cicso and hasn't been updated by them since its initial issuance. Next is this driver by design is extremely difficult to uninstall. It's associated device registry key must be manually deleted. This registry key resides in an area where all installed device drivers exist. If one misidentifies the MBRFilter device driver registry key and deletes something else there, the likelihood of a Windows blue screen at system startup is quite high. You have been forewarned.

In my prior postings on this subject, I suggested Eset use this driver and incorporate into Eset security products. Obviously, this hasn't been done. Why? One obvious reason is MBRFilter is a Windows  mini-port filter device driver. Microsoft has deprecated the use of mini-port filter device drivers over the recommended use of the Windows Filtering Platform (WFP).

However, "one time in the not too distant past" Eset drivers were mini-port filter drivers. Eset subsequently converted those drivers to use WFP. Therefore, Eset certainly has the expertise to convert this MBRFilter mini-port device driver to use WFP.  It just needs the impetus to do so.

Edited April 26, 2023 by itman

[Marcos 5,069]

That "Virus_Destructive" by MalwareStudio is detected as MSIL/KillFiles.BU trojan.

[itman 1,659]

2 hours ago, Marcos said:

That "Virus_Destructive" by MalwareStudio is detected as MSIL/KillFiles.BU trojan.

I'm confused. I didn't see any Eset detection alert in the video. It also appears the MBR was trashed. Are you stating OP excluded the .exe from Eset real-time detection?

[Marcos 5,069]

3 hours ago, itman said:

I'm confused. I didn't see any Eset detection alert in the video. It also appears the MBR was trashed. Are you stating OP excluded the .exe from Eset real-time detection?

I took the source files from a video at youtube, compiled an executable and scanned it. It was detected as I mentioned above. If there's another undetected variant, we kindly ask the OP to submit it to samples[at]eset.com.

[itman 1,659]

10 hours ago, Marcos said:

I took the source files from a video at youtube

Can also be downloaded from here: https://github.com/MalwareStudio/Virus_Destructive .

[Dmitry228 1]

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

[Dmitry228 1]

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

Edited April 27, 2023 by Dmitry228

[Marcos 5,069]

It could not be detected by LiveGuard because it required the user to click a button to rin the app.

[Dmitry228 1]

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

[itman 1,659]

Rather than "tip toeing through the destruction tulips" as Metler.B does, just employ a disk wiper as noted here: https://attack.mitre.org/techniques/T1561/001/ .

Of note is RawDisk use;

Quote

RawDisk is a legitimate commercial driver from the EldoS Corporation that is used for interacting with files, disks, and partitions. The driver allows for direct modification of data on a local computer's hard drive. In some cases, the tool can enact these raw disk modifications from user-mode processes, circumventing Windows operating system security features

https://attack.mitre.org/software/S0364/

[SeriousHoax 83]

1 hour ago, Marcos said:

It could not be detected by LiveGuard because it required the user to click a button to rin the app.

If it's that easy to evade LiveGuard then I have to say that LiveGuard seems very basic and ineffective. There are emulators/sandbox out there that can simulate user clicks. There are also malware that tries to fool such sandbox's but countermeasure can be taken to detect such evasion techniques which would indicate that the file is malicious. You can read all about it and much more here:

https://evasions.checkpoint.com/techniques/human-like-behavior.html#check-mouse-movement:~:text=a sample emulation.-,2.2. Check via a request for user interaction,-Some malware samples

It doesn't make much sense to charge premium price for LiveGuard when it can't even do this. LiveGuard would give safe verdict to such samples and users may end up getting infected. Samples marked as safe by LiveGuard probably aren't sent to malware analysts, so till they get their hands on such samples, it's a lost cause. There's a huge room for improvements here for ESET.

[itman 1,659]

2 hours ago, SeriousHoax said:

https://evasions.checkpoint.com/techniques/human-like-behavior.html#check-mouse-movement:~:text=a sample emulation.-,2.2. Check via a request for user interaction,-Some malware samples

Great find!

Personally, I never expected endpoint AV cloud sandbox solutions to be on par with those used by EDR solutions such as those mentioned in the article. Add CloudSriike Falcon to that list.

I view LiveGuard as better as what existed previously which was no cloud scanning. On par with what exists in MD Home version. My main complaint about it is I can't configure it to be more aggressive as can be done with LiveGuard Advanced including user decision on suspicious detection's.

Edited April 27, 2023 by itman