Jump to content

facingthesea

Members
 View Profile  See their activity

  • Posts

    26

  • Joined

  • Last visited

 Content Type 

Posts posted by facingthesea

    ESET need realy an antiCryptor module

    in Malware Finding and Cleaning

    Posted

    On 7/7/2021 at 2:58 AM, itman said:

    Actually, almost all the major AV solutions have some form of protected folders protection presently.

    Most employ "bait" files within the protected folders which act as "triggers" when encrypted to alert that abnormal encryption activities are taking place. At most, only a few files get encrypted before detection takes place. Some AV products like Kaspersky due to their system snapshot capability can actually restore the few files that end up encrypted. Note that this concept is not "bullet proof" and a dedicated APT actor employing a targeted attack can bypass it. However, it does take a bit of work to do so.

    My take is that Eset doesn't want to get involved with the protected folder approach due to the incessant user requests that will follow due to legit processes being blocked access to the protected folders. There also might a legal liability element here. If ransomware was successfully performed on a network employing protected folders, I would suspect the plaintiff's lawyers would have a better case for damages against the AV concern.  

    These "bait" files can use special file names to make them the first to be encrypted.

    Remind users not to open them or set hidden attributes for them.

    This technique used by many AVs effectively prevents ransomware and rarely causes unnecessary user requests.

    At least, it can be used in personal products.

    As for the legal issue you mentioned, the "bait" files does not need to appear in the form of a "protected folder" function, but only as a means of detection.

    Rootkit

    in Malware Finding and Cleaning

    Posted · Edited by facingthesea

    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.

    Rootkit

    in Malware Finding and Cleaning

    Posted

    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?

    Rootkit

    in Malware Finding and Cleaning

    Posted

    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

    Rootkit

    in Malware Finding and Cleaning

    Posted

    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-

     

     

    Rootkit

    in Malware Finding and Cleaning

    Posted

    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.

     

    Rootkit

    in Malware Finding and Cleaning

    Posted

    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.

    Rootkit

    in Malware Finding and Cleaning

    Posted · Edited by facingthesea

    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

    Rootkit

    in Malware Finding and Cleaning

    Posted

    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.

    Rootkit

    in Malware Finding and Cleaning

    Posted

    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.

    Rootkit

    in Malware Finding and Cleaning

    Posted

    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.

     

    Rootkit

    in Malware Finding and Cleaning

    Posted

    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.

    Rootkit

    in Malware Finding and Cleaning

    Posted

    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

    Rootkit

    in Malware Finding and Cleaning

    Posted

    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?

    Rootkit

    in Malware Finding and Cleaning

    Posted

    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?

    Rootkit

    in Malware Finding and Cleaning

    Posted

    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.)

    Rootkit

    in Malware Finding and Cleaning

    Posted · Edited by facingthesea

    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.

    1730024029_2021-07-11224041.thumb.png.769dbc8789b232f5b0e78585c4ad36f2.png

     

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

    99348897_2021-07-11235427.thumb.png.a28976d4c51619d8775cbc11d5700366.png

     

    Mini Filter

     

    18463868_2021-07-11232238.thumb.png.b8ce14820e138b2126db4cb71e77ffec.png

     

    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.

×
×
  • Create New...