WEBVTT 00:09.080 --> 00:11.400 Hey Bill, how do you pronounce your last name? 00:12.980 --> 00:17.500 You're not going to be able to say it, but it's Demir Kapo. 00:18.420 --> 00:20.040 Do you want me to try it? 00:21.020 --> 00:23.660 I mean, I don't care. 00:23.660 --> 00:25.880 I won't get offended if you don't say it. 00:27.880 --> 00:29.940 Looks like we are live. 00:29.940 --> 00:31.580 Yep, we seem to be live. 00:31.580 --> 00:32.180 Alright. 00:33.220 --> 00:34.480 Welcome everyone. 00:34.480 --> 00:37.840 I want to introduce Bill. 00:37.840 --> 00:46.340 Bill, I just tried to do your last name in my head, and I was not successful at it, so I'd like you to say it for everybody if you care to. 00:47.120 --> 00:48.800 Sure, it's Demir Kapo. 00:48.800 --> 00:50.280 Alright, thank you for that. 00:51.000 --> 00:53.780 Instead of me murdering that, I wanted you to try it. 00:53.780 --> 00:59.520 So , Bill did a talk on demystifying modern Windows rootkits. 00:59.520 --> 01:02.880 This is your opportunity to ask questions of Bill. 01:02.880 --> 01:10.100 So, there are a few questions already coming in through the TrackOne Live QA channel. 01:10.100 --> 01:11.740 Let's just go ahead and get started. 01:12.760 --> 01:21.840 Eragon asks, what are the easiest features to find that might reveal a modern rootkit via static analysis? 01:23.260 --> 01:29.120 I think a good place to start for static analysis is going to be the strings. 01:29.120 --> 01:37.760 Because if they leave any debug strings behind, or any unique strings for that specific binary, that's a good thing to maybe add to your signatures. 01:37.760 --> 01:43.340 But another opportunity is going to be the imports of the driver. 01:43.340 --> 01:56.300 For example, if a driver imports a bunch of undocumented functions, that's obviously going to be a little bit more suspicious, given that legitimate drivers tend to try to stick with what's documented and what's stable. 01:56.300 --> 02:06.020 So, if there's any functions that it imports that is not stable, or it's just not really known about, it's something to look at. 02:06.180 --> 02:14.220 So, anything undocumented that's getting pulled in, you're thinking that's going to be your opportunity for shenanigans on that side. 02:17.060 --> 02:17.900 Potential. 02:18.600 --> 02:20.120 What was that, Pasties? 02:20.120 --> 02:21.560 I was just going to say that. 02:21.560 --> 02:22.540 Potential shenanigans. 02:22.540 --> 02:22.980 Potential shenanigans. 02:22.980 --> 02:23.980 It could still be legitimate. 02:23.980 --> 02:24.920 Yeah, that's true. 02:24.920 --> 02:29.860 So, next question from RPTK2015. 02:29.860 --> 02:34.020 Did you actually find any P-key when searching in Greyhat? 02:34.440 --> 02:38.980 Mentioned in the context of using a legitimate key to sign your driver. 02:39.600 --> 02:40.380 Yes. 02:40.380 --> 02:44.560 So, I didn't, of course, crack any of them. 02:44.560 --> 02:47.840 But, I mean, some of them were pretty obviously related to code signing. 02:47.840 --> 02:51.080 For example, I remember one that had, like, code signing in its name. 02:51.080 --> 03:01.320 So, it was pretty clear that these were probably associated with code signing and that it's potentially, if you crack it, you could use it for kernel-mode code signing. 03:01.320 --> 03:08.260 It all depends on the type of certificate it is and, you know, what vendor it came from and stuff like that. 03:08.260 --> 03:16.820 But I have definitely, I can confirm that I've seen potentially viable private keys on Greyhat. 03:17.340 --> 03:21.140 Do you know if there are some keys that are, like, more trusted than others? 03:21.140 --> 03:26.800 Like, some that you can use to sign code but that aren't trusted for, like, kernel-level drivers or something like that? 03:26.800 --> 03:32.600 I assume, like, a Microsoft signing key is, like, gold, but... 03:32.600 --> 03:33.700 Yeah, yeah. 03:33.700 --> 03:40.240 So, usually how it works is that you have, like, these certificate companies that issue these code signing certificates. 03:40.240 --> 03:44.260 And they work with Microsoft to get what's called a cross-signing certificate. 03:44.260 --> 03:54.280 So, this means that Microsoft says, yes, you can use this vendor or this root authority can issue certificates for kernel-mode code signing, just to give you an example there. 03:54.280 --> 03:57.740 And so, what you can do there is you can... 03:57.740 --> 04:04.600 So , some vendors don't have a cross-signing cert and they probably will not work for kernel-mode code signing, while others do. 04:05.100 --> 04:15.340 And so, that's usually the different levels is whether or not the vendor has, you know, deals with Microsoft or has a cross-signing certificate from Microsoft. 04:16.020 --> 04:21.000 Where would I look up that information if I wanted to find out more of a specific cert? 04:21.860 --> 04:27.020 Yeah, so, I think Microsoft has, like, a list of cross-signing certificates on just their... 04:28.360 --> 04:31.180 on MSDN, Microsoft documentation. 04:31.600 --> 04:33.180 Yeah, I found a page here. 04:33.180 --> 04:37.540 It's, like, cross-certificates for kernel-mode code signing. 04:38.340 --> 04:38.940 Gotcha. 04:38.940 --> 04:47.240 Okay, so, a follow-up question on that one would be, what's a good place to find leaked certificates were I to decide I needed one? 04:48.480 --> 04:58.460 Yeah, so, one of the places I mentioned that it's a good place to start for looking for leaked certificates is going to be on the... so, cheating-related forums. 04:58.460 --> 05:01.500 There's quite a few available there that some of them have been out for years. 05:01.620 --> 05:05.980 And I still think that, so, you can use them because a lot of the... 05:06.260 --> 05:12.880 a lot of antivirus simply don't have detections in place for these leaked certificates, even ones that, again, have been out for years. 05:12.960 --> 05:26.060 So, if you're out looking for a leaked certificate, look at game-hacking forums, look, like, search for leaked certificates, and then the game-hacking forums' names, and I can guarantee you that you'll find some. 05:26.060 --> 05:30.220 That's an interesting crossover that totally makes a ton of sense, but I was... 05:30.220 --> 05:33.580 it's not something that would have come to mind if I was ever going to go look for that. 05:35.380 --> 05:42.000 Yeah, especially considering who's making these things and, you know, who builds a lot of the games out there. 05:43.060 --> 05:44.900 RPTK has another question there. 05:44.900 --> 05:50.180 Can you explain a little more about why would the kernel accept a driver signed by an expired certificate? 05:50.920 --> 05:51.720 Yes. 05:51.720 --> 06:01.140 So, when you see a... let's say you go into the digital signatures section of a driver, and you see a certificate there, and it says, this certificate has expired. 06:01.140 --> 06:16.320 Well, what you're seeing there when you go to the digital signatures section is the result of winVerifyTrust, which is a user-mode function, whereas the kernel-mode code-signing policy is completely different, because that's in the kernel. 06:16.540 --> 06:25.760 So what you see returned by the winVerifyTrust function will, generally speaking, not always be what the kernel-mode code-signing policy checks for. 06:25.760 --> 06:30.640 And what I mean by that is, if the winVerifyTrust returns, this is expired, or this is revoked. 06:31.860 --> 06:41.440 Some reasons that a kernel code... that you might be able to still load that driver is because, at the time of signing, it was still valid. 06:41.720 --> 06:55.400 So, even without a timestamp, the kernel just assumes that, since this was at some point signed by a valid certificate, even if the certificate expired, it still should be loaded. 06:55.780 --> 06:57.500 That seems like a problem. 06:59.140 --> 07:00.180 Yeah, it seems like an overstatement. 07:00.180 --> 07:03.240 Yeah, I think it's mostly going to be for compatibility reasons. 07:03.260 --> 07:04.980 That's what I'd, I guess, assume. 07:04.980 --> 07:09.680 But it's speculation, given that I don't work for Microsoft, so I don't know the reasoning behind it. 07:09.680 --> 07:11.480 I'm sure there's a whole lot of history there. 07:11.980 --> 07:14.480 So we have another question. 07:15.620 --> 07:26.480 Trinsky is asking if you have any interest in creating a roadmap of resources, courses, or tutorials on your blog, a person can get to your level of reverse engineering competency. 07:27.360 --> 07:34.800 Yeah, so, for that question, it's mostly, you know, most of my, I guess, knowledge comes from just experience. 07:34.800 --> 07:40.940 And the best recommendation I can really give is to just try things out, you know, do CTFs. 07:40.940 --> 07:43.860 If you want to learn reverse engineering, you know, do the CTS. 07:44.140 --> 07:52.540 And really, you know, one of the ways that I go about, you know, looking for even projects or stuff to do, is I always stay curious. 07:52.540 --> 08:03.860 And what I mean by that is, if I see some weird functionality by a program I'm using, like in real life, on my machine, I will probably quickly try to check underneath of what's happening here. 08:03.860 --> 08:06.040 You know, why is it doing this one weird thing? 08:06.040 --> 08:10.980 And oftentimes, I've found that that can actually lead to other issues, like actual security issues. 08:10.980 --> 08:18.660 So if you're looking for what, you know, what projects to do or what to reverse, it's really just going to be the software you use in your everyday life. 08:18.660 --> 08:27.220 And I don't have any plans to do like a course or something on just, you know, tutorials on how to reverse engineer, for example. 08:27.220 --> 08:38.560 But it's going to be really going out and finding your own projects that you find interesting, so that you'll continue pursuing it. 08:38.560 --> 08:40.360 That's, I guess, the trick I did. 08:40.360 --> 08:45.440 The reason that I was able to learn so fast was because I always did stuff I was always interested in. 08:45.440 --> 08:48.280 And that was, you know, in specifically game hacking. 08:48.280 --> 08:51.360 I love games, and I'm bad at games. 08:51.360 --> 09:00.120 So I had a, you know, self-interest to continue reverse engineering these games, and figuring out how they work, and maybe how the anti-cheat works. 09:00.120 --> 09:09.980 And then you'll end up learning a lot from just, you know, trying out things, trying to reverse new programs you might have not had looked at before, stuff like that. 09:09.980 --> 09:11.580 Well, a quick step back then. 09:11.580 --> 09:15.420 So you said you watch as a program does something unusual. 09:15.420 --> 09:20.800 It's not exactly the words you used, but what types of unusual things are you expecting? 09:20.800 --> 09:24.540 What types of things would make the radar go off? 09:24.980 --> 09:32.320 So just to give you an example of like a vulnerability I found a few years ago, was in the software called Dell Support Assist. 09:32.320 --> 09:40.400 And how that worked was when I went to update my drivers, because I installed a new SSD, I needed drivers for that one machine. 09:40.400 --> 09:45.640 The website claimed to be able to update my drivers, but from the website itself. 09:45.660 --> 09:48.500 And I was like, how does a website update my drivers? 09:48.500 --> 09:58.120 Well, it turns out that Dell pre-installs this software that basically allows its own website to communicate with it and install stuff like updates. 09:58.120 --> 10:02.000 Well, that's kind of weird, you know, because you're allowing a website to have that sort of access. 10:02.000 --> 10:07.680 And then I reverse engineered it further, and I found that the restrictions there weren't quite as strong. 10:07.680 --> 10:12.360 And I found a way to bypass the restrictions the application had. 10:12.680 --> 10:17.660 But so the weird part there was, well, it's a website claiming to, you know, update my drivers. 10:17.660 --> 10:19.080 That's not normal. 10:19.120 --> 10:24.080 Websites, it normally can't just do it automatically update my drivers itself. 10:24.180 --> 10:26.560 You know, it might be something I have to install and do it myself. 10:26.560 --> 10:28.440 But so in that case, that was something weird. 10:28.440 --> 10:32.400 It's just basically finding these, you know, why does this thing happen? 10:32.400 --> 10:34.200 Why did they design it this way? 10:34.200 --> 10:40.760 And it's looking for those logical flaws in their, like, design or just their code itself. 10:40.900 --> 10:41.500 Yeah. 10:41.680 --> 10:44.660 So this is one that I've actually hit myself. 10:45.980 --> 10:50.080 RPTK2015 asking another question, like, keep them coming. 10:50.080 --> 10:52.540 This dude's pretty orchic. 10:52.540 --> 10:53.720 I don't know. 10:54.000 --> 10:57.940 Could you explain on how secure boot blocks some of the driver signing methods? 10:57.940 --> 11:01.160 I've definitely noticed that some drivers work with UEFI and some don't. 11:01.160 --> 11:03.260 And it's usually a driver signature problem. 11:03.260 --> 11:03.820 Yeah. 11:03.820 --> 11:20.980 So the main issue you're going to have with secure boot is if you're, like, going after using a leaked certificate or if you're buying your own certificate, the thing to consider is if the certificate was issued after July 29th, 2015, that's the cutoff date. 11:20.980 --> 11:27.400 Then you're going to need a EV certificate, so extended validation certificate on newer versions of Windows 10. 11:27.400 --> 11:36.640 So what that means is you're going to have to, basically, the certificate vendors that give you these code signing certificates have to, you know, do extra validation. 11:36.640 --> 11:42.520 And typically the certificate is given to you on, like, a USB drive instead of just sending you the private key file. 11:42.800 --> 11:56.140 So that, you know, for versions of Windows 10 that have secure boot enabled, you're basically preventing drivers that aren't signed with an EV certificate to be loaded just because that's the policy that follows. 11:56.140 --> 11:58.220 And in those newer versions. 11:58.580 --> 12:11.540 And so, but if your leaked certificate was released before, issued before July 29th, 2015, then it will still work on these newer builds with this secure boot protection, I guess you call it. 12:11.820 --> 12:14.520 There is sort of an extension of that. 12:14.720 --> 12:22.080 When I encountered this issue, there was a registry flag that you could set that was sort of bypassed it. 12:22.080 --> 12:23.380 It was unattended upgrade. 12:23.380 --> 12:25.760 It was from Windows 7 to Windows 10 upgrade. 12:25.760 --> 12:28.900 Did you try playing around with that to see if we might? 12:29.500 --> 12:36.560 I know, mostly because the leaked certificates, like you can just, the ones publicly available are issued before that cutoff date. 12:36.700 --> 12:40.300 So, I mean, it's like, there's like, almost all of them are issued. 12:40.300 --> 12:46.320 I mean, at least right now, you know, the leaked certificates I used was when I found it was issued before that date. 12:46.320 --> 12:50.400 So I haven't actually found the leaked certificate that was issued after it yet. 12:50.400 --> 12:55.740 So it's easy enough to find it that you haven't had to hunt down that possible other way to get it done. 12:57.080 --> 12:58.040 Right, right, right. 12:58.040 --> 13:03.360 And so there's quite a number of ways you can approach the problem of, you know, getting your driver loaded. 13:03.420 --> 13:12.040 And at that point, well, if you don't even need to look into, you know, other ways there, it's a non-issue, I guess you call it. 13:12.040 --> 13:20.740 But it's something to keep in mind, you know, going forward, once those leaked certificates start to run out, you're probably going to run into that issue of that date restriction. 13:20.740 --> 13:32.080 And at that point, I'd probably recommend the second method of loading a driver and abusing another legitimate driver that has been signed with like an EV certificate. 13:32.280 --> 13:40.040 But again, the problem with that, in my talk, I mentioned it is that you can run into a lot of stability issues when abusing another driver and trying to load your own. 13:40.040 --> 13:45.120 Just because there's oftentimes going to be stability concerns like race conditions. 13:45.840 --> 13:47.200 That makes sense. 13:49.980 --> 13:55.340 So Trunsky is asking, did you test your rootkit against any of the top EDRs? 13:55.840 --> 13:56.620 No, I didn't. 13:56.620 --> 14:01.720 But I took EDRs into consideration when designing the application. 14:01.720 --> 14:07.620 And for example, how I hook communication between the AFT driver and user mode applications. 14:07.620 --> 14:13.880 I always went for methods that would try to make it as expensive as possible to detect. 14:13.880 --> 14:18.600 Because I feel like that's the best approach is not security through obscurity. 14:18.600 --> 14:27.620 It's going to be, how can I make the antivirus have to go through a very expensive and time-consuming process to detect me? 14:27.620 --> 14:30.600 Because oftentimes they'll reconsider for those reasons. 14:30.600 --> 14:35.680 Or another perspective might be, how can I cause compatibility issues? 14:35.680 --> 14:43.120 If there's an application that already does these suspicious operations, maybe I can impersonate that application. 14:43.120 --> 14:48.260 And the antivirus would have to accept it because the legitimate application also does suspicious operations. 14:48.260 --> 14:52.120 Trigger bad false positives that they can't work around themselves. 14:52.440 --> 14:53.280 Right, right, right. 14:53.280 --> 14:55.720 Or it's very difficult to detect around that. 14:56.700 --> 14:58.600 Yeah, makes sense. 14:58.600 --> 15:04.440 Yeah, I feel like a lot of security is just making the other side do more work to get to the same goal. 15:06.980 --> 15:10.180 So RPTK asks another question here. 15:10.560 --> 15:17.260 There were some methods you were able to see that were not HVCI compatible. 15:17.260 --> 15:21.000 Can you please explain a little bit about HVCI mitigations? 15:22.280 --> 15:26.960 Yeah, so the HVCI, let me look what it stands for. 15:26.960 --> 15:30.620 It's like, yeah, virtualization-based protection of code integrity. 15:30.620 --> 15:33.500 So essentially what it does is it's a mitigation. 15:33.500 --> 15:36.720 If you have virtualization enabled, you should be able to enable it. 15:36.720 --> 15:48.240 That basically makes it so once the driver is loaded into memory, especially its executable sections, it can never again have those executable sections set to writable. 15:48.720 --> 15:58.420 The memory protections will never be able to be writable for that memory page because it's an executable section. 15:58.420 --> 16:06.920 So essentially it prevents code hooking, for example, or basically modifying the actual bytes of the driver's executable code. 16:07.780 --> 16:09.580 That makes sense. 16:12.260 --> 16:15.000 So I apparently missed this. 16:15.000 --> 16:19.420 Can you talk a little bit about your Peacemaker project and how it compares to Spectre? 16:20.680 --> 16:21.520 Sure. 16:21.520 --> 16:31.840 So Peacemaker was a proof-of-concept EDR that I wrote a few months ago, which was basically the opposite of what I'm doing now. 16:31.840 --> 16:35.960 Instead of writing a rootkit, I wrote a driver to detect malware. 16:36.240 --> 16:44.940 And the biggest difference between the two is the fact that one of them is a blue-teaming defense application while the other one is a rootkit. 16:45.260 --> 16:48.020 But how does it compare? 16:48.020 --> 16:54.020 Well, Peacemaker is going to be... I believe it's a little bit less efficient in general. 16:54.020 --> 17:01.400 And I followed a stricter code design policy for myself in this latest one. 17:01.400 --> 17:05.060 So, I mean, those are, I guess, how it compares. 17:05.060 --> 17:08.300 But they're two different projects for two different reasons. 17:10.100 --> 17:11.580 That's fair. 17:11.700 --> 17:17.200 So speaking about other projects and other places you might want to push this research... 17:17.800 --> 17:30.920 You already mentioned a little bit about a gap of the upgrade process for if you end up running out of certificates that were signed before the cutoff date. 17:30.920 --> 17:37.920 What other interesting things are out there for somebody who wants to do research in the same field that you're in? 17:37.920 --> 17:44.300 What would you recommend for somebody who is looking for a neat project to jump in and start working? 17:45.900 --> 17:52.440 So for, I guess, neat projects of where to start, it would first of all be... 17:52.440 --> 18:02.960 If you're interested in learning more about the Windows kernel or the internals of the Windows operating system, the best recommendation I have, besides experience, is going to be... 18:02.960 --> 18:12.580 Some of the books out there include the Windows internals, 7th edition is the latest one, that really goes into depth about the internals of the Windows operating system. 18:12.580 --> 18:21.200 But it's really going to be finding a way to make security interesting for you or make learning interesting to you. 18:21.200 --> 18:25.080 And that's the best way I can recommend, I guess, of how to... 18:25.080 --> 18:34.660 What's the best way to go about learning these difficult topics is to gamify it and is to incentivize the research itself. 18:35.920 --> 18:39.660 But yeah, in general, it's going to be... 18:39.660 --> 18:46.060 Most of your experience and knowledge is going to come from experience and just playing with things, trying new things. 18:46.060 --> 18:49.920 And for projects you could do, it varies. 18:49.920 --> 18:55.820 You can try looking at reversing drivers for vulnerabilities in their IOCTL interface. 18:55.820 --> 18:58.760 That's what I started with, at least. 18:59.020 --> 19:03.640 And you can try to find a way to abuse those drivers. 19:03.640 --> 19:06.260 Like the abuse legitimate drivers portion. 19:06.260 --> 19:13.760 If you're looking for some drivers to, I guess, that might be vulnerable, a lot of OEM drivers have security issues in them. 19:14.200 --> 19:15.820 I'm always shocked. 19:16.680 --> 19:18.980 I've become desensitized to it. 19:18.980 --> 19:24.100 Almost every OEM driver has something questionable in it. 19:24.380 --> 19:29.280 And I guess that's the place to start if you're looking for vulnerable drivers. 19:29.280 --> 19:36.720 It almost sounds like as you're approaching these projects, the new thing pops out at you. 19:36.720 --> 19:43.000 Maybe not from getting a depth into, hey, I'm going to find all of the drivers out there. 19:43.000 --> 19:47.040 But you're looking for other things, you're learning everything you can. 19:47.040 --> 19:51.820 And then the context for your next project kind of filters out from that. 19:51.820 --> 19:56.520 Or do you find that you have to go searching for what you're going to attack next? 19:57.640 --> 20:00.900 In general, not even just Windows Kernel stuff. 20:01.040 --> 20:04.720 I generally don't search for projects to do. 20:04.720 --> 20:07.520 Again, it's just finding stuff that might be interesting. 20:07.920 --> 20:12.940 If a program is doing something suspicious, there you go, that's a project right there. 20:12.940 --> 20:14.780 Find out why it's doing that thing. 20:14.780 --> 20:18.720 Or anything similar it's doing that could be called into question. 20:18.720 --> 20:28.380 But for Windows Kernel, one thing I do is I try to get part of the virus scanning platforms out there. 20:28.380 --> 20:30.560 One I am part of is hybrid analysis. 20:30.560 --> 20:33.940 And what I'll do is I'll occasionally search for drivers on there and download them. 20:33.940 --> 20:37.880 And just take a quick peek under the hood and you can see what's going on there. 20:38.280 --> 20:42.780 And so that's a good place to find these driver files if you're trying to search for them. 20:43.840 --> 20:45.080 Sorry, go ahead. 20:45.080 --> 20:47.800 I was going to say, are those already infected drivers? 20:47.800 --> 20:53.120 Or are these just tons of driver repository kind of thing? 20:53.280 --> 20:54.400 It's just a repository. 20:54.400 --> 20:57.520 These aren't necessarily bad drivers or vulnerable drivers. 20:57.520 --> 21:01.520 These are just potent, might be legitimate drivers as well. 21:01.520 --> 21:03.300 So it's just a driver repository. 21:04.760 --> 21:09.880 Have you looked at any other driver infections just to see how they are doing those hooks? 21:09.880 --> 21:15.700 Get basically similar ideas and work back from the attack side rather than being like, oh, this is weird. 21:15.800 --> 21:18.780 Instead of like, oh, this is an active attack, how are they doing this? 21:18.780 --> 21:21.020 Could this apply to other situations? 21:21.520 --> 21:26.120 So basically, do you look at malware or do you just look for new things in weird drivers? 21:26.700 --> 21:29.400 I look for new things in weird drivers. 21:29.500 --> 21:33.300 I don't specifically just look at drivers I know that are malicious. 21:34.460 --> 21:38.160 What I do is I'll reverse engineer, like I said, OEM drivers. 21:38.160 --> 21:39.900 And that's a starting point. 21:39.900 --> 21:40.940 Those are legitimate. 21:40.940 --> 21:44.660 And I'll just look into what I can find. 21:45.080 --> 21:49.440 First of all, it's like auditing attack surfaces, finding out what can you actually talk to. 21:49.540 --> 21:52.960 And then it's finding out now you know what you can talk to. 21:52.960 --> 21:58.120 What are the access controls in place that limit how much you can talk to the application? 21:58.200 --> 21:59.340 And it's going from there. 21:59.340 --> 22:04.420 It's that type of investigation of what can you access and how can you manipulate what you can access. 22:05.820 --> 22:06.820 Cool. 22:07.120 --> 22:11.560 So Truinsky asked a question that fits into kind of the direction I was pointing there. 22:11.560 --> 22:14.700 How do you balance your personal life and doing research? 22:14.700 --> 22:18.580 So you're clearly deeply involved in this. 22:18.580 --> 22:26.600 At what point is this all you do and how do you fit in the rest of the stuff you want to do with your life? 22:27.660 --> 22:28.440 Yes. 22:28.440 --> 22:31.420 So, well, specifically how I manage my time is going to... 22:31.940 --> 22:38.000 The big thing is, you know, over the summer I didn't do most of my most of my research was before I was in school. 22:38.040 --> 22:41.080 So before, you know, any internship or summer work. 22:41.200 --> 22:43.920 So it's going to be in school. 22:43.920 --> 22:46.040 I've just I've got too much free time. 22:46.960 --> 22:53.580 And so I just spend that time researching or, you know, I spend some of that time trying to research things. 22:53.580 --> 22:54.760 And it's different. 22:54.760 --> 22:57.600 You know, if you have a full time job, I don't know if I have a recommendation for you. 22:57.600 --> 23:01.960 Because a fact is, I know how like 40 hours a week is rough. 23:02.820 --> 23:06.260 You know, you'll probably be tired when you get home. 23:06.260 --> 23:09.660 So , you know, doing research then it can be difficult sometimes. 23:09.660 --> 23:12.340 And so I don't know if I have any recommendations specific to that. 23:12.340 --> 23:18.820 But in general, I try to use this free time I have as much as possible, like valuably, I guess. 23:19.100 --> 23:26.240 And since I have so much free time in school, you know, I dedicate a portion of that to doing my own research. 23:27.620 --> 23:28.860 That's awesome. 23:29.400 --> 23:38.480 So not that we want to point towards anything specific, but you did mention that there were some CTFs out there that are good training resources. 23:38.620 --> 23:44.860 Maybe this is a good time for you to say, do you have a favorite CTF for teaching this type of material? 23:44.860 --> 23:51.960 Other than, you know, you were talking about the Windows, Windows internal stuff that you can read the 30 pound book. 23:52.540 --> 23:54.280 So it's actually unfortunate. 23:54.280 --> 23:58.540 I find that a lot of CTFs don't really focus on Windows related challenges. 23:58.540 --> 24:04.000 It's really rare you'll see like an actual challenge that's dedicated about Windows internals. 24:04.000 --> 24:11.000 It's usually, you know, like if it's like a binary exploitation thing, generally speaking, I see it being like Linux application, right? 24:11.120 --> 24:13.800 Maybe running even on the ARM architecture. 24:13.880 --> 24:18.640 But I just rarely see I don't have any good CTFs to recommend for Windows related stuff. 24:18.640 --> 24:24.060 Just because oftentimes you probably won't see Windows related stuff. 24:24.280 --> 24:28.240 One of them I can I know I can mention that it's pretty good. 24:28.240 --> 24:33.680 It's I guess you call my favorite CTF overall is the Flareon reversing CTF. 24:33.700 --> 24:35.740 They have some really interesting challenges there. 24:35.740 --> 24:37.520 You know, it's not just going to be Windows stuff. 24:37.520 --> 24:43.760 It's going to be, you know, reversing a bunch of different architectures and applications, figuring out what they do. 24:44.280 --> 24:47.460 It's one of the favorite ones I participate in. 24:49.100 --> 24:53.980 Also, I mean, I guess that also kind of exposes like that CTF sounds awesome. 24:53.980 --> 24:57.900 It seems like any for anyone that's watching that there's a gap in the community. 24:58.080 --> 24:59.920 Windows CTFs. 24:59.920 --> 25:01.380 There you go. 25:03.100 --> 25:04.800 Next DEF CON talk. 25:06.720 --> 25:08.540 Well, so what's next for you? 25:08.540 --> 25:13.100 If you could pick which direction you would point for your for your next research topic? 25:15.260 --> 25:18.120 That's simple to say, I honestly don't have a next direction. 25:18.160 --> 25:19.920 I don't have the next project. 25:19.920 --> 25:22.520 I'm again, I kind of just go with the flow. 25:22.620 --> 25:29.300 I see it really is literally just looking at the everyday software I use. 25:29.300 --> 25:33.660 And then if I know that I just tend to notice stuff like this is weird. 25:33.660 --> 25:37.960 And that's how I how I go about doing it for this specific for my talk. 25:37.960 --> 25:44.160 I came up with it, I guess you could say is is our schools or our schools security club. 25:44.200 --> 25:50.960 A red team needed a new we wanted new malware to use against our best blue team competitors. 25:50.960 --> 25:55.360 So we run competitions where we do like we simulate a corporate environment. 25:55.360 --> 26:00.460 And you have a red team that tries to maintain persistence and a blue team that tries to kick you out. 26:00.460 --> 26:07.140 Blue teams also have like uptime and these challenges that they have to keep services up while the red team tries to mess with them. 26:07.140 --> 26:13.520 And so there was just a need there for me to develop some tooling against our top blue teamers. 26:13.820 --> 26:18.560 And so that's why I decided to look into this, you know, maybe like two birds with one stone type thing. 26:18.560 --> 26:20.100 You know, I thought it'd be interesting. 26:20.820 --> 26:25.600 So there's educational resources about rootkits out there like books, I know for sure. 26:25.720 --> 26:32.680 But I haven't really seen open source tooling around, you know, kernel level Windows rootkits out there. 26:32.680 --> 26:34.100 It's rare to see it. 26:34.100 --> 26:36.920 So I thought it would actually be a pretty interesting project. 26:38.920 --> 26:40.580 Looks like it turned out that way. 26:41.720 --> 26:44.380 Did you end up crushing the blue team with this? 26:45.740 --> 26:47.320 Yes, yes, definitely. 26:47.420 --> 26:58.140 I remember having conversations about, you know, like, when I suggested that I was abusing legitimate communication, explaining to these blue teamers how I was doing things. 26:58.200 --> 27:03.200 They were really confused about, you know, like, how would you abuse a legitimate port on my machine? 27:03.200 --> 27:06.900 Because they were looking for malware and I was using... 27:06.900 --> 27:09.760 So they have to have certain services uptime, right? 27:09.760 --> 27:12.380 So they have to have these services always up. 27:12.480 --> 27:16.320 So I was just using that fact to get into their machine. 27:16.320 --> 27:18.700 Because they could, like, take down that service. 27:18.700 --> 27:27.780 So even if they knew, and they didn't, that I was abusing these legitimate services for communication, you know, they would firewall everything except for those services. 27:27.780 --> 27:32.480 And I'd still be able to get access because, you know, communicating through their services. 27:32.480 --> 27:35.720 Yeah, it was a really fun time. 27:37.740 --> 27:43.320 One person is asking for a clarification on the CTF, like, where they can find it, the Flareon. 27:43.320 --> 27:47.500 They found flare-on.com. 27:47.720 --> 27:50.480 Yeah, it is the Flareon. 27:50.480 --> 27:53.700 Flare-on.com is the one I mentioned. 27:53.820 --> 27:57.340 And another question from RPTK2015. 27:57.340 --> 28:02.340 In the resources you proposed, ReactOS, could you explain a little bit about that? 28:02.980 --> 28:03.680 Yeah, sure. 28:03.680 --> 28:12.440 So ReactOS is essentially a bunch of engineers, reverse-engineered Windows kernel, and wrote it one-to-one. 28:12.440 --> 28:19.800 I wouldn't say, obviously, it's not one-to-one 100%, but it's actually, like, insanely accurate of the actual Windows kernel. 28:19.800 --> 28:22.760 So it's kind of like an open-source Windows kernel. 28:22.760 --> 28:27.740 You'll find that a lot of the functions in the actual kernel has been re-implemented in there. 28:27.740 --> 28:29.480 It follows the same structure. 28:30.000 --> 28:33.540 It's just quite literally an open-source clone of Windows. 28:34.000 --> 28:39.180 And it's an amazing resource because sometimes you'll find undocumented functions. 28:39.180 --> 28:40.420 You don't know what it does. 28:40.420 --> 28:49.560 And luckily, you can go to the ReactOS project and just take a look at the source of that because people have spent hours reversing that one function for you. 28:49.560 --> 28:54.780 Now, some of this is going to be outdated because the ReactOS kernel replicates the XP kernel. 28:54.900 --> 28:58.810 But still, the core functionality is going to be pretty similar. 29:00.500 --> 29:01.180 Excellent. 29:01.180 --> 29:03.980 So we are right at the end of our scheduled time. 29:03.980 --> 29:10.300 Is there anything else you'd like to impart upon us before we call it for the day? 29:11.320 --> 29:13.060 Yeah, I mean, not really. 29:13.060 --> 29:15.760 I appreciate everyone for coming out to my talk. 29:15.760 --> 29:28.760 Keep in mind that I'd like more red teamers to start using Windows kernel-level rootkits and going that route because I think there's some interesting... 29:29.320 --> 29:31.040 more advanced actors use it. 29:31.040 --> 29:39.820 And I feel like more red teamers need to start simulating those advanced actors that have been using these rootkit techniques for years. 29:39.820 --> 29:43.840 I just feel like we have such a good community for user-mode malware. 29:43.840 --> 29:49.040 But we rarely see much for kernel-mode, if that makes sense. 29:49.040 --> 29:58.140 So I guess that's the parting message is please start looking into it because the real adversaries out there already have this ready to go. 29:58.280 --> 29:59.380 That makes sense. 29:59.380 --> 30:09.440 Well, we'll get you to post all of your contact information into track one and let people find you wherever you tell them that they can find you. 30:09.440 --> 30:17.440 And I really appreciate that you gave us some time today to both give that presentation and then spend this time in the Q&A. 30:17.660 --> 30:22.700 So thank you very much and hopefully we'll see more from you soon. 30:23.240 --> 30:24.180 Yep. 30:24.180 --> 30:25.360 Have a good one. 30:25.360 --> 30:26.340 Thank you, Bill. 30:26.340 --> 30:26.980 Thanks, guys.