 All right, welcome back everybody. And thank you so much for supporting the DefCom community and especially the Red Team Village. And with that in the further view, I pass it back to Gabriel. Take it away. Hi to everyone. This is a little different, but yeah, this is, I'm introducing a new tool called Drop Engine. It's a malleable payload creation framework. A bit about me. We'll go on about this for too long. But my name is Gabe Ryan. I'm a Red Team operator at SpectraOps. I used to work in a place called Gotham Digital Science doing security consulting. Got my Twitter handle in mind. My LinkedIn username is actually pretty interesting. It's ms08016. So without further ado, let's just dive right into this. Let's talk about initial access payloads. So what are initial access payloads as opposed to like normal payloads? Initial access payloads are typically used to gain access to a system environment. So at the very start of your engagement, it's what you're using to essentially gain your initial foothold. They're pretty simple design. I mean, it really has one job, which is to execute an implant or a second stage payload. And then from there, you pretty much do everything. All your secondary endpoint operations happen from that point onwards. Colloquially, they're also into distroppers or shellcode runners because they run shellcode. But yeah, while initial access payloads do have a pretty simple role, there are some obstacles that you have to face when designing them. So despite the fact that it's like the performance seemingly mundane task, right, that they just load code and memory and execute it, there are some challenges to contend with. The first of which is that during the delivery phase, so what you're actually trying to get this payload onto the target machine, usually that's going to be done via spearfishing. And if that's the direction you're going, this payload is going to be exposed to signature base detections in the form of mail filters, and stuff that's scanning through the email that you're sending out. It also may be exposed to automated behavioral analysis. So automated sandboxes is essentially what they do as they take your payload. And they actually execute it in a controlled environment. The reason why they do this is that whereas if you're just looking for signatures, you're going to get these brittle signatures that are kind of easy to evade. But in this instance, if you're looking at what the program is doing while it's executing, you're actually looking at behavior, which is a little more difficult to hide. And finally, during the delivery phase, your payload is going to be downloaded and saved to disk. You have to do this without triggering your getting caught by EDR or whatever. So that's the final challenge. And then once you've done that, you have to execute your payload. So the payload is going to be executed from disk. Usually, if it's like a fishy payload or something like that. Although typically in-memory operations are a little better, when you're just one of the challenges of your initial access payload is that you can't really start that way. So you have to start from disk a lot of the time. And you have to do this without triggering anti-virus or endpoint detection or response, AKA EDR. In Windows environments, you're also going to application wipe this thing is pretty much ubiquitous if you're operating within an active director environment or to them with Windows. What this means is that you're going to have to find a way to bypass that. And that usually means relying on something called the concept of this live-off-the-land binaries and scripts or law loss. Essentially, what these are, they're just like utilities, they're binaries that come packaged with the operating system. And they're usually designed to fulfill some benign role. But you can actually, what makes them special is that they have some functionality that you can essentially leverage to do something that is useful for you as an adversary. So in this case, there are several live-off-the-land binaries and scripts that can be used to execute payloads in various interesting ways. So that's fortunate that you can rely on that. You can use that to bypass application whitelisting. The problem is that most of these pretty much restrict you to programming languages and execution methods that get filtered through the Windows Common Language Runtime or CLR. And CLR, if you're going through CLR, you have to contend with Microsoft's anti-malware scan interface or AMSI, which just examines all this stuff that's going through. So that's another obstacle that you have to do. So in a lot of ways, getting this initial payload working and running can be very challenging, despite the fact that you're trying to do something that's seemingly simple. It's almost paradoxical in that way. And finally, you should assume that your initial access payload is going to be discovered. That's just a safe assumption to make. So your payload really should be able to withstand manual analysis in the form of threat hunters, reverse engineers, and the like. So with that in mind, all these are obstacles that are insurmountable. There are ways to contend with all of this. It is a bit of a cat and mouse game, but it's something that you can get around. The problem is that successful evasion techniques do not last very long. They have a tendency to get stale. They have a relatively short shelf life. And this is because if you're doing your job right, defenders will eventually learn from what you are doing as a red teamer and write detections against whatever TTPs you're using. So those really cool new TTPs that you drop, if you're doing a job right, this will actually improve the security. And they won't work forever. If you're using the same TTPs for years and years, well, you could argue that you're not really improving the security part. Yeah, that's a whole other thing. So defenders will eventually catch up to you. And what this means is that your payloads are finite. They have a shelf life. And that's good. And specific payloads, right? So we were talking about TTPs there, right? But specific payloads that you write have an even shorter shelf life. Because at some point, someone's going to write a signature base detection for that particular assembly that you drop on an op or something like that. And that's relatively easy to do. I mean, from a relatively, right? I mean, from an average for serious perspective, what this means is that we're using payloads as likely to get you burned. So what this means is that initial access payloads are typically kind of a pain point for offensive teams. And that's because you have all these challenges that you have to overcome. And the ways that you overcome these obstacles, but the methods that you use, essentially, are not going to last. And you typically have to write them by hand, or at least modify them by hand on an engagement per engagement basis. And code reuse can be problematic. And there's a lot of moving parts. There's a lot of, I mean, despite the relatively simple purpose, if you've ever looked at the source code for doing the process hollowing and C-sharp, you'll see there's a lot of code involved. There's a lot of things that can go wrong. So there's code reuse is a problem. You have to do a lot of stuff by hand. And there's a lot of moving parts, despite the fact that you're trying to do something relatively simple, which is kind of paradoxical. So to kind of contend with this problem, I was actually just kind of like researching payloads independently. But at some point, I just had the idea to work on this new tool called Drop Engine. Essentially, the goal of Drop Engine is to address this problem by providing a malleable framework for creating shell code runners. So if you ever used like Holostrike, for example, one of the cool things that makes like Holostrike great is the fact that just about every aspect of your agent that you're placing on, that you're using on the target machines that you're operating on can be modified. You can modify traffic profiles. You can modify essentially how it's dealing with using namepipes and whatnot. Just about every aspect of its use, you can customize it in some way. And by doing that, really get a lot of use out of this one tool. So I guess the core idea was to try to do something similar with initial access payloads. And the core idea is to identify discrete payload components. So basically examine your typical payload and say, what are all the parts that you see in this payload that repeat themselves across every payload that you ever write? And identify those and turn them into modules. And as a bonus, provide built-in obfuscation encryption and symbolic substitution capabilities, which makes it easier to evade significant actions. And in the case of encryption, makes it easier to evade human analysts. By doing that, we greatly extend the shell's life of those individual payload components that we're writing. So how would something like this work? To kind of think about this, we have to talk about how payloads are built. This is actually the interesting thing about this project. This is less of a Red Team project than it is a software development project. Because we're actually not really trying to do a whole lot of crazy stuff here with the actual, the payload itself. We're just looking at kind of the abstract design pattern here. If we think about the anatomy of a payload, at their core initial access payloads are relatively simple. They involve two major steps, which we talked about below the shell code into memory you executed. A little bit of terminology that I'm gonna throw out here, from this point on, or in this presentation, we're gonna refer to the routine that performs these two actions as the executor function, just to kind of make things simple. So there are many ways of achieving shell code execution. You've got DLL injection, you can spawn a local thread. You can use process hollowing, thread execution, hijacking, all kinds of stuff. But we actually want to abstract away specific details like this. We don't really wanna focus on them quite yet, because what we're looking at is actually for more of a bigger picture. Also, something else we have to consider, we mentioned that we need to contain with application whitelisting, and that really means that we're limited to formats that can be executed by law boss, live off of land buyers and scripts. So what this means is that our initial access payload is really gonna require three basic components. And you can kind of see my diagram here on the left here. We're gonna have the shell code runner. Technically the whole entire thing is a shell code runner, but just for the sake of labeling things, we'll refer to this outer wrapper as a shell code runner. That's gonna be law boss specific. Right? You know, if it's MSPIL payload, that's gonna be like an accidental file. Basically, if it's an installUtil payload, that's gonna be a C-sharp file that's compiled into an assembly. But you have your outer shell code runner, and then you have your payload name. That's your application entry point that's gonna call your executor function. And really everything else that gets called within your payload, but we're not gonna worry about everything else yet. It's just these three components. And then finally, you have your executor function. And this is gonna load your shell code memory, execute it, and essentially, yeah, that's the meat of this payload so far. So Drop Engine implements these basic components as base classes. Essentially what I've done is I've taken these three components and made it so you can inherit from them and derive modules from them. And what this means is that you could just write a module, and you can use any executor type you want, wrap it in a shell code runner you want, and the overall structure of the payload remains the same despite that you have a lot of different options as to how to actually implement all of this stuff. To kind of give you an example when we're talking about the structure, this is a, I ripped this direct. Well, there's supposed to be a link to this GitHub, but I guess like it's getting cropped on the bottom because it's PowerPoint and Zoom. But yeah, this is from 0x13, Steve Flores' GitHub. It's from a project called MoveKit. This is just an MS build runner, right? You have your outer wrapper, which is what we talked about here, right? And this is just your XML file. You have your payload main, which is just importing stuff and calling this executor here. And then you have your actual executor function there, your shell code inject. And this is this main, just gonna have to switch back and forth here a little bit. I'm actually gonna stop sharing for a second and then reshare from Hyper. Cool. So yeah, I mean, you're gonna see a lot of other stuff here, but if you look at the overall structure of how things are done, we have our components, have our runners, we can break them into individual discrete components like that. And we'll kind of go into more depth of this a little bit. And then of course we have our secure functions, which I don't have a whole lot of them in there quite yet, but that's okay, because so I'm gonna stop this and I'm gonna have time to share this again. Okay, there we go. And then hit from current slide. Okay. So we've identified our discrete components here, right? These items here. We also want to throw in encryption capabilities. So it's typically a good idea to leverage encryption when creating initial access to payloads for multiple reasons. Basically, you have your shell code that is gonna be executed by your shell code runner. And if it's something you don't necessarily wanna, a lot of these are gonna be like binary payloads or something like that. And you don't necessarily wanna have to throw that whole entire thing out just because that particular signature is detected by antivirus. So what we do is one way of hiding that for signature based checks is by encrypting it. But the other advantage of encrypting your shell code is that it makes it more difficult for human analysts to reverse engineer a payload. Remember, we need to assume that the payload is eventually gonna get caught. And when it does, we wanna make it as difficult for the reverse engineer to pick this apart as humanly possible. What this means is that our updated payload execution process is actually gonna involve a few more steps. We were going to load the encrypted payload into memory. We're going to decrypt that payload using the encryption key to obtain plain text shell code. And then finally, we're going to load that plain text shell code into memory and execute it. So the extra step here that we've added is this encryption function. So if we're gonna use encryption, this introduces yet another thing that we have to account for and that's key storage, derivation, and retrieval. When we leverage encryption to protect our shell code, essentially this is going to require us to provide our payload with one of the following. It's either going to need to be able to derive the encryption key somehow without actually storing it, right? So it's not gonna store it, but we need to be able to obtain the encryption key somehow. It needs to be able, if we can't do that, it could possibly just retrieve the encryption key from some other location. So we could provide it with that capability. Or we could just store the encryption key itself in the payload. Now, obviously this last option is not ideal because if you're storing the encryption key in the shell code and if someone in the payload, then someone compromises the payload that they can decrypt the shell code and you're kind of, you're just adding an extra step, but you're not really making it terribly difficult to pick apart. So let's talk about this first option of it, right? We mentioned the use of the first option is to derive the encryption key. One really great way of doing this is the use of environmental keying. This is like a really, I mean, so environmental keying's been around for a pretty long time. I mean, there's a lot, if you just look up like Maurer, environmental keying and just Google it, there's just tons of papers written about the subject. I think that the three most relevant projects to check out though, in terms of like prior work that's like really relevant to red teaming would definitely be, well, Ebola is the classic one, you know, job, yeah. That's, so if you look up Ebola GitHub, like that one is gonna come up really and environmental keying, that one will come up. The other one is Spotter, that one was released fairly recently, I think like in 2018 or something like that. And it pretty much does something pretty similar. And then also there's, I think like Leo Lupic has some blog posts where he talks about this and also expands off of those. But yeah, so the idea with environmental keying is that you actually derive the encryption key either entirely or in part from values in the environment. So what do we mean by this? Well, let's say that by attributes in environment, we're talking about usernames. So for example, you could use the currently logged in user that your payload is running as, as part of the encryption key, you could try to obtain the external IP address from where your shell payload is executing and use that as part of the encryption key. You could use your, make sure that you're actually on the right computer by deriving the encryption key in part by using your internal FQDN. I actually even like, you could even like use the moon phase or something like that. I mean, you can, you know, but essentially what this lets you do, well, those two things. One, it makes your payload very, very resistant to analysis because your encryption key is now no longer being stored in the payload. And essentially they'd have to, essentially like if you're setting encryption key to the value of the hard drive serial number, that means that you'll be able to decrypt and execute your payload on a specific machine that has that particular hard drive plugged in. But if you're an analyst and you just have a copy of this payload, unless you know what specific machine you're going after and what the serial number is, you're essentially forced to attempt to crack that encryption by guessing the value of that serial number. So it makes your payload super hard to crack and the added advantages that it's very targeted. Your shell code is only going to be decrypted on machines that match the key's specific attributes or if someone says they're brute forcing for a very, very long time. So I'm now going to set the first live demo of this over Zoom, no less, this will be interesting. All right, so I'm going to do a couple of things. First, I'm going to show you my setup that I'm using for this, because I think that's important. Just so that you all know kind of what's going on here. So I'm going to stop sharing for one second and I'm literally going to share. Well, can I do that? Okay, actually, yeah. So the first thing I have to show you, security settings on this machine that I'm using because that's actually very relevant. And you should see it. Okay, let me try sharing this again. Oh, you know what I can do? Yeah, here it is. Okay, I got it. So as you can see, I don't have cloud-delivered protection because I don't want the stuff I'm working on at the moment to get shipped off to antivirus analysis land essentially. So that started off as well as automatic sample submission. But this is a brand new Windows 10 install, have real-time protection turned on, tamper protection turned on so you can't disable it. And I also, but I do have an exclusion setup and I want to explain this really fast in case you're wondering why certain things are working. So I have one exclusion here and this is this directory demo AB include. So essentially what I'm going to be doing during these demos is I have four and I'm going to have to now switch windows that I'm sharing again. So you should see hyper right now is four terminals. I'm going to try to make this a little cleaner. So in the top left, this is just for my benefit. That's essentially, I'm trying not to anger the demo gods. So I am keeping as much of this stuff in the text file. I'm going to run the commands that are in there rather than trying to just guess. This will be relevant later. This is going to be our remote key server and you can kind of, we'll talk about that a second. This is a metasploit instance. So this is, yeah, so we're actually going to use the interpreter for this. So like every AP engine under the sun should be able to detect what we're doing essentially is what I'm trying to say. We're just using a, the payload we're going to be using is going to be a just a plain interpreter reverse HTTPS. We have to use the HTTPS because the actual unencrypted traffic will be picked up immediately. But the, so that exclusion that we're seeing we're just being difficult. I'm going to have to, it's going to be in this directory here. I'm going to exclude. And this is because we're going to be building this payload and all the payload was generated here. You know, the second I SCP that payload over onto onto my main machine, which is, which is what you're seeing in this top right terminal here. If the Federer would just do that. And I really don't want to just keep turning the fender on and off every time I have to do a demo, which is because that's just going to, I'm trying to make this goes as smoothly as possible. So the kind of compromise here is that we're going to be pulling our actual shellcode out of demo AV exclude. But when we execute it, that's not where we're going to be executing from. We're going to be executing outside of the exclusion folder. Okay. With that on the way, let's show you how we go over, let's go over how we'd make like a payload using environmental key. So, essentially the first thing we're going to do is get a list of available models, right? And just run this and these are all the different payload components we can choose from. So let's say that we want to use environmental keying. You know, we want to essentially grab let's do the FQDN because I have that written down and and the use of my current username. So like we're going to wrap the key from that. In that case, you know, we could just do this because you type on prop engine break on to new view line here. Specify that our shell code should be you know, in that if you could demo AV exclude to shell we're going to use the interface. I'm specifying this command interface. That's like literally the glue that holds everything together. You know, if you're working in C sharp you're going to use a C sharp interface. Don't worry about that too much. But we're going to say C sharp runner interface, right? And then we're going to also look at just like this encryption keys. We need an encryption key and a decryption key. So the key keys we're going to use are going to be this external X FQDN that we talked about. And notice I'm using more than one. We'll kind of go into how that works in a second. Right. It's going to use the decryption keys which is essentially these things, but we didn't C sharp because, you know, I'm just going to copy these with that there. We're then going to need to select the crypto to encrypt our shell code. So we're going to say crypto, yes, we're just going to use AES 256. That should really be named AES 256, not just AES, I should change that. And we're going to use a decryptor. So decryptor C sharp, ridge and doll AES which is corresponding decryption function that we need. Finally, for our shell code, I'm going to go ahead and use MS build because that will save me from having to compile something which will take extra time. And then we're going to need a mutator. We haven't really talked about mutators yet, but we will. But for now I'm going to say mutator. And essentially what that's going to do is going to take all the variable names and our finished output and change them to a random string. So it just makes it a little harder to signature on. And that really is, oh, we also need to specify the actual username and external FQDN that we're trying to use for our key. So I'll put my username, well as FQDN, and I'm just going to copy it from here. And hopefully this didn't update in the last time, like in the past hour or so, but I don't think it would have. And finally, oops. All right, forgot something. We need an executor function. Yeah, so we need that executor function that actually executes our shell code. And we're just going to use C-sharp virtual alec thread. So just going to make a call it virtual alec, virtual protect and all that and spawn some new thread. And we're going to make our output file example.csproj. And that's going to be our in a spilled file. Cool. Looks like your RAM didn't get any errors. If you look at our example csproj, here is an obfuscated in a spilled file. Actually, I should probably kind of show you what this is actually doing. I'm going to do mutator null, which basically install mutate anything. But yeah, so basically here are all the different components that are stacked together here, your decryption keys and your decryptor, your executor, everything else, right? And then here's your actual payload itself and payload main. Essentially, all this is just being rendered into the payload by drop engine on magically. And finally, we're going to start doing that. But I want this to be random because I don't know demo gots, I guess. So make that a random one. So now we're going to set up our handler, use exploit multi handler payload, first CTP, I'll host set L port 443, which should be correct. And I'm going to say exploit that's J to start our handler in the background. Now we're going to actually run this using as built. And there we go. Now, just to kind of case you don't believe me, like that this is actually doing something. I'm going to kill everything here. That was the best, whatever. Like copy of the enter nano. You know what, I'm actually deviating from the demo right now. And I think that's a bad idea. We'll get back to this if you have time. No, actually, you know what? I'm stubborn. Let's do the, yeah, if I copy MOAB, exclude empty shell, and let's just copy it up on level. We should get, or perhaps not, maybe we might have to run it to get the alert. But yeah, I'm not going to say you're tinkering with this. Let's get back to PowerPoint. Okay, from current slide. So that's our, you know, payload with basically like custom built payload with environmental keying that we literally just created in like a second. So mutator modules, right? We mentioned also that we're using, I guess not, okay. Ignore me. I could have sworn there was something else that I was supposed to talk about there. Okay. Yeah, so like the other thing, essentially what we've just done, I mean, we've said, you know, here's the executor function we want to use. Here's the shell code runner we want to use. Here's the encryption, decryption routines we want to use. And by the way, we want to drive our keys from these two specific functions and we're going to pull this stuff together and make it into a payload. And by the way, randomize all the variables in variable names in that payload and just write command and then it just does it. And then voila, you have a payload. The way that we did the actual, the changing of the variable names was using module, basically modular symbolic mutation. So drop engine supports the use of mutator modules. That, I mean, that's what they do is that they, every module that had, you know, corresponds to something that has a variable names or function names has a mutator method that gets called in the backend by whatever mutator module that you select and the mutator module then systematically goes through and takes like a list of variable names and maps them using some algorithm. The algorithm is irrelevant, it's module specific. And then when the actual, and returns back to that module, the original module, that mapping like, so like a dictionary of like, here's all your variable names and here's the stuff that we've mapped them to. And then what happens is that we render when that module gets rendered into a rendered template and that's how we're building everything. It's using change of templates. We are, a sense of what's going on is that it looks at that mapping in order to figure out what's named the variable. So this is pretty cool because it allows us to create payloads that, you know, are circumvent signature-based detections pretty easily. I only have like three supported methods in there right now, road 13, the random string, and also a simple substitution using a word list. No mutator doesn't really count because that's just, it just doesn't do anything. It's a null mutator. It's primarily there for debugging purposes. And I've kind of already demonstrated that, but if you want to just go over, you know, just once again, like with that, that looks like, you know, take this one that we just did, just print the screens that are out of the file. So for example, here's your, actually, let me use, I've got another piece of shell code that isn't so long that we can use for demos. Yeah, so, you know, here's your random strings. You know, if you wanted to use road 13, these look awful a lot like the variable names. Let's use a word list. I actually have to specify a word list when I do this. Let's use US cities. And that will, now all of your variable names are corresponded to US cities. A better use of this would just be to find like a, make a word list that actually are believable variable names. But, I don't know, this is better for doing a demo. When you go back to PowerPoint, let's move on from here. And then we just make sure, okay, cool. So, let's talk about some more keyings of the kind of techniques that we support. We talked about environmental keying, remote keying, it's also pretty neat. Essentially, instead of deriving the key from some place in your environment, you're actually going to retrieve the encryption key from some remote location, either for HTTP or HTTPS, DNS or some other communication protocol. This is actually, if you have well-designed non-attributal attack infrastructure, it actually makes this method pretty effective. You can place the key server behind a redirector and only accept requests for that key under a specific, for very specific profile traffic that's being sent to the redirector. If you want to make it even better, you can use a one-time remote key, which is a variant in which your key server, which is a server that's hosting these remote keys. By the way, you want to have one key per payload and Drop Engine does support that. So, keys should be unique to the payload that you generate. But essentially, the one-time remote key variant, once that key is successfully retrieved from the key server, it actually is deleted from the key server. So, the key server goes back into its database, just nukes the key. And what this means is that any future requests for that key are either going to be ignored by the key server or return some kind of junk data, or you could even, at that point, respond to that kind of request by returning a redirect. So, you could do what a redirect would do and redirect that request to something innocuous, like, you know, like remotely hosted jQuery or something. Like, look, it's not just jQuery, right? But, so, I mean, there are some obvious advantages to doing key in this way. It's very resistant to analysis. The encryption key is not stored on the payload file. And it's hopefully being protected in transit using TLS. It's also less targeted, right? You know, well, highly targeted payloads are good in a lot of cases. Sometimes they're not. Sometimes you don't just want to attack the computer of that one person that has that particular hard drive or username. So, that would be one, a little more breadth. And in this case, you don't have to limit your scope. I mean, you should limit your scope regardless, but I guess what I'm saying is like, the scope isn't, you know, implicitly limited by your key mechanism at this point. So, I'll show you how this works and it drop-ends really fast. And I'm gonna go back to my screen here or go back to Hyper. And so, in the bottom left, we have this, what looks like a Plascap, it is. It's a really, really basic. I honestly did put a whole lot of time into this because, you know, I was just trying to get the perfect concept out the door, but this is our remote one-time key server. And what we're gonna do here is get a very similar payload to what we just did, right? So, we're gonna grab this. And this is, you know, as you can see here, well, it's just RAM. But what we just did, we created a shellcode using our M2 shell, like our server shell that's in that M2 shell.bin file. It's pretty much the same attributes we used last time. The difference here is we actually added some key and components. We added a new key here, which you can see right here. It's the E-key one-time remote HTTP and the corresponding decryption key, which is their D-key remote C-sharp OTK HTTP. And essentially what this is doing is it's just providing functions that will attempt to reach out to this server right here that is running in the bottom left to retrieve this encryption key. And it's gonna use that by using a specific identifier since you need to your implant. So that, you know, essentially what this guy down here is gonna do is look in the database to see if that identifier exists. And if it does, it's gonna respond with the decryption key and send it back to our payload. And then, you know, it'll be deleted from the database. So if subsequent requests just won't be honored. So let's run that really fast. We just kind of crop the bottom left here. Make sure we don't have any stragglers either in our sessions or, oh, okay, cool. So we're gonna run our handler and we gotta rebuild this really fast just to make sure everything looks up to snuff. It does. And we're gonna call it in miss build once again. And there we go. And you'll notice here, this traffic showed up in the Flask app and that is our server going back. That is our payload retrieving the key, right? Now let's go ahead and, oops, let's go ahead and kill this session right here. And the reason why I'm doing that is I wanna show you what happens when we, so we've already retrieved that remote key. So what we're gonna do now is we're going to just kind of demonstrate. If we happen to curl for that same value, right? Let's say we do a curl request to 127, as it's running on mobile, so we can just do this. HTTP, one slash slash, we're not using SSL at the moment. And, oh, you know what? We'd actually need the implant ID, wouldn't we? Oh, no, here it is. Yeah, let's grab this implant ID right from here. Cool, so we have everything we need to make this work. And you'll see that we don't actually get a response this time because it's just, it's been cleared. All right, so back to our PowerPoint. We've got about 20 minutes left. Open this up for chat phone about 10. Let's go back here, press slide. So one thing I'll notice is that we're, is that we're actually using multiple encryption keys here or it seems like it, right? Because we're specifying these different key types and combining them to create a final encryption key. We're doing this using something that I like to call key stacking, which is the practice, and this is just a, key stacking is just like a label. I'm sure this has been done before like at any times because it's really not that complicated. Like it's pretty simple in practice and we'll see that in a minute, but essentially key stacking is the practice of combining the results of multiple key methods to create single combined keys. So for example, let's say we have one key that's comprised of four parts, the hard drive serial number, external IP address, a not stored in the payload file. So it's stored component and also one time key that is retrieved over HTTPS. Well, in that point, we essentially would just make four method calls of it, our payload, to four different key derivation functions can catnate the results together. And by doing that, we'd have one encryption key that was derived from all these different sources. So one advantage of doing this to give us a little more security is that it's difficult to compromise. This advantage is kind of complicated. If you do this by hand, like it's adding more moving parts to the equation. But once again, since we're using a framework, it makes it a little less complicated. Essentially what makes this possible is that with the actual architecture that we saw at the very beginning, it has been updated a little bit. So remember originally we just had that shellcode runner and a payload main in there and an executor function. In this case, we still have our shellcode runner. It's our outermost wrapper. That's our LulzBoss specific script that contains the encapsulates everything. But we also have our payload main. And within that, we now have, you see here, we all have all these d-key functions. So we have a d-key one, d-key two, all the way through d-key n. It's an arbitrary number of d-key functions. And essentially the way that this works is that, you know, each key part is extracted from each of these key derivation functions and passed to the decryptor function along with the encrypt the shellcode that combined or stacked key is then used to get the plaintext shellcode as passed to the executor. So, you know, really this, it's not too bad, you know. And we just did, we already went over key stacking. So let's talk about pre-models and post-models. And I included the cookie monster here because like who doesn't like the cookie monster? Like really, so what are pre-models and post-models? Essentially, this is a concept. I mean, there's often, often when you're executing that initial access payload, right, that does shellcode within your shellcode runner. There are things that you want to do first before you actually start trying to execute your shellcode. You know, for one thing, you might want to perform sandbox checks. You know, like if you're trying to see if you're in one of those automated sandboxes, you might not want to, you might want to check for some known attributes of the sandboxes such as certain file paths or, you know, number of CPUs or what have you to actually see if you're in, you know, like a quote unquote real environment or in a sandbox. Also, we mentioned that this is likely going to be going through the CLR. So you might want to try to bypass AMSI. And that's something that you might want to try to do before you execute your shellcode. So a pre-module is hard to do. I mean, essentially they are just sub-routines that are prepended to everything else in your payload. So what Drop Engine lets you do is you can specify, you know, any number of pre-modules that you want. And these will just get run before everything else does. You know, so for example, if you want to run a sandbox check in AMSI bypass, you pass those both to Drop Engine as pre-modules. They then get executed. And then once they finish executing, and they are executed in the order that you specify them by the way, which is pretty cool. You actually control which order they execute in. But once they finish executing, then we execute the rest of your shellcode here. So, you know, post-modules, they're pretty much the opposite thing instead of being prepended to the beginning of the payload, we append them to the end of the payload. So that's useful for if there's something that you want to do after your shellcode terminates. You know, so, you know, clean up routines, log file deletion, modification. And both pre-modules and post-modules should be completely modular and mutable, just like the rest of the payload's components. So you can mangle all the string names and variable names however you want. And so if we're gonna demo process of adding pre-modules, here's how you do it. Make this a super fast one. So for example here, you can see if we want to create a payload that, you know, let's say we want to run an empty sandbox check for, you know, say like, you know, check to see if we're in a sandbox by checking the minimum number of USBs that have ever been installed, you know, if you, let's say we look for also file paths that can be led us to being a fan, that were in a sandbox. So we do a file path, path-based sandbox check. And then finally we want to execute a SCAM, AMG bypass for the AMG scan buffer bypass. We can just, you know, append these here as pre-modules. And oops. It's okay. Should be M2 shell, not shell. Go just like this. And essentially, actually if you're curious what this looks like, I'm not actually going to say this. I'm just going to switch with the screen. So yeah, that's what I want to do. And then I'm going to use that, that really, really small shell code that I showed you earlier, that's easier to read. Should not be from the exclusion folder, because that small shell code is not in the exclusion folder. And you'll see here that, you know, here your sandbox checks and your AMG bypass and that's all getting executed up here essentially. So that all gets done right before you're in everything else. So once again, let's we're up on our under-spill payload. We're going to start up our handler and we created it in the last steps. I'm not going to recreate it. And you see that it runs. So everything just kind of goes swimmingly because we're out of sandbox. We go ahead and fill this and just wrap this up. We kind of did both demos at once and that's all right. And the last thing we're going to talk about is essentially how do you create drop engine modules? So the goal of the project isn't really to provide pre-bake methods for bypassing AP and EDR. It's really more, we did provide some of these big example modules but really, you know, that they're not really doing anything new or novel. And this is my design because the goal of this framework is to enable red teams to maximize the value that they get from their individual payloads by converting them into reusable modules. And if you're a defender, this is useful too because you can use this tool to quickly create large sets of sample payloads from which to build a learning strategy. So there are two types of modules that you can build, input modules and output modules. Essentially input modules are anything that's going in before it gets your payload. So your encryption functions and input module and, you know, whereas for example, your executor function is going to be an output module. This is super important. Shout out to Marcelo by Pleader for his basically like the loader that it's using to build these is heavily based off of some of the stuff he's done. So I think about input modules, they always have to correspond to one or more matching output modules, but they're really, relatively simple to implement. As you can see here, you know, what we're doing is we're just inheriting from the, we're building an encryption key module and we're just inheriting from this base class and then creating constructor, which is just kind of setting the various attributes associated with this. Although all the argument handling is up on the back end. So you just, if you want to pass command line arguments to your module, just add an add arguments function. If you've ever used our parts in Python before, it's, you could just add all these here. The parser was already initialized by one of the parent classes of your module. So you could just make calls to self.parser at argument and add all the arguments you want and that will get parsed automatically, essentially once your payload is generated. And then you have your generate routine and this is essentially, well, for encryption keys is generate, but depending on the module type we're using, you're gonna have your function that actually does stuff. Output modules, very similar, but even simpler. So the way the output modules work, this is the actual, these actually get rendered into your payload. They may potentially correspond to an input module. They may not as in the case of like an executor, for example, but it's really just a simple to your component design, you have a JINTA template and Python file that stores metadata that is passed into that JINTA template. So for example, here I've got a list of all my variables and imports and whatnot. And that gets passed to the interface and then passed back and then load into the template in however format you need it. And then here you just have the JINTA template they're using. As far as actually like creating these things go, how much time do we actually have? I won't spend too much time on this. And just a minute, if you wanna create one of these modules, aside from the stuff, I guess what we haven't really showed you is the template, but here's just an example module. It doesn't really do anything. But I see all that you have to do is just set these attributes and then you give it a list of interfaces it's compatible with. And then any input module is compatible with, give it a list of all the variables in your C-sharp file or whatever kind of file or is it really, it's not limited to C-sharp. And then also give it the name of the template and give it a function and class name in this particular instance. You have to do that. It's not very long. Then you have to create a template, right? And so literally this is the process of creating a template. And I'm actually working on automating this, but that requires essentially, you need to write something that can parse C-sharp then that's coming along, but it's not quite done yet. But for now, what you do, if you wanna actually turn just a normal C-sharp file into a template that can do understand but still by drop engine, you just find all your variables in here and just wrap them in this ginger parameter. So you just say B and then you, I use a syntax here. So we've got variable Nick, we just kind of edit it like that. And then we can do the same thing here, with variable N. Should be our only two variables there. And I just do that once again over here. So this is kind of painful for longer ones, but it's the only have to do it once in that case. And I'm working on some, some ways to automate a lot of that, check screen, PowerPoint, and that's pretty much it. I'm going to actually, this is zoom thing, so I don't really know, that's the location of the project on GitHub, if you wanna check it out, I'm gonna, I think it's supposed to be like a Q and A thing right now and I need to figure out how that works. So I'm gonna. Yeah, basically, once again, thank you so much for your time and for the presentation here, excellent presentation. So for the Q and A, you can jump into this court, it's gonna be offline, of course, it's a little bit of delay between the stream and when they can answer. And there's a lot of people actually already talking about the presentation. So. Super cool. Kudos. And for those of you also that probably just joined, please take a look at all the talks and all the activities that we have in our website. The description should be in the bottom of the stream, right? So in the description of the stream, all the links and related material. And also please join the conversation as we said in this court. So we're going to go in a little break and the next presentation will start in just a few minutes. Thank you again. Gabriel.