Using WMIC To Create SOC Based Inventory of Executables

Written by Frank Angiolelli, CISSP
www.fortknoxnetworks.com

Using WMIC To Create SOC Based Inventory of Executables

As many of us know, WMIC is an exceptionally powerful tool for collecting information. When coupled with additional tools, a useful and actionable collection of material can be created that provides visibility across an enterprise.

For example, leveraging WMIC to collect all running processes and inventory that data is an interesting use case.  For those of you unfamiliar with wmic, the following command can get you started (Pro versions of Windows only):

wmic process list brief /format:list

The information presented provides HandleCount, Name, Priority, Process ID, Threadcount and WorkingSetSize. Interesting information to say the least, however without the actual paths, usefulness is limited.
By running the following command, we can discover all the information presentable:

wmic process list /?

This is a lot of information, not all of which is usable. For my purposes, I choose the following information. Name, ProcessID, Executablepath. The Name will show you the executable, the ProcessID is useful information if you need to executable something based on your query and the Executablepath shows you the location of the executable on the system.

wmic process get name,processid,executablepath

Now as we start to move into useful information, we need to edit formatting and output it to a file that again is useful. This can be achieved using the format and output commands.

wmic /output:%computername%.csv process get name,processid,executablepath /format:csv

Now we have an output of a file that is useful for our purposes. When looking at the csv file, you will notice that the first column is called "Node" which indicates the computername variable.

Without going too in depth, this information can be collected, transported or queried from a centralized location and then input into a database engine of your choice. For example, inputting into MySQL can be done with multiple files using a type command for all csv files created/collected and then running something like. I have not used this with all queries run from a single system as of writing of this article, but this seems quite possible.




Again, in my above case, I've ignored three lines because I'm consolidating multiple queries using a simple type command resulting in the first three lines being garbage.

Once all the data is consolidated, running a query inside MySQL for key indicators like 'temp' or 'appdata' becomes simple and fast. In addition, an inventory of system executables like csrss.exe or explorer.exe can report any executable not running in standard Windows Directories.

Building a front end on the system allows for access, queries and reporting based on standardized queries on a daily basis. Build a python based email reporting system and your system is now alerting you to suspicious executables on a daily basis.

In my Watchtower product I have taken this to extremes building transport, consolidation, reporting and front end systems with email reports daily to account for inventories of processes, startup tasks and services captured from multiple endpoints on a daily basis.