DLL Hijacking – A New Spin on Proxying your Shellcode

This webcast was originally published on October 4, 2024.

In this video, experts delve into the intricacies of DLL hijacking and new techniques for malicious code proxying, featuring a comprehensive discussion on methodology and weaponization. The talk explores the practical application of these techniques in real-world engagements, addressing common questions from recent research releases. The speakers emphasize the importance of understanding DLL functionalities and the impact of Microsoft’s security measures, while also highlighting the effectiveness of continuous pen testing in discovering vulnerabilities.

• The webinar focused on DLL hijacking and new techniques for stealthy code execution via DLL proxying.
• Continuous Penetration Testing (CPT) allows for extensive research and development of advanced techniques tailored for hardened environments.
• The webinar emphasized the importance of simple yet effective methodologies for maintaining persistence and evading detection.

Highlights

Full Video

Transcript

Matthew Eidelberg

So yes, this talk can be talking about DLL hijacking and some of the research I did to kind of come up with new techniques. I like to call it spin on proxying your shellcode through.

We’re actually going to be talking about the methodology that I kind of used to discover these vectors, how I weaponized it. And we’re going to be talking a lot about CPT with, Michael Allen on how we actually use this on engagement.

Because obviously it’s all well and fine to talk about the research around it, but how do you actually apply it? And that was something because we released the article in the research last week and I got a lot of questions around that.

So I’ve kind of tailored this to also address those questions. As we mentioned, a lot. this is all kind of came out of our CPT continuous testing team.

As you can see up in the top left-hand corner, you can see our little axolotl logo. With that in mind, I wanted to, before we dive into everything, kind of just level set, kind of give a prelude that, as we kind of start talking, there’s going to be a lot of terms that we are going to be saying that sound very familiar and it might be confusing, but unfortunately with DLL and DLL hijacking, side loading, all those sort of, terminologies, while they all sound different, they all kind of do something similar.

So I’m going to try to highlight as best as I can in a very brief, methodology review. So that way we all have a certain baseline of information and that’s really just to help understand, the infinite possibilities and what kind of set me down this path to start looking at these.

Obviously, when we’re tasked to look for any type of new, attacks or when we’re coming up against a long campaign, the biggest thing we have to do is look at what is known in the wild, what is getting caught, what we know is going to have a high level of risk, and then start kind of working backwards and see what can we find that’s not being talked about.

Something new or maybe something that’s maybe obscure. And one of the conversations we all had as a group was persistence, making something that we can have something last over a long period of time.

If you tuned in for the pre show banter we mentioned that, in these type of CPT operations, these gigs often go months, weeks, maybe half a year, so to speak.

So we want to kind of establish something that’s very persistent and something that won’t get us caught. So with that in mind, this is kind of how we approach this and the methodology and research I did and what I discovered.

Obviously, since we’re here to talk about DLL hijacking. What is DLL hijacking? So when we talk about DLL’s, we first have to kind of understand that a DLL is a library of functions that a process can load in that then they can call.

So the most notable one is probably NT DLL. That’s the core for Win 32. So that’s how you can allocate memory, that’s how you can create a file, save a file, change permissions of a memory section.

So when, let’s say we’ll use an example, excel. When Excel loads, it’s going to load NT DLL into the process.

It’s going to set it all up, allocate, space in its own process for it. But that doesn’t mean that once that DLL is loaded, it instantly runs, and that’s where it differs from a traditional exe file or executable.

So once it’s loaded, any of those functions that the DLL has supported, are accessible to the process to be called on. And once that’s called, they can then, begin to perform an action.

So when we talk about DLL hijacking, what we’re actually really focusing in on is exploiting a trust between an application and a DLL.

And what we are trying to do is kind of insert ourselves in the middle. So that way we can then do something such as load our malicious code when it’s trying to call a valid DLL.

As I mentioned before, persistence. but these types of attacks are used for more than just persistence. for the past few years there’s been great techniques where you could do some type of DLL hijacking to actually gain an elevated context.

So go from the standard low privilege user to a high privileged or NT system even, or even as a great way to deploy something that then runs after a certain period of time or after a trigger to initially establish code execution that we’ll actually talk about in one of our use cases and how we weaponize this for a large spear phishing campaign.

But because of how impactful this is, Microsoft has taken a lot of steps to kind of close the gaps on a lot of the traditional methods, making DLL hijacking easy to detect and also harder to exploit.

And these kind of common ones that I just kind of mentioned that were hard are getting harder and harder are listed right here. So you have your kind of top three. There are tons I want to pause before someone says, hey, wait a second, I’m used to doing these types of attacks.

These are the most common ones. There are at least, four others. But I really wanted to focus in for the level set of knowledge on these. So the first one is sideloading and that’s really when you drop a DLL into the same folder, as the process.

So let’s say if you’re, let’s just say Excel and you can drop a file right in there and it looks for this weird DLL that doesn’t exist in its m, first folder.

So maybe it looks for NT DLL using that same example before, rather than looking in the system folder, it looks in its own folder and obviously it fails and then it goes to the next one.

Well, where is it? Oh, now I have the right path. By dropping in the same folder, it will then blindly trust and load our DLL. Now there are some caveats that obviously when you take over a DLL like that, you have to make sure that you’re still providing those functions and stuff.

Because core DLL’s like NT DLL, they’re not accessible. The process will crash and we don’t want a process to crash, especially from a covert stealth operation. that kind of gives us a way we don’t then achieve our goal of establishing a foothold.

So that’s one problem that’s been slowly closed out by a making sure proper permissions are on these folders. Another big one is missing DLL’s and what we can do with that is by looking and understanding what the process loads or it looks for.

There are sometimes due to development lifecycle, CIDC pipelines and stuff, where through development they have additional, DLL’s that don’t make it through or no longer need it.

This could be something where legacy removed from one os to another. Maybe they’re no longer existent, but they still look for them. At that point we can find those names and then just drop the DLL with the same name and it will blindly trust it.

The last one, this one, while it’s still prevalent, it’s harder to achieve is the order hijacking. I kind of mentioned that before with the DLL sideloading, but there are some times where they will look for a valid DLL in random places.

And if you can find out the order and one of those places you can write to by putting that DLL in that order, you’ve kind of jumped the line and all of a sudden your DLL is loaded rather than the other one, even though you have the same name.

It’s just where it’s looking first. As I mentioned, these were great previously, but over time, developers are kind of being more focused in on making sure secure coding methodologies, adhered to, making sure that a lot of these gaps are, not in present, especially in the operating system parts.

You see these sometimes more common in third party software or even freeware software. So if DLL hijacking is not sort of the norm or it’s easy to get caught, what are we really going to do?

What is this talk all about? Well, I like to call this DLL proxying attacks. And what really we’re doing is we’re taking advantage of one of two things. We’re going to talk about the first one, which is folder permissions.

Even though I mentioned, that the operating system, they’ve taken great strives to make sure that everything is secured and locked down. there are still things like widgets, plugins, add ons that you see to this day, that are put in places that allow anyone to write to and that is great.

But if we were to just totally take over that DLL, the process will crash because we’re not providing its functions. How do we achieve both goals? How do we achieve getting our code loaded and established while still providing access to those functions and all those core libraries?

Hence the term proxy. So we do this by introducing our DLL into the same folder. Now, first thing, someone’s probably says, wait a second, you can’t have two DLL’s with the same name.

You are correct. So what we do is we actually rename the original one. It can be something like totally legitimate, that old or something.

By doing this, what we can then do is map the exact functions from our malicious DLL’s and point them at the original one.

When a request comes in, what you’ll see is the function gets it and it will pass it almost as if it’s like an attacker in the middle proxy. If you’re familiar with something like evil Gen X two, or any of those types of phishing tools where they proxy authentication requests, we’re kind of doing the same thing, but with DLL functions.

Now there are these proxy attacks that don’t even require the DLL to be in the same folder. We’re going to touch base on that. But what I just described, I have this great visual to kind of explain it.

So let’s say this, we hijack process exe, and so our DLL is in there and our code is running, but process exe all of a sudden says hey, I need this function.

Let’s say it’s going back, let’s say it’s virtual allocate. Well, our DLL is going to get that request and it’s going to say wait a second, this function is not one of my malicious ones, it’s a valid one.

I’m going to go find the original DLL, say DLL old, send that request to it and load it so that way it can actually do what it needs to do so the process doesn’t crash.

You might be thinking, how is this possible? It’s actually really, really easy. And something that is kind of developed native to all DLL files, which is definition files.

These are just function files that can dictate attributes or operations of DLL’s. So it can be something from hey, when you compile this, I need this file to have these attributes in the file detail.

Hell, in some cases with binaries you can say I want it to have this image to show up. So in our case what we’re actually doing is we’re defining the exports. We’re going to say, hey, we’re going to have this export, but when you call it, we’re going to say it’s in this file, the function name, as you can see right below.

So this is the code that you just attached to your deal. It’s very elegant, it’s very simple, and this allows that any time that these functions get called, we pipe it to, in this case one auth legitimate and then the function name.

So when our malicious DLL is loaded, the process never loses any function ability. The user never notice a disruption to service, like things are not available, process doesn’t crash, everything looks normal to the system, which is also great when we’re thinking about from an operational perspective, staying under the radar.

If everything is operating, and it’s hard to tell, that’s what we want. So how do we discover these? Well, the easiest way is using process monitor.

It’s a free tool that Microsoft offers, and what it can do is it monitors every single event in your operating system. That could be from load image, events to even queries to say hey, who touched a file?

But it gives you a lot. It’s like drinking from a fire hose. So you really need to know how to master the filter, feature. So these are the filters that I recommend and this is what I use to go look through.

So I would look for load image. What does that mean? That is the actual operation that a process says when they’re loading a DLL. And what I’m looking for are DLL’s that are not in places that are protected by administrative rights.

So obviously no Windows, no program files. What I then do is I just let the computer run. I might pretend I’m a user, have the software installed.

So I’ll pretend, oh, gonna open up Outlook, send an email, oh, I’m gonna do my spreadsheets, whatever it is, that normal operation, as things progress, the events get calculated and logged.

So by just looking for load image events that are not in these two places, we can start to look to see what processes are loading DLL’s from other places.

Now this is the example that started all this research which was outlook. Outlook is the most common tool used in all business. It’s for email. I don’t think there’s an alternative that even rivals it these days that’s still being used by business.

So you can see right here that under this user low privilege in the appdata local there’s a teams add on that gets loaded and you can see a bunch of DLL’s that just get loaded.

And what’s great about anything that’s in the app data folder is that you as the user have read write permissions to it. So all of these DLL’s we can manipulate, that means we can rename them, we can drop a new DLL in there, which is all the things we just described that we needed to do to be successful.

You can see that right here in the actual folder we can see low privilege user has read, execute, modify, full control over files in here.

That’s the key thing we need for this type of attack to be successful. Going back as you saw before, all we just needed to do was then scan that DLL, see what its functions are, map them into this export file, rename the old one, say legitimate, and then compile, drop our malicious one in.

Now the next time outlook runs it will load our DLL. And in this case, this one’s just going to show a simple hello world from Rust. If you haven’t heard or ever listened to any my talks or followed me on Twitter or x, I’ve really been a big rust fan.

So everything is rust. So I apologize. If you see rust code, you’re like oh my God, trust me, it’s the best language. Personally by my take. So with this following code we’ll kind of see what happens the next time Outlook runs.

So instantly we get a pop up message because it was just loaded. And if we actually go and look at the folder, we can see first we see our outlook and then Outlook legitimate and then we see in the next part where that arrow is.

That’s all the DLL’s, that outlook launch. I know Outlook’s a little cropped out but that is the process. And we can see one off is there when we double click on it using process, Explorer, we can see from this point that in fact all those functions have an accl reference to that legitimate one.

So that’s how it looks. So anytime startup is called Outlook is going to say hey, one off, I need startup, RDL is going to go ok, startup is in one off, legitimate, pass that request and that way there is no disruption to service and our DLL gets loaded and no one’s the wiser.

So just by briefly doing this and as I mentioned at the beginning the drive for CPT was we needed to find something that was common across multiple different clients as we were targeting a large group of clients.

So that meant, not just 20 users but maybe 30 users across 20 different clients. So you have to kind of, what is the commonality we looked at? Well, everyone uses Outlook and teams, so focusing in on we actually found using that methodology, four differeNT DLL’s that were universal across, Windows ten, Windows eleven and all those different versions, these were predominantly the ones that could be easily hijacked.

This technique, all you had to do is drop the file in this place. Obviously you need to know which version. So a quick registry query to see what version of Outlook was running, that was the easy thing.

And obviously knowing the user that you’re running under, but automating that to just to drop a DLL and then wait for the next time outlook ran would result in us getting a remote access through either some sort of c two.

Now if we go deeper under the hood and take a look at this, as I mentioned before, just because our DLL is loaded does not mean our code instantly runs and we have shells.

Michael Allen

Sorry.

Matthew Eidelberg

So we need to look at a way to achieve this because obviously no process is going to run our evil cPT code or something like that.

So we have to figure out how we can automatically get our code to launch right when the DLL is loaded. We had to find something that’s universal, that is guaranteed if you’ve done any type of malware development.

You probably know where we’re going with this, but we’ll kind of talk about the fact that DLL main is present. That’s the one we chose.

Why DLL main? Because it’s a universal function, and what it does is, serves a major purpose when a DLL gets loaded or when a process is terminated, because all it does is it initializes the DLL dependencies.

and if you’re shutting down or say the DLL needs to be unloaded, DLL main does the post initialization to make sure the memory space is cleared and nothing is errant or unwanted.

It’s a very common function. It is used for a lot of different basic operation structure. If you ever go and just search and like on Microsoft documents or GitHub, show me a sample DLL, you’ll see the first example will always have a DLL main.

And inside there’ll be things like what happens when it gets attached to a process, what happens when a thread gets called, and then it just handles all those things. So by attaching to that, we’re, almost attaching to the startup operation, or if you almost think of it as a computer, we’re attaching ourselves to the boot process of a DLL.

Someone might think, wait a second, isn’t that kind of dangerous? And you’re right, there are lots of issues by attaching your code to DLL main.

the biggest one is process deadlocking. How do I know this? Because I deadlocked many processes developing this because of the fact that when DLL main is loaded, it does a quick series of checks, and then it just waits for something to happen in a process.

When it’s loading, we’ll say, hey, load this DLL first. Okay, now that DLL is working, everything’s good. Go to the next one. Just got a message back that DLL is working. Everything’s fine, loaded.

Good. So if we load something into DLL main, and when it gets called, it takes a long time, we freeze that process and deadlock it, which disrupts it.

it’s waiting for something. So if our shell code is in there, for instance, and we prevent the process from kind of loading the additional resources, something gets skipped or even the process freezes.

First off, the user notices and that’s already game over. But sometimes you can actually cause the process to crash, making it very unstable, which then doesn’t resolve in us maintaining access.

So Microsoft actually, because of this and how easy it is to cause, recommends that any type of, functions or any type of additional stuff gets postponed as far as possible until way after the initialization, process.

This is just to ensure that no additional actions are superseding. The processes need to kind of load everything and get every environmental variable set up and make sure support across DLL’s is there.

And they actually have a great reference. there’s a hyperlink right down here about things that DLL main should not never perform. And you can see a lot of these are what you would see with regards to any type of shellcode or malware development load library, create process threads, because it can cause this deadlocking issue and once a process is deadlocked, you can’t really recover it.

So how do we get around this solution? Well, you might seem like a very simple fix, but boy, it did take a while to figure out which is there’s a reference in their documentation of Microsoft that says hey, you should defer everything until later.

Now I do not want to defer or anything else. So what I actually came up with was the idea of actually creating a thread. And inside that thread there’s a sleep function that will, once that sleep function is done, we’ll run our shellcode.

Now why would we want to create a thread or someone saying, hey, what’s the difference with a thread? Well, when you create a thread, you’re creating almost like a parallel series of function processes that can operate.

So everything that’s in this thread can run. That’s the main. We create this offshoot so other functions can then run. And because of that we can just wait. Okay, we’ll wait 10 seconds or 15 seconds, and that should ensure everything is loaded, then we’re going to run our code.

This actually works very elegantly. It’s such a simple solution. And in addition to the COVID option where because the process loads and after a long period of time, our code executes, a lot of traditional products, security products will scan, check and say, hey, there’s no weird behavior right now.

And then a, few seconds later something happens and kind of helps us stay under the radar. It’s not always a guaranteed evasion technique. And please don’t go off and say, Matt says if you sleep it long enough you can bypass every EDR.

That’s not what I’m saying, but it does help. but it also mainly just makes sure that everything gets loaded and there’s no disruption. and that worked really great.

And I’ll kind of mention this, but we provided Microsoft with a lot of this information and they kind of said, thank you for the advisement, really are. We understand that this is an issue.

We’ll take this under future production, environmental changes. And I wondered why they weren’t taking this seriously. And I come to find out that they’re actually decommissioning a lot of the outlook in Microsoft Teams for their new version that they’ve been working on.

And that’s where I decided to dig deeper. That’s where the second half of the research came into play. So Windows apps, now you’re probably like what are Windows apps?

Because that was my question. When we look at it, they’re actually in a separate folder than traditional files. You can see right here the new version of teams. It’s in C program, Windows apps, anything from the new outlook which if you’re wondering they renamed to olk.

Don’t ask me why, but they’re in a different folder location. It made sense why they weren’t taking my responses so seriously.

because obviously they’re decommissioning if they’re focusing on the new platforms, even though these other ones that are still widely in use and widely in circulation and will be for some time.

So kind of going the extra mile. Let’s take a look at those. Well first thing I notice with these Windows apps is that they’re all self contained in this folder.

Nothing is loaded externally as well. No one has access. That means not even an administrator.

The only people that have access is NT system and the trusted installer. So we could try to do a privilege escalation to get to those contexts.

But in reality Microsoft did this, as I mentioned before, as a way to protect against DLL based attacks. If everyone can access the folder, everyone can’t try to attack or manipulate some kind of part, ensuring that nothing in there is manipulated and so the entire process is safe, or so they thought.

This is where we’re going to introduce the term objects or component. Object modules is a framework that Microsoft developed years ago, that allows the communication of resources between the operating system and other processes regardless of what language they’re written.

So if you have a process that’s written in python that needs to call c sharp, components of the Windows operating system, they can communicate without any type of cross dependencies.

It also allows for processes to operate or manipulate Windows or system level elements. some of the great type of things I already mentioned intercommunication processing, but there’s support for versioning.

So if you have legacy like back when Windows seven was around, you still had 32 bit being circulated in a lot of offices, but also the creation and manipulation of dynamic objects.

Those objects can be something like hey, I need the email sending capability of outlook. So it would actually not load the entire outlook, but it would just load that capability or component or in excel word hey, I just need access to the VBA environment.

So rather than loading up word and then the VBA environment, it could load up that VBA environment independently. Using that same methodology I talked about before, we’re going to take a slight adjustment.

Rather than home tuning on the load image functions, what we’re actually going to do is look for anything that is related to now one of the big things with is that every object has this very long character string.

So if we search for references to it and they’re usually in curly brackets, we can see several calls. First one is a registry open and we see it’s not found.

Then we see another one with the exact same entry that is found. And the only difference is, as you see in there, I highlighted in blue is the HKCU and that stands for the current user section of the registry.

The HKCR is the more locked down root version. And so based on all of this I discovered that these processes look for DLL’s using their object id and where the big vulnerability here is that they first look in the user section where they don’t exist and then they go and they fail over to the right path.

So in that example we can see that what they were looking for is netprof FM DLL. So now it knows the entire pathway and then it’s going to say to the process here’s the path, and then a load image operation gets called.

But why do we care about that HKCU area is because that area is the current user section, which means as the current user we have read and write privileges to it, which means we can write our own registry key and tell it what the path is, which is pretty significant because now we have just taken that proxying from in the same folder to anywhere in the operating system.

What’s great about this is that we are now able to then proxy system DLL’s the ones that are found in Windows C, Windows system 32. Using this technique we don’t need to have any type of precursor elevation, we don’t need to even have additional privileges.

We can do this as a low privilege user and by actually writing that value in that area we can see a major difference. So now that first call where it says HKCU, it’s successful.

And if we then go and see what outlook, the new olk loads of. Oh, we see a window. That window says hello world from rust.

Now that’s great. That’s those Windows apps. But if we take a look, could there be other applications of this? Yes there is.

By using that same methodology, looking for those calls, we can see hundreds of Windows processes, not just ones that are installed like Excel, but like where, fault, svchost, msedge, you name it.

They all look using different, looking for differeNT DLL’s. As you can see, I have sideloader one through I believe 13 different test cases I’ve mapped out, which is pretty significant when you think about the fact that these are native Windows deal processes being arbitrarily load and that we can hijack them.

So how do you automate this? How do you do all this? Well, if you followed the release last week I released a tool that automates this whole process called face dancer.

What this tool does, it has two functionalities. The first one is to create hijackable DLL’s like we just discussed. So the ones that I know and I have mapped out will be there. You can create ones that are those first examples.

You drop them in those folders to proxy certain uh.com objects. And that mode I like to call raining shells because you can have maybe five to 20 processes I’ve seen call the same object loading that same DLL and you just see shells after shells raining in the other mode is a more targeted hey, I just want it to trigger if it’s process, let’s say msedge, that’s what the ATT and CK module does.

The recon module allows you to start scanning and creating those definition files yourself. So say for instance, you find your own and you want to weaponize it like I’ve just described.

You can use the recon to scan that DLL, it will create that definition file. You can then pipe that definition file into the attack mode of this tool and it will generate you that DLL for you.

So one of the big drivers here and why I want to talk about this is I want this to be a continuous project where people can research and find more and more. Because while I found numerous ones, I know there are thousands out there and they’ll be continuing.

But a quick example of how this would look is say for instance, we’re going to target the process msetge. So we’re going to use our shellcode, very key thing that’s very important.

What you load in is not raw shellcode. It needs to be a fully compiled DLL facedancer will then use a technique called SRDI to bootstrap and turn that DLL into shellcode for you.

And then what it will do is it will spit out the registry key values you need to apply and all of a sudden that’s all you need. In this example I actually took vanilla unmodified, cobalt strike DLL’s the ones you get generically made.

There’s no artifact kit, there’s no modification. I used it using face dancer, deployed it on a Windows box. And you can see when Msedge got loaded, our beacon calls home.

And when we look at that DLL Ms edge, even though there are two, because of how ours is structured, it gets mapped in a separate area. And when we look at it, you can see every one of those function calls mapped to mpproxy DLL.

And the process is going to know based on this reference I got a first look in the system folder, system 32, and it natively loads it so we can proxy all those function requests while hijacking this DLL.

We did not need to drop our DLL into the system folder to achieve this. In fact this case it was running on the desktop. So this is all great. And I’ve been talking a lot about DLL’s, but how do you actually get this, how did we actually deploy this in a real engagement?

Michael, would you like to discuss this now?

Michael Allen

Yeah, absolutely. Matt just laid out this, awesome method of getting code execution and getting around EDR products, using DLL hijacking and other techniques.

But in order to use this on some kind of attack we had to pair this with some other things. So this gave us a really great opportunity on the continuous pen testing team to execute a big campaign with a new technique that we could incorporate multiple other custom built tools and custom things, created by multiple operators and really operate like a real world apt.

So go ahead and go to the next slide if you would. I don’t think I have control of the slides. Okay, perfect. Yeah, so this is the ruse that we came up with first of all to execute this.

So we created a message where we wanted the message to look like it was coming from an automated ticketing system from within the organization that was telling users there is a critical Microsoft outlook update that they’re going to need to install.

And so you see the screenshot on the right. We cloned the real Microsoft Outlook, or rather Microsoft security website, one of the pages on there for a real update.

And modified it a bit so it matched our ruse and had all these details about a fake update that users were going to have to install. We did some other cool things too, like modifying the or adding some JavaScript to the page so that way we could get around the little warning that pops up whenever users download a file and that file is not frequently downloaded.

A lot of times your browser will say this is a suspicious file or this file is not frequently downloaded. We learned that by opening an MSIX file in particular on Microsoft Edge we could actually get around that little warning.

So we had some JavaScript on the page that forced the page to open in Microsoft Edge, then getting a bit deeper into that MSX file that we used here. It was a Msix dropper, payload.

If you’re not familiar with a dropper payload, it does exactly what it sounds like it does. It either extracts or downloads another file to the disk of the computer somewhere, be it the file system, the registry, or whatever it may be.

In this case, we were dropping that DLL file that was created with Matt’s tool to the correct place on the hard drive where it would be loaded whenever Outlook executed and would be a proxy DLL for that.

Teams add in that came pre installed with Outlook and we had a little bit of logic in there to determine which version of the teams add in was installed.

So that way we’d get the correct DLL dropped in the correct place, rename the original DLL and modify anything else that we needed, to get execution.

That’s the nice thing about the MSIX payload is that it can do a lot of other things like set up environment variables or modify registry keys, things like that. Go ahead and jump to the next slide.

Here is what the execution of that MSIx payload looks like. in the screenshot on the right you see it’s prompting to install the Microsoft Outlook update. There’s an install button for the user to click.

It looks pretty legit. This is a signed MSIx package. You see publisher signed software where we’ve actually signed it with a real EV signing certificate.

this is something that we learned would actually bypass the mark of the web protections when we used a mSIX payload specifically and the users downloaded it and executed it.

Even though market the web was in place on the file, there was no smart screen alert whenever they were executing this. So this quickly became our favorite, payload to use for payload based phishing because we could get around mark of the web like that.

We also added in some cool logic, Joff thyroid, he was the one that actually built this msix payload. He added in some logic so it would detect if Outlook was running whenever the payload was launched.

If it was running, the user would get a pop up to ask them to close, Outlook. It wasn’t necessary for them to close Outlook for our payload to run, but what was necessary was for Outlook to be executed for the payload to then launch after it had been dropped to disk that second stage, the DLL file.

The only way it was going to launch was if Outlook was executed. So we needed the user to close Outlook so that way we didn’t have to wait a week or however long it took for them to close their Outlook application or reboot their computer or whatever and get that execution because we wanted to get it quicker than a week or however long it took depending on what the computers have or the users habits were like, okay, go ahead and go to the next slide.

So, as I said, we did this as a phishing campaign. We actually did an email based phishing campaign for this one, because we wanted to launch it so quickly. We really wanted to get this new technique out that the Matt had created that specifically taking over that teams, add in DLL.

We wanted to exploit that before Microsoft potentially patched it, although I don’t think that they ever did. But at any rate, we sent it over email and sending it over email is not personally my favorite.

A lot of people on the team, we don’t really like to fish over email if we don’t have to. And that was sort of the Achilles heel of this entire attack was we tested our emails ahead of time against every email defensive product that we could.

we had a proofpoint environment set up, we had a Microsoft environment set up, we had others set up to make sure our emails were actually landing in inboxes even when we were phishing against these different defenses and they were landing in the inbox every time when we were doing our testing.

When we launched the real campaign, sure enough, most of the emails actually either got blocked or went to junk. But a few still did land in the inbox in several different environments.

And where they did land in the inbox we got multiple successful executions. And when we got those executions, the payloads were not detected at all. In fact, the security products determined that the files that were on disk where our payloads lived were actually completely safe.

Even after our customers submitted those files, like manually submitted those files as being suspicious files, they still found them to be safe. So that was really very interesting to us and just further evidence of the efficacy of this attack and this technique.

Then go ahead and jump to the next slide there mike. I think it’s, yeah, this one’s you.

Matthew Eidelberg

So as Michael kind of mentioned we, our customers in obviously a joint effort, we tried to reach out again. This time I was talking about all these different features I’ve highlighted and the impact and with some real world cases they kind of came back with this response, which if anything about Microsoft’s bug Bundy program, it’s not shocking.

What is shocking is unfortunately that because of these issues there’s a lot of tuning that a company will have to do to even start to begin to detect this.

I’m sure someone in Microsoft’s development team is looking at this going hey, we can fix this and I hope that this information reads them. But right now as of today we’ve been looking at this correctly wrong.

This has been several months in the making. every Windows system is vulnerable to this. Windows ten, Windows eleven. and because of it we kind of are dubbing this a forever day, which is not the greatest thing to talk about.

But the whole intent of this is also to help raise awareness and continue this research. So if you’re part of a security team or any type of defensive team and you’re wondering well how, how can I stop this?

Like is my company at risk? until Microsoft recognizes this there aren’t really any type of remediation steps to patch this right now my hope is that as this starts a dialogue and maybe down the road they’ll fix this.

but what can you do? well first off, because they’re what I dub a forever day or end day, it makes preventing this attack from actually existing in your environment nearly impossible.

So the next step is to detect it. And if you can start developing rules or logic around it you can create detections and then from there you can create isolations and quarantine remediations.

How you do that is always going to depend on your type of business and how it works. In the example Michael walked through, one of the big type of key things that prevented us from being successful was email filters.

So if we were to take a step back and say is worrying about DLL’s loading the bigger issue or making sure files don’t get dropped to disk, well how did those happen?

Could be this, could be that. Looking at the onion approach, don’t just look at this one sort of thing. Look at how it’s coming into your environment. Make sure those outer layer defenses are tuned up to ensure that files from unknown locations are not allowed.

Making sure that if, say, this is hosted somewhere that you literally lock down those firewall rules. Ensure strong email filter controls. Make sure you have monitoring for abnormal domains, maybe phishing ruses or anything like that that triggers on click here, download here.

Those are some of the best ways to prevent an external threat from bringing anything, not just these attacks. And if you focus on those types of defensive measures, it makes it really hard for us to get in and by then extension any real world threat actor from doing this.

Because they don’t have internal access to every computer, they need to do something to establish that foothold first. So it always comes down to those controls.

And as well, phishing awareness, your users are your weakest link. So phishing awareness campaigns education around that is a huge, huge boom to protect against any type of phishing attacks, including these.

Now if you’re a security researcher or anyone that’s interested in looking into this, there are tons of processes I mentioned. They’re not just loaded via, folder permissions or objects.

Face dancer is designed to help create those DLL’s. I want to stress before anything else, there is no evasion components in face dancer.

Face dancer is not a typical EDR tool bypass that I’ve written in the past, like scarecrow, freeze, you name it. This tool is designed to create these hijackable DLL’s.

So whatever techniques or things you want to bring in, that’s your prerogative, that’s part of your operation. If you’re doing research, if you think, oh, I’m going to use this on my next pen test, I’ll just grab raw DLL’s and stuff that won’t probably work, it’s intended like that.

But my kind of focus with developing it this way is so that way. This could be a tool in someone’s arsenal for not only testing, but also research to find new DLL’s that are vulnerable to this, possibly new ways to hijack into elevated privileges.

And what I did mention it is my type of favorite hobby is creating bypasses for edrs. There are, in theory, ways to use these types of proxy attacks to legitimately unhook edrs.

I’ll leave that to people, to kind of discover. But that is the intent of this. but really I wanted to bring this all to the attention to not only start a dialogue but hopefully provide ways for companies to share information on how to mitigate this.

as Michael and I kind of discussed, we found some of the things that were very effective, but I’m sure depending on the organization or else there’s other ways. And if you have an idea or if you thought of a way to defend against this, there are probably organizations in the world that haven’t, that probably could use that information.

So the whole purpose of this is to start the conversation, share information, and hopefully get Microsoft to remediate this.

Now, I know I’ve talked a lot. I, want to say thank you to Michael Allen for coming in and, helping today. If you’re interested in any more about this, the article is right there, as well as the link to the tool.

Thank you, everyone, for attending. I guess it’s now question time. Oh, before that, I just want to say one huge shout out to no bandwidth. If you are going to wild west hacking Fest, please stop by.

CBO just released an album a little while ago. Please go take a look at it on Spotify. Most of the code base of Face Dancer was written while listening to his music.

Deb Wigley

We just finished the album art for Bo’s new album that’s coming out as an original soundtrack for the comic book that we have coming out next year, which is amazing.

Matthew Eidelberg

Amazing.

Deb Wigley

Yeah. Well done, Matt. Matt. Michael, do you scare the heck out of everyone listening?

Matthew Eidelberg

Well, I’m sometimes worried that I put people to sleep with how it sometimes dry the technical dive is, and I hope the audience is still awake and that they can ask questions.

Yeah. we have some questions, for sure. let’s see. in order to land in the inbox, do you have tips like domain aid, et cetera?

Michael Allen

You want me to take that one, Matt, or you want to use it.

Matthew Eidelberg

As the initial access broker? That is all yours.

Michael Allen

All right. So, yeah, there’s a lot of stuff that you can do to try and get into the inbox. We age our domains. we try and get the domains categorized, based on both content that they host and on things that are potentially sent from the domains.

those things are difficult to do, on short notice. So that takes a bit of time. We try and do that well in advance of a campaign, of course, for aging.

Again, let’s see what else I got off the top of my head. There’s a whole list of these, actually, that I teach in my red team class. I don’t have that slide in front of me at the moment, but, using some like third party services whose business it is to, send your email.

That’s another thing that’ll really help. leveraging things like, mailgun, for example, is one of one of several, like Twilio, I think, or Sendgrid, any kind of service like that, who’s, whose business it is to get them to land an inbox.

And then there are other techniques that are out there available to be they sending from a domain that already exists and has an established reputation, like an on Microsoft domain or even a free gmail account or Outlook account.

Sometimes if your ruse matches it, or sometimes doing email spoofing. There’s a great blog post on the bhis blog that Steve Borsch wrote. It’s, spoofing, email like it’s 1995.

Something along those lines.

Matthew Eidelberg

Nope.

Michael Allen

You hit it.

Matthew Eidelberg

Exactly. That’s the title.

Michael Allen

Okay, perfect. And that’s an excellent way to get around those email controls for multiple reasons. Actually. I won’t go into all of them here, but yeah, definitely recommend checking that out for sure.

Matthew Eidelberg

All right, seems like someone found that article.

Deb Wigley

Great job. And that was fast. so I have a question, but before I ask the question, for those of you that are tuning in live watching the, webcast and you’re in discord, make sure you check in for Hackett.

So we give you credit for being here today. Once you hit ten, you unlock a special channel. We send you a reward. No matter where you’re at in the world. We’ve sent stuff to many remote places.

Where really, is that an address? So this is kind of a self serving question, but I think it goes into like, there was pen testing, then there’s red teaming, and then there’s continuous pen testing, which is the team that Matt and Michael are on.

Is it because you’re on the CPT team that you have the time to be able to do this kind of thing where you can research for a long period of time and then execute across all of the customers that we have?

So since you have a chance to do this for a long period of time, take me through what it’s like to be on a team where you have a long period of time to actually do the work that you do.

Matthew Eidelberg

Sure. so as I kind of mentioned, I kind of alluded Michael is the initial access broker. We all have, titles. They’re not really solidified. But what it really means is like, that is Michael’s specialty.

Everyone helps out, but Michael kind of is the one that is establishing the initial access. He is amazing at that. He comes up with ideas. Most of us, we’re not even thinking about, truly some crazy things he, has come up with.

My type of role is to create those EDR bypasses, malware, develop exploits that he can then use in those ideas to kind of combine.

So if you think about those apt groups, they’re never one person or something else. Everyone has an assigned role in the fold campaign.

And so my kind of job here, I’m always tasked by Corey, our quartermaster, is to kind of create something where, hey, look into us, hey, we’re having a problem with, let’s say in this case it was persistence.

We get onto a box and 30 seconds later we’re gone because something kicks us out. Maybe we’re with all the virtualizations, VDI’s and stuff. The session goes down.

we all do have to sleep, even though the m joke is I don’t sleep. At some point things log off, your system goes idle and then you lose everything. So that was a big driver to start looking at stuff.

So we spitballed some ideas that the team had tried before and failed, or things that are no longer working. And my job was to find something. And when I did, Michael came up with that amazing ruse.

And as we mentioned, Joff, who’s not able to join today, found a way to then take my exploit and create into a nice, elegant wrapper. And combining all those different steps, we were able to create this complex campaign that was highly effective.

And we do that not just with this, but, it could be with social engineering, looking through stealer logs. So everyone has a type of specialty, and we combine them together to create one constant machine that is working as an apt all the time.

So to kind of answer about the time, it’s not just the time, it’s also working in a group and working hand over hand together.

Deb Wigley

Michael, do you have anything to add to that?

Michael Allen

Yeah. So one thing I would add is that on a regular red team, so on a regular red team, most of our red teams are three to five weeks.

And during the external phase of the red team, when we’re trying to break in on our own, we really have to try and do that as quickly as possible, because we got that short period of time.

And that means we have to do a lot of the same things over and over and over from one customer to the next, because we’ve got tools and techniques that we know have a high chance of working and we have to execute those things as quickly as possible, but we have to, it means there’s a lot of repetition from one red team to the next.

And so, I mean, that’s, if that’s the type of project that you’re doing, that’s really what you want to do. You want to be able to execute those things quickly. and I’ll quickly, like, plug my class again, that’s exactly what I like teach in the class is, I teach all the techniques that we do that work, like, rapidly and can be executed very quickly on a very short time box red team exercise like that.

But on CPT, most of our customers, on CPT, I think all the customers actually are the more hardened environments. They’ve all had red team exercises already.

So one, they are the customers who have already fixed all the things that we would normally use to get in on a red team exercise. So those same tricks are not going to work against them because we already told them about that and we’ve been at them for quite a while.

And two, that, yeah, definitely gives us the ability to actually go into the weeds and like, come up with something that is not necessarily a tool or technique that we already know about and already know how to do.

We, get that time to just really dig in and find something that, is going to have a high chance of success against multiple customers. So not just fine tuned for this one, but that really, like, we can come up with something custom that we can then execute against a bunch of different organizations and see, does it work against multiple organizations instead of just one?

Deb Wigley

If anyone out there wants to have us be your friendly apt. because that’s what we are. We’re your friendly apt. We’re not doing it for a malicious reason.

We’re doing it because you want us to, where to find us. we have a couple of questions coming in. I think what we’ll do is harvest questions, see if there’s an opportunity for a blog or something like that. For Matt.

Matt showed me one time he’s got this notebook that he keeps, like, all the ideas that he has. And one day, one day we’re going to do something with that notebook. Because when I saw it, I was like, you were like a serial killer for EDRs.

Matthew Eidelberg

Yes, we’ll have to put that together. I just laughing at them. We’re coming back full circle back to serial killers.

Michael Allen

I feel like Jason’s got serial killers on the brain.

Deb Wigley

No, I know. I’m just heading to a remote location next week. Everything’s fine. I’ll be a wild second fest.

Matthew Eidelberg

It’s a pattern.

Deb Wigley

Yeah. So, to wrap up, Matt, if you could sum up everything today, one final thought, would it be. And, Michael, I’ll have you do the same thing. So, Matt, if you could sum up today, and one final thought, what would it be?

Matthew Eidelberg

Long haul truckers should not be trusted, as they may be serial killers. that was pre shop answer, pre.

Deb Wigley

Show banter, but, yeah, it’s all together.

Matthew Eidelberg

I would say if you are interested in developing or research or looking into anything, there are looking at things. So simply by monitoring how a process behaves, using process monitor, that’s one of my go to tools.

You will find treasure troves of, undiscovered exploits. So if you are interested for either your own personal purposes or for a gig, you’re trying to, establish some sort of thing, there are amazing tools out there.

Just look at the process. You don’t need to know. You don’t need to be an expert in programming or in debugging, reverse engineering. Just look at the process, look at the events, and you’ll start to draw conclusions.

Deb Wigley

Michael, you. If you could sum up everything today in one final thought.

Michael Allen

Yeah, I think, I mean, Matt did an excellent job of breaking down everything he was doing into a much more accessible level and sort of making it simple.

And I want to call that out. That simple is really powerful. A lot of the things that we do on CPT are kind of simple at their heart.

Or can be broken down into a simple way, whether it is a technical attack like this or whether it is a social engineering ruse or whatever it may be. So, yeah, I think that’s really just something to think about, is keeping things simple whenever you’re doing attacks like this, is an excellent way to be able to operate, even if somebody that has a, beginner level skill level, to start getting your feet wet and doing things.

And also, whenever you are more advanced, to, have things that actually work, is keep it simple. It should be no more complex, than it absolutely has to be.

Deb Wigley

Appreciate it. All right, everyone, we’ll be at Wild west hacking fest next week, so if you’re attending, we’ll see you in person. If not, come to the one in Denver. And then the week after that, we’re taking a much needed week of just rest and recuperation, and then we’ll be back after that with more webcasts all the way till the end of the year.

So if you’re joining us, if you’re a part of Hackett. If you keep showing up to these, like, hey, we’ll be gone for two weeks, but when we get back, we’d love to see you again. So thank you for being a part of this community. And please, please, please stay in discord and engage with other people.

Ask questions, answer questions, be a part of the community. because we do. Can’t do this alone, right? Like, we all. Like, when you see this kind of attack, then you’re like, oh, like another one and another one, and another one and another one.

Right? And so being in community, being in a place where other people have the same feelings as you, the same, like, heartache as you, the same kind of, like, worries as you. So that way we realize that we’re not alone.

We’re all doing this together. We’re trying to make the world a safer place, the best we possibly can. And with that, Ryan, kill it with fire. Ryan, kill it.

Matthew Eidelberg

Kill it. Do it.

Deb Wigley

All right, Ryan, teach the other people to kill it.