[00:00.000 --> 00:13.300]  Hello, everyone, and thank you to be here. 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:27.820]  Okay, about me, a really simple overview about who am I. I'm Eduardo Aviles. 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:22.920]  More about me, well, for more than eight years, I've been dedicated on the world of cybersecurity and currently on hacking. 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:44.340]  And internationally. 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 --> 03:00.420]  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. And mainly, how to do it.
[03:00.420 --> 03:15.400]  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. 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:57.960]  Table of contents. 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:24.160]  If we do the things okay, it is really difficult for the blue team to detect us. So we will see mainly four parts. 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:41.900]  The second point is about traditional persistence. I mean, the persistence in a traditional way or traditional approach. Like, how can we deploy persistence on the internal servers, workstation, and so on.
[04:41.900 --> 05:08.920]  Okay, so this point is a basic overview of the main techniques that we could use as an actor inside the company. 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:28.880]  And not only basic, but at the same time really difficult to detect for the blue team. 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:45.720]  So let's start with the first point about the introduction. 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 --> 06:10.640]  This is more or less. This part corresponds, as we will see later, with the possible infrastructure that is necessary for an actor. I don't know if you see the mouse is here. So this part is basically the infrastructure of an actor. But all of them is about the infrastructure of the company.
[06:10.640 --> 06:38.940]  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. Inside the network, we can see a network. Normally, we have so many networks, not only one network, because the company normally is segmented in different networks and that type of thing. But, well, this is a real simple overview.
[06:38.940 --> 07:02.940]  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. This type of servers could be proxies to access to the Internet.
[07:02.940 --> 07:32.920]  Here we can have another similar infrastructure, and I think, because of my experience, it's really common. 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:57.340]  But in different locations. 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. 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:42.790]  This is a really simple overview. 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. This is only a simple overview to understand the different type of persistence that we will see later in the presentation.
[08:42.790 --> 09:12.230]  So, the first concept is about what is persistence. And in my opinion, it's really simple. 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:29.980]  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. It is simple. Game over.
[09:29.980 --> 09:51.200]  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. Because normally, this type of exercise could extend many months in time.
[09:51.200 --> 10:11.960]  So, let's see what difference could there be in the previous scenario if we deployed persistence. We see this scenario, simple, bad company. 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:51.840]  And we can configure persistence, for example, in providers, in workstations, in internal servers, or in an additional infrastructure in other locations, for example. One important question that we will see later, too, is that persistence is a backup.
[10:51.840 --> 11:19.500]  Normally, the red team uses the access vector, or one persistence. But, the other type of persistence normally, or should always be, a backup. 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:31.580]  But, always without making use of others and, therefore, guarantee their future use. 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 --> 12:20.860]  So, this is only an example, but we could deploy more and more and more and more persistence. 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:37.160]  And this is the question. If we configure currently that type of persistence, we could be sure that always where we can access, we could access. Okay? It is really important.
[12:37.160 --> 12:59.300]  So, more basic concepts, really simple. Why? Well, why? Maybe it's a really, really simple question. 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:13.240]  Okay. 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:30.600]  Okay. The next concept. Simple what? Where? The simplest answer is as everywhere as you can. Typically, many teams focus on deploy persistence only on internal systems or internal servers.
[13:30.600 --> 13:54.420]  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. Okay? So, we will have to deploy persistence in different locations, as we will see. The military zone, internal server, internal workstation, internal domains, and so on.
[13:54.420 --> 14:21.720]  But always, depending on the needs and remaining time of the exercise. 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. For example, if we have only one week, maybe we don't want to spend that week deploying persistence.
[14:21.720 --> 14:34.000]  Okay? But if we have more time, it is important to deploy some different type of persistence. Okay? And guarantee that access for a long term.
[14:34.000 --> 14:52.200]  And the last one is when. When we need to deploy that persistence. And here again, the answer is as soon as we can do it. Okay? It is always good to deploy persistence at different points.
[14:52.200 --> 15:15.520]  And, well, it will always be a good idea to spend time deploying persistence as intrusion progress. Okay? And not just waiting for access to the internal networks or domain administration privilege. Because if we wait, maybe we could lose access. Okay?
[15:15.520 --> 15:34.260]  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. Okay? But we will see here this point.
[15:45.520 --> 16:12.960]  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. Okay?
[16:12.960 --> 16:27.900]  In no case substitute for the use of some types of traditional persistence. Okay? It is important to have both or maybe traditional. It is, of course, important.
[16:27.900 --> 16:48.600]  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. Okay?
[16:48.600 --> 17:10.100]  So, let's start. With internal servers, both servers and workstations. Okay. Note that the possibility of deploying persistence on both servers and workstations is important. Okay? We need to deploy it on both types of servers because they are completely different.
[17:10.100 --> 17:26.600]  Servers tend to have higher availability, but it's less common that they have internet access in many cases. So, we can configure it, but we need to modify it. In some cases, this is not the best situation.
[17:26.600 --> 17:53.840]  On the other hand, we use workstations. They usually have configured internet access, and also, they also usually have security measures. 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:16.120]  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. Okay? The left part of the scheme.
[18:16.120 --> 18:44.520]  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. But in any cases, in both systems, it is possible to define the same types of connection which could be devised into the following. Okay?
[18:44.520 --> 19:01.020]  So, the first type of connection, okay? We can configure, as I said, both servers or internal workstation with reverse connection to a BPS controlled by us. But we could have some different types of persistence.
[19:01.020 --> 19:24.900]  First of all, direct connection. It consists of a direct connection to the internet, which does not go through a proxy, for example. So, a computer with half direct connected to internet output. So, it is not common, but it can be found sometimes.
[19:24.900 --> 19:54.400]  The communication setup in this case would be trivial. 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:21.200]  So, this is the first possibility, but normally this option is common by using of this other type of protocols like DNS. Okay? 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. Okay?
[20:21.200 --> 20:45.020]  So, the next one is more common, the use of an open proxy. 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:14.920]  So, keep in mind that reliability is less as they could be eliminated. Normally, this type of proxy are for preproduction environment.
[21:14.920 --> 21:24.940]  So, it's not the best case, too. And the most common, and normally the type of persistent, is this two next ones.
[21:24.940 --> 21:47.980]  And well, in both cases, basically, is where we detect internally a proxy with credential. 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:28.420]  So, because if we detect, for example, in an intrusion, we cannot connect really to internet or we cannot detect an open proxy. Normally, we could detect a proxy with credential because it could be configured in the workstation of the people.
[22:28.420 --> 22:46.900]  So, once we detect that proxy, we could establish a reverse connection using that proxy with an SSS connection, for example. But, of course, we need to use some different type of tools, like, for example, CNTLM or GSM, for example.
[22:47.640 --> 23:14.720]  With that tools, we could use the proxy and tunneling the SSS connection. 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:31.460]  So, okay, this is the fourth type of connection that we could create. 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:25.020]  The first one is basically if we, well, BPS with public IP. 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:46.360]  So, the next possibility about the infrastructure is the domain fronting. 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 --> 25:13.020]  But more or less it's the same, but with one domain in front. And the last one, and maybe it's the hardest option, is the IP laundry. 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:25.600]  Normally, in Red Team Access, we could use any of them. 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:53.780]  So, to carry out the persistence, in addition to the connection, of course, it will be necessary for the connection to be executed periodically. For this, it will be possible to use, among others, the following techniques. 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:52.100]  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, 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:41.230]  In my opinion, deploying persistence on web servers is really important. 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,
[31:41.230 --> 32:00.110]  but at the same time, take one or two computers in two different demilitarized zones and deploy different types of persistence, like, as we will see here, for example, WebShell, FileManager, or WebProxy.
[32:00.110 --> 32:18.250]  These are normally the main types of resources that we could deploy. 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:46.730]  The second one is the FileManager, which only allow the uploads of files, since it is not necessarily malicious code. It is really complex to detect. 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:09.950]  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, ASP, ASPX, or a similar language.
[33:09.950 --> 33:37.270]  So, one of the most common, maybe, tools in this file is regearch. 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. 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:22.890]  Okay. 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. The integration of resource is to take one existing resource and integrate the FileManager inside the resource. Okay. In my opinion, it's the best.
[34:22.890 --> 34:41.110]  And the last and, of course, more complex is the integration with multiple resources. In this case, we need to take some different resources internally and put, for example, the FileManager in parts in some different existing resources. Okay.
[34:41.110 --> 35:09.310]  Okay. And, well, as we see in the last part of the internal servers persistence, here we have some other key aspects. 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. Okay.
[35:09.310 --> 35:22.690]  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. Okay. So, that's really interesting.
[35:22.690 --> 35:46.670]  More. 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. Okay.
[35:46.670 --> 36:15.810]  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. Okay. For example, if we deploy regearch as a persistent, it is really important that the regearch is not public to the use of anyone. Okay.
[36:15.810 --> 36:38.590]  We need to put a password, IP filtering, or something like that. Okay. It's really important. Okay. 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:04.810]  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, for example.
[37:04.810 --> 37:29.030]  So, this is a simple example. Okay. 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. Okay.
[37:29.030 --> 37:53.150]  Well, in this case, it's a small difference. Here I have some examples of which, in my opinion, the most useful and least sticking is the first. The best option is to analyze the active directory to identify and to detect privileged or potential usable users.
[37:53.150 --> 38:17.450]  It's the best because we don't need to modify in any way the active directory. So, in my opinion, it's the best. As I say, in general, the less the infrastructure of an organization is modified to deploy persistence, it's better. Okay. Since we will have less possibilities of being detected, of being identified. Okay.
[38:17.450 --> 38:34.170]  At the same time, from this list, okay, as I said, the first one, for me, is perfect. And the second is the persistence in secondary internal domains. Maybe it could be the same organization or other secondary organization.
[38:34.170 --> 38:56.550]  Well, this could be affected because it's related to the same as I said. Okay. 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:41.730]  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. Okay. And well, the last case refers to the possibility of deploying persistent in private clouds that the organization or the only providers may have. Okay.
[39:41.730 --> 40:02.510]  It is something that lately has been more carried out. 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:28.810]  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. 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:54.550]  Okay, normally the providers or company providers have internal infrastructure. 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. But it's not the most common situation. 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:39.470]  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. And it's not common.
[41:39.470 --> 42:02.350]  Okay, so let's continue. And finally, we got to the part I want. 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 --> 43:00.130]  Okay, so the first one is the predictable credential. 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:34.910]  So, what are the steps to do this? They are really, really, really simple. I mean, the first one is the extraction and the password history.
[44:34.910 --> 44:49.610]  It could be a selective extraction, and it depends on the goal, of course. 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:58.730]  The next one is the Wi-Fi networks with connection. Really simple. Many times, the company have Wi-Fi with password. 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:34.690]  And are common, normally, in the organization. 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 --> 47:00.050]  If it's connected, it's perfect. 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:17.410]  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. So, it would be practically impossible to prevent the attacker from continuing to enter.
[47:17.410 --> 47:38.410]  And here, the steps are really simple. 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:58.830]  The next one. Try to connect periodically to a Wi-Fi. This is quite a little bit strange. 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 --> 49:04.770]  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. 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:28.690]  Try it one time a day, for example, or one time a week. 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:49.610]  We could create a trigger, for example, if it detects the Wi-Fi, create a local user, and we could use that user. So, here we can do many actions, but it's a really interesting approach, in my opinion, to really deploy persistence.
[49:50.510 --> 50:17.920]  And, well, this point is maybe a little bit more different, but, in my opinion, it could be interesting, too. 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:37.810]  The most important is the silence action. I don't have a lot of time, so I go more fast. First of all, silence action. The first one is the display of the GAL, global access list, to deploy a brute force attack.
[50:37.810 --> 50:53.670]  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. It's normal information. 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:40.430]  If we detect that, we have a user we could use, or try to use, in Wi-Fi, VPN, email, and so on. More, email forwarding with keywords. This is really interesting. 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 --> 52:10.410]  And, the third one, is the uploading files to expose web servers, for example. 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:29.090]  It's like a computer, internally, but that computer is deploying persistence without any type of interaction. You have the list, so you only need to go to that web servers, and use, without any kind of problem. It's really, really interesting.
[52:29.090 --> 52:47.650]  And, here, we have more aggressive action, but I don't explain in detail, for example. Credential extraction and forwarding is like the first of silent action, but, of course, more aggressive. We can try to, well, extract credential and send it out.
[52:47.650 --> 53:03.290]  More, the modification of files, of office files, in repositories, in NAS, for example, and put malicious macros. We can create triggers, and, well, it's the same as web servers, as said.
[53:03.290 --> 53:23.690]  The third one, the deployment of .scf files, that allow us to obtain, maybe, keys or hashes for the employees. And, the last one, the modification of .lnkey files.
[53:23.690 --> 53:40.610]  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? So, the last part, because I don't have enough time. Do you think you catch me? This is the question.
[53:40.610 --> 54:09.810]  As it has been seen, we have shown only some examples, but the limit, as I said, is imagination. Especially for these alternative vectors to create persistent organization. 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:35.890]  Of course, in my opinion, keep in mind that it's not necessary to display all the type of persistence seen. 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? We need to deploy persistence with mind.
[54:35.890 --> 54:55.290]  Okay. So, here is, like, the aspect of blue team. 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:24.430]  This can always allow the attacker to detect the drop in persistence and, therefore, time to access and configure others. It doesn't matter. 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? Really, really, really simple guidelines, but, at the same time, really effective.
[55:25.290 --> 55:53.670]  So, the first one is to keep the data of persistence active in an organization. Restrict the use of public assets. Of course, if we put persistence on a web server, it's important to protect it. Monitoring every persistence. Detection and action. If we detect that a persistence drops, it's important to use another persistence. Go into the organization, inside the network, and try to put some other different persistence.
[55:53.670 --> 56:08.310]  To maintain access continuously, okay? So, redeploy in case of loss. More, avoid internal notification every time. It's one of the most important aspects of doing a red team exercise. Try to avoid internal notification.
[56:08.310 --> 56:33.550]  Different destinations. I mean, you need to put in the configuration of each persistence, connect to a different server. 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:48.050]  At the same time, different internal location. Don't try to configure every persistence in the same network. Use different networks, different type of computers, different paths, different binaries. Every different as you can, okay?
[56:48.050 --> 57:07.050]  Date and resource change. 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? It's important.
[57:07.050 --> 57:29.790]  And this is the next one. Camouflage on existing resource. As we said, one possibility is not only to upload persistence. It doesn't matter if it's a regearch or it's a web shell. It doesn't matter. 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:50.650]  And the last two is do not relate or interact between persistence. It's really important if you want to avoid the detection of your persistence internally, okay? Persistent infrastructure. And the last one is really, really important. Maintain persistence as a backup, always.
[58:05.750 --> 58:25.770]  It's important to have really different type of persistence. But at the same time, maintain that persistence as a backup. You only use the access vector. If the access vector detects, you need to use one persistence. But keep the others as a backup, okay? It's really important.
[58:25.770 --> 58:39.490]  So, the same structure as we see. How can you really catch me? If you do that, it's practically impossible for the blue team to detect, okay?
[58:39.490 --> 59:09.470]  If we deploy persistence following the guidelines, with different user and locations internally, with different origins and different suppliers, okay? 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:26.530]  In my opinion and experience, no, it's impossible, okay? If we deploy persistence on servers and internally, well, it is like an ITRA, okay? It's like this, a symbol of ITRA.
[59:26.530 --> 59:41.830]  When the blue team could off ahead, we only have to reenter and deploy two more to continue guaranteeing access. And for the blue team, it's impossible to go faster than that, than us, okay?
[59:41.830 --> 01:00:07.030]  That's it. I commend that soon I will publish a tool that helps in the development of all this type of persistence. And that's all. Thank you all of you. I hope you like it and enjoy the remaining talks of the conference. And of course, thanks to the organization for the opportunity, okay? And that's all. See you soon. Bye.