Adversary Village - Operation Bypass Catch My Payload If You Can
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 84 | |
| Author | ||
| License | CC Attribution 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/54347 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
Service (economics)SimulationSoftware frameworkOpen sourceProxy serverFocus (optics)Coma BerenicesRSA (algorithm)Control flowSource codePoint (geometry)State of matterNumeral (linguistics)Software frameworkLevel (video gaming)Information securityProfil (magazine)Price indexComa BerenicesType theoryGame controllerOpen sourceOperator (mathematics)Computer wormData managementReal numberProxy serverServer (computing)
01:26
Video gameCycle (graph theory)Kernel (computing)Event horizonInterior (topology)Process (computing)InjektivitätCodeGUI widgetDependent and independent variablesSource codeProduct (business)ChainMechanism designEncryptionDiagramDependent and independent variablesTerm (mathematics)Video gameCycle (graph theory)Link (knot theory)Goodness of fitData miningBitProjective planeExterior algebraNatural numberSystem administratorBlock (periodic table)Computer-assisted translationGame theoryDifferent (Kate Ryan album)Phase transitionOrder (biology)Mechanism designCuboidSeries (mathematics)Combinational logicVirtual machineMultiplication signPhysical systemSinc functionWindowSoftwareLine (geometry)Normal (geometry)Digital photographySign (mathematics)ThumbnailPatch (Unix)Machine learningKernel (computing)Gastropod shellCodePoint (geometry)Process (computing)FlagSystem callEvent horizonElectronic signatureInjektivitätIntegrated development environmentInformationChainType theoryRule of inferencePower (physics)Game controllerHash functionLevel (video gaming)1 (number)Product (business)Structural loadElectronic mailing listCartesian coordinate systemBootingDeterminantWalther-Meissner-Institut für Tieftemperaturforschung
08:08
ChainMechanism designEncryptionRead-only memoryRadical (chemistry)Event horizonProcess (computing)Pressure volume diagramElectronic signatureBinary fileInternetworkingComputer fileGUI widgetOperator (mathematics)Fisher's exact testFinite element methodScripting languageAdditionGastropod shellWeb 2.0Price indexComputer fileEncryptionPosition operatorMultiplication signDataflowRight angleCharacteristic polynomialData streamRadical (chemistry)Black box1 (number)Product (business)Point (geometry)Decision theoryScripting languageFlow separationUniform resource locatorProxy serverIntegrated development environmentBitBinary fileRule of inferenceMechanism designUniverse (mathematics)Video gameOperator (mathematics)ChainInformationGame controllerAreaAntivirus softwareBlock (periodic table)Type theoryBinary codeInformation securityProcess (computing)Semiconductor memoryString (computer science)Event horizonEmailSystem callHydraulic jumpFile formatGastropod shellCodeBootingCuboidConnected spaceInteractive televisionSimulation
14:26
Network topologyPressure volume diagramEvent horizonCoefficient of determinationInformationGastropod shellPower (physics)EncryptionSubstitute goodFluid staticsString (computer science)Rule of inferenceBootingIntegrated development environmentBinary fileComputer fileAttribute grammarMetadataMiniDiscProcess (computing)Structural loadRead-only memoryGUI widgetInformationNetwork topologyMiniDiscEvent horizonBinary codePoint (geometry)String (computer science)CodeComputer fileMetadataAttribute grammarPrice indexGame controllerIntegrated development environmentProduct (business)Coma BerenicesEnterprise architectureType theoryBootingSemiconductor memoryProcess (computing)Functional (mathematics)InjektivitätGastropod shellBlock (periodic table)System administratorDecision theoryMalwareBuildingChainCausalityMeasurementNeuroinformatikInsertion lossLaptopSystem callMobile appStructural loadProcedural programmingBitGroup actionComputer programming1 (number)Form (programming)Latent heatClient (computing)Limit (category theory)CuboidWordRule of inferenceServer (computing)Power (physics)Formal languageEncryptionState observerAdvanced Encryption StandardStreaming mediaPerspective (visual)Multiplication signDifferent (Kate Ryan album)Operator (mathematics)QuicksortLine (geometry)Combinational logicProper mapRegulärer Ausdruck <Textverarbeitung>WindowPhysical systemMereology
22:55
System callPatch (Unix)CodeAttribute grammarData typeBootingComa BerenicesStructural loadBinary fileControl flowPlug-in (computing)Process (computing)Function (mathematics)Extension (kinesiology)Read-only memoryDependent and independent variablesProduct (business)CurvatureProxy serverSingle-precision floating-point formatDefault (computer science)GUI widgetTime domainFlagMacro (computer science)Object (grammar)Recursive descent parserSerial portGame controllerSoftwareSign (mathematics)Enterprise architectureDefault (computer science)Module (mathematics)Line (geometry)Validity (statistics)PasswordProxy serverArithmetic meanMultiplication signStructural load1 (number)Scripting languageCellular automatonDomain nameSampling (statistics)Computer configurationSemiconductor memory2 (number)MiniDiscSoftware frameworkKernel (computing)Product (business)Keyboard shortcutGroup actionClient (computing)Different (Kate Ryan album)WindowBit rateBinary fileFluidDomain nameCodeBootingBinary codeType theoryPlug-in (computing)FlagGastropod shellComputer fileAttribute grammarProcess (computing)WordRecursive descent parserIntegrated development environmentPhysical systemAdvanced Encryption StandardFile formatObject (grammar)InformationInformation securityElectronic signatureBookmark (World Wide Web)Macro (computer science)Coma BerenicesHookingExploit (computer security)Stack (abstract data type)
31:25
BootingProxy serverSerial portTime domainMaizeCodeGastropod shellPhysical systemBootingProcess (computing)Price indexComputer animation
32:04
Electronic signatureReal numberDirect numerical simulationInternetworkingString (computer science)EmailComputer configurationUniqueness quantificationResource allocationProcess (computing)Content delivery networkPublic key certificatePrice indexProfil (magazine)InternetworkingDifferent (Kate Ryan album)String (computer science)Formal languageWindowPoint (geometry)Source codeGraphical user interfaceProcess (computing)Direct numerical simulationElectronic signatureComputer wormComputer fileGastropod shellCodeSemiconductor memoryComa BerenicesStandard deviationMedical imagingInjektivitätInheritance (object-oriented programming)Public key certificateTheory of relativityComputer configurationLevel (video gaming)Normal (geometry)Type theoryRight angleUniform resource locatorSoftware developerElectronic mailing listEmailPhysical systemState of matterRandomizationResource allocationServer (computing)Procedural programmingMultiplication signReading (process)Computer-assisted translationGame theorySlide ruleMacro (computer science)FreewareTwitterDecision theoryThread (computing)Flow separationContent delivery networkOverhead (computing)BuildingSoftware frameworkBookmark (World Wide Web)Integrated development environmentError messageGroup actionTemplate (C++)Game controllerTouchscreenProduct (business)ResultantSimulationTransformation (genetics)MalwareStack (abstract data type)Entropie <Informationstheorie>System on a chip
Transcript: English(auto-generated)
00:00
Hello, and welcome to my talk, Operation Bypass, catch my payload if you can. My name is Matthew Utterberg. I'm a technical manager in Optiv. Under the adversarial services, I am primarily a lead there. My role is focusing primarily on red teaming, purple teaming, basically any type of adversarial real nation state based attacks.
00:23
I've also authored numerous open source tools and frameworks. A lot of the research I've done has been focused on evasion, bypasses, and as well as circumventing EDR and other endpoint based controls and security. I'm a Microsoft Hall of Famer related to several disclosed Microsoft com bypasses, and I've spoken
00:44
at numerous places, including DEFCON, Red Team Village, Derby Con, B-Sides Las Vegas, VeraCon, RSA. So just a brief overview of the agenda that we're going to cover today. First, we're going to understand the level of detection and look at some opposite considerations and understand some TTPs for the modern era.
01:04
Then we'll focus in on using Scarecrow, a framework for bypassing endpoint detection tools. And then kind of drilling more into the indicators of compromise that can lead to a detection or any type of artifacts when we're talking about command and control services. And then introduce a new tool to help with those C2 profiles.
01:27
So to begin, I mean, this is a fairly common diagram to kind of depict the red team life cycle. Primarily, we're really going to focus in today once again on the C2 and all the aspects of it, from establishing
01:41
that presence to making sure you don't get detected and to your long term longevity that leads into eventually post tech techniques. But first, let's kind of define endpoint detection and response tools. How do they actually detect us and subsequently prevent our attacks?
02:01
Well, they primarily rely on a series of different combinations these days. User land hooking being the most common, kernel callbacks using ETW events, or the moniker of machine learning AI, which I use that in quotes because a lot of times when we get down to it, it's usually a signature base or a combination of the three with something else in the background.
02:24
Not to dispute that there is any value to machine learning AI, which is oftentimes when we see this as a tool to prevent threats, it's usually something that is really not selling the whole truth. And so there are a lot of misconceptions to it.
02:43
So with that in mind, how do we get around it? Well, the most common things have been process injection. But with more recent events in the modern landscape, going to things such as using custom system calls, using a technique called block DLLs, which we'll kind of go into in a little bit.
03:01
But also more and more undocumented API calls. Now, I've kind of posted a link here for a good buddy of mine. He does an amazing bit of research, and he has a great project called Alternative Shell Code Exec. This really focuses on using alternative API calls and kernel callbacks to basically execute shell code that are not in the normal way.
03:26
And this kind of by nature allows us to circumvent the normal detections and therefore establish a presence without being detected because these are alternative ways. So EDRs and other tools are often not looking for these as a point to see if malicious activity is being used.
03:46
So block DLLs, this has been a very common and a great technique. This is essentially a technique where you can set your process to have a flag. And this flag says, hey, only allow Microsoft signed DLLs.
04:00
Which means that only system level DLLs such as NT DLL, kernel 32, these ones, they're all the only ones that are allowed to be loaded into our process. Which means, frankly, that any type of EDR product can't load their DLL into our process to then subsequently detect our activity.
04:22
So their response to our attacks, they've started getting their DLL signed by Microsoft CA. So this is a very effective way. So that allows them to basically still load in even with that flag. Deploying as a feature whitelisting controls.
04:40
Rather than the traditional blacklisting, but whitelisting where you block everything and only limit certain applications has been very effective as binary based attacks no longer work. These whitelisting rules are often using hashes. So it's really hard to imitate a legitimate hash, say, of CMD with your implant.
05:04
And other kind of controls, XDR. This is just endpoints detection tools, way of gathering telemetry from different aspects rather than just the endpoint. But looking at the network behavioral traffic, what's egressing, and activity between the host to determine baseline of malicious or suspicious activities such as WMI exact calls.
05:24
Or anything along the lines that would lead to techniques that an attacker would do or things that are out of the norm for that user. Really heavily emphasizing the baselining of activity. So, our response to their response.
05:42
So, one of the things that I kind of preach is with this data edge of more and more people having their EDR DLL signed by Microsoft is just to avoid blocked DLLs as a whole. Especially for initial footle, but also for post-x techniques. There are a lot of great techniques right now coming out of there as a replacement.
06:04
But this really kind of helps prevent us from kind of being detected as this flag of my only sign Microsoft DLLs isn't really standard across a lot of processes. And when we're talking about trying to blend in, that flag itself can sometimes stick out as a sore thumb.
06:21
Therefore, kind of drawing more attention to our process than we actually wanted. With regards to whitelisting controls, we'll kind of talk a lot more about this. But avoiding using process injection in favor of a technique called sideloading. We're going to get into that in a little bit.
06:40
But with regards to XDR controls, this is really where some of the interesting stuff about blocking or in-memory patching of ETW events. Since ETW and other things like that aren't organically built into the Windows environment, how these things work is when they're actually running. They actually have to basically start enabling the traffic and stuff.
07:04
So there's no additional resources that are loaded. So by patching and terminating or tampering with them, they don't send the right information. Therefore, these controls don't really work. And so this really comes down to the cat and mouse game and how do we get better. And really, at the end of the day, it really has to come down to how are we getting that alert?
07:26
How are our teams seeing us? And it's sometimes not always the shellcode or the implant's fault. There is a lot of different phases that get to the point of that shellcode running that can often be the catalyst for the trigger. And we really need to understand this chain of events in order to identify where we need to improve in our tradecraft.
07:48
So when we look at this, the example or definition I like to run by is there's the delivery, the loader, and the implant. The delivery is the mechanism that you're going to get your loader onto the box. Most commonly, things like MSHTA, BITS admin, anything that allows you to download
08:05
or pull from a remote or local resource, your code onto the desktop. So that's one area. The second area is the loader itself. So whether it be a binary, a DLL, a JScript file, what have you. This is the file that contains your implant as well as whatever techniques you're going to introduce.
08:25
Whether it be anti-SAM boxing, anything for unhooking DLLs, or like a decryption technique. These are the things that happen inside this process before your actual implant will run. I like to define the implant as the shellcode, or in COBOL strikes, it's the reflective DLL that runs in memory.
08:43
And that essentially is responsible for establishing that remote connection out. So once we have these three things defined, we need to understand what's detecting us. So I like to break it down into two things. Behavioral, which is really coming down to EDRs.
09:01
So EDRs really like to focus in on that behavioral indicators. I have the example up here of Y is Excel spawning CMD.EXE. That's a behavioral thing. But there's also signatureizing. As great as we look at it, signatureized base, such as the historical antivirus agents, that still comes into play when they're detecting things like large block strings of base64 or shellcode.
09:27
But what is the harder thing to understand, and often is the more common reason that leads to an event, is actually coming from something like a human interaction, a SIM, or some kind of stock tool that's monitoring for events.
09:41
This can be something like files being dropped in a location, such as temp, and then a process spawning from a weird location to something even more abnormal, such as an alert that says, hey, we're seeing a lot of egress to a new destination. And tracing it back, this is a conference room PC, so why is it calling out at 3 in the morning?
10:02
These are all taken from real-life red team operations, where there has been some kind of generated alert. And the lessons here are really kind of, some of them are really simple, tell more of a convincing story. But of them are more technical that you have to apply more advanced techniques to basically bypass that technical control.
10:25
So the detection, these are the most common gotchas that I mentioned. I like to break them down to kind of four things to really focus in on when I'm developing an attack. What is the command I'm executing? So obviously, these days, things like PowerShell or bits admin, they're very highly indicated.
10:45
There has been a lot of research. They're a very prominent LOL bin. So by focusing and using that, there's a high chance that there is some kind of rule or type of mechanism out there that's looking for the execution of it. Now, there are a couple of things you can do to kind of obfuscate that,
11:02
and that's really where you have to understand what you're going up against, as well as being mindful of the file type. Obviously, if you're downloading from some random location, a binary is just straight. There are going to be things that I pass this through, web proxies and external control, and they can see it, this large data stream.
11:22
And binaries have a universal header, so it's easy to detect that. So these are all things you have to be mindful of when you're setting up this attack chain. Also for abnormal behavior, this one is a little harder to kind of discern, but what I like to say is that if you're going to start using commands, LOL bins,
11:41
you have to understand who are you. Are you someone that is a standard user? Is your user someone that would probably use this? And if a security team was looking at it, they wouldn't bat an eye. So it's really about blending in and telling that story. And finally, whitelisting controls. So when I talk about whitelisting controls, we have to really understand what's there.
12:05
Oftentimes, you can have the greatest attack chain ever, but if they block your ability to run something, you'll never know it. And especially in a black box situation, the beacon may not come home, your implant, your C2 essentially won't fire, and you don't know if that detection is.
12:21
So if I can leave you with one thing when we talk about detections, it's this. Detections are really easy to trigger, but they can be impossible to understand unless you have the ability to look at the alert and understand what it's triggering on. And sometimes that can only be done through life lessons and experience. Now let's just kind of talk about an example in this situation.
12:40
We'll use Cobalt Strike C2. Let's say PowerShell scripted web delivery. So that would be a PowerShell script that remotely calls, downloads, establishes a beacon. And this happens. The beacon calls home several times before the operator even executes a command. The first command they run is, who am I?
13:01
And all of a sudden, the beacon stops calling home. So right now, let's kind of take a look and follow this flow. So here we see the chain. We see that CMD was used to spawn PowerShell. Something in PowerShell was executed, and then who am I was the last process.
13:23
When we look into it, we see that first and foremost, the PowerShell script, while it was an event, they don't have enough information right here. They believe there's something malicious, and there has characteristics. So it's not confirmed. They still need more data.
13:41
These EDR products don't want to jump to the gun or terminate because it can actually impact business. So they need the right information because if they're terminating everything like that, it cannot be used in their environment. No one's going to use their product. So they need more data points to make that decision. The next alert. Okay, so now it's a bit more of a severity. They see there's a base64 encoded command, and it appears to be malicious.
14:05
But there's not enough indicators right now for them to know what's going on because sometimes this could be a false positive. And then the final one, we see a recon command. Obviously, who am I, was used. And with all this combined, that's where this alert is.
14:21
So we see this breakdown. It wasn't necessarily that the scripted web delivery was the catalyst. It was simply enough behavioral indicators had been tripped for something to occur. So once again, oftentimes, the implant cannot be the primary cause of the detection.
14:40
It can sometimes be post-ex techniques. And so when you are looking at this and you're establishing a foothold, you have to be also mindful of just because you have this foothold doesn't mean that you're free in the clear. There are often secondary controls that can trigger, that can lead to a preventative measure and a loss of a beacon.
15:02
So it's really important to understand, even if you're successful, how you were successful. Are there still stuff? Are you fully flying blind? Do they have enough information? Is there something they're waiting for? Even if you're using the latest techniques, if you're using a very common catalyst,
15:21
like a delivery command that's highly indicated, you can get caught really easily. And thus, those highly undetectable techniques will never really be triggered or used. I like to call this fruit from a poison tree because if they're already onto you for the first initial call, once again, let's say PowerShell, everything subsequent is already suspect.
15:44
So going back to that event, I want to kind of say, who am I was just the tipping point. There was enough information from there because from the behavioral instance, who am I simply uses a recon and with everything in that attack chain, there was enough to discern and confirm that based on the fact that who am I was run,
16:03
that the PowerShell activity was indeed malicious. And why they did that, it might be a question, why didn't they just instantly block PowerShell? Because PowerShell, as much as we use this, still has legitimate business uses for IT and administration.
16:21
So by completely terminating it doesn't actually really work. You need more points to make a decision. I like to also call out here as an opposite consideration to avoid PowerShell at all costs. Most of these days C sharp tools pretty much cover the gambit of everything. C sharp is highly flexible, it's easier to obfuscate, makes it harder for luteins or even endpoint protection tools
16:44
and anti-malware controls to detect this. So if at all costs, avoid using PowerShell because it's highly indexed and kind of indicators of compromise are clearly defined. So some opposite considerations when we're building out these attack chains as well as our implants.
17:04
So first and foremost, let's look at the implant itself. So first, I always say encryption. Always use some sort of encryption. The higher and the stronger the encryption, the better. Sometimes I have discussions and people ask,
17:20
well, what about base64 or something along those lines? That's good, but it's by no means a replacement for encryption. It's great to use a combination, especially when you're encrypting AES or something like that, the string to base64 or encode it makes it easier to store in your file, your loader.
17:40
Now that being said, the next issue becomes avoiding the strings. This is often a common thing that YAR rules or any type of luteins are looking for is for something to write a rule or some kind of trigger on. So if they can find a static string or a value that's always going to be the same, they will use that as a catalyst to create their rule for detection. This kind of plays away from the EDR perspective into those SIM stock and all that type of stuff.
18:05
So I always like to say if you can, make your loader as morphic as it can be. So each time you generate, it's always going to be different values. The strings are going to be different sizes and everything like that. That just adds a level of entropy, making it harder to see it. You can kind of see here, if you see in this example of a YAR,
18:23
you can see these ops and all these things. These are static values. The chances are that when that triggers, there will be an alert. Also, if you can, depending how fluid your comfortability is, using uncommon languages is a great way to add a layer of obfuscation to your loaders.
18:41
The most common ones these days for tooling is C sharp, C++, but looking at things like Golang, Rust, F sharp can be very valuable as just a natural way of obfuscating. So offset considerations when we're talking about a loader. So this is where it becomes very much an art form and situational.
19:03
So the key thing here is to understand your environment. What are you targeting? What controls do they have? Is there something that could just not execute in that environment for a specific reason? More so to the point, what are the products, everything like that? Is it a thin client? Is it the end point that you're targeting?
19:22
Is it like a limited box? Everything like that. If you're going to use some kind of COM agent or something like that, are those COM things that are related to Outlook or Word, they might not exist on the server. So those are things you need to be mindful of. Other things can be the file name.
19:44
If your file name stands out as something very suspicious, that's one major thing. If it looks more like a program than it would be found in enterprise, that kind of makes it easier to tell that story once again to blend in, as well as going deeper, looking at the metadata, at the attributes you don't want,
20:01
your home computer or your own personal name in the metadata. And that all kind of stems down to how does it look on disk? If it's just a weird size, a weird binary or something really weird sitting on the desktop on a laptop, someone's laptop, they might see this, as well as where you're executing it from.
20:20
If you're once again executing it from temp or app data, it could be suspicious enough that it would warrant investigation. I called this out before, but strings, base64, large strings, is a very easy way. Microsoft is becoming more adept into looking for files that have large base64 strings. By breaking them up, it makes it harder for them to discern that,
20:43
oh, this is definitely something that's suspicious because there's this large string of code. And as always, binaries. I don't mean to beat up on them a lot, but binaries are really easy to detect. That's why looking at, and we're going to talk about it right now,
21:02
looking at new ways to basically load shellcode into memory. So onto the tactics, techniques, and procedures for this modern era. We talked about this a little bit, but sideloading. This is becoming more and more prevalent as threat groups around the world are starting to use this technique
21:22
more and more in favor of traditional things like binaries or even process injection attacks. This technique is simply the act of loading your DLL into a program, a legitimate program of that, in a malicious way. So how this can be is, you know,
21:40
an example can be with CPL files for when they are executed. If you execute your malicious CPL file, it will spawn runDLL, which is managed, which is responsible for the control panel. CPLs are controlled panel applets. So when you execute that binary, that CPL, I should say,
22:00
it will spawn a runDLL process, and that process will then load if it has the proper export functions, that CPL file, into memory and execute it. So what does that look like? It looks like runDLL, a legitimate process, is loading something in. You see this a lot with, you know, reg server32 as well, with DLLs.
22:21
But it basically circumvents, in a lot of times, whitelisting controls, because these are native to the Windows operating system. These are things that are allowed. These are part of the system. They're not something foreign. So they're often whitelisted. There's many of them, different types of sideloaders. I just use runDLL and register as the most common ones out there. But what's great about these is once they're loaded in,
22:44
your loader way that drops, any type of dropper that drops that DLL or CPL, whatever catalyst you're using, you can remove it and clean it up so that way the process is there, it's running in memory, and how you got it onto disk, how you got everything set up,
23:01
can be cleaned away and it's very effective. So now let's talk about Scarecrow. Scarecrow is a framework I developed that actually performs a lot of the kind of techniques we've been talking about. So first and foremost, using custom system calls, it actually will reload NT-DLL kernel base and kernel 32,
23:22
flushing out the EDR's userland hooks in it. So there won't be any hooks. It also encrypts the shellcode in an AES format. It patches ETW so that way there's no telemetry. And it actually goes a step further and uses an alternative way to execute shellcode that's not standard.
23:43
So everything we've just kind of talked about, it's built in this framework. What it also does is those loaders, those files, whether it be a binary, a DLL, a JScript file, it spoofs the attributes of ones that are legitimately found on the Windows environment, ranging from cmd.exe, word.exe to libcrypto.dll.
24:03
All these values, as well as it allows you the ability to validly codesign by actually spoofing the attributes of a domain for codesigning cert. I've provided a link, and I'll provide it at the end to the framework.
24:21
But talking about the loaders, there are several different ones here, and I've kind of listed them out. So primarily it still does use binaries. There is a place still in the world for binaries. But the control, the DLL, the Excel, MS-EXACT, and WScript, these are all techniques to sideload. So we've already kind of talked about control and DLL,
24:42
but the DLL is very polymorphic. It can be used for anything. It just generates a DLL, and you can use it with any type of attack or exploit. Excel, it actually will create an Excel plugin, once again with valid attributes and a codesigning cert, and then uses JScript to actually spawn Excel in the background
25:04
and load this plugin into memory in a sideloading technique. I recently added MS-EXACT. This creates an MS-EXACT process and loads, once again, that DLL into memory. In WScript, it uses a technique called registration-free COM,
25:23
which takes a manifest file and says, this manifest file says, hey, you need to load this DLL into memory, and it provides the attributes and everything of what it needs to do, so it will look for that DLL, which is our malicious DLL, and then load it into memory. Now, because sideloading has become so prevalent,
25:43
and as, again, threat actors are using this in the wild more and more, EDRs are trying to combat this. So you can kind of see right here there was a malicious module loaded. They rank this as a high. But what are they actually looking at? Because this is a really hard thing to kind of detect and stop. So, you know, simply put, sometimes from my investigations,
26:05
looking at it, when they are looking at it, they look for some abnormal module behavior occurring in the process. What does that mean? Sometimes it can be as simple as, then two DLLs were loaded at the same time with the same name. Just by changing it, there's no trigger anymore.
26:22
There's no alert. So it really comes down to that this technique is very valuable and really hard to detect. As such, Scarecrow does ensure that the DLL names that it does load in for WScript, Excel, run DLL, control panels.
26:43
They're not DLLs you're ever going to see in those processes, so this alert never will be triggered. So I wanted to provide some tips using this framework. So the first one is the loader flag. This flag actually stipulates what type of loader you're going to make.
27:04
So as we kind of talked about, side-loading loaders are way better than binary-based loaders. This is simply because they can bypass whitelisting controls. If you don't fill this in, it will by default fill it in as binary, and that might break your success. So always ensure that you know what you're using.
27:21
Don't just use the default. DLLs, like I said, they have their place. It's really versatile, so it can be used with pretty much any type of attack. If you have a metasploit module or anything along those lines or maybe another exploit where it needs a DLL as a catalyst for your implant, this is where that feature really comes into play.
27:41
The next one is the domain flag. This flag basically determines the domain you're going to use to spoof the code signing search. Now, if you do have a valid code signing search, you can enter it. Along with the password, it will actually use that to validly code sign it. One thing, and it's a very common thing that I get asked is,
28:00
sometimes it doesn't work. You can't reach out installed when trying to sign. That's sometimes because wherever you're creating your loader, it needs to be able to reach out to that domain. So if you're coming from a host that has no access to that domain name or that domain doesn't actually exist, that can be a problem. One of the biggest things I always want to stress to people
28:23
is that when you're actually choosing the domain, never use the company's domain. Very few companies, unless they're a big tech company that actually has a code signing search, they use software or anything like that, they're typically not going to have a code signing search and therefore they're typically not going to whitelist it in their own EDR products
28:42
or across their enterprise. So stick to things that are more common in the enterprise. Everyone has network switches everyone uses, Windows everyone uses. Those are the things that are going to give you a higher success rate when you're picking a domain. Next thing is the delivery command.
29:00
This is what we talked about. This is very, very, very dependent on what you're facing. Like I've been saying, LOL bins are great, but they can also come with a high chance of detection. So they're a double-edged sword. The way I tell people is that HTAs are good, but macros and com objects, they're better.
29:24
Once again, that fluid depends on the environment. So the more information you get from your recon, everything like that, will really tell you which one will work better. It's never going to be that this one's always the best. It's always going to be this one is the best for this situation. And that situation can change client to client, network to network,
29:42
enterprise to endpoint, security stack to security stack. You really want to then focus in on the user behavior. I like to always say, you know, Sally from accounting does not know how to use certutil. So if you're trying to pretend to be Sally, maybe certutil is probably not the best thing for you to do. Maybe it might be a different way.
30:01
And I mean, sometimes it can be as easy as if you have, you know, an RDP-based access. It's next to impossible for any product to detect, you know, a mouse and keyboard clicks. It's no way to determine that, you know, once again, this is Sally's clicks and keyboard actions versus me as a malicious attacker.
30:21
So when you're thinking about it, it really comes down to that story and what you have access to. The more you have, the better the story is. I also wanted to provide some sample, you know, commands to get, you know, the ideas going. So here we have the first one is just creating a signed binary
30:41
with ETW bypassing. That's the first option. Second option is a JScript. The JScript ones are usually my favorite. They're my go-to. JScript is really great to kind of get through those network controls and land on this environment. So you see right here with the domain flag and the loader set to control with dash O.
31:04
Then finally, the last one, WScript. Now, WScript is my go-to loader. Just with that manifest file, it's very powerful and really hard to detect, but it might not be yours. You might, depending on, once again, on the situation, it might be something better, a different loader.
31:21
Always keep that in mind when you're looking at these situations. So here we have a little example. We have our loader.js, and it's going to spawn. And if you can see in the private bytes, you can see that value is going up because our DLL is being sideloaded into the process.
31:42
And once it's finished, it'll start executing. It will unhook all those DLLs, then decode the shellcode using custom system calls. Once that happens, it will use a different way to execute, giving us our remote shell. Here we can then enter commands without being detected.
32:01
So now let's talk indicators of compromise. What are they? Simply put, they are pieces of or artifacts that can help identify malicious activity. This can be, you know, related to attacks,
32:20
post-x techniques, you know, data breaches, or even infectious malware that we drop on environments. As our attacks become more advanced in this age, IOCs are becoming more and more relied on to look for. This is that transition away from relying solely on an anti-malware controller and EVR product
32:41
to solely be your sole point, but that layered approach where you have a SIM or a SOC analyzing all this stuff to ensure that the behavior or anything that's dropped or anything that happens is then correlated to behavioral or known attack techniques. And we should care about this
33:01
because this is how the game is changing as we look at it. Fenders are learning from us. They're coming to our talks. They're reading our research. They're following whenever we come up with new techniques and then trying to figure a signature to detect it. And as we modify this, so do the IOCs.
33:23
So if we are constantly evolving our tradecraft, we are circumventing those predefined IOCs that they're looking for. And once again, that cat and mouse game is occurring. And simply put, if we can do that further by modifying how our C2 interacts, that's a great step ahead
33:40
and keeping us always one step ahead of them. And simply put, threat actors are doing this with huge success. So I'd like to give an example. Using Cobalt Strike, a C2 profile that didn't have beacon.dll stripped out. The phishing email that contained a payload. When the user opened the file and enabled the macro,
34:02
the shellcode executed. It's great. The beacon called home. But any time the command was executed, the EDR would block the payload. By simply stripping things out such as beacon and beaconx64 out of the profile and retrying again, the EDR did not catch on to this because it was looking for this
34:23
and didn't see beacon.dll in memory. Therefore, it didn't have enough points of data to make the decision to terminate the process. That's just one example of what we can do for our C2 to manipulate it to avoid detection.
34:40
Another one, once again, looking at those human aspects. User agent strings. Now, this only comes into play if you're using DNS-based beacons. You don't really need to worry about a user agent. Also, while we're on the subject, it's really good to avoid using TCP over the internet. It's very odd.
35:01
It sticks out. If you're going across the internet, HTTPS is the best. But oftentimes, the user agent string can be a dead giveaway. If it's something that's odd or weird or doesn't look normal, sometimes that's an indication that there needs to be something to investigate. More mature companies can go as specific as looking at,
35:21
well, we're a Firefox shop, and then one day they start seeing Internet Explorer user agent strings. That stands out from the crowd, and that can be the point of an IOC that they can start investigating on. So with all of this in your mind, let's introduce a new tool that I'll be releasing today called SourcePoint.
35:41
SourcePoint is a tool that actually generates malleable C2 profiles for Cobalt Strike. Using all these features we kind of talked about and more. It really ensures that each time you generate a profile, regardless if you put the same values in, the actual profile itself will be unique. So you can generate multiple profiles
36:01
using the same values, and they'll be unique from each other. There's over 15 different customization options in this tool alone for you to select. But if you choose to leave them blank, they'll be randomly selected for you. So you're always ensuring a high level of entropy. 15 options can seem daunting. So there is YAML support, so it's really good
36:22
to use a YAML file so you can always have kind of like your go-to sampling that you can start modifying. It is written in Go, but it's simply using a template-based language to generate these profiles. So some of the features it has, as I mentioned before by that user agent string,
36:41
there's over 60, ranging from Windows 10, Windows 10 Chrome, Windows 10 IE, Firefox, Server, Mac, Linux. You kind of get this in the picture, so there's a lot of them. Also, different options for a PE header. There's over 21 currently built into it. There are seven different types of profiles
37:00
for your traffic to be shaped to. In right now, it does strip out 95 strings that EDRs use to look and detect shellcode, especially around your cobalt strike. You can kind of see right here a large list of them. Now, usually the question I get is, well, there's options to obfuscate and encrypt, so why would I bother with this?
37:22
Oftentimes, all that stuff gets down to the point that it's a great way to avoid detection, but at some point, it needs to be read and interpreted by the system. So it has to be in an unencrypted state for it to be processed on the stack properly, and that's when those detection alerts can be triggered.
37:41
So that's why, going through this, I've looked through and found the common indicators of compromise, looking for commonalities and things that they would look for and just removing them. As I mentioned before, there is a lot of raminizations, so the values for allocations on different features are always changing.
38:00
Obviously, there's sleep, jitter, kind of standard things, but the more interesting thing is the manipulation of injection-based strings. For post decks, there's even 18 options. I'd like to also call, we can kind of see here, this is a great document or image. If you haven't had a chance, please go ahead,
38:21
look at this. It is basically a parent relation process map of normal Windows processes and their parent and child processes. So with this, when we're talking about post decks or any type of spawn-to processes, especially like execute assembly, we can actually map a process with a more realistic child process for spawning.
38:43
It makes sense, and it's harder to detect, and it doesn't stand out as much. This tool, SourcePoint, has CDN support for anything that you need for CDN, depending on how you're setting up your C2, as well as allocation manipulation values. It also supports SSL certificates.
39:03
So why use it? It's been in development for several years. It's been deployed on hundreds of Red Team Ops prior to today's public release. The most important thing I would probably say is unique profiles. If you're taking something that is static or using something that's the same profile over and over again for multiple engagements,
39:23
eventually you're going to get caught burnt, especially if you're basing it off with something that's public and you're not really modifying it extensively. Chances are other people are downloading it and doing the same thing. So having completely unique profiles really does aid and, once again, keep being one step ahead of Blue Teams.
39:42
Another reason is it automates the process and reduces the overhead of building and stripping out these IOCs from your C2. My personal favorite is human error. People make mistakes. I often make them. That's why I developed this, so that way I can do it once and have it automate it.
40:04
I couldn't show an example template because it would just run off the screen. We can be here for hours going through all the different features. To show you what the results are from C2 in it, you can see right here how it looks, all the different features, what it's done, the transformations, everything like that,
40:21
the values, and how it just really blends in. My final thoughts before we wrap up. We really need to, as Red Teamers, understand Blue Teams and their procedures better. From that, we can understand how they're detecting us
40:40
and what we can do to go around those detections. Simply, Blue Teamers are attending our talks. They're reading our research. Every time we publish something, they're reading it, they're learning it, so that way they can fine-tune their tradecraft to be better at detecting it. So we really need to do that, and that's how this cat-and-mouse game is going to work and continuously continue.
41:03
Lastly, at the end of the day, for us to be better Red Teamers, we need to start learning Blue. So any questions? You can find the Scarecrow framework for bypassing ADRs and all that stuff for developing implants here.
41:21
Sourceplant can be found on my GitHub along with the slides. If you have any questions or ever want to talk about this stuff, this is my passion, my bread and butter. I really spend a lot of free time doing this and learning and kind of advancing my own tradecraft. So if you ever have a question or want to talk, feel free to reach out to me on my Twitter, my GitHub.
41:41
Before I wrap up today, I just want to say thank you for attending my talk. Have a great day.