[00:00.000 --> 00:06.880]  So, the next speaker is Vitor Ventura, who's going to be talking about an interesting topic,
[00:06.880 --> 00:12.720]  which is getting ahead of bad guys, right? We are all good hackers. Here, he's going
[00:12.720 --> 00:19.360]  to... hmm, interesting. I will not say much. I will let him speak. I'm not going to break
[00:19.360 --> 00:21.060]  the suspense here.
[00:22.680 --> 00:29.980]  So, hello everyone. So, I'm Vitor Ventura. I work for Cisco Talos. I'm a Threat Research
[00:30.000 --> 00:34.920]  Researcher. This presentation was done along with my colleague, Arnaud, who unfortunately
[00:34.920 --> 00:40.820]  could not be here with me. So, yeah, I will be doing this alone. But if anything goes
[00:40.820 --> 00:43.600]  wrong, it's his fault, okay? Let's just keep it like that.
[00:45.400 --> 00:50.160]  So, the objective here is getting ahead of the bad guys. We always, whenever we are doing
[00:50.160 --> 00:54.920]  our works, trying to defend, we always want to get ahead. We don't want to be reactive,
[00:54.920 --> 00:58.900]  we want to be proactive. Most of the times, all the data that is scanned on the internet
[00:58.900 --> 01:06.380]  is like Shodan or Synthesis or whatever is, okay, let me see what that IP has because
[01:06.380 --> 01:10.600]  it was attacking me. Let me see what's there because it's attacking me or let me see how
[01:10.600 --> 01:13.220]  my security is from the outside.
[01:13.280 --> 01:19.680]  So, the idea here is that, okay, that's good, but maybe we can get ahead by using this data
[01:19.680 --> 01:24.540]  in our favor, by querying the right things to these kind of tools. So, this is what we
[01:24.540 --> 01:29.200]  want to talk about. So, first of all, the internet is really big, so it's really hard
[01:29.200 --> 01:35.120]  to pinpoint where the bad guys are unless we have some prior information. So, in order
[01:35.120 --> 01:41.880]  to get ahead of that, maybe we can do some analysis, we can look into our IOCs, we can
[01:41.880 --> 01:46.320]  look into leaked data, we can do all sorts of things. But still, the results are not
[01:46.320 --> 01:52.160]  100% what we really want. We want to know where are the bad guys. And we cannot just
[01:52.160 --> 01:57.240]  go ahead and just block IP addresses because chances are we'll have a false positive and
[01:57.240 --> 02:03.020]  we'll end up stopping our business and we'll have a CEO really, really pissed at us. So,
[02:03.020 --> 02:10.340]  the idea is we need to be almost 100% sure that we can block an IP address ahead of time.
[02:10.340 --> 02:15.960]  And that's our goal. So, that's one thing. The other thing is if we don't have any business
[02:15.960 --> 02:20.480]  on Tor sites, for instance, maybe we want to block any Tor exits because we don't want
[02:20.480 --> 02:25.540]  our communication going from inside to Tor exit because maybe that's a way for the bad
[02:25.540 --> 02:29.580]  guys to exfiltrate information. Same thing with VPNs. We need to know our business in
[02:29.580 --> 02:34.460]  order to block it so that when we are doing some of these kind of blocks ahead of time,
[02:34.460 --> 02:41.360]  we are not getting into any risks that things can go wrong. Same thing with IOCs. We all
[02:41.360 --> 02:46.200]  see a lot of IOCs, lists, feeds, and all that kind of thing. But no one really blocks an
[02:46.200 --> 02:51.040]  IP address for a really, really long time. Because if you do, chances are they will rotate,
[02:51.040 --> 02:54.720]  bad guys move to another site, and then you are blocking something that is legitimate.
[02:54.880 --> 02:58.900]  Or for instance, if you just go ahead and block IP addresses, just imagine what happens
[02:59.520 --> 03:03.360]  with sites which are on shared hosts. You block an IP address and all of a sudden you
[03:03.360 --> 03:08.780]  are blocking 100,000 websites, some of which you might need to access. So, all of these
[03:08.780 --> 03:15.920]  are problems that we need to solve ahead of time in order to prevent our proactive efforts
[03:15.920 --> 03:22.100]  from becoming a problem for us. So, that's how we actually see things, and that's how
[03:22.100 --> 03:27.500]  we can actually move forward. So, first of all, we want to have a behavioral analysis.
[03:27.500 --> 03:31.760]  We just don't want to go ahead and block things from IOCs. We want to have a behavioral analysis.
[03:32.000 --> 03:39.140]  And a lot of you, I'm sure, have heard about, for instance, Cobalt Strike. How many of you
[03:39.140 --> 03:46.100]  have actually installed it? One, two, three... two of you work with me. That's not... you
[03:46.100 --> 03:52.200]  don't count. So, three. See, a full room of people that want to defend. Everyone knows
[03:52.200 --> 03:57.040]  about Cobalt Strike, and no one... most of you have never installed it. So, there's a
[03:57.040 --> 04:01.060]  lot to gain to actually install these tools on your own systems to get knowledge on how
[04:01.060 --> 04:06.320]  they work. And I'm talking about Cobalt Strike as an example, but of course we can talk about
[04:06.320 --> 04:13.560]  Sliver, Brutal, all of these C2s that are out there on GitHub or on other repositories.
[04:13.560 --> 04:17.820]  And even from some APT data that you can actually get the samples, get the implants, get them
[04:17.820 --> 04:23.320]  to run on your sandboxes, and try to understand what they do. Because often, we get information
[04:23.320 --> 04:28.720]  about these C2s, we get information about these APT groups, but we don't get what really
[04:28.720 --> 04:34.680]  can help you to defend ahead of time. And that's what we are looking for. We are trying
[04:34.680 --> 04:38.680]  to do reconnaissance ahead of time. I don't want to be waiting for anyone to tell me,
[04:38.680 --> 04:43.040]  this IP address is malicious. If I can get that information for myself, then that's great,
[04:43.040 --> 04:49.380]  and that's what I want to do. So, we need to understand, install it, try it, see which
[04:49.380 --> 04:53.240]  kind of certificates there exist, which kind of... what's the behaviors that you can actually
[04:53.240 --> 04:57.700]  incorporate that into your own infrastructure. Then there's the searches that we were talking
[04:57.700 --> 05:05.340]  about initially. So, on Shodan, you can search for a lot of stuff. You can search how your
[05:05.340 --> 05:11.120]  systems are, but more often, you can actually search for indicators of IP addresses that
[05:11.120 --> 05:16.220]  are serving malicious payloads. And then you can analyze those and block them ahead of
[05:16.220 --> 05:21.440]  time. I imagine that you can actually go into Shodan and search, tell me all the IPs that
[05:21.440 --> 05:29.140]  when I do a request to the web port, gives me a Cobalt Strike Beacon. Those I want to
[05:29.140 --> 05:34.440]  block. If I can get the configuration, if I'm absolutely sure, I want to block those.
[05:34.440 --> 05:39.200]  There's no reason why my organization should be accessing an IP address that, by default,
[05:39.200 --> 05:43.180]  when I access port 80, will give me a Cobalt Strike Beacon. And that's a false positive,
[05:43.180 --> 05:49.260]  almost null. So, there are that kind of searches that you can actually do. This is a different
[05:49.260 --> 05:58.460]  example for the Mythic 5 Beacon data, but the principle is the same. You want to query
[05:58.460 --> 06:02.800]  these kind of platforms for stuff that you know that are malicious, and then from there,
[06:02.800 --> 06:08.960]  you move on to block them. Of course, it's not 100% like that. There are some caveats
[06:08.960 --> 06:13.000]  to this. In some cases, you need to do a little more work. In other cases, you need to do
[06:13.000 --> 06:20.040]  less work. Synthesis can also help you with this kind of information. So, if you have
[06:20.160 --> 06:24.360]  a Yara rule that you can actually search for an IP address, this is a more practical example.
[06:24.360 --> 06:28.860]  You can actually search for... on Shodan, you can search for words, but you can also
[06:28.860 --> 06:33.700]  search for byte strings. So, if you search for the mz header, you know that that will
[06:33.700 --> 06:39.300]  be serving an executable. So, you can actually go there and do that, but Shodan will not
[06:39.300 --> 06:43.300]  give you the full payload. It will give you... it will truncate the data, so there's not
[06:43.300 --> 06:50.940]  100% of the data. But, if you have a rule that somehow matches... that can match data
[06:50.940 --> 06:55.580]  in the amount of bytes that Shodan actually gives you, you have a good way to identify
[06:55.580 --> 07:00.380]  malicious stuff. So, this is what we did, basically. We have rules that just run on
[07:00.380 --> 07:05.480]  the first bytes, and with that, we can actually check if it's malicious or not. In this case,
[07:05.480 --> 07:10.080]  you start by checking if it's an executable. You cannot block all the IP addresses that
[07:10.080 --> 07:14.980]  are on Shodan delivering executables. There are a lot of good reasons for them to deliver
[07:14.980 --> 07:21.200]  you an executable. But, because the data is long enough, you can actually get the part
[07:21.200 --> 07:25.740]  of the data that will tell you if it's a Cobalt Stripe beacon or not, because the configuration
[07:25.740 --> 07:31.440]  is on the first bytes. So, you can actually do that. So, the idea is, you can look for
[07:31.440 --> 07:37.540]  the data, have some rules on the beginning of the payload, and identify. Another good
[07:37.540 --> 07:43.640]  example is that Metapeter Android payloads. This is actually how the whole project started.
[07:43.740 --> 07:49.040]  So, in this case, we know that this will be an implant for Android. There is no reason
[07:49.040 --> 07:55.020]  why we should be actually allowing this. So, the idea is, let's go into these kind of platforms,
[07:55.020 --> 07:59.420]  get all the data, make sure that we don't have any false positives, and then, well,
[07:59.420 --> 08:03.260]  we just can get creative and search for the stuff. I've just given you a few examples.
[08:03.400 --> 08:07.980]  You can also search for bus history. There's even some cases, well, I think it's a little
[08:07.980 --> 08:14.300]  ahead, where we found entire VMs, which had a lot of information, really nice information,
[08:14.300 --> 08:20.860]  actually. So, we need to just keep in mind, be creative. Don't use that data just for
[08:20.860 --> 08:25.800]  what you actually, yourself, go ahead of time. But then, you need to automate it. There's
[08:25.800 --> 08:32.240]  all kinds of results that you can get from this. This is just a huge amount of them.
[08:32.240 --> 08:36.480]  You just need to figure out what do you think that you might get hit you. Every time you
[08:36.480 --> 08:40.520]  get something that hits your organization, just try to create some kind of search that
[08:40.520 --> 08:44.700]  you can go and show that and see if it's giving you back that. And if it is, then you can
[08:44.700 --> 08:50.360]  actually get the process in automated process that will actually help you to protect ahead
[08:50.360 --> 08:56.300]  of time, instead of only reactively. So, as for the VM, well, if you search for VM
[08:56.300 --> 09:01.240]  and Cobalt, you might just get a Gobal Strike VM, fully ready to use, without encryption.
[09:01.240 --> 09:04.860]  I will not tell you where it is, but, well, you can check out by the kind of language
[09:04.860 --> 09:10.040]  and all of that. So, just go and it's there. And you have the IP address, you can download
[09:10.040 --> 09:14.380]  it and you can just actually go and see what they are using, how they are using it, what
[09:14.380 --> 09:17.960]  they are, all the tools that go along with it, and it will give you a lot of information.
[09:18.440 --> 09:24.280]  It can get to the point, it can get to way too much information, like the previous speaker
[09:24.280 --> 09:28.920]  was talking about leaks, well, maybe these guys don't always delete the data from their
[09:28.920 --> 09:33.980]  victims on these kind of VMs, so they just move them around from system to system, so
[09:33.980 --> 09:40.160]  maybe you'll get other information there. So, and it's not, it's just a query on show
[09:40.160 --> 09:47.780]  that, or census, or whatever platform you have of the same kind. So, now that we have
[09:48.320 --> 09:52.940]  our behavior, we know how it works, we know how to hunt for it on show that, now we need
[09:52.940 --> 09:57.420]  to actually qualify the results. So, just having the MZ address is not enough, as I
[09:57.420 --> 10:03.040]  was telling you, you want to get more information. Sometimes it is incomplete, as we talked about,
[10:03.040 --> 10:08.720]  so we need to actually be able to get it out, be able to analyze it, and kind of start to
[10:08.720 --> 10:16.280]  build your own database for it. Of course, because we also use a lot of ClamAV, we'll
[10:16.280 --> 10:20.460]  use ClamAV to actually analyze it, the first byte, you can use ClamAV, it can be Yari,
[10:20.460 --> 10:25.320]  rules, whatever. Whatever you find, you need to qualify it into something that you are
[10:25.320 --> 10:30.600]  absolutely sure that you can block. Remember, a lot of this information may lead you to
[10:30.600 --> 10:37.000]  false positives, and that's what you don't want that. The first, these kind of projects,
[10:37.000 --> 10:42.480]  they're always really fun, and everyone likes it, until you stop the business. That's when
[10:42.480 --> 10:47.780]  everything goes away. So, you want to be sure that, give little incremental steps, but sure
[10:47.780 --> 10:52.660]  steps that you won't be messing with the business. That's kind of a key, you need to earn their
[10:52.660 --> 10:58.240]  trust for some reason, yeah. So, in this case, what we do is that we download the Cobalt
[10:58.240 --> 11:03.420]  Stripe beacons, we get the information, we start to process it every day, we scan the
[11:03.420 --> 11:07.960]  internet every day for the JARM signatures, and we try to collect as much information
[11:07.960 --> 11:14.140]  as we can about certain IP addresses, and as time goes along, we start to build a profiling,
[11:14.140 --> 11:18.460]  basically. And we know that some actors will get an IP address, then it will go away when
[11:18.460 --> 11:22.300]  they get exposed, and sometimes they will go back into the same IP address because they
[11:22.300 --> 11:28.600]  have that little set of hosting providers that they like. So, we start to get a good
[11:28.600 --> 11:34.400]  idea of how, what's the likelihood of that IP address becoming bad over time, and then
[11:34.400 --> 11:40.600]  good and then bad. So, it's our process of automation, it's just query, okay, query the
[11:40.600 --> 11:45.520]  results, query what we know about it, filter the results, and go back to the active scan.
[11:45.560 --> 11:50.280]  Remember that Sheldon will not give you everything, so in some cases, you might need to have your
[11:50.280 --> 11:54.680]  own scanning process to get it. So, you get an IP address that probably is malicious,
[11:54.680 --> 11:57.960]  but there's not, the full date is not there, so you might do your own scanning to that
[11:57.960 --> 12:02.480]  IP address to make sure that it's actually malicious before you want to block it. It's
[12:02.480 --> 12:08.520]  just a question of, okay, trust but verify. Because again, we don't want any false positives.
[12:09.960 --> 12:19.200]  And again, store everything. A lot of what we get, of course, it's open out there, but
[12:19.200 --> 12:24.020]  we need to establish a profile. You need to keep, in order to avoid false positives, you
[12:24.020 --> 12:28.300]  need to keep a profile of what's going on. On that IP address, there will be times that
[12:28.300 --> 12:31.900]  we'll have IP addresses with a C2, but there will be times that that IP address, before
[12:31.900 --> 12:36.060]  it has a C2, it has an open D where you can get information from it. So, you start to
[12:36.060 --> 12:40.440]  build a profile of what's going on, and more confidence you'll have that when you block
[12:40.440 --> 12:44.540]  it, instead of blocking it for just one day and every day verify it, maybe start blocking
[12:44.540 --> 12:50.400]  two days and verify every three days, you kind of get that confidence, because you don't
[12:50.400 --> 12:55.660]  have the limited resources. You won't be able to scan all of these IP addresses every
[12:55.660 --> 12:59.300]  day. Unless you have a lot of money, in that case that doesn't really matter, but most
[12:59.300 --> 13:05.300]  companies don't. So, you need to start to actually build a confidence level on your
[13:05.300 --> 13:09.360]  analysis so that over time, instead of scanning the same IP every day, you'll scan it every
[13:09.360 --> 13:14.260]  two days or every three days, and then you go back. And for that, you need to have more
[13:14.260 --> 13:17.500]  information. You need to keep and store all the information you can.
[13:18.760 --> 13:22.340]  So, for us, we have a little database that will allow us to give you context, to know
[13:22.340 --> 13:27.960]  what it was, when it was, where the information came from. It's not really complex, we try
[13:27.960 --> 13:33.080]  to keep it as simple as we can, but it's important for us to have a context. So, we know that
[13:33.080 --> 13:37.700]  over this period of time, this IP address has had this kind of information, it came
[13:37.700 --> 13:42.400]  from these sources. And this allows us to build a confidence level for what we are doing.
[13:44.120 --> 13:48.240]  So, and then, of course, you need to share it. You are doing this for yourselves. I'm
[13:48.240 --> 13:52.480]  not saying you should share it outside your company, but you definitely should and must
[13:52.480 --> 13:57.120]  share it within your company, because that's where the value of what you are doing actually
[13:57.120 --> 14:02.580]  reflects. So, you are scanning this, and you need to block it. Maybe you don't, you cannot
[14:02.580 --> 14:06.720]  block it yourself, you need to share it with whoever takes care of the firewalls or the
[14:06.720 --> 14:15.080]  rules or whatever. But also, you might want to share this with your instant response guys.
[14:15.340 --> 14:20.040]  So, there are some cases where, for instance, you don't know what it was, you have an incident
[14:20.040 --> 14:24.960]  and you want to know what's this IP address, and you don't know it. But if you go back
[14:24.960 --> 14:29.960]  to this information, you might know that today I don't know what this IP address has, but
[14:29.960 --> 14:37.320]  well, a few months ago, it had a C2 for Cobalt Strike. So, you can actually go back and see
[14:37.320 --> 14:41.940]  that, and you cannot trust 100% all of the scanners, but you know what you have because
[14:41.940 --> 14:47.420]  you have your own information. So, sharing this with anyone in your organization is important,
[14:48.140 --> 14:52.260]  because it helps the instant response, it helps researchers, it will help a lot of people.
[14:52.780 --> 14:58.160]  Not often you share this outside of your organization, because some of these might be more important
[14:58.160 --> 15:01.500]  to you, it might tell you something about your business, so there is some equilibrium
[15:01.500 --> 15:05.880]  here, and also because most of this is already in Shodan, but internally, it's really important
[15:05.880 --> 15:09.300]  for you to share with all of your organization what you know about these IP addresses.
[15:09.300 --> 15:14.580]  And remember, this is ahead of time. All of that we are doing, it's ahead of time, but
[15:14.580 --> 15:19.180]  when something happens, well, if you didn't block it, but you have information about it
[15:19.180 --> 15:25.100]  because you detected it earlier, then that's helpful. And you may reduce and you may contain
[15:25.100 --> 15:31.320]  an incident much faster. So, and then, well, we go back to the same thing, which is, okay,
[15:31.320 --> 15:37.280]  let's keep going, let's keep helping, let's keep an eye on it, let's have a circle, it
[15:37.280 --> 15:41.060]  doesn't stop once, it's something that it keeps repeating. It's interesting that while
[15:41.060 --> 15:45.520]  we were doing this, we actually noticed that at some point, Cobalt Stripe just went down
[15:45.520 --> 15:50.260]  in the number of C2s that were online, and at the same time, the sliver just went up.
[15:50.260 --> 15:54.000]  For some reason, at that point in time, something happened, and we'll see this. For instance,
[15:54.000 --> 15:58.280]  you'll see that some C2s will actually have more popularity at some point in time because
[15:58.400 --> 16:02.620]  a new version was released, because something was leaked, because there was some licenses
[16:02.620 --> 16:07.820]  that were leaked, and you'll see kind of changes in the way that this behaves. But again, this
[16:07.820 --> 16:13.220]  will tell you, of course, this is historical data, but it will also give you a trend. If
[16:13.320 --> 16:17.700]  a new version of Cobalt Stripe is coming out, well, you might know that you might have more
[16:17.700 --> 16:22.360]  stuff about Cobalt Stripe. And this allows you to plan ahead, well, as much as you can,
[16:22.360 --> 16:25.840]  of course, but it will allow you a little bit of planning ahead instead of just being
[16:25.840 --> 16:35.080]  reactive. So, in terms of improving, and I did my talk really fast, well, in terms of
[16:35.080 --> 16:38.900]  improving, it's keeping track of what you're doing, trying to narrow the gaps. There are
[16:39.060 --> 16:42.160]  a lot... so, these are the examples that I gave you are just a couple of examples that
[16:42.160 --> 16:46.240]  you come across with, but there are a lot of stuff that you can actually do. So, show
[16:46.240 --> 16:53.400]  them, census and all that. It's not just about reaction. They are scanning the internet.
[16:53.400 --> 16:57.940]  The bad guys, they will have a lot of stuff out there exposed, especially if they don't
[16:57.940 --> 17:05.940]  do any kind of geofencing, if they are not concerned about the geography of their victims.
[17:05.940 --> 17:10.520]  So there will be a lot of data there that will help you to protect ahead of time. Just
[17:10.640 --> 17:14.880]  a question of being creative. Every time you have an incident, try to figure out if you
[17:14.880 --> 17:20.020]  could have detected that ahead of time based on the information that was actually shared
[17:20.020 --> 17:24.400]  available to you and what's on the scanning data. And every time that happens, you can
[17:24.400 --> 17:29.280]  probably improve your process and make it so that you can be alerted ahead of time.
[17:29.280 --> 17:33.620]  Not always. It's about blocking. It might just be about making a rule about having an
[17:33.620 --> 17:39.320]  alert or having some alerts which are not prone to false positives. We always have a
[17:39.320 --> 17:45.940]  lot of alerts in our telemetry and we don't have the resources to reach to them all.
[17:45.960 --> 17:50.640]  So having this kind of information that allows you to define what is a high priority alert
[17:50.640 --> 17:54.380]  because I have more information that allows me to figure out that this is actually a bad
[17:54.380 --> 17:59.200]  thing, I can dedicate the resources to this bad thing instead of going just by the queue
[17:59.200 --> 18:04.420]  one by one, increasing the priority. So it's all about getting ahead of time with the information
[18:04.420 --> 18:08.520]  that is out there, putting it into your own environment and then use it the best way
[18:08.520 --> 18:15.580]  you can. And I always talk too fast. Sorry about that. I'm available for any questions
[18:15.580 --> 18:31.970]  if you have them. No questions? Okay.
[18:45.620 --> 18:54.180]  So we usually prioritize all kinds of C2s. Frameworks, basically. So all of those which
[18:54.180 --> 18:59.140]  are the ones that will give you the next step. And those are the ones that have more
[18:59.140 --> 19:05.480]  prevalence being exposed. So that maximizes our results. Those are our initial priorities.
[19:05.480 --> 19:12.280]  And then we have other stuff that we do which is not as prioritized like looking for ports
[19:12.280 --> 19:17.340]  that are exposing weird stuff like bash scripts or that kind of stuff. But the priority always
[19:17.340 --> 19:21.640]  goes to the frameworks because that will give us a better... they are more exposed for a
[19:21.640 --> 19:25.620]  longer time, the IP address are predictable, there's a lot more into it. Stuff like the
[19:25.620 --> 19:29.560]  executables are also one of the priorities because if they are on that code, it gives
[19:29.560 --> 19:34.740]  you immediate results also. Okay. Okay, thank you.