 All right, we're back and thank you, Alvaro, for supporting the community, supporting DEFCON for your 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 DEFCON Red Team Village. Welcome to Total Iagresio, a evading intrusion detection system for stealthier implants. So first of all, I would like to introduce myself. My name is Alvaro Folgado, hashtag rebel hacker, and I was a product security engineer. Well, I perform a lot of software and architecture security reviews. I do a lot of offensive app sec, both 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 in a main project that is an implant framework. It's kind of dividing two parts. The first part is SC2, operation manager, growth on Golan. Most of it used the reform to deploy like infrastructure, proxies, and redirectors. And the other half is the modular bichito that is growth on Go, C++, to perform a little bit more of native action over the target device. I had the lag in the past, as I say, to present this framework on the DEFCON 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 I'm going to develop. So the connection here is, you know, in the last year, while 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 an string to address and I shall 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 ones 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 PLS fingerprints, we could perfectly detect that that's a Go, HTTPS client. And, you know, you know, if we kind of wild list 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'm egressing through Gmail, but still not even by, you know, doing a deep packet inspection, not able to do that I'm using some kind of malware. So, you know, this really triggered my attention. So I focus my next year research on them towards like creating kind of a skeleton network model, not just for my tool, but also as a piece of code for every, every rating on the community to be able to use these for bypassing this kind of filtering of these 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 at the network level, I wanted to start a little bit with like a high level vision of kind of the different techniques that a blue team or sister could deploy in a corporate network towards detecting or running in planning 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 or laptop to set the certificate 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 a indicator of compromise or most common like problems, right? But I'm not going to 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 where like or foothold is connecting to. So, you know, the blue team will start to look at things like 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 like serving is self-signed or not? And then they will also could look at the wire itself, which kind of protocol we are using. If there is a huge amount of package load on DNS aggression, and you know, they could say, oh, something is going on here. So, you know, if we come back to the concept of aggressing through 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, if as the opportunity to modify an string, we can make our foothold to communicate through the C2 just by pulling, pushing data on it. And now it's where it comes 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 are 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 aggressive, 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 all hosts introduced in the technical 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 I was saying with this research, they published it with this GA3 tool, so it's 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 an implant, and now we need to think about how he's going to address 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 you said HTTPS, the first thing that the 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 CIFRs you want to use, but particularly which kind of extensions you want to use, and a lot of these bytes, that really relate 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 implants, 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 CIFRs are really like particular alert to the blue teamers. So if you follow the source code, you can go to the GF32 and see exactly what he's doing when you provide to the Python script in a pickup, but if we go to the YSHA, and we start to listening to the flows, and we just open a browser that is performing HTTPS connection, we can easily filter those packages, and we can see what's going on. We can go to the header of the secure socket layer, and we can see all these particular bytes that we have. And while TLS version and CIFRs are kind of easy to modify, there is a bunch of extensions that are 64, they are accepted by the RFC that can be configured. So the Python screen will just go over that set of packages, divide those bytes in five sections, transform them in dexadecimal, and then generate this MD5 hash that particularly matched a certain version of a software for the client and the server. So okay, where are the red teamers? We know this is a problem, and we know that we may be detected because of this. So now it's where we come to the idea of blending it in the network and trying to like evading these techniques, right? So I had a bunch of ideas. My first idea was, okay, you know, 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 client 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, you know, the hash to decide for copying another client's software. So, you know, this was kind of a tricky one. So my next idea was, okay, I will, you know, just open a TCP socket and throw there my copy of client hello package and see what happens. 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 of my hand dirty and go and modify the source code of the programming language I was using. In this case, it was Golan. So I will say, okay, I will add feature and this is more or less how it works. So, you know, and I'm sure this is similar in all the languages that relate to which kind of language you're using for writing your input, but at least in Golan, when you want to, yes, you need to graph your HTTP client and when you create 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 POSCET 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 problems I was telling me for, we don't have a feature where we can like put whatever bytes we want to. So I modify the source code of Golan and HTTP client to accept in the TLS configuration a new string input and this string input will be exactly what the GA3 tool provides to us. So in that case, we can use GA3 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 need to add another part of the code, you are like marshaling or creating this claim, hello. I added a for loop and for each decimal 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 decimal bytes in the right order, you can extract the fingerprint of the browser you are targeting. It's true that a lot of them, I'm sure this extension will be modified with time, but I have enough right now entropy or availability of the decimal bytes already for like setting most of the browser. If you feel that you need more decimal 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 we need for copying rightful connection of browsers and any other like software you like, antivirus, regression, whatever. But now it's kind of the problem that we want to address using Gmail. That I need to config to change on the source code. So let's say 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 for 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. We'll provide both the credentials to the digital alongside with the TLS fingerprint. And then the implant will start with the aggression. And for the aggression, the first thing he will do is using the refresh token against the Google authentication servers. And then when he gets the access token, he 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 received commands perfectly and totally transparent into the operator. At the eyes of the blue team that is looking at this proxy, it will just look like a Chrome browser, which is good to go. So to speak a little bit about Deepak's inspection on how we can bypass or avoid this stuff. So, you know, if we have the bad luck that the SOC or the system is gripping common stream within or like flow against Gmail, we could kind of use some kind of later your cryptography and share a symmetric key with the C2 and then common grips or common arrays will not pop up. If we have the bad luck that it's a flat hunter catching our flaws, 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 Cista time is just doing the similar thing, putting on the body of the draft whatever JSON payload we want to process by height, but instead of just putting plain strings, we can use like encrypting with this symmetric key. I have still not developed this full model, but it will be added to Cista time in the future. So let's go ahead with the demo. So what I have created here is to 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 a graphical interface of Cista 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 G32. 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 is I am using a BIMI Work 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 it gets through email is going to be really by a one to server that is a polar proxy. It's a TLS proxy with polar proxy, which is not the most interesting. The important thing is running a suricata network detection system and you have a bunch on alert just to like detect that if the TLS fingerprint is going to be declined to show me an alert, if not, you can go ahead. Let's go to the demo. As you can see here, this is a graphical interface of Cista 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 use the load executable and somehow we will make the foothold to execute through any attack vector we want to. This is the one to 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 g3 plugin for suricata and they will get the the header of the TLS connection of every aggression package they will generate an MD5 hash. If that hash matches this one, we will pop up an alert. We can check that these two hashes, they match by the public database of VF3, a Go HTTP client. So let's search for the hash, similarly to virus total, 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 configurations, it's changed by using a Go HTTP client. At the end of the day, all those hashes, they will be registered with this public database. So we have two appearance on the load of suricata and the reason is because I was saying before one request for getting the access token for the Google authorization servers and the second one is for pushing pooling 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 creating with CSTA time and with the TLS fingerprints for Chrome browser. So the creation of the implant is just the same process. What is going to change is 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 wire shack and let's start to like detect and read all the packets that are going through the TLS proxy. And the objective of this is since we don't maybe don't trust what the suricata is saying to us, let's make sure that this fingerprint is a Chrome browser instead of going to the decline. So let's filter, let's get all the make hello and then let's export it in a pickup and we can use this pickup for like a G3 to parse it and tell to us which end of 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 for any other rightful software. So here you see there is like this five section of bias. This one will be the input for the suricata inflame. We want to generate an implant with these fingerprints and there is two different MD5 hashes because as this is a TLS proxy, you know, 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 G3 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 progress. So if we go back to just a time graphical interface, we can see we already have the host infected. We have a kill 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 secret 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 the defender, how to make them better because at the end of the day, you know, the routine operation is have a lot of reasons, 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 networking through 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 is, you know, going through all these extensions by it, so 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 bytes inside this, like a nonial layer, right? And this is something that G3 is not doing right now. That we always generate more MB5 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 networking through detecting techniques, but, you know, focusing on the host, introducing the 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 it might be cheating, it's still doing not so straightforward actions against the operating system. And you know, this could be easily detected, like, you know, Omega CMD.exe, for persisting use, calling the APIs of the windows, this could be like a little bit more like 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 CSI 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.