Kayaker
December 8th, 2008, 22:43
Nice analysis evilcry.
I was wondering though, near the end you print out a list of module strings (sys and exe) that the driver contains and mention that the PsSetLoadImageNotifyRoutine callback terminates the processes with ZwTerminateProcess if they are detected starting up.
That
can't be the case however for the sys driver modules, so I was wondering what action the driver takes when one of the listed sys modules are detected.
In explanation, there are two ways to detect in a PsSetLoadImageNotifyRoutine routine whether the module loading is a driver (other than checking for a ".sys" extension or perhaps PE header parsing).
One is
if (ProcessId == 0) // a driver is loading
Otherwise ProcessId will be a normal PID value for an exe or dll.
The second is to check the value of PIMAGE_INFO->SystemModeImage. For a driver it will be 1, for an exe or dll, 0.
ImageAddressingMode is 3 for both cases. So the full Properties dword will be 103 for drivers and 3 for non-drivers.
Code:
typedef struct _IMAGE_INFO {
union {
ULONG Properties;
struct {
ULONG ImageAddressingMode : 8; // code addressing mode
ULONG SystemModeImage : 1; // system mode image
ULONG ImageMappedToAllPids : 1; // image mapped into all processes
ULONG Reserved : 22;
};
};
PVOID ImageBase;
ULONG ImageSelector;
SIZE_T ImageSize;
ULONG ImageSectionNumber;
} IMAGE_INFO, *PIMAGE_INFO;
That is what your driver is doing in this sequence, accessing the SystemModeImage bit, which it passes to a function:
Code:
00011EF6 mov eax, [esp+PIMAGE_INFO]
...
00011EFD mov ecx, [eax]
00011EFF shr ecx, 8
00011F02 and ecx, 1
00011F05 push ecx // SystemModeImage
Also, the prototype for NotifyRoutine seems inaccurate. There IS no ProcessHandle (except as an OUT parameter for ZwOpenProcess). From the looks of it it should be PUNICODE_STRING FullImageName instead. So in the second call you reverse you have the first parameter named as PUNICODE_STRING ProcessHandle, which is passed to RtlUnicodeStringToAnsiString. "FullImageName" would be more accurate than "ProcessHandle". Maybe the subsequent call to ZwOpenProcess confused the IDA naming, I can't quite tell, but something doesn't seem quite right.
Code:
(*PLOAD_IMAGE_NOTIFY_ROUTINE) (
IN PUNICODE_STRING FullImageName,
IN HANDLE ProcessId, // where image is mapped
IN PIMAGE_INFO ImageInfo
);
Getting back to the blacklisted drivers and what the malware may do with them... at least one of them, /spdt.sys, is a boot loading driver which is loaded well before the (subverted by the malware) Beep.sys. (On my system beep.sys is normally about the 70th system driver to load, right after null.sys). So there's NO way the malware could detect spdt.sys loading up. So why does it have that string and does it actually do something with it?
It's easy enough to prevent a driver from loading through a PsSetLoadImageNotifyRoutine callback, if that is what the malware might be doing. You can simply patch in at the start of DriverEntry something like:
MOV EAX, 0xC0000001
RETN 8 (return STATUS_UNSUCCESSFUL)
However, this would/should normally kick up an error message that the user would see, so it's not too covert a thing to do. There's not really much else a malware could do to a loading driver in PsSetLoadImageNotifyRoutine, at least not directly, because the DRIVER_OBJECT structure isn't even fully defined yet, though attacking the import table / direct PE modification might be a possibility.
All in all, it really sucks to see this f**king AntivirusPro2009 spamware and its ilk try to take advantage of unsuspecting users. Remember, it's probably going to be your dear old grandmother who gets scared enough to fall prey to the assholes behind it all.
So, thanks again for the analysis and exposé.
Regards,
Kayaker
