 Next up, we are going to have some fun with some low-level RootKits kind of stuff. Now, Alexandre Bortus, I'm doing my best here, is in all the way from Brazil and he is a first-time speaker, so we want to give him a special recognition, so let's give him a round of applause. Have a wonderful time. Hello, everybody. Good afternoon. My name is Alexandre Bortus. I'm a malware and security researcher at BlackStorm Security and let's talk about RootKits. First of all, two things. English is not my native language, so if you don't understand something, please send me an email. These professionals deserve my sincere thank you and a deep respect for their researchers about the same time. Let's start. Honestly, I was expecting only 10 or 12 people here. This is a table of content. I will talk about two topics, ring zero and advanced malware, ring minus two. First, RootKits, ring zero. Malicious drivers have been using the same tricks every single day to infect systems, but no doubts. Callback methods or kernel callback functions is a good one because it's a kind of modern Roots used by anti-various programmers for monitoring and alerting the kernel models about a specific event occurrence. And kernel callback methods are a good trick to evade the defenses. Kernel callback methods provide us a notification when a process, a library, and a kernel memory is mapped into memory. When a file system becomes available, when a system is going to download, before a system crashes, when a thread starts or ends or finishes, when a process starts or finishes, when some registry entries are modified or removed. For example, I have seen some hours using this specific callback method, CM-register-callback, for checking if there are persistence entries are kept and just an analyst or software or a programmer removed, so the malware is able to add it back. It's a nice trick to keep the persistence. To find the number of callback methods is so easy, using Windows back, the first command there. And running a couple of commands, we have a very nice way to list the callback methods. For example, PS set creates process notify routine. It's a kind of list of callback routines to be called when a process is created or deleted. So in this case, it's so easy to find the number of installed callbacks, the first command at Windows back, and a very easy entry to the command at the middle to list all the callback methods that are installed. In the last few weeks, I have seen several malware using this specific callback method, PS set, legal notify routine callback methods. To register a malicious routine that is called during the thread termination. In this case, the malware changed the key thread dot lego data to provide malicious address and the routine redirects the execution flow to the malicious code. It's a very nice and different trick. Here we have the output from the last slide about the callback methods associated to create process. And here we have the structure of key thread and the legal data field that is changed by the malware. Windows offers different types of drivers such as legacy drivers, filter drivers, and manifest drivers. All of them are developed by using our WDM or WDF frameworks. Basically, a drive is composed by one or more device object, and each object is associated to a driver object. So most ring zero malware installs filter drivers for modified aspects and behavior of existing drivers, filter user of operations, add new malicious features, for example, key loggers. The trick is almost the same. We have driver stack in the malware. First, create a password for the unnamed device object by using this first function, add device. And secondly, the malware adds the unnamed device object on the top of the stack by using this function, IO attach device. All communications in the drive stack is done by using IRP packets. And each IRP packet is processed by a dispatch routine that's retrieved from the major function table. The IRP parameters are retrieved from the IO stack location by using this function, IO get key range IP stack location. Additionally, it's possible to pass down the IRP parameters to the next layer by using IO skip key range stack location or copy them by using IO copy key range IRP stack location. Alternatively, IRP packets can be passed down to the layer drive by using this specific call, IO call driver. Here we have a very nice trick. And some hours try to pass the IRP packet to the lowest driver by passing the middle of drivers and so avoiding to be detected by monitoring tools and hooking tools. So it's a very nice and smart trick to evade defenses. Here I show you a complete picture about it. And at the left, we have the driver stack. At the right, we have the associated device subject to each driver. Paytation that the IO call driver function is called to pass down the IRP packet to the next layer. At the bottom, we have computational routines that are called in the reverse order. So the computational routine is the function that does the job. All of them are managed by the IO compete request function at right. Here we have the IRP structure composed by a static part and a dynamic part. The dynamic part is composed by IO stack locations. So each IRP is created by calling the IO allocates IRP function. And as I mentioned before, this function and the other three in your head are interesting functions to be analyzed when you reverse in a malware. At the right bottom, we have the IO stack locations to culture composed by the major function. The major function holds the pointers to dispatch routines. Parameters field and computational routines field. Parameters fields depends on the major and minor functions. So in this slide, we have its structure of the parameters fields. And in the next slide, we have a complete list of IRP types. So easy. And here we have a complete relationship between the IO stack location structure, device object structure and driver object structure. It's a good slide to read tomorrow night. Here I show you a step by step investigation about a potential driver named A. Borges with some commons in the back. And pay attention. This specific malware uses some dispatch routines such as create, read, close, write, and device control. It's so usual to see things like that when you're analyzing malicious drivers. Here, a more complete overview of the structure. Show you the relationship between the reverse quote, driver object, and dispatch routines. In this slide, I started an investigation about potential malicious filter driver by using some commons in the back. Naturally, as close at the bottom of device stack across the infection, the more effective it is. I mean, most monitoring tools, a hooking tools, try to check the middle of the stack. So if the infection happened at the bottom, you are skipping all these tools and evading the defenses. Some malware tries to intercept requests such as read and write operations. By manipulating the module function array, for example, mg, device control, and IRP internal control callback, dispatch routines. Root kits try to protect itself from being removed by modifying functions such as IRP, mj, device control, and hooking requests going to the disk. It's other kind of tricks. Some malware tries to hook the driver and load routine for preventing the root kit from being removed. Another trick. However, most malicious drivers or most malicious mavers try to avoid touching areas protected by pet guard because pet guard is so tough to circumvent. Here, we have a list of protected areas by pet guard. Thanks to Alexi by this comment. Most time, mavers have been storing their payloads and configurations and encrypt-hiding file systems. Additionally, they have created the random device object names during the boot to associate to the special file system. Some mavers, composed by executable drivers, have been using APLC, a different local procedure call, to perform the communication between the user code and the driver code. Instead of using IO control commands. It's another smart trick. Some mavers don't use any specific driver for injection, but try to randomly pick up a driver by passing this last structure there. Key, loader, data, table, entry. Certainly hooking the file system access is so easy. Here, I show you a complete list of APIs. It's so easy to do that. A few mavers have been hooking this specific API, ZWQH, for intercept open requests sent to devices. It's a smart trick because it is antivirus using the same tricks. Some mavers, after assisting by dropping drivers, try to force a reboot by calling ZW Raise Harder Error Function. It's a very special trick. Other mavers, try to use the less routine here in red. I will register to download notification for restoring the malicious drivers in the next reboot. So, if you try to remove them, they back. Fortunately, most mavers have been using X Allocate Pull with Tag Function to allocate memory pull. But it's so easy to find them because we have the volatility here. We can find it by using Ida Pro, as you already know, or execute a command and win the back. Finally, most malicious drivers have been using APC Injection to inject some malicious code instead of using create remote thread. So, my recommendation is to pay attention to these three last functions in red. So, now, I'm going to talk about advanced mavers, basically, root key to ring minus two. When we talk about ring minus two mavers, the context is so different. Most mavers acting in this level attack NBR, VBR, UEFI, for example. Some mavers alter the BBP Biosparameter block to change the execution flow to another place in this case. This kind of malware alters these last field hiding sectors to change it to another address and execute the malicious code instead of executing the IPL. Here, we have a real case about mavers such as TDL4, which is encrypted and infects the MBR. So, in this case, the trick is try to load a good MBR and a bad one in the Ida Pro and emulate them using a box emulator. So, I try to compare to make my analysis easier. MBR modifications and VBR modifications are effective ways to bypass QCS kernel mode code sign policy. QCS is responsible for validating the drive signature. So, there are some ways to bypass QCS. Disabled, put windows in test mode, but in this case, secure boot must be disabled. Change the kernel memory. It's so easy. Or even try to find a flaw in the firmware. In this case, again, secure boot must be disabled. Here, we have a real case about a Trojan banker where the malware is put in the windows in test mode. In this case, it goes into force in a near future to load an unsigned malicious driver. Here, I show you a more complete overview. Composed by BIOS. Here, we have the boot process. Composed by BIOS, MBR, VBR, boot manager. And look at the left down. Here, we have the wing load easy. Many boot kits try to attack the before, load the kernel and illam protection. It's another smart trick to bypass the fence. MBRs have been infecting boot manager. Boot manager is responsible to switch the process and execution from real mode to protection mode. So, MBRs have been using some interrupts to access the driver, to patch models, and load malicious drivers. At the bottom, I show you some tasks associated to wing load easy. It enables the protected mode, check the models in accuracy, and load the windows kernel, load several DLLs and illam protection, and finally load drivers and system registry data. Therefore, integrity checking of wing load is critical. And if it is subverted, everything falls because the integrity control doesn't exist anymore. So, pay attention here. All modern protections are based on digital certificates and digital signatures. So, it's critical. Most advanced boot kits, as I mentioned previously, store their payload and configuration in a encrypted hide and file system by using some special upcodes. As you know, SMM mode is a kind of medical mode or God mode. That's a perfect place to hide a malware. Here I show you a first approach composed by SPI flash, SMM, UEFI services, MBR, VBR, the OS loader, and OS. Pay attention here. MBRs can attack any block here. So, you are not safe. Here is a quick reminder about the UEFI phases. Here I show you a more complete overview about the boot process composed by hardware, the UEFI phases, and things like that. Again, malware can attack everywhere here, but we have good protection such as boot guard, UEFI secure boot, OS secure boot, and so on. Remember, the SPI flash is composed by descriptors, Gigabit Ethernet, Managing Genie, ACPI, and BIOS. So, for example, the boot guard controlled by Managing Genie is responsible for validating the boot process by flashing a public key into the Intel Managing Genie. Obviously, for a perfect working of the boot guard, the SPI flash region must be locked, and the boot guard configuration must be set and protected against SMM root gates. Here I show you a quick picture about the boot guard blocks. Basically, each block verifies the next one. It's kind of a certificate chain. Another very interesting protection is the BIOS guard, which runs within the SMM and protects the platform against non-authorized SPI flash, BIOS update, boot infection, and corruption. Basically, BIOS guard only allows stress models to modify the SPI flash memory. Secure boot is responsible for protecting the entire path against the boot's key infection, protects the key components during the kernel load, key drivers and important system files, and at the end, secure boot prevents any loading of strange codes without a valid digital signature. Two essential items in the secure boot are the platform key. The platform key establishes a relationship between the platform owner and platform firmware, and it is responsible for verifying the key exchange key. At the bottom, key exchange key establishes a trust relationship between the platform firmware and OS. Actually, the key exchange key verifies the authorized database, which contains authorizing sign certificates and digital signatures, and forbidding database which contains the forbidding certificates and digital signatures. Obviously, if the platform key is corrupt, everything falls because the secure boot must be or can be disabled. Unfortunately, some vendors store important secure boot settings into F5 variables. However, if some root key exploits these variables, secure boot can be disabled. UFI BIOS supports TerseA as a cultural format. However, TerseA doesn't support signatures. Remember what I told you, all the modern protections are based on digital signature and digital certificate. So, in this case, if a root key is able to replace the typical PL loader by TerseA is equitable, so secure boot can be disabled. Fortunately, new release of Windows 10 introduced a very interesting feature about SMM protections known as Windows SMM secret mitigation table in Windows 10. The firmware is executed in SMM, it must be authorized and entrusted by VBS, so it's an additional protection for us. SMM protection flags in Windows can be configured for your use. Here, I show you some flags. Finally, I'm showing here a practical case about a customer in Brazil. In this case, the system is not protected against BIOS writing. You see the second one, BIOS read-write permission. So, it's terrible. In the same system, BIOS write-enable is set. It's terrible, too, because any malware can write a malicious code there. The BIOS lock-enable is unset. It's terrible, too, because this is a kind of notification bit. The SMM BIOS write protection is disabled. Horrible again. At the bottom, write. The protection range registers are disabled, too. So, in this case, we have a complete expose the machine, complete expose the system. Here, I'm using chipsack to perform my analysis, my checking. Here, we have the flash configuration lock-down is enabled. That's okay. However, it doesn't matter because the settings protects the protection range registers which are disabled. So, it doesn't matter. Here, the BIOS stop swap mode is disabled. That's okay, because in this case, it's impossible to redirect the resetting vector to a backup boot block. So, it's impossible to execute a malicious code. Finally, the SMM range is enabled. It's a good news. So, it's impossible to access the SMM run from a non-SMM mode. My conclusion are most security professionals are not ready to analyze malicious drivers because the theory is huge and not easy. I know that. Real customers, real words, are not aware about wing minus two threads. They don't know how to update the firmers. Most customers don't know how to do that. Finally, remember, all modern protections are based on the integrity. For example, digital certificate and signature. However, I leave a question here. What would happen if these algorithms were broken? For example, using quantum computation. This talk is dedicated to my wife and for you who deserve it sometime to be here. Thank you for attending my talk.