Rootkit

[facingthesea 0]

Hi Dear ESET Admins.

Sorry,I'm not good at English, so I may make some grammatical mistakes.

Some netizens shared a Rootkit that locks the browser start page and invites everyone to test whether anti-virus softwares can clear it after it is installed.

 

I tested ESET and ESET couldn't even open its files.

 

Mini Filter

 

 

After I set

Computer Configuration\Administrative Templates\System\Early Launch Antimalware

to

Good only

in gpedit.msc and restarted, the rootkit will be still loaded.

Under what circumstances does ESET's ELAM driver work?

 

run_bat.zip

Password: infected

 

When the rootkit is not installed, ESET detects it as Generik.MVDZQHX.

ESET cannot detect it after it is installed.

Edited July 12, 2021 by facingthesea

[Marcos 5,074]

Please supply the executable that installs the driver to samples[at]eset.com along with a link to this topic.

[facingthesea 0]

21 minutes ago, Marcos said:

Please supply the executable that installs the driver to samples[at]eset.com along with a link to this topic.

The driver and registry are extracted from the infected computer, so I don’t have the executable that installs the driver.

The compressed package contains a bat file for importing the registry and installing the driver. This driver is the main body of the malware.

Is this OK?

（Excuse me, I'm not good at English, and I don’t know if this tone is offensive.)

[facingthesea 0]

1 hour ago, Marcos said:

Please supply the executable that installs the driver to samples[at]eset.com along with a link to this topic.

There is another question.

Under what circumstances does ESET's ELAM driver work?

[Marcos 5,074]

1 hour ago, facingthesea said:

There is another question.

Under what circumstances does ESET's ELAM driver work?

The driver is required on Windows 10 for ekrn to load other modules.

[facingthesea 0]

1 hour ago, Marcos said:

The driver is required on Windows 10 for ekrn to load other modules.

So it does not check whether other drivers are malicious before they are loaded?

[Marcos 5,074]

It's ekrn.exe which scans files for threats.

[facingthesea 0]

5 minutes ago, Marcos said:

It's ekrn.exe which scans files for threats.

 

Will ekrn scan the drivers before they are loaded?

[Marcos 5,074]

21 minutes ago, facingthesea said:

 

Will ekrn scan the drivers before they are loaded?

After it starts it can scan any files, including drivers. A driver itself cannot scan files or drivers.

[ReinaKirisame 0]

Hello admin, I am a user who watched the whole test and there may not be enough clarity on facingthesea's question. What I want to ask is, does ekrn detect any driver (normal or not) before it is loaded?

[facingthesea 0]

1 hour ago, Marcos said:

After it starts it can scan any files, including drivers. A driver itself cannot scan files or drivers.

Thank you for your quick replies.

My previous questions may not be very clear.

1. I know that the ELAM driver starts before other third-party components (including drivers), so does ekrn also start before other third-party components?

For example, the rootkit in this post. After the rootkit starts, erkn won't be able to scan it, so will ekrn scan it before the rootkit starts?

2. Will ekrn send the scan results to the operating system to prevent malicious drivers from starting according to the

Computer Configuration\Administrative Templates\System\Early Launch Antimalware

in the group policy?

Or does ESET have another similar setting?

 

All in all, does ESET have some mechanism to prevent rootkits from starting at boot time?

[itman 1,659]

Here's the deal on ELAM driver scanning by all AV's that deploy it including Windows Defender.

The ELAM driver is one of the first drivers to load after all device drivers load. The reason for this is fairly obvious; Windows has not even fully loaded yet. The only thing that can examine device drivers on loading is the Win 10 Secure Boot feature. First, your hardware has to support Secure Boot and the feature has to be enabled.

If this rootkit is device driver based; assumed to be kernel based; and loads at boot time, you're out of luck as to any ELAM driver based detection. This is more so on old BIOS based systems that do not employ a UEFI. On UEFI based systems, Eset can scan it for malicious device drivers but cannot remove them.

Edited July 12, 2021 by itman

[facingthesea 0]

27 minutes ago, itman said:

Here's the deal on ELAM driver scanning by all AV's that deploy it including Windows Defender.

The ELAM driver is one of the first drivers to load after all device drivers load. The reason for this is fairly obvious; Windows has not even fully loaded yet. The only thing that can examine device drivers on loading is the Win 10 Secure Boot feature. First, your hardware has to support Secure Boot and the feature has to be enabled.

If this rootkit is device driver based; assumed to be kernel based; and loads at boot time, you're out of luck as to any ELAM driver based detection. This is more so on old BIOS based systems that do not employ a UEFI. On UEFI based systems, Eset can scan it for malicious device drivers but cannot remove them.

1. I tested it on a Hyper-V virtual machine with Secure Boot enabled.

2. For this rootkit, ESET can't even scan it (can't open its files), not just can't clean it.

3.

Quote

The ELAM driver is one of the first drivers to load after all device drivers load.

Can you provide an authoritative source for this?

The Microsoft documentation says this:

Quote

The ELAM feature provides a Microsoft-supported mechanism for antimalware (AM) software to start before other third-party components. AM drivers are initialized first and allowed to control the initialization of subsequent boot drivers, potentially not initializing unknown boot drivers. Once the boot process has initialized boot drivers and access to persistent storage is available in an efficient way, existing AM software may continue to block malware from executing.

https://docs.microsoft.com/en-us/windows-hardware/drivers/install/early-launch-antimalware

[facingthesea 0]

49 minutes ago, itman said:

Here's the deal on ELAM driver scanning by all AV's that deploy it including Windows Defender.

The ELAM driver is one of the first drivers to load after all device drivers load. The reason for this is fairly obvious; Windows has not even fully loaded yet. The only thing that can examine device drivers on loading is the Win 10 Secure Boot feature. First, your hardware has to support Secure Boot and the feature has to be enabled.

If this rootkit is device driver based; assumed to be kernel based; and loads at boot time, you're out of luck as to any ELAM driver based detection. This is more so on old BIOS based systems that do not employ a UEFI. On UEFI based systems, Eset can scan it for malicious device drivers but cannot remove them.

4. According to a test conducted by a netizen, on Windows 10 21H1, when Windows Defender is enabled, after setting

 Computer Configuration\Administrative Templates\System\Early Launch Antimalware

in Group Policy to

Good only

, this rootkit is prevented from starting.

[itman 1,659]

6 minutes ago, facingthesea said:

Can you provide an authoritative source for this?

Quote

The ELAM software feature provides a Microsoft-supported mechanism for antimalware software to start before all other third-party components.

https://docs.microsoft.com/en-us/windows-hardware/test/hlk/testref/early-launch-antimalware-testing-prerequisites

Also as far as secure boot goes, it is only checking if drivers are validly signed:

Quote

Secure boot is a security standard developed by members of the PC industry to help make sure that a device boots using only software that is trusted by the Original Equipment Manufacturer (OEM). When the PC starts, the firmware checks the signature of each piece of boot software, including UEFI firmware drivers (also known as Option ROMs), EFI applications, and the operating system. If the signatures are valid, the PC boots, and the firmware gives control to the operating system.

https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences/oem-secure-boot

Hands down, your worst malware nightmare is a validly signed device driver and they have occured previously.

[itman 1,659]

2 minutes ago, facingthesea said:

4. According to a test conducted by a netizen, on Windows 10 21H1, when Windows Defender is enabled, after setting

 Computer Configuration\Administrative Templates\System\Early Launch Antimalware

in Group Policy to

Good only

, this rootkit is prevented from starting.

Since you demand sources, please do so on your own postings.

[facingthesea 0]

2 minutes ago, itman said:

Since you demand sources, please do so on your own postings.

I can provide the source, but only if you can read Chinese.🙂

[itman 1,659]

2 hours ago, facingthesea said:

I can provide the source, but only if you can read Chinese.

The Group Policy setting you reference is described in this article: https://www.bleepingcomputer.com/tutorials/configure-early-launch-antimalware-protection/. This refers to Win 8.1 but is also applicable to Win 10.

So what does "Good" policy setting mean:

Quote

Good: The driver has been signed and has not been tampered with.

This is further attested to by the driver residing in C:\Windows\System32\Drivers directory and Secure Boot allowing the driver to load. Bottom line - all its means is the driver is validly signed.

You previously stated that "When the rootkit is not installed, ESET detects it as Generik.MVDZQHX." Why this occurs is it appears the driver contains packed or encrypted code. Eset via real-time hueristic scanning can detect this during its memory sandboxed analysis upon file creation or subsequent scan analysis. Note that this is a generic detection. That is Eset doesn't have a specific malware signature for the detection.

At this point let's pause. The above notes that the driver would have never been installed in the first place if Eset was installed. Therefore, the rootkit driver was installed prior to Eset being installed.

As to why Eset's ELAM driver doesn't detect the rootkit driver loading is it does not have a specific signature for it. Its ELAM driver is not going to perform detailed sandboxed analysis on every driver loading since it would greatly impact system startup times. It is also not going to block a kernel mode driver on a generic detection if it did perform detailed analysis on every driver loading, and take the risk of borking a device.

Assuming the WD detection at boot time claim is legit, and I am skeptical of this, it implies WD has a specific signature for the rootkit driver.

Edited July 12, 2021 by itman

[itman 1,659]

I also wonder if the rootkit you are testing is this one: https://www.bleepingcomputer.com/news/security/microsoft-admits-to-signing-rootkit-malware-in-supply-chain-fiasco/ . Of course Microsoft would be specifically blocking it now since they created the mess in the first place.

-EDIT- Eset detects the well known hashes associated with this driver shown here: https://www.gdatasoftware.com/blog/microsoft-signed-a-malicious-netfilter-rootkit

However, there appears to many variants of it: https://docs.google.com/spreadsheets/d/1FYgBmJH8MOli99oIqRsIHJA2XzI3aSdAOb9mZmqj_q0/edit#gid=1028909258

Edited July 12, 2021 by itman

[itman 1,659]

One final comment and I am done here. I appear to have overlooked the obvious and could have saved myself a lot of typing.

You already stated that Eset detects this rootkit .sys file. This also implies that at some point in your testing, your have whitelisted this file from Eset real-time detection. This also would have excluded the .sys file from any ELAM driver detection.

Next, I assume you rebooted and had the rootkit load. Next, you removed the Eset real-time exclusion and shutdown the system and then started it again to see if Eset ELAM driver would block the driver from loading. Now if you had Win 10 fast startup enabled which is the default, Eset would not detect the rootkit driver. This is because with fast startup enabled, drivers are not unloaded so there is no scanning of drivers via the ELAM driver. If you however do a system restart, all drivers do reload and Eset should detect this rootkit driver. And again that's a maybe because Eset;s detection was a generic one.

[facingthesea 0]

7 hours ago, itman said:

您引用的组策略设置在这篇文章中有描述： : https //www.bleepingcomputer.com/tutorials/configure-early-launch-antimalware-protection/ 。 这指的是 Win 8.1，但也适用于 Win 10。

那么“好”策略设置是什么意思：

驻留在 C:\Windows\System32\Drivers 目录中的驱动程序和允许加载驱动程序的安全启动进一步证明了这一点。 底线 - 其所有手段是驱动程序已有效签名。

您之前曾说过“当未安装 rootkit 时，ESET 会将其检测为 Generik.MVDZQHX。” 出现这种情况的原因是驱动程序似乎包含打包或加密的代码。 Eset 通过实时色调扫描可以在文件创建或后续扫描分析的内存沙盒分析期间检测到这一点。 请注意，这是一个通用检测。 也就是说，Eset 没有用于检测的特定恶意软件签名。

在这一点上，让我们暂停一下。 上面指出如果安装了 Eset，驱动程序将永远不会被安装。 因此，rootkit 驱动程序是在安装 Eset 之前安装的。

至于为什么 Eset 的 ELAM 驱动程序没有检测到 rootkit 驱动程序加载是因为它没有特定的签名。 它的 ELAM 驱动程序不会对每个驱动程序加载执行详细的沙盒分析，因为它会极大地影响系统启动时间。 如果它确实对每个驱动程序加载进行了详细分析，它也不会在通用检测上阻止内核模式驱动程序，并冒着使设备崩溃的风险。

假设启动时的 WD 检测声明是合法的，而我对此持怀疑态度，这意味着 WD 具有针对 rootkit 驱动程序的特定签名。

If the driver starts, WD won't be able to detect it either.

This group policy prevented the driver from starting. In the subsequent manual scan, WD detected it as Trojan:Vamson.A!rfn and successfully cleared it.

 

[facingthesea 0]

7 hours ago, itman said:

The Group Policy setting you reference is described in this article: https://www.bleepingcomputer.com/tutorials/configure-early-launch-antimalware-protection/. This refers to Win 8.1 but is also applicable to Win 10.

So what does "Good" policy setting mean:

This is further attested to by the driver residing in C:\Windows\System32\Drivers directory and Secure Boot allowing the driver to load. Bottom line - all its means is the driver is validly signed.

You previously stated that "When the rootkit is not installed, ESET detects it as Generik.MVDZQHX." Why this occurs is it appears the driver contains packed or encrypted code. Eset via real-time hueristic scanning can detect this during its memory sandboxed analysis upon file creation or subsequent scan analysis. Note that this is a generic detection. That is Eset doesn't have a specific malware signature for the detection.

At this point let's pause. The above notes that the driver would have never been installed in the first place if Eset was installed. Therefore, the rootkit driver was installed prior to Eset being installed.

As to why Eset's ELAM driver doesn't detect the rootkit driver loading is it does not have a specific signature for it. Its ELAM driver is not going to perform detailed sandboxed analysis on every driver loading since it would greatly impact system startup times. It is also not going to block a kernel mode driver on a generic detection if it did perform detailed analysis on every driver loading, and take the risk of borking a device.

Assuming the WD detection at boot time claim is legit, and I am skeptical of this, it implies WD has a specific signature for the rootkit driver.

This driver has a certificate that is valid from 2012/11/6 to 2013/11/7 and has been revoked.

[ReinaKirisame 0]

15 minutes ago, facingthesea said:

此驱动程序的证书有效期为 2012/11/6 至 2013/11/7，已被吊销。

Yes, but you'd better tell us about the whole testing process, 😂 there seems to be some misunderstanding.

Edited July 13, 2021 by ReinaKirisame

[facingthesea 0]

7 hours ago, itman said:

I also wonder if the rootkit you are testing is this one: https://www.bleepingcomputer.com/news/security/microsoft-admits-to-signing-rootkit-malware-in-supply-chain-fiasco/ . Of course Microsoft would be specifically blocking it now since they created the mess in the first place.

-EDIT- Eset detects the well known hashes associated with this driver shown here: https://www.gdatasoftware.com/blog/microsoft-signed-a-malicious-netfilter-rootkit

However, there appears to many variants of it: https://docs.google.com/spreadsheets/d/1FYgBmJH8MOli99oIqRsIHJA2XzI3aSdAOb9mZmqj_q0/edit#gid=1028909258

No, this is a rootkit spread in China, known for its technology to anti antivirus software. It has been in existence for many years, and it has stopped updating. This is a relatively late version.

There is also a  cheating software that seems to be written by the same author and uses a lot of similar techniques.

[ReinaKirisame 0]

3 hours ago, itman said:

One final comment and I am done here. I appear to have overlooked the obvious and could have saved myself a lot of typing.

You already stated that Eset detects this rootkit .sys file. This also implies that at some point in your testing, your have whitelisted this file from Eset real-time detection. This also would have excluded the .sys file from any ELAM driver detection.

Next, I assume you rebooted and had the rootkit load. Next, you removed the Eset real-time exclusion and shutdown the system and then started it again to see if Eset ELAM driver would block the driver from loading. Now if you had Win 10 fast startup enabled which is the default, Eset would not detect the rootkit driver. This is because with fast startup enabled, drivers are not unloaded so there is no scanning of drivers via the ELAM driver. If you however do a system restart, all drivers do reload and Eset should detect this rootkit driver. And again that's a maybe because Eset;s detection was a generic one.

Hello Sir. one thing to note about this test is that the process is to install the rootkit in PC first and then install the antivirus to detect it. But why this is a problem we do not know.😂