Stolen Laptops, Modern physical access attacks with Pierre Nicolas Allard Coutu

All right, welcome back everyone. Uh, not sure if housekeeping was done. Uh, reminder, no drinks in the theater, please and thank you. We want to be invited back next year. Uh, so Ryan, thank you very much for everything. Uh, and warming up the crowd. So, my bad dad joke, hopefully it doesn't bomb, is why did the hackers spend the day at the local cafe? He wanted to enjoy cookies while he was hacking the Wi-Fi. It bombed. It's fine. Uh, okay. So, welcome back. It's my privilege to introduce today's speaker, Pierre Nicolola Allar Kutsu, a leading voice in offensive security research with deep expertise in hardware and firmware exploitation. Pierre has spent se several years uh dissecting the

vulnerabilities that arise when attackers gain physical access to devices and his work continues to push the boundaries of what we understand about modern threat tactics. Uh today he'll be presenting stolen laptops, modern physical access against hardware and firmware part is how I'm calling it. Uh this session dives into cutting edge techniques used to compromise laptops through direct memory access exploitation. Explores the limitations of TPM based encryption and showcases live demonstration of hardware exploits. The talk builds on a previous work uh with fresh insights, updated demos and advanced countermeasure evasion strategies tailored for 2025. So please join me in giving a warm welcome to Pierre. [applause] All right. Can everybody hear me? Yes, I can hear myself. Okay. Uh, so welcome

besides uh to my talk. Uh, it is a privilege to be here for the second year in a row. If you were here last year and you caught my talk on the same subject, um, don't worry, there's a lot of new material for this year, but if you were not here last year, we are going to recap some of the stuff that we went over last year as well in a more condensed format. So, uh, yeah, it should be fun. We're going to go from zero to 100 in terms of tactics against modern laptops. So, if you've never heard of any of this before, there should be enough of the introductory stuff for you to follow. And if you do

uh you know interact with this sort of material on the regular, hopefully there's some novel stuff for you to uh be excited about. So, let's get started. Uh my name is Pierre. I am a senior penetration tester at Bell Canada. I've been there for about five years now and I've been doing pentest for about eight years. Uh I do a lot of different types of pentest. So internal external red teams. I do malware development for our red teams. And recently I have started to work a lot on physical penetration testing which is what we're going to talk about today. So uh those are my cats by the way and uh there's my GitHub and a lot less interesting my LinkedIn.

So let's get right into the type of engagement that we are here to discuss. We as a pentest service uh offerer we uh package this into an engagement type called stolen laptop scenarios. The objective of a stolen laptop scenario for the uh person purchasing the service is to understand the potential impacts of a lost asset uh versus moderately advanced threat actors. So all organizations these days have laptops. Everybody has employees with laptops. They're always on the move and they present an opportunity for people to come and steal them or even just interact with them while they're unattended. And so it is an interesting attack surface that is not often touched upon. And I find that to be a shame

because it's a very interesting pentest uh sphere and domain. Even other competent pentesters often tell me, you know, I'm not interested in physical pentesting because, oh, it's encrypted. There's nothing to do. I'm not going to waste my time with this. Well, it's not that simple and there's a lot more depth to it. And hopefully you'll get a taste of that today. So, when we do these uh scenarios, we have uh several assumptions that we start with. The first is that as an attacker, you have unlimited physical access. This means that you can open up the chassis, you can void warranties, you can do what you want to have fun with that asset. Uh, typically soldering is out of scope and

we won't talk about any soldering today. Um, and but there are ways around that. So any other type of physical interaction with the asset, the motherboard, the components is all perfectly legit. Uh, we have reasonably unlimited time to perform the attacks. That just means that we don't have to get it right on the first try. When we're doing this as a pentester, we can make a mistake and we can do it again or we can, you know, try multiple times in a row until we succeed. Uh and finally, the computer has been used by a real employee. So someone has logged into that computer at least once, meaning it's been onboarded to the various Windows systems. Typically, Active

Directory credentials have been used and the computer has been functionally prepped so that it represents a good legitimate target. Uh there's a few things that we assume we won't be doing. One of them is brute forcing encryption keys. That's not what we're talking about today. And we are also not going to assume that the computer is on when it's stolen. That's an unreasonable assumption and we need to kind of abstract that away. So there's no cold boot attacks or anything like this. Uh we are assuming that we've taken possession of the laptop and it is in a powered off state and that's where we're starting from. So uh what do we get if we succeed? We're going to start at the

end and use it to justify why you guys are going to sit here for an hour. So uh we get code execution as system if we manage to compromise the computer. That means we can do anything we want on that computer. It is ours. We are god. We can access all of the files. We can uh extract credentials. We can get stuff like recon data like emails and all sorts of other types of information that can be used for further social engineering or other types of compromise. But most importantly, we're looking to do something called a scope change. So what we want to do is we want to extract from memory or from secret stores on that computer credentials that

give us access to some other scope of systems. In today's world, that typically takes the form of either browser cookies, so giving us access to cloud environments. either we're going to look for primary refresh tokens or uh sorry primary access tokens or refresh tokens that sort of stuff or we can also extract credentials from uh related to active directory and windows authentication. So we can get things like NLM hashes, keraros tickets and so on and so forth. Whether those are related to cloud accounts, active directory accounts, machine accounts, you know, users, service accounts, or even local computer accounts, they often give us an opportunity to perform lateral movement and move to other systems and assets once we've

compromised that one stolen laptop. And this is something that IT administrators and organizations in general don't off don't consider uh correctly. the potential um the the potential I'd say uh expansion of the attack surface once you've compromised that single laptop and and this is why we are interested in doing this at all. So I can't talk about physical attacks without talking about the number one uh countermeasure against them which is encryption at rest. In 2025 almost all of your Windows computers are encrypted at rest using something called Bit Locker. This means that the data that's stored on the drive itself uh is encrypted at all times when the computer is powered off and it will

decrypt in order to power on the computer. So to decrypt it, we use keys, right? Decryption keys. And the standard practice for decryption keys in 2025 is to use something called a TPM. TPM is a trusted platform module. It is either a dedicated or firmwarebased chip. Doesn't really matter what the difference is for you guys, but there it's it it's more and more a firmwarebased chip. Either way, it is a it is a hardware component that purpose is to store large encryption keys that you would not be able to remember in your mind. So instead of remembering some code 1 2 3 4, it's like a 256-bit, you know, co uh encryption key. And that's a lot more

robust against brute forcing. So the TPM is usually what is used to decrypt the drive when you power on the computer. And this has certain implications for users. One of them, and users love this, is that they don't have to do anything to decrypt the computer. You power it on and I call these autoloading or auto decryting Windows uh configuration where it is encrypted at rest but when you power it on it just automatically goes to the Windows loon screen. You don't have to do anything as the user. It was encrypted but the TPM took care of everything transparently. You didn't have any interaction with that blue bit locker screen uh and you now have the

opportunity to log in. So as an attacker this this behavior this autoloading auto decryption behavior is a very interesting attack surface that we are not going to ignore. Now of course the computer is encrypted at rest and has all of the traditional protection you would expect from that. You can't just like grab the computer, take the drive out, pop it into your computer and then go and modify things. But we don't need to do that. What we are interested in is attacking memory. So we are going to talk about the way we do this and it is through a type of attack called a DMA attack or a direct memory access attack. Direct memory access is uh basically

when a peripheral device wants to read and write to system memory without passing through the CPU in the traditional sense. Why does this exist? Uh it exists because today peripheral devices are very high performance. So you can think of things like GPUs, SSDs, WAN cards, LAN cards, etc. Uh they're very fast and they're getting faster and faster every every year. um they're so fast that if you want to have it your peripheral device perform some sort of calculation and then move that data to the actual computer to get use out of whatever computation it did, uh the bus system becomes the bottleneck. And so they computer manufacturers needed to conceive direct memory access in order

to remove that bottleneck and allow the peripheral device to go ahead and change things directly in system memory without passing through any additional components. And it is implemented through a technology called PCI express or PCIe. Uh PCIe or peripheral component interconnect express is a high-speed serial bus expansion network uh which allows peripheral devices to communicate with system memory directly. That's the whole point. It's got its own protocol. It's got its own packet forms and it's a kind of a network topology sort of setup. I won't go into too much detail of how this works, but essentially it is a system that allows a peripheral device to communicate with memory and read and write to arbitrary addresses. Now, if

that made you feel a little excited, uh it should because reading and writing to arbitrary memory is in fact a very powerful thing. So, the idea behind DMA attack is to use an intentionally malicious device called a screamer and we're going to plug that into our target laptop and we're going to use it to do a direct memory uh or an interaction with memory directly. and we will read and write to the kernel and do all sorts of nasty things. And we basically instant pone the computer. Now, we will explain that in more detail, so don't worry. To start, we need to know how we're going to connect to this thing that I just explained, right? PCI Express. How do we

connect to it? Well, we're going to use one of these here, ports. Okay, these are your typical PCIe ports. They come in different uh amount of X, which is just the amount of data lanes that there are. So, the higher X is going to be faster. It has more input output capabilities, but these are all basically compatible if they fit. And you're never going to find these on a laptop in 2025. You will find a different PCI Express form factor. And there are many. There's Thunderbolt, which is very common. A lot of people know about Thunderbolt. Uh there's also mini PCIe. There's uh Express card and the most common one, M.2 or M2. These are all different flavors of M2 ports.

And M2 is essentially just a form factor of PCI Express. It's one of many different ways that we can connect to the PCI Express network. So on a modern laptop here we've got a 2024 some manufacturer which I won't mention. Um and we've got uh we've opened up the back and we can see immediately there is an M2 port which is free. So when we do a physical pen test we're always going to be opening up the chassis and we're always going to be looking for some way to interact with PCI Express network. Almost always we will find a free port. But if we can't find a free port we can also disconnect whatever was connected to it and make it

free by removing something that we don't need for the course of the pentest. I often remove a Wi-Fi card uh because I don't need Wi-Fi while I'm doing a physical pen test in this particular uh way. And so I'll disconnect whatever I don't need. Now I have a free port and I can use that. What do we connect with? I told you what we're connecting to. What do we connect with? This is the main culprit. This is called an FPGA or field programmable gate array. It is a basically a fancy calculator that uses a whole bunch of different logic gates to perform uh parallel processing at high speeds. And we are going to use it.

These these are not expensive. They're like $1 to $200 on average. They're getting less expensive uh more and more these days. But we are going to use this to attack the computer. Now, obviously, we can see that that uh the male uh connector is not going to fit in the M2 ports that we were just talking about. So, we typically going to need a series of adapters which are all very low cost uh to basically MacGyver our way into getting it to fit. Uh all of these different like PCIe, mini PCIe, M2, they're all essentially intercompatible. you might have to provide voltage uh separately or figure out some weird physical way to get it to connect. But

once you do have a connection, you can pretty much do the same things in all of these cases. So that's uh our hardware setup. Now for our software and firmware, we are going to use a uh a framework called PCI Leech. PCI Leech is the de facto industry standard for direct memory access attacks and research. And it was created by a researcher whose name is Alf Frisk. Uh all of this is open source. It's well documented on his GitHub. He's talked at various conferences and I encourage everyone to check out this uh these tools. So what we're going to do is we're going to take the PCI leech software and put it on our attack

computer and then we're going to take the PCI leach firmware and put it on that FPGA board. We're going to plug FPGA board into the target and we're going to control our board remotely with our computer and we can do all sorts of exploitation that way. So this uh this framework comes with features and functionalities out of the box that allows us to do typical exploitation things like removing passwords, creating processes, dumping processes, that sort of stuff. And so um we are going to hook everything up and it's going to look like this. You've got your target laptop usually in some sort of weird position so that you can get things to fit and then your actual attacker laptop which

is connected to the board. And once we boot that computer, we win. We literally instantly win if the computer boots and there are no additional countermeasures. Exploitation is going to look like this. I'm going to try and make this a little bit more concrete. Um, so PCI leach exploitation usually occurs in two steps. The first step is what is referred to as implanting a kernel module. So if you are familiar with other types of uh remote access tools, maybe like you've messed with mutterper like metas-loit or cobalt strike or something like that, you can think of this as analogous to getting a beacon or an initial implant. Basically the first stage is we're going to write a special

piece of code to the kernel which acts as a shell code handler and it's going to sit there and wait for us to send it additional commands and then we're going to send it additional commands in the form of shell code. It's going to execute them and we basically have this little machine which can run whatever we want it to run. So usually we're going to do things in two steps. One we put that initial handler and then we send it whatever we want it to do. So the first box up there we see that we've implanted our shell code handler and we get the address that it has been written to. And then in the second uh command, we're

going to send it the ps list module, which is basically shell code that is going to list all the processes on that computer. And we get a process list. Here we have something a bit spicier. So we're doing the same thing, but instead of uh sending it a module to list processes, we are sending it a module to create one. We're going to create a cmd process as a child of spool sv. It's going to run as system, and we get execution of arbitrary code as system. So it's I mean this it's not incredibly demonstrative but it's ve it's really like two commands and you're in full control of that computer if there are not additional countermeasures in place.

Now it is not that simple in 2025 because everybody knows about this and they have started to implement various defensive technologies. So we are going to talk now about those defensive technologies and we're going to go into quite a bit of detail so I'll try not to lose you. Um, yeah, I like to split this and and this has not been like very well researched or documented or described. So, this is like my sort of ad hoc description. I don't know if it's the most accurate, but it does in my opinion uh concisely illustrate the concept of various layers of defense. So, in my estimation, there are three layers of defensive technologies that are that are

important for us to consider. There's the operating system layer defenses, there's the firmware defenses, and there's the physical defenses. And we're going to go through all three of those and the interconnectedness and relationship between them. So starting with the operating system, uh there's two flavors of operating system level countermeasure that we need to care about when we're trying to do this sort of attack. The first is virtualization based security and the second is kernel DMA protection. Um virtualization based security is quite a complex topic and I uh I I can't do it justice, you know, summarizing it here in I guess 30 seconds, but I will try. uh VBS is the combination of various different

security mechanisms that are implemented in Windows in modern Windows operating systems that serve uh that leverage HyperV essentially. So they are leveraging the capacity of the computer to do virtualization. If you're familiar with modern Windows implementation uh you know that the the abstraction layer between virtual memory addresses and physical memory addresses which is typically handled by the kernel that knows how to dreference things is now more complex than that. There's actually another layer now because now we everything is virtualized. Your entire kernel is in a VM and there's multiple VMs which are actually separating different important processes based on their integrity level. And uh the the thing that's in control of all of this is the hypervisor. Now it's not the

kernel anymore. In fact, the colonel doesn't even know what the real physical address of something is. It it thinks it knows, but it's actually the hypervisor which is going to go and translate that. And all of these like ex all of this extra complexity is implemented by the CPUs. So the CPU needs to support this sort of extra abstraction layer through things like extended stack pointers and various other cool technologies. Intel has their own thing and AMD has their own thing, but it's all pretty much the sameish. Uh we're adding we're using virtualization to create segmentation between different integrity level processes and and subsystems. And so all of VBS which includes hypervisor based code integrity. It includes secure

kernel and like isolated user mode and all that stuff for our purposes. What we need to understand is that this is going to prevent our shell code from working. Now that is a super simplification but it's going to stop the shell code from working. And we'll see why later. From our perspective as a physical attacker we don't need to understand all of that complexity. We just need to turn this off somehow. So we will try to do that later and we'll succeed. But we we will uh we'll contend with it by just removing it. We need to understand that it will stop our shell code from working. The second thing, kernel DMA protection. This is also using

virtualization, but in a slightly different way. This is going to make it so that our malicious peripheral device, the the screamer board, the red board that we saw is just not going to work. We're going to plug it in. It's going to try and read and write to some memory that we're interested in, and we can't. But we'll see how and why. But uh that's the main two operating system layer uh defenses. Now the two flavors of firmware countermeasure are uh the MMU and DMA protection. So the MMU is analogous to a regular MMU in that it is a table of translations between virtual and physical addresses. Uh this construct is going to allow us to apply

access control to a device that is attempting to read and write to arbitrary places. And we can say, "Oh, you're not supposed to write there. You're the driver for this uh this Ethernet card. I don't want you to write to the kernel and that doesn't make sense and so we can we can apply access control through this structure. Uh this is crucially controlled by features that are implemented in the CPUs. In Intel's case, we're talking about something called VTD or virtualization technology for directed IO. It's easier to say VTD. Uh and in AMD's case, there's AMDVI, sometimes called AMDV, which is basically the same thing. It is the implementation of that OMMU for that processor. Then there is DMA protection.

DMA protection sounds an awful lot like kernel DMA protection that we just saw and I hate that. But uh yeah, someone decided this name was appropriate. Uh so this is not the same thing as kernel DMA protection. This is enabled in the firmware and it supplements kernel DMA protection. So in a normal case where you don't have this enabled and you have just kernel DMA protection enabled, you try to attack with your screamer board, it won't work. If this is enabled and you do the same attack, it's going to cause a blue screen. So the addition like B what this adds is it's instead of just not working it's going to throw a fault when it's detected which is more

hardcore and is actually going to stop an attacker more effectively than nothing happening right so that's that's how uh that's how DMA protection works it goes and adds on to the existing capabilities now we're going to talk about the three flavors of physical countermeasure uh there's bit locker plus TPM BIOS password and hardware whitelisting now as you can see from my meme these are not all created equal um I do I do not consider hardware whitelisting to be a legitimate security feature. It is anti-consumer. It's security through obscurity. There's a lot of problems with it and it doesn't work. So, uh I will tell you how to bypass it, but I will not include it in

my graphs that have all of the different security features because I don't consider it to be a security feature. Okay. So, uh let's let's continue. Here's the first graph. Oh, I'm glad the colors work. Okay. Because it doesn't that colors don't always work in this. Okay. So this is my attempt to uh summarize what I just said and show the relationship between these various things. And we're going to add to this graph. It'll change. It doesn't have everything in it right now. Uh you can see from the legend there's basically uh two main types of arrows. There's the dotted arrows and the solid arrows. The dotted arrows represent a protection relationship and the solid arrows

represent a requirement relationship. So just as an example here we see that Windows 10 at the bottom is protected by virtualization based security but virtualization based security needs virtualization technology to be enabled in the firmware. So that's what the different types of arrows mean. Now just looking at this really quick we can see that there's a few things that are kind of unprotected and would make good uh initial attack uh steps and we're going to we're going to talk about that. So, let's assume that we're trying to compromise a laptop that has all the modern stuff enabled. Okay. Uh, it's got uh the it's using a TPM for decryption. It's got Bit Locker. It's got VTD

enabled, DMA protection. Okay, cool. Where are all of these things configured? Well, the answer is Yuthi. And if these things are configured in Yui and you have unlimited physical access, why don't you just boot into Yuthi and turn them off, right? We can literally see them. There's like two switches right there. All we have to do is, you know, boot into BIOS and turn off those two things and Bob's your uncle. We're ready to go. Well, it's it's not that simple. It can be, but it's usually not that simple. So, we need to talk about BIOS/ EU security. I am going to use BIOS and UI interchangeably in this talk um because they themselves use it interchangeably

in the documentation. This is a screenshot of Yui asking for your BIOS administrator password. So, it's not fair. Um, I know they're not exactly the same thing, but they refer to each other as uh interchangeable terms. So, I might say BIOS when in fact I am talking about Yuthi modern preboot environment. Okay. So, to prevent an attacker from going in there and disabling things, you can put a BIOS password. Shocked Pikachu because not enough people do this. Um, here's your regular interaction between the different layers of countermeasure. Here's how much better that looks when you add a BIOS password. Notice how all of those things are now protected by something and before they were not. This

adds a lot of value to your overall physical uh protection let's say status. Um and we will we will talk about what we can do with the BIOS password and all of this. Um but first we need to talk about how BIOS is implemented. BIOS is firmware data which exists on a chip. That type of chip is called an EPROM chip or an electronically erasable programmable readonly memory. Uh it is a type of chip that can be read or completely wiped and rewritten. Uh so these chips um usually there's two which are attached to the motherboard which serve different purposes. One of them is the embedded controller and the other one is the main BIOS and they're usually

connected to SPI or ESPI bus or something. Um, but they're almost always the same in that it's just a it's just a 32 megabyte or 64 megabyte chip which contains static data. And the computer is going to read that data when it boots. Here, here's a view of a modern laptop with the two chips identified. We can get a little closeup of the chip. There are usually these 8 foot chips uh that are soldered directly onto the board. And we can read the data the same way the computer does by connecting a piece of metal to those pieces of metal. It's actually quite simple. So, we're going to use something called a universal programmer, which costs about

a hundred bucks on Amazon, and some DIY uh you know, probes or or wires or whatever we actually can manage to afford or MacGyver. And uh we are going to connect them directly to the chip as we see in the last photo there. And once we have a good solid connection, we can read the data or overwrite the data on that chip directly without having to desolder anything from the board. So this is what allows us to do a whole bunch of interesting attacks against BIOS. And this is how we would interact with it. So that's what it looks like when you are very concentrated and uh doing that. Uh pro tip, don't drink too

much coffee when you're going to do this. You need to have steady hands. So during your physical pentest, when you get to this step, you're going to take a what I call a firmware dump or a BIOS dump where you're going to essentially extract all the information that was on that chip. You're going to end up with a nice 32 megabyte or you know 64 megabyte file. Uh and that file contains the raw data of the firmware. You can analyze it using free open source tools like UI tool. uh UI tool will take the binary data that's in that firmware dump and allow you to parse it and display human readable format of uh information that

is in it. Now from this pos from this position we have access to everything that's in that firmware dump. That means there are programs there's programs in firmware. They're called EFI programs. We can't really modify those because there's uh verification technologies in place. For example, with Intel, there's Intel Bootgu Guard, which is going to stop us from swapping drivers and like putting our own malicious driver directly in there. That would be catastrophically bad if they did not have that. Um, and it it's enforced by a very strong hardware root of trust uh system. So, it's it's pretty I mean, it's not infallible, but it's pretty good. And we won't be attacking that today. Uh, AMD has their own thing with

like Fenix hash and all of that. We can't modify those components of the firmware. So that's to say everything that would be highlighted in red or in yellow in UI tool which is going to show us the uh Intel boot guard markings automatically. But as you can see there's a lot that is actually in white here. Everything that's in white is something that we can modify. So there is by its by its very nature uh some of these components of UI need to be modifiable. They cannot be immutable because they represent stateful changes to the firmware. So you as the user you might go in the settings and change things. those settings will be tracked

and will be uh managed through this non-volatile section of the UV image which is called NV RAM or nonvolatile random access memory. So these are basically key value pairs and they can be kind of complex like the the value can be its own key value pair and then you could have like nested it can get quite complicated but essentially it's key values and you can modify the values to do all sorts of interesting things. This is the majority of the attack surface for preboot environments. So, as an example, in the past, what I did was I found a specific NVRAM key. I changed its value to a specific non-printable hex character string. And just doing

that, flashing it back onto the computer, it would boot into manufacturer programming mode, which you see here at the bottom in red. And when that mode is active, you can overwrite anything you want. You can delete the security settings, and you don't need to know the password. So, this is one way you can circumvent a BIOS password. A more simplistic view would be just overwriting all of the NV RAM. You can maybe extract a clean one from a firmware update that's available from the manufacturer's website. Take that NV RAM, swap it out. You've cleaned basically all of the configuration settings and sometimes that'll remove passwords on less well-designed hardware. There are in fact a number of

different ways you can do this and it often varies from model to model of different laptops. Sometimes it's not discovered yet. Maybe you will be the one to discover it. The takeaway is that there's a lot of ways to remove passwords and sometimes you don't even need to remove the password at all. You can perhaps modify an NV RAM variable which controls the setting that you're looking to change. So you don't even need to know the password. You can just change the setting and leave the password in place. You're bypassing it altogether by modifying NV RAM directly. So there are occasionally going to be patches that are introduced by these manufacturers to protect against these

various attacks. It happens. It's not often but it does happen. Uh in those cases as a pentester you have two solutions. You can come up with a new exploit which has not been documented yet which is not as hard as it should be. Uh or you could exploit the lack of roll back prevention. This is often disabled by IT admins because they don't want their entire fleet of computers to go to the trash if ever there's a firmware uh mistake or a broken update that goes for firmware. So they will um it's it's pretty common to see secure roll back prevention disabled. What this means is that I can now take my target laptop and flash a previous version of

the BIOS onto that computer and I've essentially downgraded it and and in doing so I've reintroduced previously patched vulnerabilities to the system and now I can exploit those. So if you can do a downgrade attack it can be worth it depending on how far back you go. Counter measures against this um regularly perform pentests. That's kind of a given. uh secure rollback prevention is something that you should enable and ultimately use a BIOS password but don't rely only on the BIOS password because it becomes a single point of failure and we are all about defense and depth right folks so um I mentioned hardware whitelisting okay uh now we are going to talk about how you

can defeat hardware whitelisting and then we will not mention it again so uh hardware whitelists are a lazy way to restrict PCI express access to a device from the firmware basically Basically, hardware components have to advertise what they are to the computer in one of two ways. They'll either use something called a USB ID or a PCI ID. Uh most of the time when you're connecting directly to the motherboard, you're going to be talking about PCI IDs. So, they have this form here. You've got a little example there. And then all the way on the corner PCI 886. That is literally a PCI ID for whatever device that happens to be. Um these values are uh when we

implement something like a whitel list, what we're going to be doing is we need to compare the currently connected device with a list of authorized values here. And the only thing that we can compare against is the PCI ID. It's the only way that the device identifies itself. So if we go to our scenario and we plug in a screamer board to our target laptop and instead of booting, it gives us an ugly message like this. System is halted. Unauthorized network card is plugged in. power off and remove the network card. Now we know, okay, there's a hardware white list in place. It's not accepting my arbitrary device. I need to find a way around this. Now,

the strategy depends on the fact that we took a firmware dump previously, and we're always going to be taking a firmware dump every time we do a physical pen test. So, we have a dump of the firmware from this computer. We've tried to plug in the the the board, and it doesn't work. This message is not coming from space, okay? It is coming from a program. It is a programmatic message. And Windows is not loaded yet, right? Like Windows has not booted. So this is coming from the firmware. This is coming from UI. UI programs are called EFI programs. They have many different forms. There's DXC drivers, PEI drivers, SMM drivers, whatever. It doesn't matter. Uh what we're concerned

with, what we're interested in is finding the program in firmware that is responsible for giving us this message. So we know the message. We have our firmware dump in UI tools. We can do a uni-ode string search for a keyword that we got from that message. It said unauthorized network card is detected. Okay, I'm going to search the firmware dump for the raw string unauthorized. And I will see it occurs in several places. One of them is this here d uh wma policy. Well, that that that seems like probably the right place. So, what's cool with UI tools is I can extract this entire section as I can do extract body and I'll get the EFI which

is actually the program that is responsible for this message. Now, an EFI is like any PE32. It's an executable. So, I can put this in GIDRA or IDA or whatever decompiler I want. And I can do the same thing. I know that initial string that I'm looking for. Unauthorized network card is detected. I can do a string search this time in IDA for that phrase. And I see, oh, there it is. Unauthorized network card is detected. Power off and remove the network card. And then percent s because there's a placeholder for whatever it's telling us our uh PCID currently is. I can use cross references to go through my decompiled executable. And I can work

backwards to find what is the value this is getting compared against. And finally I can come up with the actual PCID whitelist which is in a data part of this executable. And it's right there. There's actually two values which are allowed. Um and the comparison between what my board is and and what it's supposed to be happens there. And I can actually extract the whitelisted values. Now because PC PCI leech the the firmware is open source. I can recompile it uh in Zilent Studio which is kind of painful but not too too hard. I can swap out these here values with the authorized PCI ID. Recompile the firmware. And now I have defeated the white list. I can plug in my board. No

problem. It's going to spoof the authorized ID. And uh yeah, that's defeated. So this is not real security. Okay, this is security through obscurity. This is hoping that you won't put the effort to do what I did here. But there's no actual security implementation here stopping us from doing malicious things. This also is extremely anti-consumer. You should be able to plug in whatever you want to a computer you own and it should not be coming from a specific white labelled brand. Uh so not going to talk about that anymore. Bit locker at Yuthi. Let's assume that we have bypass the BIOS password for now. Okay. Uh we are spoofing an authorized PCI ID like I

showed. Bit locker is enabled. We've got DMA uh we want to do a DMA attack. We've got VTD enabled and DMA protection enabled in the firmware. So we go into Yui and we turn off those two features VTD and DMA protection. We reboot the computer and we get this. It says Bit Locker needs your recovery key because an unexpected change has occurred. Why does that happen? That happens because the TPM is more than just decryption keys. It has things called platform configuration registers which can store values related to the current state of UI. And this is an awesome feature. What it does is it basically takes a like a a fingerprint of your UI configuration at

the time that Bit Locker was implemented. And if there's a change between what it expects UI to be in or what configuration state it expects UFI to be in and what it is, uh, it's going to throw this error and you're going to have to use a recovery key. That's a good way to do hardware encryption. Now, the TPM is going to track by default the two things that we're interested in disabling. It's going to turn on it's going to track VTD and it's going to track DMA protection. So that's not a game over as much as it should be though. Uh not everything is tracked by the TPM. So if we have a way to leave

certain features nominally enabled but otherwise disable them or break them, we can get around this particular feature. So taken from the Microsoft documentation, we have here in the first extract the conditions that are going to make the TPM force a bit locker recovery. Um basically on every boot where VTD or DMA protection is disabled, we force a bit locker recovery. Okay, that's fair enough. But then if we look at the again from Microsoft the um the requirements for enabling secure kernel DMA protection, there's actually an additional thing which is not tracked here. And it says that in order for this to work, we need to turn on Intel virtualization technology or VTX. So we are in a situation where VTX seems to be

required for proper protection but it's not something that the TPM is actually tracking and will flag uh Bit Locker recovery screen with. So we can go into a random vendor's uh UI implementation and indeed we can turn off VTX without touching VTD or DMA protection and this doesn't trigger Bit Locker. Here's a different vendor uh also popular uh same problem. For some reason they're like yeah go ahead turn off VTX. We just don't want you to touch VTD or DMA protection. So in both of these cases, we can disable VTX manually and there's nothing that's going to stop us. Um for DMA protection, it depends on the implementation, but often what you can do is you can change the subsettings,

not DMA protection itself. So one subsetting of DMA protection is preboot DMA protection. And we can change the subsettings from all PCI Express devices to Thunderbolt only, which is only going to protect the Thunderbolt port. Uh and that's not going to trigger a bit locker recovery either. So, if we look at our different vendors again, that looks like this. Notice above I've turned off VTX. VTD is still on. DMA protection is still on. I've changed pre-boot DMA protection now to Thunderbolt only. Okay. Well, if I do all that, what I've done is I've uh made it so the computer it's not going to throw a Bit Locker recovery error. It will boot. It will automatically

decrypt. It's all good. I can do my attack and I can perform now a pre-boot DMA attack. So, what is pre-boot DMA attack? We're going to talk a little bit about this uh quickly. So PCI Leech out of the box is capable of pawning a Windows uh device from pre-boot. That means from a position in UFI. It comes with an included module called the UI exit boot services which is going to parse memory during u UFI. It's going to find the uh the EFI system table. It's going to hook the exit boot services function and it's going to jump to our arbitrary code. We can have it execute whatever we want um once it hits that

hook. So this is built in and it looks like this when you run it. Kind of nondescript but whatever. Uh okay. And once that happens you're in a very interesting position because you're you have NOS kernel in memory but you're still in UI. You have intercepted the exit boot services call. So you have access to all the boot services none of the runtime services. You're in UI. You can do whatever you want in UI but NTOS kernel is there in memory ripe for modification. You can go and do whatever you want to it. So the idea out of the box would be to use the additional module called windloadad NTOS patch which is going to do what it sounds like

it does. It's going to patch NTOS kernel. It's going to go and write one of those kernel modules like the implant that I talked about before uh to the kernel and once Windows loads and boots uh we already have our kernel module implanted. So I essentially it saves us a step. we've we've written our main you know Trojan to the kernel during preboot instead of during the operating system stages and then we can interact with it once Windows is loaded and that gives us the same thing as before arbitrary code execution. However, there is a problem with this technique. You will recall that we have in our scenario only changed pre-boot DMA protection. We have

not changed DMA protection. We've left it on because if we turn it off we get a blue screen. U sorry not a blue screen we get a a bit locker error. So because these uh defensive technologies are still enabled, we can't actually use the outofthe-box functionality with PCI leach, we can write our main kernel module to the kernel, but we can't communicate with it after to get it to do stuff. If we do, we get a blue screen because DMA protection is enabled. And that's what DMA protection does. So I had this scenario happen to me uh over a year ago. And I realized, you know, this has to be exploitable. We can we have

the ability to write code to the kernel. there's no reason why we shouldn't be able to exploit this. We just can't talk to our implant. Um, so I created a way to exploit this scenario uh in the form of a module I call first strike. And this is something that I discussed last year. So we're still at the older stuff for those of you who uh yeah who were here. Um so first strike is a PCI leech module I developed which circumvents this issue. Basically the idea is we're going to put everything on autopilot. So, we do not need to talk to it and we will not trigger the DMA protection mechanism because we're not doing any

subsequent PCI Express interaction. It does everything by itself. And when I say that it's been placed on autopilot, I mean it's just going to create a process uh to spawn a new cmd, create a new user, put that user in the admin group, and we know that user's password. That's all it's going to do. It's also going to pop a message on screen so that we know we are not uh completely insane. And uh yeah, here is the original graph with the relationship between the different security mechanisms. And this is how first strike comes into play. So again, there's no um there's no bit lock, there's no UI password in this scenario. As you can see, it's not all

that stuff is not protected. And this is why we need to protect it because we can come and manually disable virtualization technology as we showed it doesn't trigger Bit Locker. That's going to kill virtualization based security. And then we can manually disable pre-boot DMA protection as we shown that does not trigger Bit Locker. That is going to impede our uh the computer's ability to prevent preboot DMA attacks. We can then patch the kernel with our first strike module and we can compromise Windows 10 this way. So uh I'll show you a quick demo. This video is a little bit better uh than the one I had last year. Uh and then we'll get into the really

interesting stuff because this is still against, you know, Windows 10 and it has some requirements. Uh but yeah, we might as well show it, right? So we've got a fresh Windows install. There is no demo user. We're going to turn off VTX manually and turn off pre-boot DMA protection manually. So we go there, show. Okay, VTD is enabled. DMA protection is enabled. Change preoot DMA protection and turn off VTX. And that's it. We'll save and exit. And we will see that this does not trigger Bit Locker. So um just going to show quickly there is no additional user on this computer. Let's get physical. So, first we're going to open up the chassis and we identify a uh LAN card

which is using an M2E port. So, we're going to remove the LAN card and we're going to take the port. Uh we're going to put an adapter. So, this is an M2E to M2M adapter. Doesn't really matter the adapters. It's just to make things fit. Uh we take our FPGA board, M2M to PCI 4X. Connect that all together like Legos. We need to give it uh power. I'm going to use this SATA de Molex for 12 volts. Uh and we connect that to the target laptop like that. And then we plug it into our attacker laptop like that. And we're ready to go. So once it's on, this is what it looks like. Uh we've got

the target laptop which is uh running in Yuthi and we're going to run this from our attacker laptop. So this is going to find the EFI system table base address. We'll talk about that later. So I'm not going to go over too much, but we're going to manually trigger the exit boot services hook. And now we are loaded. We can execute first strike. This is basically how it was designed to be used. So we're going to call PCI lead first strike. We give it the address of our UI kernel module and we wait for it to run. We get success. Now we can exit. We're stuck in a loop here. So we have to say

kmd exit. And once we do, Windows will resume the boot that we have interrupted. and it will start loading. So we go here and we've resumed. Okay, so at this point everything is done. We've already injected everything into the kernel. Um everything has been modified. The attack is pretty much over. Shell code is in memory and we could turn off the screamer board which is connected to the back. Uh in fact I do that in just about one second. So what we've done is we've automated the process of exploiting the operating system after this initial stage. So since everything is in memory and automatic, it's going to just keep running for about a 100 seconds and then

it's going to detonate which helps to ensure that we're at the Windows lo on screen and it should be about a minute later or 100 seconds later. There you go. Okay. So once it detonates, you get your message which tells you you're not crazy. I'm going to unplug that so that I can flip it. It was already off though, so it doesn't really matter. Uh and now if I go to login, we will see that there's an additional user which has been created at the bottom left there. There's the demo user which has a password that we know because that's what it was programmed to do. So we can do p srd1 123 and now it's going to log

us in for the first time. So this is all very cool. Uh and uh yeah so we get our wind I mean you guys know this screen. Uh yeah. Okay. So the demo user is in fact an admin because we've placed them in the local admin group. So I'm just going to open a cmd really quick. See who am I? and like a net user just for proof. There's who am I? We are demo and trying to shave off time here. Net user demo and there we are. We are in the administrators group and this this user was just created. Uh the password was just set. So yeah, that's that's basically how first strike works. So

first strike is on my GitHub, has been for a while now. You guys should all check it out if you're interested in this sort of stuff. Um but it is hacky and it only works on Windows 10. Okay, so now we get into the interesting stuff from this year and I have about 15 minutes left. I'm not going to lie. Uh, okay. So, um, the limitations of First Strike are that it only works on Windows 10. It assumes you bypass the UI password through dark magic. It assumes you have control of VTX and it assumes you have control of preoot DMA protection. What if we don't have that? Let's go to modern DMA attacks. Okay, so

target is Windows 11. BIOS password that we cannot remove and there's no access to the UI settings whatsoever. So, here is our modern protection. We've got everything enabled. What will we do? The objectives are to disable VBS, to disable kernel DMA protection, and not trigger Bit Locker while we're doing it. Okay, so let's start by disabling VBS. How do we do that? Well, the first step is to enter Winre. You can do this on almost any laptop that you want that is running Windows. You basically have to hard reboot twice in a row, and if you hold the power button while the little spinner is on screen, you will get to your diagnosing your PC/W Windows

recovery uh environment. You can now go to automatic repair. You can go to troubleshoot. You can go to advanced options. You can go to command prompt. It's going to ask you for a bit locker key. You say, "I don't have a Bit Locker key. Skip this drive." You do not care about decryting the C drive. What we want to do is mess with the boot configuration device. So, we get our uh command prompt. And now we're in the X partition, which is the the recovery partition. Uh, and we can use the command bcdedit to modify the boot configuration device for this computer. And we can set it in safe mode. Safe mode is really cool for attackers, by

the way. So, um, once you've put this computer in safe mode, if you boot it and you check out its capabilities in MS Info32, you'll see that virtualization based security is enabled but not running. And that's really important for us. So, this is how you can disable VBS on pretty much any computer without knowing the Bit Locker keys or having any other credentials whatsoever. Uh, you can also just straight up disable the hypervisor instead of putting the whole thing into safe mode. There's a few ways to do this, but they all leverage BCDEit. So if we go back to our thing uh we can see that we can introduce winre enable safe mode. This bypasses the need to change

virtualization technology and allows us to disable VBS completely. So this is leaving pretty much only half of the protection that ultimately matters uh still in place. Now how do we get rid of the rest? So we're going to want to disable pre-boot DMA protection. Now researching U this is something that we're going to need to do by attacking Yuthi. And researching Yuthi is difficult. It is extremely limited emulation options. You can do it with Kimu sort of, but it's not very good. Um, and fuzzing requires basically uh like a lot of patience. You need to modify something, flash the chip, go back, check what happened, and then back and forth, and you're orders of magnitude slower than any other type of

fuzzing you would do in any other sort of pentest scenario that like this is just ridiculously slow. Vendors know this, and they are not putting a lot of effort to secure things because they know that it's too much of a pain for most people to go and try to hack. So NV RAM as a consequence pretty much undocumented attack surface which is perfect for exploitation in a lot of cases. My technique is to create a target state and a protected state. I might change one setting at a time. I will uh identify where what exactly is it modifying in NVRAM when I change that setting in UI and then I will take a firmware dump before and after that

setting in different positions and check to see if I can identify a meaningful change. In the case of preboot DMA protection, we may find that the protected state is something as simple as 0 1 0 1 0 1 02 and the state we want it to be in might be 0 1 0 1 0 1 0 1. So it's really that simple. Sometimes you just change one bit and you can get an entire feature to turn itself off. So uh once we flash the chip with the modified firmware, we can actually patch NV RAM and control the settings of the firmware without knowing the password and the password's still present. We've just entirely circumvented it by going

directly to the setting and changing that. So we can actually disable pre-boot DMA protection this way. And once preboot DMA protection is disabled, we've actually hurt our Intel VTD and MMU protections through that dotted line. You can see they have been impacted. So from this stage, we've allowed ourselves now to do pre-boot DMA DMA attacks because we've gotten rid of preboot DMA protection and we need to find a way to disable kernel DMA protection. So last section, hopefully this isn't too long. Disabling kernel DMA protection is is a whole thing and I have a blog post on this if you want to see a lot of details, but we're going to go through it real real quick. Um,

basically when you look at your device in uh device security in Windows uh in Windows 11 or Windows 10, you'll see uh a section called memory access protection which tells us that uh a colonel DMA protection is enabled. We can also see that in MS info 32. It will be represented here by kernel DMA protection on. Okay, so the theory is kernel DMA protection has several requirements in order to function properly. We can attack these requirements to disable it. So I know from my research that uh kernel DMA protection depends on MMU and we saw that earlier a little bit. Now the OMMU actually depends on Intel VTD being enabled. If we read the VTD

documentation from Intel, it says here the system BIOS is responsible for detecting remapping hardware functions of the blah blah blah blah blah. It uses something called the DM ACPI table. Okay, the MCPI table is basically just a construct which has values and which is stored somewhere in memory uh which serves to report to the OS how things have been remapped so that the OMU can actually be used so that colonel DMA protection can actually be used. The idea is if we want to destroy kernel DMA protection or disable it, we can actually target DMA the DM table instead of going through MU or VTD itself. So how would we attack the DM ACPI table? Well, we're going to use a library

called Leech Core. Leech Core is part of the PCI Leech Framework project and is basically a series of wrapper libraries that lets us control the board in arbitrary ways. There's a Python library, there's a C# library, and there's a C library. Uh, so we can write our own program to do arbitrary DMA type stuff without relying too much on the existing stuff from PCI Leech. We will implement our own program to read and write to memory during preboot. and we will actually find a way algorithmically to derive the location of this DM ACPI table so that we can destroy it. That's the idea. So skipping over a lot of stuff here to save time. Um we're going

to start with the EFI system table. EFI system table is pretty much the main choice for exploitation in Yuthi because it contains pointers to all of the important functionality that an EFI program might require. So it's got pointers to the boot services, the runtime services, and a bunch of configuration data. That's how EFI programs get to do stuff. This is like their their API, okay? Or their their their Windows API for UV, let's say. So we can start by identifying the EFI system table base address in memory by parsing for this structure which always starts with IBI cyst F. So all I need to do is just regular you know regular expression search read memory until I

get to this pattern and say okay here's my EFI system table. Now from the UI 2.1 standard I can actually see that the EFI system table will uh always at a predictable offset from that base there will be a reference to something called the configuration table and that's always going to be 70 bytes away from the base uh address. Now the configuration table looks like this and we see this is the EFI system table right there at 70 there's an address in little Indian that is pointing to my configuration table. Now if I find the configuration table, it is full of GUID pointer pairs. These are 24 byt uh pairs basically of uh GUIDs and pointers which

give a location. If I read the documentation for Yuthi, I can find a ser um basically a whole bunch of well-known GUIDs. One of those is the ACPI 2.0 EFI GUID. So this is going to be pointing always to the ACPI vendor table in every UI implementation. Um if I can actually find that in the configuration table right there followed by its vendor table pointer. I can then navigate to the vendor table where I can find something called a root system description pointer or an RSDPR. This value is going to take me to the RSDT or the root system description table. This table contains all of the ACPI tables that are installed in the firmware for this instance of the

computer. Okay. So, I can parse every single address in here and I can go read the data that is there and I'm going to be basically going through each ACPI table that's installed on this computer including the DM ACPI table which starts with a predictable pattern the letters DM. So eventually I will actually find the real physical address of the DM ACPI table through this methodology. Now I can implement all of that. It's a whole bunch of steps. It's not that complicated in a Python program which I called DMA Reaper. Okay. And what it's going to do is it's going to find the DMAC A C A C A C A C A C A C A C A C A C

A CPI table from preboot and it's going to nuke it. Basically override it with a bunch of zeros so that it's not available when the operating system actually boots. And let's look at what that is. There may or may not be music. Okay, there's no music. All good. It's uh it's let's get physical. Anyway, it's good. It was funny. Uh, okay. So, first we just check the computer, make sure everything is running as expected. There's your memory access protection. And this is Windows 11, by the way. So, here kernel DMA protection is enabled. We'll go to FS info32. And we see again colonel DMA protection is enabled. Fantastic. Okay. So, let's let's see what it looks like when we use

DMA Reaper against this target. So, we're going to first just boot into Yuthi and check the configuration. make sure all the nice bells and whistles are enabled. Uh, so I'm gonna first check out. Okay, we have enhanced firmware runtime intrusion prevention and detection. That doesn't do [ __ ] Um, there's secure, sorry, there's secure boot enabled. There's virtualization technology for directed IO. There's DMA protection. There's all everything all the good stuff all on. Okay, save and exit. Cool. Now, we'll flip this over and same thing as before. I'm not going to explain everything in this this time, but we basically do the exact same thing we did before. We connect our board and we uh connect it to our attack computer

and then we boot into Yuthi and from here we can do our attack. Okay, so we're going to run DMA Reaper. It's going to scan. It's looking for the EFI system table. It finds it. Okay, cool. It finds all the other stuff. Configuration table, RSDT, finds DM ACI table and overwrites it. Cool. Done. Took like you know 10 seconds. Awesome. Now I can just click continue boot. Everything is done. And this guy is going to boot pretty fast because he's in safe mode, I think. Yep. And there we go. We can turn this off and going to log in. And we'll show the impact that what we just did had on the system. Presumably, it just it

deactivated Colonel DMA protection or I wouldn't be here. Uh but yeah, so we're going to go into device security. And now I love how Windows does this. They just like it's just gone. So there is no more access. It's the memory access protection is just not there. And if we check uh if we check MS info 32 for the capabilities, uh we'll see that kernel DMA protection is in fact off now. Okay. So this is how you can disable kernel DMA protection against Intel processors. The same thing works against AMD processors. It's just instead of a DM table, it's called an IVRs table. It is the same thing and this tool works in both cases. So this

is also on GitHub. Please check it out. There's a very good blog post in my opinion. I mean, I wrote it, so yeah, it's super good, but there there's a there's a blog post that accompanies it that's attached to the GitHub um like posting so you can actually follow in much more detail than we just went through now. Um and finally, I will show how this interacts with all of our different defensive mechanisms to uh allow us to pone Windows 11 in modern times. So, as we saw, we can use Winre and safe mode to get around VBS. We can patch NV RAM directly to disable preboot DMA protection. And once we've destroyed the DM ACI table using DMA Reaper, uh

the MMU is now gone. And so we can because kernel DMA protection is disabled, we can now just do a regular DMA attack against Windows 11 and nothing is left to protect us. Uh and so I will show that here. And that's the last thing I swear. So this is just synthesizing all the steps that we just went through uh and actually doing an attack. So, first we have to get around VBS. Skip the drive. Okay cool. BCD edit. Enable safe mode. And now we are going to turn off the computer. Now we go directly into using the DMA Reaper attack. And on our attack computer, now we have two terminals. We've got one where we're

just going to run DMA Reaper and let it disable Colonel DMA protection. And the other one which is PCI leech out of the box and we're just going to do regular exploitation. So this almost instantly runs. Uh, so Colonel DMA protection is now disabled. I'm going to allow the computer to boot. So I'm going to click continue boot and about 1 second later, it should be at the login screen. And of course, this is in safe mode. Uh, and now I can do a regular DMA attack with PCI leach as if there was no protection because we've effectively gotten rid of it. So we get a successful execution in the kernel. And now I can pass that

implant uh whatever shell code I want. In this case I can create a this is I can create a terminal uh or like a reverse shell basically. And I can do now this this is arbitrary command execution on the target laptop. So for demonstration I'll do message star pawned. And if I run that and we check the computer we got the pone message because we are broadcasting it to everybody. Um and so this computer is now completely compromised. And if I say who am I, I'm going to see that I am system. And it's actually better than system because I'm running in the kernel, but basically it's system. So this computer is pawned. Okay. So what

can we do to prevent this? Um, use an aggressive Bit Locker policy. Do not use just the TPM. If you have one thing to take away from this, okay, oh, we saw some crazy stuff today, didn't we? Yeah, we did. Don't just use TPM. It's not enough. It's 2025. It is not enough. You need multiffactor authentication to allow you to decrypt your computer. If you're a serious organization, you have serious security needs where you might be facing advanced attackers. You cannot just be using a TPM. That's the main thing that would disrupt all of these kill chains. And it it's not too too hard to do. It's just your users won't love you. Um but I mean, do they even

love us at all? They they never they never loved us. Okay. Uh finally, do use the BIOS password. Even though it it can be circumvented, it still is a relatively robust uh security mechanism. And in some cases, I have encountered some laptops where I wasn't able to get around it. Like it really depends from model to model. Uh do a bit of research maybe in advance if you're going to provision like a fleet of a thousand laptops, but uh otherwise use it anyway. And uh yeah, continue performing regular pentests. And I hope you guys enjoyed this talk. Please check out the GitHub entries if you're interested. [applause] Thank you.