 Hello. Hi. Welcome to this presentation. There's a few of you still filing in, but just sit down, find a seat, sit down, be humble. Do what Kendrick Lamar says. So instead of having a normal boring like here's our history, basically our CV on a slide, what we have instead is a more or less summary of our lives. But I'd like to read you the bio that we submitted for this talk, because I think it's one of the greater literary works of the 21st century. We were raised by computerized wolves with a penchant for fine art and rum based cocktails, while technically from different mothers, and also sides of the world, we formed the first cyber wolf brothership, shell bent to amherite the state of targeted malware implants to support the ongoing war against the institutionalized mediocrity of corporate shadow government. Working in tandem with dolphin researchers funded by the oligarch llamas, we found a way to synthesize powdered ethanol in a mechanical pony fuel. That's it. So clearly we're here to talk about some gun that's made of meat that shoots bullets of malware. But before we do that, I'd like to just give you some background of the reason this is here. And the reason is that this is a tool for red team by red teamers to solve some of the headaches and problems that we had in our day to day operations. Because we wanted to be able to focus on the challenges that really matter and not all the really like annoying stuff like reporting not being very good or having to go spin up a bunch of things. So also, if you're asking, do I mean pen testing? No, no, I do not. I don't mean to start a holy war here, but it's not a pen testing tool. I don't even think we do pen testing anymore. It's red teaming. But this tool isn't going to help you penetrate anything. This isn't a hacking tool that has a bunch of exploits in it. This isn't something that is going to like penetrate a network in any way for you. It's a tool for red team. So fundamentally, it's a framework for creating and managing and interacting with stealth implants that support persistent adversarial operations. You still need to have those implants. You still need to be able to get them in the environment somehow. It's basically just a shell. Management portal. So, red team operating paradigm. There's more background on what we do and how we do it. So when we do scopes, we try and scope it so that it's any systems, humans or processes that are employed by the target. We call this YOLO scoping. We choose the targets for ourselves as a red team and we try most of the time pretty successfully to set the rules of the engagement for ourselves and we never time box it. We set the amount of time we need as well and it's however long it takes because that's how the adversaries work too. And if we're going to simulate something accurately, it's however long it takes. Not you have two weeks to hack us or else. Also, sometimes we do steal stuff for real and because of that incident responders, they respond for real. They treat us like we're real. And because of that, we have to try really hard not to get caught and we have to pull out any stops necessary. We try and read out our results to a large audience as well too. Not quite as large as this one but it's about trying to craft propaganda and craft a change for security to uplift things. It's not just about ha ha, it's hacked, here's your list of results. So a bit of an origin story. Starting out, basically new job they say, hey, hack stuff. Also cause and impact. Also don't get caught. Also do you have shell yet? Wait, do you have shell yet? Do you have shell yet? So after a few weeks of do you have shell yet? I'm just like fine. I'll just go get some malware and that sounds easy enough and I'll craft a social engineering campaign and I'll just get someone to run my malware. Except, most of the decent malware was for Windows and anything that was for OS X either didn't have encrypted communications which is a no go and you have a full network PCAP. It also maybe didn't have like persistence mechanisms or the shell wasn't even interactive. So write your own. Myfirstmower.jpg. Basically it's just a Python script that makes reverse SSH tunnels happen. It's pretty rudimentary. Tried to put some cool tricks in there like using Twitter to resolve C2s, random scheduling, things to try and thwart our blue team. And it was obfuscated and there was a nice script to try and like generate it different. So I was able to try and be adaptable. And it worked good for like a year maybe. Like this was a pretty effective piece of thing because when you custom write something it works good. This is my favorite gift by the way. I think in the whole presentation. Second favorite. But this comes with some problems. First of all, blue side they don't like getting wrecked by a Python script. So naturally because it's an adversarial game they start writing specific detections for the red team. And specifically to detect the exact techniques that our mower deploys. And because of this the attribution of the red team gets really good. So our ability to do things like not tell them it's us and have them believe that it's not us goes down big time. And suddenly we are getting attributed all over the place and we can't be good boogie men. And plus we still have this thing that's like mostly spaghetti code because I wrote it and I'm crap. So we iterate. New team members say hey one of the first things you're going to do writes mower. And she writes a Java SSH full implementation. Goes both ways. Does pretty much the same thing but looks totally different. That works for it. Then we have to iterate again. We get a one that's written completely in bash. We add some new tricks to it and we're just like yes this is great. New mower, new tricks, DJ Cali, who's the best? It's great. Except the status quo was that we ended up rewriting our mower each time we wanted something new. And we had to stand up all our own C2 each time as well. And we had to manage and configure it all as well. This kind of sucks. And we had to manage the keys and the certs. And it took a lot of time and effort. And this is prone to errors. Because of that time and effort we start messing up. We accidentally reused C2. That gets us attributed. That's not what we want. Maybe things get us caught. One time we accidentally connected to it from the internal corporate network. Now you see C2 and also red team laptop connecting to the same thing. Yeah. Owned, right? This is painful because our stuff is unreliable. It's impossible to maintain. It's impossible to truly iterate on it. And it's really hard to add features because again, spaghetti code. Spaghetti code. So wouldn't it be nice if you didn't have to write things from scratch every time? Sorry. Cutting new mower implants only took seconds. And you could pick the features you wanted for that implant. And the C2 server infrastructure set up happened automatically for you. And each sample was unique. So when you take an MD5 of something, you upload it in the virus total. That means nothing. And each C2 end point was unique. These are operational things that we want. So break it in, right? And you didn't have to manage the keys for the servers because that's hard. And wouldn't it be nice if the mower was just super bugging awesome? And each time you added new things to it, it just got better because you actually have a system to iterate on it. So let's imagine. I want you all to reach under your seats. Underneath there we placed like an Oprah show. An imaginary thinking cap for you. You're not reaching under your seats. That guy. Thank you. I knew someone would do it. So let's put on our imagination hats and let's imagine a world with better mower for red team operators like us. Where there's a framework. Let's imagine that we build it in a way so that we can get the features we need. So we have a core. And the core, we probably want to bolt on some modules to it. Maybe things like how to connect to network. And this could be something like as simple as a network connection or as complex as Reddit posts or YouTube comments or Twitter things, right? And it doesn't necessarily only have to be one either. You might have multiple different C2 methods and you can have all of those in the same malware implant and then swap between them or send fragments of packets across all of them. Which would be really hard to do with spaghetti code. And then we can also have things like persistence modules because we want to run long term persistent ops. Bad guys already have this stuff. Just no one really shares it, right? But we can do better simulations if we had this, right? Maybe we want to have like a dropper, right? Spoiler alert is I don't think we have this yet. But we're building this for the best case scenario for the future to scale for like our own capability. So maybe we want, so that when a system is infected, it takes little information like hardware IDs of that system, submits that to the server. And then the server says, here you go, just in time compilation of your malware, it's encrypted for your system. So when you pull it off that system and you throw it in your automated sandbox, it doesn't work. And even if Blue Team kind of know that you're doing this, you can randomize the metrics or the IDs that you're using on that system. So they still have to put in some reversing effort to work out what you've actually used that time. Yeah, so we basically want to be able to change our IOCs programmatically, right? And then because you've got all of this in the one framework, you can then start to do more advanced things like have threat profiles for a specific operation. So maybe, you know, this time you want to spin up your C2 this way. And you want to have it on this cloud provider and you want to have like this particular configuration for it where you can do that in the framework. And you can start to simulate that with multiple operators all at the same time. They don't need to manually do that. It just happens automatically whenever you spin up that C2. So you can also probably do things like if you're a red team, right, part of what you're saying that you're doing is adversary simulation. So this could give you the ability to say, okay, I'm going to add a network module in and that network module is going to dictate how the traffic looks on the wire. So even though you get to use your shell like whatever, you could say let's mimic this threat actor based on a P-CAP, feed it in and get that type of traffic. Yeah, you can look at the frequency of packets, you can look at the average size of packets and you can look at the average length of connection and then you can use those types of connections in the network, split your data across multiple ones of those. So when the blue team is looking for your data being X filled, it's not being X filled over one connection but multiple connections that all look like common traffic on that system. So let's keep imagining, right? It's nice if we're going to have more things, we're going to have more things that we want to cronin-berg all together and we don't want to have to rewrite all these different components. So let's just let that be anything else. And also we should probably write it in go-lang, right? That's sexy these days. Go-lang is sexy, right? Yeah. Who likes go-lang? And this all has to work together and it needs to come together as like a singular atomic unit, like the things that make up our bodies and our ever expanding universe and it should probably adapt to any situation like MacGyver, like work on different OS's, do things like that. It doesn't need to be tied to a certain thing and it should be designed eloquently. Yeah, like Taylor. Like Tay-Tay. This guy loves Taylor Swift, like for real, like cool. So yeah, that's what we built. Well, it's the beginnings. No, it's done. So we start with the core that you kind of saw before. We need everything to kind of be orientated around this so we can bolt the functionality into a common, common, yeah, a center point. It's essentially a microkernel. So you're managing execution flow between all the different modules and whatever their functionality might be, as well as passing data between them and then saving that and returning it to the C2 network. So the core is going to be in a specific language. Right now, our first core is written in Golang and you can attach Golang modules onto this and the core determines what platforms it can run on. So in this case, Golang is trivially cross-platform so you can run on Mac, Linux and on Windows. So when you want to execute some part of that module functionality, how does the core manage to do that? Well, it uses two specific things to manage execution flow. One is an event loop where modules can register themselves to handle specific events. If you've done any OS programming, it's very similar to like a standard OS event loop. When that gets signaled by any module, it will then trigger the module which is going to handle that functionality. And we have a scheduler loop. Maybe you want to have some code that's going to execute every hour, every day or every week. Well, in this case, the core will handle that for you as well. So if we look at an example of a module, the C2 module is a good one to start with because every core needs to have a C2 module in order to connect back to Meet Pistol. So this is our C2 module. Its job is to, without the core needing to understand how it does it, connect and disconnect from the Meet Pistol network and provide a method for the modules to communicate data or transfer data back to the C2 network for the operators to use. So how does the core know how to use that? Well, once again, it comes back to the event loop where the core knows that if it triggers a C2 connect event, that the C2 module will do whatever it needs to do and then report back on whether it succeeded or not. So in this particular example, C2 connect and disconnect. All right. But a malware implant that only has a C2 connection is not very exciting. So why don't we add some persistence to it? Or why don't we add some file capabilities to be able to put files on that system, grab files off that system, download files from the internet. Then we, perhaps we're doing a whole bunch of common activities every single time we compromise the system to expel Chrome cookies or, you know, UTC password or whatever it is that you do when you get on that system, why not wrap that up into a single command that can be executed on demand? And then of course we need shells, so we need an exact module. And then you can start to think of a whole range of other modules that you might be able to use with the framework. For example, you might have a module that regularly detects if anything is being scanned on that system. If there's responders looking for that malware so you can clean up and get off. And you can see, I mean, with all of these different kinds of functionality, Meet Pistol gives you an opportunity to pick and choose the things that you want for each implant. Not just across the entire operation, but for every target system that you drop it on. You can customize this. It's like a malware buffet. Sounds delicious. So how does everything communicate? We've spoken about, do that again. We've spoken about how it internally communicates, but how does it externally communicate with the C2 network? Well, we've implemented like client to client unidirectional data transfer, which kind of sounds like half a TCP connection. So I mean, that's some impressive control flow there, but yeah. All right, but we need this to be persistent as well, because our operators are connecting to the master C2 and the implants are connecting to the master C2, but they're not necessarily online at the same time, or the implant might come and go as it pleases. So we have to persist the data there so that whenever they're both online, they can get what they need. And plus at the end of the operation, you want to have a record of all the things that you have done on that target system for analysis for next time, for reporting, for reporting, all cleaning up. All right, so here's our persistent storage. And we also wanted to achieve the greatest level of hacking excellence ever displayed. Finally, the dream is a reality. I know a lot of us haven't quite got there yet, but we strive for it every day to have hackers that can have two hackers on one keyboard. It's real guys. Yeah. So with having many readers and many writers on these channels, you can have two operators on different laptops in different parts of the world operating on the same shell, on the same system at the same time. So this is actually really useful because you used to be like in your shell, in your session or whatever, using whatever tool you're using. But you want someone else to be like, hey, jump into my shell and like ride along with me. Maybe they're a new person, maybe they're more senior and you need their help. So now you can have someone just like in the framework jump into your session with you. And they can type or take over, but you can both see it. So we used to accomplish this by like setting up shared screen sessions that we'd all jump into at the same time. And importantly, even if you spawn multiple shells on the me pistol framework, it's not spinning up new connections. It's all multiplexing, all of that data across the one connection. So you can control how that occurs. So if you have C2 and you want to fragment that data up, it's fine. You don't have to like open up new connections that Blue Team can see. And to achieve that, we needed to introduce some additional blocking semantics which, yeah, allow you to block at the end until the whole channel is closed. Which gives you an interface that looks a little bit like this. The important thing in me pistol is to push all the complexity, not at the not at the module level where you want to write as many modules as you want and you want them to be simple and easy to implement. You want to push all that to the server side. So the module just sees something that it can read from, it can write to, it can attach and detach, which is similar to a normal file open and close, and then close, which essentially says there are no more writes ever going to occur on this channel. So if you read to the end, it will return EOF finally instead of blocking. So that's how one client to client communication works. How does the whole me pistol network look? Well, I mean this pretty much sums it up. It's not too complicated. There's two important things that I would like to point out here. One, it's a red team. It's not a red person. So we have multiple operators all connecting to the master C2. And they're operating in the same state with the same implants at the same time. And then the second part is the infected hosts you see down on the right hand side are all your implants, but they're not connecting directly back to the master C2 because this is obviously trivial to attribute. Instead we have a proxy C2 layer in the middle, which it could be a simple, dumb, transparent proxy which just forwards packets straight through to the master C2. Or maybe it's a more intelligent C2 that will take fragmented packets and then decode them or whatever and then pass that data back. This design, this model is for OPSEC, for teams that have to operate internally, right? Because you have all these strange things where the real adversaries, they don't have this problem. This is a design paradigm for red teams because you might be internal to your company, right? You might work somewhere or be on site. You want it so that no one ever sees you talking to the same thing as the infected hosts talk to. I see a lot of nods. Cool, I can't. Well, what does it actually look like? Okay, so we're gonna switch to mirror mode and not have any speaker notes or anything for the rest of the talk. Hope you guys are okay with that. We'll be fine. This is fine. Can you guys see that? You want it a bit bigger? Oh, RIP. I spoiled the end. All right. Oh, RIP. Sorry, I'm gonna have to quit and restart. I need a Taylor quote. There we go. All right, so we've just gotten into me pistol. We've connected to the server. If you had connected to this fuzzy, what's the first thing that you kind of would want to do? Well, you know, what we set up to do years ago was like, let's make a thing that lets us build malware without it being a headache. So maybe build some malware? Let's make some motherfucking malware. All right. I got that right. So we're gonna create a new blueprint. We're gonna call it Tay-Tay because I think that's been fairly well established by now. A blueprint is a set of configurations for a specific implant. You can create multiple blueprints at the start of an operation. You can save that for later. You don't have to keep building the same types of implants over and over again by reconfiguring them every time. So first of all, to build some malware, we need to create some modules. So we need to add modules to the blueprint. We only have four at the moment, but they implement what we need. So let's add all of those to our blueprint. How we can do this faster if we could both tape on the same keyboard. I know, right? We need meat pistol for our meat pistol. All right. So now we have a look at the options that we can configure based on the modules that we've added. Fairly standard fare here. You can set your C2 host and port because the C2 module that we've added is a GRPC. Standard TLS authentication, et cetera, et cetera, et cetera. Some of the other options that you might not be familiar with, Darken, is a custom go-lang post compilation obfuscator which we'll go through and strip out. It's a regex. Sorry. It's just regex of stuff out of the binary, but with random bytes. And then the packer, yeah, there's nothing fancy happening there either. It's just all different options that you can set. Importantly here, because it's on go-lang at the moment, you can set the OS and the architecture and it will compile for whatever you want just by changing a string. Like, yeah, I love go-lang. That's cool. Yeah. So we're gonna set debug to true so that you can see the output in the demo. And now we need to spin up a C2 for this. Now, what we could do is we could say spin up meat proxy is an alias for an image identifier. So think of any instance online, think of an image that you've created. You can alias that instead of having like the i-blah blah blah blah blah. A couple of seconds later, we have our C2 ready to rock and roll. That's all you need to do. No logging in and having the two factor through Amazon and then find out you're in the wrong region or, you know, whatever cloud provider you're using. Cue this IP address getting like doused off the internet. But I mean, even that would get a bit tiresome having to spin up your own C2 every single time. Like, if you're gonna automate things, why not go the whole way? So let's set our C2 host and C2 for it to be auto. And now let's build it. So in the background, I was just gonna comment on the names. Like, you wrote this thing, so instead of having like terrible like UIDs for everything, it just creates these crazy things. And one time it created a really useful Maurian plant for us and it was called Cottage Wife. It was really, it was with us for a long time. Cooked us bread. So as you can see now it's finished. It's got the C2. It's automatically spun that up and configured the malware to use it. I know some people in the audience are probably downloading this right now, but don't bother. It's not that exciting. All right. But I mean, you still have to build every single time you want to have one piece of malware. Wouldn't it be cool if you could just like build more of them? And in the meantime, we'll download the first one that we just created. Now you can get this on the system in any way that you want. If you're red teaming, the whole point of meat pistol is not to compromise the system. It's to manage post-compromise of the system. I told you it wasn't a penetration tool. Yeah. So you can see the first build of the malware has come back here as well. Just gives you the link and the C2 that it's spun up for you. So this is good if you want to do something like a USB drop. You want to set like 10 USBs or whatever. Copy all that across and then you're good to go. You don't have to like sit there building all of them. All right. So then we run the implant, we get the connect back. And you can notice it's coming from the C2 that was automatically spun up. So now let's have a look at the implants we've got. We can see we've got one connection from nine seconds ago, aptly basil. So we can select that implant and now we can start to do things with it. This is similar to like a, well, I mean, yeah, you can pretty much just do things with it. So the first thing you might want to do is maybe pop a shell. And so now we have a shell. Now this is not just, it's not a dumb shell. You can do pretty much anything you want. So if you want to go into them, you can go into them. I'm in them. The test for this guy's interview was write me a shell that's actually fully interactive. It's probably important to note that the things that you can do right now is dictated by what modules you chose earlier. Also we have tab complete. I know like any tool if you don't have tab complete, it's like garbage, right? Like it's the metric that everything's judged by. And we've got his tree. And then you exit out and you're back in the framework again. So at this point, you might be like, oh, yeah, that's great. Well, that's a shell. Like I can literally do that in every single tool that I've ever had before. Well, we also have this. So remember how I said that all channels are persistent? All channels are persistent. And that shell session, every read and every write is recorded with a timestamp so that you could literally ask you cinema your entire session on that box. If we wanted to view what happened in that session, sorry, it's a little bit of a, there we go. And we have the full session that we just showed you but saved. That's not useful at all, right? Because no one here ever forgets to like start their terminal logging or, you know, take a screenshot or anything like that, right? And you can also do analysis on that at the end of the operation. If you want to do like smart detection of like certs or keys or anything in your shell sessions, you can do that at the server level without the operator having to manually do that. You might also want to, you know, tell the implant to sleep for a little while. Maybe, yeah, if you're going to do this manually it's not quite as useful but what you can do is automate this process so you can say, I want to have a shell herder which will within three hours I can have one implant in this particular environment. And then the framework could sleep all the other implants for you so you are having minimal connection back to the C2 until you need something and then you'll trigger it and then we'll wake up for you. I know sleep might sound boring but imagine you want to go home for the weekend or the night, right? You're not working anymore. It's off business hours. You don't want any network traffic going to and from the systems because that's really anomalous, right? So sleep is actually useful. Cool. I mean there's a whole bunch of other commands that you can do here but we'll leave that up to people to kind of explore. That's meat pistol. Surely our presentation somewhere. There it is. Cool. Okay. So one thing you should know like I mean this was and still is very much alpha as fug and I mean that's just how it is. But the thing is we've used this on a number of operations now. And it's solved a real problem for us. Mauer implant creation with like janky scripts that we were writing, it used to take days because you had to test it, you had to figure it out and you had to try and develop something to manage this and it didn't scale from one thing to another. You had to constantly redo all of this stuff. Now it takes seconds for us. And the important thing as well is in a red team operation you want the experience for the red team operator to be the same every single time so they can get used to the workflow but you want your actual method of operation to be totally different from the forensics side. So with a framework like this you can have a very familiar interface for the red team operators while changing modules or changing how they're configured. For example like different C2 or whatever it might be. So I have a very different experience on the blue team side when they're looking at the malware that you're dropping and how it's communicating. Yeah. So once you get locked into a serious malware collection the tendency is to try and push it as far as you can. So about a week ago, maybe less than a week ago, my house got turned into a weird scene from Silicon Valley. There was like three people sitting on my couch and like contributing because John had bright ideas like maybe we can get someone to see if they could like write a new core in a different language. So why do we have a Python core? Yeah. Well yeah it's one thing to kind of write something for your own eternal use. Getting people to be able to use that and understand how it works is an entirely different thing. So we thought it would be cool to throw it out there as a challenge to some students to say hey, you know, write a Python core for this before our talk in four days. So a big shout out to Glenn and Sean. Are you guys here right now? Yeah. Is there a first DevCon? Is there a first DevCon? Get in shout outs. And in four days time after being bribed with a lunch in West Oakland, fancy. And yeah they managed to get a Python core up and running and working with a shell module and everything. So kudos. So what's the best way to increase this? Obviously like the more you get the more capability we get to do different things to simulate different stuff. The idea would be to share it or not. Which sharing it was our intent. I messed up a little bit. We messed up a little bit. I didn't realize there was an approval process in order to open source things. And I just didn't do that. Like I was told about it today. And so we can't. But we'll get back to that. We'll probably just don't worry. I'm going to do whatever I have to do to make this thing reality. We will. So you're probably wondering about the name. So of course any good tool has a backer named name. And it needs to be self-referential. I think that's what recursion is, right? Is that recursion? So we're thinking meat pistol, maybe. We're throwing around some idea of meat pistol and thralls angry tyrants proposing intimate sexy times using oligarch llamas. But then we also thought maybe marginally wrecked our pack as tactfully pursuing international slave training oligarch llamas would be a good one too. But then we thought maybe it's just a modular embedded adversary tooling platform. The point is we called it meat pistol because we can. And also I mean like maybe you got, you picked up on the head. It's an homage to an awesome tool, right? And we had to call our thing something. So it's natural for people to want to compare this tool with other tools because we understand like there is a lot of really cool stuff in the ecosystem of offensive tooling that you can use. And we get the question a lot. I mean we've been socializing this with other red teams in the industry. See like what does it need? What should we work on this? Should we develop it? And most of the first few questions are like comparison type questions. And so we'll just address a few of those before we have to answer it a million times offline. People ask us how is it different than Metasploit, right? I don't want to start holy war again. So if you disagree with me right now, just sit down be humble for a moment and don't throw anything and we can talk about it later. But I think Metasploit is a tool that is inherently, fundamentally designed to be an exploit database where you can pair an exploit with a payload and then have any whatever auxiliary modules you want, right? To weaponize things, to penetrate, to actually be a pentesting tool. It's definitely grown into much more than that. But we have no intention of being an exploit database. People also ask is this the same as CobotStrike? No, it's obviously a different tool, but CobotStrike I see is something that really helps you simulate adversarial scenarios, right? You can do spearfishing, you can do pivots, you can visualize the network. It's really, really cool. But it's visualization, it's automation, ours is just a meme hour. Also, they are like, did you hear about Empire? And I was like, yeah. And then I was like checking it out and I like, I'm looking through the models in Empire and I see that like one of the post exploitation modules is like giving me credit and I'm like, what the shit? So I was like super flattered and flabbergasted by that, but it's a really, it's a really cool tool. It's a post exploitation agent. I believe that's what it says on the GitHub page. Ours is make me malware, manage C2, manage infrastructure. And then actually the DEF CON CFP panel asked us this. They're like, they just dumped Fuzzbunch. Does that make your tool irrelevant? And I was like, shit, does it make our tool irrelevant? And so I went and like looked at the Fuzzbunch stuff and I was like, this is all Windows stuff. And they were like, it's a really cool bag of tricks, but it is in no way something that's going to help our team run operations. So, Meet Pistol, not an exploit database, not click to win automation. It's not post exploitation agent. It's not a bag of cool tricks. It's, it's obviously a meat cannon that shoots out malware implants. No, Meet Pistol is a framework for red teams to create better implants over time, to manage them in a more professional and less ad hoc crazy way. It's an efficiency tool because we want to be the best red team we can be and we think efficiency is a way to do it. It's also multi-user implant management, an interaction portal, a single place to deal with everything. Make your stuff and interact with it. It's also an offensive infrastructure automation tool. I think that's one of the ways it started. It's trying to strike that nice balance between having that commodity malware and that custom malware because nobody has time for custom malware every time. So, the point is Meet Pistol is something that has saved us a lot of time and pain. And now it could be yours in the near future, but while we can't open source it today, we do have some t-shirts that are pretty cool. So, there's a bit of a challenge here. If you can figure it out, you can have Meet Pistol t-shirt. So, thank you. That's our talk.