PsSetCreateProcessNotifyRoutineEx Problem

[0x43rypt0n]

Hi i was trying to build a windows kernel driver targeting x64

This is the source code

#include <Ntifs.h>
#include <ntddk.h>
#include <wdm.h>

UNICODE_STRING DEVICE_NAME = RTL_CONSTANT_STRING(L"\\Device\\SpotlessDevice");
UNICODE_STRING DEVICE_SYMBOLIC_NAME = RTL_CONSTANT_STRING(L"\\??\\SpotlessDeviceLink");


void sCreateProcessNotifyRoutineEx(PEPROCESS process, HANDLE pid, PPS_CREATE_NOTIFY_INFO createInfo)
{
    UNREFERENCED_PARAMETER(process);
    UNREFERENCED_PARAMETER(pid);

    DbgPrintEx(DPFLTR_IHVDRIVER_ID, DPFLTR_ERROR_LEVEL, "[-] createInfo->CommandLine->Buffer %s", createInfo->CommandLine->Buffer);
    if (createInfo != NULL)
    {
        if (wcsstr(createInfo->CommandLine->Buffer, L"notepad") != NULL)
        {
            DbgPrintEx(DPFLTR_IHVDRIVER_ID, DPFLTR_ERROR_LEVEL, "[!] Access to launch notepad.exe was denied!");
            createInfo->CreationStatus = STATUS_ACCESS_DENIED;
        }
    }
}



NTSTATUS DriverEntry(PDRIVER_OBJECT DriverObject, PUNICODE_STRING RegistryPath)
{
    UNREFERENCED_PARAMETER(DriverObject);
    UNREFERENCED_PARAMETER(RegistryPath);

    NTSTATUS status = 0;

    // routine that will execute when our driver is unloaded/service is stopped
    DriverObject->DriverUnload = DriverUnload;

    // routine for handling IO requests from userland
    DriverObject->MajorFunction[IRP_MJ_DEVICE_CONTROL] = HandleCustomIOCTL;

    // routines that will execute once a handle to our device's symbolik link is opened/closed
    DriverObject->MajorFunction[IRP_MJ_CREATE] = MajorFunctions;
    DriverObject->MajorFunction[IRP_MJ_CLOSE] = MajorFunctions;

    DbgPrintEx(DPFLTR_IHVDRIVER_ID, DPFLTR_ERROR_LEVEL, "Driver loaded");

    // subscribe to notifications
    //PsSetCreateProcessNotifyRoutine(sCreateProcessNotifyRoutine, FALSE);
    //PsSetLoadImageNotifyRoutine(sLoadImageNotifyRoutine);
    //PsSetCreateThreadNotifyRoutine(sCreateThreadNotifyRoutine);
    PsSetCreateProcessNotifyRoutineEx(sCreateProcessNotifyRoutineEx, FALSE);
    DbgPrintEx(DPFLTR_IHVDRIVER_ID, DPFLTR_ERROR_LEVEL, "Listeners isntalled..");

    IoCreateDevice(DriverObject, 0, &DEVICE_NAME, FILE_DEVICE_UNKNOWN, FILE_DEVICE_SECURE_OPEN, FALSE, &DriverObject->DeviceObject);
    if (!NT_SUCCESS(status))
    {
        DbgPrintEx(DPFLTR_IHVDRIVER_ID, DPFLTR_ERROR_LEVEL, "Could not create device %wZ", DEVICE_NAME);
    }
    else
    {
        DbgPrintEx(DPFLTR_IHVDRIVER_ID, DPFLTR_ERROR_LEVEL, "Device %wZ created", DEVICE_NAME);
    }

    status = IoCreateSymbolicLink(&DEVICE_SYMBOLIC_NAME, &DEVICE_NAME);
    if (NT_SUCCESS(status))
    {
        DbgPrintEx(DPFLTR_IHVDRIVER_ID, DPFLTR_ERROR_LEVEL, "Symbolic link %wZ created", DEVICE_SYMBOLIC_NAME);
    }
    else
    {
        DbgPrintEx(DPFLTR_IHVDRIVER_ID, DPFLTR_ERROR_LEVEL, "Error creating symbolic link %wZ", DEVICE_SYMBOLIC_NAME);
    }

    return STATUS_SUCCESS;
}

The code is compiled successfully , but when load the driver on windows 10 i can't get any debug print on dbgview

iam sure problem is not with debug print , one more thing when i use function PsSetCreateProcessNotifyRoutine it works fine and i can see what process created

So if you have guys experince and can help please share it here .

Thanks

 

[varwar]

The code is compiled successfully , but when load the driver on windows 10 i can't get any debug print on dbgview

Did you enabled capturing kernel for dbgview? It's off by default.

Try to use ed nt!Kd_Default_Mask 8 command in WinDbg. If messages will receive in the debugger then it's dbgview issue.


One more possible reason. It could be a mess with the message levels. This should be fixed with the command above or registry.

DbgPrint and KdPrint are mapped to component "DPFLTR_DEFAULT_ID" and level "DPFLTR_INFO_LEVEL". Of course xxx_INFO_LEVEL output is disabled by default. So, by default, your DbgPrint/KdPrint doesn't get sent to the kernel debugger.

OSR Dev Blog:Getting DbgPrint Output To Appear In Vista and Later

OSR Open Systems Resources, Inc. The Windows device driver and file systems experts. Seminars - Development - Consulting - Training

www.osronline.com

 

[0x43rypt0n]

Thanks for your replay yes i enabled the kernel capture also i have seen the debug print for any other function expect sCreateProcessNotifyRoutineEx

 

[varwar]

Thanks for your replay yes i enabled the kernel capture also i have seen the debug print for any other function expect sCreateProcessNotifyRoutineEx

I assume you take the code from https://www.ired.team/miscellaneous...image-load-notifications-from-a-kernel-driver

There were a note. Did you do that?

If PsSetCreateProcessNotifyRoutineEx is not working in your driver, you will need to add a /integritycheck switch in your linker configuration

 

[0x43rypt0n]

I assume you take the code from https://www.ired.team/miscellaneous...image-load-notifications-from-a-kernel-driver

There were a note. Did you do that?

Thanks varwar i missed the note yea i enabled the capture kernel i will try the solution and tell you the result

 

[0x43rypt0n]

varwar It's work thanks man , i have searched in google ,github for stop and uninstall driver from kernel i did not found , do you have a way to do that

I mean uninstall AV driver from my Kernel Driver

 

[DoomSlayer2002]

Unloading antivirus driver is not always possible, if you have your own driver you could search for av device and try to delete it ( will lead to bsod almost certainly ) or try to reverse engineer it to see if it accepts some IOCT that unloads the driver.

The simpler solution to make av driver non-workable ( i mean to stop it from scanning processeses ):

1) Find all hooks set by PsSetCreateProcessNotifyRoutine and zero them out
2) Find all hooks set by PsSetLoadImageNotifyRoutine and zero them out
3) Sometimes av uses etw to intercept system calls: https://the-deniss.github.io/posts/...-in-windows-11-22h2-like-avast-antivirus.html so you need to remove tihs also

There probably also would be some fs filter driver which will catch when some malware is dropped on the disk and immediatly run it against some yara rules or something like that and delete it, varwar probably knows better how to make fs filter to be harmless for the malware

 

[0x43rypt0n]

Thanks DoomSlayer2002 I already readed about Hooking ssdt but i guess it will be hard to hook ssdt on all windows versions , also there some guys selling Disabler for AV so i thought they may doing some thing like uninstalling the driver ! . but i guess now they maybe editing the registery to disable the AV and then protect the target registery value from editing

 

[DoomSlayer2002]

Thanks DoomSlayer2002 I already readed about Hooking ssdt but i guess it will be hard to hook ssdt on all windows versions , also there some guys selling Disabler for AV so i thought they may doing some thing like uninstalling the driver ! . but i guess now they maybe editing the registery to disable the AV and then protect the target registery value from editing

SSDT is protected by patch guard since vista, so they switched to the stuff like mentioned in the link about avast. Most of the people selling av killers have either their own signature so they can write their own driver, or they have vulnerable legitemate driver ( usually multiple ones ) which allows memory read/write, process kill, file deletion from kernel mode. Other techniques without driver most likely will require reboot for example some ppl sold av removal via deletion in safe mode.

 

[varwar]

I didn't look for a AV driver unloading, deletion. But yeah, unlinking DEVICE_OBJECT or DRIVER_OBJECT will probably BSOD the system. Some modern solutions just blind AV, EDR with mentioned techniques. But I failed when did it on my machine with weaponized exploit and never tried to do it again
Maybe on unknown cheats forum people know something.

 

[0x43rypt0n]

SSDT is protected by patch guard since vista, so they switched to the stuff like mentioned in the link about avast. Most of the people selling av killers have either their own signature so they can write their own driver, or they have vulnerable legitemate driver ( usually multiple ones ) which allows memory read/write, process kill, file deletion from kernel mode. Other techniques without driver most likely will require reboot for example some ppl sold av removal via deletion in safe mode.

Yeb i know that patch guard is protecting SSDT thanks for you sharing

I didn't look for a AV driver unloading, deletion. But yeah, unlinking DEVICE_OBJECT or DRIVER_OBJECT will probably BSOD the system. Some modern solutions just blind AV, EDR with mentioned techniques. But I failed when did it on my machine with weaponized exploit and never tried to do it again
Maybe on unknown cheats forum people know something.

Посмотреть вложение 71983

Thanks man again , iam testing on virtual machine to make sure i will not lost my system

SSDT is protected by patch guard since vista, so they switched to the stuff like mentioned in the link about avast. Most of the people selling av killers have either their own signature so they can write their own driver, or they have vulnerable legitemate driver ( usually multiple ones ) which allows memory read/write, process kill, file deletion from kernel mode. Other techniques without driver most likely will require reboot for example some ppl sold av removal via deletion in safe mode.

the EV cert is not a problem for me now since iam testing on my machines

 

[varwar]

0x43rypt0n try to simply use ZwUnloadDriver function and look what happen. If this bastard will protect itself in some way, dump the DRIVER_OBJECT structure with all the fields for that driver (AV) and manually diff it with some ordinary driver. Maybe there are some fields which you can patch and bypass something. I got some interesting results when did the same for EPROCESS flags.

 

[0x43rypt0n]

0x43rypt0n try to simply use ZwUnloadDriver function and look what happen. If this bastard will protect itself in some way, dump the DRIVER_OBJECT structure with all the fields for that driver (AV) and manually diff it with some ordinary driver. Maybe there are some fields which you can patch and bypass something. I got some interesting results when did the same for EPROCESS flags.

Will give it a try