The operators behind the RobbinHood ransomware are using a vulnerable, legacy driver from Taiwan-based motherboard manufacturer Gigabyte in order to get around antivirus protections. The “bring-your-own-bug” tactic is likely to crop up in other attacks going forward, according to security analysts.
According to research from Sophos, the driver has a known vulnerability (CVE-2018-19320), and was discontinued in 2018 by the company. However, the Verisign certificate used to digitally sign the driver has not been revoked, so the signature remains valid.
“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,” the researchers explained, in an analysis posted late last week.
Bring Your Own Vulnerability
RobbinHood ransomware is best-known for being the culprit behind the encryption attack on the City of Baltimore in 2019. The threat actors now have a new tactic.
Specifically, they’re updating the Windows kernel in-memory with the Gigabyte driver, according to the research – and the kernel accepts it as a “patch” thanks to the signed certificate. Once that’s loaded, they can then exploit that driver using the known vulnerability in order to load their own, unsigned, malicious driver.
Using the Gigabyte driver saves the attackers time and headaches, Sophos noted.
“64-bit Windows…only allows drivers to be loaded that have been properly signed by both the manufacturer and Microsoft,” according to the analysis. “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.”
The properly signed Gigabyte driver on the other hand will be easily accepted by Windows. And it just so happens to contain 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 – on-the-fly, in kernel memory. [They do this] by changing a single variable (a single byte) that lives in kernel space….Once driver signature enforcement is disabled, the attackers are able to load their unsigned malicious driver,” said researchers.
That second driver is tasked with defanging security applications from the kernel space. It “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,” researchers explained.
The Kernel Subversion
During the attack, the cybercriminals are subverting a setting in kernel memory on Windows 7, Windows 8 and Windows 10. To do this, the RobbinHood malware makes use of a process called STEEL.EXE, which in turn uses several different files to carry out its task – all of which are extracted to the Windows Temp folder during the initial infection.
First, the STEEL.EXE application deploys ROBNR.EXE. This is the application that drops and installs both the vulnerable Gigabyte driver (GDRV.SYS) but also the second, malicious driver (RBNL.SYS). After that, STEEL.EXE reads a text file, named PLIST.TXT, for further instructions.
PLIST.TXT contains a list of processes and their associated files that the malicious driver is tasked with destroying, researchers said; and because the text file is not embedded in STEEL.EXE, it may be tailored to the victim’s environment.
The malicious driver has various ways to delete files, and it runs all of them in sequence to cover all the bases, according to the firm.
“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) directly on the NTFS.SYS storage device,” according to the writeup. “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.”
After the file-deletion process is complete, the malicious driver ends the STEEL.EXE process, and the ransomware portion of the malware is free to encrypt files without being hindered by security products.
An Attack with Staying Power
Killing such security processes from kernel mode offers plenty of upside for the attackers, Sophos noted — and as such, it’s a technique that’s likely to show up in other campaigns.
“Endpoint protection processes that rely on object handle filtering for their tamper protection cannot prevent a kernel mode termination of processes or deletion of files,” the researchers wrote. “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.”
Going forward, researchers noted that the technique can be replicated using a range of buggy drivers, as long as they allow arbitrary read/write in kernel.
“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,” they wrote. “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.”
Learn how Operational Technology and Information Technology systems are merging and changing security playbooks in this free Threatpost Webinar. Join us Wednesday, Feb. 19 at 2 p.m. ET when a panel of OT and IT security experts will discuss how this growing trend is shaping security approaches for IoT and 5G rollouts. This webinar is for security and DevOps engineers, IoT edge developers and security executives.
