 Greetings everybody, good morning, good afternoon, good evening, based on wherever you are, welcome to my talk on modern red team tradecraft. I'd like to start off by thanking you all for viewing my talk and also a huge thank you to the brilliant team behind Defcon Red Team Village for putting together over 200 hours of content on red teaming. So massive props to Omar and the team. All right, quick introduction. I'm a senior consultant at Mandiant. My job involves simulating an adversary, otherwise known as red teaming or purple teaming. I also keep a keen eye out on tradecraft and the tactics, techniques and procedures used by the most sophisticated threat actors out there. I'm first time Defcon speaker, so yay. And you can reach out to me on Twitter at Sajal underscore Thomas. Most importantly, the opinions in this talk are mine and not my employers. Quick disclaimer here. Right, so the agenda for today is going to be a range of topics. We are going to cover why help offense to begin with. And then we will spend some time on talking about implant design considerations and upset decisions that a red team operator would require to make in order to sufficiently simulate a sophisticated adversary. We'll talk about how offense informs defense. And there's also a short section on credential harvesting because naturally no red team talk is complete without a topic on credential harvesting. Lastly, we'll cover how someone can get into red teaming and also how the modern red teamer needs to evolve and skill up in order to adequately simulate some of the sophisticated adversaries out there. At the end, we'll open up the floor for questions on the discord server. So please feel free to leave questions during the course of the talk as well as right at the end. All right, so the big question is why help offense in the first place, why spend time and energy in improving a team that merely serves the purpose of keeping you on your toes. So before we get into that, let's quickly rewind the clock to the peak of the Cold War era to draw some inspiration from clandestine intelligence and counterintelligence operations. So what you're looking at is the glorious 812 reconnaissance plane. This was built by Lockheed back in the 60s. And the purpose of this plane was to collect intelligence on the ground by flying through certain sensitive areas. And the main objective of this plane was reconnaissance and surveillance. And this plane was also known as the Ark Angel. And also in declassified documents, it was called the ox cart plane. And thanks to all the declassified documents, we now know a lot more about this plane and about how the United States had to keep it hidden from the Soviets spying eyes. So the Area 51 personnel that was operating on this plane and Area 51 was the hangar where the plane was being developed and tested. The personnel there soon realized that they would need to keep the plane hidden from Soviet spy satellites who in return would be capturing images of the plane from up above. So in order to hide it, they would quickly scoot it into a building as soon as they would learn that a spy satellite was about to enter into the Area 51 airspace. And TD Barnes, a former hypersonic flight specialist, used to say that if a plane happened to be out in the open, when the satellite was coming over the horizon, they would quickly scoot it into a building. And he would say that the entire hangar would look like a parking lot. He said that it would look like after all the cars have left, you can still see how many were parked there in infrared because of the difference in the ground temperatures. So as you can see, all the A-12 planes parked in the hangar with the shadows that they left behind on the ground. So the difference in the temperatures and the heat signatures on the ground where they were parked were naturally much different to the heat signatures of the entire hangar. And so it turned out that even with all the laborious hooting and scooting of the planes in and out of buildings, the U.S. spies learned that the Soviets had managed to get their hands on a drawing of the A-12 plane. And they assumed that they got it via the infrared satellites. So in order to thwart these infrared satellites, the Area 51 crew began constructing fake planes out of cardboard and other mundane materials in order to cast misleading shadows for Soviet spy satellites to keep pondering over. And we also know now that sometimes the hangar staff would fire up heaters near these imaginary engine locations to make it appear as if the planes had just landed. And so as red teamers and as professionals who are trying to simulate an apex adversary, what are the lessons here for us? The lessons here are that every apex adversary knows which action leaves what trace behind. And by knowing this, by knowing which signals are exposed to defenders, adversaries can mislead observers in the opposite direction. And actually if you know that your enemy or your observer is monitoring your heat signatures, then what you can do is throw them off by planting fake heat signatures and confusing them. So that was one of the lessons that I gathered from this story. And the other one is that when stealth becomes a necessity and on the other hand, if it affects the pace of the operation, then what do you do? Do you give up stealth and expose yourself or do you continue to remain stealthy but not move in the direction of your objectives? This is a question that every red team operator has faced or will face at some point in every operation. But we can conclude that having a formidable adversary to practice against does keep you on your toes and knowing every action and every signal that you leave behind does help you understand how you can improve yourself and by improving yourself how you can improve the blue team, which is the defense. So back in 2013 Lockheed Martin announced the SR-72 and they announced it with this huge slogan saying speed is the new stealth. And they said that the plane goes so fast that it's going to be invisible to radars and it's going to be undetectable in the air. But from a red team operator's point of view, is speed really the new stealth? Now there's a line of thought among red team operators that going in and getting out very quickly is something that's boastworthy. I myself am victim to this. I have boasted many a times that I got DA on day one and I completed the subjective and bad objective within a few days and that was it. But truly does this impact really help the defense achieve their goals or does this help the defense to get better themselves or does spending a lot more time and remaining undetected demonstrate more impact to the blue team? Now the defense of tech has set a new precedent. There's a lot of behavioral analysis and baselining what is normal on an endpoint or network. And what happens is that anything that goes beyond that normal or anything that comes off as an anomaly immediately generates an alert. And so allow me to share a war story of mine where I performed a Kerberos attack and I pulled 30 service account Kerberos TGS tickets within a few seconds because that's the default action when you perform any sort of Kerberos attack straight out of the box. Whether it's via Rubyus or whether you use the PowerShell script power view by picking invoke Kerberos, the default is that it will just Kerberos every single service ticket that's in the active directory. So what happened is that defenders were watching for quantity of requests and they were watching that quantity in the given time frame that I generated all those service ticket requests and they picked up this anomaly and unfortunately that was the end of my foothold. So this is from the blog by at debug privilege on Twitter. It's a blog on hunting for tactics techniques and procedures using Azure Sentinel. And what debug privilege talks about is that how requesting a huge number of Kerberos service tickets counts as an upset failure because if you if you were to look at the data from 30 days and establish a baseline of service ticket requests. I'm sorry Kerberos service account ticket requests, then you can you can have a very informed idea about how many requests or how many Kerberos tickets are requested per user per day. And then you can set a threshold and anything that goes above that threshold can just be deemed suspicious. So to conclude, maybe speed is not the new stealth for red team operations and maybe boasting about speed may not be the right approach to demonstrate impact. Okay, so let's talk about certain red team implant design considerations that will help you achieve your objectives and also simulate a sophisticated adversary. Keep in mind that we are going to be talking about red team implants alone. We're not we're not going to pick apart any of the implants used by APT actors. Right, so let's say you want to start from scratch and you do not want to rely on a commercial or open source tool. What are the few considerations you want to take into account to achieve this goal? So typically this would depend entirely on what kind of adversary you're simulating. If you if you want to simulate an APT group, then you would want to focus a lot more on stealth. Whereas if you were simulating a criminal or ransomware group, then you naturally want to spend a lot more time on speed and you don't spend more time on making your implant. able to infect a lot more variety of hosts. So you would not want to restrict it to only a certain operating system, for example, because you want to deploy it at scale. So some of the considerations that you would take into account would be to pick a language, pick a structure of your toolkit, to pick a strategy to execute your post exploitation capability because you don't want to, you don't want to have your entire implant with all the post exploitation capability in it. And we're going to talk about why in the next slide. And for inspiration, the first thing you can do is to look at the release notes of Cobalt Strike, because there's a lot to learn from the evolution of Cobalt Strike's beacon in the past few years. So my personal recommendation would be to write and see your C++ because this gives you the freedom and flexibility to interact with the native Windows 32 API, also known as Win32 API. And the structure that you would want to implement would be to write modular libraries for each post exploitation capability. So each capability should be a separate module. So if you want a key log, then your key logger should be a separate capability and that capability should be a separate library. So not only is this easier to maintain an upgrade, but there's an object benefit here, like I was mentioning in the previous slide, that if the key logging module gets burned, then at least the rest of your modules remain safe. So you're not just deploying your implant with all the capabilities in it and injecting it into the memory of your victim. What you want to do ideally is to have separate modules for all your different capabilities and then use them as per your need. And you also want to decide how to approach injecting your capabilities. So there are two major options here. One is the fork and run option which Cobalt Strike uses as well. So this approach is essentially creating a sacrificial process and injecting your capability into it, letting it complete and then closing the process and filling the process. So that is one option. The other option is to inline execute into your own process. So the process that you're running under, the process which your implant is running under, you inject your capability into this very same process and you let the job complete. Now there are caveats for both. The fork and run is actually a lot less stealthy and I'll explain why in the next few slides. And the inline execute option is much more stealthy but it runs the risk of destabilizing your implant process. So my personal recommendation is that if you have processes or if you have capabilities that you want to run over a long period of time, then you pick the fork and run option and if there are smaller capabilities or capabilities that run for a much shorter time frame, then you just inline execute them into your own process. Also Cobalt Strike has this feature which is a newly launched feature called the ability to make beacon object files. I'm not going to get into the details of how that works but essentially beacon object files now allow you to inline execute capabilities into your own process instead of the typical fork and run. So this is a move that promotes stealth but also like I mentioned there are some caveats to that. So you're operating in memory and that's perfect, that's what you want, you don't want to touch disk. All that is great but that doesn't mean that you will remain undetected. In memory it doesn't mean undetectable. Subty also known as Casey Smith once tweeted and in typical Subty fashion deleted his tweet about the three pillars of endpoint detection and response where he said that there are three things that form the pillars of EDR and the three pillars are parent-child process relationships, command line arguments and network connections made by processes. Now this makes a lot of sense from an EDR point of view and from a red teamers point of view if we were to bake these evasions into the implant design then we can have a sufficiently upset safe and still the implant. Now thanks to Will's talk at Wild West Hacking Fest we already have the evasions for the first two pillars and the last one is something we can actually do manually or we can program that logic into our implant in order to pick processes that are typically known to make network connections and use them if we want to make certain network connections inside the network or egressing from the network. So when a process launches, EDR solutions check for anomalies. So the typical examples include Word.exe spawning PowerShell.exe and then for command line arguments the typical detection for that is looking for suspicious parameters like PowerShell-execution-policy and proc-dump-m-helsaster-exec-accept-eula and the network connections are of course fairly straightforward. If you see if EDR sees explorer.exe making connections to the internet then this is naturally something that's going to come across as suspicious. So these are some of the ways that EDR performs the very basic detections. Now let's quickly talk about parent process spoofing. This isn't a new technique. This was blogged by DDA Stevens almost 11 years ago and in order to understand how parent process spoofing works let's first look at the very basics. Let's look at the Win32 API call to create a process and what this looks like is a function called create process A with certain parameters and the parameter that we are interested here is the LP startup info A parameter. So we want to make LP startup info 0.2 an extended startup info struct called startup info xA the struct startup info xA contains an attribute list called LP attribute list and the attribute list can be updated using the function update drop thread attribute. So as you can see the LP value parameter can specify which parent process you want to choose for the process that you create. So LP value will be a pointer to the handle to the process which you want to spoof as the parent as you can see in the image below. And this is proof of concept code from XPN also known as Adam Chester. You can observe the update drop thread attribute function which takes ampersand p handle as the argument and that in itself is the handle to an open process call to the specific process ID that we pick. Right, so the second vision technique talks about spoofing command line arguments. As I mentioned previously, EDR looks at this quite closely. There are many such examples. I mentioned Procmon which dumps the LSAS family. Certain other examples also include WMIC OS get slash format with a web URL pointing to an XSL style sheet which is also known as squibbley2 which was an attack discovered by Casey Smith a while back. And in order to evade this detection mechanism what we would do is we would first create a process, suspend its state, change the command line parameters in the memory to something harmless and then resume the process. But in order to do that we first need to understand what process environment block is also known as PEB. Now a PEB is mapped inside the process's workflow memory. It contains information about the process such as loaded modules, command line arguments used and other such information related to the process. And like I had mentioned the few steps involved in this process would be to create a process in the suspended state and then get the address of the PEB using the anti-query information process function call. This is something that tools like processhacker also do and that is how XPN took inspiration in order to do this. And what you do next is you replace the command line arguments stored in the PEB using write process memory and then you just resume the memory. So when you see it, when you see the logs what you'll see is the harmless parameters are logged and not the ones that you started the process with. So POC code yet again by Adam Chester. As you can see the spoof parameters right at the bottom but you start with reading the PEB from the target process using the read process memory call right at the top of the image and then you get the process parameters from the PEB using read process memory yet again and using the handle to the process and you replace the suspicious parameters with something harmless using write process memory and pointing to the PEB. The other interesting feature lets you prevent third-party DLLs from injecting into the process space of your implant. If you will recall in September 2018 Chrome 69 started this feature where it began blocking third-party software from injecting into the Chrome's process space. They did this to enhance the stability of Chrome and this feature gave inspiration to Rafael Marj creator of Cobalt Strike to bake this into Cobalt Strike's payload which is called beacon. And for those of you familiar with beacon you know that this is something we can achieve by using the block DLLs command and what block DLLs essentially does under the hood is that it creates a process with an attribute that disallows any third-party DLLs from injecting into the spawn processes. So think fork and run processes of beacon for its post exploitation and the block DLLs feature combined with it. So any new process you create in order to inject capability into it you can also set this feature into it so that it prevents any third-party DLLs from injecting into your sacrificial post exploitation processes. The caveat here of course is that only Microsoft signed DLLs can inject into these processes anything that's not signed by Microsoft cannot and also we can also use arbitrary code guard which uses a process mitigation policy to achieve similar results. So looking at the code you'll see the familiar update prop thread attribute function call yet again. What is happening here is that the create process function call is used along with the startup info x a struct which we talked about earlier and in this case this struct contains the mitigation policy which prevents non Microsoft signed DLLs from being injected. So when you observe this process you'll see that there's a mitigation policy set which will specify signature restricted to Microsoft only. Of course as everything sophisticated the level of sophistication of your activity will give away your intent. If your protected processes are something that are not normal to the environment that you're operating in then it is going to stick out like a sore thumb. So the best advice here is of course to blend in by enumerating the mitigation policies on all the processes that are running and then act accordingly. So for every apex adversary it's very important for you to know your toolkit and has a teaming advances and becomes more mature. This becomes more and more important because knowing what your toolkit does under the hood is absolutely essential. Now going back to our initial point every action by an attacker leaves a trace behind for for an attacker to reach a certain level of sophistication it is crucial to understand each action and its detection. This often means for a team operator this means that the fewer processes you create the stealthier this would be the image on the right is. Is actually a screenshot of Rafael Mudge's excellent nine part video series on retina operations. I'm going to touch upon that in the very last section of the stock. But what you see here is every action and every detection risk that is tied to it from a system on perspective. So you can see red is naturally more expensive and by expensive we mean risky. And the ones that stick out here are the creator mode thread calls the process create calls and process access. So process access includes everything from injection to hash down to any mimicettes and all the green ones are relatively safe. These are actions so file create is a very safe option. It's not something that's going to ring alarm bells all over because this is something that happens on every end point and you can possibly have alerts set for that because you'd you'd have a huge ton of false positives. Process termination is also safe. Time stopping stomping. I'm sorry is surprisingly a safe activity. Right. So at every stage of a retina operation you will be required to make an informed decision about whether your action is going to generate an alert or get blocked and based on that you will then decide how you want to proceed with achieving your objectives. So the caveat here is that actions that are loud aren't necessarily always blocked or caught straight off the bat. And Rafael sums this up very well when he says that observable does not mean observed. So the strategy is to blend in with the legitimate host and network activity. This is something that Rafael terms as session prepping. And what he means by that is that you observe the endpoint and its behavior and mergers it. My personal recommendation is that you may have to change up your session prepping based on the kind of activity you want to perform or the kind of post exploitation capability that you want to perform. And to give you an example for something like a network reconnaissance you will want to appear as a process that frequently makes a lot of network connections internally. So here what I would do is I would try to observe every single process that's making internal network connections and try to masquerade as one of them. And also bypassing the three pillars of EDR will only help your initial foothold. They'll only get you so far. What you do after that whether you stay hidden is entirely on the operator. Disabling logging instrumentation is also something that's gaining a fair amount of popularity these days. It's not something that a third party red team typically does. Why is that? It's because you're testing your customers blue team at the end of the day. And if they agree to disabling login then naturally we have a few options in terms of some of the new ETW bypasses that have come to light. And some of the Sysmon invasions and unloading of Sysmon that have been blocked about in the past few years. So these are some of the options we have but again this is not something we typically do on red team engagements. So coming back to the point about blending in your first step should always be to enumerate the running processes and their parent child relationships. Once you have a decent idea of what's running you pick a parent and a child relationship of a process that you want to masquerade as and you configure it on your implant. So this is something that you should have the option to do on the fly and not something that you have to hard code and just stick with for the rest of the engagement. Because like I said this is something that you may want to change based on the activity that you perform. Some common examples that you will see on the end points will be browser parent process. Now internet explorer used to have it with one parent process called iexplore.exe and then all the tabs that you subsequently open would also show up as child processes of that one parent process iexplore.exe. There are other such examples one of them is jusked.exe and juscheck.exe. These are the Java updater parent child processes and both of these are good options in order to blend in because they typically make network connections to the internet. So like I was mentioning internet explorer running on an end point would look something like this where there is one parent process and then the tabs that are open to show up as child processes of iexplore.exe. Another quick note about rubius. When you're performing kerblost I'm sorry not a note about rubius but about kerblosting in general. This is something that I'm going to bring up once again when we talk about how offense informs defense because it's like I mentioned it's something that very often tends to give us a lot of success in terms of domain privilege escalation. So a quick note about that I would recommend not pulling all the tickets at once. As you know I learned this the hard way because I pulled all the service tickets at once and that led to a detection and an alert and an incident and subsequently my foothold was isolated. So an effective strategy here would be to find the service account set with the earliest password set. So naturally these service accounts have the password last set attribute on their domain object and that is something you can query. And the great thing about rubius is that you can now do that with a flag called stats. So you just need to do rubius.exe kerblost slash stats and it will give you the encryption types as well as the password last set year along with the number of service accounts that had its password last set in that year. And then once you get this information what I would do is that I would then start pulling tickets from the oldest to newest and if the oldest cracks then brilliant. If it doesn't then I move on to the more recent one and then consequently progress to the more latest password last set dates. So as I mentioned previously when performing internal network req on a sense you would want to appear as a process that frequently makes internal network req connections. A good trick here is to replicate the client's host as a VM as closely as possible and then test all your actions and observe activity from a blue team's perspective. And you can use sysmon for this all day because it's free and you can also use Swift on securities sysmon config that's available publicly on the GitHub repository. And by doing so you can then look at the process relationships, the command line arguments and the network connections that your implant is making and how it's appearing on the endpoint. You'd also go a long way if you get familiar with some common quote unquote normal Windows parent time process relationships. And Sameer on Twitter posted this very informative chart with all of these examples which I refer to very often. Then I want to masquerade as something legitimate and I strongly recommend that you refer to this chart. Alright so offense informs defense and that is why we want to get better at offense and we want to go from the observable to the observed. And we want to help the blue team to observe our activity so that they can defend against threats better. So to detect parent process ID spoofing you would want to start collecting data from event tracing for Windows. Now event tracing for Windows was actually designed for debugging and not for security monitoring. But that being said it is gaining popularity to gather granular information about activity performed in the host. So to detect parent process ID spoofing you'd want to collect the event header process ID via ETW and correlate with what parent process ID you're seeing of the process. Also parent process ID spoofing requires creating processes with the extended startup information. And you'd want to monitor your process creation calls which have such information. This point is referring to the startup info XA struct. And that is a necessity if you want to perform ppins spoofing because only with that struct can you provide the handle of the process that you want to spoof as your parent. And naturally you'd want to watch out for false positives because parent process ID spoofing is actually something that UAC does and this is legitimate behavior. So you're bound to have a few false positives but as long as you know what you're looking for you should be good to go. A quick image posted by the good people at fsecure. This shows the, you can see the event generated by ETW and quite obviously the event header process ID and the parent process ID are different. And the event header process ID shows the actual parent which is 9224 process ID 9224. I also want to talk about a concept that Jared Atkinson of SpecterOps talked about in his blog. He said that we have this funnel of fidelity when it comes to detection and blue teaming. The idea here is that the funnel at each stage exists to filter out noise in a calculated way but also affects the ability of a future step to be successful. So as you can see you may have a million events in your detection funnel but with all the filters you have in place be it filters of technology or a human eye. Everything you have in place should provide output to the very next filter which would take that output as its input. So when you're triaging you should have a lot fewer alerts that you want to send to the next phase. This is because investigating a hundred alerts or even a hundred thousand events is fairly infeasible no matter how large the organization is. And as Sapti puts it in his stock along with Ross Wolf called Fantastic Red Teams and how to find them. He says that behaviors happen over time and we need to monitor where the action happens. So for example SVChost.exe being spawned without the hyphen K command line parameter is something that's quite obviously suspicious. And SVChost.exe being spawned not as a child of services.exe is also something that you should be looking at because the normal process relationship of SVChost is as a child of services.exe and again with the command line parameters have hyphen K and the name of the service after that. So another such odd behavior would be system level processes being spawned by non-system parents. This usually indicates some level of local privilege escalation wherein your non-system parent process is generating a system level escalated privilege process. So the idea would be to locate attempts to blend in and also locate legitimate binaries being renamed or being replaced and put in a different directory which is not its standard directory. You would also go a long way if you find processes which are creating network connections but these processes are part of the living of the land binaries. So lol bins as you want it. Another great blog post by Gerald revolves around his philosophy of detecting attack capabilities. He calls this the concept of capability abstraction. So the idea here is that an attacker's tools are merely an abstraction of their attack capabilities and detection engineers must understand how to evaluate abstraction while building detection logic. So what he means is that when an attacker runs let's say invoke Kerberost or Rubius or Mimikatz then these present itself as detection opportunities at many levels. So first is the managed code itself and the other is the underlying Win32 API call that is being used and it could also be the RPC call on the network that you could build your detection off of. And lastly of course the network protocol that you can monitor for suspicious activity. So speaking of Mimikatz let's jump to credential harvesting very quickly. So creds are king naturally every red teamer knows this credentials are a red teamer's best friend and when we have plain text passwords it opens up multiple doors for us. Without creds without plain text creds we have other options like hashes and tickets. But I mean there's nothing quite like good old plain text passwords right. Every red teamer needs to use some sort of credential harvesting tooling in their red team operations. This is because in order to achieve our objectives we do need to steal credentials and make our way to some level of escalated privileges to complete our objectives. Now modern defenses have caught on to this trend and made life harder for real world attackers and consequently red teamers. But overall of course this is a good thing we want this to be hard because we don't want it to be easy for the real world bad guys. So certain techniques that have been used are extensive signatures itself for the credential harvesting tools. So you now know that Defender does very very well against Mimikatz and by Mimikatz I mean just the word Mimikatz. You can have the word Mimikatz in a harmless program and it would still be detected as malicious which I have no complaints against. It is a good thing because nothing legitimate comes out of anything called Mimikatz but this is a strategy that they've chosen to go with and I respect that. So a few other techniques that we have seen being used are user-learn API hooking. So specific APIs like read process memory and sometimes open process on the LSAS process itself have proven to be suspicious or detectable by a certain EDR vendors. And of course there is protective processes light which is an OS level mitigation. Alex INSku has a great blog post series on PPL if you're interested to get into the details and internals. So what is API hooking? Think of it as a man in the middle attack by the EDR product as you can see in the image main.exe is using the create remote thread API call but this API call is hooked. So what actually happens under the hood is that there's a jump instruction that hijacks the execution flow and this jump instruction takes the flow of execution to the process space. The process space of the EDR and its DLL. So once it's in the process space of that DLL it will then perform its checks, it will look at the function call, it will look at the arguments, it will see if the parameters are safe. If it's fine then it decides that execution can assume, if it deems it as suspicious then it will either generate an alert or outright block it. Certain other techniques that have been publicly documented are unhooking these userland API hooks using direct access calls to NTDLL.dll. So what we want to do here is that we want to use the very same hooked API calls but we want to use the underlying NTDLL function call with the help of syscalls in ASM. So in order to do this you first need to resolve the syscalls from NTDLL and then jump directly to the NTDLL call. Another alternative that is publicly documented is getting creative with certain Win32 APIs. For example the PSS Capture Snapshot API. This API takes the, this function takes the snapshot of the LSAS process and what happens is you can then use the mini dump write dump function on the snapshot of LSAS instead of LSAS itself. So you're essentially creating a copy and performing all your malicious activity on the copy and not the original. So this tends to evade certain detections that rely on your getting a handle on LSAS and reading the process memory of LSAS itself. So in some occasions you'll also see LSAS running as PPL. This is something that you can observe from the registry key. This registry key is run as PPL as you can see in the image. With run as PPL enabled your, excuse me, your options will be limited to dropping a vulnerable preferably signed kernel driver and this vulnerable kernel driver will allow you to execute code in kernel space and this in turn will allow you to load another kernel driver of your choosing. So something like MimiDRV.Sys which is the kernel driver which is created by the creator of MimiGats. And if the vulnerable driver is unsigned then you would need to use the vulnerable driver to first disable driver signing enforcement, then load your driver and then dump credentials. There's a lot more to this talk but it's outside this, there's a lot more to this topic, I'm sorry, but it's outside the scope of this talk and the timeframe of this talk. But typically loading drivers on production environments is deemed risky and if you want to do this then you should request permission beforehand because ultimately we are a red team, we are not the real adversary, we don't want to cause blue screens of death on production environments and as an attacker of course the concept of offense in depth is important to us because we need to know different techniques to achieve the same goals because if one technique does not work or if one technique has been patched then you should have the knowledge of different ways to achieve the same result. Which finally brings us to being a red teamer in 2020 and how this has changed in the past few years. So to begin with the training landscape for red teaming is ever changing, there are very few courses out there, there are a few good ones of course and that number is slowly growing but most of the mainstream courses have little or no focus on skills that will enable you to walk into a red team role and like pentest roles as well there's the catch-22 of red team roles requiring experience and you needing a job in order to get experience in the first place so what is the best advice I would give to myself if I had to do it all over again? I would very very strongly recommend watching Rafael Maju's red team operations video series I mentioned earlier that this is a nine-part video series, it's based on Cobalt Strike but it will teach you the fundamentals of red team trade craft and most red team roles will require you to fully understand the ins and out of Cobalt Strike anyway so it's a win-win, the best part is that it's free and there are two such series that I strongly recommend one is the red team operations as I mentioned and the other is the in-memory evasion video series which talks about some of the features that Beacon has recently implemented which help with keeping it upset safe in memory so once you're familiar with a mature C2 framework, I would recommend that you build your own from scratch a very basic one, it doesn't have to be something sophisticated but building one yourself will go a long way in helping you understand the integrities of implants and C2 frameworks and Rastlamaus has a very informative video series on the development of Sharp C2 that is currently ongoing and I've seen that Rastlamaus is very regularly posting videos to this playlist I would also strongly recommend reading through Dominic Chell's post on learnings from a decade of red teaming he talks about what he has learned in an entire decade of red teaming and there's some very useful insight for someone who's been around for over a decade and definitely give that one a read also watch Will Burge's talk on red teaming, sorry if I butchered your last name this is a very informative talk, it pushed the envelope in favour of red teams very, very significantly and the three pillars of EDR that I kept mentioning throughout the talk are something that Will's talk has also addressed also you would want to master every attack vector on the Active Directory so for that there's no better place than going to HarmJoy's blogs and Tweets and also Biotec's Tweets and ADSecurity.org which is a fantastic resource for all things AD and security learn about process injection, you can typically do this for free because there are plenty of resources out there but I have been made aware of a course by Pentester Academy and it's being taught by Pavel Jocifovich himself which is going to be a very promising course and that's something that I might look at taking up as well I also want to mention that I'm not paid to sponsor any of these trainings or any of these materials, this is an independent and unbiased recommendation and lastly learn how to set up your C2 infra then automate it for speed and efficiency you can use Terraform, Ansible, there are plenty of ways there's a lot of DevOps influence on recent C2 infra deployment and a lot of people have found very innovative ways to do this so keep an eye out, keep reading, never stop learning so a huge shout out to the people who made their research public and pushed the envelope to improve security this is the short list and I'm quite confident that there are a lot more out there who have contributed and thank you all for all your work and image credits of the A12 Archangel and SR71 to the good people at Langley right, so now I'll open the floor for questions please post all your questions on the Discord server thank you all once again for watching my talk feel free to reach out to me on Twitter and have a nice day