1. How to inventory Windows installed software
Jonathan Risto
December 2016
GIAC (GAWN Gold, GCIH Gold, GSLC Gold, GLEG Gold, GWAPT Gold, GCCC Gold, GSNA Gold, GPEN, GCFA, GSEC, GCPM)

2. Objective Importance of a software inventory
Why is this such a problem to collect
Where is this information stored
Methods to collect the information
Scripting for speed and accuracy
Conclusion
The goals of this talk are to:
Discuss the importance of having a software inventory for devices within your network
Why is collection this information from Windows workstations such a problem to do
Where does Microsoft store information on installed software
How can we collect this information from Windows computers
Why scripting this up makes sense
Concluding remarks about the collecting this information

3. Control 2 of the 20 Critical Controls
The second item of the 20 CSC is software inventory
Without a software inventory
Cannot know vulnerabilities
Cannot keep systems updated
Cannot validate authorized software
The 20 Critical Controls state that goal of control 2 is to :
“Actively manage (inventory, track, and correct) all software on the network so that only authorized software is installed and can execute, and that unauthorized and unmanaged software is found and prevented from installation or execution.”
Within control2, it also states in section 2.3 that:
“ organizations should deploy inventory tools that track versions of the applications installed on the system in question”.
But why is this important to us as security professionals?
Without accurate information on what software is installed on a computer we cannot know what vulnerabilities exist on that computer. As well, we cannot keep the system patched and updated without knowing which software needs to be patched. A third reason that we need this information is to validate that only approved software is installed on a system.
All of these points are important to securing the system in question. To attempt to secure a computer without this information is practically impossible.

4. Where can we find it?
Windows does not have just one location to register an installed program
Example registry key locations include:
'HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\'
'HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\'
No single query can return the required information
Microsoft doesn’t make it easy to locate and know what software is installed on any computer. There are multiple registry keys where this information CAN be stored, but it is not mandatory to store the information at all.
The installing program is left to record the needed information within the registry keys on the computer. If it chooses not to place any information within the registry hive, then nothing will be known about the piece of software in question.
The two most popular locations where installation information is stored on a Window system are the following registry key locations:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\
HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\

5. Collection problems
There are challenges with collecting the information from the registry. This is primarily due to the fact that the vendor/software creator is the one that needs to properly register the information within the registry hive within the Windows system.
For example, the first screen shot shows an entry for 7-zip. This software has populated a large amount of information into the Registry, including the DisplayName and Version fields, which are queried by tools. For the tool such as WMIC to function, these two data fields need to exist and have the correct information entered into them.
The second example shows us an entry with minimal information completed, but it still contains the Version information for the software in question, that has a value of A fairly detailed software version. However, it does not contain the name of the software.
The third example shows another registry entry, which contains details on yet another piece of software. In this case, the DisplayName is properly completed, and informs the user that this is for the Intel Wireless Display program. It shows other information as well, but unfortunately it does not contain the information for the product version number.
The last example shown gives an example of a piece of software that would not report correctly in some tools. Within this example, an administrator looking at the system would be able to tell this is for the Dell Support Center software, but no information is available on the version of the product. However some tools, such as WMIC, would not report back any useful information, as the two fields needed are not present, namely the DisplayName and Version fields.

6. Available tools for collection
Commercial tools
E.g. Tripwire, Software Inspector, Nessus
Free tools
E.g. OCS inventory, PsInfo
Built-in tools
E.g. WMIC, PowerShell
There are numerous ways to collect the information on installed software on a Windows system.
Some commercial tools that can perform the task are:
Software Inspector by Secunia
Tripwire by Tripwire
Nessus by Tenable
Endpoint Manager by IBM
Some free tools that can assist with the collection are:
PsInfo.exe and PsInfo64.exe (part of the suite of tools from the Microsoft Sysinternals group)
OCS inventory
Some built in tools/commands that can help collect the needed information are:
- Wmic
- PowerShell

7. PsInfo
PsInfo is a Microsoft Sysinternals tool that can collect local or remote system information
Version 1.77 used in paper
Run from command line
psinfo.exe -s applications
PsInfo is a tool that is released and maintained by the Sysinternals group at Microsoft. It is part of the larger PsTools suite that they have created to assist with computer administration.
PsInfo offers a large amount of functionality, more than what is needed for this work. It is able to list disk information, installed hotfixes, and even kernel build details. Details on these features are beyond the scope of this presentation. However, the one item we will focus on is PsInfo’s ability to list the applications installed on a system.
Accessing the HKLM/System section of the registry hive to obtain this information, PsInfo collects the installed software on the system by using the –s switch. By also adding in the applications filter, this removes additional information that PsInfo normally returns when run, which includes processors, memory and video driver information.

8. PsInfo output example
The output shown on the screen is created by running the following command:
PsInfo –s application
One benefit of using PsInfo is that the information is sorted alphabetically, unlink some of the other command line tools.
PsInfo output is fairly easy to interpret. After the legal banner, it provides the system name you are querying, in the example it is JONATHAN-PC.
The tool then lists the application name, with the version number, with each application on a separate line.
Since this tool is a Microsoft product, it does support all versions of Windows, from Windows Vista (since XP is no longer supported by Microsoft, but the tool does work on XP) to the current Windows 10 operating system. It also works on all server versions from Windows Server 2008d and higher (again, all of the currently supported platforms).

9. WMIC Windows Management Instrumentation Command-line
Permits access to query and change system functionality
To collect inventory information
wmic product get name,version
WMIC, which stands for Windows Management Instrumentation Command-line, provides the interface to the WMI (windows Management Instrumentation) for users. It offers a collection of options that enable the local or remote administration of a computer. The options include the ability to display the system environment settings, network configuration, and even physical disk management.
For a software inventory, only the product option is needed. Within the product option, the vendor, product name, installed date and even the install location are all available options. As we saw previously on slide 5, this information is all available within the registry hive, and WMI permits access to query these values.
For this work, the product name and version is the only information that we were interested in, so to complete that query, the following command was run
wmic product get name,version
This will produce a listing of the software installed on the system, with the associated product version numbers that are found within the registry. The output is able to be redirected to a file as desired also.

10. WMIC example
In the example output shown, WMIC has returned the values that were requested on a Windows 10 system with the command:
wmic product get name,version
Within this output, it is easy to see that the information is not sorted in alphabetical order. How this information is presented is in the order that it appears within the registry keys themselves. The first entry is before the second and so on.

11. WMIC output issues
As discussed previously, the information that is reported by the various tools is only as good as the information that is contained within the registry keys being queried.
In this example, from a Windows 7 computer, shows that there is an entry with a blank name, but it has a version number associated with it. What is this software? Without opening the registry hive and searching for the key this information came from, it is not possible to know what software this version number is associated with.

12. PowerShell Uses the OpenSubKey and GetValue cmdlets within PowerShell
Accesses the following registry locations and iterates through each subkey
SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\ ,
SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\
PowerShell is Microsoft next generation shell environment that was first introduced as Monad in October 2003 with the first public release, after a renaming, in April of 2006.
PowerShell is able to run scripts, specific functional created in the .NET environment, called cmdlets, as well as standalone executables. This flexibility, as well as the vast number of cmdlets that are coded into PowerShell give the tool a large advantage over the standard command prompt.
For this work, two specific cmdlets were utilized. These were OpenSubKey and GetValue.
OpenSubKey permits the opening of a registry hive on a local or remote system.
GetValue reads the values of the registry key and returns the information back for display or storage in a variable.
By using these two cmdlets in combination, we are able to open any registry key and read the value associated with any key within the hive. For this work, the following registry key locations were utilized to gain access to the software inventory information:
SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\
SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall

13. Scripting it all together
Running commands on individual systems is tedious at best
Summer student project 
However, scripts provide a quicker means to accomplish the tasks
Two primary methods to create Windows scripts
Batch scripting
PowerShell
So far it has been discussed how the to collect the installed application information from Windows systems using a variety of methods. However, each of these methods is a done through the command line and accesses one system at a time.
In order to scale the solution, collect the required information, and ensure that data entered is correct, scripting the comments is the only viable solution for an organization of any size.
Windows provides several methods to create a script. One is to use batch scripting. Another is to use PowerShell.
Batch scripting is a collection of commands that are placed into a text file that is able to be run by from the command prompt.
PowerShell scripts are similar, however, they use the syntax of PowerShell and can be run within PowerShell or can be invoked from the command line.

14. Scripts within the paper
Scripts examples include:
Batch file for PsInfo and WMIC collection
PowerShell script for PS commands
All query for IP address to inventory
Some checking is performed for valid data types and entry
Output stored in text file for archiving and future reference
For this paper, 3 scripts were created. Two via batch programming and the third in PowerShell.
Appendix A contains the PsInfo and PsInfo64 script, which collect the required information using the Sysinternals tools.
This script first asks for the IP address of the system to run the commands against. Next, it determine the date and time to use in the file output. Once this information is collected, the two programs are run, and the information is stored into a file.
Once the file is created, some commands are run to sort the information into alphabetical order, and also to remove duplicate entries that may have occurred due to running multiple commands.
When completed, the output is stored into a file that contains the IP address that was queried, as well as the date/time that it was collected.
Appendix B contains the WMIC script. Similar to the PsInfo script, we ask the user for the IP address that they wish to query. As well, we collect from the system the date and time information to be used in saving the final file.
The command is then run within the script, using the IP address entered, and stores the information into a text file named with the IP address and date/time information for uniqueness.
Appendix C contains the PowerShell script.
This script is more complex that the previous two batch scripts. This script performs input checking on IP address that is provided by the user, and ensures it is in the correct format. If not, it loops back and asks the information again and informs the user that there was an issue. The date/time information is again collected. The procedure that collected the registry information is then run, and the output is stored into a text file in a similar format as the other two scripts, IP address with the date and time information in the filename.
BONUS
Creating a software inventory is the first step in the process of understanding what is installed on your computer systems. From a control perspective, it is excellent, but wouldn’t it be nice to understand what is on your system compared to the baseline that was created for the system in question?
Knowing what is in place today compared to what is in the baseline is crucial to understanding if there are process or administrative control problems within the environment.
If a user can install software or update the software, without the IT organization knowing or updates occur without the baseline inventory being updated, there are areas that require further work within the organization.
A paper that discusses how to audit the software inventory, as well as provides scripts for the comparison based on the scripts in this paper can be found in the SANS reading room. The paper is called “Auditing Windows installed software through command line scripts“ and it is by Jonathan Risto.
The paper can be found at the following link:

15. Conclusion 3 methods discussed in paper
Scripts provided automate the process
Increases visibility and understanding of the network
Major first step to remediation
Within the paper, 3 different methods to collect the windows installed software are presented. While command line methods are excellent to manage devices, their ability to scale out can be limited. To help address this problem, scripts have been provided that ask for the IP of the computer to scan, and then scan the system in question, storing the results in a unique file. With minimal changes, these scripts could be modified to handle ranges to IP address, and would scan each of them in turn.
Once we have an accurate software inventory, we are well on our way to be able to properly remediate the vulnerabilities within our network, and to ensure that unauthorized software that has been installed is able to be found without our environments.
To read the complete paper, and get access to the scripts, please go to the following link: