Overview of the program for proactive computer protection Defense Wall HIPS. Add or remove untrusted. Using HIPS to Create Complex Shapes
General information
When the component HIPS enabled, the activity of applications is restricted in accordance with the rules. Situations for which the rule is not set are resolved depending on the HIPS mode, program rating, and other conditions.
Normally, Safe Mode allows trusted programs to do any activity that is not prohibited by the rules, except for running unrecognized files. The launch of unidentified programs, as well as any action of these programs, is blocked by alerts.
The paranoid mode stops any activity of any programs that is not provided for by the rules with alerts.
In the Learning Mode, any activity of any application not covered by the rules will automatically create new allowing rules.
The rules are presented on the tab HIPS → HIPS Rules as a list applications and appointed by them rule sets.
Applications can be exact file paths, path patterns with * and ? , as well as groups of files. In paths and their patterns, you can use . Filegroups are sets of paths or patterns, they are configured on the tab File rating → File groups. I emphasize that applications in the HIPS rules are identified only by their paths, and not by hashes, etc.
The set of rules assigned to an application consists of two tabs: Permissions and Security Settings. On the first one, the rights of the application itself are set, on the second, on the contrary, its protection from other programs. An application can either own set of rules, or one of the pre-generated sets: they are configured on the tab HIPS → Rule sets.
The preinstalled set of rules "Windows system application" allows any activity, the set "Allowed application" - any, but does not regulate the launch of child processes; the "Isolated application" set strictly prohibits any activity; the "Restricted application" set denies almost everything except window messages and monitor access, and does not regulate the launch of child processes. You can not only create your own sets, but also change the preset ones.
As of CIS 10.0.1.6223, the "Isolated Application" HIPS rule set has been renamed to "Application Running in a Container". In my opinion, this is an erroneous translation of the name "Contained Application", since in reality the HIPS rules have nothing to do with the Container (virtual environment). To avoid confusion, I recommend renaming this set back to "Isolated Application", and in the article it will be called that way.
A special case is the "Install or Update" rule set, which grants . Programs with such privileges freely perform any actions (except those explicitly prohibited by the rules), incl. run any programs, and their child processes also get installer privileges. Executable files created by such programs are automatically trusted.
Different initial configurations of COMODO Internet Security differ both in the initial set of rules and in the controlled range of program activities. For the most complete HIPS protection, you must initially select a configuration Proactive Security and already from it to conduct further configuration.
When restricting programs' access to various resources, HIPS relies on partition data HIPS → Protected objects. For example, a file or directory can only be protected from modification if it is full name matches any of the templates on the "Protected Files" tab. So, if you want to prevent any program from modifying files on the D: drive (regardless of their type), you must first add this drive to the list of protected ones.
Then, when creating specific rules, it will be possible to vary the access restrictions to certain protected objects by clicking "Edit" in the "Exceptions" column.
It is most advisable to use HIPS in safe mode by turning off the option Create rules for secure applications, or in Paranoid. Then the order of determining the access of the program to the resource will be as follows:
As you can see, in HIPS, the “Ask” action expresses the absence of a rule (unlike in a firewall, where it instructs to show an alert).
So, the "Allowed" tab of the topmost rule that is suitable for this program has the highest priority; then - the tab "Blocked"; then - the action specified in this rule, if it is unambiguous; then - the "Allowed" tab of the next rule, and so on. In the absence of a clear rule, access is allowed if (i) installer privileges are in effect, or (ii) the program is "trusted" and HIPS mode is "Safe", or (iii) the option "Do not show alerts: Allow prompts" is checked. When none of these conditions are met, access is blocked if the option "Do not show alerts: Block requests" is checked, or an alert is issued if this option is disabled.
Special case: if the program is running in a virtual environment and/or with Auto-Containment restrictions, then in the absence of a rule it will be given permission (similar to the "Do not show alerts: Allow prompts" option). In addition, there is no file and registry protection at all in a virtual environment, even with explicit prohibitions.
Managing application rights through notifications
When responding to HIPS alerts, rules are assigned to applications, either temporarily or permanently, depending on the "Remember my choice" option.
An important point: the rules are assigned to the application, which is indicated on the left side of the alert. For example, if you are asked about the launch of an unknown program by the explorer, then the rules will be assigned to the explorer. Typical rookie mistakes: select the “Block and terminate execution” option in such an alert (thus killing the Explorer process), or the “Isolated application” option (hardly limiting Explorer rights), or the “Install or update” option (thus losing almost all protection ). Usually the smartest choice in a program launch alert is "Allow" or "Block Only".
The "Allow" or "Block Only" options in the various HIPS alerts mean only allow or block a specific resource. For example, if you allow an application to create the file C:\test\A.exe , then an attempt to create the file C:\test\B.exe will result in an alert again. To allow the application to create any files in the C:\test directory, you will have to edit the rule through the CIS setup window. Unfortunately, alerts do not provide permissions for directories, templates, groups, and so on. However, through an alert, you can apply to the application any set of rules that you previously created on the tab HIPS → Rule sets.
If you enable the "Remember my choice" option when responding to a notification, the set of rules assigned to the specified application will change; if there is no HIPS rule for this application, it will be created at the top of the list. When choosing an option allow or Only block the permission or prohibition will be added to the rules exactly for a specific resource (file, COM interface, etc.). When choosing any set of rules new rules will not be added to the old ones, but will completely replace them, i.e. the rules previously assigned to this application will no longer apply.
If you disable the "Remember my choice" option in the notification, then the permissions, restrictions, or rule sets assigned to the application will expire when the application ends or even earlier, and no changes to the CIS configuration will occur. To understand the logic behind these temporary rules, it's convenient to imagine that each response to an alert (without remembering) creates an imaginary entry in the list of HIPS rules. All "imaginary" entries are located below the "real" entries in the list of rules, but new "imaginary" entries are above other "imaginary" ones. This means that you can assign different rule sets to the same application through notifications several times (without remembering), and all these rule sets will be in effect. In this case, the “real” rules will have the highest priority, then the most recent of the “imaginary” ones, then the earlier one, and so on. But as soon as any "real" rule (with memorization) is created, all "imaginary" rules for all applications will be destroyed.
For example, having received a notification about a program, we will assign the "Isolated Application" rule set to it, without remembering. By default, the All Applications group is allowed to modify temporary files, so this program will still be able to do this, despite the fact that the Isolated Application set does not allow it. If you assign this set of rules with remembering, changing temporary files will be prohibited, since a new HIPS rule will be created at the top of the list.
There are some exceptions to the described workflow when the "Remember my choice" option is disabled. Firstly, "imaginary" permissions to launch applications are not created (i.e. when the same application is launched again, an alert will occur again). Secondly, if any program is allowed through the “change the user interface of another application” notification, then it will temporarily be able to send window messages to any application, not just the specified one.
Application Launch Control
The ability to run a program is given in HIPS by a rule for launching program, not for the one being run. In Paranoid Mode, programs are silently allowed to run only if they are explicitly allowed in the rules. In "Safe Mode" in the absence of a rule, launch is allowed if both the launcher and the program being launched are trusted. Exceptions - execution of programs with installer privileges, as well as under the influence of virtualization and / or Auto-Containment restrictions.
So, let's say that in HIPS "Safe Mode" parent.exe is running and trying to run child.exe . In the absence of additional rules it will start silently only if both programs are trusted. If the child.exe program is unrecognized, and the HIPS rules for the parent.exe program (or the group containing it) do not have permission to run the child.exe program (or the group containing it), then regardless of the HIPS rules for the child.exe program itself and regardless of the rating of the parent.exe program, a notification will appear before the launch (moreover, regarding the parent.exe program).
Thus, in order to allow the execution of an unidentified program, it is not enough to set allowing rules for itself - permission is required for its launch to the parent process, as an option - to the All Applications group.
If you want to stop the program from running, then, having received a notification regarding the parent process, you should usually turn off the remember option and select Block → Only block. Attention! "Block and complete execution" item in the alert about starting the program means shutdown parent process.
The ability to run any program is determined not only by HIPS rules, but also by Auto-Containment. The launch will be blocked if at least one of these components requires it. If the launch of the program is allowed in the HIPS rules, and the Auto-Containment rules prescribe to isolate this program, it will be launched in isolation.
It is important to know that, unlike Auto-Containment, in HIPS, the child process does not inherit the parent's restrictions: if you allow a dubious program to run a safe program, then damage can be done on behalf of a safe program.
Automatic creation of HIPS rules in "Learn Mode" and "Safe Mode"
In certain modes, HIPS rules are created automatically:
- if the "Learning mode" is enabled and the "Do not show alerts" option is disabled or set to the "Block requests" mode, then rules will be created that allow every detected action of any applications;
- if "Safe Mode" is enabled, "Create rules for safe applications" is enabled, and the "Do not show alerts" option is disabled or set to "Block requests", then rules will be created that allow every detected action of trusted applications.
In most cases, these modes are not useful and are used only for testing or preparing for switching to "Paranoid Mode".
Rules for the program (either in "Learning Mode" or trusted in "Safe Mode") are created as follows:
The type of the new rule will depend on the requested action:
- When one program launches another, a rule is created for the former to allow that particular program to run.
- When a program changes a file or registry key that is listed on the tab HIPS → Protected objects, the type of rule will depend on how the template of this resource is written.
- If at the end of the template there is a sign | , then a rule will be created that allows changing the specific object that the program accessed. For example, the program creates a text.txt file on the desktop. Does it match the pattern?:\Users\*\Desktop\*| . This means that a rule will be created allowing modification of the C:\Users\Name\Desktop\text.txt file.
- If there is no sign at the end of the pattern | , then a rule will be created that allows changing any object according to this template. For example, the program creates the file D:\prog.exe . In the list of protected objects, this file matches the pattern *.exe . This means that a rule will be created that allows this program to change any .exe files.
- When an application accesses any of the following resources, rules are automatically created that allow it access to all of them at the same time:
- Secure COM Interfaces,
- Windows Hooks and Application Hooks,
- Interprocess memory access,
- Application interruption,
- DNS queries,
- Disk(direct access),
- Keyboard,
- Monitor.
Process Protection
In the window with HIPS rules for an application, you can limit not only the own activity of this application, but also the impact of other programs on its operation. For this tab Security settings indicates which actions with this application will be blocked, and in the exceptions window (button Change) - what programs they will be allowed. Notifications are not provided here - only permission or prohibition, regardless of the rating. An action prohibited in this way will be blocked, regardless of the rules and ratings of other programs.
In particular, this function is used to protect the CIS from unloading its processes and accessing memory. Therefore, even when HIPS is not needed, it is advisable to enable it at least with the option "Do not show alerts: Allow requests" (in "Safe" or "Paranoid" mode).
A side effect of CIS self-protection is a huge number of entries in the "Defense Events+" log when using some programs, such as ProcessExplorer. You can get rid of unnecessary locks by allowing individual applications to access the memory of the COMODO Internet Security group.
I note that application interruption protection itself does not cover all ways to unload a process. For example, many applications can be terminated via window messages or via memory access. To protect an application from such termination methods, you will need to check in its rules on the "Protection settings" tab not only the "Interrupting applications", but also others.
Installer Privileges
The meaning of installer privileges
Under certain conditions, the application receives installer privileges, which are as follows:
- HIPS allows such an application everything that is not explicitly forbidden to it in the rules, i.e. works like the "Do not show alerts: Allow requests" mode;
- Auto-Containment does not contain programs launched by this application;
- while this application is running, its child processes (as well as their child processes, etc.) run with installer privileges;
- executable files that this application creates (or child processes that inherit its privileges) are automatically trusted.
Files are automatically enrolled as trusted only if the option "Trust applications installed using trusted installers" is enabled on the tab . Also, in some special cases, installer privileges are given to applications in a "truncated" form: without , or when the user responds with permission to (if the program is unrecognized and has the installer attribute), or when the program is assigned the appropriate , or when this rule is applied to it, or when the program inherits these privileges from the parent process.
Automatic app granting of installer privileges
An application automatically receives installer privileges if it is trusted and has the installer flag. You can see if an application has an installer flag in the list of active processes.
It was said in what properties of the application the sign of the installer is contained: judging by experiments, installers are programs that have the word install , setup or update in the file name or in the File Version Info (in the FileDescription , ProductName , InternalName or OriginalFilename field); msi files are also considered installers.
In older versions of CIS, the features of the installer were different, in particular, programs that requested administrator rights at startup, programs whose size exceeds 40 MB, etc. were considered installers. Because of this, many application programs were erroneously granted installer privileges (in particular, PortableApps- assembly), which created an obvious danger. In CIS 10, this threat is significantly lower.
Assigning Installer Privileges via Auto-Containment Alerts
In the default configuration of Proactive Security, when an unrecognized program that has an installer flag is launched, an alert appears offering a choice of four options: "Block", "Isolated startup", "Run without restrictions" when the option "Trust this application" is disabled, and "Start no restrictions" with the "Trust this app" option enabled.
The "Block" option means that the launch is prohibited. The "isolated launch" option means that the program will be launched in isolation according to the Auto-Containment rules.
If you enable the "Trust this application" option and select the "Run without restrictions" option, the program will become trusted and will start with installer privileges. At the same time, an Auto-Containment rule will be created, excluding the child processes of this program from isolation. Usually this rule does not make sense, and I recommend removing it.
If you select the “Run without restrictions” option with the “Trust this application” option disabled, the program will temporarily start with “truncated” installer privileges, without trusting the files being created. Those. items , and will be executed, but not .
Generally speaking, such an alert occurs if the following conditions are met:
- the Auto-Containment component is enabled,
- tab Containment → Setting Containment the "Detect programs that require elevated privileges" option is enabled,
- the option "Do not show notifications when prompted for elevated privileges" is also disabled there,
- the program to be launched must, according to the rules of Auto-Containment, run virtually and/or with restrictions,
- the program being launched has the sign of an installer or asks for administrator rights when it starts.
As you can see, the program being launched does not have to be unrecognized in order to display an alert - it is only required that the Auto-Containment rules require it to be quarantined. In addition, the program may ask for administrator rights at startup, but not be an installer.
If you enable the "Do not show alerts when prompted for elevated privileges" option, then in the menu of this option you can choose to automatically isolate (recommended) or block unrecognized installers without alerts. There are also options "Run without restrictions" and "Run without restrictions and trust" - of course, choosing them is very dangerous.
Assign installer privileges via alerts and HIPS rules
Installer privileges can be explicitly assigned to a program through HIPS: they correspond to the "Install or update" rule.
When a HIPS alert occurs regarding the activity of an application, you can select in the alert box Process as → Install or update, with or without memory.
If you check the remember option and select Install or Update, the corresponding HIPS rule will be created and the application will have installer privileges. If you select this option without the remember option, then the rule will not be created, and the application will receive a "truncated" version of the installer's privileges, without trusting the generated files (temporary launch of an unidentified installer without Auto-Containment restrictions).
Through the CIS setup window, you can pre-assign an Install or Update HIPS rule to an application. Obviously, in this case, the application will receive installer privileges without notifications and in full.
Trust files created with installer privileges
As already mentioned, executable files created by trusted installers are automatically trusted if the option "Trust applications installed using trusted installers" on the tab File rating → File rating settings. It was also said that information about the creation of files by trusted installers is entered into the database, even if this option is disabled.
Judging by experiments, when the DPUPDU option is disabled, information about the creation of files by directly trusted installers, and not by any programs that have installer privileges, is entered into the CIS database. Those. if a file is created by a child process of a trusted installer or by a program that has obtained installer privileges based on HIPS rules, then the file is not considered to be created by a trusted installer. But if the DPUPDU option is enabled, then files created by any programs that have somehow received installer privileges are marked in the database as created by trusted installers.
In determining whether a file was created under installer privileges, CIS distinguishes between creating and copying a file. So, if a program that has installer privileges performs a normal copy of a file, then the file will not yet become trusted. But if, under the influence of the installer's privileges, for example, a file is extracted from an archive, CIS will trust this file and everything identical to it (with the DPUPDU option enabled).
To some extent, installer privileges work in a virtual environment: if a trusted installer runs virtually, but creates files in a real environment (in a shared area), then these files are marked in the database as created by a trusted installer. A similar situation occurs when working in a real environment with Auto-Containment restrictions. In my opinion, this is a flaw, and potentially dangerous.
Although the DPMD option improves the usability of CIS, there is some merit in disabling it. In particular, when this option is enabled, CIS can trust potentially unwanted programs that are installed along with safe applications.
It happens that the installer of an application, even if it is trusted, creates and launches unidentified programs in the process of work. Usually CIS does not interfere with their work, because they inherit the privileges of the installer. However, as mentioned above, inherited privileges are not always in effect (which is justified for security reasons), and sometimes proactive protection may work during the installation process. If this only shows up as a HIPS alert, then responding to it is enough to continue with the installation. But if HIPS is configured to block silently, or if Auto-Containment is used, then there is a risk that the application will not install correctly. This risk is especially high if the option "Trust applications installed using trusted installers" or "Detect programs that require elevated privileges" is disabled.
In order for the installation of applications to proceed without interference from the CIS, I suggest launching the installers through a special context menu item. For this, a simple program will be used that runs the file specified in its command line arguments. You will need to download the archive with the program (password cis), place the program in any convenient place, add it to the trusted ones and run it - you will be prompted to add a new item to the explorer context menu (it is deleted by restarting). The program is written in AutoIt3, source code and converter are attached in the source folder: in case of doubt, you can generate a similar program by checking its code and converter signature.
You will then need to assign the Install and Update HIPS rule, as well as the Auto-Containment rule, to this program:
- select the "Ignore" action,
- specify the location of the program in the criteria,
- leave the "Do not apply the selected action to child processes" option disabled.
Now, in order for the installation of any safe application to go smoothly, it will be enough to call on the installer, while holding down the Shift key, the context menu and select the "COMODO: run as installer" item. As a result, even when the installer itself exits, its child processes will continue to run with installer privileges. These privileges will be removed after closing a special window with the text "Press Ok when installation is complete." But even then, these processes will remain excluded from Auto-Containment control.
Changes to HIPS settings should only be made by advanced users. Incorrect settings of these parameters can lead to system instability.
Host Intrusion Prevention System (HIPS) protects against malware and other unwanted activity that tries to compromise your computer's security. Host Intrusion Prevention uses advanced behavioral analysis combined with detection-based network filtering capabilities to monitor running processes, files, and registry keys. Host Intrusion Prevention is different from real-time file system protection and is not a firewall; it only keeps track of the processes running on the operating system.
HIPS options are available under Additional settings(F5) > Antivirus > Host Intrusion Prevention System > Basic information. HIPS status (enabled/disabled) is displayed in the main window of ESET NOD32 Antivirus, under Install > Computer protection.
uses built-in self-protection technology that prevents malware from damaging or disabling virus and spyware protection. Thanks to this, the user is always confident in the security of the computer. To disable HIPS or Self-Defense, you must restart Windows.
Advanced Memory Scan Engine Works in conjunction with Exploit Blocker to provide enhanced protection against malware that can avoid detection by antimalware products through the use of obfuscation or encryption. Advanced Memory Scanner is enabled by default. See the glossary for more information about this type of protection.
Exploit Blocker designed to protect applications that are typically vulnerable to exploits, such as browsers, PDF readers, email clients, and MS Office components. The exploit blocker is enabled by default. See the glossary for more information about this type of protection.
Four filtering modes are available.
Auto mode: All operations are enabled except those blocked by predefined rules designed to protect your computer.
Intelligent Mode: The user will only be notified about very suspicious events.
interactive mode: The user will be prompted to confirm operations.
Policy Based Mode: Operations are blocked.
Learning Mode: Operations are enabled, with a rule being created after each operation. Rules created in this mode can be viewed in the rules editor, but their priority is lower than rules created manually or automatically. If learning mode is selected from the drop-down list of HIPS filtering modes, the option becomes available. Training mode will end. Select the duration for the training mode. The maximum duration is 14 days. When the specified period ends, you will be prompted to modify the rules generated by the HIPS system in learning mode. You can also choose a different filtering mode or postpone the decision and continue using the learning mode.
The host intrusion prevention system monitors events in the operating system and reacts accordingly based on rules that are similar to the rules of a personal firewall. Click the Edit button to open the HIPS rules management window. Here you can select, create, modify and delete rules.
The following example will show how to restrict unwanted application behavior.
The HIPS system, using its own driver, intercepts all software calls to the OS kernel. In the event of an attempt to execute potentially dangerous action on the software side, the HIPS system blocks the execution of this action and issues a prompt to the user, who decides to allow or deny the execution of this action.
The basis of any HIPS is a table of rules. In some products, it is not divided in any way, in others it is divided into intermediate tables in accordance with the nature of the rules (for example, rules for files, rules for networks, rules for system privileges, and so on), in others, the table is divided by applications and their groups . These systems monitor certain system events (for example, such as creating or deleting files, accessing the registry, accessing memory, starting other processes), and each time these events should occur, HIPS checks its rule table, and then acts in accordance with the settings specified in the table. The action is either allowed or denied, or HIPS asks the user what it should do in this particular case.
The feature of HIPS is group policy, which allows you to apply the same permissions to all applications in a particular group. As a rule, applications are divided into trusted and untrusted, and intermediate groups are also possible (for example, weakly restricted and strongly restricted). Trusted applications are not restricted in any way in their rights and capabilities, weakly restricted applications are prohibited from the most dangerous actions for the system, highly restricted applications are allowed only those actions that cannot cause significant damage, and untrusted ones cannot perform practically any system actions.
HIPS rules have three basic components: subject (i.e., the application or group that raises a particular event), action (allow, deny, or prompt the user), and object (what the application or group is trying to access). Depending on the object type, the rules are divided into three groups:
- files and system registry (object - files, registry keys);
- system rights (object - system rights to perform certain actions);
- networks (object - addresses and their groups, ports and directions).
Types of HIPS
- HIPS where the decision is made by the user- When an Application Programming Interface (API) function interceptor intercepts any application function, a question about the next action is displayed. The user must decide whether to run the application or not, with what privileges or restrictions to run it.
- HIPS where the decision is made by the system- the decision is made by the analyzer, for this the developer creates a database in which the rules and decision-making algorithms are entered.
- "Mixed" HIPS system- the decision is made by the analyzer, but when it cannot make a decision or the "user decision making" settings are enabled, the decision and choice of further actions are provided to the user.
Benefits of HIPS
- Low consumption of system resources.
- Not demanding on computer hardware.
- They can work on various platforms.
- High efficiency in countering new threats.
- High efficiency of counteracting rootkits operating at the application level (user-mode).
Disadvantages of HIPS
- Low efficiency of counteracting rootkits operating at the kernel level.
- A large number of calls to the user.
- The user must have knowledge of the principles of operation
How HIPS (Host-based Intrusion Prevention System) works: detailed description. General HIPS and Auto-Sandbox settings in Comodo Internet Security 8. Viruscope
HIPS
HIPS Modes
When the HIPS component is enabled, application activity is restricted according to the rules. The rules that are present initially set permissions for some system programs, and in other cases require you to ask the user. The user can add his own rules through the HIPS Rules tab interface, or they will be created through his responses to alerts, or they will be created automatically when the "Learning Mode" is enabled. You can turn off alerts by specifying to always allow or always deny activity in the absence of a rule.
The display of program alerts depends on the program and the HIPS mode. In "Safe Mode" notifications will be issued only regarding unidentified programs, while trusted ones will be silently given permission (in the absence of a prohibiting rule) for any action, except for launching any unidentified application. In Paranoid Mode, alerts will appear for all programs, regardless of reputation.
In the "Clean PC" mode, alerts appear only for new unrecognized programs, i.e. which were not previously on the disk, and the "old" ones are perceived as trusted in "Safe Mode". The "Clean PC" mode works as follows: from the moment this mode is enabled, the creation of new programs is monitored, i.e. executable files. If a new program less than 40 MB and does not have the reputation of "trusted", then it is entered in as "unidentified". Only programs from the list of "unidentified" will be limited in rights. The rest of the programs, smaller than 40 MB, will be perceived similarly to trusted ones: HIPS, Auto-Sandbox, and the firewall will perceive them as such.
The Clean PC mode is very problematic and I do not recommend using it. In particular, if in this mode a new unknown program is placed in some directory and its name is changed, then the program will be considered "old", i.e. will receive permission. Nevertheless, you can implement a correctly working analogue of the "Clean PC" mode in "Safe Mode" by adding all executable files to the trusted ones in the way suggested in .
How "Safe Mode" works with the option "Create rules for safe applications" enabled, as well as "Learning mode". Working in Clean PC mode is similar to Safe, but differs in that unidentified files that were on the disk before this mode was enabled will be processed similarly to trusted ones (“trusted” not only by HIPS, but also by Auto-Sandbox, and a firewall). ).
I will make a special case: if the program is running in a virtual environment and/or with Auto-Sandbox restrictions, then in the absence of an allow or deny rule, permission will be given (similar to the option "Do not show alerts: Allow requests"). In a virtual environment, there will be no file and registry protection at all, even with explicit prohibitions. But, of course, the virtual environment and/or Auto-Sandbox will overlay this program and its child processes.
Managing application rights through notifications
If you select "Allow" or "Block Only" in the HIPS alert, then this permission or denial will only apply to a specific resource. For example, if you allow an application to create the file C:\test\A.exe , then an attempt to create the file C:\test\B.exe will result in an alert again. To allow the application to create any files in the C:\test directory, you will have to edit the rule through the CIS setup window. Unfortunately, alerts do not provide permissions for directories, templates, groups, and so on.
One exception has been noted: if a program is allowed through an alert "changing the user interface of another application", then a rule will be created that allows that program to send window messages to any application, not just the specified one.
However, through an alert, you can apply a pre-created policy to an application. These policies are created in the HIPS > Rule Sets tab. The preset policy "Windows system application" allows any activity, the policy "Allowed application" - any, but does not regulate the launch of child processes; the "Isolated application" policy strictly prohibits any activity; the "Restricted application" policy denies almost everything except window messages and the monitor, and does not regulate the launch of child processes. You can not only create your own policies, but also change the preset ones.
Permissions, denials, and policies assigned to an app through alerts work differently depending on whether the "Remember my choice" option is enabled in the alert. If you enable this option and select the "Allow" or "Only block" option, the set of rules assigned to this application will change: it will be added to allow or deny exactly for a specific resource (file, interface, etc.). If you turn on the "Remember my choice" option and select any set of rules- new rules will not be added to the old ones, but will completely replace them; those. the rules previously assigned to this application will no longer apply. If there is no HIPS rule for this application, it will be created at the top of the list.
If you disable the "Remember my choice" option in the notification, then the permissions, restrictions, or policies assigned to the application will expire when the application ends or even earlier, and no changes to the rules will occur. To understand the logic behind these temporary rules, it's convenient to imagine that each response to an alert (without remembering) creates a "phantom" entry in the list of HIPS rules. All "phantom" entries are located in the list of rules below the "real" entries, but the new "phantom" ones are above the other "phantom" ones. This means that you can assign different policies to the same application multiple times through notifications (without remembering), and all these policies will be in effect. In this case, the “real” rules will have the highest priority, then the most recent of the “phantom” ones, then the earlier one, and so on. But as soon as any "real" rule (with memorization) is created, all "phantom" rules for all applications will be destroyed.
For example, let's assign the "Isolated application" policy to any program, without remembering. By default, the All Applications group is allowed to modify temporary files, so this program will still be able to do so even though the Sandboxed Application policy does not allow it. If you assign this policy with remembering, changing temporary files will be prohibited, since a new HIPS rule will be created at the top of the list.
Application Launch Control
The ability to run a program is given in HIPS by a rule for launching program, not for the one being run. In "Paranoid mode", running programs is silently allowed only if there is an explicit permission in the rules (for). In "Safe Mode" in the absence of a rule, the launch is allowed if both the launcher and the program being launched have a "trusted" reputation.
So, let's say that in HIPS "Safe Mode" parent.exe is running and trying to run child.exe . In the absence of additional rules, the launch will occur silently only if both programs are trusted. If the child.exe program is unrecognized, and the HIPS rules for the parent.exe program (or the group containing it) do not have permission to run the child.exe program (or the group containing it), then regardless of the HIPS rules for the child.exe program itself and regardless of the rating of the parent.exe program, a notification will appear before the launch (moreover, regarding the parent.exe program).
Thus, in order to allow the execution of an unidentified program, it is not enough to set allowing rules for itself - permission is required for its launch to the parent process, as an option - to the All Applications group.
If you want to stop the program from running, then, having received a notification regarding the parent process, you should disable the remember option and select "Block" > "Block only".
Attention! "Block and complete execution" item in the alert about starting the program means shutdown parent process. Also, selecting a policy (i.e., a set of rules) in this notification will assign it to the parent process. Accordingly, enabling the "Remember my choice" option in such a notification will result in the creation/modification of a HIPS rule for the parent process. A typical mistake of users is choosing a policy in the notification about the launch of the program by Explorer. The correct course of action is to first only allow the launch, and select the policy in the subsequent notification of the program's own activity.
It is important to know that, unlike Auto-Sandbox, in HIPS, the child process does not inherit the parent's restrictions: if you allow a dubious program to run a program that has permissions, then security will be compromised.
The ability to run any program is determined by the rules not only HIPS, but also. The launch will be blocked if at least one of these components requires it. If the launch is allowed in the HIPS rules, and the Auto-Sandbox rules prescribe to isolate this program, it will be launched in isolation.
The described procedure has certain exceptions. The first exception concerns programs that are already sandboxed in the Sandbox. The child processes of these programs will be sandboxed in the same way, not subject to other Auto-Sandbox rules. There will be no HIPS notification about their launch: only if there is an explicit HIPS deny rule, blocking will occur. In other words, the operation of HIPS for such programs is similar to enabling the option "Do not show alerts: Allow prompts".
Another exception is programs that have installer privileges. Their child processes do not obey Auto-Sandbox rules (this behavior) and do not raise HIPS alerts. They are subject only to explicit prohibitions in the HIPS rules, like the option "Do not show alerts: Allow prompts" is enabled (this behavior cannot be configured).
The third exception is programs that have an "Ignore" action in Auto-Sandbox with the " " option disabled. Such programs are simply excluded from the control of Auto-Sandbox along with their child processes. HIPS rules apply to them in the normal way.
Automatic creation of HIPS rules in "Learn Mode" and "Safe Mode"
In certain modes, HIPS rules are created automatically:
- if the "Learning Mode" is enabled and the "Do not show alerts" option is disabled or set to the "Block requests" mode, then the activity of all applications will be monitored and rules will be created that allow each of their noticed actions;
- if "Safe Mode" is enabled, "Create rules for safe applications" is enabled, and the "Do not show alerts" option is disabled or set to "Block requests", then rules will be created that allow every detected action of trusted applications.
In most cases, these modes are not useful and are only used for testing or preparing for switching to "Paranoid Mode".
Rules for the program (either in "Learning Mode" or trusted in "Safe Mode") are created as follows:
The type of the new rule will depend on the requested action:
- When one program launches another, a rule is created for the former to allow that particular program to run.
- When a program modifies a file or registry key that is listed on the HIPS > Protected Objects tab, the appearance of the rule will depend on how the resource template is written.
- If at the end of the template there is a sign | , then a rule will be created that allows changing the specific object that the program accessed. For example, the program creates a text.txt file on the desktop. It matches the pattern " ?:\Users\*\Desktop\*| ". This means that a rule will be created allowing modification of the C:\Users\Name\Desktop\text.txt file.
- If there is no sign at the end of the pattern | , then a rule will be created that allows changing any object according to this template. For example, the program creates the file D:\prog.exe . In the list of protected objects, this file matches the pattern *.exe . This means that a rule will be created that allows this program to change any .exe files.
- When an application accesses any of the following resources, rules are automatically created that allow it access to all of them at the same time:
- "Protected COM Interfaces",
- "Windows Hooks and Application Hooks"
- "Inter-Process Memory Access",
- "Interruption of applications",
- "DNS Queries"
- "Disk" (direct access),
- "Keyboard",
- "Monitor".
Usually the real order of operation of HIPS is the same as described, but there are various deviations. For example, sometimes HIPS rules are created automatically even for programs that run with installer privileges; this was observed when disabling Auto-Sandbox. There was also a situation when the rules for the program, created in the "Learning Mode", fixed access to not all file objects requested by it in the "Paranoid Mode".
Identify applications by their paths
In explicitly defined rules, only the path to the program is taken into account. Its integrity, or rather, the rating is checked only if there are no rules in the "Safe Mode". Instead of an unambiguous path, you can use templates and environment variables similarly, as well as the filegroups themselves.
Previously, it was sometimes observed that after renaming or moving HIPS programs perceived her as being in the same place. This was expressed in the fact that for this program the rules where it was written according to the old path were valid, and the rules with the new path were not valid. The problem was solved by rebooting.
Because HIPS rules are path-based, the "Generate rules for secure applications" option is dangerous. For example, if it is enabled and Explorer runs the trusted (signed) program C:\myDownloads\test.exe , HIPS "Safe Mode" will automatically create rules; and another time, test.exe will be replaced by something else. Therefore, I recommend disabling this option.
Process Protection
In the window with HIPS rules for an application, you can limit not only the own activity of this application, but also the impact of other programs on its operation. To do this, on the "Protection settings" tab, select which actions with this application will be blocked, and in the exceptions window (the "Change" button) - which programs they will be allowed to do. Notifications are not provided here - only permission or ban, regardless of the rating. An action prohibited in this way will be blocked, regardless of the rules and ratings of other programs.
In particular, this function is used to protect the CIS from unloading its processes and accessing memory. Therefore, even when HIPS is not needed, it is advisable to enable it at least with the option "Do not show alerts: Allow requests" (in "Safe" or "Paranoid" mode).
A side effect of CIS self-protection is a huge number of entries in the "Defense Events+" log when using some programs, such as ProcessExplorer. You can get rid of unnecessary locks by allowing individual applications to access CIS memory.
I note that application interruption protection itself does not cover all ways to unload a process. For example, many applications (but not CIS processes) can be terminated through window messages (such as the System Explorer program) or through memory access. To protect an application from such methods of termination, you will need to check in its rules on the "Protection settings" tab not only the item "Aborting applications", but also the items "Window messages" and "Inter-process memory access".
The method of interrupting processes used by Process Hacker allows you to unload even CIS. To disable this method, you can change the HIPS rule for the All Applications group: in the Secure COM Interfaces section, click Edit and add the line LocalSecurityAuthority.Restore to the Blocked tab. However, it is not recommended to make this ban, as it will create problems when updating Windows.
Installer Privileges
The meaning of installer privileges
Under certain conditions, the application receives installer privileges, which are as follows:
- HIPS allows such an application everything that is not explicitly forbidden to it in the rules, i.e. works like the "Do not show alerts: Allow requests" mode;
- Auto-Sandbox does not sandbox programs launched by this application;
- while this application is running, its child processes (as well as their child processes, etc.) are executed with installer privileges;
- executable files that this application creates (or child processes that inherit its privileges) will automatically be added to the list of trusted ones (except for scripts and files larger than 40 MB).
Files are automatically trusted only if the option "Trust applications installed using trusted installers" is enabled on the "File rating" > "File rating settings" tab. Also, in some special cases, installer privileges are given to applications in a "truncated" form: without , despite the inclusion of this option.
Finally, pay attention to: when the installer application terminates, its child processes will lose their inherited privileges, and HIPS will control them normally. And their further child processes will fall under the control of Auto-Sandbox.
Suppose installer "A" starts process "B" and "B" starts process "C". This usually results in process C gaining installer privileges and holding them for as long as program A is running, even after process B terminates. But after the program "A" ends, the process "C" will lose these privileges.
Compared to installer privileges, inheritance is more “safe”: it continues to affect child processes even after all parent processes have terminated. (However, a bug has been noticed: the inheritance of this rule breaks if there is no response to the HIPS alert for 2 minutes before starting the child process.)
A program acquires installer privileges in different ways: either when , or when (if the program is unrecognized and has the trait of an installer), or when , or when , or when the program inherits these privileges from the parent process. The program can only be given installer privileges when run in a real environment without Auto-Sandbox restrictions. If the program is launched in isolation, it does not receive these privileges, despite any signs and rules.
Automatic app granting of installer privileges
An application automatically receives installer privileges if it is trusted and has a . This status is assigned to applications that request administrator privileges at startup, and some others.
In previous versions of CIS, automatic granting of installer privileges to a program occurred only when the proactive defense restrictions depended on the program's rating. If the program was excluded from Auto-Sandbox and assigned a fully defined HIPS policy (like "System Application"), then it was not granted installer privileges. In CIS 8, installer privileges are granted even if HIPS and Auto-Sandbox are disabled. The only observed situation when a program with the status of a trusted installer is if its restrictions in HIPS do not depend on the rating, and Auto-Sandbox rules exclude it from isolation parental process along with its children.
Assign installer privileges via alerts and HIPS rules
Installer privileges can be explicitly assigned to a program through HIPS: they correspond to the "Install or update" policy.
When a HIPS alert occurs regarding the activity of an application, you can select the desired policy in the alert window, with or without remembering.
If you check the remember option and select the "Install or update" policy, the corresponding HIPS rule will be created and the application will have installer privileges. If you select this policy without the remember option, then the rule will not be created, and the application will receive a "truncated" version of the installer's privileges: without automatically adding the created files to the trusted ones (temporary launch of an "unidentified installer" without Auto-Sandbox restrictions).
Through the CIS configuration window, you can pre-assign an Install or Update policy to an application in the list of HIPS rules. Obviously, in this case, the application will receive installer privileges without notifications and in full.
General functions and parameters of proactive defense
Let's consider the options that affect the operation of proactive defense in general: both HIPS and Auto-Sandbox.
Various proactive defense options
The "Enable enhanced protection mode" option on the "HIPS settings" tab is designed to prevent bypassing proactive protection in 64-bit Windows versions, so it must be noted in such systems. But at the same time, it includes support for hardware virtualization, which threatens to conflict with virtual machines.
The option “Adapt the operating mode for low system resources” is needed only if there is a lack of random access memory. When enabled, CIS uses memory-saving tricks to avoid crashing while performing its tasks. However, this reduces performance.
The "Block unknown requests if the application is not running" option is intended only for infected systems and is not recommended for permanent use, as it prevents safe applications from starting correctly. If this option is enabled, then until the CIS GUI is loaded, all programs, regardless of their rating, will be blocked from any activity except those explicitly allowed in the HIPS rules. In other words, until the GUI is loaded, the behavior of HIPS will be similar to "Paranoid Mode" with the option "Do not show alerts: Block requests". There will be no blocking if HIPS is disabled or enabled with the "Do not show alerts: Allow prompts" option.
Also, the “Trust applications installed using trusted installers” option on the “File rating settings” tab, about it, can be attributed to the general parameters of proactive protection.
Another option that affects the operation of proactive protection, although it is located in a different section, is "Maximum file size" on the "Anti-virus monitoring" tab. If the file is not signed by a trusted provider, and its size exceeds the specified one, then this file will be treated as unrecognized, even if you manually add it to the list of trusted ones. The default size is 40 MB, it can be increased but not reduced. If the file is signed by a trusted vendor, this restriction does not apply.
The options you set under HIPS > Protected Objects are relevant not only for HIPS, but also for Auto-Sandbox. So, if the application is running, then exactly those files and registry keys that are indicated on the corresponding tabs of this section will be protected. For applications running in a virtual environment, the settings in this section also matter: the contents of the directories listed on the "Folders with protected data" tab will be hidden.
Objects included in the list "HIPS" > "Protected objects" > "Locked files" are denied any access, including both writing and reading. This list contains paths and file path patterns. Blocking only works when HIPS is enabled.
I will specify a special case: the "Clean PC" mode. Formally, this mode refers to HIPS, but in reality it determines the operation of all proactive defense. If you enable this mode, then only files that appear on the disk later will be considered "unidentified". Files that were present on the disk before this mode was enabled will receive trusted rights: both HIPS, Auto-Sandbox, and the firewall will treat these "old" files as if they were included in the trusted list. that Clean PC mode has certain problems and is not recommended for use.
File Protection Features
As already mentioned, only those files that are listed in the "HIPS" > "Protected Items" > "Protected Files" list are subject to protection through HIPS or Auto-Sandbox (in the absence of virtualization). You can use wildcards (* and ?) and environment variables (%temp% , %windir% , etc.) to specify these files, just like .
I will note the peculiarity of using templates when protecting directories. Usually, if you specify any directory through the CIS interface, it will be written as a template: D:\Docs\* . This kind of pattern corresponds to files and folders located in the selected directory D:\Docs , as well as in its subdirectories. Adding this template to the list of protected files means that the files and folders corresponding to it are protected from being modified and changed. However, the selected Docs directory itself is not protected from renaming. If you rename it, then its contents will no longer be protected. To protect a directory from being renamed, write it without the slash and the asterisk at the end: D:\Docs . Thus, to fully protect the directory and its contents, two lines should be added to the list of protected ones: D:\Docs\* and D:\Docs . (A variant with one line is possible - leave an asterisk at the end, but without a slash: D:\Docs* . But such a pattern will simultaneously protect the directories D:\Docs , D:\Docs2 , etc.)
In the HIPS > Protected Objects > Protected Files list, many templates end with a | . The use of this mark affects and limits the limits imposed by Auto-Sandbox. If any program is run in Auto-Sandbox with restrictions without virtualization, then it will not be allowed to create, delete or modify files that are specified by patterns with the symbol | at the end. Files specified by patterns without | at the end, they will also be protected from changes, however, a program limited by Auto-Sandbox is allowed to create such files, as well as delete (but not modify) those created by it. For example, by default, a program running with the Partially Restricted restriction level is allowed to create executable files in the %PROGRAMFILES% directory, but not in the startup directory. I emphasize that the symbol | it affects the limits of Auto-Sandbox in non-virtualization modes. When protected by HIPS, the creation, deletion, and modification of files is prohibited, regardless of the presence of the symbol | in their templates.
There is a problem with specifying paths on removable devices. Formally, you can create a HIPS, Auto-Sandbox, or other component rule using a removable device path like H:\Docs\* , but this rule will not work: CIS does not accept removable drive letters. However, rules that are not tied to a drive letter will work on removable media, for example, protecting exe files. On the other hand, it is still possible to create Auto-Sandbox rules that will be executed specifically for programs located on removable media. An example of such a rule is given.
As in the case of removable devices, CIS does not work correctly with network drive letters: data on a network drive Y: may not match either the pattern Y:\* or even ?:\* . Instead of templates with a network drive letter, you can use templates like \\network_share_name* - experiments have shown their correct operation. In particular, to protect data on Yandex.Disk, connected as a network drive via the WebDAV protocol, you can add the line \\webdav.yandex* to the Protected objects > Protected files list.
It should also be said that CIS perceives as "files" not only physical files, but also various system objects, for example, physical or virtual devices. On the one hand, this provides flexibility in customization. On the other hand, remember that . Therefore, such objects will not be protected from virtually running programs, even if there are strict prohibitions in the HIPS rules.
Registry protection features
As with files, the only registry keys that are protected by HIPS and Auto-Sandbox are those listed under HIPS > Protected Items > Registry Keys.
When setting registry keys, you can write registry path patterns using * and ? .
Consider, for example, the string *\Software\Microsoft\Windows\CurrentVersion\Run* . The * at the beginning of it means that it covers both the HKEY_LOCAL_MACHINE system registry key and each user's HKEY_CURRENT_USER key. Note that the * at the end of this line is not separated by a slash. This means that the line spans both subkeys: Run and RunOnce . The meaning of this particular line is to protect at the same time different types autoload: both general autoload and user autoload; both permanent and one-time.
The registry groups preinstalled in the CIS use the abbreviated names of the sections: HKLM , HKCU and HKUS . Also, when specifying registry paths through the CIS interface, these abbreviated names are automatically substituted. However, HIPS rules that abbreviate registry keys may not actually work. Therefore, you should always specify the full names of registry keys: for example, not HKCU\SOFTWARE\Policies\* , but HKEY_CURRENT_USER\SOFTWARE\Policies\* . You will also need to fix the paths in the preset groups on the HIPS Groups > Registry Groups tab:
- replace HKLM with HKEY_LOCAL_MACHINE
- replace HKCU with HKEY_CURRENT_USER
- replace HKUS with HKEY_USERS
According to my observations, CIS incorrectly perceives the abbreviations of the root registry keys in cases where the specified path is a link, and not a "real" location in the registry. Examples of such link paths are HKLM\SYSTEM\CurrentControlSet\* , HKCU\* .
Possible variant specifying the HKEY_CURRENT_USER section - pattern HKEY_USERS* . You can add part of the user ID to this template. For example, the string HKEY_USERS*1002\SOFTWARE\Policies\* specifies the SOFTWARE\Policies branch of the HKEY_CURRENT_USER key for one specific user. This technique can be used to prevent a restricted user from changing autoload, associations, and other settings.
For convenient and visual creation of rules, it is recommended to use registry groups:
- open the tab "HIPS" > "HIPS groups" > "Registry groups" and create a new group through the context menu;
- add registry keys to this group and, if necessary, edit the paths;
- open the tab "HIPS" > "Protected objects" > "Registry keys" and add a new group to the list;
- on the "HIPS Rules" tab, set the necessary permissions and prohibitions using groups.
Read protection
You can protect data not only from changes, but also, to some extent, from being read by certain applications. To do this, use the tab "HIPS" > "Protected objects" > "Folders with protected data". Directories added to the list on this tab are protected as follows:
- programs launched virtually perceive these directories as empty;
- programs running in a real environment with Auto-Sandbox restrictions are not allowed to browse the contents of these directories;
- programs blocked by HIPS on the Drive resource are prevented from browsing the contents of these directories (but still being able to open the files they contain).
I emphasize that it is when virtualization is used that protected folders will be perceived by isolated applications as empty, and their files as non-existent. If a program is restricted to HIPS only, then it will be able to open files by "knowing" their paths.
Through the CIS interface, you can add to the list of "Folders with protected data" only those directories that are visible in the explorer. If you need to protect data in a hidden directory, you should temporarily allow the display of hidden files and folders in Explorer (for example, through the "Control Panel").
The CIS interface allows you to list only unambiguous directory paths in the list of "Folders with protected data", but not patterns like *\ReadProtected\* . An attempt to add a template to this list by editing the configuration file can lead to a BSOD.
In the list of "Folders with protected data" you should add directories located only on local drives. Formally, you can add removable media or virtual encrypted disks to this list, but as a rule, protection does not work for them.
This protection can be completely bypassed by applications running as administrator. Such applications will be able to see the contents of the protected directory and read the data in it even if they are blocked from accessing the disk, even if they are running in a virtual environment, and even if they are sandboxed in Auto-Sandbox as "Partly Restricted" or "Suspicious". I strongly recommend keeping UAC enabled.
Process memory protection
CIS is able to prevent one process from modifying the memory of others. Thus, programs that run virtually and/or with Auto-Sandbox restrictions are not allowed to change the memory of processes running in the real environment. Additional limits on inter-process memory modification are specified in the HIPS rules.
CIS protects process memory from changes, but not from reading. Even if you block the "Inter-Process Memory Access" malware, and even if you run it virtually, it will be able to read sensitive data from the memory of processes running in a real environment. I note that this problem concerns not only the Comodo Sandbox virtual environment, but also Sandboxie.
At the same time, protection against inter-process memory modification prevents the creation of a memory dump. Apparently, it is the suspension of the process necessary to create a dump that is prohibited, but not the reading of memory itself.
Command Line Analysis
Some types of applications are not executed independently, but through interpreter programs. For example, bat scripts are executed by the cmd.exe system interpreter, vbs scripts are executed by the wscript.exe system interpreter, jar applications are executed by the javaw.exe program, which is part of virtual machine Java, etc. When a script (or similar application) is launched, the interpreter program associated with it is actually launched, given the path of this script in the command line arguments.
CIS monitors the launch of some interpreters and applies to them the restrictions that the file specified in the command line arguments has. Due to this, some types of scripts are perceived by CIS as independent applications: their activity is limited by HIPS rules or triggers alerts, and Auto-Sandbox isolates the work of scripts that are not trusted. (Some features of how Auto-Sandbox works with scripts are described in the corresponding article: impossibility or .) Also, scripts executed by them are displayed in place of interpreters.
Startup and activity are controlled in the manner described. various kinds applications: *.bat, *.cmd, *.js, *.vbs, *.wsf, *.hta, *.chm, *.msi, *.jar, etc. Library files are controlled similarly when they are executed by the system rundll32.exe program.
This behavior is controlled by the "Perform command-line heuristic analysis for specific applications" option on the "HIPS Configuration" tab, which is enabled by default. If it is disabled, then scripts and similar applications will be executed with the same rights that their interpreters have.
There was a bug in the CIS 7 version: the launch of scripts with long paths was not controlled. The bug has been fixed in CIS 8.0. Also, in all versions from 5.10 to 8.1, there was a serious command line parsing vulnerability that allowed one program to run with the rights of another. This vulnerability is nearly fixed in CIS 8.2.
Shell code injection protection option
On the "HIPS Configuration" tab, there is an option "Detect shell code injection". As the name suggests, enabling it is intended to prevent buffer overflow attacks.
However, the "Detect shell code injection" option still affects the operation of CIS. Or rather, the list of exceptions for this option has an effect, regardless of whether it is enabled itself. Applications added to the "shellcode protection" exclusion list exhibit the following features:
At the same time, HIPS controls applications that are excluded from “shellcode protection” for launching programs, accessing the memory of other processes, sending window messages, changing files and the registry, accessing the keyboard, and accessing the disk. Also, if these applications are run virtually (manually or based on Auto-Sandbox rules), file and registry changes should not affect the real environment.
Apparently, it is the implementation of the guard(32|64).dll library that is responsible for those CIS functions that do not work for applications excluded from "shellcode protection".
Sometimes excluding programs from the "Detect shell code injection" option eliminates some conflicts. So, it is usually recommended to add the VMware Player/Workstation program directory, the Alcohol program, the program and its sandbox directory to these exceptions. There was also a conflict between CIS 8.2.0.4674 and Google browser Chrome 45.0.2454.85, which was fixed by adding the chrome.exe file to the exceptions for this option.
Viruscope
Viruscope alerts
In addition to the main proactive protection tools - HIPS and Auto-Sandbox - there is a Viruscope component designed to dynamically detect suspicious process activity. It should detect dangerous behavior unidentified programs and issue an alert with a proposal to roll back the changes made by a certain program and its child processes, and delete the program itself.
If the "Do not show notifications" option is enabled on the "Virusscope" tab, then the removal of programs and the rollback of changes will occur automatically (similarly, if you do not respond to the notification within 2 minutes).
Reverting Changes Manually
Applications can be terminated and their changes rolled back, not only when suspicious activity is detected, but also manually. To do this, launch the KillSwitch task manager, call the context menu on the desired process and select the “End process tree and revert changes” item. The program file is not deleted. This item of the KillSwitch context menu is available only when Viruscope is enabled.
Another way to manually terminate programs and roll back their changes is through HIPS and firewall alerts. When Viruscope is enabled, an additional item appears in these notifications: "Lock, end execution and discard changes." When this item is selected, the program specified in the notification and all its child processes will end, and the changes made by them will be canceled; the program file will not be deleted.
Activity Report
When Viruscope is enabled, a new item appears in the context menu called from the main CIS window: "Show Activity". Clicking on it will open a window with a report on the activity of the selected program and its child processes.
Also, when Viruscope is enabled, the "Show activity" button appears in notifications of various CIS components. Clicking on it also opens a report on the activity of the program specified in the alert.
It should be said that reporting activity in the CIS window is far from convenient. However, you can export this report to an XML file via the context menu and study it separately.
Also, the activity report can be viewed through the KillSwitch task manager: in the process properties window, called through the context menu, there is a Process Activity tab. However, in KillSwitch this report is presented even worse than in CIS, and there is no export to file function.
Restricting Viruscope control to sandboxes only
By default, in the Proactive Security configuration, on the Virusscope tab, the option "Use Viruscope" is enabled and the option "Apply Viruscope action only to applications in Sandbox" is disabled. In this configuration, all processes in the real and virtual environments are monitored. The work of Viruscope is described above for this particular mode.
If you check the option "Apply Viruscope action only to applications in the Sandbox", then the activity of only those programs that are running in a virtual environment or limited by Auto-Sandbox will be monitored. For programs running in a real environment without Auto-Sandbox restrictions, the activity will not be recorded and therefore will not be reported on.
However, after this option is enabled, HIPS and firewall alerts will still contain the "Block, exit and discard changes" item, and the KillSwitch context menu will also have the "End process tree and revert changes" option. In fact, choosing these items will not roll back changes, but only terminate the selected program and its child processes.
Recognizer Management
The Virusscope tab lists a file based on which certain application activity is considered suspicious. This file defines the behaviors that should trigger Viruscope alerts. If the status of such a file is set to disabled, then the corresponding behavior of applications will not lead to alerts and Viruscope blocks; At the same time, monitoring of program activity will remain.
Limitations of use and problems of Viruscope
Viruscope cannot roll back actions such as deleting files from disk. Also, changes made during the previous cycles of the suspicious process cannot be rolled back. Rolling back the actions of a process mistakenly recognized as dangerous can lead to data loss (this risk occurs in the "Do not show alerts" mode).
There was a serious problem in CIS 7 version - when Viruscope was enabled, unpredictable crashes occurred in the operation of secure applications. These failures occurred in the absence of any notifications and entries in the CIS logs, making it difficult to find their cause. Apparently, the failures were provoked by the very observation of the processes, and not by the detection of suspicious behavior.
The previous known conflicts no longer appear in CIS 8. The problem may have been fixed. However, due to its seriousness and difficulty in detecting it, I still recommend deprecating Viruscope. With all the limitations, Viruscope's protection is not very useful.
To use Viruscope safely, you can enable it with the "Apply Viruscope action only to applications in Sandbox" option. But in this case, the purpose of Viruscope will not be protection, but the study of the operation of applications running in a virtual environment.
Please enable JavaScript to view theIn this comparative testing, we analyzed popular personal antiviruses and firewalls that have HIPS (Host Intrusion Prevention Systems) components in their composition for the ability to prevent malware from penetrating to the kernel level (hereinafter referred to as Ring 0) operating system Microsoft Windows. If the malware manages to penetrate the kernel level, then it gains full control over the victim's computer.
Summary:
Introduction
Behavioral analysis technologies and host-level intrusion prevention systems (HIPS) are gaining popularity among manufacturers of antiviruses, firewalls (firewalls) and other means of protecting against malicious code. Their main goal is to identify and block malicious activities in the system and prevent it from being infected.
Most difficult task protection in this case is reduced to preventing the penetration of a malicious program onthe level of the operating system kernel (eng. Kernel Level), operating in the "zero processor ring" (Ring 0). This level has maximum privileges when executing commands and accessing the computing resources of the system as a whole.
If the malware managed to penetrate the kernel level, then this will allow it to gain full and, in fact, unlimited control over the victim's computer, including the ability to disable protection and hide its presence in the system. A malicious program can intercept user input, send spam, carry out DDoS attacks, spoof the content of search queries, or do whatever it wants, despite formally working anti-virus protection. Therefore, for modern means protection, it becomes especially important to prevent malware from entering Ring 0.
In this test, we compared popular antiviruses and firewalls that have HIPS components in their composition on the ability to prevent malware from penetrating the kernel level (hereinafter referred to as Ring 0) of the Microsoft Windows XP SP3 operating system.
Selection of malware for testing
We decided not to simulate penetration into Ring 0 by any artificial means, but to test it on real malware. At the same time, the latter were selected in such a way as to cover all the used recording methods in Ring 0, which are actually used in “ wild nature» (In The Wild):
- StartServiceA- a malicious driver is loaded by replacing the system driver file in the %SystemRoot%\System32\Drivers directory with subsequent loading. Allows you to load the driver without modifying the registry.
ITW occurrence: high - SCM- use to register and load the service control manager driver. This method is used by both legitimate applications and malware.
ITW occurrence: high - KnownDlls- modification of the \KnownDlls section and a copy of one of the system libraries in order to load malicious code by the system process.
ITW occurrence: medium - RPC- creation of the driver and loading by means of RPC. Usage example: famous Rustock.C loader
ITW occurrence: rare - ZwLoadDriver- replacement of the system driver with a malicious one, by moving and subsequent direct download.
ITW occurrence: high - ZwSystemDebugControl- remove hooks set by HIPS to control system events in SDT using debug privileges.
ITW occurrence: high - \
device\
physical memory- remove hooks set by HIPS to control system events in SDT using a write to the physical memory section.
ITW occurrence: medium - ZwSetSystemInformation- loading the driver without creating keys in the registry by calling ZwSetSystemInformation with the SystemLoadAndCallImage parameter.
ITW occurrence: medium - CreateFileA\\.\PhysicalDriveX- sector-by-sector disk read/write (modification of files or disk master boot record).
ITW occurrence: average
Thus, nine different malicious programs were selected that use the methods described above to penetrate Ring 0, which were then used in testing.
Benchmarking Methodology
Testing was conducted under VMware Workstation 6.0. The following personal anti-virus protection tools and firewalls were selected for the test:
- PC Tools Firewall Plus 5.0.0.38
- Jetico Personal Firewall 2.0.2.8.2327
- Online Armor Personal Firewall Premium 3.0.0.190
- Kaspersky Internet Security 8.0.0.506
- Agnitum Outpost Security Suite 6.5.3 (2518.381.0686)
- Comodo Internet Security 3.8.65951.477
Unfortunately, for technical reasons, F-Secure and Norton antiviruses were excluded from the test. The HIPS built into them does not work separately from the included anti-virus monitor. And since the selected samples of malicious programs could be detected by signature, they could not be used. It was not suitable to use these antiviruses with old antivirus databases (in order to avoid signature-based detection). the update process in these products may affect not only anti-virus databases, but also executable modules (protection components).
Why did we take other popular antivirus products and firewalls into the test, of which there are many? Yes, because they do not have a HIPS module in their composition. Without this, they objectively have no chance to prevent penetration into the OS kernel.
All products were installed at maximum settings if they could be set without fine manual tweaking of HIPS settings. If during installation it was proposed to use the auto-learning mode, then it was used until the moment the malicious programs were launched.
Before testing, the legitimate utility cpu-z (a small program that reports information about the processor installed in the computer) was launched and a rule was created that suggested the tested product (its HIPS component). After creating a rule for this utility, the auto-learning mode was disabled and a snapshot of the system state was created.
Then, malware specially selected for the test was launched one by one, the reaction of HIPS to events directly related to the installation, registration, driver loading, and other attempts to write to Ring 0 was recorded. As in other tests, before checking the next malware, the system was returned to the one saved in the beginning of the picture.
In the antiviruses participating in the test, the file monitor was disabled, and in Kaspersky Internet Security 2009, a malicious application was manually placed into weak restrictions from the untrusted zone.
Testing steps:
- Create a snapshot of a clean virtual machine (primary).
- Installing the tested product with maximum settings.
- Work in the system (installation and launch Microsoft applications Office, Adobe Reader, Internet Explorer), enable learning mode (if available).
- Marking the number of messages from the product under test, running the legitimate cpu-z utility and creating rules for it.
- Disable auto-learning mode (if available).
- Transferring the product under test to the interactive mode and creating another snapshot of the virtual machine with the product installed (auxiliary).
- Create snapshots for all tested products by reverting to the main snapshot and redoing steps 2-4.
- Selecting a snapshot with the product under test, loading the OS and launching malware one by one each time with a rollback to its original state, monitoring the reaction of HIPS.
Benchmarking Results
A plus in the table means that there was a HIPS reaction to some event from the side of a malicious program for penetration into Ring 0 and it was possible to stop this action.
Minus- if the malicious code managed to get into Ring 0, or managed to open the disk for sector-by-sector reading and write.
Table 1: HIPS Component Benchmarking Results
Ring 0 Penetration Method | PC Tools | Jetico | Online Armor | Kaspersky | Agnitum | Comodo |
StartServiceA |
- |
+ | + | + | - |
+ |
SCM |
- |
+ | + | + | - |
+ |
KnownDlls |
- |
+ | + | - |
+ | + |
RPC |
- |
+ | + | + | - |
+ |
ZwLoadDriver |
+ |
- |
+ | + | - |
+ |
ZwSystemDebugControl |
- |
+ | + | + | + | + |
\Device\PhysicalMemory |
+ | + | + | + | + | + |
ZwSetSystemInformation |
- |
+ | + | + | + | + |
CreateFileA\\.\PhysicalDriveX |
- |
- |
+ |
+ | + | + |
Total suppressed: |
2 |
7 |
9 |
8 |
5 |
9 |
Number of alerts and user action requests |
Few |
Lots of | A lot of | Few | Medium |
A lot of |
It is worth noting that when the learning mode is completely disabled, some of the tested products (for example, Agnitum Outpost Security Suite 6.5) may show better results, but in this case, the user is guaranteed to encounter a large number of various alerts and actual difficulties in working in the system, which was reflected in the preparation of the methodology for this test.
As the results show, the best products for preventing malware penetration to the OS kernel level are Online Armor Personal Firewall Premium 3.0, Comodo Internet Security 3.8, Kaspersky Internet Security 2009.
It should be noted that Online Armor Personal Firewall Premium is an advanced firewall and does not contain classic anti-virus components, while the other two winners are complex solutions of the Internet Security class.
The reverse and negative side of the operation of all HIPS components is the number of all kinds of messages and requests for user actions that they display. Even the most patient of them will forego reliable HIPS if it bothers them too often with suspicious activity detections and demands for an immediate response.
The minimum number of user action requests was observed in Kaspersky Internet Security 2009, PC Tools Firewall Plus 5.0 and Agnitum Outpost Security Suite 6.5. The rest of the products were often annoying with alerts.
“Behavioral analysis is a more effective way to prevent infection by unknown malware than heuristic methods based on code analysis of executable files. But in turn, they require certain knowledge on the part of the user and his reaction to certain events in the system (creating a file in the system directory, creating an autoload key by an unknown application, modifying the memory of the system process, etc.),” comments Vasily Berdnikov, site expert.
“In this comparison, the most famous products that have HIPS on board have been selected. As you can see, only three products were able to adequately prevent penetration into the zero ring. Another very important parameter is the number of messages (alerts) that occur during daily work on a PC and require the user's decision. It is here that the technological advantage of the products is determined - to control the system as much as possible and at the same time use all kinds of technologies to reduce the number of questions asked by HIPS at startup, installation of programs, ”the expert notes.