KDU v1.1 release and bonus (AsIO3.sys unlock)

KDU stands for Kernel Driver Utility. It was developed mainly to assist in some other projects, like for example VBoxHardenedLoader. Since release in the beginning of 2020 it supported various vulnerable drivers as "functionality providers".

Overall these are the major 1.1 version changes:

• Driver mapping shellcode has been updated, two additional shellcode variants have been added;
• More vulnerable drivers from Huawei, Realtek, MSI, LG, ASUSTeK have been added.

Details about changes are below.

Shellcode variants

Overall shellcode has been redesigned to work with mapped section instead of registry. Previous version read payload driver image from Windows registry specific key. It was quick and cheap solution as I didn't bother with it and just re-used Stryker bootstrap shellcode variant. Now KDU will allocate special section with random name to store payload driver image, additional parameters and to query result uppon shellcode execution completion.

There are three variants of driver mapping shellcode available for selection via -scv <number> command. The difference between them is how they handle payload execution part. First variant uses newly created system thread to run payload entry point. It is pretty much the same method as original KDU/TDL/Stryker use. Second allocates work item and runs payload entry point within existing system worker thread. Third is more complex as it is designed for a small limited usage with drivers that are unaware of preconditions required for manual mapping. Preciously they require their DriverEntry parameters to be valid. This shellcode variant will allocate driver object, fill it common part and pass it together with supplied registry path to the payload DriverEntry as parameters. This is something like Dustman copy-pasters did with Eldos RawDisk however it also provides valid registry path parameter which is can be used by payload driver. While using 3rd shellcode version you need to supply driver object name using command -drvn <ObjectName> and optionally registry key name -drvr <RegName>. If no registry key name specified KDU will assume registry key name is the same as driver object name. Examples of usage -> https://github.com/hfiref0x/KDU#usage.

New providers

• Huawei PhyMemx64 driver from Huawei MateBook Manager of various versions. This driver is a blatant copy-paste from infamous WINIO source code;
• Realtek RtkIo64 driver from Realtek Dash Client Utility of various versions. This driver based on PHYMEM open-source project code, which is a wormhole by design;
• EneTechIo64 from MSI Dragon Center, it is similar to previously added EneTech variants (all based on WINIO), however it utilizes "unique" unlocking algorithm (see https://swapcontext.blogspot.com/2020/08/ene-technology-inc-vulnerable-drivers.html for a complete overview) and freshly signed so that is why I decided to add this variant too;
• LG LHA driver from LG Device Manager, which is explained in Jackson_T blogpost. This driver is semi-original with some influence of open-source projects;
• ASUSTeK AsIO2 driver from ASUS GPU Tweak utility, this driver also described in my blogpost about EneTech drivers derivatives.

That's all about KDU. Ironically bonus part is much longer.

Bonus (AsIO3.sys unlock)

ASUSTeK "giveio" drivers seems had some special love from the developers who are sitting on WINIO source code in EneTech. GLCKIO, GLCKIO2, AsIO, AsIo<O><variousnames>, AsIO2 and now AsIO3. What they share in common (except WINIO base) - their authors never fix their bugs. They actually just pull "new" version of driver when someone find a bug in it and contact ASUS for security reasons. Numerous CVE numbers generated by various groups/researches etc. So what they actually changing? Well, they just switching driver "locks" - a primitive handmade solutions which purpose is to block usage of the given driver by 3rd party. And under 3rd party I mean - block and/or ruin the way this driver was exploited in the submitted security issue. Thus submitted issue will be no longer reproducible as-is and they can tell - hey we fixed it, now you can gtfo, lol. Sometimes, like in case of AsIO2 their newly added locking code adds additional bugs and vulnerabilities. But nobody cares I guess.

Their latest release is AsIO3.sys with self-explaining pdb (C:\Working\MB\GLCKIO2\AsIO3\x64\Release\AsIO3_64.pdb). The key changes compared to AsIO2:

1. They have been forced to make it pass Driver Verifier checks; 👏
2. New driver lock, no more TinyAES with keys found by devs in Google search;
3. All the bugs/vulnerabilities of WINIO stay same.
   

Driver is fresh and comes as part of ASUS GPU Tweak software v2303.

Pic 1. AsIO3 details.

New driver "lock" looks pretty damn solid and complicated! I mean they wasted so much code to create this ineffective piece of garbage while instead they could put their efforts into fixing (or even rewriting) entire WINIO. To "unlock" previous AsIO2 all you need - generate special resource named "asuscert" and put it into your application resources, see complete unlocking code here. In newest versions everything changed. 

AsIO contain three components - AsusCertService.exe (32bit), wrapper dll and driver. In the AsIO3 driver implemented special check of requestor application during IRP_MJ_CREATE. Driver reads file from disk, calculates SHA256 for it and compares this value with hardcoded hash. If they do not match - STATUS_ACCESS_DENIED will be returned to the caller.

Pic 2. AsusCertService.exe SHA256 hardcoded in AsIO3 driver

Thus initially only AsusCertService.exe allowed to open and communicate with AsIO3 driver. Entire purpose of this executable is to manage connections for AsIO3 driver. This driver also provides a way to register "trusted application" that will be able to call AsIO3. AsusCertService setups named pipe (no SD set ROFL) called "asuscert". Now if another application want to use AsIO3 and should contact AsusCertService via named pipe. AsusCertService will validate client executable to be digitally signed and signer must be one of the hardcoded values as shown below.

Pic 3. AsusCertService client signer check.

After successful check service will register client process as trusted for AsIO3 driver by sending special IOCTL 0xA040A490 with input buffer set to client process id. Driver manage this list similar to GLCKIO2 where it was firstly introduced. Another IOCTL 0xA040A494 used to remove client process id from trusted process list. 

How to bypass this garbage and completely useless code and unlock this driver for your application:

1. Make a copy of AsusCertService somewhere, make sure it is unmodified otherwise driver side hash check will fail;
2. Create a zombie process from this copy, stop before calling entrypoint;
3. Unmap original code and replace it with your own shellcode;
4. Resume zombie process;
5. In a shellcode -> open driver and register your parent process in trusted process list using 0xA040A490 IOCTL code;
6. Make sure AsusCertService zombie process will be alive and kicking (put it into infinite wait for example in your shellcode) while your main process is working, this is to prevent AsIO3 driver from zeroing trusted processes list;
   
7. Now from your process you can do whatever you want with AsIO3, for example BSOD it (since AsIO3 provides full set of unfixed WINIO vulnerabilities/bugs).
   

Pic 4. AsIO3 usual state.

Well, what can I say. A quantum supercomputer calculating for a thousand years could not even approach the number of fucks which ASUS do not give when it comes to security of their drivers.

AsIO3 unlock PoC can be found at -> https://github.com/hfiref0x/AsIo3Unlock

Disclaimer

Using KDU program might crash your computer with BSOD. Compiled binary and source code provided AS-IS in hope it will be useful BUT WITHOUT WARRANTY OF ANY KIND. Since KDU rely on completely bugged and vulnerable drivers security of computer where it executed maybe put at risk. Make sure you understand what you do.

KDU github with precompiled binaries -> https://github.com/hfiref0x/KDU

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.