I found my old note about signature detection apporach that typically used by AV products and I thought that it may be interested, so let’s dive in.
As an example, let’s consider Mimikatz (one of the most popular hacking tools) – Mimikatz 2.2.0 branch, tagged as version 2.2.0.
Interestingly, the simplest part of this tool is the kernel-mode driver, as it doesn’t contain much code.
Let’s build the mimidrv project and upload the resulting driver to VirusTotal to see how antivirus software detects it. However, we should keep in mind that each upload is logged by VirusTotal, and anyone interested in Mimikatz-related events will be able to see your IP address and other related details.
The first unmodified version of the driver is detected as follows: VirusTotal report.
Out of 68 antivirus engines, 29 detected the Mimikatz driver.
Trick 1: The simplest source code modification
We simply changed two predefined strings, as shown below
POOL_TAG is used in memory allocation / deallocation routines for troubleshooting purposes and MIMIDRV utilizes it in:
- IoCreateDevice
- IoCreateSymbolicLink
to create a new device and link it to a symbolic name that the user-mode code will use for communication.
This simplest modification causes McAfee antivirus to miss detecting the file: VirusTotal report.
Trick 2. Simple changes to the source code
Let’s replace the default values in the resource file
with the new ones
We now have the following result: VirusTotal report
Wow, it seems that the AVs’ signature detection method is ineffective, even in popular AVs like:
- McAfee
- Microsoft
- Symantec
use signatures extracted from the resource file inserted by the linker into the binary .sys driver to detect the Mimikatz driver.
If we examine the binary driver file, we can still see the “mimikatz” strings.
Let’s remove them as well. To do this, we should temporarily comment out the lines shown below.
We can easily replace these strings:
- “mimikatz.exe”
- “cmd.exe”
- “powershell.exe”
We can easily replace these strings with simply corresponding encrypted values, but I’m not going to do that here. Let’s just check how the AVs will detect the Mimikatz driver in this case.
Now, our driver doesn’t contain any “mimikatz” strings, and the detection result is as follows:
Do not think that :
- Cylance
- FireEye
- eGambit
- VBA32
have some improved techniques. That;s the truth. AVs can’t have a 100% effective method that will allow them to detect malicious code. In our case, the code contains typical machine instructions.
Finding unique signatures that hackers can’t replace with something else (like the “mimikatz” string) is not feasible.
Detecting that certain operations are performed by a hacker’s code is impossible if those operations can also be performed by legitimate code. For example, process enumeration in kernel mode code, such as in kkll_m_process_enum, from a machine code perspective, looks like:
and there is nothing unusual.
Actually, AV products are not as bad as they may seem. The most popular products use various remaining techniques to detect potentially unwanted code execution flows:
- CPU / hardware virtualization
- file system and registry operation virtualization using file system minifilter drivers and kernel mode Windows registry callback functions filtering functionality and etc
We can assume that AVs couldn’t execute binary driver code in their sandboxes before. Now, let’s try to hide Mimikatz strings in Windows PE executable file.
Here is what the detection rate looks like for the original, just-built binary mimikatz.exe: VirusTotal detection report.
And here is what it looks like after deleting strings like “mimikatz” from the source code and rebuilding the binary
so, detection rate didn’t improve. “It can be assumed that this is related to the specifics of how it works in a sandbox. In any case, I hope this article will provide an opportunity to see the picture from a different perspective.”