 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. 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 and online modality. So 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, okay, a real intrusion or a simulation like a red team exercise. But it's true that I'm not going to focus on each technique, on the technical part, because well, many of the techniques are simple and well, have been exposed several times in public documents and presentation like this, okay? So let's start with the presentation and see how we can organize our infrastructure. Okay, about me, really simple overview. About who am I? I'm Eduardo Arviolos and the co-founder of the cybersecurity startup here in Spain, call it Rootpointer, where we are working on the development of different products that helps organizations to improve and be reactive against target attacks. At the same time, I work at different universities here in Spain and well, mainly in the Utah University. More about me, well, for more than eight years, I've been dedicated on the world of cybersecurity and countryly on hacking and the 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 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, okay? And because of that, I have seen very similar actions between companies and one of them is the lack of privilege on how to act when they detect an attacker, okay? And mainly how to do it. 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, okay? If an attacker has managed and 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 be here. I will see here in this presentation, okay? So, okay, perfect. 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 a pure reality for me of an intuition when an infrastructure of persistence exists well-deployed, okay? If we do the things okay, it's really difficult for the blue team and 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 persistent, why we need to deploy it, where, when and so on. The second point is about traditional persistence. I mean, the persistent in a traditional way or traditional approach, you know? Like how can we deploy persistent on the internal servers, workstation and so on, okay? So this point is a basic overview of the main techniques that we could use as an attacker 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 attacker to maintain persistence on the organization, okay? And not only basic, but at the same time it's really difficult to detect for the blue team, okay? And the last point is the conclusion about if you really think the blue team can catch us, okay, during an intuition. 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. This is more or less, okay? This part corresponds, as we will see later, with the possible infrastructure that is necessary for an attacker, okay? I don't know if you see the yeah, the mouse is here. So this part is basically the infrastructure of an attacker, okay? But all of them is about the infrastructure of the company. Here we can see, for example, the military system with some servers like web application, email servers, or other corporate servers like, for example, VPN. Inside the network, we can see a network, okay? Normally we have so many networks, not only one network, because the company normally segments in different networks and that type of things, but well, this is a real simple overview. 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, okay? Because it's normally a divide into a different network. This type of servers could be proxies to access to the internet, okay? 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 many many locations, it's common that they have a small infrastructure, but at the same time with other domain or sub-domain, domain controller, internal servers, workstation, and all the same infrastructure, but in different locations. And at the same time in this small and simple structure of a company, we could say some, we could see some different providers, like Google Cloud Platforms, Amazon, or Azure. Typical providers where the company could deploy private cloud, okay? And the last part here, this icon of the building represents a provider and more traditional provider of the organization, okay? Because it's possible that this provider and the cloud platforms, too, could have access internally to the network, okay? For some different things that we will see later. Okay, this is a really simple overview, okay? 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 persistent that we will see later in the presentation. So, the first concept is about what is persistence? And in my opinion, it's really simple. Persistence refers to the concept of maintain access to the organization for a long period of time, guarantee the possibility of accessing the entity through additional ways. And without the use of access vector detected initially during the red team exercise. Okay, 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's a simple game over, okay? 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, okay? Because normally, this type of exercise could extend many months in time, okay? So, let's see what different could there be in the previous scenario if we deployed persistence, okay? We see this scenario, simple, bad company, okay? But at the same time, we could say, we could see this all the way, but with no things. 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. And we can configure persistence, for example, in providers, in workstations, in internal servers, or in an additional infrastructure in other locations, for example, okay? One important question that we will see later too is that persistence is a backup, okay? Normally, the red team use the access vector, okay? Or one persistent. But the other type of persistence normally or should always be a backup, okay? 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, but always without making use of others. And therefore, guarantee their future use, okay? It is really, really, really important. And of course, as we will see, we could use another type of persistence more like incoming, okay? Where the red team really connected to some computers or some other type of access, like for example, Wi-Fi access to access to the organization, okay? So this is only an example, but we could deploy more and more and more and more persistence, okay? As we will see, we could use internal server 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. And this is a 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. 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 term, a long period of time as a real attacker could do because normally we need to simulate a real attacker, 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 intuition at any time, 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. But in my opinion, it is a mistake. Science, 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 system, internal server, internal workstation, internal domains and so on. But always depending on the needs and remaining time of the exercise. If intuition has been achieved, for example, and there is a weak left, the persistence will not be the same as if there is a month left, for example, okay? If we have only one week, maybe we don't want to spend that week deploying persistence, 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. And the last one is when? When we need to deploy that persistence? And here again, the answer as soon as we can do it, okay? It is always good to deploy persistent at different points. And well, it will always be a good idea to spend time deploying persistence as the 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? 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 at this point. So, now let's see a brief summary about the most common persistent methods that are used by many red teams. An important aspect to remark is that these techniques are practically used in any extra sense and can be performed in many more ways than those show below, okay? And on the other hand, the alternative techniques that will be shown later in the next point are intended to be complementary and in no case a substitute for the use of some types of traditional persistence, okay? It's important to have both or maybe traditional, it's of course important. 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 this could give for many talk, okay? So, let's start with internal servers, both servers and workstations, okay? And note that the possibility of deploying persistent both servers and workstation is important, okay? We need to deploy it on both type of servers because they are completely different. 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 and in some cases, this is not the best situation. On the other hand, we use workstation and they usually have configured internet access and also they also usually have security masters and 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 servers. So, normally to gain persistence on an internal system, our route connection is usually established against a system owner or a server owner, a VPS, for example, owned by an attacker, okay? The left part of the schema. So, it is really simple because normally it's like setting a reverse SSH tunnel to map different ports of the internal machine, okay, where we deploy persistent, 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? So, the first type of connection, okay, we can configure, as I said, both servers or internal workstation with reverse connection to a VPS controlled by us, but we could have some different type of persistence. 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. 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 establish that reverse connection, but also this would require tunneling through this protocol, okay? So, this is the first possibility, but normally this option is common by using of these 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 establish a reverse connection, but it's not the best case because it's useless, okay? So, the next one is more common, the use of an open proxy. Normally, HTTP proxy, a use for developing actions which we will be able to find as the information tructions get out or configure in the system, for example, development or pre-production system. Well, the use of this proxy is quite simple, since tools like SSH or Pelling, if we use Windows system, allow us to establish a proxy through which to pass the communication. So, keep in mind that probability is less as they could be eliminated. Normally, this type of proxy are for pre-production environments, so it's not the best case too. And the most common and normally the type of persistent is this two next one. 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. Well, individual authentication is performed against the active directory, which is the most common case. And it would be good to look for predictable credential or use or users who do not expire the password as we will see later. 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. 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 CHISA, for example. 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. Okay? 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? Because if we want to deploy a traditional persistence on a workstation, on a server, it doesn't matter if it's a dual connection or a connection through a proxy with authentication, we could need three different types of infrastructure from the easiest and to the more difficult infrastructure. 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 higher to receive the connection, okay, of the persistence, either direct or tunneling using other protocols, which allow the connection to the internal system to be established. 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, okay? 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 visit the domain in question, okay? Normally in Red Team Accesses, we could use any of them, and of course, depends on the security measures of the company that normally need to be analyzed, well, before we deploy persistence. 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, okay? We could use schedule tasks, new services, file modification, or account creation, okay? 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 is really, really, really better, okay? Because we, I mean, it's easier, okay? And at the same time, for the Blue Team, it's really more complicated to detect it. So, finally, some 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. So, it's really important. The second one, different, different binaries, dates, path that we used and think, okay? Because if a persistent has been detected, others cannot be found by simple search or research of, or directories, okay? So, it's really important. The third, use of different outgoing proxy and internal servers. 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, okay? And the last point is to try to use low privilege user and if it's possible without key outdated to internal connection, okay? If we need to use a proxy, normally we're with credential, of course, we need to use user and credential. So, it's important to analyze the active directory and try to search and that type of user that could access the internet using a proxy, but without a password expiration, okay? 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, okay? But, as always, we need to put as more different as possible persistence. So, if we want to deploy persistent 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. And at the same time, we can use a workstation in other completely different network that use other different proxy with other different user with all different credentials, okay? As much different as we can, okay? It's the perfect situation. So, this is a small brief, a small overview about how can deploy a persistent internal server or a workstation. Let's continue with more type of persistence. The next one is public server and basically, this type of persistence will be deployed on those systems that are exposed directly on internet. Also, it is not so common, but it is a powerful vector as it is rarely reviewed by the blue team when they detects an internal intrusion, okay? 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, okay? And using public resource directly. So, these persistence are usually deployed initially in the event that an access vector has been detected in a device located in the demonstration zone, for example, which allows jumping to other visible machines or servers, or we already have privilege. So, if the infrastructure pull 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 resource that we can take advantage of from outside the organization to continue interacting with internal servers. 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, okay? In my opinion, deployed persistence on web servers is really important, okay? And normally, servers that we do not touch during the intrusion, okay? But once we have good privilege on your initiation, it's really interesting to deploy some traditional persistence on an internal servers and workstation, but at the same time, take one or two computers in two different than the electricity zone and deploy different types of persistence, like as we will see here, for example, a web shell, file manager, or web proxy, okay? These are normally the main type of resource that we could deploy, okay? Web shell, if we want to interact with the system, okay? Execute commands, perhaps the easiest to detect due to the need to call a certain process. The second one is the file manager, which only allows the uploads of files. Science, it is not Nazismalicious 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, expose an internet, upload from the inside of the network, some different type of file manager, and in the case that we need to use that persistence, use the file manager, upload a web proxy, for example, and with that, well, in the case of web proxy is without a doubt the most powerful since it allows using the system as a proxy, throw the use of PHP, ASP, ASPX, or similar language. So, one of the most common, maybe, tools in this file is ReGeorge, okay? So, in my opinion, one of the best persistence to deploy in a demo-resistant zone is to take some different servers and upload a file manager, and when we need to use it, use the file manager and upload a web proxy or a web cell, for example, to re-enter again into the organization. So, in addition to the 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. Okay, so, here we have some possibilities, like, as I said, independent resource is, like, we take the file manager and upload the file manager to the server. The integration of resource is to take one existing resource and integrate the file manager inside the resource. Okay, my opinion is the best. And the last, and of course, more complex, is the integration with multiple resources. In this case, we need to put, sorry, we need to take some different resources internally and put, for example, the file manager in parts in some different existing resources, okay? Okay, and, well, as we see in the last part of the internal server persistence, here we have some other key aspects. And, well, for example, in one hand, use servers that are host in the different military zone, as I said, if they exist, of course, and deploy different resources on each server, okay? 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. More, make use of different names and roads 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? 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? 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 polling information there is. So, in this case, deployment systems in the Active Directory usually hence to aid in the development of internal persistence on servers previously seen or generate new access to the internal network from the internet, such as creating a user who has permission to access the VPN, for example. So, this is an 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 Distribute Active Directory or the use of different type of corporate service like email or VPN, okay? 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 a privileged or potential usable users. 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 authentication is modified to deploy persistent is better, okay, since we will have less possibilities of being detected, of being identified, okay? 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 could be the same organization or other secondary organization. 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 allows us to continue with intrusion in the case of there is any problem. But in my opinion, it's better than modification, for example, the Active Directory distraction, 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, 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 literally providers may have, okay? It is something that lately is being more carried out. But in the end, it is based on identifying providers that have some type of access with internal network of the target organization. And displaying persistent in them or deploying persistent in them, it is under the mostly useful sense. 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, okay? Normally, the providers or company providers have internal infrastructure. So, if we take, 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 is the same action. 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 in that environment because at the end, normally, companies have more security measures internally. But in other networks, it doesn't matter if it's a provider or it's a cloud, a private cloud, it's more difficult for the blue team to deploy that type of security measure. And it's not common. Okay, so let's continue. And finally, we got to the point 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. Okay, we have to remember that when the blue team detects an incident, those first hours or days, and 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. So in many occasions, these techniques are extremely effective due to the ignorance of the way an attacker acts for the blue team. 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. So for example, if a user has been identified with passwords like May 2020, June 2020, July 2020, it will be 13 that in a few months, this user will have the password October 2020. Okay, and that's a perfect persistent because it's really and rarely to think about it for the blue team. Okay, so in the case the user has the ability to access corporate services that do not have double factor indication, for example, VPN or Wi-Fi, it would be a perfect persistent which could only be avoided if the blue team force all the users to change their password. So also it will be surely to be the next or the next month. Okay, because normally the user always follow the same pattern. Okay, so there are very common password patterns that usually mix the company name, location, month and year and maybe the name of the person. With that, we can create some patterns and try to search that pattern. 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. Hashes, okay, could be a selective extraction and depends on the goal, of course, tracking that hashes and normally using rules with Hascat or any other tool like that and opting clean password. The third point is the identify which user had password with patterns with the last month, for example, August 2020 in this case, a verified corporate service and the type of interaction that they allow to understand what type of persistence we could deploy. For example, it's completely different 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. Okay, so it's important to understand the possibilities for the intrusion of this service. And the last one, do not use them if not necessary, okay, and never from a source that we have already used. Okay, so this is one of my favorite alternative persistence. 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. Okay, so this second scenario consists of identifying during the intrusion credential to access to the organization Wi-Fi networks that are directly connected to the internet network. Of course, not VPA to enterprise, okay, but normally VP to PSK. Okay, and our common normally in the organization will try to find from the inside during the analysis of internal system, the workstation of the administration administrators, or the NAS servers. Okay, try to find this information, okay, the credential of the networks, and of course, detect is that network is directly connected. If it's connected, it's perfect, okay, 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. 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 will be practically impossible to prevent the attacker for continue to enter. Okay, and here the steps. Really simple. The identification of Wi-Fi network, identification of users, position of throw, the analysis, for example, the identification of system connected to a Wi-Fi and extraction of credential, and finally, verification of access to these Wi-Fi networks. Okay, the next one. Try to connect periodically to a Wi-Fi. This is quite a little bit strange. This third case will consist of identify system, a usually employee, laptops that are accessible through a Wi-Fi network generated by ask. 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. When the entity, well, when the blue team, when the entity team did so, and we could already have a connection, being able to use internal servers, internal users in this case, that we have. Okay, any user that has been created in the system, et cetera. Okay, conversely, the other way around could be for the employee to raise, to admit 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 attacker creates. Okay, 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 that location, create the Wi-Fi, the laptop connect to our Wi-Fi. And in that case, we can directly interact with the server. Okay, we could create a trigger, for example, to if the text, the Wi-Fi create a local user, and we could use that user. Okay, so here we can do many actions, okay, many, many actions, but it's a real interesting approach in my opinion to really deploy persistence. Okay, and well, this point is maybe a little bit more different, but in my opinion, it could be interesting too. Okay, 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. Okay, for example, the most important is the silent section. Okay, I don't have a lot of time, so I go more, more run and more, more fast. First of all, silent section. The first one is the display of the gal global access list and to deploy a brute force attack. Okay, 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 users, it's normal information, it doesn't matter, I mean, 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 user have a predictable password, 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 real 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. 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 ReGeorge on a web server and you have a list of web servers, you can configure a laptop to try each month to use that list, and each month you deploy some different web server. 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. And here we have more aggressive action, but I don't explain 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. More, the modification of files, of office files in repositories, in apps, for example, and put malicious macros, we can create triggers and well as the same as web servers as said. The third one is the deployment of .scf files that allow us to obtain maybe keys or hazes for the employees. And the last one, the modification of .ln key files, 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. So the last part, because I don't have enough time, do you think you catch me? This is the question, 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 without 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? 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 normally 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. We need to deploy persistence with mind. Okay, so here is 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 necessary insufficient. This can always allow the attacker to detect the drop in persistence under four 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. Multiple types 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 persistent drops, it's important to use that another persistent, go into the organization inside the network and try to put some other different persistence to maintain access continuously. Okay, so redeploy in case of loss. More, avoid internal notification every time is one of the most important aspects to doing a red team exercise. Try to avoid internal modification. 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 persistent, analyze the system, they cannot correlate with all their persistence, always if the IP where we connected is different. At the same time, different internal locations, don't try to configure every persistent in the same network. Use different networks, different type of computers, different paths, different binaries, every different as you can. Okay, 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 ReGeorge, it's important to change, for example, the date of the ReGeorge to be the same more or less as in the same resource in the same path. Okay, it's important. And this is the next one, camouflage on existing resource. As we said, one possibility is not only to upload the persistent, it doesn't matter if it's ReGeorge or it's a web shell or it doesn't matter. You could upload directly, but you can camouflage that resource integrating in another existing resource and it's really important. 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, and it's really, really important, maintain persistence as a backup always. Okay, normally, in my experience, we configure three, four persistence completely different. For example, one in a web server or in a internal server on other alternative persistence like predictable user with credential. Okay, 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. 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, if we deploy persistent, follow 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 a blue team really be able to detect all of them and kick us before we could access and continue to deploy more persistent? In my opinion, an experience. No, it's impossible. Okay, if we deploy persistence on servers and internally, well, it is like an ITRA. Okay, and like this symbol of ITRA, when the blue team could off head, 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 us. Okay, that's it. Command that soon. I will publish a tool that helps in the development of all these type of persistence. And that's all. Thank you 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.