Science @ Avira, the ITES project
It is well known that classical computer architectures were not designed with security in mind. We intend to change that. The ITES project is creating a system purposefully built for high-security environments.
The current ITES system deploys verified compartments via Virtual Machines for different tasks. A compartment contains an operating system and the required programs (e.g. email client). Each compartment has restricted permissions that are unique. For example the browser compartment does not have access to the business plan, so if an exploited browser is running on a different OS than the email client, which has access to critical information, the impact of an attack is reduced.
Our goal in the ITES research project has been to extend the compartments system to identify hacked Virtual Machines and start countermeasures. We identify hacked machines by observing them with different sensors (user-space hooking, memory forensics and VMI – Virtual Machine Introspection).
After gathering information about the current situation in Virtual Machines, a central component will classify the state of the machines into ‘trustworthy’ or ‘suspicious’. Depending on the decision, the machine can be stopped, analyzed, repaired or restored from a snapshot.
The goal of a scientific project is to learn by building a „Demonstrator“ (an Alpha Prototype) – it is not to create a product. The operating system is split into several compartments with Antivirus (AV) technology and hypervisor sensors attached.
However, many of the pioneering technologies we developed to build Demonstrator are or will soon be integrated into our internal processes. One of our backend systems in the Virus Lab at Avira is now classifying samples for our customers based on this new technology.
Identifying malicious files is the Virus Lab’s first task when encountering unknown software.
Three methods are usually deployed to identify malicious code.
This is Avira’s traditional forte and is how we’ve been identifying malicious code for years. Malware is, for example, identified by exact hash, fuzzy hash, byte patterns, structural generics, or by an AI while the engine complements the analysis by gathering behavioral patterns. It is not part of the ITES project.
Dynamic analysis monitors the behavior of malware. You can do it on the end-user’s system (behavior analysis performed by the AV software) or using specific analysis systems (e.g. Analysis Sandbox like Cuckoosandbox or our internal cloud-enabled Autodumper tool).
Depending on the type of the malware, we will have to monitor it in different ways. By monitoring the User-Space API, we are able to detect the Dropper of malware. Sensors in Kernel Space or below are required to identify rootkits. Kernel space sensors are drivers, and you get those with your AV software.
They will have a different (less detailed) point of view, but cannot be easily tricked by the malware in the User-Space API. Monitoring the OS from outside of the Virtual Machine is even better. One existing tool that does this is Volatility. It uses a memory snapshot of a real machine or a virtual machine and checks for anomalies in the OS data structures. As a part of the ITES project, we integrated Volatility into a Cuckoo Sandbox and use it as a second sensor.
A disadvantage of Volatility is that it only uses a snapshot, so it is possible to observe the effects of the infection, but not the process of the system being infected. Additionally User-Space events are not observed at an acceptable level of quality.
Virtual Machine Introspection (VMI) takes this approach to the next level and is currently being researched by the RUB (Ruhr University Bochum) & IFIS (Institute For Internet Security) as part of the ITES project. By monitoring the system through the hypervisor we could achieve a similar perspective as with Volatility, but without having to create snapshots. Soon we will know what granularity of data will be possible.
Having a cloud service and large databases on our backend servers, it is possible to identify specific spread patterns that are typical for malware. Suspicious patterns can be defined by scripts. Rules might look like
- If a user is running a sample, which has not been seen by the cloud yet, and is strangely packed: trigger a warning
- If a computer executed an unknown file, after the user visited a suspiscious page on a freehoster, and the computer is running an outdated PDF reader program: trigger a warning
You get the idea. The ITES project does not cover this area.
There will be more blog posts covering the details soon.
Avira is investing into scientific research to deliver superior protection to our customers.
This article is also available in: German