[00:00.000 --> 00:01.440] All right, we're back. [00:01.580 --> 00:03.800] And thank you, Alvaro, for supporting the community, [00:03.800 --> 00:07.500] supporting DEF CON, for, of course, presenting here, [00:07.500 --> 00:09.880] and definitely supporting the Red Team Village as well. [00:10.820 --> 00:13.260] We're glad to have you here, and the floor is yours. [00:13.260 --> 00:14.100] Take it away. [00:14.480 --> 00:15.620] Thank you so much, Omar. [00:15.620 --> 00:17.700] I'm so happy to be here another year [00:17.700 --> 00:19.900] presenting the DEF CON Red Team Village. [00:19.980 --> 00:21.560] Welcome to Total Eagresio, [00:21.560 --> 00:24.760] Evading Intrusion Detection System for Stealthier Implants. [00:24.780 --> 00:27.260] So, first of all, I would like to introduce myself. [00:27.260 --> 00:30.140] My name is Alvaro Folgado, hashtag Rebuhacker, [00:30.140 --> 00:31.780] and I was a product security engineer [00:32.360 --> 00:33.700] where I perform a lot of software [00:33.700 --> 00:35.560] and architecture security reviews. [00:35.560 --> 00:39.060] I do a lot of offensive appsec, bug hunting, [00:39.420 --> 00:41.820] a little bit of research about this last topic. [00:41.820 --> 00:43.880] But in my free time, I have been spending [00:43.880 --> 00:45.520] more or less the last two years [00:45.520 --> 00:49.540] working on a main project that is an implant framework. [00:49.760 --> 00:51.380] It's kind of divided in two parts. [00:51.380 --> 00:54.140] The first part is the C2 operation manager, [00:54.140 --> 00:55.220] that is grown on Golang. [00:55.720 --> 00:57.520] Most of it, like, it used Terraform [00:57.520 --> 01:00.660] to deploy, like, infrastructure, proxies, and redirectors. [01:00.660 --> 01:02.760] And the other half is the modular Vegeto [01:02.760 --> 01:04.840] that is grown on Go, C++, and OGTC [01:04.840 --> 01:06.440] to perform a little bit more of, like, [01:06.440 --> 01:09.080] native action over the target device. [01:09.080 --> 01:10.980] I have the lag in the past, as I say, [01:10.980 --> 01:14.200] to present this framework on the DEF CON Red Team Village [01:14.200 --> 01:16.020] of the past year alongside Shellcon. [01:16.020 --> 01:18.280] I am here again to speak a little bit [01:18.280 --> 01:19.740] of this kind of same topic, [01:19.740 --> 01:22.760] but connected to other stuff that I'm gonna develop. [01:22.760 --> 01:25.040] So the connection here, it's, you know, [01:25.040 --> 01:28.340] in the last year when I was presenting this framework, [01:28.340 --> 01:31.280] one of the stuff that I was kind of most proud about [01:31.280 --> 01:34.220] is, like, the ability of my implant of egressing, [01:34.220 --> 01:37.120] not just using HTTPS against a custom server, [01:37.120 --> 01:38.680] but using Gmail itself. [01:39.040 --> 01:41.000] And I was saying in my talk, like, you know, [01:41.000 --> 01:43.300] give me a string to egress and I should hack the planet [01:43.300 --> 01:44.640] because, you know, you can use Gmail, [01:44.640 --> 01:46.960] but you can use any other software service. [01:47.240 --> 01:48.620] And from that talk, [01:48.620 --> 01:51.100] I got an amazing amount of cool feedback. [01:51.100 --> 01:53.280] But, you know, one of the most interesting one [01:53.280 --> 01:56.400] was from one Blue Team engineer back then [01:56.400 --> 01:59.300] that told me, you know, this looks cool, [01:59.300 --> 02:02.000] but you know that by analyzing some header of your flow, [02:02.000 --> 02:03.520] like the TLS fingerprints, [02:03.520 --> 02:06.660] we could perfectly detect that that's a Go HTTP client. [02:06.660 --> 02:08.320] And, you know, if we kind of, [02:08.320 --> 02:09.840] while this is the kind of software we have [02:09.840 --> 02:11.900] in the domain host of a corporate network, [02:11.900 --> 02:13.280] that will look sketchy. [02:13.280 --> 02:16.100] So I was like, okay, so you're telling me [02:16.100 --> 02:17.340] I am egressing through Gmail, [02:17.340 --> 02:19.860] but still not even by, you know, [02:19.860 --> 02:21.060] doing a deep packet inspection, [02:21.060 --> 02:23.640] we are able to detect I'm using some kind of malware. [02:23.740 --> 02:25.820] So, you know, this really triggered my attention. [02:25.820 --> 02:28.400] So I focused my next year research on them [02:29.240 --> 02:32.260] towards like creating kind of an skeletal network model, [02:32.260 --> 02:33.260] not just for my tool, [02:33.260 --> 02:35.980] but also as a piece of code for every, [02:35.980 --> 02:39.740] everything around the community to be able to use this [02:39.740 --> 02:43.160] for bypassing this kind of filtering of this kind of rules [02:43.160 --> 02:44.580] that the Blue Team could have [02:44.580 --> 02:46.880] deployed in a corporate network. [02:46.880 --> 02:50.620] So, you know, if we focus on this, you know, [02:50.620 --> 02:54.400] on this field and we really want to like look stealthy [02:54.400 --> 02:55.700] on the network level, [02:55.700 --> 02:58.600] I wanted to start a little bit like a high level vision [02:58.600 --> 03:00.680] of kind of the different techniques [03:00.680 --> 03:03.260] that the Blue Team could deploy in a corporate network [03:03.260 --> 03:05.840] towards detecting or running implant in a foothold [03:05.840 --> 03:08.020] just by looking at the network package. [03:08.020 --> 03:11.580] So I like to divide in kind of like two big parts, right? [03:11.580 --> 03:14.480] We have all the deep packet inspection techniques [03:14.480 --> 03:18.200] where, you know, somehow the Blue Team has deployed [03:18.840 --> 03:21.440] the infrastructure to force every domain host [03:21.440 --> 03:23.900] network package to go through a proxy, right? [03:23.900 --> 03:25.660] And this proxy normally is a TLS proxy [03:26.620 --> 03:28.640] that filter out all this flow [03:28.640 --> 03:31.520] and make the target operating system [03:31.520 --> 03:33.100] all up to accept the certificates. [03:33.100 --> 03:35.740] So I can deep look at the body of the flow. [03:35.740 --> 03:37.840] And then, you know, by looking at this body, [03:37.840 --> 03:40.380] I can get kind of common strings that match to malware [03:40.380 --> 03:43.780] and I can try to create a set of fine grained rules [03:43.780 --> 03:45.980] to detect which one are the flows that match [03:45.980 --> 03:48.580] most common like indicative of compromise [03:48.580 --> 03:50.600] and most common like problems, right? [03:50.820 --> 03:53.740] But I'm not gonna get still really deep [03:53.740 --> 03:54.740] into these techniques. [03:54.740 --> 03:56.000] I want to focus a little bit [03:56.000 --> 03:58.560] in not deep packet inspection techniques, right? [03:58.980 --> 04:00.760] That those techniques will be focused [04:00.760 --> 04:03.100] not in what the body of the payload is, [04:03.100 --> 04:06.980] but more in things like where the aggression is going, right? [04:06.980 --> 04:10.220] Which is the server or foothold is connecting to. [04:10.520 --> 04:12.260] So, you know, the Blue Team will start to look [04:12.260 --> 04:14.720] at things like a sketchy IP range, [04:14.720 --> 04:18.060] or if we are using some kind of service like Amazon or Azure, [04:18.060 --> 04:19.800] they can start to look at the domain, right? [04:19.800 --> 04:21.500] Which kind of domain we are using. [04:21.540 --> 04:23.680] And if we use something like domain fronting, [04:23.680 --> 04:24.660] they start to look at, [04:24.660 --> 04:26.740] oh, which kind of operating system or software [04:26.740 --> 04:28.880] is listening to the connection, right? [04:28.880 --> 04:33.520] Which kind of certificate is this server like serving? [04:33.520 --> 04:35.460] Is self-signed or not? [04:35.700 --> 04:38.860] And then they will also could look at the wire itself, [04:38.860 --> 04:41.220] you know, which kind of protocol we are using. [04:41.220 --> 04:46.300] If there is a huge amount of package load on a DNS aggression, [04:46.300 --> 04:48.600] you know, they could say, oh, something is going on here. [04:48.640 --> 04:52.100] So, you know, if we come back to the concept [04:52.100 --> 04:55.440] of aggressing to a software as a service, like email, [04:55.440 --> 04:57.860] then we can finish with all the problems [04:58.420 --> 05:01.920] of detection by the endpoint, almost all of them. [05:01.920 --> 05:04.040] And we can do this easily because if it's a software [05:04.040 --> 05:07.140] as a service, it has the opportunity to modify on a string, [05:07.140 --> 05:09.760] we can make our foothold to communicate through the C2 [05:09.760 --> 05:12.060] just by pulling, pushing data on it. [05:12.460 --> 05:14.160] And now it's where you come to the funny part, [05:14.160 --> 05:16.840] like we have finished with the problem with the endpoint, [05:16.840 --> 05:18.920] but still the blue team has powerful tools [05:18.920 --> 05:22.100] to analyze which kind of HTTP client we're using. [05:22.100 --> 05:24.580] And they can say, oh, this domain host [05:24.580 --> 05:25.840] is using a common browser. [05:25.840 --> 05:28.860] That looks good to me, but oh, this human resource laptop [05:28.860 --> 05:32.300] is running a Python script to go to whatever server [05:32.300 --> 05:33.440] or a Go client. [05:33.440 --> 05:35.800] That kind of look a little bit more sketchy. [05:35.800 --> 05:37.860] So at the end of the day, [05:37.860 --> 05:40.680] the blue team has a powerful tool to analyze [05:40.680 --> 05:45.140] before breaking the encryption through TLS fingerprints, [05:45.140 --> 05:49.060] which kind of software the foothold is using for this, [05:49.060 --> 05:50.460] which kind of software we are using, [05:50.460 --> 05:52.340] or redirect, or proxy, or whatever, [05:52.340 --> 05:53.800] to receive the connection. [05:53.800 --> 05:55.660] And by matching both of them, [05:55.660 --> 05:58.340] they could get a really strong indicator of compromise. [05:59.140 --> 06:01.700] This will work similarly to like antivirus [06:01.700 --> 06:04.080] or host intrusive detective system, [06:04.080 --> 06:06.360] where they will extract a hash from the binary [06:06.360 --> 06:08.240] and compare it with a public database. [06:08.240 --> 06:10.780] Instead of now doing that with the binary, [06:10.780 --> 06:12.820] they will do that with a TLS handshake, [06:12.820 --> 06:15.280] and they will extract a certain number of bytes, [06:15.280 --> 06:17.900] perform a hash, and compare it with a public database. [06:17.900 --> 06:19.900] This is around a really interesting research [06:19.900 --> 06:23.720] that was done time ago by a bunch of blue team engineers. [06:23.920 --> 06:25.980] And alongside with this research, [06:25.980 --> 06:28.600] they publish it with this GA3 tool. [06:28.600 --> 06:29.960] This is a Python script. [06:30.260 --> 06:32.400] I'm going to do a little bit of a deep dive, [06:32.400 --> 06:33.120] what's going on. [06:33.120 --> 06:35.320] So let's imagine we're writing our implant, [06:35.320 --> 06:38.140] and now we need to think about how he's going to egress [06:38.140 --> 06:40.300] or how he's going to connect to the C2, right? [06:40.300 --> 06:43.140] So if we are going to use HTTPS, [06:43.140 --> 06:44.540] and a lot of you will say, [06:44.540 --> 06:46.480] okay, don't use HTTPS, use HTTP, [06:46.480 --> 06:48.940] but for some reason we need to use HTTPS, [06:48.940 --> 06:51.800] or endpoint for some reason uses HTTPS. [06:51.800 --> 06:53.800] The first thing that our implant will perform [06:53.800 --> 06:55.500] is opening a TCP socket. [06:55.860 --> 06:57.820] And following that TCP socket, [06:57.820 --> 06:59.740] the TLS handshake will start. [07:00.140 --> 07:03.720] And that TLS handshake has a lot of information on it, [07:03.720 --> 07:06.600] because first the client is going to tell to the server [07:06.600 --> 07:09.060] which kind of TLS version we want to use, [07:09.060 --> 07:11.120] which kind of C4CZ you want to use, [07:11.120 --> 07:14.120] but particularly which kind of extension you want to use. [07:14.120 --> 07:15.640] And a lot of these bytes, [07:15.640 --> 07:18.380] they're really related to the kind of software we are using [07:18.380 --> 07:20.920] or the kind of library we are using to write our implant. [07:21.000 --> 07:23.600] In the same way, the server will do the same. [07:23.700 --> 07:27.280] So the Python script will parse this pickup of, [07:27.280 --> 07:28.840] you know, if we're using YSHA or any other software [07:28.840 --> 07:33.300] to get them, and then we'll just select this package [07:33.300 --> 07:36.940] and we'll analyze the bytes, transform them in MD5 hash [07:36.940 --> 07:39.180] and match them to a really particular software. [07:39.600 --> 07:41.460] If we're writing with our implant, [07:41.460 --> 07:43.400] sometimes we rely on those libraries, [07:43.400 --> 07:45.240] and other times we're going to use some software [07:45.240 --> 07:47.080] that is already matched, [07:47.080 --> 07:48.580] and it's already like, [07:48.580 --> 07:52.480] give us a really particular alert to the blue timers. [07:52.940 --> 07:54.240] So if you follow the source code, [07:54.240 --> 07:55.460] you can go to the GF3 tool [07:55.460 --> 07:57.800] and see exactly what he's doing when you provide [07:57.800 --> 07:59.500] to the Python script a pickup. [07:59.540 --> 08:01.800] But if we go to the YSHA, [08:01.800 --> 08:05.000] and we start to listen to the flows, [08:05.000 --> 08:06.120] and we just open a browser [08:06.620 --> 08:08.660] that is performing HTTPS connection, [08:08.660 --> 08:10.320] we can easily filter those package [08:10.320 --> 08:12.180] and we can see what's going on. [08:12.180 --> 08:14.560] We can go to the header of the SQL Socket layer [08:14.560 --> 08:17.740] and we can see all these particular bytes that we have. [08:17.800 --> 08:21.220] And while TLS version and CIFS are kind of easy to modify, [08:21.220 --> 08:23.380] there is a bunch of extension that are assisted [08:24.280 --> 08:26.760] by the RFC that can be configured. [08:26.760 --> 08:30.880] So the Python script will just go over that set of package, [08:30.880 --> 08:33.420] divide those bytes in five section, [08:33.420 --> 08:34.940] transform them in hexadecimal, [08:34.940 --> 08:36.960] and then generate this MD5 hash [08:36.960 --> 08:40.600] that particularly match a certain version of a server [08:40.600 --> 08:42.080] for the client and the server. [08:42.220 --> 08:44.360] So, okay, where are the red timers? [08:44.620 --> 08:45.780] We know this is a problem [08:45.780 --> 08:48.840] and we know that we may be detected because of this. [08:48.900 --> 08:50.720] So now it's where it becomes the idea [08:50.720 --> 08:52.040] of blending in the network [08:52.040 --> 08:56.460] and trying to like evading these techniques, right? [08:56.460 --> 08:58.300] So I had a bunch of ideas. [08:58.300 --> 09:00.200] My first idea was, [09:00.200 --> 09:02.480] okay, I'm using a programming language. [09:02.480 --> 09:04.000] This programming language gave me the option [09:04.000 --> 09:06.300] to create my own HTTP client, [09:06.300 --> 09:07.760] choose the library I want to. [09:07.840 --> 09:10.080] But the problem is like most of the HTTP clients [09:10.080 --> 09:12.100] that accept TLS configuration, [09:12.100 --> 09:14.200] while they provide you a lot of bytes [09:14.200 --> 09:16.740] for configuring your own TLS handshake, [09:16.740 --> 09:18.580] they really don't provide you like an input [09:18.580 --> 09:20.260] where you can put all the bytes you like [09:20.260 --> 09:21.320] and the order you like. [09:21.320 --> 09:23.280] So you can have the hash to decide [09:23.280 --> 09:26.060] for copying another client software. [09:26.320 --> 09:28.520] So this was kind of a tricky one. [09:28.520 --> 09:30.720] So my next idea was, okay, [09:30.720 --> 09:33.260] I will just open a TCP socket [09:33.260 --> 09:36.520] and throw there my copy client hello package [09:36.520 --> 09:37.460] and see what happened. [09:37.460 --> 09:39.140] Obviously the TLS handshake breaks [09:39.140 --> 09:40.780] and it's not interesting to us [09:40.780 --> 09:41.840] because at the end of the day, [09:41.840 --> 09:43.540] we need to use HTTPS. [09:43.780 --> 09:47.120] So my last option were like getting a little bit [09:47.120 --> 09:49.140] my hands dirty and go and modify [09:49.680 --> 09:52.440] the source code of the programming language [09:52.440 --> 09:54.400] I was using in this case was Golang. [09:54.400 --> 09:56.380] So I will say, okay, I will add a feature [09:56.900 --> 09:59.080] and this is more or less how it works. [09:59.860 --> 10:01.980] So, you know, and I'm sort of similar [10:01.980 --> 10:03.980] in other languages that relate [10:03.980 --> 10:05.140] to which kind of language you're using [10:05.140 --> 10:06.000] for writing your input, [10:06.000 --> 10:07.600] but at least in Golang, [10:08.040 --> 10:09.160] when you want to address, [10:09.160 --> 10:10.780] you need to graph your HTTP client. [10:10.820 --> 10:11.980] And when you graph the HTTP client [10:11.980 --> 10:13.320] and you want to use HTTPS, [10:13.320 --> 10:14.680] you provide the TLS configuration [10:14.680 --> 10:15.860] that is like a struct. [10:17.080 --> 10:19.140] Before requesting to the endpoint [10:19.140 --> 10:20.240] with a post get, [10:20.240 --> 10:22.220] whatever HTTP request you want to, [10:23.760 --> 10:25.040] the language will go through [10:25.040 --> 10:28.240] the flow of crafting this TLS hello. [10:28.260 --> 10:29.900] And it will take kind of your configuration [10:30.400 --> 10:33.020] and then grab up the bytes [10:33.020 --> 10:34.780] and send them to perform the handshake. [10:34.780 --> 10:36.140] The problem is, I was telling before, [10:36.140 --> 10:36.940] we don't have a feature [10:36.940 --> 10:40.080] where we can like put whatever bytes we want to. [10:40.080 --> 10:43.520] So I modify the source code of Golang [10:43.520 --> 10:45.280] and HTTP client to accept [10:45.280 --> 10:46.740] in the TLS configuration, [10:46.860 --> 10:48.080] a new string input. [10:48.080 --> 10:50.520] And this string input will be exactly [10:51.020 --> 10:53.520] what the GF3 tool provide to us. [10:53.520 --> 10:54.400] So in that case, [10:54.400 --> 10:56.260] we can use like GF3 tool [10:56.260 --> 10:59.100] for copying a Chrome Firefox Opera browser [10:59.100 --> 11:02.280] and throwing in the compilation of our implant. [11:02.560 --> 11:05.300] In that way, when you go to TLS, [11:05.300 --> 11:06.760] the TLS flow, [11:06.760 --> 11:08.400] and you need to add another part of the code [11:08.400 --> 11:09.880] where you are like marshalling [11:09.880 --> 11:11.740] or creating this client hello, [11:11.740 --> 11:12.700] I added a for loop [11:12.700 --> 11:15.360] and for each hexadecimal value, [11:15.360 --> 11:17.060] I kind of copy a reference, [11:17.060 --> 11:17.860] which is the package [11:17.860 --> 11:20.900] or the syntax that respect the RPC. [11:21.020 --> 11:21.920] So if you have a bunch [11:21.920 --> 11:23.800] of hexadecimal bytes in the right order, [11:23.800 --> 11:25.060] you can extract the fingerprint [11:25.060 --> 11:27.260] of the browser you are targeting. [11:27.700 --> 11:29.420] It's true that a lot of them, [11:29.420 --> 11:30.400] and I'm sure this extension [11:30.400 --> 11:32.740] will be like modified with the time, [11:32.740 --> 11:34.560] but I have enough right now, [11:34.560 --> 11:37.060] entropy or availability [11:37.060 --> 11:39.400] of like hexadecimal bytes already caught [11:39.400 --> 11:41.380] for like accepting most of the browser. [11:41.380 --> 11:42.240] If you feel that you need [11:42.240 --> 11:43.360] more hexadecimal bytes, [11:43.360 --> 11:44.520] I will add them. [11:44.600 --> 11:45.300] There is no problem. [11:45.300 --> 11:46.360] The source code is already published [11:46.360 --> 11:48.260] in these links on GitHub. [11:48.480 --> 11:49.100] So, okay. [11:49.100 --> 11:51.500] Now we have the HTTPS client [11:51.500 --> 11:52.780] that we need for copying [11:52.780 --> 11:54.420] rightful connection of browsers [11:54.420 --> 11:56.560] and any other like software you like, [11:56.560 --> 11:58.580] antivirus, aggression, whatever. [11:58.900 --> 12:00.160] But now it came the problem [12:00.160 --> 12:02.440] that we want to address using Gmail. [12:16.020 --> 12:21.120] That I need to change on the source code. [12:21.480 --> 12:23.160] So that's it. [12:23.160 --> 12:26.180] I want to like provide you a flow [12:26.180 --> 12:28.000] of how this implant will work [12:28.000 --> 12:29.000] on the background, [12:29.000 --> 12:31.640] once we get the execution on the foothold. [12:31.800 --> 12:33.380] So when we craft our implant, [12:33.380 --> 12:34.780] the first thing we need to have [12:34.780 --> 12:36.760] is the Gmail connected app. [12:36.760 --> 12:37.580] We configure it [12:37.580 --> 12:38.880] and we provide those credentials [12:38.880 --> 12:40.200] to the C2. [12:40.200 --> 12:42.040] And the C2 on the completion of the implant [12:42.040 --> 12:44.140] will provide both the credential [12:44.140 --> 12:46.820] to the digital alongside [12:46.820 --> 12:48.200] with the TLS fingerprint. [12:48.260 --> 12:49.660] And then the implant will start [12:49.660 --> 12:50.460] with the aggression. [12:50.460 --> 12:51.200] And for aggression, [12:51.200 --> 12:52.040] the first thing he will do [12:52.040 --> 12:53.560] is using the refresh token [12:53.560 --> 12:55.920] against the Google authentication servers. [12:55.920 --> 12:58.120] And then when he get the access token, [12:58.120 --> 12:59.860] we will start to like push, [12:59.860 --> 13:01.820] pull information through Gmail. [13:01.820 --> 13:03.220] The C2 or the operation server [13:03.220 --> 13:04.380] will do similarly. [13:04.380 --> 13:06.540] And we could create a data connection [13:06.540 --> 13:08.680] for sending or receiving commands perfectly [13:08.680 --> 13:11.040] and totally transparent to the operator. [13:11.260 --> 13:12.440] At the eyes of the blue team [13:12.440 --> 13:15.000] that is looking to this proxy, [13:15.000 --> 13:17.320] it will just look like a Chrome browser, [13:17.320 --> 13:18.740] which is good to go. [13:20.260 --> 13:21.780] So to speak a little bit [13:21.780 --> 13:22.720] about DeepPacket inspection [13:22.720 --> 13:26.240] or how we can bypass or avoid this stuff. [13:26.240 --> 13:27.080] So, you know, [13:27.080 --> 13:28.500] if we have the bad luck [13:28.500 --> 13:29.840] that the sock or the scissor [13:29.840 --> 13:31.340] is gripping common string [13:32.260 --> 13:34.620] within or like flow against Gmail, [13:34.620 --> 13:36.540] we could kind of use some kind [13:36.540 --> 13:37.940] of later cryptography [13:37.940 --> 13:40.100] and share a symmetric key with the C2 [13:40.100 --> 13:41.800] and then common grips [13:41.800 --> 13:43.740] or common errors will not pop up. [13:43.740 --> 13:44.820] If we have the bad luck [13:44.820 --> 13:45.880] that it's a threat hunter [13:45.880 --> 13:47.260] catching our flows, [13:47.260 --> 13:49.700] we can also use other techniques [13:49.700 --> 13:51.060] like stenography. [13:51.060 --> 13:52.280] It wouldn't be as difficult [13:52.280 --> 13:53.920] because also Gmail provides us [13:53.920 --> 13:55.140] the ability to attach images [13:55.140 --> 13:56.540] to the draft emails. [13:57.220 --> 13:59.140] So a little bit [13:59.140 --> 14:00.820] of how the network model [14:00.820 --> 14:02.540] with the encryption will work [14:02.540 --> 14:04.220] in Siesta time is using [14:04.220 --> 14:05.420] the similar thing, [14:05.420 --> 14:06.680] putting on the body of the draft [14:06.680 --> 14:07.720] whatever JSON payload [14:07.720 --> 14:09.400] we want to process by height. [14:09.400 --> 14:10.720] But instead of just putting [14:10.720 --> 14:11.760] playing the strings, [14:11.760 --> 14:12.840] we can use like encrypting [14:12.840 --> 14:14.240] with the symmetric key. [14:14.560 --> 14:15.780] I have still not developed [14:15.780 --> 14:16.920] this full model, [14:16.920 --> 14:17.680] but it will be added [14:17.680 --> 14:19.340] to Siesta time in the future. [14:20.360 --> 14:22.160] So let's let's go ahead [14:22.160 --> 14:22.920] with the demo. [14:22.920 --> 14:24.540] So what I have created here [14:24.540 --> 14:25.840] is trying to reproduce [14:25.840 --> 14:26.760] this environment [14:26.760 --> 14:29.160] where the blue team has deployed [14:29.160 --> 14:30.100] this kind of detection [14:30.100 --> 14:31.540] technique in a network. [14:31.720 --> 14:32.580] I have created [14:32.580 --> 14:33.600] two different implants. [14:33.600 --> 14:34.680] This is the graphical interface [14:34.680 --> 14:35.860] of Siesta time. [14:35.860 --> 14:37.200] And alongside all the inputs [14:37.200 --> 14:38.320] that I'm not going to speak [14:38.320 --> 14:39.460] about each one of them, [14:39.460 --> 14:40.780] particularly we see here [14:40.780 --> 14:42.340] we have this TLS fingerprint [14:42.340 --> 14:44.160] with an extra 4G S3 tool. [14:44.160 --> 14:44.880] In that way, [14:44.880 --> 14:46.420] we can create different implants [14:46.420 --> 14:46.960] that mimic [14:46.960 --> 14:48.760] whatever connection we want to. [14:49.260 --> 14:50.720] If we focus a little bit [14:50.720 --> 14:53.320] the network topology of the demo, [14:53.320 --> 14:54.520] what this is going to look like [14:54.520 --> 14:56.880] I am using a BIMI workstation [14:56.880 --> 14:58.680] with three machines on it. [14:58.680 --> 14:59.640] But particularly interesting [14:59.640 --> 15:00.840] is we have the Windows 10 [15:00.840 --> 15:02.400] foothold that is going to run [15:02.400 --> 15:03.320] two different implants [15:03.320 --> 15:04.280] and every connection [15:04.280 --> 15:05.240] that I get through email [15:05.800 --> 15:06.620] is going to be read [15:06.620 --> 15:08.060] by a Ubuntu server [15:08.060 --> 15:10.900] that is a TLS proxy [15:10.900 --> 15:11.760] with Polar Proxy, [15:11.760 --> 15:13.200] which is not the most interesting. [15:13.200 --> 15:13.840] The important thing [15:13.840 --> 15:15.140] is running a Suricata [15:15.760 --> 15:17.660] network interface detection system. [15:18.120 --> 15:19.240] And you have a bunch of alerts [15:19.240 --> 15:20.520] just to like detect [15:20.520 --> 15:22.000] that if the TLS fingerprint [15:22.000 --> 15:23.200] is not going to the client [15:23.200 --> 15:24.320] to show me an alert, [15:24.320 --> 15:26.040] if not, you can go ahead. [15:26.080 --> 15:28.220] So let's go to the demo. [15:31.280 --> 15:32.780] So as you can see here, [15:32.780 --> 15:33.880] this is a graphical interface [15:33.880 --> 15:34.660] of siesta time. [15:34.660 --> 15:35.520] These are all the jobs [15:35.520 --> 15:37.260] that the Hive has processed already. [15:37.380 --> 15:38.920] And now we have two implants [15:38.920 --> 15:39.980] that are created. [15:40.400 --> 15:41.380] That means we can just [15:41.380 --> 15:42.900] download the executable [15:42.900 --> 15:44.600] and somehow we will make [15:44.600 --> 15:45.580] the foothold to execute [15:46.800 --> 15:49.160] through any attack vector we want to. [15:49.420 --> 15:51.220] So this is the Ubuntu machine [15:51.220 --> 15:52.020] that is listening [15:52.020 --> 15:52.780] to all the connection [15:52.780 --> 15:54.640] or the aggression of the foothold. [15:54.640 --> 15:56.880] And we have the Suricata running on it. [15:57.760 --> 15:58.840] Suricata will match [15:58.840 --> 16:00.560] the two following rules. [16:00.960 --> 16:02.220] These two rules, [16:02.220 --> 16:03.340] they're using a GS3 plugin [16:03.340 --> 16:04.160] for Suricata, [16:04.160 --> 16:06.680] and they will get the header [16:06.680 --> 16:07.620] of the TLS connection [16:07.620 --> 16:09.340] of every aggression package. [16:09.340 --> 16:11.480] They will generate an MD5 hash. [16:11.480 --> 16:13.580] If that hash match this one, [16:13.580 --> 16:15.180] we will pop up an alert. [16:15.580 --> 16:18.080] We can check that these two hashes, [16:18.080 --> 16:20.400] they match by the public database [16:20.400 --> 16:23.220] of GS3, a Go HTTP client. [16:26.490 --> 16:27.750] So let's search for the hash, [16:27.750 --> 16:29.030] similarly to VirusTotal, [16:29.030 --> 16:30.170] but with TLS fingerprints. [16:30.170 --> 16:32.330] We see this is a Go HTTP client, right? [16:33.290 --> 16:35.070] We are going to run the first implant [16:35.070 --> 16:36.810] in the Windows 10 foothold [16:36.810 --> 16:38.750] and we're going to be detected. [16:41.970 --> 16:44.110] So the interesting thing [16:44.110 --> 16:45.710] about these two is like, [16:45.710 --> 16:47.310] obviously, this Go client [16:47.310 --> 16:47.870] is going to be using [16:47.870 --> 16:49.050] the default configuration, [16:49.050 --> 16:50.510] but we can change things. [16:50.950 --> 16:52.850] But the cool thing about this is like, [16:52.850 --> 16:53.270] it doesn't matter [16:53.270 --> 16:54.850] how many configuration is changed [16:54.850 --> 16:56.750] by using a Go HTTP client. [16:56.750 --> 16:57.770] By the end of the day, [16:57.770 --> 16:58.830] all those hashes, [16:58.830 --> 16:59.530] they will be registered [16:59.530 --> 17:00.870] with this public database. [17:00.990 --> 17:02.510] So we have two appearances [17:02.510 --> 17:03.650] on the log of Suricata. [17:03.650 --> 17:04.370] And the reason is [17:04.370 --> 17:06.650] because I was saying before, [17:06.650 --> 17:08.530] one request is for getting the access token [17:08.530 --> 17:10.850] for the Google authorization servers. [17:10.850 --> 17:12.650] And the second one is for pushing, [17:12.650 --> 17:15.070] pulling data from Hive through Gmail. [17:15.770 --> 17:17.390] So let's clean the logs. [17:17.410 --> 17:18.690] And now we are going to do [17:18.690 --> 17:19.750] exactly the same, [17:19.750 --> 17:21.870] but using the implant [17:21.870 --> 17:22.890] that has been created [17:22.890 --> 17:24.070] with siesta time [17:24.070 --> 17:25.750] and with the TLS fingerprint [17:25.750 --> 17:27.350] of a Chrome browser. [17:30.250 --> 17:32.590] So the creation of the implant [17:32.590 --> 17:33.710] is just the same process, [17:33.710 --> 17:34.510] which is going to change [17:34.510 --> 17:35.690] with the execution of it [17:35.690 --> 17:37.030] and how we detect it. [17:37.030 --> 17:38.850] And the data flow is just the same. [17:38.850 --> 17:40.550] So let's execute the implant [17:40.550 --> 17:42.350] that now is copying [17:42.350 --> 17:44.750] the fingerprint of a Chrome browser. [17:45.550 --> 17:47.470] And let's go back to the Suricata. [17:47.490 --> 17:49.190] And we see there is no any log, [17:49.190 --> 17:51.870] but let's recheck what's going on. [17:51.870 --> 17:53.450] So let's open a Wireshark [17:53.450 --> 17:55.330] and start to detect [17:55.330 --> 17:56.730] and read all the packets [17:56.730 --> 17:59.650] that are going through the TLS proxy. [18:00.590 --> 18:02.750] And the objective of this is, [18:02.750 --> 18:04.470] since we maybe don't trust [18:04.470 --> 18:06.190] what Suricata is saying to us, right? [18:06.190 --> 18:06.850] Let's make sure [18:06.850 --> 18:08.530] that this fingerprint is a Chrome browser [18:08.530 --> 18:10.570] instead of a Go HTTP client. [18:10.570 --> 18:11.730] So let's filter, [18:11.730 --> 18:13.570] let's get all the main hello, [18:13.570 --> 18:16.170] and then let's export it in a pickup. [18:16.770 --> 18:18.230] And we can use this pickup [18:18.990 --> 18:21.570] for like a GS3 to parse it [18:21.570 --> 18:22.410] and tell to us [18:22.410 --> 18:24.050] which fingerprints of bytes [18:24.050 --> 18:26.650] is detecting from this aggression. [18:28.270 --> 18:30.050] This way will be the same [18:30.050 --> 18:31.170] that we need to follow [18:31.170 --> 18:32.690] if we need to copy the TLS fingerprint [18:32.690 --> 18:34.690] from any other rightful software. [18:35.310 --> 18:36.870] So here you see there is like [18:36.870 --> 18:38.730] this five section of bytes. [18:38.730 --> 18:39.810] This one will be the input [18:39.810 --> 18:40.690] for CSTATIME frame [18:40.690 --> 18:42.470] we want to generate an implant [18:42.470 --> 18:43.590] with these fingerprints. [18:43.590 --> 18:45.430] And there is two different MD5 hashes [18:45.430 --> 18:48.110] because as this is a TLS proxy, [18:48.110 --> 18:49.250] there is a second fingerprint [18:49.250 --> 18:51.170] for polar proxy itself. [18:51.190 --> 18:53.770] But if we go and we take the fingerprint [18:54.130 --> 18:55.150] of the implant, [18:56.310 --> 18:57.630] we are going to see [18:57.630 --> 19:00.110] that this is effectively [19:00.530 --> 19:01.830] the public database GS3 [19:01.830 --> 19:04.010] is effectively pointing it [19:04.010 --> 19:04.890] to a Chrome browser [19:04.890 --> 19:06.630] instead of a Go HTTP client [19:06.630 --> 19:08.030] or a Java client, [19:08.030 --> 19:08.610] Python client, [19:08.610 --> 19:10.550] whatever we have HTTP library [19:10.550 --> 19:12.950] we have used for our implant to address. [19:14.290 --> 19:15.570] So if we go back [19:15.570 --> 19:18.690] to CSTATIME graphical interface, [19:19.250 --> 19:21.730] we can see we already have the host infected. [19:21.830 --> 19:24.210] We have killed one implant. [19:24.210 --> 19:24.930] So that's offline, [19:24.930 --> 19:26.470] but the other is still alive. [19:26.630 --> 19:27.930] So now we can do things like, [19:27.930 --> 19:29.330] you know, injecting a shell [19:29.330 --> 19:32.810] or injecting a reverse SQL shell. [19:32.810 --> 19:34.250] We have all the information [19:34.250 --> 19:36.730] from the target host that we have infected. [19:36.770 --> 19:38.250] And we also have like, you know, [19:38.250 --> 19:40.250] an asynchronous interactive shell. [19:40.250 --> 19:41.530] And all these will happen [19:42.250 --> 19:43.710] totally transparent to the operator [19:43.710 --> 19:44.770] and through email. [19:44.770 --> 19:46.570] You see the fingerprints we need. [19:48.270 --> 19:48.990] So, [19:49.930 --> 19:52.170] I want to speak last but not least, [19:52.830 --> 19:54.030] how to help defender, [19:54.030 --> 19:54.810] how to make them better [19:54.810 --> 19:57.150] because at the end of the day, [19:57.150 --> 19:58.790] you know, the routing operation [19:58.790 --> 20:01.190] is have a lot of reason, [20:01.190 --> 20:02.870] but we want to make the defenders [20:02.870 --> 20:03.930] to be better, right? [20:03.930 --> 20:05.470] And to be prepared to this kind of attack. [20:05.470 --> 20:07.130] So if I focus on the network [20:07.130 --> 20:08.410] intrusive detecting techniques [20:08.410 --> 20:10.470] and in the TLS, [20:10.470 --> 20:12.210] a fingerprint detection, [20:12.210 --> 20:14.430] if you ask me if there is gap of improvement, [20:14.430 --> 20:16.050] I will say, yes. [20:16.790 --> 20:18.370] There is for one reason [20:18.370 --> 20:20.850] that the Python script of GS3, [20:20.850 --> 20:22.030] it's, you know, [20:22.030 --> 20:24.130] going through all these extensions by it. [20:24.130 --> 20:26.090] So they will, the big entropy happens, [20:26.090 --> 20:27.790] but it's just taking the headers. [20:27.790 --> 20:29.190] You know, the Python screen, [20:29.190 --> 20:30.470] we could write a new for loop [20:30.470 --> 20:32.510] for like getting more byte inside [20:32.510 --> 20:34.510] this like an onion layer, right? [20:34.510 --> 20:35.950] And this is something that GS3 [20:35.950 --> 20:37.150] is not doing right now. [20:37.150 --> 20:39.030] That we always generate more md5 hashes [20:39.030 --> 20:40.030] and more different [20:41.470 --> 20:43.150] entropy to search. [20:43.150 --> 20:43.890] But that's it. [20:43.890 --> 20:44.890] That's cool. [20:45.070 --> 20:49.610] But this is the catch of the mouse. [20:49.610 --> 20:50.370] If they do that, [20:50.370 --> 20:53.350] I will use another for loop in my HTTPS client [20:53.350 --> 20:54.770] and then we're in the same. [20:54.830 --> 20:55.890] What I think is interesting [20:55.890 --> 20:59.170] is not just using network intrusive detecting technique, [20:59.170 --> 21:00.070] but, you know, [21:00.070 --> 21:02.030] focusing on the host intrusive detecting techniques [21:02.030 --> 21:03.430] or now called EDR [21:03.430 --> 21:05.610] and trying to match kind of the two signatures [21:05.610 --> 21:07.350] and see if something is going on. [21:07.350 --> 21:09.290] I say this because while my VGTO [21:09.290 --> 21:10.950] is regressing really efficiently, [21:10.950 --> 21:14.090] this is still doing not so like a straightforward actions [21:14.090 --> 21:15.730] in the operating system. [21:15.890 --> 21:17.750] And, you know, this could be easily detected. [21:17.770 --> 21:18.410] Like, you know, [21:18.410 --> 21:20.850] when we can see md.x as a forward cell x [21:20.850 --> 21:23.050] or for persisting use, [21:23.050 --> 21:25.750] calling the APIs of a schedule that's on Windows. [21:25.910 --> 21:28.670] This could be like a little bit more like a shiny [21:28.670 --> 21:30.410] at the hour of detection. [21:31.870 --> 21:33.250] So that's everything. [21:33.250 --> 21:34.390] Thank you so much. [21:34.770 --> 21:37.630] The source code is already published for everything. [21:37.630 --> 21:38.790] And there is a user guide [21:38.790 --> 21:42.190] for the CSTATIME framework as well. [21:44.030 --> 21:46.810] I have the Discord and I can answer questions. [21:46.890 --> 21:48.630] So just let me know. [21:53.260 --> 21:53.880] Okay. Yeah. [21:53.880 --> 21:54.760] The slides will be, [21:54.760 --> 21:55.920] I will publish the slides. [21:55.920 --> 21:56.580] Source code is there. [21:56.580 --> 21:57.460] There is user guide. [21:57.460 --> 21:57.940] Yeah. [22:02.560 --> 22:03.480] So that's everything. [22:03.480 --> 22:04.380] Thank you so much.