In this proof of concept (PoC), we'll take a look at using Cortex XDR to block software installations in a test environment.
This PoC focuses on blocking files that use the .msi and .exe file extensions. These file types are widely used for common software installations and should serve to cover a broad base of applications. For testing, four executable files will be installed: Two .msi and two .exe files. From there, we’ll try to find anything we can use to block the installations. We're also going to focus on BIOC’s and prevent the execution of these files and their associated processes.
Please note: These processes were tested in a lab environment. Any attempt to reproduce the process described in this article may have various results.
For this PoC the following will be required in your environment:
Installation typically involves code (program) being copied/generated from the installation files to new files on the local computer. It provides easier access via the operating system — creating necessary directories, registering environment variables, providing separate programs for un-installation, etc. Because code is generally copied/generated in multiple locations, uninstallation often involves more than just erasing the program folder. For example, registry files and other system code may need to be modified or deleted for a complete uninstallation.
The most common types of installation files are .msi and .exe. These will be the focus of this PoC. Other types of installation files exist such as .bat, .com, .cmd, .inf and .run, but for this PoC we’re only going to focus on .msi and .exe as they’re the more prevalent types of installation files available.
The .exe extension may be one of the most easily recognizable file formats in existence. An executable file (EXE file) is a computer file that contains an encoded sequence of instructions that the system can execute directly when the user clicks the file icon. Executable files commonly have an EXE file extension, but there are hundreds of other executable file formats.
With Windows, EXE is the file extension for an executable file. All EXE files are executable files, but not all executable files are EXE files.
Executable files with the .exe extension also come in different types such as portable executables. For this PoC we’re going to focus on installation files and not any of the other types.
Below is an image of the contents of the VLC Media Player install file with its contents extracted using the 7 zip utility.
An MSI file is a Windows package that contains installation information for a particular installer, including files to be installed and installation locations. It may be used for Windows updates or third-party software installers.
Windows uses the Windows Installer program to open MSI files. This program was previously named the Microsoft Installer, which is what gave MSI files their name.
Below is an image of using the 7 zip utility to extract the files inside of Firefox Setup 14.0.1.msi.
Developers may save Windows application installers as .MSI files instead of EXE files. MSI files are similar to EXE files, except they always contain application installers. They never contain Windows applications or other programs. Windows always uses Windows Installer (a utility included with Windows) to open MSI files and install the program they contain.
Chrome and VLC Media Player are now going to be installed on the test machines. Once that’s completed we can investigate the causality chain and see if there are any interesting characteristics that we can hone in on.
Below are the Causality chains for the install of our two installation files for Google Chrome and VLC Media Player respectively.
At first glance nothing seems to pop out. After going through things like file actions, registry modifications and processes there don’t appear to be any similarities. We did see something interesting in the target_process_cmd for chrome set up, though:
The use of the /install flag is not something that has been seen in all software installations, but it may be something we can use later.
The aforementioned .msi files have now been installed on our test host. Now we’ll take a look at the installations of all files and see if we can discern any useful information about them that will help us block the installation of these files on another test machine.
Let’s begin by first looking at our .msi files. We’re going to do a simple query to pull up all the data on our endpoint over the previous 24 hours.
By navigating to Incident Response -> Query Builder we can select ‘Process’. From there we’re going to type in the name of the test machine and run the search.
Select Process after selecting query builder
Querying the test machine's host name
Once the search is run we can filter through the results by narrowing down on ‘target_process_cmd’ and selecting any entry that contains .msi as seen below.
The images below represent the causality chain for the install of our two MSI files. Looking at these two images we can quickly see a similarity.
The command that executed the install for these files uses a file called msiexec.exe with a flag and then the location of our installation files.
The genuine msiexec.exe file is a software component of Microsoft Windows by Microsoft.
Microsoft Windows is an operating system. Windows Installer is an application programming and software component of Microsoft Windows. Msiexec.exe is part of the Windows Installer utility and is used to install MSI and MSP packages, and is completely safe for your PC.
In our install example we saw the /i flag being used which is the flag for a normal installation. Below is a table that describes the syntax for msiexec.exe
When it came to our .exe installations, we didn’t see any similarity between the two files we chose for this PoC. In actuality, several different applications were installed into our test machine and, after analyzing the data, I’ve concluded that while some installations can be blocked there is no one-size fits all for this.
While looking at the installation for Google Chrome we did notice the use of a flag /install. This could be used to stop the installation of Google Chrome. By creating BIOC, focusing on process execution and setting CMD =~ install. This BIOC will stop the install of Google Chrome and an installer that uses the same flag. Again, in our testing Google Chrome was the only application that used the flag on install. This will work for our specific application, but be warned it may have the undesired consequences in your environment. Testing in a non production environment should be used before trying to apply a rule like this.
Another avenue which could be used is a BIOC that would block the execution of any files that have the .exe extension. However, during testing this proved to be troublesome. Windows relies on a lot of files in the background that run without the user ever seeing them. Some of these are crucial to basic windows functionality. Blocking the execution of any .exe program will undoubtedly cause unexpected issues as it did during testing.
There’s also the use of CMD. For the install of all of the software during this testing we’ve been relying on what commands were used in CMD. What if we just blocked the execution of cmd.exe? Well, that also has some very unexpected consequences. While it does block software installations, it now allows the use of any CMD commands, and also prevents any internet browsing and opening of most programs. This is because CMD is crucial to the Windows operating system.
When dealing with known software to block an IOC, a rule can always be used instead by using the full name, file path or hash value. For this PoC the goal is to stop the installation and not just remove the file.
When it comes to .msi installations we did find some interesting similarities in their execution. We discovered the file msiexec.exe. Creating a BIOC to block the execution of this file should result in blocking any attempts to install applications using the .msi extension. We’ll navigate to Detection Rules -> BIOC and select ‘process’. Once there we’ll type ‘msiexec.exe’ into the name filed under process and create the BIOC.
Now the rule will be added to our prevention profile and applied to our test machine.
SUCCESS!
After applying the rule to the test machine and attempting to install an application using the .msi extension, it was blocked. Below we can see an image of the alert generated by msiexe.exe. This was tested several times and all resulted in success.
This is because the software installations require the use of msiexec.exe.
In this PoC we demonstrated how Cortex XDR can be used to block software installations. We were successfully able to block .msi installations and had mixed results with .exe installations.
While Cortex XDR can be used to block software installations, there are better ways to achieve this; a great use case for this would be an air-gapped portion of your network that was only used to perform certain specific functions. For production environments I would recommend using Group Policy Objects (GPOs), as they would allow administrators to block all software installations by disallowing users to do things like make registry changes based on user groups. GPOs could be used to block the executions of executable files, but wouldn’t be a recommended use case for Cortex XDR. Based on the testing shown in this PoC Cortex XDR could be used to block .msi based installations. Again, I would caution any user to conduct testing in their own environment before trying this in a production environment.
Cortex XDR PoC: Software Installations Blocking References:
FileInfo.com: MSI File Extension
Cortex Help Center: Create an IOC Rule
Cortex Help Center: Create an BIOC Rule
