All right, we're back.
And thank you, Alvaro, for supporting the community,
supporting DEF CON, for, of course, presenting here,
and definitely supporting the Red Team Village as well.
We're glad to have you here, and the floor is yours.
Take it away.
Thank you so much, Omar.
I'm so happy to be here another year
presenting the DEF CON Red Team Village.
Welcome to Total Eagresio,
Evading Intrusion Detection System for Stealthier Implants.
So, first of all, I would like to introduce myself.
My name is Alvaro Folgado, hashtag Rebuhacker,
and I was a product security engineer
where I perform a lot of software
and architecture security reviews.
I do a lot of offensive appsec, bug hunting,
a little bit of research about this last topic.
But in my free time, I have been spending
more or less the last two years
working on a main project that is an implant framework.
It's kind of divided in two parts.
The first part is the C2 operation manager,
that is grown on Golang.
Most of it, like, it used Terraform
to deploy, like, infrastructure, proxies, and redirectors.
And the other half is the modular Vegeto
that is grown on Go, C++, and OGTC
to perform a little bit more of, like,
native action over the target device.
I have the lag in the past, as I say,
to present this framework on the DEF CON Red Team Village
of the past year alongside Shellcon.
I am here again to speak a little bit
of this kind of same topic,
but connected to other stuff that I'm gonna develop.
So the connection here, it's, you know,
in the last year when I was presenting this framework,
one of the stuff that I was kind of most proud about
is, like, the ability of my implant of egressing,
not just using HTTPS against a custom server,
but using Gmail itself.
And I was saying in my talk, like, you know,
give me a string to egress and I should hack the planet
because, you know, you can use Gmail,
but you can use any other software service.
And from that talk,
I got an amazing amount of cool feedback.
But, you know, one of the most interesting one
was from one Blue Team engineer back then
that told me, you know, this looks cool,
but you know that by analyzing some header of your flow,
like the TLS fingerprints,
we could perfectly detect that that's a Go HTTP client.
And, you know, if we kind of,
while this is the kind of software we have
in the domain host of a corporate network,
that will look sketchy.
So I was like, okay, so you're telling me
I am egressing through Gmail,
but still not even by, you know,
doing a deep packet inspection,
we are able to detect I'm using some kind of malware.
So, you know, this really triggered my attention.
So I focused my next year research on them
towards like creating kind of an skeletal network model,
not just for my tool,
but also as a piece of code for every,
everything around the community to be able to use this
for bypassing this kind of filtering of this kind of rules
that the Blue Team could have
deployed in a corporate network.
So, you know, if we focus on this, you know,
on this field and we really want to like look stealthy
on the network level,
I wanted to start a little bit like a high level vision
of kind of the different techniques
that the Blue Team could deploy in a corporate network
towards detecting or running implant in a foothold
just by looking at the network package.
So I like to divide in kind of like two big parts, right?
We have all the deep packet inspection techniques
where, you know, somehow the Blue Team has deployed
the infrastructure to force every domain host
network package to go through a proxy, right?
And this proxy normally is a TLS proxy
that filter out all this flow
and make the target operating system
all up to accept the certificates.
So I can deep look at the body of the flow.
And then, you know, by looking at this body,
I can get kind of common strings that match to malware
and I can try to create a set of fine grained rules
to detect which one are the flows that match
most common like indicative of compromise
and most common like problems, right?
But I'm not gonna get still really deep
into these techniques.
I want to focus a little bit
in not deep packet inspection techniques, right?
That those techniques will be focused
not in what the body of the payload is,
but more in things like where the aggression is going, right?
Which is the server or foothold is connecting to.
So, you know, the Blue Team will start to look
at things like a sketchy IP range,
or if we are using some kind of service like Amazon or Azure,
they can start to look at the domain, right?
Which kind of domain we are using.
And if we use something like domain fronting,
they start to look at,
oh, which kind of operating system or software
is listening to the connection, right?
Which kind of certificate is this server like serving?
Is self-signed or not?
And then they will also could look at the wire itself,
you know, which kind of protocol we are using.
If there is a huge amount of package load on a DNS aggression,
you know, they could say, oh, something is going on here.
So, you know, if we come back to the concept
of aggressing to a software as a service, like email,
then we can finish with all the problems
of detection by the endpoint, almost all of them.
And we can do this easily because if it's a software
as a service, it has the opportunity to modify on a string,
we can make our foothold to communicate through the C2
just by pulling, pushing data on it.
And now it's where you come to the funny part,
like we have finished with the problem with the endpoint,
but still the blue team has powerful tools
to analyze which kind of HTTP client we're using.
And they can say, oh, this domain host
is using a common browser.
That looks good to me, but oh, this human resource laptop
is running a Python script to go to whatever server
or a Go client.
That kind of look a little bit more sketchy.
So at the end of the day,
the blue team has a powerful tool to analyze
before breaking the encryption through TLS fingerprints,
which kind of software the foothold is using for this,
which kind of software we are using,
or redirect, or proxy, or whatever,
to receive the connection.
And by matching both of them,
they could get a really strong indicator of compromise.
This will work similarly to like antivirus
or host intrusive detective system,
where they will extract a hash from the binary
and compare it with a public database.
Instead of now doing that with the binary,
they will do that with a TLS handshake,
and they will extract a certain number of bytes,
perform a hash, and compare it with a public database.
This is around a really interesting research
that was done time ago by a bunch of blue team engineers.
And alongside with this research,
they publish it with this GA3 tool.
This is a Python script.
I'm going to do a little bit of a deep dive,
what's going on.
So let's imagine we're writing our implant,
and now we need to think about how he's going to egress
or how he's going to connect to the C2, right?
So if we are going to use HTTPS,
and a lot of you will say,
okay, don't use HTTPS, use HTTP,
but for some reason we need to use HTTPS,
or endpoint for some reason uses HTTPS.
The first thing that our implant will perform
is opening a TCP socket.
And following that TCP socket,
the TLS handshake will start.
And that TLS handshake has a lot of information on it,
because first the client is going to tell to the server
which kind of TLS version we want to use,
which kind of C4CZ you want to use,
but particularly which kind of extension you want to use.
And a lot of these bytes,
they're really related to the kind of software we are using
or the kind of library we are using to write our implant.
In the same way, the server will do the same.
So the Python script will parse this pickup of,
you know, if we're using YSHA or any other software
to get them, and then we'll just select this package
and we'll analyze the bytes, transform them in MD5 hash
and match them to a really particular software.
If we're writing with our implant,
sometimes we rely on those libraries,
and other times we're going to use some software
that is already matched,
and it's already like,
give us a really particular alert to the blue timers.
So if you follow the source code,
you can go to the GF3 tool
and see exactly what he's doing when you provide
to the Python script a pickup.
But if we go to the YSHA,
and we start to listen to the flows,
and we just open a browser
that is performing HTTPS connection,
we can easily filter those package
and we can see what's going on.
We can go to the header of the SQL Socket layer
and we can see all these particular bytes that we have.
And while TLS version and CIFS are kind of easy to modify,
there is a bunch of extension that are assisted
by the RFC that can be configured.
So the Python script will just go over that set of package,
divide those bytes in five section,
transform them in hexadecimal,
and then generate this MD5 hash
that particularly match a certain version of a server
for the client and the server.
So, okay, where are the red timers?
We know this is a problem
and we know that we may be detected because of this.
So now it's where it becomes the idea
of blending in the network
and trying to like evading these techniques, right?
So I had a bunch of ideas.
My first idea was,
okay, I'm using a programming language.
This programming language gave me the option
to create my own HTTP client,
choose the library I want to.
But the problem is like most of the HTTP clients
that accept TLS configuration,
while they provide you a lot of bytes
for configuring your own TLS handshake,
they really don't provide you like an input
where you can put all the bytes you like
and the order you like.
So you can have the hash to decide
for copying another client software.
So this was kind of a tricky one.
So my next idea was, okay,
I will just open a TCP socket
and throw there my copy client hello package
and see what happened.
Obviously the TLS handshake breaks
and it's not interesting to us
because at the end of the day,
we need to use HTTPS.
So my last option were like getting a little bit
my hands dirty and go and modify
the source code of the programming language
I was using in this case was Golang.
So I will say, okay, I will add a feature
and this is more or less how it works.
So, you know, and I'm sort of similar
in other languages that relate
to which kind of language you're using
for writing your input,
but at least in Golang,
when you want to address,
you need to graph your HTTP client.
And when you graph the HTTP client
and you want to use HTTPS,
you provide the TLS configuration
that is like a struct.
Before requesting to the endpoint
with a post get,
whatever HTTP request you want to,
the language will go through
the flow of crafting this TLS hello.
And it will take kind of your configuration
and then grab up the bytes
and send them to perform the handshake.
The problem is, I was telling before,
we don't have a feature
where we can like put whatever bytes we want to.
So I modify the source code of Golang
and HTTP client to accept
in the TLS configuration,
a new string input.
And this string input will be exactly
what the GF3 tool provide to us.
So in that case,
we can use like GF3 tool
for copying a Chrome Firefox Opera browser
and throwing in the compilation of our implant.
In that way, when you go to TLS,
the TLS flow,
and you need to add another part of the code
where you are like marshalling
or creating this client hello,
I added a for loop
and for each hexadecimal value,
I kind of copy a reference,
which is the package
or the syntax that respect the RPC.
So if you have a bunch
of hexadecimal bytes in the right order,
you can extract the fingerprint
of the browser you are targeting.
It's true that a lot of them,
and I'm sure this extension
will be like modified with the time,
but I have enough right now,
entropy or availability
of like hexadecimal bytes already caught
for like accepting most of the browser.
If you feel that you need
more hexadecimal bytes,
I will add them.
There is no problem.
The source code is already published
in these links on GitHub.
So, okay.
Now we have the HTTPS client
that we need for copying
rightful connection of browsers
and any other like software you like,
antivirus, aggression, whatever.
But now it came the problem
that we want to address using Gmail.
That I need to change on the source code.
So that's it.
I want to like provide you a flow
of how this implant will work
on the background,
once we get the execution on the foothold.
So when we craft our implant,
the first thing we need to have
is the Gmail connected app.
We configure it
and we provide those credentials
to the C2.
And the C2 on the completion of the implant
will provide both the credential
to the digital alongside
with the TLS fingerprint.
And then the implant will start
with the aggression.
And for aggression,
the first thing he will do
is using the refresh token
against the Google authentication servers.
And then when he get the access token,
we will start to like push,
pull information through Gmail.
The C2 or the operation server
will do similarly.
And we could create a data connection
for sending or receiving commands perfectly
and totally transparent to the operator.
At the eyes of the blue team
that is looking to this proxy,
it will just look like a Chrome browser,
which is good to go.
So to speak a little bit
about DeepPacket inspection
or how we can bypass or avoid this stuff.
So, you know,
if we have the bad luck
that the sock or the scissor
is gripping common string
within or like flow against Gmail,
we could kind of use some kind
of later cryptography
and share a symmetric key with the C2
and then common grips
or common errors will not pop up.
If we have the bad luck
that it's a threat hunter
catching our flows,
we can also use other techniques
like stenography.
It wouldn't be as difficult
because also Gmail provides us
the ability to attach images
to the draft emails.
So a little bit
of how the network model
with the encryption will work
in Siesta time is using
the similar thing,
putting on the body of the draft
whatever JSON payload
we want to process by height.
But instead of just putting
playing the strings,
we can use like encrypting
with the symmetric key.
I have still not developed
this full model,
but it will be added
to Siesta time in the future.
So let's let's go ahead
with the demo.
So what I have created here
is trying to reproduce
this environment
where the blue team has deployed
this kind of detection
technique in a network.
I have created
two different implants.
This is the graphical interface
of Siesta time.
And alongside all the inputs
that I'm not going to speak
about each one of them,
particularly we see here
we have this TLS fingerprint
with an extra 4G S3 tool.
In that way,
we can create different implants
that mimic
whatever connection we want to.
If we focus a little bit
the network topology of the demo,
what this is going to look like
I am using a BIMI workstation
with three machines on it.
But particularly interesting
is we have the Windows 10
foothold that is going to run
two different implants
and every connection
that I get through email
is going to be read
by a Ubuntu server
that is a TLS proxy
with Polar Proxy,
which is not the most interesting.
The important thing
is running a Suricata
network interface detection system.
And you have a bunch of alerts
just to like detect
that if the TLS fingerprint
is not going to the client
to show me an alert,
if not, you can go ahead.
So let's go to the demo.
So as you can see here,
this is a graphical interface
of siesta time.
These are all the jobs
that the Hive has processed already.
And now we have two implants
that are created.
That means we can just
download the executable
and somehow we will make
the foothold to execute
through any attack vector we want to.
So this is the Ubuntu machine
that is listening
to all the connection
or the aggression of the foothold.
And we have the Suricata running on it.
Suricata will match
the two following rules.
These two rules,
they're using a GS3 plugin
for Suricata,
and they will get the header
of the TLS connection
of every aggression package.
They will generate an MD5 hash.
If that hash match this one,
we will pop up an alert.
We can check that these two hashes,
they match by the public database
of GS3, a Go HTTP client.
So let's search for the hash,
similarly to VirusTotal,
but with TLS fingerprints.
We see this is a Go HTTP client, right?
We are going to run the first implant
in the Windows 10 foothold
and we're going to be detected.
So the interesting thing
about these two is like,
obviously, this Go client
is going to be using
the default configuration,
but we can change things.
But the cool thing about this is like,
it doesn't matter
how many configuration is changed
by using a Go HTTP client.
By the end of the day,
all those hashes,
they will be registered
with this public database.
So we have two appearances
on the log of Suricata.
And the reason is
because I was saying before,
one request is for getting the access token
for the Google authorization servers.
And the second one is for pushing,
pulling data from Hive through Gmail.
So let's clean the logs.
And now we are going to do
exactly the same,
but using the implant
that has been created
with siesta time
and with the TLS fingerprint
of a Chrome browser.
So the creation of the implant
is just the same process,
which is going to change
with the execution of it
and how we detect it.
And the data flow is just the same.
So let's execute the implant
that now is copying
the fingerprint of a Chrome browser.
And let's go back to the Suricata.
And we see there is no any log,
but let's recheck what's going on.
So let's open a Wireshark
and start to detect
and read all the packets
that are going through the TLS proxy.
And the objective of this is,
since we maybe don't trust
what Suricata is saying to us, right?
Let's make sure
that this fingerprint is a Chrome browser
instead of a Go HTTP client.
So let's filter,
let's get all the main hello,
and then let's export it in a pickup.
And we can use this pickup
for like a GS3 to parse it
and tell to us
which fingerprints of bytes
is detecting from this aggression.
This way will be the same
that we need to follow
if we need to copy the TLS fingerprint
from any other rightful software.
So here you see there is like
this five section of bytes.
This one will be the input
for CSTATIME frame
we want to generate an implant
with these fingerprints.
And there is two different MD5 hashes
because as this is a TLS proxy,
there is a second fingerprint
for polar proxy itself.
But if we go and we take the fingerprint
of the implant,
we are going to see
that this is effectively
the public database GS3
is effectively pointing it
to a Chrome browser
instead of a Go HTTP client
or a Java client,
Python client,
whatever we have HTTP library
we have used for our implant to address.
So if we go back
to CSTATIME graphical interface,
we can see we already have the host infected.
We have killed one implant.
So that's offline,
but the other is still alive.
So now we can do things like,
you know, injecting a shell
or injecting a reverse SQL shell.
We have all the information
from the target host that we have infected.
And we also have like, you know,
an asynchronous interactive shell.
And all these will happen
totally transparent to the operator
and through email.
You see the fingerprints we need.
So,
I want to speak last but not least,
how to help defender,
how to make them better
because at the end of the day,
you know, the routing operation
is have a lot of reason,
but we want to make the defenders
to be better, right?
And to be prepared to this kind of attack.
So if I focus on the network
intrusive detecting techniques
and in the TLS,
a fingerprint detection,
if you ask me if there is gap of improvement,
I will say, yes.
There is for one reason
that the Python script of GS3,
it's, you know,
going through all these extensions by it.
So they will, the big entropy happens,
but it's just taking the headers.
You know, the Python screen,
we could write a new for loop
for like getting more byte inside
this like an onion layer, right?
And this is something that GS3
is not doing right now.
That we always generate more md5 hashes
and more different
entropy to search.
But that's it.
That's cool.
But this is the catch of the mouse.
If they do that,
I will use another for loop in my HTTPS client
and then we're in the same.
What I think is interesting
is not just using network intrusive detecting technique,
but, you know,
focusing on the host intrusive detecting techniques
or now called EDR
and trying to match kind of the two signatures
and see if something is going on.
I say this because while my VGTO
is regressing really efficiently,
this is still doing not so like a straightforward actions
in the operating system.
And, you know, this could be easily detected.
Like, you know,
when we can see md.x as a forward cell x
or for persisting use,
calling the APIs of a schedule that's on Windows.
This could be like a little bit more like a shiny
at the hour of detection.
So that's everything.
Thank you so much.
The source code is already published for everything.
And there is a user guide
for the CSTATIME framework as well.
I have the Discord and I can answer questions.
So just let me know.
Okay. Yeah.
The slides will be,
I will publish the slides.
Source code is there.
There is user guide.
Yeah.
So that's everything.
Thank you so much.