{"id":17654,"date":"2020-02-06T09:20:58","date_gmt":"2020-02-06T17:20:58","guid":{"rendered":"https:\/\/www.palada.net\/index.php\/2020\/02\/06\/news-11389\/"},"modified":"2020-02-06T09:20:58","modified_gmt":"2020-02-06T17:20:58","slug":"news-11389","status":"publish","type":"post","link":"http:\/\/www.palada.net\/index.php\/2020\/02\/06\/news-11389\/","title":{"rendered":"Living off another land: Ransomware borrows vulnerable driver to remove security software"},"content":{"rendered":"

Credit to Author: Andrew Brandt| Date: Thu, 06 Feb 2020 15:22:24 +0000<\/strong><\/p>\n

\n

Sophos has been investigating two different ransomware attacks where the adversaries deployed a legitimate, digitally signed hardware driver in order to delete security products from the targeted computers just prior to performing the destructive file encryption portion of the attack.<\/p>\n

The signed driver, part of a now-deprecated software package published by Taiwan-based motherboard manufacturer Gigabyte, has a known vulnerability, tracked as CVE-2018-19320<\/a>. The vulnerability, published along with proof-of-concept code in 2018<\/a> and widely reported at the time<\/a>, was disclaimed by the company, who told the researcher who tried to report the bug that “its products are not affected by the reported vulnerabilities.” The company later recanted, and has discontinued using the vulnerable driver, but it still exists, and it apparently remains a threat.<\/p>\n

Neither Microsoft nor Verisign, whose code signing mechanism was used to digitally sign the driver, have revoked the signing certificate, so the Authenticode signature remains valid.<\/p>\n

In this attack scenario, the criminals have used the Gigabyte driver as a wedge so they could load a second, unsigned driver into Windows. This second driver then goes to great lengths to kill processes and files belonging to endpoint security products, bypassing tamper protection, to enable the ransomware to attack without interference.<\/p>\n

\"\"<\/p>\n

This is the first time we have observed ransomware shipping a Microsoft co-signed (yet vulnerable) third party driver to patch the Windows kernel in-memory, load their own unsigned malicious driver, and take out security applications from kernel space. The ransomware that was being installed in both instances calls itself RobbinHood<\/strong>.<\/p>\n

Ransomware trying to circumvent security products is not new. For example, Nemty kills processes and services<\/a> using regular taskkill, and Snatch ransomware figured out how to reboot PCs into Safe Mode<\/a> to get around endpoint protection. Obviously, doing the process killing from kernel mode has a lot of advantages.<\/p>\n

This article takes a deep dive on how the attackers do it. We’re publishing this information now so other defenders can anticipate and enact defenses against this novel attack, where adversaries bring a vulnerable third party driver to subvert the Windows kernel, terminate defenses, and encrypt files unhindered by endpoint protection software.<\/p>\n

Attacking Windows defenses<\/h2>\n

We’ve recently seen the RobbinHood ransomware family perform this strategy to encrypt files without being hindered by endpoint protection software. They successfully subvert a setting in kernel memory on Windows 7, Windows 8 and Windows 10.<\/p>\n

Without diving into the ransomware or data encryption itself, we\u2019re going to focus on the module with which the adversaries can kill encountered endpoint protection software. This part of the attack consists of several files embedded in STEEL.EXE<\/strong>. All of these files are extracted to C:WINDOWSTEMP<\/p>\n

 <\/p>\n

STEEL.EXE<\/h3>\n

The STEEL.EXE application kills the processes and deletes the files of security applications. In order to do this, STEEL.EXE deploys a driver. The driver runs in kernel mode and is therefore optimally positioned to take out processes and files without being hindered by security controls like endpoint protection. Even though they run under NT AUTHORITY\/SYSTEM, most parts of an endpoint security product run in user space.<\/p>\n

The STEEL.EXE application first deploys ROBNR.EXE, which installs the malicious unsigned driver RBNL.SYS.<\/p>\n

Once this driver is installed, STEEL.EXE reads the PLIST.TXT file and instructs the driver to delete any application listed in PLIST.TXT, then killing their associated processes. If the process was running as a service, the service can no longer automatically restart as the associated file has been deleted.<\/p>\n

Once the STEEL.EXE process exits, the ransomware program can perform its encryption attack without being hindered by the security applications that have been taken out decisively.<\/p>\n

ROBNR.EXE<\/h3>\n

This application is dropped to the disk by STEEL.EXE. This is a convenient application that drops and installs both the vulnerable GDRV.SYS driver, and the malicious RBNL.SYS driver.<\/p>\n

64-bit Windows computers have a mechanism called driver signature enforcement<\/em> which means that Windows only allows drivers to be loaded that have been properly signed by both the manufacturer and Microsoft. This is a requirement for all drivers in order to be loaded on 64-bit versions of Windows.<\/p>\n

The malware authors did not bother to sign their malicious driver as it involves purchasing a certificate. Also, a purchased certificate can be revoked by the certificate authority causing the driver to no longer work, as it will no longer be accepted by Windows.<\/p>\n

Instead, the malware authors chose a different route. The properly signed third party GDRV.SYS driver contains a privilege escalation vulnerability as it allows reading and writing of arbitrary memory. The malware authors abuse this vulnerability in order to (temporarily) disable driver signature enforcement in Windows \u2013 on-the-fly, in kernel memory. Once driver signature enforcement is disabled, the attackers are able to load their unsigned malicious driver.<\/p>\n

Disabling Driver Signature Enforcement<\/h3>\n

The attackers are able to disable driver signature enforcement by changing a single variable (a single byte) that lives in kernel space. On Windows 7 (or older), this variable is called nt!g_CiEnabled<\/strong> (NTOSKRNL.EXE). On Windows 8 and 10, this variable is called ci!g_CiOptions<\/strong> (CI.DLL). In order to resolve the location of this variable, the attackers use a strategy taken from DSEFix<\/a>.<\/p>\n

On Windows 8 or 10, the trick starts by loading the standard Windows component CI.DLL as a data library using DONT_RESOLVE_DLL_REFERENCES<\/strong> in their process. Once CI.DLL is loaded, they query the location of CI.DLL in kernel memory via the GetModuleBaseByName function. It uses NtQuerySystemInformation<\/strong>(SystemModuleInformation<\/em> \u2026) to get the kernel addresses of all loaded kernel modules.<\/p>\n

\"\"
Decompiled: Showing how the variable is found that controls Driver Signing Enforcement.<\/figcaption><\/figure>\n

 <\/p>\n

 <\/p>\n

 <\/p>\n

 <\/p>\n

\"\"
Decompiled: Showing how to get a module’s kernel address.<\/figcaption><\/figure>\n

Once they know those kernel addresses, the attackers resolve the exported CiInitialize<\/strong> function from the module’s export address table<\/em>.Then they disassemble the instructions of that function in order to find the call CipInitialize()<\/strong> instruction. Once that function is found, they look for the mov dword ptr [address],ecx<\/strong> instruction. That address is g_CiOptions<\/strong> as shown in the figure below.<\/p>\n

\"\"
Decompiled: Showing how to find the location of g_CiOptions using the HDE disassembler.<\/figcaption><\/figure>\n

Now that they know the location of the g_CiOptions<\/strong> variable in kernel space, the vulnerable third party driver is dropped to disk and started. See this article on the exact vulnerability<\/a>. Any vulnerable driver that allows arbitrary read\/write in kernel will do. So even though the attackers are using the GDRV.SYS driver to do this today, there’s no reason they will continue to use it if it becomes untenable to do so.<\/p>\n

There are many other vulnerable drivers (with a similar vulnerability) in addition to the Gigabyte driver that these or other attackers may choose to abuse later, such as ones from VirtualBox (CVE-2008-3431), Novell (CVE-2013-3956), CPU-Z (CVE-2017-15302), or ASUS (CVE-2018-18537). But in these attacks, we’ve only seen the Gigabyte driver being abused in this way.<\/p>\n

\"\"
Decompiled: Showing how the malicious driver is deployed.<\/figcaption><\/figure>\n

The malicious driver<\/h2>\n

Once the malicious driver is successfully deployed and started, the ROBNR.EXE process exits. Then STEEL.EXE starts processing the PLIST.TXT file, listing all the applications to kill.<\/p>\n

This malicious kernel driver is used to terminate processes and delete the associated files. It employs several tricks to kill these applications, even when they are in-use and protected by tamper protection mechanisms employed by security products.<\/p>\n

\"\"
Decompiled: How the malicious driver starts.<\/figcaption><\/figure>\n
\"\"
Decompiled: How the malicious driver processes commands (IOCTL) from STEEL.EXE.<\/figcaption><\/figure>\n

The following string was found in the malicious driver, indicating it was likely built by the same authors behind the RobbinHood ransomware.<\/p>\n

C:UsersMikhailDesktopRobnholdx64Win7ReleaseRobbnhold.pdb<\/pre>\n
Deleting Files<\/h2>\n
The malicious driver has various ways to delete files. But it does not pick one way, it runs them all sequentially, in order to ensure the file really gets deleted.<\/p>\n
To delete files that are in-use the malicious driver issues an I\/O Request Packet (or IRP, a low-level message passed between device drivers<\/a>) directly on the NTFS.SYS storage device. By clearing the ImageSectionObject and DataSectionObject pointers, the storage device assumes the files are not in-use and the file is safely deleted, even when the file is still running as a process!<\/p>\n
This trick is similar to the technique mentioned on this blog post<\/a>.<\/p>\n
\"\"
Decompiled: The malicious driver uses multiple ways to delete a file.<\/figcaption><\/figure>\n
\"\"
Decompiled: How the malicious driver deletes a file that is in-use.<\/figcaption><\/figure>\n
Terminating Processes<\/h2>\n
Once the files are deleted, STEEL.EXE kills all the processes associated with the files. Again, it uses its malicious kernel driver to terminate the processes.<\/p>\n
\"\"
Decompile: How the malicious driver terminates a process.<\/figcaption><\/figure>\n
Endpoint protection processes that rely on object handle filtering<\/a> for their tamper protection cannot prevent a kernel mode termination of processes or deletion of files. The process handles opened by the malicious driver are kernel handles, and kernel handles cannot be filtered. So, the malicious kernel driver can kill these processes without interference of endpoint security controls. One solution is for the endpoint protection process to watch for any process trying to install these vulnerable kernel mode drivers, and prevent the installation from taking place.<\/p>\n
If the process was running as a service, the Service Control Manager of Windows will (usually) try to restart the process that just got killed. But it will fail to do so as the related file no longer exists. Consequently, the application is effectively and permanently disabled. The failed attempts to restart the service show up in Event Logs.<\/p>\n
When STEEL.EXE has killed all the processes and files in the PLIST.TXT list, it exits. Now the ransomware can encrypt all the files on the system unhindered.<\/p>\n
What users can do to prevent this type of attack<\/h2>\n
Computers that are fully patched and have no known vulnerabilities can still end up in ruin because this attacker brings his own vulnerability. So what can you do to prevent the initial access by the attacker?<\/p>\n
Adopt a three-pronged approach to minimize your risk of falling victim to an attack.<\/p>\n
1. Threat protection that disrupts the whole attack chain<\/h3>\n
Today’s ransomware attacks use multiple techniques and tactics, so focusing your defense on a single technology leaves you very vulnerable.
 Instead, deploy a range of technologies to disrupt as many stages in the attack as possible. And integrate the public cloud into your security strategy.<\/p>\n
2. Strong security practices<\/h3>\n
These include:<\/p>\n