A long time ago, in a galaxy far, far away (actually, it was about 5 months ago, and I was in the same geographic location), I wrote a diary about WMIC. For the uninitiated, WMIC is the Windows Management Instrumentation Command-line, an amazing tool for managing Windows boxen at a very fine-grained level. You can read my previous diary for some ideas I compiled from readers like you on using WMIC to support incident handling.
My previous WMIC article, however, was very focused on attributes of a Windows box? listing them, reading them, and even tweaking a few. The areas that WMIC can interact with are called aliases, and there are a bunch of them, such as process, os (operating system), nteventlog, startup, etc. Each of these has its own set of attributes. To get a list of aliases supported by WMIC, you can do this:
C:\> wmic /?
Then, to get a list of attributes and all of their settings for a given alias, type:
C:\> wmic [alias] list full
But, WMIC is object-oriented, you see, so you've got attributes and methods. Attributes are cool, letting you get info about your box and tweak it a bit, but methods let you take action on a box, giving you real power. And, with great power comes great responsibility, as we all know.
To illustrate the difference, consider the sky. It has attributes (cloud cover, color, etc.). If Microsoft implemented a WMIC alias for the sky*, you might be able to check your weather by doing something like this:
C:\> wmic sky list full
C:\> wmic sky where location="NYC" get cloudcover
But, what if you could have methods for the sky? That would give your real power. Why, you might be able to do something like this:
C:\> wmic sky call scorch
Now, that would be scary. Note that you invoke methods using the "call" syntax.
* As far as I know, the sky alias for WMI was originally planned for Windows Vista, but was dropped or majorly tweaked like so many other things.
It occurs to me that, if you were a Jimi Hendrix fan, you could run:
C:\> wmic sky where haze="purple" call kiss
(Sorry, I couldn't resist.)
So, musings about the sky alias aside, let's look at some fun methods we can call for various attributes of Windows. Keep in mind, that to get a list of methods you can call for any given alias, you could run:
C:\> wmic [alias] call /?
First off, one of the annoying things about "wmic process" is that it doesn't have an attribute for the owner of the process. But, what the Big Softie left out in attributes, he gave us in methods:
C:\> wmic process where name="cmd.exe" call getowner
C:\> wmic process where name="cmd.exe" call getownersid
Nice! (Note... Thanks Robert for the pointer about fixing the badly pasted double-double quotes... they are fixed now).
Second, how about this? Want a built-in command to reboot or shutdown a Windows box (that can even work across the network? see my old article for making this stuff happen remotely)? Try this (make sure you've saved all work in any running applications first!):
C:\> wmic os where buildnumber="2600" call reboot
Or, replace "reboot" with "shutdown" if that's what you want. Note that I've found that I have to specify a where clause in the "wmic os" alias whenever I call a method to identify a specific instance, even though there is only one operating system. Other WMIC aliases don't require the precision of referring to a specific instance, but os does. Go figure. Note that on a WinXP box, I refer to the build number, because, for whatever reason, it is easy for me to remember that one. ;)
Third, let's get into network stuff. Here's a handy one for getting MAC addresses (and remember, it can be run remotely, too!):
C:\> wmic nic get macaddress
I know, I know? that is attribute oriented. But I like it? a lot. You want interface-related methods? Check these out:
C:\> wmic nicconfig call setdefaultttl 200
C:\> wmic nicconfig call settcpwindowsize 3212
Those change the IP TTL and TCP Window size from default settings to something else, possibly fooling some forms of passive OS fingerprinting. Be careful with them, though... changing those settings could hose your network performance, make your system ugly, and make your hair fall out. You have been warned!
Fourth, how about some event log stuff? To clear the security event log, you could:
C:\> wmic nteventlog where (description like "%secevent%") call cleareventlog
Or, if you just want to get certain kind of events (I'm going to go all attribute on you here again) like those associated with logging onto the box:
C:\> wmic ntevent where (message like "%logon%") list brief
Fifth, here is one that could be useful for handlers:
C:\> wmic netlogin where (name like "%skodo") get numberoflogons
Replace skodo with any other name you are interested in, and it'll show you the cumulative number of times they've logged in to that box historically. One thing that bothers me here is that WMIC refers to "netlogin" with an "i". Whenever I write articles and stuff, I always try to use the word "login" when referring to Linux/UNIX and the word "logon" when referring to Windows. It drives my editors nuts, but it is how these actions are typically referred to in each operating system. But, here we have a Windows command referring to that action as "login". Spooky, I tell ya.
So, enough of my stuff? I'd like to hear from you. What WMIC methods have you found useful or interesting? Send them to me, and if they tickle my fancy, I'll summarize them and post them throughout the day.
ISC reader D. Alan Ridgeway points out that you can use methods associated with "wmic service" to change the service configuration, as in:
C:\> wmic service where (name like "Fax" OR name like "Alerter") CALL ChangeStartMode Disabled
While that is true, I personally prefer the syntax of the sc command. Still, I could foresee circumstances where the sc command is kaput (and the Services Control Panel is really messed up), so having this option in our WMIC arsenal is helpful. Thanks, Alan, for the tip!
Fellow Handler Daniel "I beat your CtF game" Wesemann wrote in:
C:\> wmic /node:box.domain.com qfe where "not description like ''" get description,hotfixid,installedon [like followed by two single qutes]
to quickly verify if a certain box has a certain patch and when it got applied, rather than to have to tediously log into the patch mgmt system first."
Good stuff, Daniel... thanks... And your where clause does help to clear out some clutter from the output (although it's rather long to type...)
Another item we got from a mysterious reader desiring some semblance of anonymity involves hunting down apps that shouldn't be used in their enterprise, like file sharing apps. Writes this mystery person:
"[I really like] the "wmic process" domain, mainly to doublecheck after an IDS alert if a user is
indeed trying to run kazaa or the like before i call him for personal counseling." -- Mysterious Person
ISC reader Matt Wagner has some good ideas, again attribute focused, but useful in spotting discrepancies:
"No methods here, but useful WMIC queries that I have my desktop support folks do to spot any obvious problems when they are working on troubled machines. They usually run them from a batch file and pipe the output to a text file on the network. Keep in mind that batch scripts use "%" as escape characters, so you need two of them when doing a "LIKE" condition.
//Spot odd executables
C:\> wmic PROCESS WHERE "NOT ExecutablePath LIKE '%Windows%'" GET ExecutablePath
//Look at services that are set to start automatically
C:\> wmic SERVICE WHERE StartMode="Auto" GET Name, State
//Find user-created shares (usually not hidden)
C:\> wmic SHARE WHERE "NOT Name LIKE '%$'" GET Name, Path
//Find stuff that starts on boot
C:\> wmic STARTUP GET Caption, Command, User
//Identify any local system accounts that are enabled (guest, etc.)
C:\> wmic USERACCOUNT WHERE "Disabled=0 AND LocalAccount=1" GET Name" -- Matt Wagner
Nice stuff, Matt. I really like the startup alias... it's pro'lly my third favorite (after process and qfe).
Well, that's it for me for today. Thanks for the fun adventures. I appreciate all of your helpful comments and insights today.
Get a good rest tonight. You just might need it.
See you next time!
Aug 21st 2006
|Thread locked Subscribe||
Aug 21st 2006
1 decade ago