Jump to content

Rootkit


Recommended Posts

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.

I had done a system restart.

 

In fact, this rootkit will only be fully installed after restarting, and many anti-virus softwares can easily remove it before restarting.Unfortunately, I did not test ESET in this situation.

Sorry I forgot to mention this before, it may be helpful to your analysis.

@Marcos

Edited by facingthesea
Link to comment
Share on other sites

  • Most Valued Members

Yeah the problem with these tests is it helps to know everything. E.g. was an AV installed when downloading and installing. It's important to note most people wouldn't remove an AV to install something.

This is why I'm also very wary of a YouTube testers because it's often what you don't see rather than what you don't e.g. has the AV been updated and has any changes been made to settings and options. I've seen a lot of YouTubers download something that AVs seem to miss but they don't show they disabled the AVs Web protection that would have blocked it from being downloaded in the first place 

Link to comment
Share on other sites

32 minutes ago, peteyt said:

Yeah the problem with these tests is it helps to know everything. E.g. was an AV installed when downloading and installing. It's important to note most people wouldn't remove an AV to install something.

This is why I'm also very wary of a YouTube testers because it's often what you don't see rather than what you don't e.g. has the AV been updated and has any changes been made to settings and options. I've seen a lot of YouTubers download something that AVs seem to miss but they don't show they disabled the AVs Web protection that would have blocked it from being downloaded in the first place 

Quote

It's important to note most people wouldn't remove an AV to install something.

In addition to this situation, there are other reasons that may cause rootkits to be installed.

Imagine the following two situations:

1. A rookit is installed before the AV.

2. The anti-virus software did not detect a rootkit at the beginning, so the rootkit was installed, and then the AV updated the database to detect the rootkit, but because of the rootkit’s self-protection, the AV could not clean it, or even scan its files.

Link to comment
Share on other sites

1 hour ago, peteyt said:

Yeah the problem with these tests is it helps to know everything. E.g. was an AV installed when downloading and installing. It's important to note most people wouldn't remove an AV to install something.

This is why I'm also very wary of a YouTube testers because it's often what you don't see rather than what you don't e.g. has the AV been updated and has any changes been made to settings and options. I've seen a lot of YouTubers download something that AVs seem to miss but they don't show they disabled the AVs Web protection that would have blocked it from being downloaded in the first place 

Thanks for your reply.🙂

I followed the whole testing process and as a viewer I would say the facingthesea himself followed the steps but unfortunately the antivirus did detect but could not remove the virus with SafeBoot and ELAM settings turned on, I don't want to be too blunt, but there may be a small problem with the software in terms of detection.🙂

Link to comment
Share on other sites

2 hours ago, peteyt said:

Yeah the problem with these tests is it helps to know everything. E.g. was an AV installed when downloading and installing. It's important to note most people wouldn't remove an AV to install something.

This is why I'm also very wary of a YouTube testers because it's often what you don't see rather than what you don't e.g. has the AV been updated and has any changes been made to settings and options. I've seen a lot of YouTubers download something that AVs seem to miss but they don't show they disabled the AVs Web protection that would have blocked it from being downloaded in the first place 

😂Sorry Sir, I made a mistake: it's not that it can't be removed, it's that the antivirus can't detect the virus directly after it's been infected, because the antivirus can't read that driver file. (Thanks to the author for the correction🤣)

 

P.S. : Why can't I edit a reply after a few minutes after posting it?

Edited by ReinaKirisame
Link to comment
Share on other sites

10 hours ago, facingthesea said:

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

Then you disabled Secure Boot since it would not allow the PC to boot when trying to load this driver.

Link to comment
Share on other sites

10 minutes ago, itman said:

Then you disabled Secure Boot since it would not allow the PC to boot when trying to load this driver.

I made it clear in the previous post that I enabled secure boot.

1535924256_2021-07-11224235.thumb.png.1770fa94bc2dd32e499cddd254f405e4.png

This is a screenshot at the time, but you may not understand Chinese.

 

Link to comment
Share on other sites

10 minutes ago, itman said:

Again unless you provide the driver to @Marcos for his testing, there is no way to verify anything you posted to date is the truth.

I have provided the driver through this topic and mail.

Link to comment
Share on other sites

9 minutes ago, facingthesea said:

I made it clear in the previous post that I enabled secure boot.

Sorry, I don't believe you anymore.

If the rootkit driver was signed with a revoked cert., Secure Boot would have prevented your device from booting:

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

Link to comment
Share on other sites

2 minutes ago, itman said:

Sorry, I don't believe you anymore.

If the rootkit driver was signed with a revoked cert., Secure Boot would have prevented your device from booting:

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

This VM is running and I enabled secure boot.

 

20245201_2021-07-13210045.thumb.png.6fa5b4d14529baac85c2dfe321d55558.png

Quote

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.

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

 

The driver is loaded by the operating system and it follows the Driver Signing Policy.

https://docs.microsoft.com/en-us/windows-hardware/drivers/install/kernel-mode-code-signing-policy--windows-vista-and-later-

 

 

Link to comment
Share on other sites

18 minutes ago, itman said:

Sorry, I don't believe you anymore.

If the rootkit driver was signed with a revoked cert., Secure Boot would have prevented your device from booting:

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

1138197965_2021-07-02231147.thumb.png.9677d43d0f2a18c3b78ee23e216bde55.png

Link to comment
Share on other sites

Let me explain the test environment I use again, please don't ask repeated questions:

  • a Hyper-V virtual machine with Secure Boot enabled
  • Windows LTSC 2019 17763.2028
  • set
    Computer Configuration\Administrative Templates\System\Early Launch Antimalware
    to
    Good only
    in gpedit.msc or use the default settings
  • ESET Internet Security 14.2.19 with pre-release update enabled
Link to comment
Share on other sites

Let's try to end this discussion once and for all.

Assume Secure Boot is enabled. This means the driver loaded sometime after the boot phase.

Is it possible to dynamically load a kernel mode driver after boot time? Yes it is. A prime example of this is SysInternals Process Explorer that many use. Windows based driver protection only requires that a valid signed .sys file exists in C:\Windows\System32\Drivers directory. Further Windows will not allow by default a non-valid signed ,sys file to be created in that directory.

However, there is a Windows mechanism built in that will allow for a non-valid signed ,sys file to be created in C:\Windows\System32\Drivers directory. This was an accommodation to old systems that may be using drivers that don't conform to Microsoft's driver signing requirements. And this setting is contained in the registry.

Next and of note is how this supposed rootkit driver was installed on the test device:

Quote

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.

The above alone is enough to discontinue further discussion since it is not disclosed in detail what went on when this script ran.

In any case, the .sys file would have to be created in the C:\Windows\System32\Drivers directory for Windows to dynamically load a kernel mode driver. It has already been disclosed that Eset detects the rootkit .sys by signature. Therefore and again, it has to be assumed Eset was disabled when the .bat script ran and created the .sys file. It is also assumed that Windows driver signing requirement checking was also disabled by the script since Windows would have blocked creation of the .sys file in C:\Windows\System32\Drivers directory.

Edited by itman
Link to comment
Share on other sites

10 minutes ago, itman said:

Let's try to end this discussion once and for all.

Assume Secure Boot is enabled. This means the driver loaded sometime after the boot phase.

Is it possible to dynamically load a kernel mode driver after boot time? Yes it is. A prime example of this is SysInternals Process Explorer that many use. Windows based driver protection only requires that a valid signed .sys file exists in C:\Windows\System32\Drivers directory. Further Windows will not allow by default a non-valid signed ,sys file to be created in that directory.

However, there is a Windows mechanism built in that will allow for a non-valid signed ,sys file to be created in C:\Windows\System32\Drivers directory. This was an accommodation to old systems that may be using drivers that don't conform to Microsoft's driver signing requirements. And this setting is contained in the registry.

Next and of note is how this supposed rootkit driver was installed on the test device:

The above alone is enough to discontinue further discussion since it is not disclosed in detail what went on when this script ran.

In any case, the .sys file would have to be created in the C:\Windows\System32\Drivers directory for Windows to dynamically load a kernel mode driver. It has already been disclosed that Eset detects the rootkit .sys by signature. Therefore and again, it has to be assumed Eset was disabled when the .bat script ran and created the .sys file. It is also assumed that Windows driver signing requirement checking was also disabled by the script since Windows would have blocked creation of the .sys file in C:\Windows\System32\Drivers directory.

 

The bat is included in the attachment to my post. It is very simple:

sc create c29275bfe6 binpath= %~dp0\c29275bfe6.sys type= kernel start= demand error= ignore
regedit /s %~dp0\data.reg
sc start c29275bfe6
pause

The registry that it imports is only rootkit data and does not modify other settings. It is also included in the attachment.

You should turn to the first post on this topic and take a look. Or, attachments are only visible to uploaders and administrators?

Link to comment
Share on other sites

18 minutes ago, itman said:

Let's try to end this discussion once and for all.

Assume Secure Boot is enabled. This means the driver loaded sometime after the boot phase.

Is it possible to dynamically load a kernel mode driver after boot time? Yes it is. A prime example of this is SysInternals Process Explorer that many use. Windows based driver protection only requires that a valid signed .sys file exists in C:\Windows\System32\Drivers directory. Further Windows will not allow by default a non-valid signed ,sys file to be created in that directory.

However, there is a Windows mechanism built in that will allow for a non-valid signed ,sys file to be created in C:\Windows\System32\Drivers directory. This was an accommodation to old systems that may be using drivers that don't conform to Microsoft's driver signing requirements. And this setting is contained in the registry.

Next and of note is how this supposed rootkit driver was installed on the test device:

The above alone is enough to discontinue further discussion since it is not disclosed in detail what went on when this script ran.

In any case, the .sys file would have to be created in the C:\Windows\System32\Drivers directory for Windows to dynamically load a kernel mode driver. It has already been disclosed that Eset detects the rootkit .sys by signature. Therefore and again, it has to be assumed Eset was disabled when the .bat script ran and created the .sys file. It is also assumed that Windows driver signing requirement checking was also disabled by the script since Windows would have blocked creation of the .sys file in C:\Windows\System32\Drivers directory.

It is late at night in Beijing time, so I may not reply to you afterwards.

Edited by facingthesea
Link to comment
Share on other sites

  • Administrators

It appears that everything has been said and continuing the topic makes no sense for other users either. Having said that, we'll draw it to a close.

Link to comment
Share on other sites

  • Marcos locked this topic
Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...