Kernel API Virtualization by Comodo – Uncovered (1)

Kernel API Virtualization by Comodo

When it comes to securing your enterprise endpoints, it’s important to have a foundational understanding that there are three types of files: the good, the bad and the unknown. Approaches such as Antivirus (both vendor-branded “next gen” and legacy detection-based), Blacklisting and Whitelisting handle the known good and the bad files – but what about the unknown files?

Regardless of the “next gen” nature and effectiveness of any new pre-execution, detection- based solution, there will always be a certain number of unknown files, executables and code which by default are allowed to run on the host if not deemed malicious. The problem is that detection-based solutions will never detect 100% of what is malicious. Unknown files may be perfectly harmless and required for system functionality or they may be dangerous zero-day threats or APTs that cause mega breaches.

Comodo’s Solution: Kernel API Virtualization

As a key component of Comodo Dragon Platform, Kernel API Virtualization technology defeats zero-day attacks with no impact to the end user experience. Comodo’s solution uses a combination of Kernel API virtualization, whitelisting, machine learning, behavior analysis, and advanced static and dynamic threat cloud analysis (Comodo Valkyrie) to accurately and quickly deliver trusted verdict for unknown files and processes, that no other cyber security vendor provide today. Pre-execution, our technology authenticates every executable and process that requests runtime privileges.

if (!(known-good || known-bad) )
{
   launch_in(kernel_api_virtualization)
}

Containment (Kernel API Virtualization mode) does not allow access to system resources or user data directly. This provides protection against zero-day threats while having no impact on end-user experience or workflows. Whether the unknown files are malicious or safe, our technology is architected so that they run and perform in the auto- containment (Kernel API Virtualization mode) just as well as they would on the actual host system. However, they cannot damage or infect the systems because they cannot access the underlying operating system resources. This allows safe applications the freedom to run as needed while denying potentially malicious applications the system access they require to inflict damage and cause breach.

This is achieved by introducing virtualization layer between processes running unknown executable with Kernel functions. We have introduced 5 main virtualization components that filters any relevant Kernel calls or callbacks. File System, Registry, Kernel Object, Service and DCOM/RPC are main virtualization components that runs both user and kernel mode and handle necessary interrupts and implement all necessary filter drivers to fulfill the requests. This should not be conflated with Hooking API’s used in mainly malware analysis as Comodo’s technique goes beyond and virtualizes Kernel API’s.

File System Virtualization is a good example for this.  File System virtualization is an abstraction layer between File System and the client programs that access those files. It provides a logical view of the files. By using redirection techniques, some client programs access to the physical file is redirected to a virtual file, which prevents malicious programs modifying system files and isolates the operations to the files. These client programs doesn’t need to concern the details of file virtualization, it is completely transparent.

This type of virtualization can only be done on kernel level via file system filter drivers, where we can capture all relevant events, modify them or redirect them if necessary. The routines we have captured and virtualized are :

• File creation
• File read
• File write
• File change.

Lets take file creation event as an example and summarize what routines should be captured and their interactions.

PreCreateFile routine executes when any process want to access Kernel for file create operations, according to input parameters, there are two cases: create a new file or open an existing file.

Create File

The following figure shows the interaction on file creation virtualization.

Open Existing File

The following figure shows the interaction on file opening virtualization.

The following figure shows the main flow of the create file operation:

As shown in the figure, the PreCreateFile routine summarizes in the following list:

1. Check if the file path is in the exclusion list or not. If it is in the list, bypass. Otherwise go to step 2.
2. Check if the thread which creates or opens the file needs to be virtualized. If it needn’t to be virtualized, bypass. Otherwise go to step 3.
3. Retrieve the full path information for the accessed file, and parse the virtual file name.
4. Check the operation is to create a new file or opens an existing file. If it is to create a new file, go to step 5. Otherwise go to step 6.
5. Create a virtual file in the virtual file storage, and return the ShadowFileObject which points to the virtual file. Re-fill the UserFileObject fields with the ShadowFileObject fields.
6. Open an existing file, and return the ShadowFileObject which points to the real file. Re-fill the UserFileObject fields with the ShadowFileObject fields.

Virtual File System

Of course in order to support file system virtualization you need to maintain virtual file tree in memory to maintain the virtual files. We use this tree to cache virtual files and record states of virtual files, like deletion, renaming, etc. Following is the definition of the virtual file tree node:

typedef struct _SB_VIRTUAL_FILE_TREE_NODE
{
UNICODE_STRING				Name;
ULONG						Flags;
		SB_VIRTUAL_FILE_TREE_NODE *	Parent;
		SB_VIRTUAL_FILE_TREE_NODE *	Child;
		PRTL_SPLAY_LINKS		Brothers;
		……
} SB_VIRTUAL_FILE_TREE_NODE, *PSB_VIRTUAL_FILE_TREE_NODE;

SB_VIRTUAL_FILE_TREE_NODE structure describes the directory (file) structure of virtual files. Following figure shows the virtual files on the virtual file tree (“\HarddiskVolume1\Dir1\File.txt” and “\HarddiskVolume1\Dir2”).

The virtual file tree node is created when a unknown process creates or opens a file in PreCreateFile routine. If it creates a new file, the file virtualization component redirects the operation into the virtual file storage (create a new virtual file) and then marks the Flags field as FV_FLAGS_VIRTUALIZED. If it opens an existing file, the file virtualization component marks the Flags field as FV_FLAGS_NOT_VIRTUALIZED.

When a unknown process to delete (or rename) a file on disk, if the file has been virtualized before, the virtual file is deleted (or renamed) instead of the real one. After the operation is complete, the virtual file tree will be updated. On the contrary, if the file has not been virtualized before, it means the contained process wants to delete (or rename) a real file on disk, no files are actually deleted (or renamed). We only mark the Flags field as FV_FLAGS_DELETED on the virtual file tree node.

After all the unknown processes which access the same file name exited, the virtual file tree node instance is freed.

Like what we are doing in file virtualizations, whenever unknown processes tries to do relevant operations on registry, kernel objects, services or RPC, operations are interrupted and diverted to virtualized interfaces. Therefore, malware or ransomware in containment (Kernel API Virtualization mode) cannot access user data or damage the protected system and are deleted by default upon receiving a “Malicious” verdict. Conversely, if unknown processes are given a final verdict of “Good” while in containment (Kernel API Virtualization mode) environment, they are automatically allowed to run on the host in subsequent sessions, contingent upon the administrator’s policy. This concept of intelligent containment (Kernel API Virtualization mode) is essential to ensure the usability of the machine and user experience remains completely unchanged.  Yet the user may now click on anything without the risk of infection and subsequent enterprise breach.

Comodo Blog 

Free Tutorials