Marketing departments of Cybersecurity vendors around the globe go into overdrive when they can shout from the rooftops that their solution is ‘agentless’. Sure, that sounds good, but why is this so important? And what is truly agentless?
To appreciate the importance of an agentless approach, we’ll go old school and invoke Locard’s Exchange Principle.
What is Locard’s Exchange Principle?
Decades ago, the principle was established in the field of forensic science that the perpetrator of a crime will bring something into the crime scene and leave with something from it, both can be used as forensic evidence.
How is Locard’s Exchange principle relevant to malware analysis?
This principle has stood the test of time and works quite well in digital forensics – with a twist. The twist? In physical crime scene forensics, Locard’s principle aids the investigators.
In malware analysis, it works in reverse. If the malware analysis tool makes a change to the environment, that change is observable by the malware. Malware can then modify behavior to evade detection by simply ceasing operation or throwing off spurious and benign behavior.
We touched on these points in an earlier blog post about building a better Panopticon. The goal of a malware analysis tool is to have, like the Panopticon prison guards, total visibility into the inmates’ actions, except for our purposes we want to be unobserved. Therefore, we need to eliminate both the Observer Effect and the Locard Exchange Principle.
The Agentless approach to malware analysis and detection
This brings us to the importance of an agentless approach. The standard approach used by most malware analysis tools is to inject a hook – a user-land or kernel-land driver that intercepts communication between the suspected malicious process in memory and the OS (Figure 1). In other words, the hook intercepts the API calls like a shim and communicates the information to an external monitor.
Figure 1: Possible hooking locations in Windows kernel
That hook is the agent, and this agent is a modification of the environment, leaving artifacts for the malware to detect. So, what to do? Some vendors have taken the full system emulation approach of sandboxing. This has its own drawbacks, such as performance. And malware can detect any flaw in the emulation.
At VMRay we’ve taken an altogether different approach: A truly agentless approach where all monitoring is in the hypervisor. Yet, rather than emulating, the target machines are Windows VMs – your own golden desktop and server images for example.
By using SLAT (Second level address translation) tables, we are able to bridge the semantic gap by reconstructing the guest OS memory from the physical mapping of memory to the host OS, giving us full visibility from the outside. Furthermore, we leverage the CPU virtualization extensions in current CPU architecture to exert control over the guest entirely from the hypervisor without modifying a single bit of the target machine. Hence, a truly agentless approach.
You can read more about how the agentless approach eliminates one of the major vectors of sandbox detection by malware in our series on sandbox evasion starting here.
References
https://www.ijecs.in/issue/v5-i3/32%20ijecs.pdf
https://en.wikipedia.org/wiki/Locard%27s_exchange_principle
https://www.vmray.com/blog/eliminating-observer-effect-malware-analysis/
https://www.vmray.com/blog/sandbox-evasion-techniques-part-1/
https://www.vmray.com/wp-content/uploads/2016/07/VMRay_Technology_Whitepaper.pdf
