 Hello DevCon, welcome to my talk, Rekiteer prototype and control ransomware operations. My name is Dimitri Snashkov. I work at Pertivity on Attack and Penetration Testing Team, where I have a chance to do tooling, offensive research and automation. And today we're going to talk about ransomware. Specifically, we're going to talk about simulating the lifecycle of ransomware, injecting into it, understanding it and emulating the steps that need to happen to properly test it. Our talk is going to be split in two phases. The first phase we're going to talk about the problem, construction of a solution from architectural perspective. And then the second part of the talk is going to be the demo where we dive in how the operation happens, what makes the Rekiteer toolkit tick. Let's start. So ransomware is definitely a technical issue. It's implemented in technology. But what fascinates me about ransomware is just such a good business model. It is just an efficient economic exit activity from cyber attack. Imagine that the bar of entry is low on the technical side and tooling is available. And encryption of the files, locking of the files can happen almost immediately once the dropper actually gets onto the box. So you don't really need, as a ransomware deployer, actually go to the second or third tier in the network, on the customer network. You can actually monetize right there and then. Also, all the features that the cost of deploying ransomware is much smaller than a lot of other cyber offensives. And with advent or actually use of crypto monetization activation path is fast. You can actually say that even the attribution is getting much more fragmented than before. And obviously with such business model, there's no wonder that ransomware has grown about 330% year over year growth. So if that's such a good business model, how do we emulate the testing for it? How do we inject into this? And how do we make sure we can actually trace what's going on, understand its capabilities and react to it? Well, traditionally, obviously, we need to contain, we need to keep on with preventative and detection controls because ransomware is just another variation of offensive on your network. You absolutely need to go across teams for disaster recovery drills. You know, do your incident response triage and one more thing is to add external negotiation with ransomware party as part of your tabletop exercises. But so just like everything else, a lot of times you can detect or prevent things, you can actually minimize mean time between failures. And this is what racketeer tooling is attempting to do is essentially trying to emulate the path and the lifecycle of ransomware and allow the teams to kind of get in the middle of that. And the way you do this is obviously you need to know your assets and data that ransomware may target. And you need to perform simulation and feedback. And that simulation feedback is what we're going to talk about. But before we move on, let's just distill the lifecycle of ransomware to three things literally is the persistence where the dropper actually executes the task on the assets be files or anything else. Then there is an extortion capability, which may or may not happen in sequence. You can have offline negotiation, you can have online kind of IOC's popped in that says, hey, you know, you have T minus 48 hours to pay us or else. And then from the ransomware perspective, there is a D stage or decryption capability that has to happen and potentially clean up, right? If you if you care about leaving the network intact, not causing denial of service. And so the objective of racketeer tooling is to refine that process of injecting into this lifecycle to help teams on whatever side of the story, whether it's the tabletop to support the incident response and triage, whether it's providing optics into TTPs and actually do in a collection of indicators of compromise they can, you know, that the teams can learn from. And, you know, obviously play towards the red team side where the objective is to implement the last mile delivery of ransomware in your objectives through your campaigns. Obviously, you know, for us as testing as testers, we have to abide by SLAs and it's good practice to keep the network intact, not denial, do not perform denial of service on it or cause denial of service. And so this is why we're calling our toolkit control prototype of ransomware, right? It's a controlled run where we have precise targets where you have kind of a balance of stealth and openness so you can both showcase the capability but also open it up to defenders to kind of inspect things. So if it is a ransomware simulation, what technical features does it need to have? Well, as we talked about before, we need to be correct and reliable in locking and unlocking assets because we want to make sure that the customer stays up, stays up. You know, real-time encryption versus offline decryption of assets is very useful because there are circumstances in ransomware campaigns where decryption and encryption happens separately or the agent dies and you should be able to bring the assets back into the unencrypted form as much as you can. Obviously, dormancy and activation, dropping the agent on the network does not mean it's going to get active and start encrypting things, right? We have to manage that. And because of that, we have to have flexibility in communications and specifying targets and all that good stuff. So let's just try to build one. What would be the good agent for our purposes? Well, let's just target Windows because it's the most prevalent kind of target for ransomware historically. Obviously, that can be adapted to Linux or go cross-platform. But in this case, we're going to take a look at encrypting local files on Windows and also encrypting remote files on Windows by going, you know, across the network. For example, you can remote into a different box through that agent and kind of do the encryption of assets there. And obviously we need to have control of execution as we mentioned before. The other technical features that we want to have in this agent is lifetime key management and key generation. It has to happen offline as far as generation because of, you know, both stealth and convenience. If you want to have offline capability to decrypt the assets, you should be able to do that. And then we work through policies. We load policies into the agent. The policies have to be flexible. They need to carry profiles with them as far as how you connect to the box, what user idea you're using, how do you shield credentials, all that good stuff. We mentioned offline asset recovery. And because of that, we actually have an operation on the hub and spoke model where a commander accepts the agent and then manages it there. So, you know, from the construction of those features, what else? We have to have communication emulation how ransomware usually interacts, obviously encryption on transmission layer, but also application level message encryption for the agent. That's become very prevalent and we need to be able to kind of inject into that. You know, it operates on or emulates a ransomware that does REST communication. It's your PubSub type of deal where you come in, ask for the task, execute it, upload the results and whatnot. So everything is sort of distributed in this way. What else do we need to do? Well, we mentioned the policy, but it also needs to be hot patching. So we need to be able to encrypt the assets, but we also need to be able to back out from the same policy so we don't lose correlation of the keys. Again, real time or remote, whichever the case may be. If we are testing customers and we are soliciting for credentials, if we need to, for example, impersonate a user to go to a remote box on the network, i.e. literally move to it, we want to make sure we put security on credentials. We don't want clear text creds, so we're doing some encryption on that, credential shielding. And then obviously we need to be flexible in how authentication maps happen. If we are going from one domain to another domain, for non-domain to domain, we should be able to employ various profiles for connectivity on the network itself. So that plays to flexible operations. What else? We also want to have mutual authentication between a C2 or commander, if you will, and the agent so that the agent knows who their C2 is at the time of deployment and creation. And also C2 wants to accept only the agents that it knows about. And so that kind of plays into the delivery options and how agents get triggered. Sometimes you hard-code the policy into the agent to, let's say, get moving on air gap network without C2 interaction where you can have an agent on the network and kind of start encrypting things right away without accepting tasks from C2. Or you can go the old route where you dormant until activated, right? Some notes on stealth versus transparency. One of the problems in ransomware is not knowing what's going on once agents are deployed. So we want to make sure we know at all times what's going on. So we run logs on the agent, but those logs are in memory and we're able to retrieve and kind of introspect, get some optics into what's going on. And then obviously, one of the interesting features or needed features in our testing is to be able to kind of clean up after ourselves, killing the agent, popping up notifications that has been killed, or whatever the case may be, removing the threat from the network on their own. So we've talked a lot about the policy. And so the policy is what ties everything together, right? You have flexible connectivity to C2s. You have profiles on connectivity. You've got authentication maps that match credential triplets to hosts that they go to on a domain or not. You also have flexibility on key generation and whether you're encrypting assets with one key per host or you can have flexibility where you have separate keys for each file or mix thereof. You know, you can have situations where you can kind of tier the priority on file. So if one keys are covered, the other one stays kind of encrypted as well. So this brings us to a demo where we can talk about specifics of deployment and operations of Rekiteer toolkit. And we'll come back to discuss other things later. Let's take a look at the operations of Rekiteer. Here we have four windows. There's a C2. There is a utility box that helps manage encryption and master keys, site IDs, as well as decrypt encrypted files offline. And on top there are two windows that represent simulated attack network. There is a non-domain join machine and there is a domain join machine. And so our task for Rekiteer is to go out and use the agent that gets deployed on the non-domain machine to manage, i.e. encrypt the assets on it and then pivot over to the domain box and do exactly that on the other side. So before we talk about the execution of it, we'll like to take a look at the policy file. So the policy file, as we've discussed, is the one that ties the tasks, communication, encryption keys and authentication profiles for the agent as seen by the operator from the outside. And there are multiple sections to it. There's connectivity section with various profiles and security of communications. There is a REST profile and endpoints that needs to talk to. There are keys such as master key and identifier of the site for the agent. And there are also a series of authentication profiles that take the triplets, username, password and domain, or operate on a local asset. And then there is an array of hosts and files that file connector or the agent is able to operate on mixing and matching host keys with file keys. You can repeat these sections as many times as you would like to. This is very contained operations. And so in order for us to task the agent with execution, first we need to start the agent on the remote box. It starts up and we can see that it's running under PID 1940. Then what we can do, we can activate it. Right now it's an appending state. Let's activate the agent. And what we're going to do is we're going to accept the agent to be a part of our communication, which means that we only accept the agents that are the ones that we know about. Then what we can do is we can authenticate the agent to the C2 and the C2 to the agent by specifying the master key you've created before. And so we can send the master key to the agent at which point it will know that it's talking to the C2 that it knows about and has been kind of paired up with. And then what we can do, we can actually do send the policy, which we've specified before. This policy is going to encrypt the assets across the board. It will take a while for it to respond, usually within the profile that you've specified, 5 to 10 seconds or more. And as you can see, the agent actually operates on the assets locally and then goes out using the authentication profile to the domain and encrypting the assets on the other side. And as you can see, those assets are encrypted as we're going to see in the moment they are locked and the customer is kind of forced to operate under those conditions. And the same thing happens here. But the other thing that we need to be able to do if we're not ready to decrypt offline is we're actually reversing the policy. And the reverse of the policy is just a matter of specifying the operations type, flip a bit on encryption and decryption. And so what we're going to do, we're going to flip that policy back into decryption mode. Same thing, PollExec file, decryption, the same keys that you specified, or you can do one by one, decrypt one file, all the files, none of the files. This should work. And once it's decrypting the file, we will be able to see the content as it was there before. And essentially everything should be back to normal. One other thing that I would like to mention is the execution profile in the memory. So we can get the logs on the logs, which means that it will increase the verbosity of the agent and we can do logs get on it. And we'll be able to see what it's doing there. And obviously, to align with our directives of working with perhaps triage teams, what we can do, we can kick off a tabletop exercising by popping up a notification message on the agent or on the host where the agent resides. That basically says, I am here, why don't you start taking care of what I'm doing here. And we can do this with unhiding console message, which will basically lock the box, show the notification, and then the triage process happens. Obviously, less but not least is that we can agent self terminate to clean up after ourselves. This will destage the agent and the box will be clean with all the assets intact. Or the variation on the theme is when agents are locked and the files are locked and the agent is no longer in memory. So how do you recover your assets as you talk to the ransomware team and ransomware team by using the utilities in the utility box are able to use the keys that they've specified in the policy to decrypt files one by one or all. This is Racketeer Toolkit. Okay, we're back. So what can we do to, what does it tell us? It tells us that we are able to kind of simulate the life cycle of controlled ransomware, right? We are able to maintain SLA and uptime on the network, try to deliver the last mile monetization module for the teams that need it, and kind of plug in into the response process, either to support it or kick it off. And also learn more about the ransomware and how, you know, the deficiencies are and the capacity of it is. For defenders, I think it's safe to say that let's not signature this tool but do pay attention to behaviors because artifacts may be minimal because it's all in memory, right? But TTPs still exist, the lateral movement, the sequential encryption of the files. So all of that is still present. So the bottom line is that IOCs are tied to implementation and the agent has been deliberately weakened to showcase the kind of the injection points and analysis points. And obviously, instrument your environments where you correlate operational performance and security messages. And with that, I want to thank everybody who's listened, looked at the demo, watched the demo rather. Here's the link to open source code for the Reketeer. Thank you very much.