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