The Grammar of WMIC
Whenever I’m Handler on Duty, I typically write up a little Windows command line tip to help security people and especially incident handlers analyze and understand their Windows systems better. Most of these articles focus on very specific ways to use a given command, usually the very powerful WMIC command included in WinXP Pro, Win2003, and WinVista. But, you know, quite often, people tell me, “I like to use the WMIC command in this or that specific way, but I don’t really follow the underlying syntax of the thing.” Or, I hear, “I can never remember the overall flow of the WMIC command, so I just Google every time I need to use it to get the syntax for what I want to do.”
Remember that old saying? “Give a man a fish, and you feed him for a day. Teach a man to fish, and you feed him for…” Well, you remember it. What I’d like to do with this diary posting is to describe, in I hope an understandable and memorizable way, the overall syntax for using and exploring WMIC. Now, you may be thinking, “Well, Microsoft provides documentation of the formal WMIC syntax here.” You were thinking that, weren’t you? But, that Microsoft description is rather… let me try to be charitable here… obtuse. Let’s get practical.
For an intro and overview of WMIC, please read my earlier articles. I don’t want to regurgitate those here. For most of the way you’ll want to use WMIC, its practical syntax is as follows:
C:\> wmic [stuff to make it run against a remote system] [alias] [where with where clause] [verb with verb clause]
Yes, there are other variations and subtleties, but this structure is how I sort WMIC out in my own head, and how I most often use it. Let’s dissect these components.
If you don’t include the stuff to make it run against a remote system, WMIC takes effect on the local system. To make it run against a remote system, you would include the following as the [stuff to make it run against a remote system]:
/user:[admin_user] /password:[password] /node:[machine_name]
If you don’t provide a /password on the WMIC line, it will prompt you for one after you hit ENTER.
Next, we get to the alias. This is the component of your system that you want WMIC to interact with, such as process, startup, os, and so on. There are many dozens of aliases. To get a list of them, run this:
C:\> wmic /?
After the alias, we typically include a where clause that lets us specify what we really want to look for. WMIC with where clauses makes your whole Windows machine look like a SQL database, for which you formulate queries using WQL (the WMI Query Language, which Microsoft claims is a subset of standard SQL). Anyway, the most common form of a where clause is:
where [attribute]=”[value]”
To get a list of attributes for a given alias to include in your where clauses, you could run this:
C:\> wmic [alias] get /?
Note also that where clauses can use ANDs and ORs, as in:
C:\> wmic process where (name=”cmd.exe” or name=”calc.exe”) list brief
This command shows you a short listing of various important attributes of all processes named cmd.exe or calc.exe.
Also, we can match substrings in a where clause with the use of like and %, as in:
C:\> wmic process where (executablepath like “%system32%") list brief
This shows you a short listing of processes running out of any directory named system32 on your box.
Then, we get to the verb clause. There are various verbs supported. To get a list of them, you could run:
C:\> wmic [alias] /?
Let’s look at some of the most common verbs:
list: this verb shows the value of a bunch of attributes of the given instances identified by the alias and where clause. Whew! That sounded like gobbledygook. Essentially, list just lists values for specific stuff. It’s most commonly used as “list brief” (see above), which gives you one line per instance of the things you are looking at with the most important attributes listed. The other common use is “list full” which shows all values of all attributes of the given thing we are analyzing. Compare:
C:\> wmic process list brief
C:\> wmic process list full
Note that I’ve omitted the where clause here to look at every process on the box.
get: get retrieves specific attribute values, from a list you can specify. So, if you only wanted to get the processID, name, and executable path for processes named cmd.exe on your box, you would run:
C:\> wmic process where name=”cmd.exe” get processid, name, executablepath
This can be used to create customized reports. Note that, unfortunately, the columns you get in the output are in a pre-baked alphabetical order by attribute name. That is, the output will show executablepath first, name second, and processid third, because e comes before n, which comes before p. That’s kind of a bummer, but you could write scripts or use a spreadsheet to manipulate this order.
delete: removes some entity from your system. Be careful with this one, because it can really hose up your machine if you are not careful. But, it can be used to kill processes, as in:
c:\> wmic process where name=”cmd.exe” delete
Boom! That’ll kill all cmd.exe processes running on the box. That technique, when used with the right name or names, can be quite helpful in killing spyware processes and bots, by the way.
UPDATE: You see how I said "be careful" up there... well, I meant it. One of our readers has really hosed his system up by deleting stuff that shouldn't be deleted. You remember Spider-Man's mantra... with great power comes great responsibility. WMIC does give us an option for lowering the chance of messing ourselves up, though. You can follow the wmic invocation with the option /interactive:on and it will prompt you with a (y/n) question before taking an action that may hurt your machine, as in:
c:\> wmic /interactive:on process where name=”cmd.exe” delete
Note that just deleting all processes named cmd.exe doesn't hurt your system... but deleting many other things can.
call: This is the big one. It lets you call specific methods that are supported by that alias. These methods could let you take all kinds of useful and sometimes crazy actions on your system. While list and get just pull data, the call verb can be used to change stuff. To get a set of the methods supported for a given alias, you could run:
C:\> wmic [alias] call /?
As in:
C:\> wmic process call /?
C:\> wmic nicconfig call /?
There are some quite interesting methods in the process and nicconfig aliases as you can see above. The verb clause is a set of parameters you might pass into the verb, which, for the call verb could be some parameters that the method requires, as in:
C:\> wmic process call create cmd.exe
This command calls the create method in the process alias to make a new process named cmd.exe, a new command prompt running on your box. I’ve found this technique useful in kicking-off a background anti-virus or anti-spyware scan executable with some AV and AS products that support command-line use.
So, there you have it… by combining these various aspects, you can explore WMIC to your heart’s content. I hope you have fun with this stuff!
--Ed Skoudis
Handler on Duty
Intelguardians
Remember that old saying? “Give a man a fish, and you feed him for a day. Teach a man to fish, and you feed him for…” Well, you remember it. What I’d like to do with this diary posting is to describe, in I hope an understandable and memorizable way, the overall syntax for using and exploring WMIC. Now, you may be thinking, “Well, Microsoft provides documentation of the formal WMIC syntax here.” You were thinking that, weren’t you? But, that Microsoft description is rather… let me try to be charitable here… obtuse. Let’s get practical.
For an intro and overview of WMIC, please read my earlier articles. I don’t want to regurgitate those here. For most of the way you’ll want to use WMIC, its practical syntax is as follows:
C:\> wmic [stuff to make it run against a remote system] [alias] [where with where clause] [verb with verb clause]
Yes, there are other variations and subtleties, but this structure is how I sort WMIC out in my own head, and how I most often use it. Let’s dissect these components.
If you don’t include the stuff to make it run against a remote system, WMIC takes effect on the local system. To make it run against a remote system, you would include the following as the [stuff to make it run against a remote system]:
/user:[admin_user] /password:[password] /node:[machine_name]
If you don’t provide a /password on the WMIC line, it will prompt you for one after you hit ENTER.
Next, we get to the alias. This is the component of your system that you want WMIC to interact with, such as process, startup, os, and so on. There are many dozens of aliases. To get a list of them, run this:
C:\> wmic /?
After the alias, we typically include a where clause that lets us specify what we really want to look for. WMIC with where clauses makes your whole Windows machine look like a SQL database, for which you formulate queries using WQL (the WMI Query Language, which Microsoft claims is a subset of standard SQL). Anyway, the most common form of a where clause is:
where [attribute]=”[value]”
To get a list of attributes for a given alias to include in your where clauses, you could run this:
C:\> wmic [alias] get /?
Note also that where clauses can use ANDs and ORs, as in:
C:\> wmic process where (name=”cmd.exe” or name=”calc.exe”) list brief
This command shows you a short listing of various important attributes of all processes named cmd.exe or calc.exe.
Also, we can match substrings in a where clause with the use of like and %, as in:
C:\> wmic process where (executablepath like “%system32%") list brief
This shows you a short listing of processes running out of any directory named system32 on your box.
Then, we get to the verb clause. There are various verbs supported. To get a list of them, you could run:
C:\> wmic [alias] /?
Let’s look at some of the most common verbs:
list: this verb shows the value of a bunch of attributes of the given instances identified by the alias and where clause. Whew! That sounded like gobbledygook. Essentially, list just lists values for specific stuff. It’s most commonly used as “list brief” (see above), which gives you one line per instance of the things you are looking at with the most important attributes listed. The other common use is “list full” which shows all values of all attributes of the given thing we are analyzing. Compare:
C:\> wmic process list brief
C:\> wmic process list full
Note that I’ve omitted the where clause here to look at every process on the box.
get: get retrieves specific attribute values, from a list you can specify. So, if you only wanted to get the processID, name, and executable path for processes named cmd.exe on your box, you would run:
C:\> wmic process where name=”cmd.exe” get processid, name, executablepath
This can be used to create customized reports. Note that, unfortunately, the columns you get in the output are in a pre-baked alphabetical order by attribute name. That is, the output will show executablepath first, name second, and processid third, because e comes before n, which comes before p. That’s kind of a bummer, but you could write scripts or use a spreadsheet to manipulate this order.
delete: removes some entity from your system. Be careful with this one, because it can really hose up your machine if you are not careful. But, it can be used to kill processes, as in:
c:\> wmic process where name=”cmd.exe” delete
Boom! That’ll kill all cmd.exe processes running on the box. That technique, when used with the right name or names, can be quite helpful in killing spyware processes and bots, by the way.
UPDATE: You see how I said "be careful" up there... well, I meant it. One of our readers has really hosed his system up by deleting stuff that shouldn't be deleted. You remember Spider-Man's mantra... with great power comes great responsibility. WMIC does give us an option for lowering the chance of messing ourselves up, though. You can follow the wmic invocation with the option /interactive:on and it will prompt you with a (y/n) question before taking an action that may hurt your machine, as in:
c:\> wmic /interactive:on process where name=”cmd.exe” delete
Note that just deleting all processes named cmd.exe doesn't hurt your system... but deleting many other things can.
call: This is the big one. It lets you call specific methods that are supported by that alias. These methods could let you take all kinds of useful and sometimes crazy actions on your system. While list and get just pull data, the call verb can be used to change stuff. To get a set of the methods supported for a given alias, you could run:
C:\> wmic [alias] call /?
As in:
C:\> wmic process call /?
C:\> wmic nicconfig call /?
There are some quite interesting methods in the process and nicconfig aliases as you can see above. The verb clause is a set of parameters you might pass into the verb, which, for the call verb could be some parameters that the method requires, as in:
C:\> wmic process call create cmd.exe
This command calls the create method in the process alias to make a new process named cmd.exe, a new command prompt running on your box. I’ve found this technique useful in kicking-off a background anti-virus or anti-spyware scan executable with some AV and AS products that support command-line use.
So, there you have it… by combining these various aspects, you can explore WMIC to your heart’s content. I hope you have fun with this stuff!
--Ed Skoudis
Handler on Duty
Intelguardians
Keywords:
0 comment(s)
Over-Zealous OneCare Eats Some Outlook E-mail
There is an interesting post here and a detailed discussion here of a problem that has hit some users of Microsoft OneCare. Apparently, OneCare has deleted some folks' Microsoft Outlook .PST file, destroying all of their e-mail. There are some work arounds in the post which describes how to make OneCare stay away from your .PST file. This is a problematic solution, because OneCare won't be able to scan for any malware in your .PST file, but it sure beats having all of your e-mail deleted!
Keywords:
0 comment(s)
No Microsoft Security Bulletins Planned for This Month
Woohoo! Looks like you can take that vacation you were planning next week... Microsoft announced that there are no Security Bulletins planned for next week's Microsoft patch Tuesday. Frankly, that's kind of a relief.
On second thought... you might not want to take that vacation after all... instead of patching, you might be required to clean up some infected systems.
UPDATE: One of our readers requesting anonymity mentioned that this announcement may have been a result of the upcoming Sunday switch in some geographies to Daylight Savings Time. This new schedule for DST may hose some software. Microsoft might be trying to avoid negative interactions of new patches on Tuesday only two short days after DST conversion. Interesting theory!
On second thought... you might not want to take that vacation after all... instead of patching, you might be required to clean up some infected systems.
UPDATE: One of our readers requesting anonymity mentioned that this announcement may have been a result of the upcoming Sunday switch in some geographies to Daylight Savings Time. This new schedule for DST may hose some software. Microsoft might be trying to avoid negative interactions of new patches on Tuesday only two short days after DST conversion. Interesting theory!
Keywords:
0 comment(s)
BackTrack 2.0 Released
A few days ago, the BackTrack 2.0 bootable Linux distribution was released. For the uninitiated, BackTrack is a very powerful collection of penetration testing and security-related tools, all pulled together and integrated into a fantastic bootable Linux CD package, freely downloadable as an ISO image.
The new update is very well done, including Metasploit 2 and 3, better wireless support, and much more. You can learn more about it here.
The new update is very well done, including Metasploit 2 and 3, better wireless support, and much more. You can learn more about it here.
Keywords:
0 comment(s)
×
Diary Archives
Comments