Review of Update in Destructive tool undermines Windows systems by Curt Wilson
During the years 2022 and 2023, Sophos X-Ops released a study regarding a toolkit to disrupt the operations of endpoint security software which was in the process of development and use in collaboration with various significant ransomware organizations. Mandiant had formerly dubbed this tool Poortry, and its loader application Stonestop.
The originators of the Poortry tool triumphed in obtaining purposefully designed, customized kernel-level drivers signed through Microsoft’s validation signing procedure. Following the publication of our study — and Microsoft’s dismissal of the loophole that allowed these drivers to be confirmed — the developers of the tool did not halt their operations. Instead, they persisted in introducing enhancements and capabilities to the Poortry driver, in a continuous effort to avoid detection and identify novel methods to deactivate EDR and endpoint security software.
In order to elaborate on the recent functionalities in Poortry, let’s delve into how drivers interact with the operating system, and how the creators of this EDR annihilator have advanced their tool over time.
The Way Windows Drivers can undermine safeguards
The majority of EDR terminators depend on a device driver being integrated into the operating system’s kernel, granting them rights to the type of intricate functionality necessary to detach and terminate various forms of security software.
Beneath Windows, which supports numerous peripherals and connected components, kernel-mode drivers are granted broad authorization to execute these kinds of intricate functions. In a regular scenario, these drivers do not interact with software or hardware from other companies or manufacturers, but this conduct is not enforced. Hence, if a legitimately signed driver fails to validate the procedures interacting with it adequately, EDR terminators can exploit some of its features to dismantle protective measures.
Microsoft has devised various methods through which their operating systems can regulate whether drivers are permitted to load at all, such as the Driver Signature Enforcement mechanism: Drivers are required to be digitally validated by a software provider whom Microsoft trusts before they can be incorporated.
The developers of EDR termination tools exploit the deficiencies in this trust model: They may utilize a driver susceptible to exploitation that was formerly published by a legitimate software enterprise; Alternatively, they might authenticate their own driver utilizing a genuine code-signing certificate (and there are numerous avenues to procure pilfered or divulged certificates).
Usually, there are three approaches EDR terminator developers manipulate code validations:
Utilization of leaked certificates
This is the most direct approach to tackle this issue: Detect a leaked, stolen, or otherwise compromised code-validation certificate from a legitimate firm, and leverage it to confirm your driver (or to deceive Root Certificate Authorities into generating a certificate for you).
For all iterations of Windows that emerged after Windows 10 version 1607, Microsoft has mandated all third-party developers of kernel-mode drivers to present their driver to Microsoft’s developer portal, to be endorsed by Microsoft. Nevertheless, cross-validated drivers not approved by Microsoft are still permitted to be implemented if they fulfill one of the following conditions:
- The computer was upgraded from a prior release of Windows to Windows 10, version 1607
- Secure Boot is deactivated in the system BIOS
- Driver was validated with an end-entity certificate distributed before July 29, 2015 that chains to a recognized cross-validated CA
Despite the fact that the update decreased the peril of cross-validated drivers that were validated by stolen certificates, the third bullet creates a gap that enables attackers to utilize the second method.
Forging Signature timestamps
In order to maintain compatibility with outdated drivers, Windows accommodates drivers that are certified with “end-entity certificates distributed before July 29, 2015 that chains to a validated cross-validated CA.”
While certifying a kernel driver, Microsoft imparts the software provider with a tool dubbed signtool.exe. In addition to authenticating the provided file, signtool also verifies that the provided certificate is still authentic. One approach to ensure this is to deploy the function
Evading Microsoft attestation validation
‘
The ultimate method is to transcend Microsoft’s attestation validation process, and acquire validation for the kernel driver directly from Microsoft. This is arguably the most challenging to accomplish, yet it also confers a validation stamp from Microsoft itself — nearly an esteemed WHQL certificate.
To exploit this technique, attackers necessitate:
- A genuine EV certificate
- Entrance to the Microsoft developer portal
Upon meeting these prerequisites, they can compile a CAB file, encompassing the driver itself, authenticate it with the EV certificate, and submit it to the dashboard.
Upon submission, the driver will endure various assessments to validate that it is not malevolent. If the driver clears these evaluations, it will bear the “Microsoft Windows Hardware Compatibility Publisher” validation.
Poortry & Stonestop: A Current Menace Since 2022
Poortry (alternatively named BurntCigar) is a corrupt kernel driver utilized alongside a loader named Stonestop by Mandiant, who initially shed light on the existence of the tool. The driver surpasses Driver Signature Enforcement by leveraging any of the three methods delineated earlier. Both are substantially veiled by commercial or open-source packers, such as VMProtect, Themida, or ASMGuard.
From late 2022 to mid-2023, Poortry variants bore the Microsoft WHQL certificate. Nonetheless, as a outcome of collaborative efforts between Sophos X-Ops and Microsoft, a majority of these attestation signed examples were identified and Microsoft rendered the accounts that had been exploited to secure those drivers void.
The creators of Poortry were not disheartened; Instead, they transitioned either to Signature Timestamp Forging or securing a legitimate leaked.credentials.
In the past year, we managed to correlate the utilization of Poortry with assaults linked to at least five prominent ransomware groups:
- CUBA
- BlackCat
- Medusa
- LockBit
- RansomHub
Starting from 2023, there has been consistent use of Poortry by threat actors during attacks. One consistent pattern from our initial investigation is that the developers of Poortry frequently change their encryption methods, generating a slew of slightly altered versions based on the original. In our study, we discovered various WHQL-signed iterations, packaged with diverse commercial or non-commercial encryption tools.
Following the closure of that avenue, the creators of Poortry have now resorted to circulating the drivers endorsed by a broad spectrum of non-Microsoft certificates.
The visual representation below depicts a sequence of the observed signatory names utilized by Poortry’s payload driver over a 15-month span.
It is noteworthy that our observations are sometimes made during response to incidents and at other times gathered as telemetry. One certainty is that the overall quantity and diversity of certificates surpasses what our observations alone can ascertain.
Engaging in certificate rotation
Sophos, periodically, has witnessed a threat actor deploy variations of Poortry on various systems within a single infrastructure during an incursion. These variations include identical payloads but are signed with distinct certificates compared to the initial driver spotted in use during the attack. In August 2023, in the course of a Sophos X-Ops inquiry, it was identified that intruders obtained initial access through a remote tool called SplashTop. Upon infiltrating the network, they proceeded to implant Poortry and Stonestop. However, the signer name “bopsoft” was already recognized as a stolen certificate and was neutralized through a behavioral policy.
Solely 30 seconds after the last endeavor with the “Bopsoft” signed code, the attackers began deploying an alternate Poortry driver, this time signed by “Evangel Technology (HK) Limited.” Subsequently, the system was rapidly isolated, foiling the attack.
Evolution from EDR destroyer To EDR eraser
In July 2024, while handling an incident where adversaries sought to unleash RansomHub ransomware, Sophos CryptoGuard foiled the encryption endeavor as analysts sealed off the trespassing points. A post-event evaluation disclosed that prior to the ransomware assault, two extra executables were planted on multiple machines:
<d>Users<u>desktopc7iy3d.exe <d>Users<u>appdatalocaltempusnnr.sys
By employing a blend of static and dynamic assessments, it was concluded that the programs were Poortry and Stonestop. Among the distinctions noted between the prior version and this edition, Poortry now possesses the capacity to entirely eliminate critical EDR components, rather than merely ceasing their operation.
Trend Micro communicated in 2023 that Poortry had acquired the ability to scrub files from the disk, though this was the first instance where we observed this trait in an attack.
An in-depth analysis of the recent iterations
Both the Stonestop executable and the Poortry driver are heavily packed and obscured. This loader was concealed using a proprietary packer named ASMGuard, accessible on Github.
The driver bears a certificate imprinted with the signatory name “FEI XIAO.” Sophos X-Ops confidently asserts that the signature timestamp was fabricated to endorse the driver. Interestingly, it attempts to disguise itself by utilizing identical details in its properties as a driver (idmtdi.sys) for a software widely available, Internet Download Manager by Tonec Inc. Nevertheless, it is not affiliated with this software suite’s driver – the malefactors merely duplicated the data from it.
For elucidation purposes, we segment the execution sequence into three distinct stages.
Commencement Phase
In episodes that we have monitored, threat actors deposit Poortry and Stonestop together in the same directory. Upon execution, Stonestop examines the current directory for the corresponding driver.
Both the driver’s filename and device name are hardcoded in the loader. When started, the loader retrieves the handle of the malicious kernel driver and starts a handshake by transmitting a hardcoded string to the driver using the DeviceIoControl API call.
The communication among the components primarily occurs through this DeviceIoControl API. Every function provided by the kernel-mode component is activated by dispatching a distinct IOCTL code. Previous versions used to communicate via the IRP_MJ_DEVICE_CONTROL handler. The latest version employs the IRP_MJ_MAXIMUM_FUNCTION handler for receiving I/O request packets.
It’s important to note that the mappings between IOCTL codes and functionalities have been altered since our previous analysis. For instance, the operation to terminate a specific process by its ID was initiated by sending an I/O request packet with code 0x222094. In the current iteration, the same functionality is now mapped to IOCTL code 0x222144.
Since Trend Micro’s 2023 report, Poortry’s developers have increased the number of valid IOCTL codes from 10 to 22. Our investigation into all available features is still ongoing.
Similar to previous releases, a handshake process is commenced by dispatching a predefined string to the driver. Once the handshake value is acknowledged, it sets a flag in the binary file, activating the capabilities of the malicious driver.
Disruption Phase
The second phase concentrates on incapacitating EDR products using various methods like removing or altering the kernel notify routines.
Security drivers leverage multiple functions provided by the Windows OS to register callbacks for specific events on the Windows system. An illustration of this is the PsSetCreateProcessNotifyRoutine function, which inserts a callback routine provided by the driver when a new process is created.
The elimination of these callback routines is often a crucial step to neutralize EDR products. In 2022, we also detailed a similar incident where BlackByte ransomware exploited a legitimate vulnerable driver to erase critical kernel notify routines.
During the second phase, we identified a total of seven unique IOCTL codes sent to the kernel-mode component. Only the function associated with code 0x222400 is executed. The other features halt prematurely due to particular flags configured in the binary. It is suspected that the untriggered functionalities are either experimental, activated on specific system types, or simply disabled.
The IOCTL codes and their corresponding behaviors are outlined as follows:
0x2220C0 (Disabled)
Upon reception, Poortry proceeds with an additional initialization routine to obtain addresses of critical structures and functions.
0x222100 (Disabled)
Upon receipt, Poortry tries to toggle kernel callbacks by adjusting the PspNotifyEnableMask flag. This is a common method employed by rootkits to toggle kernel routine callbacks, as elaborated in this article.
0x222104 (Disabled)
When receiving this IOCTL code, Poortry modifies the kernel callbacks of the PsProcess, PsThread, and ExDesktopObj object types. These object types represent specific objects in the Windows kernel, with PsProcess representing a process object. Each type includes a variable pointing to the callbacks registered for the respective object.
Due to the deactivation of this feature, it’s uncertain how adversaries would aim to manipulate these callback lists. One probable scenario could involve completely disabling them by assigning the callbacks to a function without any operations, essentially returning instantly.
0x222108 (Disabled)
Upon reception, Poortry alters the CmpCallbackCount variable to enable or disable registry kernel callbacks. This variable counts the number of registered callbacks. It is assumed that resetting this value to zero would render the callbacks non-functional.
0x22210C (Disabled)
Upon receipt, Poortry endeavors to detach the fltMgr.sys driver from the FileSystemFastFat and FileSystemNtfs device by utilizing the DeviceIoDetachDevice function. Although this function is typically used by genuine drivers for cleanup during shutdown, rootkits can employ it to block targeted drivers from receiving further I/O requests.
fltMgr.sys serves as the filter manager in Windows, extending or modifying existing functionalities on the system. This driver is frequently utilized by EDR products.
By detaching it, installed filters are rendered ineffective on the targeted system.
0x2221C0 (Disabled)
Upon receipt, Poortry executes routines to acquire the addresses of key function handlers of ClassPnp.sys and ntfs.sys, like NtfsFsdClose or NtfsFsdRead from ntfs.sys. Consequently, this routine appears to be an additional initialization step for obtaining critical function addresses used by other features.
0x222400 (Enabled)
Upon receipt, Poortry deactivates installed kernel callbacks using various techniques. The user-mode component includes the name of the targeted driver when the I/O request packet is transmitted.
Modifications have been made to kernel callbacks through PsSetLoadImageNotifyRoutine, PsSetCreateThreadNotifyRoutine, and PsSetCreateProcessNotifyRoutine. Within the callback function’s prologue, Poortry changes the initial instruction to immediately exit with a return value of zero upon entry.
We have uncovered various methods to neutralize kernel callbacks and security drivers:
- Traversal of internal structures utilized by PsSetLoadImageNotifyRoutine, PsSetCreateThreadNotifyRoutine, and PsSetCreateProcessNotifyRoutine functions to identify tagged security driver callbacks. Consequently, callback functions assigned to these drivers exit immediately without executing their intended routines.
- The Windows kernel incorporates crucial data structures such as PsProcess, PsThread, and ExDesktopObject, housing a field named CallbackList that manages object-specific callback routines. Poortry scans this list and when a callback belongs to a tagged security driver, the associated callback function exits prematurely without performing its operations.
- Traversal of an internal linked list used by CmRegisterCallback and CmUnregisterCallback, containing function pointers to registered registry and object callbacks. If a callback is associated with a tagged security driver, its prologue is tampered with.
- Utilization of the exported function FltEnumerateFilters from fltMgr.sys to cycle through applied filters. If a filter pertains to a tagged security driver, its prologue is modified.
- While direct functionality triggering was not accomplished, evidence suggests Poortry’s potential abuse of the IoDetachDevice function to detach device objects selectively from the system’s device stack, differing from IOCTL code 0x22210C in its specificity to match device names provided via DeviceIoControl.
Cleanup Operation
Following impairment, the EDR killer targets the termination of security-related processes, rendering the EDR agent inept by erasing pivotal files from storage.
The user-mode component initiates numerous I/O requests with IOCTL code 0x222144 towards the kernel-mode module, involving the process ID of the designated process for termination.
The loader maintains a catalog of hardcoded paths pointing to locations housing EDR products, systematically removing critical EDR agent files, such as EXE or DLL files, by issuing an IOCTL request with code 0x222180 to the driver, along with the specified file path for deletion.
Noteworthy is the dual operating modes of the user-mode component:
- Deletion by file type
- Deletion by file name
It is suspected that these operation modes were introduced by the author to ensure adaptability for diverse targets. The list of hardcoded paths addressing EDR product installation locations is believed to vary based on the target.
Wrap-Up
Over the past 20 months, Poortry and its accompanying loader, Stonestop, have undergone substantial enhancements following a collaborative expose by Sophos and Microsoft concerning the WHQL signing mechanism exploitation by the EDR killer. Originally a rudimentary tool for disengaging troublesome endpoint protection elements, Poortry has evolved into a versatile offensive tool leveraging a vast array of purloined or misappropriated code signing certificates to circumvent Driver Signature Verification safeguards.
A distinct hallmark of Poortry’s development has been its evolution beyond simple EDR disarming to function as a rootkit, exerting precise control over various API calls governing low-level OS operations. Its capacity now extends to eradicating opposition – security software – from the system, paving the way for ransomware deployment.
About Author
