[00:01.760 --> 00:05.900] Greetings, everybody. Good morning, good afternoon, good evening, [00:05.900 --> 00:11.000] based on wherever you are. Welcome to my talk on modern Red Team Tradecraft. [00:11.380 --> 00:19.580] I'd like to start off by thanking you all for viewing my talk and also a huge thank you to the [00:19.580 --> 00:26.160] brilliant team behind DEF CON Red Team Village for putting together over 200 hours of content [00:26.160 --> 00:30.840] on Red Teaming. So, massive props to Omar and the team. [00:32.220 --> 00:38.460] All right. Quick introduction. I'm a senior consultant at Mandiant. My job involves [00:38.460 --> 00:45.340] simulating an adversary, otherwise known as Red Teaming or Purple Teaming. I also keep a keen eye [00:45.340 --> 00:52.400] out on tradecraft and the tactics, techniques, and procedures used by the most sophisticated [00:52.400 --> 00:59.820] threat actors out there. I'm a first-time DEF CON speaker. So, yay. And you can reach out to [00:59.820 --> 01:07.600] me on Twitter at Sajal underscore Thomas. Most importantly, the opinions in this talk are mine [01:07.600 --> 01:19.290] and not my employer's. Quick disclaimer here. Right. So, the agenda for today is going to be [01:19.390 --> 01:26.550] a range of topics. We're going to cover why help offense to begin with. And then we'll spend some [01:26.550 --> 01:33.470] time on talking about implant design considerations and OPSEC decisions that a Red Team operator [01:34.410 --> 01:42.830] would require to make in order to sufficiently simulate a sophisticated adversary. We'll talk [01:42.830 --> 01:51.510] about how offense informs defense. And there's also a short section on credential harvesting [01:51.510 --> 01:58.450] because, naturally, no Red Team talk is complete without a topic on credential harvesting. [01:58.890 --> 02:07.050] Lastly, we'll cover how someone can get into Red Teaming and also how the modern Red Teamer [02:07.050 --> 02:16.550] needs to evolve and scale up in order to adequately simulate some of the sophisticated [02:16.550 --> 02:21.570] adversaries out there. 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:34.450] All right. So, the big question is why help offense in the first place? Why spend time [02:34.940 --> 02:42.070] and energy in improving a team that merely serves the purpose of keeping you on your toes? [02:42.490 --> 02:49.070] So, before we get into that, let's quickly rewind the clock to the peak of the Cold War era [02:49.720 --> 02:55.220] to draw some inspiration from clandestine intelligence and counterintelligence operations. [02:57.460 --> 03:06.500] So, what you're looking at is the glorious A-12 reconnaissance plane. This was built by Lockheed [03:06.500 --> 03:14.680] back in the 60s. And the purpose of this plane was to collect intelligence on the ground [03:14.680 --> 03:21.760] by flying through certain sensitive areas. And the main objective of this plane was reconnaissance [03:21.760 --> 03:31.360] and surveillance. And this plane was also known as the Archangel. And also, in declassified [03:31.360 --> 03:38.100] documents, it was called the Oxcart plane. And thanks to all the declassified documents, [03:38.100 --> 03:44.700] we now know a lot more about this plane and about how the United States had to keep it hidden [03:45.130 --> 03:55.620] from the Soviets' spying eyes. So, the Area 51 personnel that was operating on this plane, [03:55.620 --> 04:03.320] and Area 51 was the hangar where the plane was being developed and tested. The personnel there [04:03.320 --> 04:10.140] soon realized that they would need to keep the plane hidden from Soviet spy satellites, [04:10.140 --> 04:18.300] who in return would be capturing images of the plane from up above. So, in order to hide it, [04:18.300 --> 04:25.520] they would quickly scoot it into a building as soon as they would learn that a spy satellite was [04:26.380 --> 04:37.420] about to enter into the Area 51 airspace. And T.D. Barnes, a former hypersonic flight specialist, [04:37.420 --> 04:43.140] used to say that if a plane happened to be out in the open when the satellite was coming over [04:43.140 --> 04:51.660] the horizon, they would quickly scoot it into a building. And he would say that the entire hangar [04:51.660 --> 04:57.220] would look like a parking lot. He said that it would look like, after all the cars have left, [04:57.220 --> 05:03.160] you can still see how many were parked there in infrared because of the difference in the [05:03.160 --> 05:14.760] ground temperatures. So, as you can see, all the A-12 planes parked in the hangar with the shadows [05:14.760 --> 05:20.760] that they left behind on the ground. So, the difference in the temperatures and the heat [05:20.760 --> 05:26.800] signatures on the ground where they were parked were naturally much different to the heat signatures [05:26.800 --> 05:34.840] of the entire hangar. And so, it turned out that even with all the laborious hooting and scooting [05:34.840 --> 05:41.880] of the planes in and out of buildings, the US spies learned that the Soviets had managed to [05:42.340 --> 05:49.000] get their hands on a drawing of the A-12 plane. And they assumed that they got it via the infrared [05:49.000 --> 05:57.500] satellites. So, in order to thwart these infrared satellites, the Area 51 crew began constructing [05:58.040 --> 06:04.560] fake planes out of cardboard and other mundane materials in order to cast misleading shadows [06:05.080 --> 06:14.860] for Soviet spy satellites to keep wandering over. And we also know now that sometimes the hangar [06:14.860 --> 06:21.920] staff would fire up heaters near these imaginary engine locations to make it appear as if the [06:21.920 --> 06:31.880] planes had just landed. And so, as red teamers and as professionals who are trying to simulate [06:32.560 --> 06:38.200] an Apex adversary, what are the lessons here for us? The lessons here are that [06:39.160 --> 06:47.440] every Apex adversary knows which action leaves what trace behind. And by knowing this, by knowing [06:47.440 --> 06:54.220] which signals are exposed to defenders, adversaries can mislead observers in the opposite direction. [06:54.220 --> 07:02.500] So, naturally, if you know that your enemy or your observer is monitoring your heat signatures, [07:02.500 --> 07:10.820] what you can do is throw them off by planting fake heat signatures and confusing them. [07:11.580 --> 07:18.300] So, that was one of the lessons that I gathered from this story. And the other one is that when [07:18.300 --> 07:25.120] stealth becomes a necessity, and on the other hand, if it affects the pace of the operation, [07:25.720 --> 07:32.000] then what do you do? Do you give up stealth and expose yourself? Or do you continue to remain [07:32.000 --> 07:38.240] stealthy but not move in the direction of your objectives? This is a question that [07:38.240 --> 07:45.600] every red team operator has faced or will face at some point in every operation. [07:46.680 --> 07:52.820] But we can conclude that having a formidable adversary to practice against does keep you [07:52.820 --> 07:59.880] on your toes. And knowing every action and every signal that you leave behind [08:00.320 --> 08:08.340] does help you understand how you can improve yourself, and by improving yourself, [08:08.340 --> 08:12.440] how you can improve the blue team, which is the defense. [08:14.460 --> 08:24.660] So, back in 2013, Lockheed Martin announced the SR-72, [08:25.220 --> 08:33.400] which and they announced it with this huge slogan saying speed is the new stealth. And [08:34.360 --> 08:41.660] they said that the plane goes so fast that it's going to be invisible to radars and it's going [08:41.660 --> 08:49.580] to be undetectable in the air. But from a red team operator's point of view, is speed really [08:49.580 --> 08:59.020] the new stealth? Now, there's a line of thought among red team operators that going in and getting [08:59.020 --> 09:07.760] out very quickly is something that's boastworthy. I, myself, am a victim to this. I have boasted [09:07.760 --> 09:14.360] many a times that I got DA on day one and I completed this objective and that objective [09:14.360 --> 09:26.660] within a few days and that was it. But truly, does this impact really help the defense achieve [09:26.660 --> 09:35.320] their goals? Or does this help the defense to get better themselves? Or does spending a lot more [09:35.320 --> 09:43.320] time and remaining undetected demonstrate more impact to the blue team? Now, the defense of tech [09:44.180 --> 09:51.500] has set a new precedent. There's a lot of behavioral analysis and baselining [09:51.500 --> 09:59.600] what is normal on an endpoint, on a network. And what happens is that anything that [10:00.920 --> 10:07.920] goes beyond that normal or anything that comes off as an anomaly immediately generates an alert. [10:08.800 --> 10:15.980] And so, allow me to share a war story of mine where I performed a Kerberos attack and I pulled [10:15.980 --> 10:22.920] 30 service account Kerberos TGS tickets within a few seconds. Because that's the default action [10:22.920 --> 10:27.520] when you perform any sort of Kerberos attack straight out of the box. Whether it's via [10:27.520 --> 10:36.400] Rubius or whether you use the PowerShell script, PowerView by picking invoke Kerberos. The default [10:36.400 --> 10:41.520] is that it will just Kerberos every single service ticket that's in the active directory. [10:42.520 --> 10:50.720] So, what happened is that defenders were watching for quantity of requests. And [10:51.460 --> 10:58.960] they were watching that quantity in the given time frame that I generated all those service [10:59.520 --> 11:05.600] ticket requests. And they picked up this anomaly. And unfortunately, that was the end of my foothold [11:10.460 --> 11:22.440] So, this is from the blog by at debugprivilege on Twitter. It's a blog on hunting for tactics, [11:22.440 --> 11:28.520] techniques, and procedures using Azure Sentinel. And what debugprivilege talks about is that [11:30.460 --> 11:37.640] how requesting a huge number of Kerberos service tickets counts as an OPSEC failure. Because [11:38.340 --> 11:46.300] if you were to look at the data from 30 days and establish a baseline of service ticket requests, [11:46.300 --> 11:52.760] I'm sorry, Kerberos service account ticket requests, then you can have a very [11:54.060 --> 12:04.820] informed idea about how many requests or how many Kerberos tickets are requested per user per day. [12:04.820 --> 12:09.600] And then you can set a threshold and anything that goes above that threshold [12:09.600 --> 12:16.540] can just be deemed suspicious. So, to conclude, maybe speed is not the new stealth for Red Team [12:16.540 --> 12:23.760] operations. And maybe boosting about speed may not be the right approach to demonstrate impact. [12:27.300 --> 12:32.700] Okay. So, let's talk about certain Red Team implant design considerations [12:33.740 --> 12:40.980] that will help you achieve your objectives and also simulate a sophisticated adversary. Keep [12:40.980 --> 12:46.260] in mind that we are going to be talking about Red Team implants alone. We are not going to pick [12:46.260 --> 12:53.820] apart any of the implants used by APT actors. Right. So, let's say you want to start from [12:53.820 --> 12:59.600] scratch and you do not want to rely on a commercial or open source tool. What are the few [12:59.600 --> 13:05.340] considerations you'd want to take into account to achieve this goal? So, typically, this would [13:05.340 --> 13:12.860] depend entirely on what kind of adversary you're simulating. If you want to simulate an APT group, [13:12.860 --> 13:18.900] then you would want to focus a lot more on stealth, whereas if you were simulating a criminal [13:18.900 --> 13:25.620] or a ransomware group, then you'd naturally want to spend a lot more time on speed and [13:25.620 --> 13:31.300] you don't spend more time on making your implant [13:33.780 --> 13:41.780] able to infect a lot more variety of hosts. So, you would not want to restrict it to only a [13:41.780 --> 13:49.200] certain operating system, for example, because you want to deploy it at scale. So, some of the [13:49.200 --> 13:53.220] considerations that you would take into account would be to pick a language, to pick a structure [13:53.220 --> 13:58.980] of your toolkit, to pick a strategy to execute your post-exploitation capability, because [13:58.980 --> 14:09.500] you don't want to have your entire implant with all the post-exploitation capability in it. And [14:09.500 --> 14:15.760] we're going to talk about why in the next slide. And for inspiration, the first thing you can do [14:15.760 --> 14:21.360] is to look at the release notes of Cobalt Strike, because there's a lot to learn from the evolution [14:21.360 --> 14:28.960] of Cobalt Strike's beacon in the past few years. So, my personal recommendation would be to write [14:28.960 --> 14:35.260] in C or C++, because this gives you the freedom and flexibility to interact with the native [14:35.260 --> 14:43.460] Windows 32 API, also known as Win32 API. And the structure that you would want to implement would [14:43.460 --> 14:49.600] be to write modular libraries for each post-exploitation capability. So, each capability [14:49.600 --> 14:56.500] should be a separate module. So, if you want to keylog, then your keylogger should be a separate [14:56.500 --> 15:05.460] capability. And that capability should be a separate library. So, not only is this easier [15:05.460 --> 15:10.440] to maintain and upgrade, but there's an object benefit here, like I was mentioning in the previous [15:10.440 --> 15:19.300] slide, that if the keylogging module gets burned, then at least the rest of your modules remain safe. [15:19.300 --> 15:26.180] So, you're not just deploying your implant with all the capabilities in it and injecting it into the [15:26.180 --> 15:32.840] memory of your victim. What you want to do, ideally, is to have separate modules for all your [15:32.840 --> 15:42.960] different capabilities, and then use them as per your need. And you also want to decide [15:42.960 --> 15:50.500] how to approach injecting your capabilities. So, there are two major options here. One is [15:51.320 --> 15:58.860] the fork and run option, which Cobalt Strike uses as well. So, this approach is essentially [15:59.680 --> 16:08.180] creating a sacrificial process and injecting your capability into it, letting it complete, [16:08.180 --> 16:14.360] and then closing the process and killing the process. So, that is one option. The other option [16:14.360 --> 16:21.020] is to inline execute into your own process. So, the process that you're running under, [16:21.700 --> 16:27.760] the process which your implant is running under, you inject your capability into this very same [16:27.760 --> 16:36.840] process, and you let the job complete. Now, there are caveats for both. The fork and run is [16:36.840 --> 16:44.060] actually a lot less stealthy, and I'll explain why in the next few slides. [16:44.400 --> 16:52.160] And the inline execute option is much more stealthy, but it runs the risk of destabilizing [16:52.160 --> 16:59.640] your implant process. So, my personal recommendation is that if you have processes, [16:59.640 --> 17:06.400] or if you have capabilities that you want to run over a long period of time, then you pick the fork [17:06.400 --> 17:14.820] and run option. And if there are smaller capabilities or capabilities that run for a [17:14.820 --> 17:20.500] much shorter time frame, then you just inline execute them into your own process. [17:20.500 --> 17:26.560] Also, Cobalt Strike has this feature, which is a newly launched feature called [17:26.560 --> 17:34.100] the ability to make beacon object files. And I'm not going to get into the details of how that [17:34.100 --> 17:40.680] works, but essentially, beacon object files now allow you to inline execute capabilities [17:40.680 --> 17:49.940] into your own process instead of the typical fork and run. So, this is a move that promotes stealth, [17:49.940 --> 18:00.340] but also, like I mentioned, there are some caveats to that. So, great. So, [18:00.340 --> 18:05.100] you're operating in memory, and that's perfect. That's what you want. You don't want to touch [18:05.100 --> 18:10.740] disk. All that is great, but that doesn't mean that you will remain undetected. It doesn't mean [18:10.740 --> 18:18.640] in memory doesn't mean undetectable. Subty, also known as Casey Smith, once tweeted, [18:18.640 --> 18:25.680] and in typical Subty fashion, deleted his tweet about the three pillars of endpoint detection [18:25.680 --> 18:33.740] and response, where he said that there are three things that form the pillars of EDR [18:33.740 --> 18:40.260] and the three pillars are parent-child process relationships, command line arguments, [18:40.260 --> 18:47.020] and network connections made by processes. Now, this makes a lot of sense from an EDR [18:47.020 --> 18:53.220] point of view, and from a Red Teamers point of view, if we were to bake these evasions [18:54.100 --> 19:02.960] into the implant design, then we can have a sufficiently OPSEC safe and stealthy implant. [19:02.960 --> 19:11.120] Now, thanks to Will's talk at Wild West Hacking Fest, we already have the evasions for the first [19:11.120 --> 19:19.280] two pillars, and the last one is something we can actually do manually, or we can program that [19:19.280 --> 19:28.380] logic into our implant in order to pick processes that are typically known to make network connections [19:28.380 --> 19:35.620] and use them if we want to make certain network connections inside the network, or egressing from [19:35.620 --> 19:46.060] the network. So, when a process launches, EDR solutions check for anomalies. So, the typical [19:46.060 --> 19:56.320] examples include word.exe spawning partial.exe, and then for command line arguments, this is [19:56.980 --> 20:04.960] the typical detection for that is looking for suspicious parameters like a partial-execution [20:04.960 --> 20:18.980] policy, and proc dump-n lsast.exe, hyphen accept EULA, and the network connections are, of course, [20:18.980 --> 20:24.880] fairly straightforward. If you see, if EDR sees explorer.exe making connections to the internet, [20:24.880 --> 20:30.820] this is naturally something that's going to come across as suspicious. So, [20:30.820 --> 20:37.820] these are some of the ways that EDR performs the very basic detections. [20:38.300 --> 20:46.520] Now, let's quickly talk about pair-and-process spoofing. This isn't a new technique. This was [20:46.520 --> 20:56.640] blogged by DDR Stevens almost 11 years ago. And, in order to understand how pair-and-process [20:56.640 --> 21:04.700] spoofing works, let's first look at the very basics. Let's look at the Win32 API call to [21:04.700 --> 21:14.140] create a process. And what this looks like is a function called create process A with certain [21:14.140 --> 21:19.660] parameters. And the parameter that we are interested here is [21:21.720 --> 21:33.990] the LP startup info A parameter. So, we want to make LP startup info point to an extended startup [21:33.990 --> 21:42.750] info struct called startup info XA. The struct startup info XA contains an attribute list called [21:42.750 --> 21:50.070] LP attribute list. And the attribute list can be updated using the function update [21:50.070 --> 21:58.190] drop thread attribute. So, as you can see, the LP value parameter can specify which process, [21:58.190 --> 22:05.650] which pair-and-process you want to choose for the process that you create. So, LP value will be a [22:05.650 --> 22:10.550] pointer to the handle to the process which you want to spoof as the parent, as you can see in [22:10.550 --> 22:22.130] the image below. And this is proof of concept code from XPN, also known as Adam Chester. You [22:22.130 --> 22:32.630] can observe the update drop thread attribute function which takes ampersand P handle as the [22:32.630 --> 22:43.390] argument. And that in itself is the handle to an open process call to the specific process ID that [22:43.390 --> 22:51.250] we pick. Right. So, the second evasion technique talks about spoofing command line arguments. [22:52.270 --> 22:59.110] As I mentioned previously, EDR looks at this quite closely. There are many such examples. [22:59.110 --> 23:08.990] I mentioned Procmon, which dumps the LSAS memory. Certain other examples also include [23:09.830 --> 23:18.070] WMIC OS get slash format with a web URL pointing to an XSL style sheet, which [23:18.950 --> 23:27.290] is also known as squiggly2, which was an attack discovered by Casey Smith a while back. And [23:28.070 --> 23:37.310] in order to evade this detection mechanism, what we would do is we would first create a process, [23:37.310 --> 23:42.730] suspend its state, change the command line parameters in the memory to something harmless, [23:42.730 --> 23:52.910] and then resume the process. But in order to do that, we first need to understand what [23:52.910 --> 24:00.190] process environment block is, also known as PEB. Now, a PEB is mapped inside the process's [24:00.190 --> 24:05.970] virtual memory. It contains information about the process, such as loaded modules, [24:05.970 --> 24:12.370] command line arguments used, and other such information related to the process. [24:14.270 --> 24:19.970] And like I mentioned, the few steps involved in this process would be to create a process [24:19.970 --> 24:28.810] in the suspended state, and then get the address of the PEB using the NT query information process [24:28.810 --> 24:37.790] function call. This is something that tools like Process Hacker also do. And that is how XPN took [24:37.790 --> 24:45.850] inspiration in order to do this. And what you do next is you replace the command line [24:46.770 --> 24:52.070] arguments stored in the PEB using write process memory, and then you just resume the memory. So, [24:52.070 --> 24:59.590] when you see it, when you see the logs, what you'll see is the harmless parameters are logged, [24:59.590 --> 25:07.790] and not the ones that you started the process with. So, POC code yet again by Adam Chester. [25:08.170 --> 25:15.910] As you can see, the spoof parameters right at the bottom. But you start with reading [25:16.710 --> 25:24.630] the PEB from the target process using a reprocess memory call right at the top of the image. And [25:24.630 --> 25:30.330] then you get the process parameters from the PEB using reprocess memory yet again, [25:30.330 --> 25:38.210] and using the handle to the process. And you replace the suspicious parameters with [25:39.190 --> 25:44.390] something harmless using write process memory, and pointing to the PEB. [25:47.850 --> 25:54.670] The other interesting feature lets you prevent third-party DLLs from injecting into the [25:55.130 --> 26:06.170] process space of your implant. If you will recall, in September 2018, Chrome 69 started this feature [26:06.170 --> 26:11.390] where it began blocking third-party software from injecting into the Chrome's process space. [26:11.390 --> 26:20.110] They did this to enhance the stability of Chrome. And this feature gave inspiration to Raphael [26:20.110 --> 26:28.390] Mudge, creator of CobaltStrike, to bake this into CobaltStrike's payload, which is called Beacon. [26:28.550 --> 26:33.930] And for those of you familiar with Beacon, you know that this is something we can achieve by [26:33.930 --> 26:41.890] using the block DLLs command. And what block DLLs essentially does under the hood is that [26:41.890 --> 26:47.670] it creates a process with an attribute that disallows any third-party DLLs from injecting [26:47.670 --> 26:57.750] into the spawn processes. So think fork and run processes of Beacon for its post-exploitation and [26:58.670 --> 27:04.670] the block DLLs feature combined with it. So any new process you create in order to inject [27:04.670 --> 27:12.470] capability into it, you can also set this feature into it so that it prevents any third-party DLLs [27:12.470 --> 27:17.970] from injecting into your sacrificial post-exploitation processes. The caveat here, of [27:17.970 --> 27:25.310] course, is that only Microsoft-signed DLLs can inject into these processes. Anything that's not [27:25.310 --> 27:34.830] signed by Microsoft cannot. And we can also use arbitrary code guard, which uses a process [27:34.830 --> 27:45.660] mitigation policy to achieve similar results. So looking at the code, you'll see the familiar [27:45.660 --> 27:51.400] update prop thread attribute function call yet again. What is happening here is that the create [27:51.400 --> 27:57.980] process function call is used along with the startup info xa struct, which we talked about [27:57.980 --> 28:06.580] earlier. And in this case, this struct contains the mitigation policy which prevents non-Microsoft [28:06.580 --> 28:17.930] signed DLLs from being injected. So when you observe this process, you'll see that there's a [28:17.930 --> 28:27.030] policy set which will specify signature restricted to Microsoft only. [28:29.370 --> 28:38.290] Of course, as everything is sophisticated, the level of sophistication of your activity will [28:38.290 --> 28:48.410] give away your intent. If your protected processes are something that are not normal to the environment [28:48.410 --> 28:53.310] that you're operating in, then it is going to stick out like a sore thumb. So the best advice [28:53.310 --> 28:58.850] here is, of course, to blend in by enumerating the mitigation policies on all the processes that are [28:58.850 --> 29:08.780] running, and then act accordingly. So for every APEX adversary, it's very important for you to [29:08.780 --> 29:15.800] know your toolkit. And as red teaming advances and becomes more mature, this becomes more and [29:15.800 --> 29:22.170] more important. 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:35.560] For an attacker to reach a certain level of sophistication, it is crucial to understand [29:36.410 --> 29:43.460] each action and its detection risk. This often means, for a red team operator, [29:43.460 --> 29:52.360] the fewer processes you create, the stealthier this would be. The image on the right is actually [29:52.560 --> 29:58.500] a screenshot of Raphael Mudge's excellent nine-part video series on red team operations. [29:59.020 --> 30:06.860] I'm going to touch upon that in the very last section of this talk. But what you see here is [30:07.510 --> 30:15.600] every action and every detection risk that is tied to it from a Sysmon perspective. So [30:16.550 --> 30:26.160] you can see red is naturally more expensive. And by expensive, we mean risky. And the ones [30:26.160 --> 30:31.680] that stick out here are the create remote thread calls, the process create calls, and [30:32.400 --> 30:37.100] process access. So process access includes everything from injection [30:39.060 --> 30:46.900] to hash dump to running mimikatz. And all the green ones are the relatively safer actions. So [30:48.200 --> 30:52.660] file create is a very safe option. It's not something that's going to [30:53.600 --> 30:58.600] ring alarm bells all over, because this is something that happens on every endpoint, [30:58.600 --> 31:05.860] and you can't possibly have alerts set for that, because you'd have a huge ton of false positives. [31:06.580 --> 31:15.540] Process termination is also safe. Time stomping is surprisingly a safe activity. [31:19.420 --> 31:24.300] Right. So at every stage of a red team operation, you will be required to make an informed decision [31:24.300 --> 31:32.160] about whether your action is going to generate an alert or also get blocked. And based on that, [31:32.160 --> 31:37.910] you will then decide how you want to proceed with achieving your objectives. [31:44.860 --> 31:53.500] So the caveat here is that actions that are loud aren't necessarily always blocked or caught [31:53.500 --> 31:59.680] straight off the bat. And Raphael sums this up very well when he says that observable does not [31:59.680 --> 32:07.320] mean observed. So the strategy is to blend in with the legitimate host and network activity. [32:07.880 --> 32:15.220] This is something that Raphael terms as session prepping. And what he means by that is [32:15.960 --> 32:22.100] that you observe the endpoint and its behavior and merge with it. [32:22.340 --> 32:28.840] My personal recommendation is that you may have to change up your session prepping based on the [32:28.840 --> 32:33.840] kind of activity you want to perform or the kind of post-exploitation capability that you want to [32:33.840 --> 32:42.760] perform. And to give you an example, for something like network reconnaissance, [32:42.760 --> 32:48.400] you will want to appear as a process that frequently makes a lot of network connections [32:48.400 --> 32:56.420] internally. So here what I would do is I would try to observe every single process that's [32:56.420 --> 33:01.040] making internal network connections and try to masquerade as one of them. [33:02.360 --> 33:08.280] And also bypassing the three pillars of EDR will only help your initial foothold, [33:08.280 --> 33:15.060] they'll only get you so far. What you do after that, whether you stay hidden, is entirely [33:15.060 --> 33:22.600] on the operator. Disabling logging instrumentation is also something that's gaining [33:23.480 --> 33:30.660] a fair amount of popularity these days. It's not something that a third party red team [33:30.660 --> 33:36.620] typically does. Why is that? It's because you're testing your customer's blue team at the end of [33:36.620 --> 33:45.200] the day. And if they agree to disabling login, then naturally we have a few [33:45.200 --> 33:52.460] options in terms of some of the new ETW bypasses that have come to light and some of the Sysmon [33:52.460 --> 33:59.640] evasions and unloading of Sysmon that have been blogged about in the past few years. [33:59.820 --> 34:05.680] So these are some of the options we have. But again, this is not something we typically do on [34:05.680 --> 34:15.280] red team engagements. So coming back to the point about blending in, your first step should always [34:15.280 --> 34:21.140] be to enumerate the running processes and their parent-child relationships. Once you have a decent [34:21.140 --> 34:28.080] idea of what's running, you pick a parent and a child relationship of a process that you want [34:28.080 --> 34:35.400] to masquerade as, and you configure it on your implant. So this is something that you should [34:35.400 --> 34:41.200] have the option to do on the fly and not something that you have to hard code and just stick with for [34:41.200 --> 34:48.400] the rest of the engagement. Because like I said, this is something that you may want to change [34:48.400 --> 34:55.500] based on the activity that you perform. Some common examples that you will see on the endpoints will [34:55.500 --> 35:04.200] be a browser parent process. Now, Internet Explorer used to have it with one parent process [35:04.840 --> 35:11.460] called iExplore.exe, and then all the tabs that you subsequently open would also show up as child [35:11.460 --> 35:18.720] processes of that one parent process, iExplore.exe. There are other such examples. One of them is [35:18.720 --> 35:28.280] jusced.exe and juscheck.exe. These are the the Java updater parent-child processes, [35:28.840 --> 35:37.260] and both of these are good options in order to blend in because they typically make network [35:37.260 --> 35:46.470] connections to the internet. So like I was mentioning, Internet Explorer running on an [35:46.470 --> 35:50.030] endpoint would look something like this, where there's one parent process and then [35:50.530 --> 35:56.790] the tabs that are opened show up as child processes of iExplore.exe. [35:59.990 --> 36:06.550] Another quick note about Ruby is, when you're performing Kerberost... I'm sorry, not a note [36:06.550 --> 36:13.030] about Ruby, but about Kerberosting in general, this is something that I'm going to bring up [36:13.030 --> 36:20.050] once again when we talk about how offense informs defense, because it's, like I mentioned, it's [36:20.050 --> 36:28.550] something that very often tends to give us a lot of success in terms of domain privilege escalation. [36:28.550 --> 36:36.390] So a quick note about that, I would recommend not pulling all the tickets at once. As you know, [36:36.390 --> 36:45.030] I learned this the hard way because I pulled all the service tickets at once and that led to a [36:45.030 --> 36:53.650] detection and an alert and an incident and subsequently my foothold was isolated. So an [36:53.650 --> 36:58.150] effective strategy here would be to find the service account set with the earliest password set [36:59.730 --> 37:04.670] so naturally these service accounts have the password last set attribute on their domain [37:04.670 --> 37:12.770] object and that is something you can query. And the great thing about Ruby is that you can now [37:12.770 --> 37:24.030] do that with a flag called stats. So you just need to do rubyist.exe Kerberost slash stats and [37:24.570 --> 37:33.390] it will give you the encryption types as well as the password last set year along with the number [37:33.390 --> 37:40.970] of service accounts that had its password last set in that year. And then once you get this [37:40.970 --> 37:46.790] information what I would do is that I would then start pulling tickets from the oldest to newest [37:47.450 --> 37:55.670] and if the oldest cracks then brilliant. If it doesn't then I move on to the more recent one and [37:55.670 --> 38:08.350] then consequently progress to the more latest password last set dates. So as I mentioned [38:08.350 --> 38:12.290] previously when performing internal network reconnaissance you would want to appear as a [38:12.290 --> 38:18.530] process that frequently makes internal network connections. A good trick here is to replicate [38:18.530 --> 38:26.250] the client's host as a VM as closely as possible and then test all your actions and observe [38:26.250 --> 38:33.110] activity from a blue team's perspective. And you can use Sysmon for this all day because it's free [38:33.110 --> 38:44.850] and you can also use Swift on security's Sysmon config that's available publicly on the GitHub [38:44.850 --> 38:52.250] repository. And by doing so you can then look at the process relationships, the command line [38:52.250 --> 38:58.730] arguments and the network connections that your implant is making and how it's appearing on the [38:58.730 --> 39:08.850] endpoint. You'd also go a long way if you get familiar with some common quote-unquote normal [39:08.850 --> 39:16.590] Windows parent-child process relationships. And Sameer on Twitter posted this very informative [39:16.590 --> 39:24.230] chart with all of these examples which I refer to very often when I want to masquerade as something [39:24.230 --> 39:36.290] legitimate and I strongly recommend that you refer to this chart. All right so offense informs [39:36.290 --> 39:42.390] defense and that is why we want to get better at offense and we want to go from the observable [39:42.970 --> 39:50.950] to the observed. And we want to help the blue team to observe our activity so that they can defend [39:50.950 --> 39:58.230] against threats better. So to detect parent process ID spoofing you would want to start [39:58.230 --> 40:03.850] collecting data from event tracing for Windows. Now event tracing for Windows was actually designed [40:03.850 --> 40:10.130] for debugging and not for security monitoring but that being said it is gaining popularity to [40:10.130 --> 40:16.930] gather granular information about activity performed in the host. So to detect parent [40:16.930 --> 40:23.370] process ID spoofing you'd want to collect the event header process ID via ETW and correlate [40:23.370 --> 40:31.830] with what parent process ID you're seeing of the process. Also parent process ID spoofing [40:31.830 --> 40:35.550] requires creating processes with the extended startup information [40:37.670 --> 40:43.510] and you'd want to monitor your process creation calls which have such information. This point is [40:43.510 --> 40:50.810] referring to the startup info xa struct and that is a necessity if you want to perform [40:50.810 --> 40:56.670] peep and spoofing because only with that struct can you provide the handle [40:56.670 --> 41:04.690] of the process that you want to spoof as your parent. And naturally you'd want to watch out [41:04.690 --> 41:09.630] for false positives because parent process ID spoofing is actually something that UAC [41:11.230 --> 41:16.650] does and this is legitimate behavior. So you're bound to have a few false positives [41:16.650 --> 41:20.950] but as long as you know what you're looking for you should be good to go. [41:22.390 --> 41:31.270] A quick image posted by the good people at F-Secure, this shows the [41:32.390 --> 41:40.770] you can see the event generated by ETW and quite obviously the event header process ID [41:40.770 --> 41:48.490] and the parent process ID are different and the event header process ID shows [41:48.940 --> 41:55.180] the actual parent which is 9224, 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.910] He said that we have this funnel of fidelity when it comes to detection and blue teaming. The idea [42:15.910 --> 42:25.710] here is that the funnel at each stage exists to filter out noise in a calculated way but also [42:25.710 --> 42:33.030] affects the ability of a future step to be successful. So as you can see you may have [42:33.370 --> 42:42.470] a million events in your detection funnel but with all the filters you have in place, be it [42:43.750 --> 42:50.730] filters of technology or a human eye, everything you have in place should [42:52.370 --> 42:59.450] provide output to the very next filter which would take that output as its input. So when [42:59.450 --> 43:06.070] you're triaging you should have a lot fewer alerts that you want to send to the next phase. [43:06.540 --> 43:17.450] This is because investigating 100 alerts or even 100,000 events is fairly infeasible, [43:17.450 --> 43:26.490] no matter how large the organization is. And as Sapti puts it in his talk along with Ross Wolf [43:27.270 --> 43:34.750] called Fantastic Red Teams and How to Find Them, he says that behaviors happen over time and we [43:34.750 --> 43:43.090] need to monitor where the action happens. So, for example, svchost.exe being spawned without [43:43.090 --> 43:53.690] the hyphen k command line parameter is something that's quite obviously suspicious. And svchost.exe [43:53.690 --> 44:00.730] being spawned not as a child of services.exe is also something that you should be looking at [44:01.660 --> 44:09.790] because the normal process relationship of svchost is as a child of services.exe and again [44:09.790 --> 44:16.330] with the command line parameters have hyphen k and the name of the service after that. [44:16.430 --> 44:24.190] So another such odd behavior would be system level processes being spawned by non-system [44:24.190 --> 44:31.030] parents. This usually indicates some level of local privilege escalation wherein your [44:32.490 --> 44:40.630] non-system parent process is generating a system level escalated privilege process. [44:41.050 --> 44:48.710] So the idea would be to locate attempts to blend in and also locate legitimate binaries being [44:48.710 --> 44:57.650] renamed or being replaced and put in a different directory which is not its standard directory. [44:58.370 --> 45:05.530] You would also go a long way if you find processes which are creating network connections [45:06.530 --> 45:11.030] but these processes are part of the living off the land binaries, so [45:11.910 --> 45:21.090] lolbins as you call it. Another great blog post by Gerald revolves around his philosophy of [45:21.090 --> 45:27.470] detecting attacker capabilities. He calls this the concept of capability abstraction. [45:27.930 --> 45:34.430] So the idea here is that an attacker's tools are merely an abstraction of their attack [45:34.430 --> 45:40.270] capabilities and detection engineers must understand how to evaluate abstraction while [45:40.270 --> 45:49.850] building detection logic. So what he means is that when an attacker runs, let's say, [45:49.850 --> 45:59.950] Invoke Kerberost or Rubius or Mimikatz, then these present itself as detection opportunities [45:59.950 --> 46:04.790] at many levels. So first is the managed code itself [46:06.650 --> 46:17.250] and the other is the underlying Win32 API call that is being used and it could also be the RPC [46:17.250 --> 46:24.530] call on the network that you could build your detection off of. And lastly, of course, the [46:24.530 --> 46:35.600] network protocol that you can monitor for suspicious activity. So speaking of Mimikatz, [46:36.720 --> 46:44.340] let's jump to credential harvesting very quickly. So creds are king, naturally. Every red teamer [46:44.340 --> 46:49.360] knows this. Credentials are a red teamer's best friend and when we have tame text passwords, [46:49.360 --> 46:58.720] it opens up multiple doors for us. Without plain text creds, we have other options like hashes and [46:58.720 --> 47:07.760] tickets. But I mean, there's nothing quite like good old text passwords, right? Every red teamer [47:07.760 --> 47:17.400] needs to use some sort of credential harvesting tooling in their red team operations. This is [47:17.400 --> 47:26.000] because in order to achieve our objectives, we do need to steal credentials and make our way [47:26.000 --> 47:31.540] to some level of escalated privileges to complete our objectives. [47:31.960 --> 47:40.660] Now, modern defenses have caught on to this trend and made life harder for real world attackers and [47:40.660 --> 47:46.640] consequently red teamers. But overall, of course, this is a good thing. We want this to be hard [47:46.640 --> 47:54.980] because we don't want it to be easy for the real world bad guys. So certain techniques that [47:55.660 --> 48:02.760] have been used are extensive signatures itself for the credential harvesting tools. [48:03.160 --> 48:11.240] So we now know that Defender does very, very well against Mimikatz. And by Mimikatz, I mean just the [48:11.240 --> 48:18.880] word Mimikatz. You can have the word Mimikatz in a harmless program and it would still be [48:18.880 --> 48:27.060] detected as malicious, which I have no complaints against. It is a good thing because nothing [48:27.060 --> 48:33.220] legitimate comes out of anything called Mimikatz. But this is a strategy that they've chosen to go [48:33.220 --> 48:39.640] with and I respect that. So a few other techniques that we have seen being used are [48:40.080 --> 48:46.640] user-learned API hooking. So specific APIs like read process memory [48:48.400 --> 48:57.700] and sometimes open process on the LSAS process itself have proven to be [48:58.640 --> 49:07.980] suspicious or detectable by certain EDR vendors. And of course, there is protected processes light, [49:07.980 --> 49:13.920] which is an OS level mitigation. Alex Ionescu has a great blog post series on [49:14.540 --> 49:21.120] PPL if you're interested to get into the details and internals. So what is API hooking? [49:21.860 --> 49:30.740] Think of it as a man-in-the-middle attack by the EDR product. As you can see in the image, [49:30.740 --> 49:37.380] main.exe is using the create remote thread API call, but this API call is hooked. So [49:37.380 --> 49:43.100] what actually happens under the hood is that there's a jump instruction that hijacks the [49:43.100 --> 49:51.920] execution flow. And this jump instruction takes the flow of execution to the process space of the [49:51.920 --> 50:03.360] EDR and its DLL. So once it's in the process space of that DLL, it will then perform its checks. [50:03.360 --> 50:08.500] It will look at the function call. It will look at the arguments. It will see if the parameters [50:08.500 --> 50:18.420] are safe. If it's fine, then it decides that execution can resume. If it deems it as suspicious, [50:18.420 --> 50:28.070] it will either generate an alert or outright block it. Certain other techniques that have been [50:28.070 --> 50:38.560] publicly documented are unhooking these useland API hooks using direct syscalls to ntdll.dll. [50:40.640 --> 50:46.130] So what we want to do here is that we want to use the very same hooked API calls, [50:46.130 --> 50:53.450] but we want to use the underlying ntdll function call with the help of syscalls in ASN. [50:53.650 --> 50:59.390] So in order to do this, you first need to resolve the syscalls from ntdll and then jump directly to [50:59.390 --> 51:11.220] the ntdll call. Another alternative that is publicly documented is getting creative with [51:11.220 --> 51:22.280] Win32 APIs. For example, the PSS capture snapshot API. This function takes the snapshot of the process [51:23.300 --> 51:31.500] and what happens is you can then use the mini dump write dump function on the snapshot of Lsas [51:31.500 --> 51:39.800] instead of Lsas itself. So you're essentially creating a copy and performing all your malicious [51:39.800 --> 51:46.740] activity on the copy and not the original. So this tends to evade certain detections that rely on [51:46.740 --> 51:54.420] your getting a handle on Lsas and reading the process memory of Lsas itself. [51:57.390 --> 52:04.510] So in some occasions, you'll also see Lsas running as PPL. This is something that you can [52:05.330 --> 52:08.310] 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:24.950] With run as PPL enabled, your options will be limited to dropping a vulnerable, [52:24.950 --> 52:31.250] preferably signed kernel driver. And this vulnerable kernel driver will allow you to [52:31.250 --> 52:37.810] execute code in kernel space. And this in turn will allow you to load another kernel driver of [52:37.810 --> 52:47.890] your choosing. So something like mimi-drv.sys, which is the kernel driver which is created by the [52:48.610 --> 52:55.030] creator of Mimikatz. And if the vulnerable driver is unsigned, then you would need to use the [52:55.030 --> 53:03.710] driver to first disable driver signing enforcement, then load your driver, and then dump credentials. [53:04.210 --> 53:09.630] There's a lot more to this talk, but it's outside this... there's a lot more to this topic, [53:09.630 --> 53:16.270] I'm sorry. But it's outside the scope of this talk. And the time frame of this talk. [53:16.830 --> 53:24.830] But typically, loading drivers on production environments is deemed risky. And if you want [53:24.830 --> 53:31.350] to do this, then you should request permission beforehand. Because ultimately, we are a red team. [53:31.350 --> 53:38.770] We are not the real adversary. We don't want to cause blue screens of death on production [53:38.770 --> 53:48.670] environments. And as an attacker, of course, the concept of offense in depth is important to us. [53:48.670 --> 53:55.450] Because we need to know different techniques to achieve the same goals. Because if one technique [53:55.450 --> 54:01.890] does not work, or if one technique has been patched, then you should have the knowledge of [54:03.110 --> 54:09.960] different ways to achieve the same result. Which finally brings us to [54:11.480 --> 54:16.520] being a red teamer in 2020 and how this has changed in the past few years. [54:19.410 --> 54:24.510] So, to begin with, the training landscape for red teaming is ever changing. There are [54:24.510 --> 54:32.170] very few courses out there. There are a few good ones, of course. And that number is slowly growing. [54:32.770 --> 54:41.470] But most of the mainstream courses have little or no focus on skills that will enable you to walk [54:41.470 --> 54:51.450] into a red team role. And like pen test roles as well, there's the catch 22 of red team roles [54:51.450 --> 54:57.510] 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:11.770] Well, I would very, very strongly recommend watching Rafael Maggio's Red Team Operations [55:11.770 --> 55:18.270] video series. I mentioned earlier that this is a nine-part video series. It's based on [55:18.270 --> 55:24.390] Cobalt Strike, but it will teach you the fundamentals of red team tradecraft. And [55:24.970 --> 55:30.870] most red team roles will require you to fully understand the ins and outs of Cobalt Strike [55:30.870 --> 55:40.330] anyway, so it's a win-win. The best part is that it's free. And there are two such series that I [55:40.330 --> 55:45.830] strongly recommend. One is the Red Team Operations, as I mentioned, and the other is the In-Memory [55:45.830 --> 55:54.970] Evasion video series, which talks about some of the features that Beacon has recently implemented, [55:54.970 --> 56:04.030] which help with keeping it OPSEC safe in memory. So, once you're familiar with a mature C2 framework, [56:04.330 --> 56:09.410] I would recommend that you build your own from scratch. A very basic one. It doesn't have to be [56:09.410 --> 56:14.910] something sophisticated, but building one yourself will go a long way in helping you understand [56:15.750 --> 56:24.730] the nitty-gritties of implants and C2 frameworks. And Rastamouse has a [56:24.730 --> 56:31.590] very informative video series on the development of Sharp C2 that is currently [56:31.590 --> 56:39.610] ongoing, and I've seen that Rastamouse is very regularly posting videos to this playlist. [56:41.610 --> 56:48.890] I would also strongly recommend reading through Dominic Chell's post on learnings from a decade [56:48.890 --> 56:55.950] of Red Teaming. He talks about what he has learned in an entire decade of Red Teaming, and there's [56:55.950 --> 57:03.990] some very useful insight for someone who's been around for over a decade. And definitely give that [57:03.990 --> 57:11.570] one a read. Also, watch Will Burge's talk on Red Teaming. Sorry, Will, if I butchered your last [57:11.570 --> 57:21.190] name. This is a very informative talk. It pushed the envelope in favor of Red Teams very, very [57:21.190 --> 57:30.650] significantly, and the three pillars of EDR that I kept mentioning throughout the talk are something [57:30.650 --> 57:39.150] that Will's talk has also addressed. Also, you would want to master every attack vector on the [57:39.150 --> 57:47.710] Active Directory. So, for that, there's no better place than going to Harmjoy's blogs and tweets, [57:47.710 --> 57:56.590] and also biotech's tweets, and adsecurity.org, which is a fantastic resource for all things AD [57:56.590 --> 58:05.980] and security. Learn about process injection. You can typically do this for free, because there are [58:05.980 --> 58:12.880] plenty of resources out there, but I have been made aware of a course by Pentester Academy, [58:13.240 --> 58:23.840] and it's being taught by Pavel Yosefovich himself, which is going to be a very promising course, [58:24.480 --> 58:31.460] that's something that I might look at taking up as well. I also want to mention that I'm not [58:31.460 --> 58:39.660] paid to sponsor any of these trainings, or any of these materials. This is an independent and [58:39.660 --> 58:48.440] unbiased recommendation. And lastly, learn how to set up your C2 infra, then automate it for speed [58:48.440 --> 58:54.410] and efficiency. You can use Terraform, Ansible, there are plenty of ways. There's a lot of [58:56.100 --> 59:04.020] DevOps influence on recent C2 infra deployment, and a lot of people have found very innovative [59:04.020 --> 59:09.170] ways to do this. So, keep an eye out, keep reading, never stop learning. [59:12.600 --> 59:17.740] So, a huge shout out to the people who make their research public, and push the envelope [59:17.740 --> 59:27.020] to improve security. This is a short list, and I'm quite confident that there are a lot more [59:27.020 --> 59:35.580] out there who have contributed. And thank you all for all your work, and image credits of the [59:35.580 --> 59:45.000] A12 Archangel and SR71 to the good people at Langley. Right. So, now I'll open the floor [59:45.000 --> 59:51.980] for questions. Please post all your questions on the Discord server. Thank you all once again [59:51.980 --> 59:58.900] for watching my talk. Feel free to reach out to me on Twitter, and have a nice day.