Application Control Engine

Introduction

VSP uses a dual strategy of system integrity assurance and runtime protection to ensure that even the most advanced attackers cannot exploit the server infrastructure for any malicious act.

While host monitoring capabilities of VSP ensure only the executables that are trusted and safe can execute on the server workloads, malicious actors often leverage advanced defense evasion techniques at various exploitation and post-exploitation stages of an attack cycle. This involves the execution of non-binary entities like scripts and the use of living-off-the-land binary applications. Script execution is difficult to detect using traditional signature-based controls. Living-off-the-land binaries are already a part of these servers in the form of OS packages and other trusted packages that have typical uses in enterprises. This makes it particularly critical for their usage to be controlled to allow regular business operations to continue, but it does not let attackers weaponize them.

 Typical use cases for App Control policies are:

1. Script-based attack prevention
2. Living-off-the-land attack prevention
3. Protection against defense evasion techniques
4. Critical data collection
5. Lateral Movement Prevention
6. Protection against Persistence
7. Remote-Code Execution

App Control Policies allow control over the dynamic execution of otherwise genuine binary applications. Through App Control Policies, VSP users can:

1. Block a particular binary application from running under all circumstances, even if they are generally trusted
   Example

   Block mshta.exe that attackers use to execute javascript/vbscript hosted on a remote web server.
2. For binary applications that act as interpreters and allow file-based scripts to be executed, this feature provides the definition of an allow-list of such scripts
   Example

   Allowing only certain PowerShell, bat, shell, python scripts
3. Control the execution of these binaries by ensuing
   1. Only specific command-line arguments and flags are allowed, OR
   2. Some risky command-line arguments and flags are disallowed
      Example

      Block “-encodedcommand” flag for PowerShell, used to obfuscate malicious PowerShell payload or allow only “CREATE” for schtasks.exe to ensure tampering with scheduled tasks is not possible
   3. VSP 2.8 and Above: The provided regex is compared only against the parameters and not the actual command:
      1. When the command: "/bin/ls /home/test" is executed, the commandline regex is valuated against: /home/test
      2. To match an empty commandline using a commandline regex, the user can provide "^$" as the regex input string
   4. VSP 2.7 and Below: The provided regex is compared against the command and the parameters
      1. When the command: "/bin/ls /home/test" is executed, the commandline regex is valuated against: "/bin/ls /home/test"
      2. To match an empty commandline using a commandline regex, the user can provide "^/bin/ls$" as the regex input string
4. Put additional access control on these binaries to put an allowlist or denylist for these processes so that either
   1. Only a certain set of users are allowed to run these applications, OR
   2. A specific set of users are always denied to run these applications
      Example

      Restricting usage of certain Linux commands only to root user
5. Put a runtime control on what kind of parent processes are
   1. Allowed to spawn a child process of the binary application in scope
   2. Disallowed to spawn a child process of the binary application in scope
      Example

      For binary applications powershell.exe, the only parent process that is allowed is explorer.exe, thereby allowing PowerShell execution through only interactive sessions. mshta.exe can be blocked, that attackers use to execute javascript/vbscript hosted on a remote web server
6. Put additional runtime control on allowing/disallowing the binary applications to spawn any child process
   Example

   For binary applications cmd.exe, iis.exe cannot be a parent process, thus potentially stopping remote command execution by exploiting web applications running on iis.exe

ACP Workflow

The ACP workflow is depicted below:

Out-of-the-Box ACPs

Virsec provides a set of out-of-the-box App Control Policies that users can utilize to harden their security posture. These policies are designed to stop the most commonly run malicious activities by attackers after an exploitation, using living-off-the-land binaries.

1. Windows-Default: Recommended policy for all windows servers
2. Windows-Strict: Includes all Default policy rules and some additional patterns and script configurations for strict security posture. This configuration should be reviewed before association with the host profile
3. Linux-Strict: Linux with patterns and script configuration for a script security posture

To view them, navigate to Manage > Host > App Control Policies in the left navigation page of the CMS:

Create ACP

To create a new ACP, follow the below steps:

1. Navigate to Manage > Host > App Control Policies in the left navigation page. Click ADD APP CONTROL POLICY
2. Provide the App Control Policy Name and Comment (Optional)
3. For each of the Interpreters on the installed OS, specific App Control configurations can be defined. Click ADD APP CONTROL RULE
4. App Control Policy configuration consists of four key sections:
   1. The first section defines the rule's name, the binary application for which the rule needs to be created and whether that binary is blocked. The application name field accepts regex inputs with a scope limited to a specific path
      1. Block unless allowed checkbox blocks the binary under all circumstances (unless Allow rules are created under File-Less section as described in the next section)

         Field Name	Description
         Name	Name of the Script Configuration
         Description	A short description of the configuration
         Create Configuration using	Select an existing Script Configuration that can be used to prepopulate the form
         Application	Executable file name of this interpreter configuration that will be associated with configuration. The value can be a full name or a partial name or a full path or a partial path or hash or a regular expression. Along with the Application name, the hash value is also considered during process execution
         Block unless Allowed	Select the checkbox to prevent the application from executing under all circumstances

   2. The file-based configuration defines what kind of files (extensions) are monitored for file-based execution of binary applications that are also interpreters. Signed scripts are all allowed by default
      1. Scan Criteria - The list of extensions specified here are only used during the reference host scan workflow for the purposes of generating the initial allowlist
   3. File-less configuration defines the command-line, users or parent processes that are allowed or disallowed for the binary application in the scope. This is typically the most used configuration
      

      Field Name	Description
      Command Line	Enable – Once enabled, provide the Match Type (Matches, Does not Match), regex pattern for command line execution and relevant description. It provides control on which processes can spawn the interpreter. Provide the actual file path and NOT its symbolic link (For linux). Provide only the pattern. Do not prefix “-“ to it Disable – No check for the command line is performed
      Parent Process Control	Enable – Once enabled, provide the Match Type (Matches, Does not Match), regex pattern for the parental process and relevant description. It provides a control on which processes can spawn the interpreter. The value can be a full name/partial name/full path/partial path/hash/regular expression. Disable – No check is performed on the parent process invoking the configured script. Any process can launch the interpreter
      User Access Control	Enable – Once enabled, provide the Match Type (Matches, Does not Match) and relevant user names. User should be the exact match for the username. For Windows, it is case-insensitive. Disable - No check is performed on the user invoking the configured script

   4. Dynamic Execution Rule configuration allows or blocks spawning of any child process
      1. Launch Process - Allow – Allow the script to launch processes; Block – Block the script from launching processes
   5. Click SAVE
      TIPS

      • Use a proper regex expression to specifically target the expected process AND EXCLUDE unwanted processes
      • For a particular configuration type, the user can define either an allow rule or a deny rule
      • For “Block Unless Allowed” binaries, file-less config has ability to configure allow rules
      • During ACP scan, scripts are also discovered along with the binary files
      • ACP rules are applied based on the hash values, along with the file names
      • When a combination of rules are configured - File Based, i.e., commandline, user based and parent process - Allow Rules take more precedence over Deny Rules
      • ACP takes precedence over the allowlist: A process can be allowlisted manually, as a part of scan or it is a safe process. It can be blocked ACP for the given process is attached
5. To modify the allowlist for scripts, on the Host Monitoring page, expand the profile and click Edit Allowlist
   1. Click the link Total Allowlisted Libraries/Scripts on the pop-up window and modify the allowlist as required

Example ACP Configuration

1. Block registry actions using reg.exe
2. Allow only signed PowerShell scripts (ps1,psc1) files
3. Block msiexec to install from a remote msi installer
4. Block rundll32.exe process from being spawned by the task scheduler process
5. In cases of "Allow" rules use the regex: “^$” to ignore empty parameter scenarios

ACP List on CMS

To view the ACP list on the CMS:

1. Navigate to Manage > Host > App Control Policies in the left navigation page. The list of App Control Policies is displayed
2. Click the below link to view all the associated Host Profiles associated with a specific App Control Policy

Export/Import ACP

1. App Control Policies can be imported or exported with .virsec extension
2. This feature can be used during the scenario below:
   1. When VSP protection is extended to a different environment (Example: Pre-production to Production environment)
   2. To clone an existing entry
3. Ensure that import/export operations are carried out in the same VSP version. Import/export feature is compatible across various patches in the same major release (Example: VSP 2.8.x)

Modify ACP

1. On the App Control Policies page, click Edit
2. Modify as required. Click SAVE
3. Click YES on the confirmation screen

Delete ACP

1. On the App Control Policies page, click Delete
2. If the policy is associated with a host profile, an alert is displayed and the ACP cannot be deleted