 So a little bit about me. Been a hacker for a while, in case you didn't know. One of the tools that I've written recently, it actually started way back in DEF CON 22 as the process detection mechanism for detecting processes in physical memory by page table detection. And there's a lot of reserve bits that you needed. And because of, you know, characteristics about how the page table is organized, in particular the self pointer, I could detect all these processes. And, you know, then we were pointing up at the screen and we were like, hey, because there's a VM running. And it could even detect the processes in the VM, you know, nested wise. And that gave me the idea to kind of keep developing the tool set. And here we are a few years later with something I think is pretty cool. You'll see it at the end, hopefully. But it's all on GitHub right now. It does a full integrity checking of code pages in memory. And you just golden image your VM. And then you can check it any time you want. So that's going to be like, hopefully we get to see a little demo. Overall, the outline of what we're going to talk about today is how to forensic, how to fuck forensics, how to unfuck it. I don't know how much any of you guys have done forensics, but it can be a very frustrating proposition. There's a lot of tactics used by adversaries to misdirect you to cause you to do extra work and cost people a lot of money and time. So overall, there's been a lot of techniques over the years. I've got a couple slides on like a break out of different things that I borrowed from another presentation. But last year in 80 did this AF presentation, like as fuck, but it means anti-frenzics. And he did this interesting mechanism to break certain tools. And then the ROP stuff is going to be how to forensic kind of meets reverse engineering and kind of meets like low level analysis and how, you know, these different domains are kind of overlapping a bit. And you've got to really have an understanding at least of these things and maybe want to look out for them. And I got some references to some other cool tools. One of the guys from Cisco Talis did recently. Pretty awesome. And then Cloud Leech is a rip I did on Ulfris, DMA, PCI Leech stuff. And I was going to have a demo of like unlocking a cloud container. But trust me, it all works great. It all works great. Just imagine it, wave my hands around. So the forensic process in general kind of starts out in the most basic form of trying to understand the timeline of events that happened and trying to reconstruct an understanding and some comprehension of like what happened, what's the capability of this guy, what can he do, how much do I have to like backpedal, or how hard do I have to come, do I have to redeploy my domain controllers, or can I just format some backups, you know, or unroll some tapes and we're good. So, hold on, let me see, these artifacts often come from disk or log event sources. And the better you are at providing high quality sources at the front end and have your infrastructure being monitored properly in different ways, you'll have a lot better luck in the back end because it's easy to tamper with one machine, but it's hard to go after and compromise the logging that's going on in multiple systems and to try and, you know, if the attackers got us now subvert, remoting events and things like that, it makes this job a lot harder. So this one is talking about some different tools you can use in different ways, you can go about it. Mark Kucinovich did this sysmon stuff, which really enhances the Windows event utils, but I don't know how many of you guys have, or people have used WEVT util. I grew up in Windows and back in the day, it used to be event log and it was system app programs, there are like four of them. There's almost 1200 of them that you can configure and this will log everything from binaries being executed to really the minutiae of your VPN connections, what packets got dropped, firewalls, all kinds of stuff. And this is an amazing set of logs that can really boost your understanding and your comprehension of events and you can tie it together easier and it's a lot more difficult to mask your activity when you've got to kind of compromise all these different logs. Swift on security has a GitHub repro that has a bunch of sysmon configs, which will help make running sysmon a lot easier and more concise as it were. And also if you're in the Linux space, I don't want to be totally Windows focused here, but in the Linux space, go ahead and take a look at OS query from GitHub. So handling memory, you know, has gotten pretty intense over the years and there's a lot of different tools here as well. Essentially you want to reconstruct like what's actually running and develop an understanding of like what was running from the artifacts in memory. You know, and this is where we start to get into the reverse engineering kind of component of it. Steven really has this really cool tool for like sandbox memory hacking. You should totally check that out. And always the game hacking space, you know, if you really want to go farther and understand the limits of what people are doing, it's a good way to go. So hiding really well, misdirecting and or like exploiting people. Alex Stamos actually way back in DEF CON 15 did this talk with a couple other guys on breaking forensic software and they had like NTFS hacks. They had like encase exploits and stuff like this. So that stuff still goes on. And that's kind of in the vein of what dual core like N80 guy did last year in trying to like attack the tool. This is the overall kind of anti-frenzyx taxonomy and it kind of breaks out like all these different techniques that these guys came up with and they tried to expand on. This is like some academic guys that you can check the reference out and they're trying to get more into this space and publish papers in that area. Sorry I didn't make the slides for the CD or anything. I'm going to upload them to GitHub in my repro if you guys want to check and I'm also going to pass them to the media people after. Some foreshadowing is like if you can normalize your tactics as an attacker into like what's expected of the network, then, you know, it's a lot harder to be seen if you're like assumed to be like a regular guy. Like I'm a VPN user, what, you know? And, you know, so if the attacker gets in and just reconfigures your system and just uses what's there, you know. So the counter to in 80s anti-frenzyx, the counter counter to this is more or less there's always additional sources just like logs in memory. There's always going to be additional sources to take advantage of and in particular for his, my tool in Vitero works out of the box because I base all of the dumping on page tables and that's something defined by the ABI and the hardware and you can't really mess that up, so to speak and in the same way. I believe Volatility and Recall have an option for using dads to discriminate the pages for your executables and make it easier to dump them as well. So with a little digging, you can always find a way to kind of get around this stuff. So the ROM, I know I got to make this really quick because I burnt up so much time with the monitor. Anyhow, the monitors on the ROM, the ROMs are, you know, becoming, they're an attack exploitation technique but now it's being seen that they're actually becoming a persistence method. So Gargoyle was like the public example of like how to interact with a ROM and make a persistence threat out of it as opposed to just like an exploit. And it sort of waits on a timer and then evaluates the stack a little bit and sets up a window to jump in and out of kind of like as a, you know, a little splash jump and he'll jump into one page on a timer on and off. Anyhow, the way this ROM works, it actually gets a little bit easy to detect because it's not exactly perfect either. So let me just jump right to the tools because I know I'm running so short. ROM emu is this really cool tool that actually will evaluate a ROM chain and if you want to do some like analysis of like what is this ROM doing because it's really hard to, if you've got a ROM in the stack, like understanding what all the little micro gadgets are, what gadgets are what you return into that does a little operation so that you can, you know, construct shell code or you can execute something. And you have to chain these together. So anyhow, ROM emu will take these ops and actually emit an elf binary that you can just throw into IDA, which is pretty dope. Also, so Invitero, my tool as well, has a ROM detection built into it for forensics so you can in the tool know if gargoyle or something like gargoyle is running. Lots of different injection techniques over the years. A lot of these are kind of variations on a theme. You know, more or less loading a binary up and then like using part of the address space to inject your own code so that you're hiding again. Always these attackers are going to want to hide in something that's in the, you know, hiding in the trees or in the grass or whatever else. So another one, sorry to keep going like this, this is, so in a sense the PCI leech is kind of like a code cave attack because it's an inline patch. And inline patches are really, really hard to detect because they're not modifying something that normal hookers do, which is like an import table or an entry point or prologue or something like this. It's actually just like right in the byte stream of the binary. So unless you're actually reverse engineering or dumping like the whole address space of the OS and manually going through and auditing it or something like that, you can have a real hard time understanding if you've been comprehensive and if you understand everything that you're looking at in terms of a memory dump. So that's where kind of integrity validation comes in and this is the feature that I released just a couple weeks ago. And it does essentially 64 byte piecewise hashing over a binary. So you're all the tech segments of all the binaries that you whitelist or golden image that converted into this database that then you can go and test your machines and go, hey, is this thing what I think it is? And a lot of people did pages for hashing, but you know, I don't even want to disassemble four kilobytes. Like a page is 4K. That's a lot of assembly instructions. So I support like a configurable size that you specify you're like, you know, I don't want to spend any time at all disassembling. So you could just say 64 bytes. And then if it detects like a patch in these bytes, it goes right to the byte that is patched or right near it. You know, it's only three or four instructions there. Tied it all together. You know, always use complementary sources and build an understanding of like, you know, the latest techniques and understand that these things are coming and they do happen and a lack of visibility into an understanding of these methodologies can leave you with some gaps in your understanding of what you're looking at. And my hope was to show you this tool, and it's got a really awesome output where, you know, it'll, I'll just give it a shot while I'm up here. If I do get a chance to run it, if I get one second, what's the wrong cable? Oh well. They don't have it. Nuts. I don't want. Sorry point. Is that it? No. Okay, sorry. Want any questions? Go check the tool out, you know. Full integrity checking, golden image of your VM. And I also have live editing. If anyone's ever used PyDebug, I've got a similar concept where I reflect all of the native kernel, all the symbols I reflect into iron python which is .NET. So you can basically go like E process, .image path name equals foo and it can write back to the memory image that you're looking at. So you can suspend VMware, edit it with this tool and then resume it and then, you know, whatever will happen and the kernel will happen. And the thing that will protect you is normally you've got to set up BCD entries for debugging. But if you're dealing with an advanced adversary, that will actually tip them off that they're in a, you know, monitored environment. So when, you know, when you configure the BCD debug, it changes the kernel and whatnot. So that was the concept behind the passive, active memory hacking. You know, give a shout out on GitHub and thanks again, everybody. Thanks.