WEBVTT 00:00.000 --> 00:04.300 Hello, everyone, and thank you to be here. 00:04.300 --> 00:13.300 First of all, I would like to thank the organization for the possibility to be here today. 00:13.320 --> 00:26.200 I know it's not the same as being in Vegas, but it's a certain honor for me to be able to participate in this new modality of DEF CON, an online modality. 00:26.200 --> 00:44.580 Before starting, I would like to clarify that the purpose of this presentation is to show how simple it can be to maintain access to an organization during an intrusion, a real intrusion or a simulation like a red team exercise. 00:44.580 --> 01:03.760 But it's true that I'm not going to focus on each technique, on the technical part, because many of the techniques are simple and have been exposed several times in public documents and presentations like this. 01:04.060 --> 01:11.820 So let's start with the presentation and see how we can organize our infrastructure. 01:11.820 --> 01:20.260 Okay, about me, a really simple overview about who am I. 01:20.260 --> 01:21.700 I'm Eduardo Aviles. 01:21.700 --> 01:27.820 I'm the co-founder of the cybersecurity startup here in Spain. 01:43.040 --> 01:52.940 At the same time, I work at different universities here in Spain, and well, mainly in the Utah University. 01:54.300 --> 02:05.320 More about me, well, for more than eight years, I've been dedicated on the world of cybersecurity and currently on hacking. 02:05.320 --> 02:22.920 And last five years, I work as a manager of different red team services, where the only job was to develop real attack simulations on large scale companies here in Spain. 02:22.920 --> 02:25.200 And internationally. 02:25.500 --> 02:44.340 So during these simulations, and after not being detected, we normally force the development of tests to measure the detection and response capabilities, where we observe the true capability of dealing with the target attack. 02:44.340 --> 02:57.540 And because of that, I have seen very similar actions between companies, and one of them is the lack of knowledge on how to act when they detect an attacker. 02:58.100 --> 03:00.420 And mainly, how to do it. 03:00.420 --> 03:11.860 So it is very common to find blue teams that detect users, computers, and block them, and think that they have already kicked the attacker out. 03:11.860 --> 03:15.400 But the truth is completely different. 03:15.400 --> 03:36.880 If an attacker has managed to gain high privilege, like administration privilege, for example, in the domain, or in the network, it is trivial that he can continue accessing, as we will see here in this presentation. 03:40.840 --> 03:42.440 Table of contents. 03:42.440 --> 03:57.960 Here, as I suppose you know that the title of the talks refers to the movie of the same title, because it is the pure reality for me of an intuition when an infrastructure of persistence exists while deployed. 03:57.960 --> 04:05.860 If we do the things okay, it is really difficult for the blue team to detect us. 04:05.860 --> 04:09.980 So we will see mainly four parts. 04:09.980 --> 04:24.160 The first one is the introduction, where we will see the basic concepts about persistence, what is persistence, why we need to deploy it, where, when, and so on. 04:24.160 --> 04:29.760 The second point is about traditional persistence. 04:29.760 --> 04:35.220 I mean, the persistence in a traditional way or traditional approach. 04:35.780 --> 04:41.900 Like, how can we deploy persistence on the internal servers, workstation, and so on. 04:41.900 --> 04:50.240 Okay, so this point is a basic overview of the main techniques that we could use as an actor inside the company. 04:50.340 --> 05:08.920 And the third point is, in my opinion, the most important part of this presentation, because we will see some really basic action that we could use as an actor to maintain persistence on the organization. 05:08.920 --> 05:17.820 And not only basic, but at the same time really difficult to detect for the blue team. 05:17.980 --> 05:28.880 And the last point is the conclusion about if you really think the blue team can catch us during an intuition. 05:28.880 --> 05:34.100 So let's start with the first point about the introduction. 05:34.460 --> 05:45.720 First of all, I would like to show a simple outline, a simple overview of what the infrastructure of an organization could be like. 05:45.720 --> 05:47.480 This is more or less. 05:48.460 --> 05:56.560 This part corresponds, as we will see later, with the possible infrastructure that is necessary for an actor. 05:56.560 --> 06:01.180 I don't know if you see the mouse is here. 06:01.180 --> 06:06.240 So this part is basically the infrastructure of an actor. 06:06.240 --> 06:10.640 But all of them is about the infrastructure of the company. 06:10.640 --> 06:22.800 Here we can see, for example, the Demilitarized Zone with some servers like web application, email servers, or other corporate servers like, for example, VPN. 06:23.940 --> 06:27.120 Inside the network, we can see a network. 06:27.120 --> 06:36.140 Normally, we have so many networks, not only one network, because the company normally is segmented in different networks and that type of thing. 06:36.140 --> 06:38.940 But, well, this is a real simple overview. 06:38.940 --> 06:57.320 So here we can see, well, the domain controller of an active directory, for example, servers internally, the building, and other network dedicated to the employees, because it's normally divided into a different network. 06:57.440 --> 07:02.940 This type of servers could be proxies to access to the Internet. 07:02.940 --> 07:12.560 Here we can have another similar infrastructure, and I think, because of my experience, it's really common. 07:12.560 --> 07:32.920 In companies that are really big and they have presence in many countries and in many locations, it's common that they have a small infrastructure, but at the same time with other domain or subdomain, domain controller, internal servers, workstation, and all the same infrastructure. 07:32.940 --> 07:35.840 But in different locations. 07:36.180 --> 07:51.380 And at the same time, in this small and simple structure of a company, we could see some different providers, like Google Cloud Platforms, Amazon, or Azure. 07:51.460 --> 07:57.340 Typical providers where the company could deploy private cloud. 07:57.940 --> 08:21.520 And the last part here, this icon of a building represents a provider, a more traditional provider of the organization, because it's possible that this provider and the cloud platforms too could have access internally to the network for some different things that we will see later. 08:22.210 --> 08:24.520 This is a really simple overview. 08:24.520 --> 08:35.600 Normally, if you work in a company or you do a penetration testing or a red team exercise, normally the network infrastructure is really more complex. 08:35.600 --> 08:42.790 This is only a simple overview to understand the different type of persistence that we will see later in the presentation. 08:42.790 --> 08:48.650 So, the first concept is about what is persistence. 08:48.650 --> 08:51.550 And in my opinion, it's really simple. 08:51.550 --> 09:12.230 Persistence refers to the concept of maintaining access to the organization for a long period of time, guaranteeing the possibility of accessing the entity through additional ways, and without the use of access vectors detected initially. 09:15.050 --> 09:27.810 So, this type of actions, in many cases, not carried out currently, is really important since the security team detects the action of the red team. 09:27.810 --> 09:28.990 It is simple. 09:28.990 --> 09:29.980 Game over. 09:29.980 --> 09:44.500 So, because of that, we really need to deploy a correct infrastructure of persistence that allows us to continue accessing to the organization for a long period of time. 09:44.500 --> 09:51.200 Because normally, this type of exercise could extend many months in time. 09:51.200 --> 09:59.340 So, let's see what difference could there be in the previous scenario if we deployed persistence. 09:59.480 --> 10:04.300 We see this scenario, simple, bad company. 10:04.400 --> 10:11.960 But, at the same time, we could see this other one, but with more things. 10:11.960 --> 10:29.660 For example, in this case, we see all the different persistence that we will see later in the presentation that start a reverse connection and allow us, as an advert, to access directly to an internal server. 10:29.660 --> 10:42.400 And we can configure persistence, for example, in providers, in workstations, in internal servers, or in an additional infrastructure in other locations, for example. 10:43.180 --> 10:51.840 One important question that we will see later, too, is that persistence is a backup. 10:51.840 --> 10:58.480 Normally, the red team uses the access vector, or one persistence. 10:58.480 --> 11:06.020 But, the other type of persistence normally, or should always be, a backup. 11:06.100 --> 11:19.500 It's really, really important because if you need one because we have lost access, you must decide which one and use it as an access vector from that moment. 11:19.500 --> 11:27.120 But, always without making use of others and, therefore, guarantee their future use. 11:27.120 --> 11:31.580 It is really, really, really important. 11:31.580 --> 11:50.880 And, of course, as we will see, we could use another type of persistence, more like incoming, where the red team is really connected to some computers or some other type of access, like, for example, Wi-Fi access, to access to the organization. 11:50.880 --> 11:58.080 So, this is only an example, but we could deploy more and more and more and more persistence. 11:58.080 --> 12:20.860 As we will see, we could use internal servers as a persistence, internal workstations, Wi-Fi, persistence on the domain controller, on the active directory, provider cloud, private cloud, and many other locations where we can deploy persistence. 12:20.880 --> 12:23.820 And this is the question. 12:23.820 --> 12:35.480 If we configure currently that type of persistence, we could be sure that always where we can access, we could access. 12:35.480 --> 12:35.800 Okay? 12:35.800 --> 12:37.160 It is really important. 12:37.160 --> 12:40.540 So, more basic concepts, really simple. 12:40.540 --> 12:41.460 Why? 12:41.880 --> 12:43.020 Well, why? 12:43.020 --> 12:45.720 Maybe it's a really, really simple question. 12:46.000 --> 12:59.300 Because we want to maintain access to the organization for a long period of time, as a real attacker could do, because normally we need to simulate a real attacker. 12:59.300 --> 13:00.520 Okay. 13:00.520 --> 13:13.240 On many occasions, it is really trivial to deploy persistence, as we will see later, guarantee us in a simple way to continue with intrusion at any time. 13:13.240 --> 13:14.480 Okay. 13:14.480 --> 13:15.860 The next concept. 13:15.860 --> 13:16.780 Simple what? 13:16.780 --> 13:17.580 Where? 13:17.580 --> 13:22.480 The simplest answer is as everywhere as you can. 13:22.480 --> 13:30.600 Typically, many teams focus on deploy persistence only on internal systems or internal servers. 13:30.600 --> 13:43.220 But in my opinion, it is a mistake, since it limits access ways, and at the same time, make it easier to detect persistence to the blue team. 13:43.220 --> 13:43.620 Okay? 13:43.620 --> 13:48.520 So, we will have to deploy persistence in different locations, as we will see. 13:48.520 --> 13:54.420 The military zone, internal server, internal workstation, internal domains, and so on. 13:54.420 --> 14:01.280 But always, depending on the needs and remaining time of the exercise. 14:01.280 --> 14:13.840 If intrusion has been achieved, for example, and there is a week left, the persistence will not be the same as if there is a month left. 14:13.840 --> 14:21.720 For example, if we have only one week, maybe we don't want to spend that week deploying persistence. 14:21.720 --> 14:22.640 Okay? 14:22.640 --> 14:29.540 But if we have more time, it is important to deploy some different type of persistence. 14:29.540 --> 14:30.580 Okay? 14:30.640 --> 14:34.000 And guarantee that access for a long term. 14:34.000 --> 14:37.620 And the last one is when. 14:37.620 --> 14:40.560 When we need to deploy that persistence. 14:40.560 --> 14:47.120 And here again, the answer is as soon as we can do it. 14:47.120 --> 14:47.540 Okay? 14:47.540 --> 14:52.200 It is always good to deploy persistence at different points. 14:52.200 --> 15:00.580 And, well, it will always be a good idea to spend time deploying persistence as intrusion progress. 15:00.580 --> 15:00.900 Okay? 15:00.900 --> 15:09.300 And not just waiting for access to the internal networks or domain administration privilege. 15:09.300 --> 15:15.020 Because if we wait, maybe we could lose access. 15:15.020 --> 15:15.520 Okay? 15:15.520 --> 15:29.820 Because of that, it is really important when we are creating the process of intrusion, whenever we can, it's important to deploy that persistence. 15:29.820 --> 15:30.500 Okay? 15:30.500 --> 15:34.260 But we will see here this point. 15:45.520 --> 15:59.880 Another important aspect to remark is that these techniques are practically used in any exercise and can be performed in many more ways than those shown below. 16:10.960 --> 16:12.960 Okay? 16:12.960 --> 16:20.520 In no case substitute for the use of some types of traditional persistence. 16:20.520 --> 16:20.900 Okay? 16:20.900 --> 16:25.900 It is important to have both or maybe traditional. 16:25.900 --> 16:27.900 It is, of course, important. 16:27.900 --> 16:47.980 So, we are not going to talk about how to achieve persistence or how to maintain or obtain the necessary privilege, but only about the ways to maintain this persistence as this could give for many talks. 16:47.980 --> 16:48.600 Okay? 16:48.600 --> 16:50.460 So, let's start. 16:50.500 --> 16:55.320 With internal servers, both servers and workstations. 16:55.740 --> 16:56.700 Okay. 16:56.740 --> 17:03.200 Note that the possibility of deploying persistence on both servers and workstations is important. 17:03.200 --> 17:03.360 Okay? 17:03.360 --> 17:10.100 We need to deploy it on both types of servers because they are completely different. 17:10.100 --> 17:18.880 Servers tend to have higher availability, but it's less common that they have internet access in many cases. 17:18.880 --> 17:23.300 So, we can configure it, but we need to modify it. 17:23.300 --> 17:26.600 In some cases, this is not the best situation. 17:26.600 --> 17:30.800 On the other hand, we use workstations. 17:30.800 --> 17:40.720 They usually have configured internet access, and also, they also usually have security measures. 17:41.160 --> 17:53.840 Their visions are normally minor than the servers, for example, and therefore, the detection capability of the blue team is less in that type of service. 17:53.840 --> 18:10.580 So, normally, to gain persistence on an internal system, a reverse connection is usually established against a system owner or a server owner, a BPS, for example, owned by an attacker. 18:10.580 --> 18:11.240 Okay? 18:11.240 --> 18:16.120 The left part of the scheme. 18:16.120 --> 18:33.000 So, it is really simple because normally it's like setting a reverse SSH to node to map different ports of the internal machine, okay, where we deploy persistence. 18:33.560 --> 18:43.760 But in any cases, in both systems, it is possible to define the same types of connection which could be devised into the following. 18:43.760 --> 18:44.520 Okay? 18:44.520 --> 18:47.420 So, the first type of connection, okay? 18:47.420 --> 18:57.560 We can configure, as I said, both servers or internal workstation with reverse connection to a BPS controlled by us. 18:57.560 --> 19:01.020 But we could have some different types of persistence. 19:01.020 --> 19:03.780 First of all, direct connection. 19:03.780 --> 19:12.980 It consists of a direct connection to the internet, which does not go through a proxy, for example. 19:13.180 --> 19:20.380 So, a computer with half direct connected to internet output. 19:20.380 --> 19:24.900 So, it is not common, but it can be found sometimes. 19:24.900 --> 19:29.440 The communication setup in this case would be trivial. 19:29.440 --> 19:54.400 And on the other hand, there are other options that allow direct access to the internet, such as, for example, the use of other protocols like DNS or other similar protocols that permit us to stabilize that reverse connection, but also this would require tunneling through this protocol. 19:54.900 --> 20:04.460 So, this is the first possibility, but normally this option is common by using of this other type of protocols like DNS. 20:04.460 --> 20:04.820 Okay? 20:04.820 --> 20:20.600 DNS connection to a domain or a server owned by the attacker and using that connection we could stabilize a reverse connection, but it's not the best case because it's useless. 20:20.600 --> 20:21.200 Okay? 20:21.200 --> 20:27.420 So, the next one is more common, the use of an open proxy. 20:27.900 --> 20:45.020 Normally, HTTP proxy, a use for development actions, which we will be able to find as the information is carried out or configured in the system, for example, development or preproduction system. 20:45.740 --> 21:03.380 And well, the use of this proxy is quite simple, since tools like SSH or Pellink, if we use Windows system, allow us to stabilize a proxy through which to pass the communication. 21:03.380 --> 21:10.100 So, keep in mind that reliability is less as they could be eliminated. 21:10.100 --> 21:14.920 Normally, this type of proxy are for preproduction environment. 21:14.920 --> 21:16.820 So, it's not the best case, too. 21:16.820 --> 21:24.940 And the most common, and normally the type of persistent, is this two next ones. 21:24.940 --> 21:32.340 And well, in both cases, basically, is where we detect internally a proxy with credential. 21:32.340 --> 21:47.980 It doesn't matter if it's only credential or if the computer, sorry, the proxy, authenticate with an TLM authentication or with the active directory. 21:47.980 --> 22:09.220 Well, in the event authentication is performed against the active directory, which is the most common case, it would be good to look for predictable credentials or users who do not expire the password, as we will see later. 22:09.220 --> 22:21.280 So, because if we detect, for example, in an intrusion, we cannot connect really to internet or we cannot detect an open proxy. 22:21.280 --> 22:28.420 Normally, we could detect a proxy with credential because it could be configured in the workstation of the people. 22:28.420 --> 22:37.740 So, once we detect that proxy, we could establish a reverse connection using that proxy with an SSS connection, for example. 22:37.740 --> 22:46.900 But, of course, we need to use some different type of tools, like, for example, CNTLM or GSM, for example. 22:47.640 --> 22:53.600 With that tools, we could use the proxy and tunneling the SSS connection. 22:53.660 --> 23:14.720 But, of course, we need to keep in mind that the company could have another security measures, like, for example, proxy, I mean, a filter in the proxy to outgoing connection and that type of thing that we will see in the next slide. 23:14.720 --> 23:22.560 So, okay, this is the fourth type of connection that we could create. 23:22.560 --> 23:31.460 But it's important to understand what the infrastructure that we need to carry out, okay? 23:31.460 --> 23:43.600 Because if we want to deploy a traditional persistence in a workstation on a server, it doesn't matter if it's a direct connection or a connection through a proxy with authentication. 23:43.600 --> 23:56.680 We could need three different type of infrastructure, from the easiest and to the more difficult infrastructure. 23:56.680 --> 24:02.760 The first one is basically if we, well, BPS with public IP. 24:02.980 --> 24:25.020 As I said, this is the simplest case where a BPS server with a public IP address is hired to receive the connection of the persistence, either direct or tunneling using other protocols, which allow the connection to the internal system to be established. 24:25.020 --> 24:30.220 So, the next possibility about the infrastructure is the domain fronting. 24:30.220 --> 24:46.360 This solution, well, in addition to hiring servers with public IP, will require buying different domains to which persistence will be pointed out. 24:46.360 --> 24:50.500 But more or less it's the same, but with one domain in front. 24:50.700 --> 24:57.700 And the last one, and maybe it's the hardest option, is the IP laundry. 24:58.380 --> 25:13.020 In this case, we have the possibility, in addition to the previous infrastructure or having different IP addresses, to which we can redirect depending on who visits the domain in question. 25:13.020 --> 25:16.760 Normally, in Red Team Access, we could use any of them. 25:16.760 --> 25:25.600 And, of course, it depends on the security measures of the company that normally need to be analyzed before we deploy persistence. 25:25.600 --> 25:38.380 So, to carry out the persistence, in addition to the connection, of course, it will be necessary for the connection to be executed periodically. 25:38.380 --> 25:44.960 For this, it will be possible to use, among others, the following techniques. 25:44.960 --> 25:53.780 We could use schedule tasks, new services, file modification, or account creation. 25:53.780 --> 26:11.820 One important question that I want to remark, in general, in the presentation, is that as less things you could modify in the company to deploy persistence, it's really, really, really better. 26:12.300 --> 26:22.620 Because it's easier, and at the same time, for the Blue Team, it's really more complicated to detect it. 26:23.520 --> 26:48.780 So, finally, a key aspect that I really want to remark is, first, this will... I mean, for example, different IPs, due to the persistence, and different BPS providers, it's really important because this will allow the identification of a persistent connection, 26:48.780 --> 26:52.100 not to identify others that are deployed. 26:52.100 --> 26:54.220 So, it's really important. 26:54.220 --> 27:02.060 The second one, different binaries, dates, path that we used, and sync. 27:02.220 --> 27:14.880 Because if a persistent has been detected, others cannot be found by simple search or resource, or directories. 27:14.880 --> 27:17.520 So, it's really important. 27:17.520 --> 27:22.520 The third, use of different outgoing proxy and internal servers. 27:22.520 --> 27:35.460 If we do that, for the Blue Team, it's really more complicated to detect the other persistence that we could use, we could have, but we don't use. 27:35.760 --> 27:45.600 And the last point is to try to use low-privilege user, and if it's possible, without key outdate to internal connection. 27:45.600 --> 27:55.820 If we need to use a proxy, normally with credential, of course we need to use user and credential. 27:56.040 --> 28:09.720 So, it's important to analyze the active directory and try to search that type of user that could access to internet using a proxy, but without a password expiration. 28:09.720 --> 28:21.480 It's really important, and in companies that have a high number of users, it's more or less common to find that type of users. 28:21.760 --> 28:32.080 But, as always, we need to put as more different as possible persistence. 28:32.080 --> 28:48.780 So , if we want to deploy persistence on an internal server and at the same time on a workstation, maybe we could configure the server to use an open proxy, for example, or a proxy with credential and use a normal user. 28:48.780 --> 29:06.940 And at the same time, we can use a workstation in another completely different network that uses other different proxies, with other different users, with all different credentials, as much different as we can. 29:06.940 --> 29:09.160 It's the perfect situation. 29:09.160 --> 29:17.660 So, this is a small brief, a small overview about how we can deploy persistence on an internal server or workstation. 29:17.660 --> 29:19.920 And we will continue with more type of persistence. 29:20.200 --> 29:23.080 The next one is public servers. 29:23.340 --> 29:32.640 And basically, this type of persistence will be deployed on those systems that are exposed directly on internet. 29:32.640 --> 29:47.980 Also, it is not so common, but it is a powerful vector, as it is rarely reviewed by the blue team when they detect an internal intrusion. 29:47.980 --> 30:10.060 So, this scenario consists of configure exposed systems on internet to allow access to the internal network or to carry out actions without having to establish a reverse connection, and using public resources directly. 30:10.060 --> 30:32.490 So, this persistence are usually deployed initially in the event that an access vector has been detected in a device located in the demilitarized zone, for example, which allows jumping to other visible machines or servers, or we already have privilege. 30:32.490 --> 30:58.310 So, if the infrastructure privilege has been achieved, it is possible to analyze the Active Directory and users who can access this type of environment, this type of servers, to deploy resources that we can take advantage of from outside the organization to continue interacting with internal servers. 30:58.310 --> 31:16.770 So, the good thing about this type of persistence is that the systems that are configured with persistence do not have any type of vulnerabilities, making it more difficult for the blue team to detect them. 31:16.770 --> 31:25.070 In my opinion, deploying persistence on web servers is really important. 31:25.270 --> 31:51.890 Normally, servers that we do not touch during the intrusion, but once we have good privilege in the organization, it's really interesting to deploy some traditional persistence on internal servers and workstations, but at the same time, take one or two computers in two different demilitarized zones and deploy different types of persistence, 31:51.890 --> 32:00.110 like, as we will see here, for example, WebShell, FileManager, or WebProxy. 32:00.110 --> 32:06.030 These are normally the main types of resources that we could deploy. 32:06.350 --> 32:18.250 WebShell, if we want to interact with the system, execute commands, perhaps the easiest to detect due to the need to call certain processes. 32:18.250 --> 32:27.270 The second one is the FileManager, which only allow the uploads of files, since it is not necessarily malicious code. 32:27.270 --> 32:29.470 It is really complex to detect. 32:29.470 --> 32:46.730 So, this could be a really awesome persistence, because we could deploy traditional persistence internally, but at the same time, take two different servers exposed on the internet, upload from the inside of the network, some different type of FileManager, 32:46.730 --> 33:06.330 and in the case that we need to use that persistence, use the FileManager, upload a WebProxy, for example, and with that, well, in the case of WebProxy is, without a doubt, the most powerful, since it allows using the system as a proxy through the use of PHP, 33:06.330 --> 33:09.950 ASP, ASPX, or a similar language. 33:09.950 --> 33:15.450 So, one of the most common, maybe, tools in this file is regearch. 33:15.650 --> 33:26.210 So, in my opinion, one of the best persistence to deploy in a demilitarized zone is to take some different servers and upload a FileManager. 33:26.210 --> 33:37.270 And when we need to use it, use the FileManager and upload a WebProxy or a WebShell, for example, to reenter again into the organization. 33:37.270 --> 34:00.690 So, in addition to a different type of persistence, it is important to know how to deploy them, since they could range from simply uploading a file to integrating this resource into other existing ones, and even multiple files, which would make their detection much more complex. 34:00.690 --> 34:01.810 Okay. 34:01.810 --> 34:13.330 So, here we have some possibilities, like, as I said, independent resource is like we take the FileManager and upload the FileManager to the server. 34:13.330 --> 34:20.630 The integration of resource is to take one existing resource and integrate the FileManager inside the resource. 34:20.630 --> 34:20.870 Okay. 34:20.870 --> 34:22.890 In my opinion, it's the best. 34:22.890 --> 34:27.870 And the last and, of course, more complex is the integration with multiple resources. 34:27.870 --> 34:40.750 In this case, we need to take some different resources internally and put, for example, the FileManager in parts in some different existing resources. 34:40.750 --> 34:41.110 Okay. 34:41.110 --> 34:42.270 Okay. 34:42.270 --> 34:51.790 And, well, as we see in the last part of the internal servers persistence, here we have some other key aspects. 34:51.790 --> 35:08.310 Well, for example, in one hand, use servers that are host in the different demilitarized zones, as I said, if they exist, of course, and deploy different resources on each server. 35:08.310 --> 35:09.310 Okay. 35:09.310 --> 35:20.510 Because if the blue team detects a persistent on a web server, and they try to find other web server with the same persistent, they don't find anything. 35:20.510 --> 35:20.790 Okay. 35:20.790 --> 35:22.690 So, that's really interesting. 35:22.690 --> 35:23.690 More. 35:23.690 --> 35:45.870 Make use of different names and routes or paths, as well as the origins of the connection to those different resources in such a way that it's not possible to identify a unique IP address that allow corresponding and correlating, sorry, different persistence with the same IP address. 35:45.870 --> 35:46.670 Okay. 35:46.670 --> 36:03.410 And, well, at the end, as I mentioned, use public server that do not necessarily have vulnerabilities, and deploying certain security measures in our resource that avoid the possibility of a third party to use them. 36:03.410 --> 36:03.570 Okay. 36:03.570 --> 36:15.570 For example, if we deploy regearch as a persistent, it is really important that the regearch is not public to the use of anyone. 36:15.570 --> 36:15.810 Okay. 36:15.810 --> 36:21.270 We need to put a password, IP filtering, or something like that. 36:21.270 --> 36:21.410 Okay. 36:21.410 --> 36:22.950 It's really important. 36:22.970 --> 36:23.690 Okay. 36:23.690 --> 36:38.590 So, the next possibility about deploy persistence, well, here we have another common possibility in which we are not going to develop much due to the amount of public information there is. 36:38.590 --> 37:03.470 So, in this case, deploy persistence in the active directory usually hints to aid in the development of internal persistence on servers previously seen, or generate new access to internal network from the internet, such as creating a user who has permission to access via VPN, 37:03.470 --> 37:04.810 for example. 37:04.810 --> 37:08.170 So, this is a simple example. 37:08.170 --> 37:08.610 Okay. 37:08.610 --> 37:28.090 The modification of an active directory could impact the possibility to access, for example, in the cloud of Azure if we have a distributed active directory, or the use of different type of corporate service like email or VPN. 37:28.090 --> 37:29.030 Okay. 37:29.030 --> 37:33.690 Well, in this case, it's a small difference. 37:33.690 --> 37:43.730 Here I have some examples of which, in my opinion, the most useful and least sticking is the first. 37:43.730 --> 37:53.150 The best option is to analyze the active directory to identify and to detect privileged or potential usable users. 37:53.150 --> 37:59.650 It's the best because we don't need to modify in any way the active directory. 37:59.650 --> 38:01.350 So, in my opinion, it's the best. 38:01.350 --> 38:10.590 As I say, in general, the less the infrastructure of an organization is modified to deploy persistence, it's better. 38:10.590 --> 38:10.810 Okay. 38:10.810 --> 38:16.690 Since we will have less possibilities of being detected, of being identified. 38:16.690 --> 38:17.450 Okay. 38:17.450 --> 38:24.150 At the same time, from this list, okay, as I said, the first one, for me, is perfect. 38:24.150 --> 38:28.730 And the second is the persistence in secondary internal domains. 38:28.730 --> 38:34.170 Maybe it could be the same organization or other secondary organization. 38:34.170 --> 38:41.850 Well, this could be affected because it's related to the same as I said. 38:41.850 --> 38:42.390 Okay. 38:42.390 --> 38:56.550 In my opinion, in this case, we need to analyze the active directory of this second company or second domain and try to find information that allow us to continue with intrusion in the case of there is any problem. 38:56.550 --> 39:17.250 But in my opinion, it's better than modification, for example, the active directory discretionary, access control list or access control entities, as well as the modification or the creation of ticket, like silver ticket or golden ticket or the creation of users. 39:17.250 --> 39:29.530 Because all of these are actions that are really aggressive and maybe cause the generation of some alerts and the possibility of detection of the blue team of the red team. 39:29.530 --> 39:30.210 Okay. 39:30.490 --> 39:40.890 And well, the last case refers to the possibility of deploying persistent in private clouds that the organization or the only providers may have. 39:40.890 --> 39:41.730 Okay. 39:41.730 --> 39:46.790 It is something that lately has been more carried out. 39:46.990 --> 40:02.510 But in the end, it is based on identifying providers that have some type of access with the internal network of the target organization and displaying persistent in them or deploy persistent in them. 40:02.510 --> 40:17.390 It is under the boldly useful since it is more complex for the organization to have detection and of course response capabilities in cloud environment or directly in provider networks. 40:17.390 --> 40:28.810 Okay, so we are not going to delve into it because in the end, it will be the same action as those already seen. 40:28.810 --> 40:33.970 Okay, normally the providers or company providers have internal infrastructure. 40:33.970 --> 40:47.930 So if we compromise directly a provider and use that provider to compromise into internal network, of course, we could deploy if we have permission, of course, persistent on that provider. 40:48.170 --> 40:51.390 But it's not the most common situation. 40:51.390 --> 40:54.550 And at the end, as I said, it's the same actions. 40:54.550 --> 41:17.250 Another important part is if we could access to a private cloud, for example, in Google Cloud Platform, Amazon, or Azure, for example, and that infrastructure have a direct access, for example, via VPN to internal organization, it is possible for us to try to deploy persistent on that environment. 41:17.250 --> 41:37.970 Because at the end, normally company have more security measures internally, but in other networks, it doesn't matter if it's a provider or it's a cloud or private cloud, it's more difficult for the Google team to deploy that type of security measure. 41:38.170 --> 41:39.470 And it's not common. 41:39.470 --> 41:42.130 Okay, so let's continue. 41:42.130 --> 41:45.210 And finally, we got to the part I want. 41:45.210 --> 42:02.350 Here we are going to see a couple of simple actions that can allow us to maintain persistence in organization by using a situation that would rarely be reviewed by a blue team during their response to an incident. 42:02.350 --> 42:26.250 Okay, we have to remember that when the blue team detects an incident, those first hours or days, they carried out the most basic actions, enough time for the attacker to find out, but certainly not enough for the blue team to detect the action that we will see here. 42:26.250 --> 42:37.870 So in many occasions, these techniques are extremely effective due to the ignorance of the way an attacker acts for the blue team. 42:37.870 --> 42:43.430 Okay, so the first one is the predictable credential. 42:43.430 --> 43:00.130 It is based on the possibility of an attacker to identify the history of keys that users have had, and to identify users with predictable patterns in the password. 43:00.130 --> 43:21.450 So, for example, if a user has been identified with passwords like May 2020, June 2020, July 2020, it will be certain that in a few months this user will have the password October 2020. 43:21.450 --> 43:31.490 Okay, and that's a perfect persistent because it's really rarely to think about it for the blue team. 43:31.490 --> 43:56.890 Okay, so in the case the user has the ability to access corporate services that do not have double-factor authentication, for example, VPN or Wi-Fi, it would be a perfect persistent, which could only be avoided if the blue team forced all the users to change their password. 43:56.890 --> 44:07.030 So, although it will be surely to be the next or the last month, because normally the user always follows the same pattern. 44:07.050 --> 44:19.210 So, there are very common password patterns that usually mix the company name, the location, month, and year, and maybe the name of the person. 44:19.210 --> 44:24.050 With that, we can create some patterns and try to search that patterns. 44:24.050 --> 44:26.790 So, what are the steps to do this? 44:26.990 --> 44:29.830 They are really, really, really simple. 44:29.830 --> 44:34.910 I mean, the first one is the extraction and the password history. 44:34.910 --> 44:39.910 It could be a selective extraction, and it depends on the goal, of course. 44:40.190 --> 44:49.610 Tracking that hashes, and normally using rules with Hascat or any other tool like that, and obtaining a clean password. 44:50.130 --> 45:00.690 The third point is to identify which user has a password with patterns with the last month, for example, August 2020 in this case. 45:01.570 --> 45:12.090 Verified corporate service and the type of interaction that they allow to understand what type of persistent we could deploy, for example, is completely different. 45:12.090 --> 45:24.190 If we could access to a mail, or if we could access to a VPN, VPN is direct access, but in mail, we need to use more things like the use of ruler or something like that. 45:24.190 --> 45:30.250 So, it's important to understand the possibilities for the intrusion of this service. 45:31.050 --> 45:40.750 And the last one, do not use them if not necessary, and never from a source that we have already used. 45:40.830 --> 45:45.790 So, this is one of my favorite alternative persistence. 45:45.790 --> 45:50.450 The next one is the Wi-Fi networks with connection. 45:50.450 --> 45:51.930 Really simple. 45:51.930 --> 45:57.290 Many times, the company have Wi-Fi with password. 45:57.290 --> 45:58.730 We try to detect that. 45:58.730 --> 46:11.510 So, this second scenario consists of identifying, during the intrusion, credentials to access to the organization Wi-Fi networks that are directly connected to the internet network. 46:11.510 --> 46:18.490 Of course, not BPA2 Enterprise, but normally BP2PST. 46:19.150 --> 46:22.070 And are common, normally, in the organization. 46:22.070 --> 46:34.690 Well, try to find from the inside, during the analysis of internal system, the workstation of the administrators, or the NAS servers. 46:34.690 --> 46:44.630 Try to find this information, the credentials of the networks, and, of course, detect if that network is directly connected. 46:44.630 --> 46:46.590 If it's connected, it's perfect. 46:46.590 --> 47:00.050 Because, in the case of losing access to the organization, it would be only necessary to access through said Wi-Fi network, and continue the intrusion to deploy more comfortable traditional persistence. 47:00.050 --> 47:11.390 If access to traditional persistence were lost, it would take a long time for the blue team to change, or to think about that, these keys. 47:11.390 --> 47:17.410 So, it would be practically impossible to prevent the attacker from continuing to enter. 47:17.410 --> 47:20.370 And here, the steps are really simple. 47:20.370 --> 47:38.410 The identification of Wi-Fi network, identification of users, position through the analysis, for example, the identification of systems connected to Wi-Fi and extraction of credentials, and finally, the verification of access to these Wi-Fi networks. 47:39.190 --> 47:41.150 The next one. 47:41.150 --> 47:44.150 Try to connect periodically to a Wi-Fi. 47:44.150 --> 47:47.410 This is quite a little bit strange. 47:47.410 --> 47:58.830 This third case will consist of identified systems, usually employee laptops, that are accessible through a Wi-Fi network generated by ATK. 47:58.830 --> 48:15.650 So, in this situation, and normally by analyzing the existing position in said location, it would be possible to configure the systems that every day, at a certain time, they try to connect to a Wi-Fi network. 48:15.650 --> 48:37.770 When the entity, well, when the blue team, when the entity team did so, we could already have a connection, being able to use internal servers, internal users, in this case, that we have, any user that has been created in the system, etc. 48:39.530 --> 48:50.150 Conversely, the other way around could be for the employee to raise, to meet an access point, but this is always something a little more complex. 48:50.150 --> 49:04.770 So, it's better to configure an internal system, and normally, as I said, an employee laptop of a concrete location, and configure that server to try to connect to a Wi-Fi that the ad group creates. 49:05.590 --> 49:09.710 Try it one time a day, for example, or one time a week. 49:09.710 --> 49:28.690 If we lose access to the organization, we lose the other type of persistent, it's simple, we only need to go to that location, create the Wi-Fi, the laptop connects to our Wi-Fi, and, in that case, we can directly interact with the server. 49:28.690 --> 49:36.830 We could create a trigger, for example, if it detects the Wi-Fi, create a local user, and we could use that user. 49:36.830 --> 49:49.610 So, here we can do many actions, but it's a really interesting approach, in my opinion, to really deploy persistence. 49:50.510 --> 49:59.430 And, well, this point is maybe a little bit more different, but, in my opinion, it could be interesting, too. 49:59.890 --> 50:17.920 We see some alternative persistence, but, at the same time, we can configure other type of persistence, more like the extraction of information that we could use to create another access vector, for example. 50:19.610 --> 50:21.550 The most important is the silence action. 50:21.550 --> 50:26.390 I don't have a lot of time, so I go more fast. 50:26.850 --> 50:29.010 First of all, silence action. 50:29.110 --> 50:37.810 The first one is the display of the GAL, global access list, to deploy a brute force attack. 50:37.810 --> 50:50.370 So, we can configure a server, internally, to each, I don't know, Monday, for example, send us the GAL with all the users, not the password, only the users. 50:50.370 --> 50:51.950 It's normal information. 50:51.950 --> 50:53.670 It doesn't matter, I mean. 50:53.670 --> 51:12.410 With that information, we can configure, for example, if we lose all the access, we can configure a brute force attack, trying to detect, with that entire list of users, if some of that users have a predictable password. 51:12.410 --> 51:21.010 If we detect that, we have a user we could use, or try to use, in Wi-Fi, VPN, email, and so on. 51:21.010 --> 51:23.430 More, email forwarding with keywords. 51:23.430 --> 51:25.130 This is really interesting. 51:25.130 --> 51:40.430 In many cases, the employees use Outlook, so we can configure the Outlook of some employees to forward some emails with specific keywords, for example, key, password, etc. 51:40.430 --> 51:47.230 And, the third one, is the uploading files to expose web servers, for example. 51:47.470 --> 52:10.410 Imagine that you can configure an internal system of an employee to try, each month, to put results on a web server, and you have a list of web servers, you can configure the laptop to try, each month, to use that list, and, each month, you deploy some different web server. 52:10.430 --> 52:18.630 It's like a computer, internally, but that computer is deploying persistence without any type of interaction. 52:18.630 --> 52:27.270 You have the list, so you only need to go to that web servers, and use, without any kind of problem. 52:27.270 --> 52:29.090 It's really, really interesting. 52:29.090 --> 52:34.530 And, here, we have more aggressive action, but I don't explain in detail, for example. 52:34.530 --> 52:40.530 Credential extraction and forwarding is like the first of silent action, but, of course, more aggressive. 52:40.530 --> 52:47.650 We can try to, well, extract credential and send it out. 52:47.650 --> 52:56.750 More, the modification of files, of office files, in repositories, in NAS, for example, and put malicious macros. 52:56.770 --> 53:03.290 We can create triggers, and, well, it's the same as web servers, as said. 53:03.290 --> 53:18.570 The third one, the deployment of .scf files, that allow us to obtain, maybe, keys or hashes for the employees. 53:18.570 --> 53:23.690 And, the last one, the modification of .lnkey files. 53:23.690 --> 53:34.550 But, of course, all this action could be programmed or used with vectors like one previously exposed, but this is only, the imagination is the limit, here, okay? 53:34.570 --> 53:37.630 So, the last part, because I don't have enough time. 53:37.730 --> 53:39.470 Do you think you catch me? 53:39.490 --> 53:40.610 This is the question. 53:40.610 --> 53:48.730 As it has been seen, we have shown only some examples, but the limit, as I said, is imagination. 53:48.730 --> 53:54.830 Especially for these alternative vectors to create persistent organization. 53:55.250 --> 54:09.810 And, with all of this, do you think, I mean, it is really possible for a blue team to identify all the access paths or the persistence of an attacker? 54:10.610 --> 54:19.790 Of course, in my opinion, keep in mind that it's not necessary to display all the type of persistence seen. 54:19.970 --> 54:32.370 But, also, it's important to know that you not only need to deploy enough to guarantee access to your organization, as we said before, it's completely different if we have one week or one month, okay? 54:32.370 --> 54:35.890 We need to deploy persistence with mind. 54:35.890 --> 54:37.310 Okay. 54:37.370 --> 54:40.690 So, here is, like, the aspect of blue team. 54:40.690 --> 54:55.290 But the truth is that, as we will see, and as we have said before, the blue team normally has to give a first response to an incident that is necessarily insufficient. 54:55.290 --> 55:03.810 This can always allow the attacker to detect the drop in persistence and, therefore, time to access and configure others. 55:03.950 --> 55:05.010 It doesn't matter. 55:05.010 --> 55:19.810 We have the blue team, and the blue team could detect an attack, but it's really, really, really difficult for a blue team being able to detect all the different persistence if we follow the next guidelines, okay? 55:19.810 --> 55:24.430 Really, really, really simple guidelines, but, at the same time, really effective. 55:25.290 --> 55:28.490 So, the first one is to keep the data of persistence active in an organization. 55:28.650 --> 55:31.150 Restrict the use of public assets. 55:31.150 --> 55:35.470 Of course, if we put persistence on a web server, it's important to protect it. 55:35.910 --> 55:38.470 Monitoring every persistence. 55:38.750 --> 55:40.530 Detection and action. 55:40.530 --> 55:47.510 If we detect that a persistence drops, it's important to use another persistence. 55:47.690 --> 55:53.670 Go into the organization, inside the network, and try to put some other different persistence. 55:53.670 --> 55:56.370 To maintain access continuously, okay? 55:56.370 --> 55:59.170 So, redeploy in case of loss. 55:59.230 --> 56:02.730 More, avoid internal notification every time. 56:02.730 --> 56:06.050 It's one of the most important aspects of doing a red team exercise. 56:06.050 --> 56:08.310 Try to avoid internal notification. 56:08.310 --> 56:10.530 Different destinations. 56:10.530 --> 56:19.130 I mean, you need to put in the configuration of each persistence, connect to a different server. 56:19.130 --> 56:33.550 Using that, if the blue team detects one persistence, analyzes the system, they cannot correlate with other persistence, always if the IP where we connect it is different. 56:33.550 --> 56:35.970 At the same time, different internal location. 56:36.030 --> 56:40.670 Don't try to configure every persistence in the same network. 56:40.670 --> 56:45.650 Use different networks, different type of computers, different paths, different binaries. 56:45.650 --> 56:48.050 Every different as you can, okay? 56:48.050 --> 56:50.130 Date and resource change. 56:50.130 --> 57:05.990 Normally, if you, for example, in the persistence, if you want to persist in a web server and you upload a regearch, it's important to change, for example, the date of the regearch to be the same or less as in the same resource in the same path, okay? 57:05.990 --> 57:07.050 It's important. 57:07.050 --> 57:08.590 And this is the next one. 57:08.590 --> 57:10.950 Camouflage on existing resource. 57:10.950 --> 57:17.310 As we said, one possibility is not only to upload persistence. 57:17.310 --> 57:19.930 It doesn't matter if it's a regearch or it's a web shell. 57:19.930 --> 57:21.110 It doesn't matter. 57:21.230 --> 57:29.790 You could upload directly, but you can't camouflage that resource integrating in another existing resource, and it's really important. 57:29.790 --> 57:34.790 And the last two is do not relate or interact between persistence. 57:34.790 --> 57:40.950 It's really important if you want to avoid the detection of your persistence internally, okay? 57:40.950 --> 57:42.750 Persistent infrastructure. 57:43.150 --> 57:46.410 And the last one is really, really important. 57:46.410 --> 57:50.650 Maintain persistence as a backup, always. 58:05.750 --> 58:10.030 It's important to have really different type of persistence. 58:10.030 --> 58:14.450 But at the same time, maintain that persistence as a backup. 58:14.450 --> 58:17.290 You only use the access vector. 58:17.290 --> 58:21.330 If the access vector detects, you need to use one persistence. 58:21.330 --> 58:24.150 But keep the others as a backup, okay? 58:24.150 --> 58:25.770 It's really important. 58:25.770 --> 58:30.490 So, the same structure as we see. 58:30.490 --> 58:33.230 How can you really catch me? 58:33.230 --> 58:39.490 If you do that, it's practically impossible for the blue team to detect, okay? 58:39.490 --> 58:49.710 If we deploy persistence following the guidelines, with different user and locations internally, with different origins and different suppliers, okay? 58:49.710 --> 59:09.470 Programming them differently and using different techniques, and also a different time to avoid locks and possible correlation, would the blue team really be able to detect all of them and kick us before we could access and continue to deploy more persistence? 59:09.490 --> 59:14.350 In my opinion and experience, no, it's impossible, okay? 59:14.350 --> 59:22.130 If we deploy persistence on servers and internally, well, it is like an ITRA, okay? 59:23.310 --> 59:26.530 It's like this, a symbol of ITRA. 59:26.530 --> 59:35.890 When the blue team could off ahead, we only have to reenter and deploy two more to continue guaranteeing access. 59:35.890 --> 59:41.830 And for the blue team, it's impossible to go faster than that, than us, okay? 59:41.830 --> 59:43.870 That's it. 59:44.070 --> 59:50.590 I commend that soon I will publish a tool that helps in the development of all this type of persistence. 59:51.090 --> 59:52.310 And that's all. 59:52.310 --> 59:54.430 Thank you all of you. 59:54.430 --> 59:59.850 I hope you like it and enjoy the remaining talks of the conference. 59:59.850 --> 01:00:04.450 And of course, thanks to the organization for the opportunity, okay? 01:00:04.450 --> 01:00:05.710 And that's all. 01:00:05.710 --> 01:00:06.510 See you soon. 01:00:06.510 --> 01:00:07.030 Bye.