Application Control is a module created to control which processes (or applications) can be executed on client machines and how they are executed. You can define a set of rules that describe what processes are allowed or blocked on your machines (in your environment) using details like Software Name, Paths, Publisher, MD5, Signature, or Wildcard Paths.
How Application Control works behind the scenes:
- Refactor mechanism to block applications using REP blocking repository
ProcessLock Service captures every process once it’s started and checks if it’s allowed or not. If the process needs to be blocked, it will be killed along with all its children in max 5 seconds.
If the blocked process is executed for the first time, the process might start, but will be killed immediately. From the second try of execution, process won’t start at all, because of the blocking repository.
The blocking repository consists in a list of items stored in local computer’s registry (path: Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options). Here, for each blocked process, we will add a redirect path to one console application (will be described in next task). Basically, from the second try of execution of a blocked process, Windows will take over and won’t open that process, but instead will open our console app.
Because we are using the same process blocking repository as the REP module, the files that were created or updated by AppControl will have HTag value set on 2 (Created) or 3 (Updated). 0 corresponds to Created by REP, 1 corresponds to Updated by REP.
Redirection app to capture executing process alongside the command line
In order to log all blocked applications, we created a console application, named “Heimdal.ProcessLock.ConsoleTrigger.exe”. It’s located in Heimdal installation folder. On first try of executing a process that should be blocked, we add a new record in the repository described above and we set a redirect path to our ConsoleTrigger. This way, every time an user will try to run a blocked app, our console will be opened instead and will notify ProcessLock Service regarding the attempt. Further, ProcessLock service will log the attempt and send it to dashboard, if necessary. The console app won’t appear on user’s screen and will be opened for a few seconds max.
Whitelist mechanism for the "allow" rules
For “allowed” processes, we won’t save any data in registry. On policy update, if default file action is set on “Allow” and there aren’t any rules created, we will clear all registry that were created / updated by App Control (Hashtag values 2 or 3, as described in Task 23629). If there are still any rules defined in GP, we will search for each process blocked in registry by App Control and remove only those processes that are not blocked anymore (either by default action or rule).
- Allow with auto-elevation
If we intercept a process that was just opened and we found a rule that matches it, if the process was started as a normal user (not with administrator privileges), we will kill it and will open it as Administrator, using the existing mechanism from “Run with AP”. This functionality isn’t affected by Patch & Asset Management, it’s operational even the client does not have Patch & Asset Management enabled from Group Policy or from licensing options.
- Hide "Always allow system executions" from dashboard
Because of the new mechanism of blocking processes, we decided to remove from dashboard that option from App Control Group Policy options, because it might cause some issues to our clients. In combination with Default File action set to “Block”, we kill all processes, including the one that were vitals for Windows to run, and that behaviour translates in BSOD over BSOD, over and over again. We hardcoded for ALL of our clients “Allow system file executions” to be enabled and removed the option from Group Policy editor view in dashboard.
- Update registry repository for Auto-elevation rules
For rules that have the option for “allow with auto elevation” now we use almost the same mechanism as for blocked processes. In the same location in registry for blocked applications, for applications that match rules with “Allow with auto elevation”, we add a new entry with a redirect path to a new console application, that sends a message to ProcessLock service, in order to log the execution and start that application with administrator privileges (it’s using the same method like Patch & Asset Management or Run with Admin Privilege.
Every time a policy update event is triggered, we clear all the registry for these kind of rules and recreate all entries based on rules for full path defined on GP. Also, when the service is stopped, we remove all registry values for those files.