Bypassing EDR through Retrosigned Drivers and System Time Manipulation

September 13, 2024 9 mins

Bypassing EDR through Retrosigned Drivers and System Time Manipulation

The Retrosigned Driver EDR Bypass is a novel modification of a technique employed by multiple ransomware groups to bypass EDR and limit visibility into malicious actions by abusing expired code signing certificates to load malicious kernel drivers.

Summary

Aon's Stroz Friedberg Incident Response Services ("Stroz Friedberg") has observed ransomware actors utilizing an Endpoint Detection and Response (“EDR”) solution bypass technique dubbed “Retrosigned Driver EDR Bypass” to terminate EDR and to limit visibility of EDR telemetry. This technique involves loading a malicious driver signed with an out-of-date code signing certificate and then manipulating the system time on the target system during the loading process. Once loaded, the driver is utilized to terminate running processes.

Background

Drivers are essential pieces of software that allow the operating system to communicate with hardware devices. They serve as a bridge between the system and the hardware, ensuring that peripheral devices like printers, graphics cards, and network adapters function correctly. Given their critical role, drivers operate with high privileges within the system, making them a prime target for malicious exploitation.

To mitigate the risks associated with driver installation, Microsoft Windows enforces a driver signing process. Driver signing involves the use of cryptographic certificates issued by trusted authorities to verify that the driver code has not been tampered with and originates from a legitimate source. This process ensures that only authorized drivers can be installed, adding a layer of security. However, when attackers find ways to bypass these protections, it opens the door for malicious drivers to be loaded, posing significant threats to system integrity.

Due to the privileged nature of kernel drivers and their potential for abuse, starting in Windows Vista, Microsoft implemented restrictions that required drivers to be signed by trusted software developers, preventing the loading of unsigned drivers. This required developers to obtain code signing certificates from a certificate authority to cryptographically attest that they were the authors of the driver being loaded. Beginning in Windows 10 1607 Microsoft tightened these requirements to only allow drivers that were signed by Microsoft to be loaded. However, to ensure backwards compatibility, Microsoft still allowed for kernel mode drivers to be loaded under certain circumstances, including if the driver was signed with “an end-entity certificate issued prior to July 29th 2015 that chains to a supported cross-signed CA.”¹

These restrictions, combined with the increasing deployment of EDR across the industry lead threat actors to explore an alternate class of attack termed “Bring Your Own Vulnerable Driver” or “BYOVD” in which a threat actor would use a vulnerability in a legitimately signed driver to gain kernel level access. This access can then be used to kill processes such as EDR. Stroz Friedberg has previously written about this technique here. Microsoft addressed this technique through the creation of the vulnerable driver blocklist which prevented known vulnerable drivers from being loaded.

Cisco Talos previously documented a technique in which threat actors forged certificate validity dates in order to make expired cross-signing code certificates appear valid during the signing process. The Retrosigned Driver technique Stroz Friedberg observed employs a distinct methodology and relies on manipulating the certificate validity time checks on targeted systems as opposed to manipulating the signing process. However, both techniques leverage on the same architectural decision in Windows to trust cross-signed code from third party certificates prior to 2015 and result in similar impact.

Retrosigned Driver EDR Bypass

Retrosigned Drivers extends previous techniques by altering the system clock on the target system to load malicious kernel drivers that were signed by historically compromised expired cross-signing certificates. The following Retrosigned Driver attack pattern was observed by Stroz Friedberg:

Stop the Windows Time Service to prevent time synchronization through Active Directory Domain Services.
- net stop w32time & w32tm /unregister
Set the date during the validity period of the certificate
- Example: powershell -command Set-Date -Date "6/23/2015"
Execute malware which loads a driver signed by a certificate valid prior to July 29th, 2015.
Kill the EDR processes using the newly loaded driver.

Stroz Friedberg analyzed the recovered sample and confirmed that it was able to successfully load the driver and kill the targeted EDR, but only when the system time was changed to a period within the validity date of the driver. Stroz Friedberg observed similar samples across several engagements involving threat actors which deployed the Medusa and Abysslocker ransomware variants.

The recovered samples had code overlaps with previously known malware samples tracked as POORTRY and STONESTOP. When these malware families were previously identified, they were signed using a Microsoft Hardware Compatibility Program certificate as opposed to an out-of-date signing certificate.

Stroz Friedberg reported their findings to the targeted EDR vendor and provided Microsoft the malicious drivers and associated certificates, along with a description of the technique. Stroz Friedberg held publication of this post for a 60-day period after the disclosure.

Detection Mechanisms

Time changes
- Kernel-General Event ID 1: Time Changed.
- Security Event ID 4616: Time Changed.
- Out of sequence MFT records.
System Event 7034 – EDR service terminated unexpectedly.
System Event 7045 – Service install of malicious driver.
System Registry Key update ROOT\ControlSet001\Services\[Malicious Driver].
Sysmon Event ID 11 – Creation of malicious .sys driver file.
PowerShell command execution: Date change.
PowerShell command execution: Stopping time service.

Contact

If you suspect you are compromised or need assistance in assessing compromise, please call our Incident Response hotline. If you are from a Law Enforcement Agency or Endpoint Detection and Response vendor and wish for more details, please contact Aon Cyber Solutions.

Building — Support

Contact our cyber response teams for urgent breach assistance.

Contact Us

Authors

John Ailes

DFIR
Zachary Reichert

DFIR

Contributors

Partha Alwar

Director, Incident Response at Stroz Friedberg, an Aon company

Aon’s Cyber Solutions offers holistic cyber risk management, unsurpassed investigative skills, and proprietary technologies to help clients uncover and quantify cyber risks, protect critical assets, and recover from cyber incidents.

This document is not intended to address any specific situation or to provide legal, regulatory, financial, or other advice. While care has been taken in the production of this document, Aon does not warrant, represent or guarantee the accuracy, adequacy, completeness or fitness for any purpose of the document or any part of it and can accept no liability for any loss incurred in any way by any person who may rely on it. Any recipient shall be responsible for the use to which it puts this document. This document has been compiled using information available to us up to its date of publication and is subject to any qualifications made in the document. While care has been taken in the preparation of this material and some of the information contained within it has been obtained from sources that Stroz Friedberg believes to be reliable (including third-party sources), Stroz Friedberg does not warrant, represent, or guarantee the accuracy, adequacy, completeness or fitness for any purpose of the article and accepts no liability for any loss incurred in any way whatsoever by any person or organization who may rely upon it. It is for informational purposes only. You should consult with your own professional advisors or IT specialists before implementing any recommendation or following the guidance provided herein. Further, we endeavor to provide accurate and timely information, there can be no guarantee that such information is accurate as of the date it is received or that it will continue to be accurate in the future. Further, this article has been compiled using information available to us up to 9/13/2024.

The contents herein may not be reproduced, reused, reprinted or redistributed without the expressed written consent of Aon, unless otherwise authorized by Aon. To use information contained herein, please write to our team.