Do do do do do do do do do... Hey Bill, how do you pronounce your last name? Um, you're not going to be able to say it, but, uh, it's um, Damir Cuppo. Do you want me to try it?

I mean, I don't care. I won't get offended if you don't say it. Oh, okay. Looks like we are live. Yep, we seem to be live. Alright. Welcome everyone! I want to introduce Bill. 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. Sure, it's Demir Koppe. Alright, thank you for that. That was, instead of me murdering that, I wanted you to try it. So Bill did a talk on demystifying modern Windows rootkits. This is your opportunity to ask questions of Bill.

So there are a few questions already coming in through the TrackOne Live QA channel. Let's just go ahead and get started. So Aragon asks, what are the easiest features to find that might reveal a modern rootkit

via static analysis? I think a good place to start for a static analysis is going to be obviously the strings, because if they leave any debug strings behind or any unique strings for that specific binary, that's a good thing to maybe, you know, add to your signatures. But another opportunity is going to be the imports of the driver.

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, you know, with what's documented and with what's stable. So if there's any functions that it imports that is not stable or is it's very, you know,

it's just not really known about, it's something to look at. So anything undocumented that's getting pulled in, you're thinking that's going to be your opportunity for shenanigans on that side. All right. Was that pasties?

I was just going to say that potential shenanigans could still be legitimate. That's true. So next question from rptk2015. Did you actually find any p key when searching in Grey Hat? Mentioned in the context of using a legitimate key to sign your driver. Yes.

So I didn't, of course, crack any of them. But I mean, some of them were pretty obviously related to code signing. For example, I remember one that had like code signing in its name. So it was pretty clear that these were probably associated with code signing and that there was, it's potentially, if you crack it, you could use it for kernel mode code signing.

It all depends on the type of certificate it is and, you know, what vendor it came from and stuff like that. But I have definitely, I can confirm that I've seen potentially viable private keys on Grey Hat. Do you know if there are some keys that are like more trusted than others?

Like some that you can use to sign code, but there aren't trusted for like kernel level drivers or something like that? I assume like a Microsoft signing key is like gold, but. Yeah, yeah. So usually what, how it worked is that you have like these certificate companies that issue these code signing certificates and they work with Microsoft to get what's called

a cross signing certificate. 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. And so what you can do there is you can, some vendors don't have a cross signing cert

and they probably will not work for kernel mode code signing while others do. And so there's, 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. Where would I look up that information if I wanted to find out more of a specific cert or?

Yeah. So I think Microsoft has like a list of cross signing certificates on just their, on MSDN, Microsoft documentation. Yeah, I found a page here. It's like cross certificates for kernel mode code signing. Gotcha. 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? 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 cheating related forums. There's quite a few available there that some of them have been out for years.

And I still think that's how you can use them because a lot of the, for these leaked certificates, even ones that again have been out for years. So if you're out looking for a leaked certificate, look at game hacking forums, look at like search for leaked certificates and then the game hacking forums names.

And I'm, I can guarantee you that you'll find some. That's an interesting crossover that totally makes a ton of sense, but I was, it's not something that would have come to mind if I was ever going to go look for that. Yeah, especially considering who's making these things and, you know, who builds a lot of the games out there.

RPTK has another question there. Can you explain a little more about why would the kernel accept a driver signed by an expired certificate? Yes. So when you see, let's say you go into the digital signature section of a driver and you see a certificate there and it says the certificate has expired.

Well, what the, what you're, what you're seeing there when you go to digital signature section is the result of wind verified trust, which is a user mode function. Whereas the kernel mode code signing policy is completely different because that's in the kernel. So what you see returned by the wind verified trust function will,

generally speaking, not always be what the kernel mode code signing policy checks for. And what I mean by that is if the wind verified trust returns, this is expired or this is revoked. There are some reasons that a kernel codes, that you might be able to still load that driver is because at the time of signing, it was still valid.

So even without a timestamp, it, the kernel, it just assumes that since this was at some point signed by a valid certificate, even if the certificate expired, it's still, it still should be loaded. That seems like a problem. Yeah, it seems like an oversight.

I think it's mostly going to be for compatibility reasons. That's what I'd, I guess, assume, but it's, it's, it's speculation given that, no, I don't work for Microsoft, so I don't know the reasoning behind it. I'm sure there's a whole lot of history there. So we have a, another question. 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 reserve, reverse engineering competency. Yeah, so for, for that question, it's mostly, you know, most of my, I guess, knowledge comes from just experience and, and the best recommendation I can really give is to just try things out, you know, do CTFs.

If you want to learn reverse engineering, you know, do these CTFs. And really, you know, one of the ways that I go about, you know, looking for even projects or stuff to do is I'm, I always stay curious. And what I mean by that is if I see some weird functionality by a program I'm using on like in real life, on my living machine, I will probably

quickly try to check underneath of what's happening here. You know, why is it doing this one weird thing? And oftentimes I've found that that can actually lead to other issues, like actual security issues. So if you're looking for what, you know, what, what projects to do or what, what to reverse, it's really just going to be the software you use in your everyday life. 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. But it's going to be really going out and finding, finding your own projects at that, that you find interesting, so that you'll continue pursuing it. That's, that's, I guess, the trick I did.

The reason that I was able to learn so fast was because I always did stuff I was always interested in. And that was, you know, in specifically game hacking. I love games and I'm bad at games. 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.

And then you'll, you'll end up learning a lot from just, you know, trying out things, trying to reverse new programs you might've not had looked at before, stuff like that. Well, a quick step back then. So you said you watch as a program does something unusual. That's not exactly the words you used, but what types of unusual things are you expecting?

What types of things would make the radar go off? So just to give you an example of like a vulnerability I found a few years ago was in the software called Dell SupportAssist and how that worked was when I went to update my drivers, cause I installed a new SSD. I needed drivers for that one machine.

The website claimed to be able to update my drivers, but from the website itself. And I was like, how does the website update my drivers? Well, it turns out that Dell pre-installs the software that basically allows its own website to communicate with it and install stuff like updates. Well, that's kind of weird, you know, cause you're allowing your website

to have that sort of access. And then I reverse engineered it further. And I found that the restrictions there weren't quite as strong. And I found a way to bypass the restrictions the application had. But so the weird part there was, well, it's a website claiming to, you know, update my drivers. That's not normal in the websites. It normally can't just do it automatically update my drivers itself.

You know, it might be something I have to install and do it myself. But so in that case, that was something weird. It's just basically finding these, you know, why does this thing happen? Why did they design it this way? And it's looking for those logical flaws in their like design or just their code itself.

Yeah. So this is one that I've actually hit myself. Rptk2015 asking another question. Like, keep them coming. This dude's pretty orchic. I don't know. Could you explain on how secure boot blocks some of the driver signing methods? I've definitely noticed that some drivers work with UEFI and some don't.

And it's usually a driver signature problem. Yeah. 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.

Then you're going to need a EV certificate, so extended validation certificate on newer versions of Windows 10. So what that means is you're going to have to basically the certificate vendors that give you these certificates, the code signing certificates, have to, you know, do extra validation. And typically the certificate is given to you on like a USB drive instead of just sending you the private key file.

So 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 it follows in those newer versions. But if your leaked certificate was released before, issued before July 29th, 2015,

then it will still work on these newer builds with the secure boot protection, I guess you could call. There is sort of an extension of that. When I encountered this issue, there was a registry flag that you could set that was

sort of bypassed it. It was unattended upgrade. It was from Windows 7 to Windows 10 upgrade. And did you try playing around with that to see if we might like- I know mostly because the least certificates, like you can just, the ones publicly available are issued before that cutoff date. So I mean, it's like, there's like almost all of them are issued.

I mean, at least right now, you know, the least certificates I used was when I found it was issued before that date. So I haven't actually found the least certificate that was issued after it yet. So it's easy enough to find it that you haven't had to hunt down that possible other way to get it done? Right, right, right. And so there's quite a number of ways you can approach the problem of, you know,

getting your driver loaded. 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. But it's something to keep in mind, you know, going forward once those least certificates start to run out, you're probably going to run into that issue of that date restriction.

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. But again, the problem with that, in my talk, I mentioned it is that you cannot run into a lot of stability issues when abusing another driver and trying to load your own,

just because there's oftentimes going to be stability concerns like race conditions. That makes sense. So Trunski is asking, did you test your rootkit against any of the top EDRs? No, I didn't. I took EDRs into consideration when designing the application.

And for example, how I hook communication between the AFD driver and user mode applications. I always went for methods that would try to make it as expensive as possible to detect because I feel like that's the best approach is not security through obscurity. 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 because oftentimes they'll reconsider for those reasons. Or another perspective might be how can I cause compatibility issues? Like if there's an application that already does these suspicious operations, maybe I can impersonate that application and the antivirus would have to accept it because

the legitimate application also does suspicious operations. Trigger bad false positives that they can't work around themselves. Right, right, right. Or it's very difficult to detect around that. Yeah, it makes sense. Yeah, I mean, I feel like a lot of security is just making the other side

do more work to get to the same goal. So RPTK asks another question here. There was some method you're able to, let's see, that were not HVCI compatible. Can you please explain a little bit about HVCI mitigations?

Yeah, so the HVCI, let me look what it stands for. It's like virtualization based protection of code integrity. So essentially what it does is it's a mitigation. If you have virtualization enabled, you should be able to enable it. That basically makes it so the once the driver is loaded into memory,

especially its executable sections, it can never again have those executable sections set to writable. The memory protections will never be able to be writable for that memory page because it's an executable section. So essentially it prevents code hooking, for example,

or basically modifying the actual bytes of the driver's executable code. That makes sense. So I apparently missed this. Can you talk a little bit about your piece nature project and how it compares to Spectre?

Sure. So Peacemaker was a, basically it was a proof of concept EDR that I wrote a few months ago, which was basically the opposite of what I'm doing now. Instead of writing a rootkit, I wrote a driver to detect malware. And the way, I mean, 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. But when it, how does it compare? Well, Peacemaker is going to be, I believe it's a little bit less efficient in general. And I followed a stricter code design policy for myself in this latest one.

So, I mean, those are just how it compares, but they're two different projects for two different reasons. That's fair. So speaking about other projects and other places you might want to push this research, 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, what other interesting things are out there for somebody who wants to do research in the same field that you're in? What would you recommend for somebody who is looking for a neat project

to jump in and start working? So for, I guess, neat projects of where to start, it would, first of all, be, if you're interested in learning more about the Windows kernel or the internals of the Windows operating system, the best recommendation I have is, besides experience,

is going to be, some of the books out there include the Windows internals. Seventh edition is the latest one that really goes into depth about the internals of the Windows operating system. But it's really going to be finding a way to make security interesting for you or make learning interesting to you.

And that's the best way I can recommend, I guess, of what's the best way to go about learning these difficult topics is to gamify it and is to incentivize the research itself. But yeah, in general, it's going to be, most of your experience and knowledge is going to come from experience

and just playing with things, trying new things. And for projects you could do, it's really, it varies. You can try looking at like reversing drivers for vulnerabilities in their iOctal interface. That's what I started with, at least. And you can try to find a way to abuse those drivers

like the abuse legitimate drivers portion. If you're looking for some drivers to, I guess, that might be vulnerable, a lot of OEM drivers have security issues in them. I'm just always shocked. Just look, I've become desensitized to it. Just almost every OEM driver has something questionable in it.

And I guess, so that's the place to start if you're looking for vulnerable drivers. It almost sounds like as you're approaching these projects looking, the new thing pops out at you, maybe not from getting a depth into,

hey, I'm going to find all of the drivers out there, but you're looking for other things, you're learning everything you can, and then the context for your next project kind of filters out from that. Or do you find that you have to go searching for what you're going to attack next? So in general, not even just like Windows kernel stuff,

I generally don't search for projects to do. Again, it's just finding stuff that might be interesting. If a program is doing something suspicious, there you go, that's a project right there. Find out why it's doing that thing. Or if there's anything similar that it's doing that could be called into question. But for Windows kernel, one thing I do

is I try to get part of the virus scanning platforms out there. Like one I am part of is like hybrid analysis. And what I'll do is I'll occasionally search for drivers on there and download them and just take a quick peek under the hood and you can see what's going on there. And so that's a good place to, I guess,

find these driver files if you're trying to search for them. Sorry, go ahead. I was gonna say, are those already infected drivers or are these just like a reference or are these just like tons of driver repository kind of thing? Just a repository. These aren't necessarily bad drivers or vulnerable drivers. These are just potent, like might be a legitimate driver as well.

So it's just a driver repository. Have you looked at any other driver infections just to see how they are doing those hooks to like get basically similar ideas and work back from like the attack side rather than being like, oh, this is weird. Instead of like, oh, this is an active attack. How are they doing this? Could this apply to other situations?

So basically, do you look at malware or do you just look for new things in weird drivers? I look for new things in weird drivers. I don't specifically just look at like drivers I know that are malicious. What I do is I'll reverse engineer, like I said, OEM drivers and that's a starting point. Those are legitimate.

And I'll just look into what I can find. First of all, it's like auditing attack surfaces, finding out what can you actually talk to. And then it's finding out now you know what you can talk to, what are the access controls in place that limit how much you can talk to the application. And it's going from there. It's that type of investigation of,

what can you access and how can you manipulate what you can access. Cool. So Truinsky asked a question that fits into kind of the direction I was pointing there. How do you balance your personal life in doing research? So you're clearly deeply involved in this. At what point do you,

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? Yes. So, well, specifically how I manage my time is going to, the basic thing is, over the summer, I didn't do most of my, most of my research was performed while I was in school. So before any internship or summer work.

So it's going to be in school. I've just, I've had too much free time. And so I just spend that time researching. I spend some of that time trying to research things. And it's different. If you have a full-time job, I don't know if I have a recommendation for you because the fact is I know how,

like 40 hours a week is rough. You know, you'll probably be tired when you get home. So doing research then it can be difficult sometimes. And so I don't know if I have any recommendations specific to that, but in general, I try to use this free time I have as much as possible, like valuably, I guess.

And since I have so much free time in school, you know, I dedicate a portion of that to doing my own research. That's awesome. So not that we want to point towards anything specific, but you did mention that there were some CTFs out there that are good at training resources. Maybe this is a good time for you to say,

do you have a favorite CTF for teaching this type of material? Other than, you know, you were talking about the windows internal stuff that you can read the 30 pound book. So it's actually really unfortunate. I find that a lot of CTFs don't really find focus on windows related challenges. It's really rare, you'll see like an actual challenge

that's dedicated about windows internals. It's usually, you know, like if it's like a binary exploitation thing, generally speaking, I see it being like a Linux application, right? Maybe run even on the ARM architecture. But I just rarely see, I don't have any good CTFs to recommend for windows related stuff, just because oftentimes you probably won't see

windows related stuff. One of them I can, I know I can mention that it's pretty good. It's, I guess you call my favorite CTF overall is the flare on reversing CTF. They have some really interesting challenges there. You know, it's not just going to be windows stuff. It's going to be, you know, reversing a bunch of different architectures

and applications, figuring out what they do. It's one of the favorite ones I participate in. So also, I mean, I guess that also kind of exposes like that CTF sounds awesome. It seems like any, for anyone that's watching that there's a gap in the community, windows CTFs. There you go.

Next Defcon talk. Well, so what's next for you? If you could pick which direction you would point for your next research topic. That's simple to say. I honestly don't have a next direction. I don't have the next project. I'm, again, I kind of just go with the flow.

I see, it really is literally just looking at the everyday software I use. And then if I noticed, I just tend to notice stuff. Like this is weird. And that's how I go about doing it. For this specific, for my talk, how I came up with it I guess you could say is our schools

or our school's security club, a red team needed a new, we wanted new malware to use against our best blue team competitors. So we run competitions where we do like we simulate a corporate environment and you have a red team that tries to maintain persistence and a blue team that tries to kick you out.

Blue team is also have like uptime and these challenges that they have to keep services up while the red team tries to mess with them. And so there was just a need there for me to develop some tooling against the kids, our top blue teamers. And so that's why I decided to look into this, maybe like a two birds with one stone type thing. I thought it'd be interesting. No one's, so there's educational resources

about rootkits out there, like books, I know for sure. But I haven't really seen open source tooling around, you know, kernel level Windows rootkits out there. It's rare to see it. So I thought it would actually be a pretty interesting project. Yeah. Looks like it turned out that way.

Did you end up crushing the blue team with this? Yes, yes, definitely. They did not exist. 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. They were really confused about, you know,

like how would you abuse a legitimate port on my machine? Because they were of course looking for malware and I was using, so they have to have certain services uptime, right? So they have to have these services always up. So I was just using that fact to get into their machine because they could like take down that service. And 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. And I'd still be able to get access because, you know, going and communicating through their services. So yeah, it was a really fun time. One person is asking for a clarification on the CTF,

like where they could find it, the Flareon. They found flare-on.com. Yeah, it is the Flareon, flare-on.com is the one I mentioned. And another question from rptk2015, in the resources you proposed ReactOS,

could you explain a little bit about that? Yeah, sure. So ReactOS is essentially a bunch of engineers, reverse engineer to Windows kernel and wrote it one-to-one. I wouldn't say obviously it's not one-to-one a hundred percent, but it's actually like insanely accurate of the actual Windows kernel. So it's kind of like an open source Windows kernel.

You'll find that a lot of the functions in the actual kernel has been re-implemented in there. A lot, it follows the same structure. It's just quite literally, you know, an open source clone of Windows. And it's an amazing resource because sometimes you'll find, you know, undocumented functions, you don't know what it does.

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. Now, some of this is going to be outdated because the ReactOS kernel replicates the XP kernel, but still the core functionality is going to be pretty similar.

Excellent. So we are right at the end of our scheduled time. Is there anything else you'd like to impart upon us before we call it for the day? Yeah, I mean, not really. I appreciate everyone for coming out to my talk. You know, keep in mind that rootkits are,

I'd like more red teamers to start using Windows kernel level rootkits and going that route because I think there's some interesting, you know, more advanced actors use it. And I feel like more red teamers need to start, like simulating those advanced actors that have been using these rootkit techniques for years. I just feel like, you know, we have so much,

we have such a good community for user mode malware, but we rarely see much for kernel mode, if that makes sense. 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. That makes sense. 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. And I really appreciate that you gave us some time today to both give that presentation and then spend this time in the Q and A. So thank you very much.

And hopefully we'll see more from you soon. Yep. Have a good one. Thank you, Bill. Thanks, guys.