Using WMI

Over the past couple of days, I've been working on updating some of the WMI code I keep on hand...updating what I have, and adding to it.

Yesterday after work, I tweaked my version of promqury.exe, which uses WMI to detect sniffers on managed Windows systems. I wanted to make sure that not only did it work correctly, but I also wanted to comment it a bit so that the code was easier to understand and follow. Basically, the code uses WMI/WDM to access the OID_GEN_CURRENT_PACKET_FILTER structure, and checks for NDIS_PACKET_TYPE_PROMISCUOUS, which, per ndis.h, equals 0x00000020. As this is hex, if we translate it to binary, it means that bit 6 (from the right) is set (equal to 1). So I took the return value for the current packet filter, translated it to a 32-character string of 1's and 0's, and checked the value of the 27th bit (from the left).

In addition, I got a version of one of the triangulation thing I mentioned before.

Let's see...what else? Oh, yeah, I wrote a process monitor tool that watches for the creation of new processes on Windows systems. The core of this is the WQL query:

"SELECT * FROM __instancecreationevent WITHIN 2 WHERE targetinstance ISA 'Win32_Process'"

I think I need to decrease the value of WITHIN, but according the warnings issued by the Perl interpreter, the WITHIN is required. I tried to do the same thing with CIM_DataFile and CIM_LogicalFile, but got warnings about quota violations...evidently the query is too large. I guess for a file monitor (for when I'm testing rootkits and such) I'll have to go back to FileMon, or use the now defunct Win32::AdvNotify module (I still have a copy around, and some code...).

I've got another script I'm working on that ties threads to their associated processes. I'm hoping that the Win32_Thread class in WMI really does look at threads, instead of enumerating processes first, and then their threads.

Interestingly enough, I was able to do what I did with the process monitor and make it watch for new threads being created, but the basic information you get from the Win32_Thread class is a bit limited.

I hope you, the reader, can see how useful something like this would be in incident response. I'd tweak these tools up a bit during a testing process, create standalone EXEs of them and burn them to CD...very useful stuff.