WEBVTT 00:01.760 --> 00:03.420 Greetings, everybody. 00:03.620 --> 00:07.700 Good morning, good afternoon, good evening, based on wherever you are. 00:07.700 --> 00:11.000 Welcome to my talk on modern Red Team Tradecraft. 00:11.380 --> 00:27.300 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 DEF CON Red Team Village for putting together over 200 hours of content on Red Teaming. 00:27.300 --> 00:30.840 So, massive props to Omar and the team. 00:32.220 --> 00:32.720 All right. 00:32.720 --> 00:34.080 Quick introduction. 00:34.180 --> 00:36.760 I'm a senior consultant at Mandiant. 00:36.760 --> 00:43.380 My job involves simulating an adversary, otherwise known as Red Teaming or Purple Teaming. 00:43.560 --> 00:54.460 I also keep a keen eye out on tradecraft and the tactics, techniques, and procedures used by the most sophisticated threat actors out there. 00:54.880 --> 00:57.420 I'm a first-time DEF CON speaker. 00:57.420 --> 00:58.440 So, yay. 00:58.500 --> 01:03.980 And you can reach out to me on Twitter at Sajal underscore Thomas. 01:04.120 --> 01:09.600 Most importantly, the opinions in this talk are mine and not my employer's. 01:11.260 --> 01:13.420 Quick disclaimer here. 01:15.910 --> 01:16.650 Right. 01:16.650 --> 01:21.010 So, the agenda for today is going to be a range of topics. 01:21.010 --> 01:24.930 We're going to cover why help offense to begin with. 01:24.990 --> 01:42.190 And then we'll spend some time on talking about implant design considerations and OPSEC decisions that a Red Team operator would require to make in order to sufficiently simulate a sophisticated adversary. 01:42.210 --> 01:45.870 We'll talk about how offense informs defense. 01:46.490 --> 01:58.450 And there's also a short section on credential harvesting because, naturally, no Red Team talk is complete without a topic on credential harvesting. 01:58.890 --> 02:18.090 Lastly, we'll cover how someone can get into Red Teaming and also how the modern Red Teamer needs to evolve and scale up in order to adequately simulate some of the sophisticated adversaries out there. 02:18.290 --> 02:21.570 At the end, we'll open up the floor for questions on the Discord server. 02:21.570 --> 02:27.310 So, please feel free to leave questions during the course of the talk as well as right at the end. 02:29.150 --> 02:29.790 All right. 02:29.790 --> 02:33.470 So, the big question is why help offense in the first place? 02:33.470 --> 02:42.070 Why spend time and energy in improving a team that merely serves the purpose of keeping you on your toes? 02:42.490 --> 02:55.220 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. 02:57.460 --> 03:04.280 So, what you're looking at is the glorious A-12 reconnaissance plane. 03:04.320 --> 03:08.380 This was built by Lockheed back in the 60s. 03:08.380 --> 03:18.400 And the purpose of this plane was to collect intelligence on the ground by flying through certain sensitive areas. 03:18.400 --> 03:22.980 And the main objective of this plane was reconnaissance and surveillance. 03:23.020 --> 03:27.560 And this plane was also known as the Archangel. 03:27.920 --> 03:35.300 And also, in declassified documents, it was called the Oxcart plane. 03:35.860 --> 03:48.800 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. 03:49.240 --> 04:01.760 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. 04:01.940 --> 04:15.540 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. 04:15.540 --> 04:30.820 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. 04:31.220 --> 04:33.360 And T.D. 04:33.360 --> 04:47.240 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. 04:47.580 --> 04:53.560 And he would say that the entire hangar would look like a parking lot. 04:53.560 --> 05:04.540 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. 05:06.580 --> 05:18.260 So, as you can see, all the A-12 planes parked in the hangar with the shadows that they left behind on the ground. 05:18.280 --> 05:28.860 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. 05:28.980 --> 05:46.200 And so, it turned out that even with all the laborious hooting and scooting of the planes in and out of buildings, the US spies learned that the Soviets had managed to get their hands on a drawing of the A-12 plane. 05:46.380 --> 05:50.280 And they assumed that they got it via the infrared satellites. 05:50.360 --> 06:09.100 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 wandering over. 06:09.340 --> 06:23.760 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. 06:26.140 --> 06:36.180 And so, as red teamers and as professionals who are trying to simulate an Apex adversary, what are the lessons here for us? 06:36.700 --> 06:44.860 The lessons here are that every Apex adversary knows which action leaves what trace behind. 06:45.180 --> 06:54.220 And by knowing this, by knowing which signals are exposed to defenders, adversaries can mislead observers in the opposite direction. 06:54.220 --> 07:10.820 So, naturally, if you know that your enemy or your observer is monitoring your heat signatures, what you can do is throw them off by planting fake heat signatures and confusing them. 07:11.580 --> 07:16.980 So, that was one of the lessons that I gathered from this story. 07:16.980 --> 07:27.420 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? 07:27.420 --> 07:30.360 Do you give up stealth and expose yourself? 07:30.360 --> 07:36.940 Or do you continue to remain stealthy but not move in the direction of your objectives? 07:36.940 --> 07:45.600 This is a question that every red team operator has faced or will face at some point in every operation. 07:46.680 --> 07:53.900 But we can conclude that having a formidable adversary to practice against does keep you on your toes. 07:53.900 --> 08:12.440 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. 08:14.460 --> 08:32.700 So, back in 2013, Lockheed Martin announced the SR-72, which and they announced it with this huge slogan saying speed is the new stealth. 08:32.880 --> 08:43.660 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. 08:45.320 --> 08:51.080 But from a red team operator's point of view, is speed really the new stealth? 08:51.080 --> 09:03.640 Now, there's a line of thought among red team operators that going in and getting out very quickly is something that's boastworthy. 09:03.640 --> 09:06.900 I, myself, am a victim to this. 09:06.900 --> 09:18.000 I have boasted many a times that I got DA on day one and I completed this objective and that objective within a few days and that was it. 09:18.240 --> 09:27.660 But truly, does this impact really help the defense achieve their goals? 09:27.660 --> 09:31.920 Or does this help the defense to get better themselves? 09:32.200 --> 09:41.060 Or does spending a lot more time and remaining undetected demonstrate more impact to the blue team? 09:41.380 --> 09:47.540 Now, the defense of tech has set a new precedent. 09:48.220 --> 09:55.700 There's a lot of behavioral analysis and baselining what is normal on an endpoint, on a network. 09:55.900 --> 10:07.920 And what happens is that anything that goes beyond that normal or anything that comes off as an anomaly immediately generates an alert. 10:08.800 --> 10:20.620 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. 10:20.840 --> 10:26.460 Because that's the default action when you perform any sort of Kerberos attack straight out of the box. 10:26.460 --> 10:35.940 Whether it's via Rubius or whether you use the PowerShell script, PowerView by picking invoke Kerberos. 10:35.940 --> 10:41.520 The default is that it will just Kerberos every single service ticket that's in the active directory. 10:42.520 --> 10:50.040 So, what happened is that defenders were watching for quantity of requests. 10:50.340 --> 11:00.860 And they were watching that quantity in the given time frame that I generated all those service ticket requests. 11:00.860 --> 11:02.800 And they picked up this anomaly. 11:02.800 --> 11:05.600 And unfortunately, that was the end of my foothold 11:10.460 --> 11:18.440 So, this is from the blog by at debugprivilege on Twitter. 11:18.440 --> 11:25.800 It's a blog on hunting for tactics, techniques, and procedures using Azure Sentinel. 11:26.080 --> 11:37.140 And what debugprivilege talks about is that how requesting a huge number of Kerberos service tickets counts as an OPSEC failure. 11:37.140 --> 12:04.820 Because 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 have a very informed idea about how many requests or how many Kerberos tickets are requested per user per day. 12:04.820 --> 12:12.320 And then you can set a threshold and anything that goes above that threshold can just be deemed suspicious. 12:12.640 --> 12:17.540 So, to conclude, maybe speed is not the new stealth for Red Team operations. 12:17.540 --> 12:23.760 And maybe boosting about speed may not be the right approach to demonstrate impact. 12:27.300 --> 12:27.700 Okay. 12:27.700 --> 12:40.360 So, let's talk about certain Red Team implant design considerations that will help you achieve your objectives and also simulate a sophisticated adversary. 12:40.700 --> 12:44.560 Keep in mind that we are going to be talking about Red Team implants alone. 12:44.560 --> 12:51.080 We are not going to pick apart any of the implants used by APT actors. 12:51.940 --> 12:52.580 Right. 12:52.580 --> 12:58.520 So, let's say you want to start from scratch and you do not want to rely on a commercial or open source tool. 12:58.760 --> 13:03.500 What are the few considerations you'd want to take into account to achieve this goal? 13:04.080 --> 13:09.480 So, typically, this would depend entirely on what kind of adversary you're simulating. 13:09.480 --> 13:38.980 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 a ransomware group, then you'd 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. 13:38.980 --> 13:47.060 So, you would not want to restrict it to only a certain operating system, for example, because you want to deploy it at scale. 13:47.380 --> 14:09.400 So, some of the considerations that you would take into account would be to pick a language, to pick a structure of your toolkit, to pick a strategy to execute your post-exploitation capability, because you don't want to have your entire implant with all the post-exploitation capability in it. 14:09.400 --> 14:11.920 And we're going to talk about why in the next slide. 14:12.300 --> 14:24.680 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. 14:26.220 --> 14:39.900 So, my personal recommendation would be to write in C or C++, because this gives you the freedom and flexibility to interact with the native Windows 32 API, also known as Win32 API. 14:40.160 --> 14:48.120 And the structure that you would want to implement would be to write modular libraries for each post-exploitation capability. 14:48.120 --> 14:51.640 So, each capability should be a separate module. 14:51.640 --> 14:57.800 So, if you want to keylog, then your keylogger should be a separate capability. 14:57.880 --> 15:02.900 And that capability should be a separate library. 15:03.520 --> 15:19.300 So, not only is this easier to maintain and upgrade, but there's an object benefit here, like I was mentioning in the previous slide, that if the keylogging module gets burned, then at least the rest of your modules remain safe. 15:19.300 --> 15:27.900 So, you're not just deploying your implant with all the capabilities in it and injecting it into the memory of your victim. 15:27.900 --> 15:39.960 What you want to do, ideally, is to have separate modules for all your different capabilities, and then use them as per your need. 15:40.820 --> 15:45.940 And you also want to decide how to approach injecting your capabilities. 15:45.940 --> 15:49.760 So, there are two major options here. 15:49.760 --> 15:55.960 One is the fork and run option, which Cobalt Strike uses as well. 15:55.960 --> 16:12.160 So, this approach is essentially creating a sacrificial process and injecting your capability into it, letting it complete, and then closing the process and killing the process. 16:12.280 --> 16:13.640 So, that is one option. 16:13.640 --> 16:17.700 The other option is to inline execute into your own process. 16:17.700 --> 16:32.180 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. 16:32.180 --> 16:35.040 Now, there are caveats for both. 16:35.620 --> 16:44.060 The fork and run is actually a lot less stealthy, and I'll explain why in the next few slides. 16:44.400 --> 16:53.940 And the inline execute option is much more stealthy, but it runs the risk of destabilizing your implant process. 16:53.940 --> 17:07.700 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. 17:07.700 --> 17:19.940 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. 17:20.340 --> 17:29.980 Also , Cobalt Strike has this feature, which is a newly launched feature called the ability to make beacon object files. 17:30.120 --> 17:45.760 And 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. 17:45.760 --> 17:54.000 So, this is a move that promotes stealth, but also, like I mentioned, there are some caveats to that. 17:57.100 --> 18:00.200 So, great. 18:00.200 --> 18:03.180 So, you're operating in memory, and that's perfect. 18:03.180 --> 18:04.200 That's what you want. 18:04.200 --> 18:06.020 You don't want to touch disk. 18:06.020 --> 18:10.280 All that is great, but that doesn't mean that you will remain undetected. 18:10.280 --> 18:13.560 It doesn't mean in memory doesn't mean undetectable. 18:14.080 --> 18:38.660 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, 18:38.660 --> 18:44.100 command line arguments, and network connections made by processes. 18:44.760 --> 19:02.960 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 OPSEC safe and stealthy implant. 19:02.960 --> 19:34.020 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, 19:34.020 --> 19:36.880 or egressing from the network. 19:37.640 --> 19:44.000 So, when a process launches, EDR solutions check for anomalies. 19:44.400 --> 20:15.300 So, the typical examples include word.exe spawning partial.exe, and then for command line arguments, this is the typical detection for that is looking for suspicious parameters like a partial-execution policy, and proc dump-n lsast.exe, hyphen accept EULA, 20:15.300 --> 20:20.260 and the network connections are, of course, fairly straightforward. 20:20.260 --> 20:30.480 If you see, if EDR sees explorer.exe making connections to the internet, this is naturally something that's going to come across as suspicious. 20:30.580 --> 20:37.820 So, these are some of the ways that EDR performs the very basic detections. 20:38.300 --> 20:42.940 Now, let's quickly talk about pair-and-process spoofing. 20:43.460 --> 20:46.080 This isn't a new technique. 20:46.080 --> 20:52.160 This was blogged by DDR Stevens almost 11 years ago. 20:53.440 --> 21:00.940 And, in order to understand how pair-and-process spoofing works, let's first look at the very basics. 21:00.940 --> 21:06.640 Let's look at the Win32 API call to create a process. 21:06.980 --> 21:15.900 And what this looks like is a function called create process A with certain parameters. 21:16.000 --> 21:24.960 And the parameter that we are interested here is the LP startup info A parameter. 21:28.270 --> 21:37.650 So, we want to make LP startup info point to an extended startup info struct called startup info XA. 21:37.650 --> 21:45.010 The struct startup info XA contains an attribute list called LP attribute list. 21:45.890 --> 21:52.050 And the attribute list can be updated using the function update drop thread attribute. 21:52.630 --> 22:02.150 So, as you can see, the LP value parameter can specify which process, which pair-and-process you want to choose for the process that you create. 22:02.150 --> 22:12.570 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. 22:15.130 --> 22:21.950 And this is proof of concept code from XPN, also known as Adam Chester. 22:21.950 --> 22:33.750 You can observe the update drop thread attribute function which takes ampersand P handle as the argument. 22:33.750 --> 22:44.650 And that in itself is the handle to an open process call to the specific process ID that we pick. 22:46.410 --> 22:47.250 Right. 22:47.250 --> 22:51.250 So, the second evasion technique talks about spoofing command line arguments. 22:52.270 --> 22:57.070 As I mentioned previously, EDR looks at this quite closely. 22:57.070 --> 22:59.110 There are many such examples. 22:59.110 --> 23:06.430 I mentioned Procmon, which dumps the LSAS memory. 23:06.550 --> 23:26.830 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 squiggly2, which was an attack discovered by Casey Smith a while back. 23:26.830 --> 23:44.730 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. 23:49.110 --> 23:56.810 But in order to do that, we first need to understand what process environment block is, also known as PEB. 23:57.090 --> 24:01.510 Now, a PEB is mapped inside the process's virtual memory. 24:01.510 --> 24:12.370 It contains information about the process, such as loaded modules, command line arguments used, and other such information related to the process. 24:14.270 --> 24:30.130 And like I 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 NT query information process function call. 24:30.130 --> 24:33.910 This is something that tools like Process Hacker also do. 24:34.070 --> 24:41.650 And that is how XPN took inspiration in order to do this. 24:41.730 --> 24:51.830 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. 24:51.830 --> 25:02.450 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. 25:05.270 --> 25:07.790 So, POC code yet again by Adam Chester. 25:08.170 --> 25:13.990 As you can see, the spoof parameters right at the bottom. 25:13.990 --> 25:24.550 But you start with reading the PEB from the target process using a reprocess memory call right at the top of the image. 25:24.550 --> 25:33.450 And then you get the process parameters from the PEB using reprocess memory yet again, and using the handle to the process. 25:33.490 --> 25:44.390 And you replace the suspicious parameters with something harmless using write process memory, and pointing to the PEB. 25:47.850 --> 25:57.650 The other interesting feature lets you prevent third-party DLLs from injecting into the process space of your implant. 25:58.590 --> 26:11.390 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. 26:11.390 --> 26:15.110 They did this to enhance the stability of Chrome. 26:15.130 --> 26:28.390 And this feature gave inspiration to Raphael Mudge, creator of CobaltStrike, to bake this into CobaltStrike's payload, which is called Beacon. 26:28.550 --> 26:36.530 And for those of you familiar with Beacon, you know that this is something we can achieve by using the block DLLs command. 26:36.870 --> 26:50.130 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. 26:50.490 --> 27:01.290 So think fork and run processes of Beacon for its post-exploitation and the block DLLs feature combined with it. 27:01.290 --> 27:16.810 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. 27:16.910 --> 27:24.330 The caveat here, of course, is that only Microsoft-signed DLLs can inject into these processes. 27:24.330 --> 27:28.030 Anything that's not signed by Microsoft cannot. 27:28.590 --> 27:37.770 And we can also use arbitrary code guard, which uses a process mitigation policy to achieve similar results. 27:42.040 --> 27:48.600 So looking at the code, you'll see the familiar update prop thread attribute function call yet again. 27:48.600 --> 27:59.100 What is happening here is that the create process function call is used along with the startup info xa struct, which we talked about earlier. 27:59.180 --> 28:10.060 And in this case, this struct contains the mitigation policy which prevents non-Microsoft signed DLLs from being injected. 28:12.230 --> 28:27.030 So when you observe this process, you'll see that there's a policy set which will specify signature restricted to Microsoft only. 28:29.370 --> 28:40.510 Of course, as everything is sophisticated, the level of sophistication of your activity will give away your intent. 28:40.550 --> 28:51.890 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. 28:51.890 --> 29:02.070 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. 29:04.940 --> 29:10.100 So for every APEX adversary, it's very important for you to know your toolkit. 29:10.140 --> 29:17.060 And as red teaming advances and becomes more mature, this becomes more and more important. 29:17.100 --> 29:22.170 Because knowing what your toolkit does under the hood is absolutely essential. 29:23.800 --> 29:29.930 Now, going back to the initial point, every action by an attacker leaves a trace behind. 29:30.540 --> 29:39.520 For an attacker to reach a certain level of sophistication, it is crucial to understand each action and its detection risk. 29:40.240 --> 29:48.460 This often means, for a red team operator, the fewer processes you create, the stealthier this would be. 29:48.680 --> 29:58.500 The image on the right is actually a screenshot of Raphael Mudge's excellent nine-part video series on red team operations. 29:59.020 --> 30:04.360 I'm going to touch upon that in the very last section of this talk. 30:04.500 --> 30:15.440 But what you see here is every action and every detection risk that is tied to it from a Sysmon perspective. 30:15.440 --> 30:20.880 So you can see red is naturally more expensive. 30:20.880 --> 30:24.140 And by expensive, we mean risky. 30:24.200 --> 30:33.740 And the ones that stick out here are the create remote thread calls, the process create calls, and process access. 30:33.740 --> 30:42.100 So process access includes everything from injection to hash dump to running mimikatz. 30:42.380 --> 30:46.560 And all the green ones are the relatively safer actions. 30:46.640 --> 30:50.740 So file create is a very safe option. 30:50.740 --> 31:05.860 It's not something that's going to ring alarm bells all over, because this is something that happens on every endpoint, and you can't possibly have alerts set for that, because you'd have a huge ton of false positives. 31:06.580 --> 31:09.360 Process termination is also safe. 31:09.660 --> 31:15.540 Time stomping is surprisingly a safe activity. 31:19.420 --> 31:19.700 Right. 31:19.700 --> 31:31.020 So at every stage of a red team operation, you will be required to make an informed decision about whether your action is going to generate an alert or also get blocked. 31:31.020 --> 31:37.910 And based on that, you will then decide how you want to proceed with achieving your objectives. 31:44.860 --> 31:55.440 So the caveat here is that actions that are loud aren't necessarily always blocked or caught straight off the bat. 31:55.440 --> 32:01.380 And Raphael sums this up very well when he says that observable does not mean observed. 32:02.240 --> 32:07.320 So the strategy is to blend in with the legitimate host and network activity. 32:07.880 --> 32:13.020 This is something that Raphael terms as session prepping. 32:13.400 --> 32:22.100 And what he means by that is that you observe the endpoint and its behavior and merge with it. 32:22.340 --> 32:35.480 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. 32:35.480 --> 32:49.420 And to give you an example, for something like network reconnaissance, you will want to appear as a process that frequently makes a lot of network connections internally. 32:49.420 --> 33:01.040 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. 33:02.360 --> 33:10.000 And also bypassing the three pillars of EDR will only help your initial foothold, they'll only get you so far. 33:10.480 --> 33:16.960 What you do after that, whether you stay hidden, is entirely on the operator. 33:18.540 --> 33:25.540 Disabling logging instrumentation is also something that's gaining a fair amount of popularity these days. 33:25.540 --> 33:32.420 It's not something that a third party red team typically does. 33:32.660 --> 33:33.340 Why is that? 33:33.340 --> 33:37.500 It's because you're testing your customer's blue team at the end of the day. 33:37.720 --> 33:59.640 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 evasions and unloading of Sysmon that have been blogged about in the past few years. 33:59.820 --> 34:01.620 So these are some of the options we have. 34:01.620 --> 34:07.420 But again, this is not something we typically do on red team engagements. 34:09.140 --> 34:19.580 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. 34:19.800 --> 34:33.940 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. 34:33.940 --> 34:42.540 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. 34:42.540 --> 34:51.000 Because like I said, this is something that you may want to change based on the activity that you perform. 34:51.760 --> 34:57.760 Some common examples that you will see on the endpoints will be a browser parent process. 34:57.760 --> 35:15.320 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. 35:15.320 --> 35:17.760 There are other such examples. 35:17.760 --> 35:23.700 One of them is jusced.exe and juscheck.exe. 35:23.700 --> 35:39.060 These are the 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. 35:41.150 --> 35:56.790 So like I was mentioning, Internet Explorer running on an endpoint would look something like this, where there's one parent process and then the tabs that are opened show up as child processes of iExplore.exe. 35:59.990 --> 36:18.770 Another quick note about Ruby is, when you're performing Kerberost... I'm sorry, not a note about Ruby, but about Kerberosting 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, 36:18.770 --> 36:28.550 like I mentioned, it's something that very often tends to give us a lot of success in terms of domain privilege escalation. 36:28.550 --> 36:35.430 So a quick note about that, I would recommend not pulling all the tickets at once. 36:35.430 --> 36:52.450 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. 36:52.710 --> 37:07.670 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. 37:08.930 --> 37:18.610 And the great thing about Ruby is that you can now do that with a flag called stats. 37:18.610 --> 37:38.390 So you just need to do rubyist.exe Kerberost 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. 37:38.990 --> 37:51.290 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. 37:51.290 --> 38:03.290 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. 38:06.830 --> 38:16.050 So as I mentioned previously when performing internal network reconnaissance you would want to appear as a process that frequently makes internal network connections. 38:16.310 --> 38:29.750 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. 38:30.130 --> 38:46.170 And you can use Sysmon for this all day because it's free and you can also use Swift on security's Sysmon config that's available publicly on the GitHub repository. 38:47.210 --> 38:59.770 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. 39:01.570 --> 39:11.490 You'd also go a long way if you get familiar with some common quote-unquote normal Windows parent-child process relationships. 39:12.050 --> 39:30.310 And Sameer on Twitter posted this very informative chart with all of these examples which I refer to very often when I want to masquerade as something legitimate and I strongly recommend that you refer to this chart. 39:33.530 --> 39:44.690 All right 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. 39:45.230 --> 39:53.130 And we want to help the blue team to observe our activity so that they can defend against threats better. 39:53.270 --> 40:01.610 So to detect parent process ID spoofing you would want to start collecting data from event tracing for Windows. 40:01.610 --> 40:14.170 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. 40:14.690 --> 40:28.950 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. 40:28.950 --> 40:42.550 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. 40:42.550 --> 41:02.090 This point is referring to the startup info xa struct and that is a necessity if you want to perform peep and spoofing because only with that struct can you provide the handle of the process that you want to spoof as your parent. 41:02.750 --> 41:13.550 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. 41:13.550 --> 41:20.950 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. 41:22.390 --> 41:53.190 A quick image posted by the good people at F-Secure, 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, 41:53.190 --> 41:55.180 process ID 9224. 41:57.200 --> 42:06.190 I also want to talk about a concept that Jared Atkinson of SpectreOps talked about in his blog. 42:07.440 --> 42:15.150 He said that we have this funnel of fidelity when it comes to detection and blue teaming. 42:15.150 --> 42:30.210 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. 42:30.210 --> 42:58.830 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. 42:58.830 --> 43:06.070 So when you're triaging you should have a lot fewer alerts that you want to send to the next phase. 43:06.540 --> 43:20.210 This is because investigating 100 alerts or even 100,000 events is fairly infeasible, no matter how large the organization is. 43:21.510 --> 43:37.910 And as Sapti puts it in his talk 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. 43:37.910 --> 43:51.010 So, for example, svchost.exe being spawned without the hyphen k command line parameter is something that's quite obviously suspicious. 43:51.650 --> 44:16.330 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. 44:16.430 --> 44:24.990 So another such odd behavior would be system level processes being spawned by non-system parents. 44:24.990 --> 44:40.630 This usually indicates some level of local privilege escalation wherein your non-system parent process is generating a system level escalated privilege process. 44:41.050 --> 44:57.650 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. 44:58.370 --> 45:14.350 You would also go a long way if you find processes which are creating network connections but these processes are part of the living off the land binaries, so lolbins as you call it. 45:16.730 --> 45:23.310 Another great blog post by Gerald revolves around his philosophy of detecting attacker capabilities. 45:23.310 --> 45:27.470 He calls this the concept of capability abstraction. 45:27.930 --> 45:43.070 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. 45:43.070 --> 46:02.430 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. 46:02.430 --> 46:21.950 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. 46:21.950 --> 46:29.870 And lastly, of course, the network protocol that you can monitor for suspicious activity. 46:32.560 --> 46:40.660 So speaking of Mimikatz, let's jump to credential harvesting very quickly. 46:41.860 --> 46:43.560 So creds are king, naturally. 46:43.560 --> 46:45.240 Every red teamer knows this. 46:45.280 --> 46:52.520 Credentials are a red teamer's best friend and when we have tame text passwords, it opens up multiple doors for us. 46:52.860 --> 46:59.900 Without plain text creds, we have other options like hashes and tickets. 47:00.040 --> 47:06.260 But I mean, there's nothing quite like good old text passwords, right? 47:06.380 --> 47:16.560 Every red teamer needs to use some sort of credential harvesting tooling in their red team operations. 47:16.560 --> 47:31.540 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. 47:31.960 --> 47:42.700 Now, modern defenses have caught on to this trend and made life harder for real world attackers and consequently red teamers. 47:42.940 --> 47:45.240 But overall, of course, this is a good thing. 47:45.240 --> 47:51.260 We want this to be hard because we don't want it to be easy for the real world bad guys. 47:51.860 --> 48:02.760 So certain techniques that have been used are extensive signatures itself for the credential harvesting tools. 48:03.160 --> 48:09.180 So we now know that Defender does very, very well against Mimikatz. 48:09.700 --> 48:12.460 And by Mimikatz, I mean just the word Mimikatz. 48:12.460 --> 48:24.840 You can have the word Mimikatz in a harmless program and it would still be detected as malicious, which I have no complaints against. 48:24.840 --> 48:30.220 It is a good thing because nothing legitimate comes out of anything called Mimikatz. 48:30.220 --> 48:35.040 But this is a strategy that they've chosen to go with and I respect that. 48:35.440 --> 48:42.520 So a few other techniques that we have seen being used are user-learned API hooking. 48:42.540 --> 49:04.920 So specific APIs like read process memory and sometimes open process on the LSAS process itself have proven to be suspicious or detectable by certain EDR vendors. 49:05.200 --> 49:10.900 And of course, there is protected processes light, which is an OS level mitigation. 49:11.240 --> 49:18.500 Alex Ionescu has a great blog post series on PPL if you're interested to get into the details and internals. 49:19.160 --> 49:21.120 So what is API hooking? 49:21.860 --> 49:27.340 Think of it as a man-in-the-middle attack by the EDR product. 49:27.440 --> 49:37.300 As you can see in the image, main.exe is using the create remote thread API call, but this API call is hooked. 49:37.300 --> 49:44.460 So what actually happens under the hood is that there's a jump instruction that hijacks the execution flow. 49:44.460 --> 49:55.620 And this jump instruction takes the flow of execution to the process space of the EDR and its DLL. 49:56.020 --> 50:03.360 So once it's in the process space of that DLL, it will then perform its checks. 50:03.360 --> 50:05.000 It will look at the function call. 50:05.000 --> 50:06.680 It will look at the arguments. 50:06.680 --> 50:10.820 It will see if the parameters are safe. 50:10.820 --> 50:16.060 If it's fine, then it decides that execution can resume. 50:16.060 --> 50:22.980 If it deems it as suspicious, it will either generate an alert or outright block it. 50:25.370 --> 50:38.560 Certain other techniques that have been publicly documented are unhooking these useland API hooks using direct syscalls to ntdll.dll. 50:40.640 --> 50:53.450 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 ASN. 50:53.650 --> 51:01.170 So in order to do this, you first need to resolve the syscalls from ntdll and then jump directly to the ntdll call. 51:03.460 --> 51:12.880 Another alternative that is publicly documented is getting creative with Win32 APIs. 51:12.880 --> 51:16.560 For example, the PSS capture snapshot API. 51:16.760 --> 51:34.160 This function takes the snapshot of the process and what happens is you can then use the mini dump write dump function on the snapshot of Lsas instead of Lsas itself. 51:34.160 --> 51:42.440 So you're essentially creating a copy and performing all your malicious activity on the copy and not the original. 51:42.560 --> 51:54.420 So this tends to evade certain detections that rely on your getting a handle on Lsas and reading the process memory of Lsas itself. 51:57.390 --> 52:02.550 So in some occasions, you'll also see Lsas running as PPL. 52:02.550 --> 52:08.310 This is something that you can observe from the registry key. 52:10.030 --> 52:14.590 And this registry key is run as PPL, as you can see in the image. 52:16.170 --> 52:27.290 With run as PPL enabled, your options will be limited to dropping a vulnerable, preferably signed kernel driver. 52:27.290 --> 52:33.570 And this vulnerable kernel driver will allow you to execute code in kernel space. 52:33.570 --> 52:39.010 And this in turn will allow you to load another kernel driver of your choosing. 52:39.170 --> 52:50.350 So something like mimi-drv.sys, which is the kernel driver which is created by the creator of Mimikatz. 52:50.730 --> 53:03.710 And if the vulnerable driver is unsigned, then you would need to use the driver to first disable driver signing enforcement, then load your driver, and then dump credentials. 53:04.210 --> 53:10.170 There's a lot more to this talk, but it's outside this... there's a lot more to this topic, I'm sorry. 53:10.170 --> 53:13.570 But it's outside the scope of this talk. 53:13.690 --> 53:16.270 And the time frame of this talk. 53:16.830 --> 53:23.970 But typically, loading drivers on production environments is deemed risky. 53:23.970 --> 53:29.050 And if you want to do this, then you should request permission beforehand. 53:29.390 --> 53:31.350 Because ultimately, we are a red team. 53:31.350 --> 53:33.050 We are not the real adversary. 53:33.050 --> 53:40.050 We don't want to cause blue screens of death on production environments. 53:40.590 --> 53:48.670 And as an attacker, of course, the concept of offense in depth is important to us. 53:48.670 --> 53:53.690 Because we need to know different techniques to achieve the same goals. 53:53.690 --> 54:05.650 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. 54:08.060 --> 54:16.520 Which finally brings us to being a red teamer in 2020 and how this has changed in the past few years. 54:19.410 --> 54:24.130 So, to begin with, the training landscape for red teaming is ever changing. 54:24.130 --> 54:26.710 There are very few courses out there. 54:26.870 --> 54:29.370 There are a few good ones, of course. 54:29.590 --> 54:32.170 And that number is slowly growing. 54:32.770 --> 54:43.050 But most of the mainstream courses have little or no focus on skills that will enable you to walk into a red team role. 54:43.830 --> 54:57.510 And like pen test 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. 54:58.190 --> 55:04.330 So, what is the best advice I would give to myself if I had to do it all over again? 55:04.330 --> 55:13.190 Well, I would very, very strongly recommend watching Rafael Maggio's Red Team Operations video series. 55:13.370 --> 55:17.070 I mentioned earlier that this is a nine-part video series. 55:17.070 --> 55:23.490 It's based on Cobalt Strike, but it will teach you the fundamentals of red team tradecraft. 55:24.170 --> 55:33.190 And most red team roles will require you to fully understand the ins and outs of Cobalt Strike anyway, so it's a win-win. 55:33.470 --> 55:36.530 The best part is that it's free. 55:37.590 --> 55:41.250 And there are two such series that I strongly recommend. 55:41.250 --> 56:00.190 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 OPSEC safe in memory. 56:00.810 --> 56:07.530 So, once you're familiar with a mature C2 framework, I would recommend that you build your own from scratch. 56:07.530 --> 56:08.630 A very basic one. 56:08.630 --> 56:22.370 It doesn't have to be something sophisticated, but building one yourself will go a long way in helping you understand the nitty-gritties of implants and C2 frameworks. 56:22.510 --> 56:39.610 And Rastamouse has a very informative video series on the development of Sharp C2 that is currently ongoing , and I've seen that Rastamouse is very regularly posting videos to this playlist. 56:41.610 --> 56:50.050 I would also strongly recommend reading through Dominic Chell's post on learnings from a decade of Red Teaming. 56:50.270 --> 57:01.790 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. 57:01.870 --> 57:05.190 And definitely give that one a read. 57:05.350 --> 57:09.910 Also, watch Will Burge's talk on Red Teaming. 57:09.910 --> 57:12.490 Sorry, Will, if I butchered your last name. 57:12.930 --> 57:15.670 This is a very informative talk. 57:15.670 --> 57:33.870 It pushed the envelope in favor 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. 57:34.650 --> 57:40.570 Also, you would want to master every attack vector on the Active Directory. 57:40.770 --> 57:58.750 So, for that, there's no better place than going to Harmjoy's blogs and tweets, and also biotech's tweets, and adsecurity.org, which is a fantastic resource for all things AD and security. 58:00.980 --> 58:03.180 Learn about process injection. 58:03.180 --> 58:28.140 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 Yosefovich himself, which is going to be a very promising course, that's something that I might look at taking up as well. 58:28.820 --> 58:37.580 I also want to mention that I'm not paid to sponsor any of these trainings, or any of these materials. 58:37.580 --> 58:41.480 This is an independent and unbiased recommendation. 58:42.400 --> 58:49.960 And lastly, learn how to set up your C2 infra, then automate it for speed and efficiency. 58:49.960 --> 58:53.480 You can use Terraform, Ansible, there are plenty of ways. 58:53.640 --> 59:05.820 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. 59:06.180 --> 59:09.170 So, keep an eye out, keep reading, never stop learning. 59:12.600 --> 59:19.760 So, a huge shout out to the people who make their research public, and push the envelope to improve security. 59:19.960 --> 59:29.060 This is a short list, and I'm quite confident that there are a lot more out there who have contributed. 59:29.900 --> 59:42.320 And thank you all for all your work, and image credits of the A12 Archangel and SR71 to the good people at Langley. 59:42.880 --> 59:43.720 Right. 59:43.720 --> 59:45.980 So, now I'll open the floor for questions. 59:45.980 --> 59:49.220 Please post all your questions on the Discord server. 59:50.720 --> 59:53.520 Thank you all once again for watching my talk. 59:53.520 --> 59:58.900 Feel free to reach out to me on Twitter, and have a nice day.