1
00:00:00,000 --> 00:00:09,920
So, the next speaker is Vitor Ventura, who's going to be talking about an interesting topic, which is getting ahead of bad guys, right?

2
00:00:09,920 --> 00:00:11,740
We are all good hackers.

3
00:00:11,840 --> 00:00:14,940
Here, he's going to... hmm, interesting.

4
00:00:14,940 --> 00:00:16,140
I will not say much.

5
00:00:16,140 --> 00:00:17,600
I will let him speak.

6
00:00:17,680 --> 00:00:21,060
I'm not going to break the suspense here.

7
00:00:22,680 --> 00:00:25,160
So, hello everyone.

8
00:00:26,140 --> 00:00:27,720
So, I'm Vitor Ventura.

9
00:00:27,720 --> 00:00:29,120
I work for Cisco Talos.

10
00:00:29,120 --> 00:00:30,700
I'm a Threat Research Researcher.

11
00:00:30,900 --> 00:00:37,060
This presentation was done along with my colleague, Arnaud, who unfortunately could not be here with me.

12
00:00:37,420 --> 00:00:39,840
So, yeah, I will be doing this alone.

13
00:00:39,840 --> 00:00:42,080
But if anything goes wrong, it's his fault, okay?

14
00:00:42,080 --> 00:00:43,600
Let's just keep it like that.

15
00:00:45,400 --> 00:00:48,740
So, the objective here is getting ahead of the bad guys.

16
00:00:48,740 --> 00:00:53,760
We always, whenever we are doing our works, trying to defend, we always want to get ahead.

17
00:00:53,760 --> 00:00:56,100
We don't want to be reactive, we want to be proactive.

18
00:00:56,440 --> 00:01:07,520
Most of the times, all the data that is scanned on the internet is like Shodan or Synthesis or whatever is, okay, let me see what that IP has because it was attacking me.

19
00:01:07,520 --> 00:01:13,220
Let me see what's there because it's attacking me or let me see how my security is from the outside.

20
00:01:13,280 --> 00:01:23,020
So, the idea here is that, okay, that's good, but maybe we can get ahead by using this data in our favor, by querying the right things to these kind of tools.

21
00:01:23,020 --> 00:01:25,560
So, this is what we want to talk about.

22
00:01:25,720 --> 00:01:33,340
So, first of all, the internet is really big, so it's really hard to pinpoint where the bad guys are unless we have some prior information.

23
00:01:34,060 --> 00:01:44,700
So, in order to get ahead of that, maybe we can do some analysis, we can look into our IOCs, we can look into leaked data, we can do all sorts of things.

24
00:01:44,800 --> 00:01:48,540
But still, the results are not 100% what we really want.

25
00:01:48,540 --> 00:01:51,480
We want to know where are the bad guys.

26
00:01:51,480 --> 00:02:02,480
And we cannot just go ahead and just block IP addresses because chances are we'll have a false positive and we'll end up stopping our business and we'll have a CEO really, really pissed at us.

27
00:02:02,480 --> 00:02:10,340
So, the idea is we need to be almost 100% sure that we can block an IP address ahead of time.

28
00:02:10,340 --> 00:02:12,140
And that's our goal.

29
00:02:12,540 --> 00:02:13,980
So, that's one thing.

30
00:02:13,980 --> 00:02:27,040
The other thing is if we don't have any business on Tor sites, for instance, maybe we want to block any Tor exits because we don't want our communication going from inside to Tor exit because maybe that's a way for the bad guys to exfiltrate information.

31
00:02:27,040 --> 00:02:28,240
Same thing with VPNs.

32
00:02:28,240 --> 00:02:39,420
We need to know our business in order to block it so that when we are doing some of these kind of blocks ahead of time, we are not getting into any risks that things can go wrong.

33
00:02:39,420 --> 00:02:41,000
Same thing with IOCs.

34
00:02:41,000 --> 00:02:44,960
We all see a lot of IOCs, lists, feeds, and all that kind of thing.

35
00:02:44,960 --> 00:02:48,180
But no one really blocks an IP address for a really, really long time.

36
00:02:48,420 --> 00:02:54,720
Because if you do, chances are they will rotate, bad guys move to another site, and then you are blocking something that is legitimate.

37
00:02:54,880 --> 00:03:01,580
Or for instance, if you just go ahead and block IP addresses, just imagine what happens with sites which are on shared hosts.

38
00:03:01,580 --> 00:03:07,560
You block an IP address and all of a sudden you are blocking 100,000 websites, some of which you might need to access.

39
00:03:07,780 --> 00:03:18,160
So, all of these are problems that we need to solve ahead of time in order to prevent our proactive efforts from becoming a problem for us.

40
00:03:18,320 --> 00:03:23,580
So, that's how we actually see things, and that's how we can actually move forward.

41
00:03:23,720 --> 00:03:27,500
So, first of all, we want to have a behavioral analysis.

42
00:03:27,500 --> 00:03:29,940
We just don't want to go ahead and block things from IOCs.

43
00:03:29,940 --> 00:03:31,760
We want to have a behavioral analysis.

44
00:03:32,000 --> 00:03:37,680
And a lot of you, I'm sure, have heard about, for instance, Cobalt Strike.

45
00:03:38,120 --> 00:03:40,700
How many of you have actually installed it?

46
00:03:42,060 --> 00:03:45,460
One, two, three... two of you work with me.

47
00:03:45,460 --> 00:03:46,920
That's not... you don't count.

48
00:03:47,060 --> 00:03:48,340
So, three.

49
00:03:48,760 --> 00:03:51,700
See, a full room of people that want to defend.

50
00:03:51,700 --> 00:03:56,120
Everyone knows about Cobalt Strike, and no one... most of you have never installed it.

51
00:03:56,140 --> 00:04:01,940
So, there's a lot to gain to actually install these tools on your own systems to get knowledge on how they work.

52
00:04:02,200 --> 00:04:13,560
And I'm talking about Cobalt Strike as an example, but of course we can talk about Sliver, Brutal, all of these C2s that are out there on GitHub or on other repositories.

53
00:04:13,560 --> 00:04:21,160
And even from some APT data that you can actually get the samples, get the implants, get them to run on your sandboxes, and try to understand what they do.

54
00:04:21,160 --> 00:04:32,680
Because often, we get information about these C2s, we get information about these APT groups, but we don't get what really can help you to defend ahead of time.

55
00:04:32,680 --> 00:04:34,300
And that's what we are looking for.

56
00:04:34,300 --> 00:04:36,260
We are trying to do reconnaissance ahead of time.

57
00:04:36,260 --> 00:04:39,740
I don't want to be waiting for anyone to tell me, this IP address is malicious.

58
00:04:39,740 --> 00:04:44,280
If I can get that information for myself, then that's great, and that's what I want to do.

59
00:04:45,220 --> 00:04:55,980
So, we need to understand, install it, try it, see which kind of certificates there exist, which kind of... what's the behaviors that you can actually incorporate that into your own infrastructure.

60
00:04:56,060 --> 00:04:58,860
Then there's the searches that we were talking about initially.

61
00:04:59,440 --> 00:05:03,600
So, on Shodan, you can search for a lot of stuff.

62
00:05:03,740 --> 00:05:13,120
You can search how your systems are, but more often, you can actually search for indicators of IP addresses that are serving malicious payloads.

63
00:05:13,760 --> 00:05:16,980
And then you can analyze those and block them ahead of time.

64
00:05:17,100 --> 00:05:27,360
I imagine that you can actually go into Shodan and search, tell me all the IPs that when I do a request to the web port, gives me a Cobalt Strike Beacon.

65
00:05:28,320 --> 00:05:29,840
Those I want to block.

66
00:05:29,860 --> 00:05:34,440
If I can get the configuration, if I'm absolutely sure, I want to block those.

67
00:05:34,440 --> 00:05:41,820
There's no reason why my organization should be accessing an IP address that, by default, when I access port 80, will give me a Cobalt Strike Beacon.

68
00:05:42,080 --> 00:05:44,540
And that's a false positive, almost null.

69
00:05:45,400 --> 00:05:48,780
So, there are that kind of searches that you can actually do.

70
00:05:48,780 --> 00:05:57,620
This is a different example for the Mythic 5 Beacon data, but the principle is the same.

71
00:05:57,620 --> 00:06:04,280
You want to query these kind of platforms for stuff that you know that are malicious, and then from there, you move on to block them.

72
00:06:04,600 --> 00:06:07,760
Of course, it's not 100% like that.

73
00:06:07,760 --> 00:06:09,540
There are some caveats to this.

74
00:06:09,660 --> 00:06:11,980
In some cases, you need to do a little more work.

75
00:06:11,980 --> 00:06:13,960
In other cases, you need to do less work.

76
00:06:13,980 --> 00:06:17,100
Synthesis can also help you with this kind of information.

77
00:06:17,620 --> 00:06:24,360
So, if you have a Yara rule that you can actually search for an IP address, this is a more practical example.

78
00:06:24,360 --> 00:06:30,680
You can actually search for... on Shodan, you can search for words, but you can also search for byte strings.

79
00:06:30,760 --> 00:06:35,400
So, if you search for the mz header, you know that that will be serving an executable.

80
00:06:35,720 --> 00:06:41,100
So, you can actually go there and do that, but Shodan will not give you the full payload.

81
00:06:41,100 --> 00:06:44,840
It will give you... it will truncate the data, so there's not 100% of the data.

82
00:06:44,840 --> 00:06:56,720
But, if you have a rule that somehow matches... that can match data in the amount of bytes that Shodan actually gives you, you have a good way to identify malicious stuff.

83
00:06:56,920 --> 00:06:58,340
So, this is what we did, basically.

84
00:06:58,340 --> 00:07:04,940
We have rules that just run on the first bytes, and with that, we can actually check if it's malicious or not.

85
00:07:04,940 --> 00:07:07,600
In this case, you start by checking if it's an executable.

86
00:07:07,600 --> 00:07:12,920
You cannot block all the IP addresses that are on Shodan delivering executables.

87
00:07:12,920 --> 00:07:16,280
There are a lot of good reasons for them to deliver you an executable.

88
00:07:16,500 --> 00:07:27,080
But, because the data is long enough, you can actually get the part of the data that will tell you if it's a Cobalt Stripe beacon or not, because the configuration is on the first bytes.

89
00:07:27,100 --> 00:07:28,280
So, you can actually do that.

90
00:07:28,280 --> 00:07:36,920
So, the idea is, you can look for the data, have some rules on the beginning of the payload, and identify.

91
00:07:37,040 --> 00:07:40,980
Another good example is that Metapeter Android payloads.

92
00:07:40,980 --> 00:07:43,640
This is actually how the whole project started.

93
00:07:43,740 --> 00:07:48,180
So, in this case, we know that this will be an implant for Android.

94
00:07:48,180 --> 00:07:51,400
There is no reason why we should be actually allowing this.

95
00:07:51,440 --> 00:08:01,480
So, the idea is, let's go into these kind of platforms, get all the data, make sure that we don't have any false positives, and then, well, we just can get creative and search for the stuff.

96
00:08:01,480 --> 00:08:03,260
I've just given you a few examples.

97
00:08:03,400 --> 00:08:05,380
You can also search for bus history.

98
00:08:05,640 --> 00:08:14,840
There's even some cases, well, I think it's a little ahead, where we found entire VMs, which had a lot of information, really nice information, actually.

99
00:08:15,360 --> 00:08:19,120
So, we need to just keep in mind, be creative.

100
00:08:19,120 --> 00:08:23,980
Don't use that data just for what you actually, yourself, go ahead of time.

101
00:08:23,980 --> 00:08:25,600
But then, you need to automate it.

102
00:08:25,600 --> 00:08:30,340
There's all kinds of results that you can get from this.

103
00:08:30,340 --> 00:08:32,240
This is just a huge amount of them.

104
00:08:32,240 --> 00:08:35,900
You just need to figure out what do you think that you might get hit you.

105
00:08:35,900 --> 00:08:43,380
Every time you get something that hits your organization, just try to create some kind of search that you can go and show that and see if it's giving you back that.

106
00:08:43,380 --> 00:08:52,900
And if it is, then you can actually get the process in automated process that will actually help you to protect ahead of time, instead of only reactively.

107
00:08:53,780 --> 00:09:01,240
So, as for the VM, well, if you search for VM and Cobalt, you might just get a Gobal Strike VM, fully ready to use, without encryption.

108
00:09:01,240 --> 00:09:05,780
I will not tell you where it is, but, well, you can check out by the kind of language and all of that.

109
00:09:05,960 --> 00:09:08,560
So, just go and it's there.

110
00:09:08,820 --> 00:09:17,960
And you have the IP address, you can download it and you can just actually go and see what they are using, how they are using it, what they are, all the tools that go along with it, and it will give you a lot of information.

111
00:09:18,440 --> 00:09:33,840
It can get to the point, it can get to way too much information, like the previous speaker was talking about leaks, well, maybe these guys don't always delete the data from their victims on these kind of VMs, so they just move them around from system to system,

112
00:09:33,840 --> 00:09:36,340
so maybe you'll get other information there.

113
00:09:36,380 --> 00:09:44,880
So, and it's not, it's just a query on show that, or census, or whatever platform you have of the same kind.

114
00:09:46,000 --> 00:09:54,680
So, now that we have our behavior, we know how it works, we know how to hunt for it on show that, now we need to actually qualify the results.

115
00:09:54,720 --> 00:09:59,640
So, just having the MZ address is not enough, as I was telling you, you want to get more information.

116
00:10:01,100 --> 00:10:12,560
Sometimes it is incomplete, as we talked about, so we need to actually be able to get it out, be able to analyze it, and kind of start to build your own database for it.

117
00:10:13,200 --> 00:10:21,460
Of course, because we also use a lot of ClamAV, we'll use ClamAV to actually analyze it, the first byte, you can use ClamAV, it can be Yari, rules, whatever.

118
00:10:21,460 --> 00:10:27,360
Whatever you find, you need to qualify it into something that you are absolutely sure that you can block.

119
00:10:27,360 --> 00:10:34,140
Remember, a lot of this information may lead you to false positives, and that's what you don't want that.

120
00:10:34,500 --> 00:10:41,180
The first, these kind of projects, they're always really fun, and everyone likes it, until you stop the business.

121
00:10:41,940 --> 00:10:43,480
That's when everything goes away.

122
00:10:43,480 --> 00:10:49,980
So, you want to be sure that, give little incremental steps, but sure steps that you won't be messing with the business.

123
00:10:50,160 --> 00:10:54,600
That's kind of a key, you need to earn their trust for some reason, yeah.

124
00:10:54,820 --> 00:11:10,200
So, in this case, what we do is that we download the Cobalt Stripe beacons, we get the information, we start to process it every day, we scan the internet every day for the JARM signatures, and we try to collect as much information as we can about certain IP addresses,

125
00:11:10,200 --> 00:11:14,540
and as time goes along, we start to build a profiling, basically.

126
00:11:14,540 --> 00:11:25,660
And we know that some actors will get an IP address, then it will go away when they get exposed, and sometimes they will go back into the same IP address because they have that little set of hosting providers that they like.

127
00:11:25,720 --> 00:11:35,400
So, we start to get a good idea of how, what's the likelihood of that IP address becoming bad over time, and then good and then bad.

128
00:11:36,280 --> 00:11:45,520
So, it's our process of automation, it's just query, okay, query the results, query what we know about it, filter the results, and go back to the active scan.

129
00:11:45,560 --> 00:11:52,180
Remember that Sheldon will not give you everything, so in some cases, you might need to have your own scanning process to get it.

130
00:11:52,180 --> 00:12:02,240
So, you get an IP address that probably is malicious, but there's not, the full date is not there, so you might do your own scanning to that IP address to make sure that it's actually malicious before you want to block it.

131
00:12:02,240 --> 00:12:05,260
It's just a question of, okay, trust but verify.

132
00:12:05,720 --> 00:12:08,520
Because again, we don't want any false positives.

133
00:12:09,960 --> 00:12:11,820
And again, store everything.

134
00:12:14,340 --> 00:12:21,100
A lot of what we get, of course, it's open out there, but we need to establish a profile.

135
00:12:21,100 --> 00:12:26,180
You need to keep, in order to avoid false positives, you need to keep a profile of what's going on.

136
00:12:26,600 --> 00:12:34,860
On that IP address, there will be times that we'll have IP addresses with a C2, but there will be times that that IP address, before it has a C2, it has an open D where you can get information from it.

137
00:12:34,860 --> 00:12:48,980
So, you start to build a profile of what's going on, and more confidence you'll have that when you block it, instead of blocking it for just one day and every day verify it, maybe start blocking two days and verify every three days, you kind of get that confidence,

138
00:12:48,980 --> 00:12:51,800
because you don't have the limited resources.

139
00:12:51,940 --> 00:12:56,180
You won't be able to scan all of these IP addresses every day.

140
00:12:56,180 --> 00:13:00,220
Unless you have a lot of money, in that case that doesn't really matter, but most companies don't.

141
00:13:00,300 --> 00:13:12,060
So, you need to start to actually build a confidence level on your analysis so that over time, instead of scanning the same IP every day, you'll scan it every two days or every three days, and then you go back.

142
00:13:12,680 --> 00:13:14,820
And for that, you need to have more information.

143
00:13:14,820 --> 00:13:17,500
You need to keep and store all the information you can.

144
00:13:18,760 --> 00:13:25,420
So, for us, we have a little database that will allow us to give you context, to know what it was, when it was, where the information came from.

145
00:13:25,420 --> 00:13:32,560
It's not really complex, we try to keep it as simple as we can, but it's important for us to have a context.

146
00:13:32,560 --> 00:13:38,740
So, we know that over this period of time, this IP address has had this kind of information, it came from these sources.

147
00:13:38,740 --> 00:13:42,400
And this allows us to build a confidence level for what we are doing.

148
00:13:44,120 --> 00:13:46,340
So, and then, of course, you need to share it.

149
00:13:46,420 --> 00:13:48,040
You are doing this for yourselves.

150
00:13:48,040 --> 00:13:57,920
I'm not saying you should share it outside your company, but you definitely should and must share it within your company, because that's where the value of what you are doing actually reflects.

151
00:13:58,440 --> 00:14:01,280
So, you are scanning this, and you need to block it.

152
00:14:01,280 --> 00:14:07,800
Maybe you don't, you cannot block it yourself, you need to share it with whoever takes care of the firewalls or the rules or whatever.

153
00:14:07,840 --> 00:14:15,080
But also, you might want to share this with your instant response guys.

154
00:14:15,340 --> 00:14:23,900
So, there are some cases where, for instance, you don't know what it was, you have an incident and you want to know what's this IP address, and you don't know it.

155
00:14:24,160 --> 00:14:35,440
But if you go back to this information, you might know that today I don't know what this IP address has, but well, a few months ago, it had a C2 for Cobalt Strike.

156
00:14:35,920 --> 00:14:43,120
So, you can actually go back and see that, and you cannot trust 100% all of the scanners, but you know what you have because you have your own information.

157
00:14:43,120 --> 00:14:52,260
So, sharing this with anyone in your organization is important, because it helps the instant response, it helps researchers, it will help a lot of people.

158
00:14:52,780 --> 00:15:05,320
Not often you share this outside of your organization, because some of these might be more important to you, it might tell you something about your business, so there is some equilibrium here, and also because most of this is already in Shodan, but internally,

159
00:15:05,320 --> 00:15:09,300
it's really important for you to share with all of your organization what you know about these IP addresses.

160
00:15:09,300 --> 00:15:11,680
And remember, this is ahead of time.

161
00:15:12,180 --> 00:15:22,640
All of that we are doing, it's ahead of time, but when something happens, well, if you didn't block it, but you have information about it because you detected it earlier, then that's helpful.

162
00:15:23,200 --> 00:15:26,460
And you may reduce and you may contain an incident much faster.

163
00:15:28,260 --> 00:15:39,840
So, and then, well, we go back to the same thing, which is, okay, let's keep going, let's keep helping, let's keep an eye on it, let's have a circle, it doesn't stop once, it's something that it keeps repeating.

164
00:15:39,840 --> 00:15:50,260
It's interesting that while we were doing this, we actually noticed that at some point, Cobalt Stripe just went down in the number of C2s that were online, and at the same time, the sliver just went up.

165
00:15:50,260 --> 00:15:53,640
For some reason, at that point in time, something happened, and we'll see this.

166
00:15:53,640 --> 00:16:06,720
For instance, you'll see that some C2s will actually have more popularity at some point in time because a new version was released, because something was leaked, because there was some licenses that were leaked, and you'll see kind of changes in the way that this behaves.

167
00:16:06,720 --> 00:16:13,060
But again, this will tell you, of course, this is historical data, but it will also give you a trend.

168
00:16:13,100 --> 00:16:19,160
If a new version of Cobalt Stripe is coming out, well, you might know that you might have more stuff about Cobalt Stripe.

169
00:16:19,160 --> 00:16:26,700
And this allows you to plan ahead, well, as much as you can, of course, but it will allow you a little bit of planning ahead instead of just being reactive.

170
00:16:28,420 --> 00:16:38,580
So, in terms of improving, and I did my talk really fast, well, in terms of improving, it's keeping track of what you're doing, trying to narrow the gaps.

171
00:16:38,680 --> 00:16:45,540
There are a lot... so, these are the examples that I gave you are just a couple of examples that you come across with, but there are a lot of stuff that you can actually do.

172
00:16:45,540 --> 00:16:47,760
So, show them, census and all that.

173
00:16:47,760 --> 00:16:51,580
It's not just about reaction.

174
00:16:51,880 --> 00:16:53,400
They are scanning the internet.

175
00:16:53,400 --> 00:17:05,940
The bad guys, they will have a lot of stuff out there exposed, especially if they don't do any kind of geofencing, if they are not concerned about the geography of their victims.

176
00:17:05,940 --> 00:17:10,300
So there will be a lot of data there that will help you to protect ahead of time.

177
00:17:10,360 --> 00:17:12,120
Just a question of being creative.

178
00:17:12,260 --> 00:17:22,760
Every time you have an incident, try to figure out if you could have detected that ahead of time based on the information that was actually shared available to you and what's on the scanning data.

179
00:17:23,100 --> 00:17:29,280
And every time that happens, you can probably improve your process and make it so that you can be alerted ahead of time.

180
00:17:29,280 --> 00:17:29,880
Not always.

181
00:17:29,880 --> 00:17:30,900
It's about blocking.

182
00:17:30,900 --> 00:17:38,200
It might just be about making a rule about having an alert or having some alerts which are not prone to false positives.

183
00:17:38,200 --> 00:17:45,940
We always have a lot of alerts in our telemetry and we don't have the resources to reach to them all.

184
00:17:45,960 --> 00:18:00,300
So having this kind of information that allows you to define what is a high priority alert because I have more information that allows me to figure out that this is actually a bad thing, I can dedicate the resources to this bad thing instead of going just by the queue one by one,

185
00:18:00,300 --> 00:18:01,560
increasing the priority.

186
00:18:01,580 --> 00:18:09,320
So it's all about getting ahead of time with the information that is out there, putting it into your own environment and then use it the best way you can.

187
00:18:10,000 --> 00:18:12,180
And I always talk too fast.

188
00:18:12,180 --> 00:18:13,260
Sorry about that.

189
00:18:14,380 --> 00:18:16,720
I'm available for any questions if you have them.

190
00:18:30,430 --> 00:18:31,330
No questions?

191
00:18:31,330 --> 00:18:31,970
Okay.

192
00:18:45,620 --> 00:18:50,640
So we usually prioritize all kinds of C2s.

193
00:18:51,520 --> 00:18:52,740
Frameworks, basically.

194
00:18:52,740 --> 00:18:56,560
So all of those which are the ones that will give you the next step.

195
00:18:56,880 --> 00:19:01,100
And those are the ones that have more prevalence being exposed.

196
00:19:01,100 --> 00:19:03,320
So that maximizes our results.

197
00:19:03,320 --> 00:19:05,480
Those are our initial priorities.

198
00:19:05,480 --> 00:19:16,100
And then we have other stuff that we do which is not as prioritized like looking for ports that are exposing weird stuff like bash scripts or that kind of stuff.

199
00:19:16,120 --> 00:19:24,820
But the priority always goes to the frameworks because that will give us a better... they are more exposed for a longer time, the IP address are predictable, there's a lot more into it.

200
00:19:24,840 --> 00:19:31,140
Stuff like the executables are also one of the priorities because if they are on that code, it gives you immediate results also.

201
00:19:31,620 --> 00:19:32,240
Okay.

202
00:19:33,580 --> 00:19:34,740
Okay, thank you.