Windows trust in abandoned code lets ransomware burrow deep into targeted machines
Attackers behind one of the world’s more destructive pieces of ransomware have found a new way to defeat defenses that might otherwise prevent the attack from encrypting data: installing a buggy driver first and then hacking it to burrow deeper into the targeted computer.
The ransomware in this case is RobbinHood, known for taking down the city of Baltimore networks and systems in Greenville, North Carolina. When networks aren’t protected by robust end-point defenses, RobbinHood can easily encrypt sensitive files once a vulnerability has allowed the malware to gain a toehold. For networks that are better fortified, the ransomware has a harder time.
Now, RobbinHood has found a way to defeat those defenses. In two recent attacks, researchers from security firm Sophos said, the ransomware has used its access to a targeted machine to install a driver, from Taiwan-based motherboard manufacturer Gigabyte, that has a known vulnerability in it. Despite the vulnerability that led to the driver being deprecated, it retains the cryptographic signature required for it to run in the highly sensitive Windows region known as the Kernel.
With the benign but buggy GDRV.SYS driver from Gigabyte installed, RobbinHood exploited the vulnerability to gain the ability to read and write to virtually any memory region the attackers chose. The RobbinHood exploit changed a single byte to disable the Windows requirement that drivers be signed. With that, RobbinHood installed its own unsigned driver that used its highly privileged kernel access to kill processes and files belonging to endpoint security products. The advanced status of the driver gave it greater ability than other techniques to ensure the targeted processes are permanently stopped.
The Sophos post didn’t identify the vulnerability or vulnerabilities that RobbinHood used to gain initial access to the targeted machines. In a message, however, Sophos researcher Mark Lohman said the initial exploit targeted an account with administrative privileges, a feat that allowed a file named STEEL.EXE to run. However that was achieved, the ransomware then dropped a file named STEELE.EXE onto the machine and got it to run.
Lowman and fellow Sophos researcher Andrew Brandt wrote in the post:
Without diving into the ransomware or data encryption itself, we’re 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. All of these files are extracted to C:\WINDOWS\TEMP
STEEL.EXE Kill application This is the application that kills the processes and files of security products, using kernel drivers. ROBNR.EXE Driver installer Deploys both the benign, signed third-party driver, and the criminals’ unsigned kernel driver. Once deployed, the unsigned driver gets loaded by abusing a known vulnerability in the third-party driver. GDRV.SYS Vulnerable kernel driver A benign but outdated Authenticode-signed driver that contains a vulnerability. RBNL.SYS Malicious kernel driver The malicious driver that can kill processes and delete files from kernel space. PLIST.TXT List of processes (and their associated files) to destroy This is a text file containing the names of the applications the malicious driver will kill and delete. This text file is not embedded in STEEL.EXE and may be tailored to the victim’s environment. STEEL.EXE
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.
The STEEL.EXE application first deploys ROBNR.EXE, which installs the malicious unsigned driver RBNL.SYS.
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.
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.
ROBNR.EXE
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.
64-bit Windows computers have a mechanism called driver signature enforcement 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.
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.
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 – on-the-fly, in kernel memory. Once driver signature enforcement is disabled, the attackers are able to load their unsigned malicious driver.
The vulnerability in the Gigabyte driver is tracked as CVE-2018-19320. After initially saying the driver was unaffected by the flaw, Gigabyte officials eventually acknowledged the flaw and discontinued the use of the driver. Despite the demise of the driver, it has remained signed and trusted by all supported versions of Windows.
Microsoft officials declined to speak on the record about their policy for revoking trust in software that’s deprecated for security reasons. On background, an employee with Microsoft’s outside PR firm said that generally, the company has certificates revoked only when the certificate itself has been compromised, which there’s no evidence happened in this case.
Revocations can result in serious collateral damage when other, non-vulnerable software is signed using the same certificate, the employee wrote in an email. The background statement also noted that to exploit the Gigabyte driver, an attacker would first have to compromise the targeted system.
The Sophos post said that there are other Windows-trusted drivers with known vulnerabilities that could be used the same way Gigabyte’s GDRV.SYS was used. The list included signed drivers from VirtualBox (CVE-2008-3431), Novell (CVE-2013-3956), CPU-Z (CVE-2017-15302), and ASUS (CVE-2018-18537). While the Gigabyte driver may be the first known instance, it very well may not be the last.
