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. In order to have a good experience using the HEIMDAL™ Security services and the HEIMDAL™ Application Control, we recommend you take a look at the following information.
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. Application Control can handle how a process (it can get automatic elevation from the Heimdal™ Privileged Access Management module, if so configured) or child process (it can allow or block all processes spawned by the process defined by the rule) should run.
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 services 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 the dashboard
Because of the new mechanism of blocking processes, we decided to remove from the dashboard that options from App Control Group Policy options, because it might cause some issues to our clients. In combination with the Default File action set to “Block”, we kill all processes, including the ones that were vitals for Windows to run, and that behavior 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 the Group Policy editor view in the 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 the 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 Privileged Access Management.
Every time a policy update event is triggered, we clear all the registries for this kind of rule and recreate all entries based on rules for the full path defined on GP. Also, when the service is stopped, we remove all registry values for those files.
Application Control View
The Application Control view displays a table with all the intercepted processes. You get information about the Process Name, the number of executions, Publisher, Software Name, Version, Group Policy, MD5, and the Status. The processes can be filtered using the following filters: All intercepted applications, Matching Allow rules, Matching Block rules, Matching Allow by default, and Matching Block by default.
1. All intercepted applications - displays all the applications that have been running on the machine(s)
2. Matching Allow rules - displays the latest interceptions that match the 'Allow' rule
3. Matching Block rules - displays the lastest interceptions that match the 'Block' rule
4. Matching Allow by default - displays the latest interceptions that match the "Allow by default' status (a process is allowed by default if the Default File Action is set to Allow)
5. Matching Block by default - displays the latest interceptions that match the "Block by default' status (a process is blocked by default if the Default File Action is set to Block)
6. Matching allow with auto-evaluation -allows the process to automatically get elevated by the Heimdal™ Privileges & App Control module
7. Dropdown button - after selecting a machine, you can choose from the two options what action do you want to take ( Allow & Block).
Block - adds the selected process to the ruleset with Block as Action Type
Remove from allowed list - removes the process from the ruleset if a matching process with Allow as Action Type is matched
Remove from block list - removes the process from the ruleset if a matching process with Block as Action Type is matched
Allow - adds the selected process to the ruleset with Allow as Action Type
Once you select a process, the Block and Allow buttons will activate:
After hitting the Allow or the Block button, a modal that enables configuration of the rule will appear:
The Global rule radio button applies the rule on all the Group Policies, while the Custom policy global block/allow rule applies to one or more Group Policies that can be specified in the dropdown field.
To configure a rule, the user needs to consider the following Rule Types: Software name, Path, Publisher, MD5, Signature, or Wildcard Paths (once a Rule Type is selected, the Subject field is automatically generated).
Priority - rules are processed based on priority numbers (the higher the number is the higher the priority is). Leaving gaps between each rule is recommended (10, 20, 30, 40, etc.) in order to have an easy and neat rule organization, without having to edit existing rules (priority ranges between 0 and 1000)
Application Control Group Policy Settings
Ruleset Mode - sets the way the Application Control rules work
Default File Action - allow or block processes that are not matched by the Application Control Rules
Application Control RulesYou can manually add a new rule to the Application Control Rules by specifying the Rule Value, the Rule Type (Software Name, Path, Publisher, MD5, Signature, or Wildcard), the Priority (0-1000), and the Action (Allow / Block).
Priority - rules are processed based on priority numbers (the higher the number is the higher the priority is). Leaving gaps between each rule is recommended (10, 20, 30, 40, etc.) in order to have an easy and neat rule organization, without having to edit existing rules. Priority ranges between 0 and 1000
Allow auto elevation - allows the process to automatically get elevated by the Heimdal™ Privileged Access Management moduleInclude spawns - allows the spawns of child-processes from the parent-process (only for processes that are Allowed)
All added rules are listed in the Application Control Rules table. They can be edited or deleted from the Action column.
On adding a new rule, a check for duplicate entries is performed. If there is another rule with the same values, a message will appear to inform you regarding this fact:
Besides that, a check for a rule that is already defined with a different Action Type (allow instead of block or vice-versa) is also performed. In this case, a popup will appear to inform the user regarding this aspect. If the user confirms it, the existing rule will be overridden with the new value on the Action Type:
e.g. If the previous rule was to block the execution of chrome.exe, and the new status is to Allow, the Action Type will be changed from Block to Allow, without adding a new record in the rules list.
If the user doesn’t want to change the existing rule, the fields for inserting a new rule will be cleared, offering the possibility to create a different kind of rule.