|
After last week's story, hopefully you've got your "problem" users accounts identified. With that worked out, let's see about finding problem applications. We all need a handle on what applications are installed on workstations for a number of reasons
First, let's look at the powershell command to list installed software. This is a rough equivalent of control panel / programs, or "wmic product list" Get-WmiObject -Class Win32_Product -computername If you run this, you'll see that this is *really* verbose (I won't show the output), and the list view is not so useful. Let's trim it down to Vendor, Product Name and Version: Get-WmiObject -Class Win32_Product -computername . | select vendor, name, version | format-table or, to make the display more useful, replace "format-table" with "out-gridview" or "output-csv" as we discussed last week:
But that just gives us programs that use the Microsoft installer process to install (msi's and similar packages). How about single exe type apps, things like putty.exe, sed.exe and so on? We can address those file by file: get-childitem sed.exe | fl Name : sed.exe
But we want a table view, and again just a few of those fields. The name, the original name (to account for users renaming EXE files), the file and application versions, and maybe the publisher. Some of these are a bit tricky to get, as they're lower down in the heirarchy of the object, but it's very do-able: get-childitem ssh.exe | format-list name,creationtime,lastwritetime,@{label="ProductVersion";expression={$_.versioninfo.productversion}},@{label="FileVersion";expression={$_.versioninfo.fileversion}},@{label="Original FileName";expression={$_.versioninfo.originalfilename}} Name : ssh.exe
OOOPS - looks like I'm a rev back on putty! - note that I renamed putty to ssh, but the file metadata remembers the original name for me This also works for more legitimate apps (excel is shown here): get-childitem excel.exe | format-list Directory: C:\Program Files (x86)\Microsoft Office\Office14
Name : excel.exe Great, you say, how is inventorying things one file at a time useful? Let's use get-childitem recursively and pull all the EXE's in one shot. This is a reasonable way to grab everything. With that in a spreadsheet or database, you'll likely want to delete duplicates entries (multiples for MS Office for instance), then after a closer look, store that as a baseline to track for changes at a later date. get-childitem c:\*.exe -recurse | format-table name,creationtime,lastwritetime,@{label="ProductVersion";expression={$_.versioninfo.productversion}},@{label="FileVersion";expression={$_.versioninfo.fileversion}},@{label="Original FileName";expression={$_.versioninfo.originalfilename}},@{label="Product";expression={$_.versioninfo.product}} Or, better yet, using a slightly different script and outputting to CSV - so you can more easily read it in excel or dump it to a database: Get-ChildItem -Path c:\utils\*.exe -Recurse |` $Path | Select-Object `
Note that not all values are populated in the metadata for every file - that's just the way it is when you're processing standalone files like this. Using this approach, you can see that with maybe an afternoon of scripting effort, you can set up a system that you might otherwise pay thousands or tens of thousands of dollars for - assuming that you're OK running your software inventory system from the CLI. For me, running my inventory from the CLI would be prefered, but I guess you figured that out ! Have you found a trick to process information like this more efficiently? Got a better script to collect this info more simply? Please, share using our comment form! =============== |
Rob VandenBrink 542 Posts ISC Handler |
| Subscribe |
Jun 29th 2015 4 years ago |
|
Very useful and necessary step to be able to identify unwanted system changes and possible malware. It's also important to run these commands as an admin to make sure you have permissions to scan all directories on the system. Another piece of metadata you might want to collect is the hash of each file using Get-FileHash - https://technet.microsoft.com/en-us/library/dn520872.aspx. Then you have something you can quickly throw at your favorite hash reputation service to validate an unknown file you've found.
|
Inspector16 8 Posts |
| Quote |
Jun 29th 2015 4 years ago |
|
There's a warning here:
http://blogs.technet.com/b/heyscriptingguy/archive/2011/11/13/use-powershell-to-quickly-find-installed-software.aspx about running WMI queries against win32_product. Also, when building expressions using the old style: @{label="FileVersion";expression={$_.versioninfo.fileversion}} is deprecated and may not work on newer version of of Powershell. Use the newer style (as you do later in the post): @{n="FileVersion";e={$_.versioninfo.fileversion}} n being short for name and e being short for expression. |
psophos 6 Posts |
| Quote |
Jun 29th 2015 4 years ago |
|
Could be a useful addition to forensics work, either investigating systems or to ensure you have a record of tools versions while you work
|
Tim 1 Posts |
| Quote |
Jun 30th 2015 4 years ago |
|
There are also many commercially available version/patch scanners. To name a few examples: ScanCircle, Secunia PSI/CSI, FileHippo. These are free for personal use, commercial use often requires a license.
|
Vincent T 14 Posts |
| Quote |
Jul 2nd 2015 4 years ago |
|
Thank You Rob! Two excellent and useful posts.
I also have a subscription to powershell.com, where they produce a regular email newsletter with equally excellent tips almost daily. Keep up the good work! Robert |
Vincent T 1 Posts |
| Quote |
Jul 2nd 2015 4 years ago |
Sign Up for Free or Log In to start participating in the conversation!
