- Hello Defcon,
welcome to my talk,
Racketeer Prototyping Control Ransomware Operations.
My name is Dimitry Snezhkov.
I work at Protiviti on attack and penetration testing team,
we have a chance to do tooling,
offensive research and automation.
And today we're gonna talk about ransomware.
Specifically we're gonna 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 gonna be split in two phases.
The first phase,
we're gonna 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 Racketeer toolkit tick.
Let's start.
So ransomware is definitely a technical issue.
It's implemented in technology,
but what fascinates me about ransomware
is it's just a, 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 the 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 an 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 a ransomware is much smaller
than a lot of other cyber offensives
and with advent
or actually use of crypto monetization activation path
is fast, right?
You can actually say that even the attribution
is getting much more fragmented than before.
And obviously with such a 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,
do your incident response triage.
And one more thing is to add external negotiation
with the 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 achieve,
is essentially trying to emulate the path
and the lifecycle of ransomware
and allow the teams to kinda 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 and feedback
is what we're gonna talk about.
But before we move on,
let's just distill the lifecycle of ransomware
into three things literally.
Is the persistence where the dropper
actually executes the task on the assets,
be it files or anything else.
Then there is an extortion capability
which may or may not happen in sequence
and you can have offline negotiation,
you can have online kinda IOCs popped in that says,
hey you have t-minus 48 hours to pay us or else...
And then from the ransomware perspective,
there's a destage or decryption capability
that has to happen and potentially cleanup, right?
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 doing collection of indicators of compromise,
they can, the teams can learn from,
and 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, for us as testers,
we have to abide by SLAs and it's good practice
to keep the network intact.
Not perform denial of service on it
or cause denial in our service.
And so this is why we're calling our toolkit
controlled 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 went to make sure
that the customer stays up,
real-time encryption versus offline decryption of assets.
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 gonna 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, just try to build one.
What would be the good agent for our purposes?
Well, let's just start get Windows
because it's the most prevalent
kind of target for ransomware, historically,
obviously that can be adapted to Linux
or cross-platform.
But in this case,
we're gonna take a look at encrypting the local files
on Windows and also encrypting remote files on Windows,
by going across the network.
For example, you can remote into a different box
through that agent and kinda do the encryption
of assets there.
And obviously we need to have control of execution
as we've mentioned before.
The other technical tactical features that we want to have
in this agent is lifetime key management
and key generation.
Has to happen offline
as far as generation because of
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 ID are you 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 from the construction of those features,
what else?
We have to have communication emulation,
how ransomware usually interacts,
obviously encryption non-transmission layer,
but also application level message encryption for the agent.
That's become very prevalent
and we need to be able to kind inject into that.
It operates on or emulates an ransomware
that does arrest communication,
that your pub/sub type of deal,
where you come in and ask for the task,
execute it, upload the results and whatnot, right?
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 the user to go to a remote box on the network,
IE laterally move to it.
We want to make sure we put security on credentials, right?
We don't want a clear text crass.
So we're doing some encryption
on that, credential shielding, all right?
And then obviously we need to be flexible
in how identification maps happen.
If we're going from one domain to another domain,
from non-domain to domain,
we should be able to employ various profiles
for connectivity on the network itself.
So that place still flexible operations.
What else?
We also want to have mutual authentication
between a C2 or a 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 kinda 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 drop in,
you can have an agent on the network
and kinda start encrypting things right away
without accepting tasks from C2.
Or you can go the old route
where you're dormant until activated, right?
Some notes on a 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 kinda 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 notification that it 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 and connectivity,
you've got authentication maps
that match credential triplets to hosts
that they go to, on a domain or not.
You also have a 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 there are of,
you can have situations
where you can kinda tier the priority on file,
files of one keys are covered, the other one stays.
Mistakes kinda encrypted as well.
So this brings us to a demo
where we can talk about specifics of deployment
and operations of a racketeer toolkit,
and we'll come back to discuss other things later.
Let's take a look at the operations of Racketeer.
Here, we have four windows,
there's a C2.
there is a utility box that helps manage encryption,
and a master key site IDs,
as well as encrypted files offline.
And on top of there are two windows
that represent simulated attacked network.
There is a non-domain joined machine
and there is a domain joined machine.
And so our task for Racketeer is to go out
and use the agent that gets deployed
on the non-domain machine to manage IE 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 you to take a look at the policy file.
So the policy file,
as we've discussed as 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 arrest profile and endpoints
that are used to talk to,
there are keys such as MasterKey
and the identifier of the site for the agent.
And there are also a series of authentication profiles
that take the triplets, username, password,
and then domain or operate in a local asset.
And then there is 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 then we can see that it's running under PID 1940.
Okay?
Then what we can do, we can activate it.
Right now, it's in the pendency state
let's activate the agent.
And what we're gonna do is, we're gonna accept the agent
to be as part of our communication,
which means that we only accept the agents
that are the ones that we know about.
Okay?
Then what we can do is,
we can authentic 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 masterkey to the agent
at which point it will know that it's talking to the C2
that it knows about and has been kinda paired up with.
And then what we can do,
we can actually do send the policy,
which we have 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,
five 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.
Then as you can see,
those assets are encrypted,
as we're gonna see in the moment.
They are locked
and the customer is kinda 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 operation style.
Flip the bit on encryption and decryption.
And so what we're gonna do,
we're gonna flip that policy back into decryption mode.
Same thing, polexec, file decryption
with 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 after 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 and the memory.
So we can get the logs.
(keyboard clutters)
Logs set debug
on the logs,
which means that they will increase the verbosity
of the agent and we can do logs to 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 again, 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.
You know, obviously last but not least
is that we can agent self terminate
to clean up after ourselves.
This we'll destage the agent and it will be,
the box will be clean with all the assets intact
or the variation on the theme is when agents are locked
or the files are locked
and the agent is no longer in memory.
How do you recover your assets
as you talk to the ransomware team
and the ransomware team by using the utilities
and 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 our time on the network,
tried to deliver the last mile monetization module
for the teams that need it
and kinda plug in into the response process
either to support it or kick it off,
and also learn more about the ransomware
and how the deficiencies are in the capacity of it is.
So for defenders,
I think it's safe to say that,
let's not signature this tool,
but do pay attention to behaviors because artifacts
maybe minimum because it's all in memory rate,
but TTPs still exists.
The lateral movement,
the sequential encryption of the files.
So all of that is still present.
So 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 wanna thank everybody who's listened,
looked at the demo,
watched the demo rather,
here's the link to open source code for the Racketeer.
Thank you very much.