WEBVTT 00:00.000 --> 00:24.080 What kind of run for the next talk? Let me choose Bion and Sina with the talk about 00:24.080 --> 00:31.080 Invisible Hypervisors, Delphi, Malbert, and Elisis with Hyperdi BG. 00:31.080 --> 00:38.400 Great. Hello, everyone. Thanks for joining. My name is Bion and I'm a PhD candidate at 00:38.400 --> 00:45.040 Fusek in Amsterdam. I'm also a security researcher, mainly specializing in UEFI, 00:45.040 --> 00:52.920 Hypervisor, and PCI express security. My previous work includes Thunderbolt vulnerability 00:52.920 --> 00:59.240 research. This is my colleague Sina. Hello, I'm Sina. I'm also a PhD candidate in 00:59.240 --> 01:05.800 FI University at Amsterdam and I'm also enjoying my time spending on system programming, maintaining 01:05.800 --> 01:13.680 Hyperdi BG, and most of the time Windows internals and Digital Designs, you can see some 01:13.680 --> 01:22.680 of my works in my blog. So we'll be providing two talks for you today about Hyperdi BG. 01:23.560 --> 01:29.320 Later today in the virtualization track, we'll have a general introduction to Hyperdi BG, 01:30.520 --> 01:35.720 where we show you what it can do, but also how we've implemented all of the features 01:35.720 --> 01:42.120 underdrewed. So if you're really interested in some in-depth technical details, please join us 01:42.120 --> 01:48.600 later today. And the current talk is, yeah, that's happening right now where we'll be talking 01:48.680 --> 01:57.400 about a specific use case, which is analyzing malware using Hyperdi BG. So let's talk about 01:57.400 --> 02:08.120 Hyperdi BG. Hyperdi BG is a hypervisor based debugger, and it's a hypervisor and it's a debugger. 02:08.120 --> 02:15.160 And the way we do is, is we leverage the Intel ISA's virtualization extensions that are 02:15.240 --> 02:23.400 actually originally intended for virtualization, but we are using instead for various debugging 02:23.400 --> 02:29.320 functionalities that are normally not possible with classic debuggers. And being hypervisor 02:29.320 --> 02:37.320 based means that we operate independently of any OS level, debugging APIs. And this opens up 02:37.320 --> 02:43.800 all sorts of possibilities, which we'll be talking about in a little bit. Our first release was 02:43.800 --> 02:51.800 in 2022 for Windows and it's been actively maintained since. We are also working on a UE5 based OS 02:51.800 --> 02:59.480 agnostic hypervisor agent so that we can support Linux, a BSD, and basically any other operating system. 03:02.360 --> 03:09.560 So on X86, the CPU offers various privileged levels through so-called protection rings 03:09.880 --> 03:18.920 and the classic debuggers like WinDBG and GDB and many other stereotypically implemented 03:18.920 --> 03:29.560 either in Ring 3 or in Ring 0, the kernel. And basically, yeah, the deeper that you go, 03:29.560 --> 03:33.720 the more prefers that you are, and the more feasibility you have over the system, and over the 03:33.720 --> 03:41.240 debugging that you're debugging. So if you are into the buggers or I've used them before these 03:41.240 --> 03:48.760 names will sound familiar to you. So there's K-Propes on Linux, which lets you do all sorts of interesting 03:48.760 --> 03:56.760 stuff even tracing in the kernel. There is, of course, S-Trace for inspecting CIS calls and there's 03:56.840 --> 04:05.000 P-Trace and U-Propes for user space. And if you're a Windows user, then a WinDBG will be 04:05.000 --> 04:12.200 the tool of choice and it will let you do debugging on any of these three levels, though it 04:12.200 --> 04:16.120 doesn't let you do it across the main, which is also one of the things that we can do. 04:18.120 --> 04:22.200 And this is where hyperDBG lists, right there in Ring-0. 04:22.360 --> 04:30.360 So debugging and analyzing malware, I'm giving the word Tuesday now. 04:30.360 --> 04:37.400 So for debugging and analyzing malware, there are lots of anti debugging and anti hypervisor 04:37.400 --> 04:45.320 techniques. And usually when a malware detects one of these, usually when a malware detects 04:45.320 --> 04:52.440 the pretense of a debugger, it tries not to reveal its malicious behavior. And as a result, 04:52.440 --> 04:59.480 the reverse engineer actually couldn't find and reverse the malware and couldn't find 05:00.760 --> 05:09.960 like what is the behavior of their malware. So here we talk about our approach. We are 05:09.960 --> 05:18.520 introducing hyperivate. Hyperivate is like an extension to HyperDBG debugger and like 05:18.520 --> 05:28.520 reverse engineers could use HyperDBG along with Hyperivate project. For the roadmap in 2022 first, 05:28.520 --> 05:35.320 we released HyperDBG and by HyperDBG by its nature. I mean since it doesn't use any debugging 05:35.320 --> 05:43.800 API from the operating system like Windows, by its nature it's more transparent and lots of 05:43.800 --> 05:50.360 the classic anti debugging methods that detect the percent of the debugger won't work on HyperDBG. 05:51.400 --> 06:00.680 And right now, we are making it even more transparent by presenting Hyperivate project. Hyperivate 06:00.680 --> 06:10.600 tries to mitigate and bypass those user mode process modules, kernel mode drivers and find 06:10.600 --> 06:17.400 hundreds. It tries to hide the percent of HyperDBG as the debugger and it also hardens the 06:17.400 --> 06:23.480 hypervisor against some hypervisors specific tampering methods like if they want to take 06:23.560 --> 06:33.880 host IDT or other things. For 2027, we tried to reduce the footprint of HyperDBG even more 06:33.880 --> 06:42.440 by mitigating some like some footprints and artifacts that are related to Hypervisors and are 06:42.440 --> 06:49.880 related to PCXpress devices as well as address the subset of architectural side channel attacks like 06:49.880 --> 06:57.080 those who detect the percent of Hypervisor by some timing side channels by some model specific 06:57.080 --> 07:04.360 registers, performance counters, or some custom instructions like XTV, SIDT or SGVT. 07:08.360 --> 07:13.320 Yeah, so talking about Hypervisor based transparency. As seen already mentioned, 07:13.800 --> 07:24.200 Hypervisors and debuggers leave all sorts of traces that could be used by malware to detect 07:24.200 --> 07:27.720 that it's running inside a virtualized environment or that it's being debugged. 07:28.920 --> 07:33.320 There are several categories that we are currently in the process of mitigating 07:34.280 --> 07:40.440 or have already mitigated in HyperDBG. CPU fingerprinting and Hypervisor specific IO are two 07:41.080 --> 07:49.720 very basic ones that we've already got covered. Currently, we're working on several aspects of X86 07:49.720 --> 07:58.040 ishubbing AF here and yeah, like in terms of certain instructions that behave differently from 07:58.040 --> 08:04.920 a guess as opposed to bear metal. Virtual device detection is an interesting one. We'll be 08:04.920 --> 08:11.560 talking about that in a bit. And timing side channels, you know, performance counters, we've already 08:11.560 --> 08:18.840 mentioned them briefly. You can tell how much time has passed between, you know, the CPU that 08:18.840 --> 08:23.720 between the time that the CPU has spent on the VM or other VMs and the host. 08:25.080 --> 08:29.480 Windows specific detection, yeah, that is really about querying Windows APIs for a 08:29.480 --> 08:36.840 but kind of hardware that you're running on. Same goes for file system or process analysis. 08:36.840 --> 08:47.080 Every Hypervisor has its own application tools like VMware Tools or the SPICE agents, virtual box 08:47.080 --> 08:56.040 guest editions. And finally, there's three remaining ones sensor metrics, very basic information 08:56.120 --> 09:02.840 like what's a temperature of a hard drive or an SSD or what's the fan speed? Well, these 09:02.840 --> 09:09.080 will return obviously very different numbers inside of the VM as opposed to bear metal. 09:09.800 --> 09:18.360 Same goes for UEFI, the BIOS, and finally memory probing where some hypervisors leave certain 09:19.320 --> 09:25.160 telltale signs in the memory and we have medications to hide them. 09:27.160 --> 09:34.840 So, virtual device detection, yeah, this is an example PCI Express device tree on bear metal. 09:35.960 --> 09:42.600 As you can see, lots of Intel hardware, there's one kiox, yeah, SSD, and a real tech ethernet 09:43.480 --> 09:48.440 now let's have a look what happens when we do the same on a VMware hypervisor. 09:48.440 --> 09:55.240 It looks completely different as you can see, but suppose you would not see the name VMware there, 09:55.240 --> 09:59.960 right? It would be something completely different. Then let's have a look at this Intel Ethernet 09:59.960 --> 10:07.640 Nick. Well, at first sight, it looks like a real Ethernet Nick, but really it is an Intel E1000 compatible 10:08.600 --> 10:15.000 virtual Nick. So, if you query the metadata for this device, it will look something like this. 10:15.960 --> 10:22.600 This occult PCI configuration space, and what we can do in hyper DBG is replaced this 10:23.160 --> 10:31.400 metadata by metadata that belongs to a physical actual Intel network interface guard. 10:32.040 --> 10:36.360 Now, I can hear all you're really here, you're thinking, but wait, this how can this happen or how 10:36.520 --> 10:42.520 can this work, right? It's two different devices. The driver will do something different, maybe, 10:42.520 --> 10:49.480 that the device won't expect. Well, the trick is that this Ethernet Nick is also E1000 10:49.480 --> 10:55.240 compatible, but it's a physical product, so we can easily swap between those two. And the same 10:56.040 --> 11:02.040 approach, we can imply to many other PCI Express endpoints that you've seen in previous slides. 11:02.120 --> 11:10.040 Another showcase that we would like to share with you is Cisco. For example, you have a user 11:10.040 --> 11:15.080 space program, it does some Cisco's, and you want to know why it's doing that or what it is 11:15.080 --> 11:24.040 is doing with it, what parameters it sends along. Hyper DBG has several features that allow you 11:24.040 --> 11:32.200 to do this in a quite easy way. So on the left, we have the Cisco handler in NTDLL, 11:32.200 --> 11:38.200 for those who are not familiar, NTDLL is mapped into the user space program, and it's basically 11:38.200 --> 11:44.920 the entry point for the Cisco handler in the kernel. So the Cisco instruction is called, 11:45.480 --> 11:53.800 then what happens is the kernel Cisco handler RSP address is copied into the RSP, that's I832, 11:53.800 --> 12:02.680 L-Star, and then we move on to the right to the swap GS instruction, which is the kernel code 12:02.680 --> 12:10.360 that actually handles the Cisco. So we put an EPT hook as we call it on the move instruction, 12:11.000 --> 12:18.680 and this will set a track flag in our flags. Now what we can do here, because it triggers a 12:18.680 --> 12:25.480 VM exit, we can actually modify the Cisco number that was called by the user space program. 12:27.480 --> 12:35.160 Finally, if we continue on the left, so we've executed the Cisco parameter, we arrive at the return 12:35.160 --> 12:43.240 instruction, then the track flag again triggers a VM exit, and then we can do we can basically 12:43.240 --> 12:49.720 modify the return value from the Cisco, or we can modify the return buffers as we would like. 12:53.080 --> 13:00.360 So a quick debugging crash course on Windows, there is a data structure called process environment 13:00.360 --> 13:07.880 block, and this is accessible to all user space programs, and well this is very interesting 13:07.880 --> 13:13.720 information, especially if you're a piece of malware. There is a parameter called being debugt, 13:13.720 --> 13:18.600 obviously it tells, it's a telltale sign, if the process is being debugged or not, 13:19.240 --> 13:26.280 there is also LDR, which basically enumerates all of the loaded modules, and obviously if you're 13:26.280 --> 13:31.960 debugging, then you should not really trust whatever is in this enemeration, because the malware 13:32.040 --> 13:40.360 will be able to hide any objectionable modules there. There is also some undocumented flags like 13:40.360 --> 13:48.760 anti-global flag, which again can be used to detect whether you're debugged or not as a user space 13:48.760 --> 13:56.840 process. There is also a track environment block, which includes sensitive information about 13:56.920 --> 14:03.080 threat state, and I can go on and I'll go on, but basically if you want to monitor all those 14:03.080 --> 14:09.800 fields like be notified of any changes, then under normal circumstances with a classic debugger 14:09.800 --> 14:15.720 you would be limited to four breakpoints, because there are only four heart-ready bug registers 14:15.720 --> 14:22.360 that can be used for this purpose, and that's where E.P.T. hooks come to the rescue. 14:23.000 --> 14:30.840 So in principles, there are a lot of addresses, there are a lot of locations where you can detect 14:30.840 --> 14:37.240 the presence of the debugger, and there are probably a lot of tools out there that are able to bypass 14:37.240 --> 14:45.960 these flags, but the difference here for HyperDVG and HyperDVG is that HyperDVG could monitor 14:46.200 --> 14:54.120 all of these locations, both in the user mode and in the kernel mode, and what it will give us 14:54.120 --> 15:01.800 is that it will show us that at some points a malware or a piece of code tries to access these 15:01.800 --> 15:08.840 locations. So the reverse engineer gets an idea, okay, this malware at this location, at this 15:08.920 --> 15:16.600 program counter tries to modify or tries to query about some flags that reveal the presence 15:16.600 --> 15:24.200 of a debugger, so probably it is the location where the malware wants to check for its 15:24.200 --> 15:32.760 untidy bugging and anti-hypervisor methods. And now we have a demo, a brief demo of HyperDVG. 15:42.760 --> 15:50.120 So for this demo, we made like a application that performs a direct system call, 15:50.120 --> 15:56.760 like instead of going through the regular Windows path to a system called through entity 15:56.760 --> 16:05.960 other, it directly calls a system call, directly calling the anti-open file, and as you can see 16:07.240 --> 16:16.120 first we run and the first we check with or EXD5 direct system, let EXD, that whether this 16:16.120 --> 16:23.960 file which is responsible for VMware tools is available in this system or not, and first of all 16:23.960 --> 16:31.400 we connect to the HyperDVG through the serial port, virtual serial port, so basically we are debugging 16:31.400 --> 16:38.120 the guest virtual machine from the host, debugging the operating system. 16:38.120 --> 16:55.480 So we here use a virtual pipeline which is a virtual serial device, and now HyperDVG is synchronizing 16:55.480 --> 17:03.080 the symbol details of this specific system like this specific guest, so as you can see I use the 17:03.080 --> 17:09.160 Hide command in HyperDVG, and Hide command either gets a process ID or a process name. 17:09.160 --> 17:17.880 Here we use a process name and I will give it a direct scull that EXD, so right now whatever 17:17.880 --> 17:30.440 process executes on the system that it contains direct scull, it will try to change the execution path. 17:30.440 --> 17:37.080 So you can see that anti-open file successfully executed for this one, but for the second one 17:37.080 --> 17:43.800 anti-open file failed with an status which reveals that the file does not exist or I don't know 17:43.800 --> 17:47.400 the system doesn't have access to that file. 17:47.400 --> 18:02.200 So as the conclusion, also 100 transparency is impossible here in HyperDVG tried to raise the 18:02.200 --> 18:14.120 bar and HyperDVG's capability to provide wider system visibility and more transparency for 18:14.120 --> 18:20.600 debugging and reverse engineering malware. As malware techniques evolve, new techniques were 18:20.600 --> 18:28.440 also added and will be required and will be managed to the HyperDVG project, and of course HyperDVG 18:28.440 --> 18:35.720 is like an open source project, it is on their active development and community contributions 18:35.720 --> 18:46.200 will come the PR. So any questions? Thank you. 19:06.680 --> 19:13.480 Thank you very much. I have a question. I seem to recall that some of the windows 19:14.280 --> 19:20.680 I take under the L but I'm not sure, relies on these debugging flags or breakpoints 19:20.680 --> 19:27.400 flag or something like this to make breakpoints work. Is that the case? And if so, what happens when 19:27.480 --> 19:40.360 it's under HyperDVG? Okay, let me answer that question. So yes, there's a data structure on windows 19:40.360 --> 19:48.760 where if the processes are being debugged, these flags get set. So the process itself knows 19:48.760 --> 19:54.440 it's being debugged but also other processes can tell that that specific process is being debugged. 19:58.040 --> 20:07.000 What are the breakpoints or not work is independent of the flag? It's really just a flag. 20:07.000 --> 20:16.200 Yeah. So basically the HyperDVG just don't use any breakpoint and any debugging stuff. 20:17.160 --> 20:21.320 HyperDVG doesn't use the flags. Yeah, it doesn't matter fine. 20:26.760 --> 20:33.640 I think since you're running at the hypervisor, can you see the memory being protected 20:33.640 --> 20:42.520 by VBS, like this kit secure on-claves? Yes, well currently we require hyper feed to be 20:42.680 --> 20:49.240 disabled, but our goal is to support running as a nest-to-type hypervisor on top of HyperDVG and 20:49.240 --> 21:00.760 then we should be able to do that. Yeah. So I have a question. The first is, does it actually 21:00.760 --> 21:07.640 on HyperDV, modify it version? And the second one is what about performance? Sorry, 21:07.720 --> 21:12.680 could you repeat the question about HyperDV? So the first question is, does it hyperv, 21:12.680 --> 21:24.200 you modify and the second question is what about performance? Oh yeah. HyperDVG supports VMware, 21:25.240 --> 21:34.520 like VMware nested visualization and works also on bare metal, but for now it doesn't support 21:34.600 --> 21:40.840 HyperDV's nested virtualization environment and we are also not using any APIs from HyperDV. So 21:40.840 --> 21:48.280 it's the pure hypervisor we can buy in bare metal. And what was the second question about the 21:48.280 --> 21:56.280 performance HyperDVG has a different architecture compared to, let's say, WindyVG, we publish the 21:57.800 --> 22:03.960 security paper, academic paper, over HyperDVG you can't see that in terms of speed, 22:04.040 --> 22:10.280 HyperDVG gains over 1000 times faster than WindyVG because of its structure, especially on the 22:11.240 --> 22:16.920 Escript language. Any more questions? 22:24.920 --> 22:32.040 Hey there, thanks cool talk. Have you already used it in practice to study some malware or some real 22:32.040 --> 22:46.600 world to use case? Yes of course HyperDVG is so practical and a lot of malware reverse engineers are 22:46.600 --> 22:55.400 using it and right now you can see probably I see maybe more than 10 or 12 reports from security 22:55.400 --> 23:02.600 companies that they are also like their malware that they detect and reverse engineer they have 23:03.400 --> 23:10.840 specific things that are related to HyperDVG to detect the HyperDVG. So this is actively used by 23:10.840 --> 23:19.160 reverse engineers and also malware developers have some specific ways of detecting HyperDVG in 23:19.160 --> 23:25.480 which we try to mitigate. We also have the questionable honor of being detected as malware 23:29.480 --> 23:36.440 because it seems that the cheating community and video games also likes to use HyperDVG for their purposes. 23:40.120 --> 23:41.080 Any more questions? 23:41.320 --> 23:55.960 I don't see any, so think. He has still time. He's still have time. 24:02.040 --> 24:08.280 Hi, thanks for talking. How does it compare to something like drag flow for other systems? 24:08.280 --> 24:15.800 Because this is not really the original or the first one that does HyperDVG to be bugging, correct? 24:16.040 --> 24:34.600 Well, HyperDVG is like a blue peel style hypervisor. I'm not sure if you're a familiar, 24:34.600 --> 24:40.840 but it's running and an already running system. So I think there is no virtual machine. There is no 24:40.840 --> 24:46.840 Zen. There is no KVM involved here. It's a pure Hypervisor and it's also a debugger. Most of the 24:46.840 --> 24:52.920 features that are available here in HyperDVG are mostly for reverse engineering purposes and it 24:52.920 --> 25:01.400 gives you capability to debug. Like it has its own programming language, we call it DSLank and it 25:01.400 --> 25:08.040 provides like a lot of functionalities that are specifically meant to be used for reverse engineering. 25:10.840 --> 25:12.840 So thank you again very much.