Detect Kernel-Mode Rootkits via Real Time Logging & Controlling Memory Access

Editor's Notes

• #2: Hi, I’m Igor, thanks for coming. The title is quite long, but actually it means just “We Protect the Computer Memory”.
• #3: The ideas I’m going to present you are based not only on my work but also on the research made by Satoshi Tanda.
• #4: About a year-and-half ago I found his blog, where he carried out a huge research about how Patch Guard can be bypassed. He is really good at reverse engineering, hypervisors, and also he is a professional developer. I found his results very interesting and suggested him an idea of how to protect PatchGuard from being defeated. And here is the result of our collaboration. Accesses to the computer memory can be illustrated as a road traffic and this traffic looks like the left picture.
• #5: Here we can see no traffic lights, no traffic signs, no road marking. Actually in computer memory we have a similar situation. My idea is to protect the memory by monitoring and controlling memory accesses. As a result, it will look like the right picture, where each car is counted and any violations /ˌvaɪəˈleɪʃ(ə)n/ will be recorded.
• #6: I’d like to start with experts’ view on some new malware trends. I’ll tell you about how to detect malware infections at early stages. Next, I’ll demonstrate you how I managed it by controlling memory access. I’ll show you the advantages of new memory monitoring tool. Finally I’ll describe my ideas about applying The Internet of Things in digital security.
• #7: The researchers from these two universities raise their concerns about modern malware rootkits. We can see that memory dump analysis is becoming useless. What protection mechanisms do we have to solve this issue?
• #8: Windows has several protection mechanisms to deal with these attacks. For example, a Driver Signature Enforcement prevents loading an unsigned driver. Another one is PatchGuard, which checks the integrity of the Windows kernel and in case of any modification PatchGuard crashes the system and we see a blue screen of death. Unfortunately, a new malware can avoid all these protection mechanisms.
• #9: 3 million of new malware binaries with digital certificates show the weakness of the Driver Signature Enforcement. These two rootkits are able to defeat PatchGuard even on newest Windows. There are a lot of examples of defeating Windows PatchGuard. I’d like to show you one of them.
• #10: I’ll show you these three scenarios. Firstly, I will load a rootkit, which hide a process and PatchGuard reacts on this manipulation via Blue Screen of Death (BSOD). Secondly, I will load an exploit which disables PatchGuard and hides a process. In this case we won’t see a BSOD. Finally, I’ll present you a new memory protector, which stops this exploit and protects the operating system. Now we will see 3 videos. Let’s start. Second video: This infection was the starting point for my research. I thought how to prevent this or similar exploit by monitoring memory access. Let’s see what I achieved.
• #11: Here are the results of these 3 scenarios. We can see that only in the final video the operating system has been protected. The new memory interceptor blocks the exploit and prevents malware infection at early stage.
• #12: What sort of malware attacks can we prevent? Let's think of some scenarios that this memory interceptor will face and try to specify its requirements. Modern malware can read sensitive data from the memory. It can change the memory content, for example, by hooking, unlinking, or patching. And also the unknown code execution can create a new thread.
• #13: Well, we need to control all possible memory accesses: reading, writing, and executing. So, for each memory access, we will log the following triple: source address, destination address, and the type of accessing. It will be also good to filter all these accesses, for example to monitor memory access only from a suspicious driver or to limit access to the sensitive data in the memory.
• #14: I propose to divide memory into three parts: Source range, Destination range and others. Memory protector controls memory accesses only from the source range to the destination range and skips all the rest. Source range can include, for example, the beginning and ending addresses of the entire driver in memory. Destination range can contain the range of addresses and can also include just one address to reveal a patching attack. What else do we need? Compile and load this memory interceptor like any other driver. And keep it up to date. This tool has to support the newest Windows 10 64 bit and multi-core CPUs. That’s it. But how to achieve this?
• #15: Let’s move on to the question – what tools and technologies are available at the moment? Windows protection mechanisms such as a process security and access rights regulate only the user-mode memory. There are no built-in tools for controlling kernel-mode memory so far. So what can help us to prevent unauthorized access in the kernel mode?
• #16: The most interesting memory mónitoring methods and projects are here. All methods can be divided into two groups: based on operating system facilities and based on hardware virtualization technology. OS-based methods can be separated into two subgroups: based on hooking memory management functions, and based on handling page fault exceptions. Hypervisor-based methods can also be divided into two groups. The first one handles page fault exceptions, while the second one applies a new virtualization extension – EPT to track all memory accesses.
• #17: And here is the table of existing projects, which are based on the corresponding methods. We can see that none-of-them controls all three memory accesses at the same time. So, I decided to create a new memory mónitoring tool, which will meet all these requirements. I named it Memory Monitor of Read- Write- and eXecute access or just MemoryMonRWX. So what technology can be used as a basis for this new tool?
• #18: The EPT technology, which has recently been integrated in Intel processors, seems very perspective. It is called VT-x with Extended Page Tables (EeePeeTee). I’ll give you a brief overview of this technology, its paging structures, and how to use EPT to monitor and control the memory access.
• #19: Let’s look at the mechanism of address translation between the guest memory and the host memory. Without EPT once guest memory is accesséd, the translation between the guest virtual address and guest physical address starts happening. Then we receive the guest physical address. Without EPT this very guest physical address is used to access the host memory.
• #20: Using EPT we get an additional or a second level address translation. This case is on the right. EPT plays the role of an intermediary during address translation. The guest mapping is the same. But now, we receive the host physical address by traversing the EPT structures. These structures are very similar to the paging structures in the protected mode and determine the mapping between the guest memory and the host memory. Let’s zoom in on EPT paging structures.
• #21: Now we are looking at the fourth EPT tables or leaves of EPT tree, which are called the EPT Page Tables. This table includes a lot of entries, which contain information about a single 4 Kilobyte memory page. Each EPT entry includes access bits and page frame number PFN. This PFN is a host physical address of the corresponding memory page. EPT access bits indicate whether read- write or execute-access is allowed for this page. Intel manual says that ‘any attempts at disallowed accesses will involve EPT violation and cause VeeM exits’. Also the hypervisor can limit access to this page by changing its PFN value. In order to intercept or skip each memory access, we configure the access bits in the corresponding EPT page table entries.
• #22: There are two main scenarios of using EPT. If this memory access is not allowed, it involves EPT violation and causes VM exit. At this moment the hypervisor is able to log access to this memory page. After that control goes to physical memory and comes back to the guest, see central figure. But, if this memory access is allowed according to the EPT bits, the hypervisor skips this access. We can see, that by changing EPT setting a hypervisor can ímplement various algorithms. This is exactly what we’ve been looking for.
• #23: Now let’s move on to the final question how to apply these EPT features to control access only from the source range to the destination range and skip all the rest. We can combine skipping and trapping memory access in the following five steps.
• #24: First of all, let’s divide memory content into three sections: source range, destination range, and others memory addresses. The memory access attempts are shown by arrows. Here we have various accesses. For example, this is the access from the source range to the destination range, that one is from the destination range to others etc.
• #25: We are interested only in accesses from the source range, which are in red. We need to skip all other access, which are from the destination range and others. They are in green.
• #26: To achieve this, we can use the following EPT structure as a trap. This is EPT normal view structure. In this structure only execution access bits on the source range are disallowed. All other accesses are allowed and will be skipped. Now any code execution on the source range will involve EPT violation, which causes VM Exit. Hypervisor will trap it and we go to Step 2.
• #27: Control goes to the hypervisor. At this point we have accesses only from the source range. We are focusing only on the accesses to the destination range. We are filtering out all other accesses.
• #28: In order to achieve it we use another EPT structure as a second trap. This is EPT monitor view structure. This structure disallows accesses to the destination range and skips all other accesses. Any access to the destination range generates a VM Exit again and we move on to Step 3.
• #29: At this point the control goes to the hypervisor again. Now we can log all related information: the source address, the destination address, and the type of áccess. Also we can optionally protect the destination data from being read {RED} or overwritten. In order to achieve it we apply the following 3 procedures:
• #30: (1) We change PFN value of the secret page to the substitute one, for example, to the null page. This helps to protect the original data. (2) We allow read- and write- access to this page. (3) We set Monitor Trap Flag (MTF). Setting MTF flag enables the system to generate VM Exit after executing each instruction. As a result, after the guest operating system reads the replaced page by executing just one instruction, the control goes automatically to the hypervisor again and we move on to Step 4.
• #31: We’ve just avoided an access to the secret data. We need to restore the original settings. We apply the following 3 procedures: (1) We set PFN value to the original page with secret data. (2) We block read- and write- access to this page. (3) We reset Monitor Trap Flag. This is the original EPT monitor view structure. After that any access to the destination range will generate VM-Exit, and we move on to Step 3 again. Any execute access on other range will also generate VM-Exit, and we move on to Step 5. We’ve already considered Step 3. Now we go to the final Step 5.
• #32: Now we trap an execution on destination range and others memory addresses. We double check if this VM Exit address belongs to the source range. If it doesn’t, it means that this code is out of our control and we don’t need to control it. So we change EPT from monitor view to normal view to be ready for trapping a new code execution on the source range. That’s it.
• #33: Here is the summary of the interaction between two EPT structures: normal view and monitor view. Firstly, we set EPT normal view to intercept any access from the source range. Secondly, after trapping an execution on the source range, we change EPT pointer to the EPT monitor view. It helps us to log accesses only to the destination range. Thirdly, we can optionally protect the page by redirecting access to another page. And after an access to the substituted page we restore setting, this is step 4 and go back to the EPT monitor view. If we trap the execution, which we don’t need to control, we change EPT to the normal view.
• #34: We checked all these ideas by developing a MemoryMonRWX hypervisor. Now let’s look at its architecture. MemoryMonRWX includes the following five components: HyperPlatform, Image Load Detector, Virtual-to-Physical Map Manager, EPT controller, and Source/Destination Range Manager.
• #35: HyperPlatform is the main component of this system, which is a bare-metal hypervisor and it is designed for intercepting various events in the operating system.
• #36: Source and destination address ranges are formed by Image Load Detector. We set the addresses of recently loaded drivers as a source range. Destination range includes, for example, address of PoolBigPageTableSize, which we’ve seen in the video at the beginning.
• #37: Virtual-to-Physical Map Manager maintains mapping between virtual and physical addresses. Actually it is a supplementary component.
• #38: EPT controller is responsible for updating EPT Structures and handling EPT violations.
• #39: And the last one is the Source/Destination Range Manager. This manager asks the EPT controller to update EPT access bits for the source and destination ranges.
• #40: Architecture is quite simple, the source code is uploaded here.
• #41: MemoryMonRWX is designed to be small. It is made up of less than 12,000 lines of code, which is less than 3% of XEN, for example. Also, it can be compiled on Visual Studio without any problems. It can be debugged with WinDbg just like a common Windows driver. MemoryMonRWX is very fast. The results showed that performance degradation was less than 10% in all tests except only one. It is quite positive.
• #42: MemoryMonRWX is a very promising project, it works in the newest Windows 10 and supports multi-core CPUs. It provides integrity and confidentiality for both code and data in memory. It can prevent data leakage attacks, unauthorized software copying, and protect PatchGuard from being disabled. MemoryMonRWX is just a fishing rod to catch memory disclosure attacks, I’m planning to develop a fast fishing boat to catch more and more. Also I’d like to show you my future plans.
• #43: During my research I usually ignore hardware tools for digital forensics and incident response, but now look at this device. This hardware can acquire physical memory dump by connecting to the ExpressCard slot. It’s produced by WindowsSCOPE company and it costs about $8000. I suppose, that the device, which only dumps memory, can cost less.
• #44: My idea is to apply IoT platform such as Raspberry Pi for the acquiring and processing memory dump. For example, it is possible to use FPGA devolvement platform Spartan-the-third to connect Raspberry Pi into ExpressCard slot. This Spartan platform has been successfully used in this project. Also after dumping we can apply Raspberry Pi to process the memory dump automatically as well as to send a dump via the Internet. All in all, it will cost about 10 times cheaper and have more features.
• #45: Another idea is to protect medical devices from being hijacked. A lot of people need wireless devices like insulin pumps, implantable cardioverter defibrillator ICDs and many others to survive and improve the quality of their life. Patients and doctors use this wireless connection to control the devices and change their runtime parameters. Unfortunately, this wireless communication is vulnerable, here you can see some examples of resent cyber-attacks on implantable devices, performed through wireless connection. The idea is to protect this wireless communication.
• #46: We are planning to provide complex security for these devices. We propose to choose for example length of crypto key according to the device specifications. We are thinking of a prevention system to reveal wireless denial-of-service attacks on these devices.
• #47: Thank you!