start	end	text
1760	5900	Greetings, everybody. Good morning, good afternoon, good evening,
5900	11000	based on wherever you are. Welcome to my talk on modern Red Team Tradecraft.
11380	19580	I'd like to start off by thanking you all for viewing my talk and also a huge thank you to the
19580	26160	brilliant team behind DEF CON Red Team Village for putting together over 200 hours of content
26160	30840	on Red Teaming. So, massive props to Omar and the team.
32220	38460	All right. Quick introduction. I'm a senior consultant at Mandiant. My job involves
38460	45340	simulating an adversary, otherwise known as Red Teaming or Purple Teaming. I also keep a keen eye
45340	52400	out on tradecraft and the tactics, techniques, and procedures used by the most sophisticated
52400	59820	threat actors out there. I'm a first-time DEF CON speaker. So, yay. And you can reach out to
59820	67600	me on Twitter at Sajal underscore Thomas. Most importantly, the opinions in this talk are mine
67600	79290	and not my employer's. Quick disclaimer here. Right. So, the agenda for today is going to be
79390	86550	a range of topics. We're going to cover why help offense to begin with. And then we'll spend some
86550	93470	time on talking about implant design considerations and OPSEC decisions that a Red Team operator
94410	102830	would require to make in order to sufficiently simulate a sophisticated adversary. We'll talk
102830	111510	about how offense informs defense. And there's also a short section on credential harvesting
111510	118450	because, naturally, no Red Team talk is complete without a topic on credential harvesting.
118890	127050	Lastly, we'll cover how someone can get into Red Teaming and also how the modern Red Teamer
127050	136550	needs to evolve and scale up in order to adequately simulate some of the sophisticated
136550	141570	adversaries out there. At the end, we'll open up the floor for questions on the Discord server.
141570	147310	So, please feel free to leave questions during the course of the talk as well as right at the end.
149150	154450	All right. So, the big question is why help offense in the first place? Why spend time
154940	162070	and energy in improving a team that merely serves the purpose of keeping you on your toes?
162490	169070	So, before we get into that, let's quickly rewind the clock to the peak of the Cold War era
169720	175220	to draw some inspiration from clandestine intelligence and counterintelligence operations.
177460	186500	So, what you're looking at is the glorious A-12 reconnaissance plane. This was built by Lockheed
186500	194680	back in the 60s. And the purpose of this plane was to collect intelligence on the ground
194680	201760	by flying through certain sensitive areas. And the main objective of this plane was reconnaissance
201760	211360	and surveillance. And this plane was also known as the Archangel. And also, in declassified
211360	218100	documents, it was called the Oxcart plane. And thanks to all the declassified documents,
218100	224700	we now know a lot more about this plane and about how the United States had to keep it hidden
225130	235620	from the Soviets' spying eyes. So, the Area 51 personnel that was operating on this plane,
235620	243320	and Area 51 was the hangar where the plane was being developed and tested. The personnel there
243320	250140	soon realized that they would need to keep the plane hidden from Soviet spy satellites,
250140	258300	who in return would be capturing images of the plane from up above. So, in order to hide it,
258300	265520	they would quickly scoot it into a building as soon as they would learn that a spy satellite was
266380	277420	about to enter into the Area 51 airspace. And T.D. Barnes, a former hypersonic flight specialist,
277420	283140	used to say that if a plane happened to be out in the open when the satellite was coming over
283140	291660	the horizon, they would quickly scoot it into a building. And he would say that the entire hangar
291660	297220	would look like a parking lot. He said that it would look like, after all the cars have left,
297220	303160	you can still see how many were parked there in infrared because of the difference in the
303160	314760	ground temperatures. So, as you can see, all the A-12 planes parked in the hangar with the shadows
314760	320760	that they left behind on the ground. So, the difference in the temperatures and the heat
320760	326800	signatures on the ground where they were parked were naturally much different to the heat signatures
326800	334840	of the entire hangar. And so, it turned out that even with all the laborious hooting and scooting
334840	341880	of the planes in and out of buildings, the US spies learned that the Soviets had managed to
342340	349000	get their hands on a drawing of the A-12 plane. And they assumed that they got it via the infrared
349000	357500	satellites. So, in order to thwart these infrared satellites, the Area 51 crew began constructing
358040	364560	fake planes out of cardboard and other mundane materials in order to cast misleading shadows
365080	374860	for Soviet spy satellites to keep wandering over. And we also know now that sometimes the hangar
374860	381920	staff would fire up heaters near these imaginary engine locations to make it appear as if the
381920	391880	planes had just landed. And so, as red teamers and as professionals who are trying to simulate
392560	398200	an Apex adversary, what are the lessons here for us? The lessons here are that
399160	407440	every Apex adversary knows which action leaves what trace behind. And by knowing this, by knowing
407440	414220	which signals are exposed to defenders, adversaries can mislead observers in the opposite direction.
414220	422500	So, naturally, if you know that your enemy or your observer is monitoring your heat signatures,
422500	430820	what you can do is throw them off by planting fake heat signatures and confusing them.
431580	438300	So, that was one of the lessons that I gathered from this story. And the other one is that when
438300	445120	stealth becomes a necessity, and on the other hand, if it affects the pace of the operation,
445720	452000	then what do you do? Do you give up stealth and expose yourself? Or do you continue to remain
452000	458240	stealthy but not move in the direction of your objectives? This is a question that
458240	465600	every red team operator has faced or will face at some point in every operation.
466680	472820	But we can conclude that having a formidable adversary to practice against does keep you
472820	479880	on your toes. And knowing every action and every signal that you leave behind
480320	488340	does help you understand how you can improve yourself, and by improving yourself,
488340	492440	how you can improve the blue team, which is the defense.
494460	504660	So, back in 2013, Lockheed Martin announced the SR-72,
505220	513400	which and they announced it with this huge slogan saying speed is the new stealth. And
514360	521660	they said that the plane goes so fast that it's going to be invisible to radars and it's going
521660	529580	to be undetectable in the air. But from a red team operator's point of view, is speed really
529580	539020	the new stealth? Now, there's a line of thought among red team operators that going in and getting
539020	547760	out very quickly is something that's boastworthy. I, myself, am a victim to this. I have boasted
547760	554360	many a times that I got DA on day one and I completed this objective and that objective
554360	566660	within a few days and that was it. But truly, does this impact really help the defense achieve
566660	575320	their goals? Or does this help the defense to get better themselves? Or does spending a lot more
575320	583320	time and remaining undetected demonstrate more impact to the blue team? Now, the defense of tech
584180	591500	has set a new precedent. There's a lot of behavioral analysis and baselining
591500	599600	what is normal on an endpoint, on a network. And what happens is that anything that
600920	607920	goes beyond that normal or anything that comes off as an anomaly immediately generates an alert.
608800	615980	And so, allow me to share a war story of mine where I performed a Kerberos attack and I pulled
615980	622920	30 service account Kerberos TGS tickets within a few seconds. Because that's the default action
622920	627520	when you perform any sort of Kerberos attack straight out of the box. Whether it's via
627520	636400	Rubius or whether you use the PowerShell script, PowerView by picking invoke Kerberos. The default
636400	641520	is that it will just Kerberos every single service ticket that's in the active directory.
642520	650720	So, what happened is that defenders were watching for quantity of requests. And
651460	658960	they were watching that quantity in the given time frame that I generated all those service
659520	665600	ticket requests. And they picked up this anomaly. And unfortunately, that was the end of my foothold
670460	682440	So, this is from the blog by at debugprivilege on Twitter. It's a blog on hunting for tactics,
682440	688520	techniques, and procedures using Azure Sentinel. And what debugprivilege talks about is that
690460	697640	how requesting a huge number of Kerberos service tickets counts as an OPSEC failure. Because
698340	706300	if you were to look at the data from 30 days and establish a baseline of service ticket requests,
706300	712760	I'm sorry, Kerberos service account ticket requests, then you can have a very
714060	724820	informed idea about how many requests or how many Kerberos tickets are requested per user per day.
724820	729600	And then you can set a threshold and anything that goes above that threshold
729600	736540	can just be deemed suspicious. So, to conclude, maybe speed is not the new stealth for Red Team
736540	743760	operations. And maybe boosting about speed may not be the right approach to demonstrate impact.
747300	752700	Okay. So, let's talk about certain Red Team implant design considerations
753740	760980	that will help you achieve your objectives and also simulate a sophisticated adversary. Keep
760980	766260	in mind that we are going to be talking about Red Team implants alone. We are not going to pick
766260	773820	apart any of the implants used by APT actors. Right. So, let's say you want to start from
773820	779600	scratch and you do not want to rely on a commercial or open source tool. What are the few
779600	785340	considerations you'd want to take into account to achieve this goal? So, typically, this would
785340	792860	depend entirely on what kind of adversary you're simulating. If you want to simulate an APT group,
792860	798900	then you would want to focus a lot more on stealth, whereas if you were simulating a criminal
798900	805620	or a ransomware group, then you'd naturally want to spend a lot more time on speed and
805620	811300	you don't spend more time on making your implant
813780	821780	able to infect a lot more variety of hosts. So, you would not want to restrict it to only a
821780	829200	certain operating system, for example, because you want to deploy it at scale. So, some of the
829200	833220	considerations that you would take into account would be to pick a language, to pick a structure
833220	838980	of your toolkit, to pick a strategy to execute your post-exploitation capability, because
838980	849500	you don't want to have your entire implant with all the post-exploitation capability in it. And
849500	855760	we're going to talk about why in the next slide. And for inspiration, the first thing you can do
855760	861360	is to look at the release notes of Cobalt Strike, because there's a lot to learn from the evolution
861360	868960	of Cobalt Strike's beacon in the past few years. So, my personal recommendation would be to write
868960	875260	in C or C++, because this gives you the freedom and flexibility to interact with the native
875260	883460	Windows 32 API, also known as Win32 API. And the structure that you would want to implement would
883460	889600	be to write modular libraries for each post-exploitation capability. So, each capability
889600	896500	should be a separate module. So, if you want to keylog, then your keylogger should be a separate
896500	905460	capability. And that capability should be a separate library. So, not only is this easier
905460	910440	to maintain and upgrade, but there's an object benefit here, like I was mentioning in the previous
910440	919300	slide, that if the keylogging module gets burned, then at least the rest of your modules remain safe.
919300	926180	So, you're not just deploying your implant with all the capabilities in it and injecting it into the
926180	932840	memory of your victim. What you want to do, ideally, is to have separate modules for all your
932840	942960	different capabilities, and then use them as per your need. And you also want to decide
942960	950500	how to approach injecting your capabilities. So, there are two major options here. One is
951320	958860	the fork and run option, which Cobalt Strike uses as well. So, this approach is essentially
959680	968180	creating a sacrificial process and injecting your capability into it, letting it complete,
968180	974360	and then closing the process and killing the process. So, that is one option. The other option
974360	981020	is to inline execute into your own process. So, the process that you're running under,
981700	987760	the process which your implant is running under, you inject your capability into this very same
987760	996840	process, and you let the job complete. Now, there are caveats for both. The fork and run is
996840	1004060	actually a lot less stealthy, and I'll explain why in the next few slides.
1004400	1012160	And the inline execute option is much more stealthy, but it runs the risk of destabilizing
1012160	1019640	your implant process. So, my personal recommendation is that if you have processes,
1019640	1026400	or if you have capabilities that you want to run over a long period of time, then you pick the fork
1026400	1034820	and run option. And if there are smaller capabilities or capabilities that run for a
1034820	1040500	much shorter time frame, then you just inline execute them into your own process.
1040500	1046560	Also, Cobalt Strike has this feature, which is a newly launched feature called
1046560	1054100	the ability to make beacon object files. And I'm not going to get into the details of how that
1054100	1060680	works, but essentially, beacon object files now allow you to inline execute capabilities
1060680	1069940	into your own process instead of the typical fork and run. So, this is a move that promotes stealth,
1069940	1080340	but also, like I mentioned, there are some caveats to that. So, great. So,
1080340	1085100	you're operating in memory, and that's perfect. That's what you want. You don't want to touch
1085100	1090740	disk. All that is great, but that doesn't mean that you will remain undetected. It doesn't mean
1090740	1098640	in memory doesn't mean undetectable. Subty, also known as Casey Smith, once tweeted,
1098640	1105680	and in typical Subty fashion, deleted his tweet about the three pillars of endpoint detection
1105680	1113740	and response, where he said that there are three things that form the pillars of EDR
1113740	1120260	and the three pillars are parent-child process relationships, command line arguments,
1120260	1127020	and network connections made by processes. Now, this makes a lot of sense from an EDR
1127020	1133220	point of view, and from a Red Teamers point of view, if we were to bake these evasions
1134100	1142960	into the implant design, then we can have a sufficiently OPSEC safe and stealthy implant.
1142960	1151120	Now, thanks to Will's talk at Wild West Hacking Fest, we already have the evasions for the first
1151120	1159280	two pillars, and the last one is something we can actually do manually, or we can program that
1159280	1168380	logic into our implant in order to pick processes that are typically known to make network connections
1168380	1175620	and use them if we want to make certain network connections inside the network, or egressing from
1175620	1186060	the network. So, when a process launches, EDR solutions check for anomalies. So, the typical
1186060	1196320	examples include word.exe spawning partial.exe, and then for command line arguments, this is
1196980	1204960	the typical detection for that is looking for suspicious parameters like a partial-execution
1204960	1218980	policy, and proc dump-n lsast.exe, hyphen accept EULA, and the network connections are, of course,
1218980	1224880	fairly straightforward. If you see, if EDR sees explorer.exe making connections to the internet,
1224880	1230820	this is naturally something that's going to come across as suspicious. So,
1230820	1237820	these are some of the ways that EDR performs the very basic detections.
1238300	1246520	Now, let's quickly talk about pair-and-process spoofing. This isn't a new technique. This was
1246520	1256640	blogged by DDR Stevens almost 11 years ago. And, in order to understand how pair-and-process
1256640	1264700	spoofing works, let's first look at the very basics. Let's look at the Win32 API call to
1264700	1274140	create a process. And what this looks like is a function called create process A with certain
1274140	1279660	parameters. And the parameter that we are interested here is
1281720	1293990	the LP startup info A parameter. So, we want to make LP startup info point to an extended startup
1293990	1302750	info struct called startup info XA. The struct startup info XA contains an attribute list called
1302750	1310070	LP attribute list. And the attribute list can be updated using the function update
1310070	1318190	drop thread attribute. So, as you can see, the LP value parameter can specify which process,
1318190	1325650	which pair-and-process you want to choose for the process that you create. So, LP value will be a
1325650	1330550	pointer to the handle to the process which you want to spoof as the parent, as you can see in
1330550	1342130	the image below. And this is proof of concept code from XPN, also known as Adam Chester. You
1342130	1352630	can observe the update drop thread attribute function which takes ampersand P handle as the
1352630	1363390	argument. And that in itself is the handle to an open process call to the specific process ID that
1363390	1371250	we pick. Right. So, the second evasion technique talks about spoofing command line arguments.
1372270	1379110	As I mentioned previously, EDR looks at this quite closely. There are many such examples.
1379110	1388990	I mentioned Procmon, which dumps the LSAS memory. Certain other examples also include
1389830	1398070	WMIC OS get slash format with a web URL pointing to an XSL style sheet, which
1398950	1407290	is also known as squiggly2, which was an attack discovered by Casey Smith a while back. And
1408070	1417310	in order to evade this detection mechanism, what we would do is we would first create a process,
1417310	1422730	suspend its state, change the command line parameters in the memory to something harmless,
1422730	1432910	and then resume the process. But in order to do that, we first need to understand what
1432910	1440190	process environment block is, also known as PEB. Now, a PEB is mapped inside the process's
1440190	1445970	virtual memory. It contains information about the process, such as loaded modules,
1445970	1452370	command line arguments used, and other such information related to the process.
1454270	1459970	And like I mentioned, the few steps involved in this process would be to create a process
1459970	1468810	in the suspended state, and then get the address of the PEB using the NT query information process
1468810	1477790	function call. This is something that tools like Process Hacker also do. And that is how XPN took
1477790	1485850	inspiration in order to do this. And what you do next is you replace the command line
1486770	1492070	arguments stored in the PEB using write process memory, and then you just resume the memory. So,
1492070	1499590	when you see it, when you see the logs, what you'll see is the harmless parameters are logged,
1499590	1507790	and not the ones that you started the process with. So, POC code yet again by Adam Chester.
1508170	1515910	As you can see, the spoof parameters right at the bottom. But you start with reading
1516710	1524630	the PEB from the target process using a reprocess memory call right at the top of the image. And
1524630	1530330	then you get the process parameters from the PEB using reprocess memory yet again,
1530330	1538210	and using the handle to the process. And you replace the suspicious parameters with
1539190	1544390	something harmless using write process memory, and pointing to the PEB.
1547850	1554670	The other interesting feature lets you prevent third-party DLLs from injecting into the
1555130	1566170	process space of your implant. If you will recall, in September 2018, Chrome 69 started this feature
1566170	1571390	where it began blocking third-party software from injecting into the Chrome's process space.
1571390	1580110	They did this to enhance the stability of Chrome. And this feature gave inspiration to Raphael
1580110	1588390	Mudge, creator of CobaltStrike, to bake this into CobaltStrike's payload, which is called Beacon.
1588550	1593930	And for those of you familiar with Beacon, you know that this is something we can achieve by
1593930	1601890	using the block DLLs command. And what block DLLs essentially does under the hood is that
1601890	1607670	it creates a process with an attribute that disallows any third-party DLLs from injecting
1607670	1617750	into the spawn processes. So think fork and run processes of Beacon for its post-exploitation and
1618670	1624670	the block DLLs feature combined with it. So any new process you create in order to inject
1624670	1632470	capability into it, you can also set this feature into it so that it prevents any third-party DLLs
1632470	1637970	from injecting into your sacrificial post-exploitation processes. The caveat here, of
1637970	1645310	course, is that only Microsoft-signed DLLs can inject into these processes. Anything that's not
1645310	1654830	signed by Microsoft cannot. And we can also use arbitrary code guard, which uses a process
1654830	1665660	mitigation policy to achieve similar results. So looking at the code, you'll see the familiar
1665660	1671400	update prop thread attribute function call yet again. What is happening here is that the create
1671400	1677980	process function call is used along with the startup info xa struct, which we talked about
1677980	1686580	earlier. And in this case, this struct contains the mitigation policy which prevents non-Microsoft
1686580	1697930	signed DLLs from being injected. So when you observe this process, you'll see that there's a
1697930	1707030	policy set which will specify signature restricted to Microsoft only.
1709370	1718290	Of course, as everything is sophisticated, the level of sophistication of your activity will
1718290	1728410	give away your intent. If your protected processes are something that are not normal to the environment
1728410	1733310	that you're operating in, then it is going to stick out like a sore thumb. So the best advice
1733310	1738850	here is, of course, to blend in by enumerating the mitigation policies on all the processes that are
1738850	1748780	running, and then act accordingly. So for every APEX adversary, it's very important for you to
1748780	1755800	know your toolkit. And as red teaming advances and becomes more mature, this becomes more and
1755800	1762170	more important. Because knowing what your toolkit does under the hood is absolutely essential.
1763800	1769930	Now, going back to the initial point, every action by an attacker leaves a trace behind.
1770540	1775560	For an attacker to reach a certain level of sophistication, it is crucial to understand
1776410	1783460	each action and its detection risk. This often means, for a red team operator,
1783460	1792360	the fewer processes you create, the stealthier this would be. The image on the right is actually
1792560	1798500	a screenshot of Raphael Mudge's excellent nine-part video series on red team operations.
1799020	1806860	I'm going to touch upon that in the very last section of this talk. But what you see here is
1807510	1815600	every action and every detection risk that is tied to it from a Sysmon perspective. So
1816550	1826160	you can see red is naturally more expensive. And by expensive, we mean risky. And the ones
1826160	1831680	that stick out here are the create remote thread calls, the process create calls, and
1832400	1837100	process access. So process access includes everything from injection
1839060	1846900	to hash dump to running mimikatz. And all the green ones are the relatively safer actions. So
1848200	1852660	file create is a very safe option. It's not something that's going to
1853600	1858600	ring alarm bells all over, because this is something that happens on every endpoint,
1858600	1865860	and you can't possibly have alerts set for that, because you'd have a huge ton of false positives.
1866580	1875540	Process termination is also safe. Time stomping is surprisingly a safe activity.
1879420	1884300	Right. So at every stage of a red team operation, you will be required to make an informed decision
1884300	1892160	about whether your action is going to generate an alert or also get blocked. And based on that,
1892160	1897910	you will then decide how you want to proceed with achieving your objectives.
1904860	1913500	So the caveat here is that actions that are loud aren't necessarily always blocked or caught
1913500	1919680	straight off the bat. And Raphael sums this up very well when he says that observable does not
1919680	1927320	mean observed. So the strategy is to blend in with the legitimate host and network activity.
1927880	1935220	This is something that Raphael terms as session prepping. And what he means by that is
1935960	1942100	that you observe the endpoint and its behavior and merge with it.
1942340	1948840	My personal recommendation is that you may have to change up your session prepping based on the
1948840	1953840	kind of activity you want to perform or the kind of post-exploitation capability that you want to
1953840	1962760	perform. And to give you an example, for something like network reconnaissance,
1962760	1968400	you will want to appear as a process that frequently makes a lot of network connections
1968400	1976420	internally. So here what I would do is I would try to observe every single process that's
1976420	1981040	making internal network connections and try to masquerade as one of them.
1982360	1988280	And also bypassing the three pillars of EDR will only help your initial foothold,
1988280	1995060	they'll only get you so far. What you do after that, whether you stay hidden, is entirely
1995060	2002600	on the operator. Disabling logging instrumentation is also something that's gaining
2003480	2010660	a fair amount of popularity these days. It's not something that a third party red team
2010660	2016620	typically does. Why is that? It's because you're testing your customer's blue team at the end of
2016620	2025200	the day. And if they agree to disabling login, then naturally we have a few
2025200	2032460	options in terms of some of the new ETW bypasses that have come to light and some of the Sysmon
2032460	2039640	evasions and unloading of Sysmon that have been blogged about in the past few years.
2039820	2045680	So these are some of the options we have. But again, this is not something we typically do on
2045680	2055280	red team engagements. So coming back to the point about blending in, your first step should always
2055280	2061140	be to enumerate the running processes and their parent-child relationships. Once you have a decent
2061140	2068080	idea of what's running, you pick a parent and a child relationship of a process that you want
2068080	2075400	to masquerade as, and you configure it on your implant. So this is something that you should
2075400	2081200	have the option to do on the fly and not something that you have to hard code and just stick with for
2081200	2088400	the rest of the engagement. Because like I said, this is something that you may want to change
2088400	2095500	based on the activity that you perform. Some common examples that you will see on the endpoints will
2095500	2104200	be a browser parent process. Now, Internet Explorer used to have it with one parent process
2104840	2111460	called iExplore.exe, and then all the tabs that you subsequently open would also show up as child
2111460	2118720	processes of that one parent process, iExplore.exe. There are other such examples. One of them is
2118720	2128280	jusced.exe and juscheck.exe. These are the the Java updater parent-child processes,
2128840	2137260	and both of these are good options in order to blend in because they typically make network
2137260	2146470	connections to the internet. So like I was mentioning, Internet Explorer running on an
2146470	2150030	endpoint would look something like this, where there's one parent process and then
2150530	2156790	the tabs that are opened show up as child processes of iExplore.exe.
2159990	2166550	Another quick note about Ruby is, when you're performing Kerberost... I'm sorry, not a note
2166550	2173030	about Ruby, but about Kerberosting in general, this is something that I'm going to bring up
2173030	2180050	once again when we talk about how offense informs defense, because it's, like I mentioned, it's
2180050	2188550	something that very often tends to give us a lot of success in terms of domain privilege escalation.
2188550	2196390	So a quick note about that, I would recommend not pulling all the tickets at once. As you know,
2196390	2205030	I learned this the hard way because I pulled all the service tickets at once and that led to a
2205030	2213650	detection and an alert and an incident and subsequently my foothold was isolated. So an
2213650	2218150	effective strategy here would be to find the service account set with the earliest password set
2219730	2224670	so naturally these service accounts have the password last set attribute on their domain
2224670	2232770	object and that is something you can query. And the great thing about Ruby is that you can now
2232770	2244030	do that with a flag called stats. So you just need to do rubyist.exe Kerberost slash stats and
2244570	2253390	it will give you the encryption types as well as the password last set year along with the number
2253390	2260970	of service accounts that had its password last set in that year. And then once you get this
2260970	2266790	information what I would do is that I would then start pulling tickets from the oldest to newest
2267450	2275670	and if the oldest cracks then brilliant. If it doesn't then I move on to the more recent one and
2275670	2288350	then consequently progress to the more latest password last set dates. So as I mentioned
2288350	2292290	previously when performing internal network reconnaissance you would want to appear as a
2292290	2298530	process that frequently makes internal network connections. A good trick here is to replicate
2298530	2306250	the client's host as a VM as closely as possible and then test all your actions and observe
2306250	2313110	activity from a blue team's perspective. And you can use Sysmon for this all day because it's free
2313110	2324850	and you can also use Swift on security's Sysmon config that's available publicly on the GitHub
2324850	2332250	repository. And by doing so you can then look at the process relationships, the command line
2332250	2338730	arguments and the network connections that your implant is making and how it's appearing on the
2338730	2348850	endpoint. You'd also go a long way if you get familiar with some common quote-unquote normal
2348850	2356590	Windows parent-child process relationships. And Sameer on Twitter posted this very informative
2356590	2364230	chart with all of these examples which I refer to very often when I want to masquerade as something
2364230	2376290	legitimate and I strongly recommend that you refer to this chart. All right so offense informs
2376290	2382390	defense and that is why we want to get better at offense and we want to go from the observable
2382970	2390950	to the observed. And we want to help the blue team to observe our activity so that they can defend
2390950	2398230	against threats better. So to detect parent process ID spoofing you would want to start
2398230	2403850	collecting data from event tracing for Windows. Now event tracing for Windows was actually designed
2403850	2410130	for debugging and not for security monitoring but that being said it is gaining popularity to
2410130	2416930	gather granular information about activity performed in the host. So to detect parent
2416930	2423370	process ID spoofing you'd want to collect the event header process ID via ETW and correlate
2423370	2431830	with what parent process ID you're seeing of the process. Also parent process ID spoofing
2431830	2435550	requires creating processes with the extended startup information
2437670	2443510	and you'd want to monitor your process creation calls which have such information. This point is
2443510	2450810	referring to the startup info xa struct and that is a necessity if you want to perform
2450810	2456670	peep and spoofing because only with that struct can you provide the handle
2456670	2464690	of the process that you want to spoof as your parent. And naturally you'd want to watch out
2464690	2469630	for false positives because parent process ID spoofing is actually something that UAC
2471230	2476650	does and this is legitimate behavior. So you're bound to have a few false positives
2476650	2480950	but as long as you know what you're looking for you should be good to go.
2482390	2491270	A quick image posted by the good people at F-Secure, this shows the
2492390	2500770	you can see the event generated by ETW and quite obviously the event header process ID
2500770	2508490	and the parent process ID are different and the event header process ID shows
2508940	2515180	the actual parent which is 9224, process ID 9224.
2517200	2526190	I also want to talk about a concept that Jared Atkinson of SpectreOps talked about in his blog.
2527440	2535910	He said that we have this funnel of fidelity when it comes to detection and blue teaming. The idea
2535910	2545710	here is that the funnel at each stage exists to filter out noise in a calculated way but also
2545710	2553030	affects the ability of a future step to be successful. So as you can see you may have
2553370	2562470	a million events in your detection funnel but with all the filters you have in place, be it
2563750	2570730	filters of technology or a human eye, everything you have in place should
2572370	2579450	provide output to the very next filter which would take that output as its input. So when
2579450	2586070	you're triaging you should have a lot fewer alerts that you want to send to the next phase.
2586540	2597450	This is because investigating 100 alerts or even 100,000 events is fairly infeasible,
2597450	2606490	no matter how large the organization is. And as Sapti puts it in his talk along with Ross Wolf
2607270	2614750	called Fantastic Red Teams and How to Find Them, he says that behaviors happen over time and we
2614750	2623090	need to monitor where the action happens. So, for example, svchost.exe being spawned without
2623090	2633690	the hyphen k command line parameter is something that's quite obviously suspicious. And svchost.exe
2633690	2640730	being spawned not as a child of services.exe is also something that you should be looking at
2641660	2649790	because the normal process relationship of svchost is as a child of services.exe and again
2649790	2656330	with the command line parameters have hyphen k and the name of the service after that.
2656430	2664190	So another such odd behavior would be system level processes being spawned by non-system
2664190	2671030	parents. This usually indicates some level of local privilege escalation wherein your
2672490	2680630	non-system parent process is generating a system level escalated privilege process.
2681050	2688710	So the idea would be to locate attempts to blend in and also locate legitimate binaries being
2688710	2697650	renamed or being replaced and put in a different directory which is not its standard directory.
2698370	2705530	You would also go a long way if you find processes which are creating network connections
2706530	2711030	but these processes are part of the living off the land binaries, so
2711910	2721090	lolbins as you call it. Another great blog post by Gerald revolves around his philosophy of
2721090	2727470	detecting attacker capabilities. He calls this the concept of capability abstraction.
2727930	2734430	So the idea here is that an attacker's tools are merely an abstraction of their attack
2734430	2740270	capabilities and detection engineers must understand how to evaluate abstraction while
2740270	2749850	building detection logic. So what he means is that when an attacker runs, let's say,
2749850	2759950	Invoke Kerberost or Rubius or Mimikatz, then these present itself as detection opportunities
2759950	2764790	at many levels. So first is the managed code itself
2766650	2777250	and the other is the underlying Win32 API call that is being used and it could also be the RPC
2777250	2784530	call on the network that you could build your detection off of. And lastly, of course, the
2784530	2795600	network protocol that you can monitor for suspicious activity. So speaking of Mimikatz,
2796720	2804340	let's jump to credential harvesting very quickly. So creds are king, naturally. Every red teamer
2804340	2809360	knows this. Credentials are a red teamer's best friend and when we have tame text passwords,
2809360	2818720	it opens up multiple doors for us. Without plain text creds, we have other options like hashes and
2818720	2827760	tickets. But I mean, there's nothing quite like good old text passwords, right? Every red teamer
2827760	2837400	needs to use some sort of credential harvesting tooling in their red team operations. This is
2837400	2846000	because in order to achieve our objectives, we do need to steal credentials and make our way
2846000	2851540	to some level of escalated privileges to complete our objectives.
2851960	2860660	Now, modern defenses have caught on to this trend and made life harder for real world attackers and
2860660	2866640	consequently red teamers. But overall, of course, this is a good thing. We want this to be hard
2866640	2874980	because we don't want it to be easy for the real world bad guys. So certain techniques that
2875660	2882760	have been used are extensive signatures itself for the credential harvesting tools.
2883160	2891240	So we now know that Defender does very, very well against Mimikatz. And by Mimikatz, I mean just the
2891240	2898880	word Mimikatz. You can have the word Mimikatz in a harmless program and it would still be
2898880	2907060	detected as malicious, which I have no complaints against. It is a good thing because nothing
2907060	2913220	legitimate comes out of anything called Mimikatz. But this is a strategy that they've chosen to go
2913220	2919640	with and I respect that. So a few other techniques that we have seen being used are
2920080	2926640	user-learned API hooking. So specific APIs like read process memory
2928400	2937700	and sometimes open process on the LSAS process itself have proven to be
2938640	2947980	suspicious or detectable by certain EDR vendors. And of course, there is protected processes light,
2947980	2953920	which is an OS level mitigation. Alex Ionescu has a great blog post series on
2954540	2961120	PPL if you're interested to get into the details and internals. So what is API hooking?
2961860	2970740	Think of it as a man-in-the-middle attack by the EDR product. As you can see in the image,
2970740	2977380	main.exe is using the create remote thread API call, but this API call is hooked. So
2977380	2983100	what actually happens under the hood is that there's a jump instruction that hijacks the
2983100	2991920	execution flow. And this jump instruction takes the flow of execution to the process space of the
2991920	3003360	EDR and its DLL. So once it's in the process space of that DLL, it will then perform its checks.
3003360	3008500	It will look at the function call. It will look at the arguments. It will see if the parameters
3008500	3018420	are safe. If it's fine, then it decides that execution can resume. If it deems it as suspicious,
3018420	3028070	it will either generate an alert or outright block it. Certain other techniques that have been
3028070	3038560	publicly documented are unhooking these useland API hooks using direct syscalls to ntdll.dll.
3040640	3046130	So what we want to do here is that we want to use the very same hooked API calls,
3046130	3053450	but we want to use the underlying ntdll function call with the help of syscalls in ASN.
3053650	3059390	So in order to do this, you first need to resolve the syscalls from ntdll and then jump directly to
3059390	3071220	the ntdll call. Another alternative that is publicly documented is getting creative with
3071220	3082280	Win32 APIs. For example, the PSS capture snapshot API. This function takes the snapshot of the process
3083300	3091500	and what happens is you can then use the mini dump write dump function on the snapshot of Lsas
3091500	3099800	instead of Lsas itself. So you're essentially creating a copy and performing all your malicious
3099800	3106740	activity on the copy and not the original. So this tends to evade certain detections that rely on
3106740	3114420	your getting a handle on Lsas and reading the process memory of Lsas itself.
3117390	3124510	So in some occasions, you'll also see Lsas running as PPL. This is something that you can
3125330	3128310	observe from the registry key.
3130030	3134590	And this registry key is run as PPL, as you can see in the image.
3136170	3144950	With run as PPL enabled, your options will be limited to dropping a vulnerable,
3144950	3151250	preferably signed kernel driver. And this vulnerable kernel driver will allow you to
3151250	3157810	execute code in kernel space. And this in turn will allow you to load another kernel driver of
3157810	3167890	your choosing. So something like mimi-drv.sys, which is the kernel driver which is created by the
3168610	3175030	creator of Mimikatz. And if the vulnerable driver is unsigned, then you would need to use the
3175030	3183710	driver to first disable driver signing enforcement, then load your driver, and then dump credentials.
3184210	3189630	There's a lot more to this talk, but it's outside this... there's a lot more to this topic,
3189630	3196270	I'm sorry. But it's outside the scope of this talk. And the time frame of this talk.
3196830	3204830	But typically, loading drivers on production environments is deemed risky. And if you want
3204830	3211350	to do this, then you should request permission beforehand. Because ultimately, we are a red team.
3211350	3218770	We are not the real adversary. We don't want to cause blue screens of death on production
3218770	3228670	environments. And as an attacker, of course, the concept of offense in depth is important to us.
3228670	3235450	Because we need to know different techniques to achieve the same goals. Because if one technique
3235450	3241890	does not work, or if one technique has been patched, then you should have the knowledge of
3243110	3249960	different ways to achieve the same result. Which finally brings us to
3251480	3256520	being a red teamer in 2020 and how this has changed in the past few years.
3259410	3264510	So, to begin with, the training landscape for red teaming is ever changing. There are
3264510	3272170	very few courses out there. There are a few good ones, of course. And that number is slowly growing.
3272770	3281470	But most of the mainstream courses have little or no focus on skills that will enable you to walk
3281470	3291450	into a red team role. And like pen test roles as well, there's the catch 22 of red team roles
3291450	3297510	requiring experience and you needing a job in order to get experience in the first place.
3298190	3304330	So, what is the best advice I would give to myself if I had to do it all over again?
3304330	3311770	Well, I would very, very strongly recommend watching Rafael Maggio's Red Team Operations
3311770	3318270	video series. I mentioned earlier that this is a nine-part video series. It's based on
3318270	3324390	Cobalt Strike, but it will teach you the fundamentals of red team tradecraft. And
3324970	3330870	most red team roles will require you to fully understand the ins and outs of Cobalt Strike
3330870	3340330	anyway, so it's a win-win. The best part is that it's free. And there are two such series that I
3340330	3345830	strongly recommend. One is the Red Team Operations, as I mentioned, and the other is the In-Memory
3345830	3354970	Evasion video series, which talks about some of the features that Beacon has recently implemented,
3354970	3364030	which help with keeping it OPSEC safe in memory. So, once you're familiar with a mature C2 framework,
3364330	3369410	I would recommend that you build your own from scratch. A very basic one. It doesn't have to be
3369410	3374910	something sophisticated, but building one yourself will go a long way in helping you understand
3375750	3384730	the nitty-gritties of implants and C2 frameworks. And Rastamouse has a
3384730	3391590	very informative video series on the development of Sharp C2 that is currently
3391590	3399610	ongoing, and I've seen that Rastamouse is very regularly posting videos to this playlist.
3401610	3408890	I would also strongly recommend reading through Dominic Chell's post on learnings from a decade
3408890	3415950	of Red Teaming. He talks about what he has learned in an entire decade of Red Teaming, and there's
3415950	3423990	some very useful insight for someone who's been around for over a decade. And definitely give that
3423990	3431570	one a read. Also, watch Will Burge's talk on Red Teaming. Sorry, Will, if I butchered your last
3431570	3441190	name. This is a very informative talk. It pushed the envelope in favor of Red Teams very, very
3441190	3450650	significantly, and the three pillars of EDR that I kept mentioning throughout the talk are something
3450650	3459150	that Will's talk has also addressed. Also, you would want to master every attack vector on the
3459150	3467710	Active Directory. So, for that, there's no better place than going to Harmjoy's blogs and tweets,
3467710	3476590	and also biotech's tweets, and adsecurity.org, which is a fantastic resource for all things AD
3476590	3485980	and security. Learn about process injection. You can typically do this for free, because there are
3485980	3492880	plenty of resources out there, but I have been made aware of a course by Pentester Academy,
3493240	3503840	and it's being taught by Pavel Yosefovich himself, which is going to be a very promising course,
3504480	3511460	that's something that I might look at taking up as well. I also want to mention that I'm not
3511460	3519660	paid to sponsor any of these trainings, or any of these materials. This is an independent and
3519660	3528440	unbiased recommendation. And lastly, learn how to set up your C2 infra, then automate it for speed
3528440	3534410	and efficiency. You can use Terraform, Ansible, there are plenty of ways. There's a lot of
3536100	3544020	DevOps influence on recent C2 infra deployment, and a lot of people have found very innovative
3544020	3549170	ways to do this. So, keep an eye out, keep reading, never stop learning.
3552600	3557740	So, a huge shout out to the people who make their research public, and push the envelope
3557740	3567020	to improve security. This is a short list, and I'm quite confident that there are a lot more
3567020	3575580	out there who have contributed. And thank you all for all your work, and image credits of the
3575580	3585000	A12 Archangel and SR71 to the good people at Langley. Right. So, now I'll open the floor
3585000	3591980	for questions. Please post all your questions on the Discord server. Thank you all once again
3591980	3598900	for watching my talk. Feel free to reach out to me on Twitter, and have a nice day.