1
00:00:00,000 --> 00:00:01,440
All right, we're back.

2
00:00:01,580 --> 00:00:09,880
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.

3
00:00:10,820 --> 00:00:13,260
We're glad to have you here, and the floor is yours.

4
00:00:13,260 --> 00:00:14,100
Take it away.

5
00:00:14,480 --> 00:00:15,620
Thank you so much, Omar.

6
00:00:15,620 --> 00:00:19,900
I'm so happy to be here another year presenting the DEF CON Red Team Village.

7
00:00:19,980 --> 00:00:24,760
Welcome to Total Eagresio, Evading Intrusion Detection System for Stealthier Implants.

8
00:00:24,780 --> 00:00:27,260
So, first of all, I would like to introduce myself.

9
00:00:27,260 --> 00:00:35,560
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.

10
00:00:35,560 --> 00:00:41,820
I do a lot of offensive appsec, bug hunting, a little bit of research about this last topic.

11
00:00:41,820 --> 00:00:49,540
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.

12
00:00:49,760 --> 00:00:51,380
It's kind of divided in two parts.

13
00:00:51,380 --> 00:00:55,220
The first part is the C2 operation manager, that is grown on Golang.

14
00:00:55,720 --> 00:01:00,660
Most of it, like, it used Terraform to deploy, like, infrastructure, proxies, and redirectors.

15
00:01:00,660 --> 00:01:09,080
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.

16
00:01:09,080 --> 00:01:16,020
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.

17
00:01:16,020 --> 00:01:22,760
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.

18
00:01:22,760 --> 00:01:38,680
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.

19
00:01:39,040 --> 00:01:46,960
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.

20
00:01:47,240 --> 00:01:51,100
And from that talk, I got an amazing amount of cool feedback.

21
00:01:51,100 --> 00:02:06,660
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.

22
00:02:06,660 --> 00:02:13,280
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.

23
00:02:13,280 --> 00:02:23,640
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.

24
00:02:23,740 --> 00:02:25,820
So, you know, this really triggered my attention.

25
00:02:25,820 --> 00:02:46,880
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.

26
00:02:46,880 --> 00:03:08,020
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.

27
00:03:08,020 --> 00:03:11,580
So I like to divide in kind of like two big parts, right?

28
00:03:11,580 --> 00:03:23,900
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?

29
00:03:23,900 --> 00:03:33,100
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.

30
00:03:33,100 --> 00:03:35,740
So I can deep look at the body of the flow.

31
00:03:35,740 --> 00:03:49,940
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,

32
00:03:49,940 --> 00:03:50,600
right?

33
00:03:50,820 --> 00:03:54,740
But I'm not gonna get still really deep into these techniques.

34
00:03:54,740 --> 00:03:58,560
I want to focus a little bit in not deep packet inspection techniques, right?

35
00:03:58,980 --> 00:04:06,980
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?

36
00:04:06,980 --> 00:04:10,220
Which is the server or foothold is connecting to.

37
00:04:10,520 --> 00:04:19,800
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?

38
00:04:19,800 --> 00:04:21,500
Which kind of domain we are using.

39
00:04:21,540 --> 00:04:28,880
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?

40
00:04:28,880 --> 00:04:33,520
Which kind of certificate is this server like serving?

41
00:04:33,520 --> 00:04:35,460
Is self-signed or not?

42
00:04:35,700 --> 00:04:41,220
And then they will also could look at the wire itself, you know, which kind of protocol we are using.

43
00:04:41,220 --> 00:04:48,600
If there is a huge amount of package load on a DNS aggression, you know, they could say, oh, something is going on here.

44
00:04:48,640 --> 00:05:01,920
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.

45
00:05:01,920 --> 00:05:12,060
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.

46
00:05:12,460 --> 00:05:22,100
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.

47
00:05:22,100 --> 00:05:25,840
And they can say, oh, this domain host is using a common browser.

48
00:05:25,840 --> 00:05:33,440
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.

49
00:05:33,440 --> 00:05:35,800
That kind of look a little bit more sketchy.

50
00:05:35,800 --> 00:05:52,340
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,

51
00:05:52,340 --> 00:05:53,800
to receive the connection.

52
00:05:53,800 --> 00:05:58,340
And by matching both of them, they could get a really strong indicator of compromise.

53
00:05:59,140 --> 00:06:08,240
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.

54
00:06:08,240 --> 00:06:17,900
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.

55
00:06:17,900 --> 00:06:23,720
This is around a really interesting research that was done time ago by a bunch of blue team engineers.

56
00:06:23,920 --> 00:06:28,600
And alongside with this research, they publish it with this GA3 tool.

57
00:06:28,600 --> 00:06:29,960
This is a Python script.

58
00:06:30,260 --> 00:06:33,120
I'm going to do a little bit of a deep dive, what's going on.

59
00:06:33,120 --> 00:06:40,300
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?

60
00:06:40,300 --> 00:06:51,800
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.

61
00:06:51,800 --> 00:06:55,500
The first thing that our implant will perform is opening a TCP socket.

62
00:06:55,860 --> 00:06:59,740
And following that TCP socket, the TLS handshake will start.

63
00:07:00,140 --> 00:07:14,120
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.

64
00:07:14,120 --> 00:07:20,920
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.

65
00:07:21,000 --> 00:07:23,600
In the same way, the server will do the same.

66
00:07:23,700 --> 00:07:39,180
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.

67
00:07:39,600 --> 00:07:52,480
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.

68
00:07:52,940 --> 00:07:59,500
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.

69
00:07:59,540 --> 00:08:12,180
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.

70
00:08:12,180 --> 00:08:17,740
We can go to the header of the SQL Socket layer and we can see all these particular bytes that we have.

71
00:08:17,800 --> 00:08:26,760
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.

72
00:08:26,760 --> 00:08:42,080
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.

73
00:08:42,220 --> 00:08:44,360
So, okay, where are the red timers?

74
00:08:44,620 --> 00:08:48,840
We know this is a problem and we know that we may be detected because of this.

75
00:08:48,900 --> 00:08:56,460
So now it's where it becomes the idea of blending in the network and trying to like evading these techniques, right?

76
00:08:56,460 --> 00:08:58,300
So I had a bunch of ideas.

77
00:08:58,300 --> 00:09:02,480
My first idea was, okay, I'm using a programming language.

78
00:09:02,480 --> 00:09:07,760
This programming language gave me the option to create my own HTTP client, choose the library I want to.

79
00:09:07,840 --> 00:09:21,320
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.

80
00:09:21,320 --> 00:09:26,060
So you can have the hash to decide for copying another client software.

81
00:09:26,320 --> 00:09:28,520
So this was kind of a tricky one.

82
00:09:28,520 --> 00:09:37,460
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.

83
00:09:37,460 --> 00:09:43,540
Obviously the TLS handshake breaks and it's not interesting to us because at the end of the day, we need to use HTTPS.

84
00:09:43,780 --> 00:09:54,400
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.

85
00:09:54,400 --> 00:09:59,080
So I will say, okay, I will add a feature and this is more or less how it works.

86
00:09:59,860 --> 00:10:10,780
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.

87
00:10:10,820 --> 00:10:15,860
And when you graph the HTTP client and you want to use HTTPS, you provide the TLS configuration that is like a struct.

88
00:10:17,080 --> 00:10:28,240
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.

89
00:10:28,260 --> 00:10:34,780
And it will take kind of your configuration and then grab up the bytes and send them to perform the handshake.

90
00:10:34,780 --> 00:10:40,080
The problem is, I was telling before, we don't have a feature where we can like put whatever bytes we want to.

91
00:10:40,080 --> 00:10:48,080
So I modify the source code of Golang and HTTP client to accept in the TLS configuration, a new string input.

92
00:10:48,080 --> 00:10:53,520
And this string input will be exactly what the GF3 tool provide to us.

93
00:10:53,520 --> 00:11:02,280
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.

94
00:11:02,560 --> 00:11:20,900
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.

95
00:11:21,020 --> 00:11:27,260
So if you have a bunch of hexadecimal bytes in the right order, you can extract the fingerprint of the browser you are targeting.

96
00:11:27,700 --> 00:11:41,380
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.

97
00:11:41,380 --> 00:11:44,520
If you feel that you need more hexadecimal bytes, I will add them.

98
00:11:44,600 --> 00:11:45,300
There is no problem.

99
00:11:45,300 --> 00:11:48,260
The source code is already published in these links on GitHub.

100
00:11:48,480 --> 00:11:49,100
So, okay.

101
00:11:49,100 --> 00:11:58,580
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.

102
00:11:58,900 --> 00:12:02,440
But now it came the problem that we want to address using Gmail.

103
00:12:16,020 --> 00:12:21,120
That I need to change on the source code.

104
00:12:21,480 --> 00:12:23,160
So that's it.

105
00:12:23,160 --> 00:12:31,640
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.

106
00:12:31,800 --> 00:12:36,760
So when we craft our implant, the first thing we need to have is the Gmail connected app.

107
00:12:36,760 --> 00:12:40,200
We configure it and we provide those credentials to the C2.

108
00:12:40,200 --> 00:12:48,200
And the C2 on the completion of the implant will provide both the credential to the digital alongside with the TLS fingerprint.

109
00:12:48,260 --> 00:12:50,460
And then the implant will start with the aggression.

110
00:12:50,460 --> 00:12:55,920
And for aggression, the first thing he will do is using the refresh token against the Google authentication servers.

111
00:12:55,920 --> 00:13:01,820
And then when he get the access token, we will start to like push, pull information through Gmail.

112
00:13:01,820 --> 00:13:04,380
The C2 or the operation server will do similarly.

113
00:13:04,380 --> 00:13:11,040
And we could create a data connection for sending or receiving commands perfectly and totally transparent to the operator.

114
00:13:11,260 --> 00:13:18,740
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.

115
00:13:20,260 --> 00:13:26,240
So to speak a little bit about DeepPacket inspection or how we can bypass or avoid this stuff.

116
00:13:26,240 --> 00:13:43,740
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.

117
00:13:43,740 --> 00:13:51,060
If we have the bad luck that it's a threat hunter catching our flows, we can also use other techniques like stenography.

118
00:13:51,060 --> 00:13:56,540
It wouldn't be as difficult because also Gmail provides us the ability to attach images to the draft emails.

119
00:13:57,220 --> 00:14:09,400
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.

120
00:14:09,400 --> 00:14:14,240
But instead of just putting playing the strings, we can use like encrypting with the symmetric key.

121
00:14:14,560 --> 00:14:19,340
I have still not developed this full model, but it will be added to Siesta time in the future.

122
00:14:20,360 --> 00:14:22,920
So let's let's go ahead with the demo.

123
00:14:22,920 --> 00:14:31,540
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.

124
00:14:31,720 --> 00:14:33,600
I have created two different implants.

125
00:14:33,600 --> 00:14:35,860
This is the graphical interface of Siesta time.

126
00:14:35,860 --> 00:14:44,160
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.

127
00:14:44,160 --> 00:14:48,760
In that way, we can create different implants that mimic whatever connection we want to.

128
00:14:49,260 --> 00:14:58,680
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.

129
00:14:58,680 --> 00:15:13,200
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.

130
00:15:13,200 --> 00:15:17,660
The important thing is running a Suricata network interface detection system.

131
00:15:18,120 --> 00:15:26,040
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.

132
00:15:26,080 --> 00:15:28,220
So let's go to the demo.

133
00:15:31,280 --> 00:15:34,660
So as you can see here, this is a graphical interface of siesta time.

134
00:15:34,660 --> 00:15:37,260
These are all the jobs that the Hive has processed already.

135
00:15:37,380 --> 00:15:39,980
And now we have two implants that are created.

136
00:15:40,400 --> 00:15:49,160
That means we can just download the executable and somehow we will make the foothold to execute through any attack vector we want to.

137
00:15:49,420 --> 00:15:54,640
So this is the Ubuntu machine that is listening to all the connection or the aggression of the foothold.

138
00:15:54,640 --> 00:15:56,880
And we have the Suricata running on it.

139
00:15:57,760 --> 00:16:00,560
Suricata will match the two following rules.

140
00:16:00,960 --> 00:16:09,340
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.

141
00:16:09,340 --> 00:16:11,480
They will generate an MD5 hash.

142
00:16:11,480 --> 00:16:15,180
If that hash match this one, we will pop up an alert.

143
00:16:15,580 --> 00:16:23,220
We can check that these two hashes, they match by the public database of GS3, a Go HTTP client.

144
00:16:26,490 --> 00:16:30,170
So let's search for the hash, similarly to VirusTotal, but with TLS fingerprints.

145
00:16:30,170 --> 00:16:32,330
We see this is a Go HTTP client, right?

146
00:16:33,290 --> 00:16:38,750
We are going to run the first implant in the Windows 10 foothold and we're going to be detected.

147
00:16:41,970 --> 00:16:50,510
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.

148
00:16:50,950 --> 00:16:56,750
But the cool thing about this is like, it doesn't matter how many configuration is changed by using a Go HTTP client.

149
00:16:56,750 --> 00:17:00,870
By the end of the day, all those hashes, they will be registered with this public database.

150
00:17:00,990 --> 00:17:03,650
So we have two appearances on the log of Suricata.

151
00:17:03,650 --> 00:17:10,850
And the reason is because I was saying before, one request is for getting the access token for the Google authorization servers.

152
00:17:10,850 --> 00:17:15,070
And the second one is for pushing, pulling data from Hive through Gmail.

153
00:17:15,770 --> 00:17:17,390
So let's clean the logs.

154
00:17:17,410 --> 00:17:27,350
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.

155
00:17:30,250 --> 00:17:37,030
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.

156
00:17:37,030 --> 00:17:38,850
And the data flow is just the same.

157
00:17:38,850 --> 00:17:44,750
So let's execute the implant that now is copying the fingerprint of a Chrome browser.

158
00:17:45,550 --> 00:17:47,470
And let's go back to the Suricata.

159
00:17:47,490 --> 00:17:51,870
And we see there is no any log, but let's recheck what's going on.

160
00:17:51,870 --> 00:17:59,650
So let's open a Wireshark and start to detect and read all the packets that are going through the TLS proxy.

161
00:18:00,590 --> 00:18:06,190
And the objective of this is, since we maybe don't trust what Suricata is saying to us, right?

162
00:18:06,190 --> 00:18:10,570
Let's make sure that this fingerprint is a Chrome browser instead of a Go HTTP client.

163
00:18:10,570 --> 00:18:16,170
So let's filter, let's get all the main hello, and then let's export it in a pickup.

164
00:18:16,770 --> 00:18:26,650
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.

165
00:18:28,270 --> 00:18:34,690
This way will be the same that we need to follow if we need to copy the TLS fingerprint from any other rightful software.

166
00:18:35,310 --> 00:18:38,730
So here you see there is like this five section of bytes.

167
00:18:38,730 --> 00:18:43,590
This one will be the input for CSTATIME frame we want to generate an implant with these fingerprints.

168
00:18:43,590 --> 00:18:51,170
And there is two different MD5 hashes because as this is a TLS proxy, there is a second fingerprint for polar proxy itself.

169
00:18:51,190 --> 00:19:12,950
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.

170
00:19:14,290 --> 00:19:21,730
So if we go back to CSTATIME graphical interface, we can see we already have the host infected.

171
00:19:21,830 --> 00:19:24,210
We have killed one implant.

172
00:19:24,210 --> 00:19:26,470
So that's offline, but the other is still alive.

173
00:19:26,630 --> 00:19:32,810
So now we can do things like, you know, injecting a shell or injecting a reverse SQL shell.

174
00:19:32,810 --> 00:19:36,730
We have all the information from the target host that we have infected.

175
00:19:36,770 --> 00:19:40,250
And we also have like, you know, an asynchronous interactive shell.

176
00:19:40,250 --> 00:19:44,770
And all these will happen totally transparent to the operator and through email.

177
00:19:44,770 --> 00:19:46,570
You see the fingerprints we need.

178
00:19:48,270 --> 00:20:03,930
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?

179
00:20:03,930 --> 00:20:05,470
And to be prepared to this kind of attack.

180
00:20:05,470 --> 00:20:16,050
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.

181
00:20:16,790 --> 00:20:24,130
There is for one reason that the Python script of GS3, it's, you know, going through all these extensions by it.

182
00:20:24,130 --> 00:20:27,790
So they will, the big entropy happens, but it's just taking the headers.

183
00:20:27,790 --> 00:20:34,510
You know, the Python screen, we could write a new for loop for like getting more byte inside this like an onion layer, right?

184
00:20:34,510 --> 00:20:37,150
And this is something that GS3 is not doing right now.

185
00:20:37,150 --> 00:20:43,150
That we always generate more md5 hashes and more different entropy to search.

186
00:20:43,150 --> 00:20:43,890
But that's it.

187
00:20:43,890 --> 00:20:44,890
That's cool.

188
00:20:45,070 --> 00:20:49,610
But this is the catch of the mouse.

189
00:20:49,610 --> 00:20:54,770
If they do that, I will use another for loop in my HTTPS client and then we're in the same.

190
00:20:54,830 --> 00:21:07,350
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.

191
00:21:07,350 --> 00:21:15,730
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.

192
00:21:15,890 --> 00:21:17,750
And, you know, this could be easily detected.

193
00:21:17,770 --> 00:21:25,750
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.

194
00:21:25,910 --> 00:21:30,410
This could be like a little bit more like a shiny at the hour of detection.

195
00:21:31,870 --> 00:21:33,250
So that's everything.

196
00:21:33,250 --> 00:21:34,390
Thank you so much.

197
00:21:34,770 --> 00:21:37,630
The source code is already published for everything.

198
00:21:37,630 --> 00:21:42,190
And there is a user guide for the CSTATIME framework as well.

199
00:21:44,030 --> 00:21:46,810
I have the Discord and I can answer questions.

200
00:21:46,890 --> 00:21:48,630
So just let me know.

201
00:21:53,260 --> 00:21:53,700
Okay.

202
00:21:53,700 --> 00:21:53,880
Yeah.

203
00:21:53,880 --> 00:21:55,920
The slides will be, I will publish the slides.

204
00:21:55,920 --> 00:21:56,580
Source code is there.

205
00:21:56,580 --> 00:21:57,460
There is user guide.

206
00:21:57,460 --> 00:21:57,940
Yeah.

207
00:22:02,560 --> 00:22:03,480
So that's everything.

208
00:22:03,480 --> 00:22:04,380
Thank you so much.