Proxy Execution with Microsoft Edge WebView2 - Matthew Eidelberg

How do sideloading techniques work in today’s runtime environment?

Join us for a free one-hour BHIS webcast with Matthew Eidelberg on proxy execution via Microsoft Edge WebView2.

Matthew will break down techniques that blur the line between legitimate app behavior and malicious activity, showing how shared runtime components are changing execution and detection boundaries.

You’ll learn how traditional sideloading concepts apply in modern environments, how WebView2 is increasingly embedded across the ecosystem, and how attackers can exploit it to bypass common detection methods.


🛝 Webcast Slides
https://www.blackhillsinfosec.com/wp-content/uploads/2026/04/Proxy-Execution-with-Microsoft-Edge-Webview2.pdf

Chapters

• (00:00) - Intro - Proxy Execution with Microsoft Edge WebView2 - Matthew Eidelberg
• (00:49) - Agenda
• (01:31) - DLL Hijacking
• (04:48) - DLL Proxy Attacks
• (06:05) - Execution Flow
• (07:17) - Windows Apps
• (12:05) - What is WebView2?
• (13:21) - Webview Security Issue
• (16:42) - Domain_action.dll
• (20:01) - Weaponizing the Flaw
• (22:38) - Tooling - FaceDancer
• (24:11) - FaceDancer - Usage
• (25:32) - FaceDancer - Examples
• (27:06) - FaceDancer - Common Questions
• (30:00) - FaceDancer - Caveats
• (30:44) - Microsoft's Response Timeline
• (34:04) - Microsoft's Disclosure Process
• (36:29) - Defensive View
• (38:37) - Wrap Up
• (39:49) - Q&A

Chat with your fellow attendees in the BHIS Discord server:
https://discord.gg/bhis
in the #🔴live-event-chat channel

🔗 Register for FREE Infosec Webcasts, Anti-casts & Summits –
https://poweredbybhis.com

Click here to watch a video of this episode.


Brought to you by:

Black Hills Information Security 

https://www.blackhillsinfosec.com

☯️ Introducing BHIS Fusion Penetration Testing
https://www.blackhillsinfosec.com/fusion-penetration-testing/

Antisyphon Training

https://www.antisyphontraining.com/

Active Countermeasures

https://www.activecountermeasures.com

Wild West Hackin Fest

https://wildwesthackinfest.com

Creators and Guests

Guest

Ashley Knowles

Ashley Knowles joined Black Hills Information Security (BHIS) in Fall 2021. As a Security Consultant, Ashley’s role is to perform network (internal/external), social engineering, and cloud penetration tests, as well as participating in red team assessments. Since joining the infosec community in 2013, she has developed and taught hacking classes, worked as a security consultant, and been a team lead on a red team. Ashley serves as a mentor at a local high school’s cyber security class and, as someone who loves to learn and teach, she looks forward to developing and teaching classes that add to BHIS’s educational catalogue. In her free time, Ashely enjoys photography, hiking and exploring new places with her kids, and building Legos.

Guest

Matthew Eidelberg

Matthew Eidelberg became part of Black Hills Information Security (BHIS) in August 2023. He works as a Red Teamer and Researcher on the continuous testing team. Matthew previously ran the red team at Optiv and the research initiative for Threat. He chose to join BHIS hearing great things from friends and started reading and watching the content BHIS produces. He most enjoys the community and working with like-minded security folks who are passionate about infosec and love to help each other out. When he’s not working, Matthew can be found cooking (mainly barbequing experimentation), reading comics, and, admittedly, creating payload tools.

Producer

Ryan Poirier

Ryan Poirier began his time at Black Hills Information Security (BHIS) as the Video Producer and Editor in August 2020. Ryan polishes and perfects every webcast, podcast, and workshop on the BHIS, ACM, and WWHF YouTube Channels. Prior to Ryan’s time at BHIS, he worked for one of the largest public schools in the United States, conducting their video production and live broadcasting. He joined the BHIS team because he felt like it would be a great group of people to work with, and he couldn’t pass up the perfect next step in his career. Outside of his time with BHIS, Ryan does freelance photography, attends Cars & Coffee events, and expands his knowledge of audio and videos.

Guest

Tom Smith

Tom Smith joined the Black Hills Information Security (BHIS) team in 2021 as a Business Consultant. He works with clients to identify their correct testing solution needs and proposal requests. Prior to his time at BHIS, he directed a business operations team in real estate. He decided it was time to make the switch when he realized he could work from home and fell in love with the energy at BHIS. Outside his time at work, he is a father to seven children, enjoys reading, playing guitar, and home improvement projects.

What is BHIS Webcasts?

Podcast audio-only versions of weekly webcasts from Black Hills Information Security

Ryan Poirier: 00:00

Alright. Hello, everybody. Welcome to the BHIS Webcast for today. We've got Matthew Eidelberg here. He's gonna talk to us about Microsoft stuff because I keep forgetting exactly what the title is, but he's gonna tell us anyway in just a moment.

Ryan Poirier: 00:15

I'm gonna go backstage, and at the end of the webcast, we're gonna come back. We're gonna talk about questions that may have come up and maybe more food stuff or not. But, anyway, it's all yours, Matthew. Take it away.

Matthew Eidelberg: 00:29

Thank you. Let's get started. So the title is proxy execution using or with MS Edge WebView2. So we're gonna kinda talk about a lot of concepts today, some old, some new, and we'll kinda bridge between them. So, of course, as I mentioned, some olds.

Matthew Eidelberg: 00:52

We're gonna kinda recap DLL attacks just to level set the knowledge. There have been a lot of research already done in these types of attacks, including some stuff I've done over the past year or so. We're gonna then kinda talk about Windows apps, what they are, what what do they do, what what why are they even around? And then the security issues. That's why we're here.

Matthew Eidelberg: 01:16

Security around them. How can we exploit them? Kinda talk about the Microsoft disclosure process, all the adventures that went through that, and then kind of end this discussion with how you can protect your organization. So to kinda begin, let's talk about DLL hijacking. At a very, very, you know, quick ten second elevator pitch, DLL hijacking is the act of taking a DLL and basically putting it in the load process, whether it's you put in the folder, you force the process to redirect its execution to look at that DLL.

Matthew Eidelberg: 01:55

But at the end of the day, you basically are tricking a trusted application that is on an endpoint to load a malicious DLL. These attacks have been widely used for not only initial access, but also they're a great fantastic persistence method as, you know, trusted applications are always gonna be on a system If they're ones that a user constantly use, even if the system is rebooted, they're always gonna be turned back on. So, you know, some great examples that we'll be talking about will involve, like, the Office Suite, Outlook, Excel, Word, web browsers, you name it. But there are also times where you can use these types of attacks to hijack and gain an elevated context or privilege escalate on a new machine. So you go from a low privilege user to a high privilege user, which can be very bad and give additional access, which is typically the goal of most engagements or more most attackers is to break and get some additional privileges, pilfer as much data, and then get out before being caught.

Matthew Eidelberg: 02:56

So I mentioned DLL hijacking. There is DLL sideloading, and then there's search order. So as you can kinda see, we already talked about DLL hijacking, but sideloading basically is when you drop a DLL into a folder where another DLL gets loaded. Now what happens in this case is that a couple things have to kind of occur, which is, first off, is that you have to have write permissions on that folder. And then, essentially, you rename the legitimate one and deploy your malicious one as that legitimate one.

Matthew Eidelberg: 03:33

So what that would look like is your evil one gets loaded, and then that evil one loads the legitimate one because of the name. Now DLL hijacking, looking for missing ones, has been a thing that's been slowly creeping away as the introduction of Windows apps. But essentially, this is where in applications when things are being compiled, sometimes what they do is they do a search order. And this search order says, hey. In the process, I need DLL x.

Matthew Eidelberg: 04:07

Can you please look to see where it is? Well, it's not in this folder. Let me go check the system. Where does the system you normally keep it? And between those two boundaries, if you place a DLL with that name, the pro the system goes, oh, I found it for you in the first place you suggested to look.

Matthew Eidelberg: 04:22

So then it loads it, and it's not necessarily the right or legitimate one. So there's a lot of different attacks. And throughout the years, Microsoft has taken steps to remediate, mitigate these with secure programming, encoding, compilation controls, as well as proper guidelines and other mitigation controls to help close off a lot of these gaps. But as we're here today, there are still some. So as I mentioned before, to be able to do these types of attacks, especially the ones we're gonna really be focusing on, there are some key things that have to be we have to have, and they have to be acknowledged because then the attack does not work.

Matthew Eidelberg: 05:02

The first thing is write permission. Wherever we're gonna drop or wherever that DLL that the trusted application we're gonna target loads that DLL from, we must have write permission. And where that comes from is not just like c program files. That's a lockdown place. That is a secure place.

Matthew Eidelberg: 05:24

But not every application installs or stores sensitive libraries in program files, and that is the big a lot of the big problems. You can see it in temp, random directories. The biggest one, however, is app data. And so all you have to do is take the DLL, drop it in the folder, rename the old one, and make sure that there's some kind of bridge mapping with that malicious DLL that says, hey. Once I'm loaded, load or pass any requests I get to the valid DLL.

Matthew Eidelberg: 05:59

So that way, the process is stable and ensures that there's no performance issues or any type of instability. And this is what it kinda looks like. If you if you're a visual learner like me, this can kinda help. So as you can kinda see, process loads, process dot e x e, excuse me. It says, hey, I need this function, function a.

Matthew Eidelberg: 06:19

Well, we are loaded. Our malicious DLL is loaded. In the background, our code, whether that be, like, a callback or, you know, some kind of Cobalt strike or maybe other shell code is running in the background. But as the process says, hey. I need function a to do something, we take that request and proxy it to the valid DOL that's in the same folder.

Matthew Eidelberg: 06:43

And that's another key thing is that all of this is happening just because we've renamed it and mapped. And so this is a very common issue, especially when you look at third party applications or things that are not native to the Windows OS. You see this a lot with old school Outlook, Microsoft Teams with version dot dll, f m m pag, DLLs, or anything with Skype. So a lot of kind of things that are common in business, but are not native to the Windows operating system, you see these types of attacks prevalent in. And that's kind of the big driver around Windows apps, which is what Microsoft's been pushing.

Matthew Eidelberg: 07:22

So if you ever started wondering and noticed, hey, my Outlook looks different. My the icons have changed. So, you know, my plugins, my my word Excel macros, add ons, everything's kinda changed over the past two years. That's all been kind of a silent push towards these Windows apps. And what they are are essentially a sandbox container, kinda like a web application.

Matthew Eidelberg: 07:48

If you're familiar with electron apps where they're all self contained. And there's a lot of value in great steps towards securing an endpoint with these because they don't typically require installing a large list of dependencies or files, so you don't have hundreds upon hundreds of files dropped all across your your user's profile or on the the endpoint itself. What you have is this container localized protected box, if you will. They're essentially developed and designed like a web app in a Windows application. So they're lightweight, they're fast, and they don't take up a lot of space.

Matthew Eidelberg: 08:30

So we talked about a lot of the perks, but from a more technical side, there's a lot of security controls that it kind of naturally alleviates. So it shifts a lot of the application around to signed and trusted controls. So no longer having to worry about third party dependencies, missing drivers, having to have or open up comm or turning down security or hardening controls. It also means that legacy installers, like, that you would have different versions or incompatibilities between controls or even just usage on OSs go away. So those risks are gone from the users, the administrative, and all that stuff.

Matthew Eidelberg: 09:13

But from a security side, there are integrity checks. So if all of a sudden someone's been tampering with it or tampering with a file that is needed to run that sandbox, the application can't run. Smart control, huge thing. It also means that there's less permissions that need to be given if you have strict application allow listing rules. So all these things kinda really work with Microsoft's ecosystem that they've been moving towards where, you know, if you've noticed with a smart screen and everything else, to kinda eliminate not only the security boundaries, the third party dependencies, but the injection points there, all while keeping a sleek, elegant user interface and experience.

Matthew Eidelberg: 09:53

And it doesn't just be go beyond. I mean, I've just listed a few here, but as you can kinda see the theme here is that a lot of these are products that are day to day business from everyone using Teams, everyone uses Word, Outlook, and these days with the induction of AI and Copilot. So Photos, Spotify, all these apps have or are, I should say, Windows apps, and there's more and more being added. Think so I was just talking with someone that calculator's been moved into this. Task manager is kinda gonna be aimed.

Matthew Eidelberg: 10:32

So there there's a big push that all kind of day to day applications that are very heavily usage or relied on on the Windows OS will be moved to these types of Windows apps for secure reasons. And if we even look at it further so this image actually shows where the Windows apps are stored. And I am an administrator on this box, but I don't even have access to it. That's because of the security controls. Only trusted installer has access to the folder itself.

Matthew Eidelberg: 11:03

Now you can, you know, modify it. You can become you can do a bunch of series of escalations or other things to then get access to the folder. But at the same point, those are the security boundaries that when you do those types of attacks, you've already triggered an alert or something else. There's a bigger goal in mind. So initial drive by attacks, initial access, or quick persistence attacks go away.

Matthew Eidelberg: 11:26

And so by and large, this protects them from a lot of these DLL based attacks, side loading, hijacking, you name it. They're all kind of mitigated because of a lot of these controls, if you can remember. And I said at the beginning, one of the major key things is write access. We clearly don't have that. So Windows apps.

Matthew Eidelberg: 11:49

As I mentioned, they are containers, but this is where it gets interesting. They depend on this runtime engine called Microsoft Edge WebView2. And this this is what we're here to talk about. This is where the problem is. So what is WebView?

Matthew Eidelberg: 12:07

Well, it's a Chromium engine very quickly. It uses the same sort of kind of engine that you'd see in a Linux open source Chromium applications, sort of thing like that, but Microsoft has adapted it to kind of just for the sandbox running of their own applications. And that's kinda where the Chromium ends. But it's really used, like I mentioned before, to help render that web application. So that way, you see all the content and everything else.

Matthew Eidelberg: 12:36

And so with WebView, these applications need it to actually be able to render important things. Basically, anything from a visual, interactive, dynamic content. If you think about Outlook, when you have calendar, when you have meetings, when you have things that are like, hey, you have a meeting, please click on this link, and then it loads up another application. All that type of rendering and cross application access is handled by WebView2. And so there is a need that while it's just a lot of the focus around the GUI at running a web app, there is a huge focus on how does it interact with the OS.

Matthew Eidelberg: 13:17

And so when we talk about security, this is where looking into the research side of it, I discovered a couple things, and that's really what we're here to talk about. So the security issue with WebView. And it comes back down to DLLs. So through investigations, as I was looking at these, I started noticing WebView2 would always load a DLL called domain actions. And what I noticed was this DLL was not inside that protected folder.

Matthew Eidelberg: 13:50

It was actually in the user's app data. Now different applications would load this DLL from a different place, which is its own security issue. If you think about how many applications I I kinda listed, if they all have their own different path that have their own version of it, but it's the same DLL, that's many different attack avenues across a wide spectrum of applications. But what's more impactful is the fact there these DLLs are outside of the sandbox. They're in a writable path, and they are needed for WebView2 run.

Matthew Eidelberg: 14:25

So if you kind of disable, delete them, remove them, block them, WebView can't run, which means these applications can't run, which means your business can't run. And because of where they're natively looked at, if you delete the folder path and you open up Outlook again, it'll say, hey, I'm missing this DLL. Hold on. Let me repair, and it'll just reinstall it again. So it's a circle of it lives in the app data because that's where it was developed.

Matthew Eidelberg: 14:54

So this by and large reintroduces DLL hijacking attacks. And because of these isolated sandbox controls, it bypasses the application allow listing rules because this is core things inside the Windows OS, Office, and they're critical DLLs, essentially. So all you have to do is drop it in and load these applications. You know, you don't have to bypass any type of deny lists because every company needs these to run. And some in some cases, I've even seen the Windows search field, like, where you search for an application or say you're looking for files, it uses WebView these days, especially with Windows 11.

Matthew Eidelberg: 15:38

So it's all core components of the OS and the extension of other applications. And this deal lives outside the sandbox and outside of all the controls. So you can kinda see right here. This is an example of Microsoft Teams. So Microsoft Teams is running.

Matthew Eidelberg: 15:57

The process ID is 1012. And you can see there's a series of processes, child processes of WebView. And if we look at process monitor, you can see there's a load image call, which loads a DLL image. And you can see on this user, you see user low privilege app data local packages, so on and so forth. You can see it's a long string, but it's loading a DLL.

Matthew Eidelberg: 16:26

And it's MS Edge WebView, and it's a parent it's a child process of when this Microsoft Teams app, which is a Windows app. So it's like this long, long, long chain to go back to the old way of doing these DLL attacks. Now what's more scary and more impactful is these DLLs are kinda signed. They're trusted. And as I mentioned, they are part of the edge domain components.

Matthew Eidelberg: 16:53

So they're actually part of MS Edge as well, which makes it even harder for you to deny block or kind of nuke it off your environment because Edge can't even run without it. And what's more interesting is as I started peeling back this onion, trying to understand what this DLL is, you kinda start seeing there's not been a lot of research around this. There is very little documentation. What documentation there is is kind of kinda listed here, that it also helps support smart screen. It handles security controls.

Matthew Eidelberg: 17:29

It also does domain reputation checks, which are all things that when you take a step back and you look at it, that's what a browser or anything that has an embedded web application inside it needs. You know, smart screen to check security policies, domain checkups for any type of applications or places it calls out for. So there is not just this erroneous DLL that's been lot you know, kind of been installed like an appendix, if you will, to these smart things. But this is actually a DLL that provides critical functions to WebView, which provides critical function to Windows apps, which provide now critical function to users. So you kinda see how it's all stacking together.

Matthew Eidelberg: 18:09

And so what better way to describe it, but then this image itself. Because at the end of the day, this one simple security feature that is everything's being moved towards. If there's no kind of putting this genie back in the bottle, reversing, everything's already there, we can't stop this. But it's built on something that's completely flawed. And just disabling it or even removing it will cause all these applications to disable.

Matthew Eidelberg: 18:42

In fact, I did a little test on a Windows 11 box. I couldn't open Explorer, couldn't search a file, couldn't click on the task manager, you name it. So many things just started falling apart. No blue screens, I wanna stress that, but it made the box almost unusable. And what's even more interesting is Microsoft wasn't even aware of it because they actually recently had to patch via security updates because AppLocker was blocking it.

Matthew Eidelberg: 19:13

So that kinda tells you, like, the left hand and the right hand are not communicating when it comes to applications, development. So this is becoming, as you can see, a very big impactful attack and design flaw inside this ecosystem of secure apps. And we talk about the secure apps, lockdown, sandbox, container, but we're still relying on legacy kind of philosophies. And no one's telling the other side, hey, we have this dependency. It has to live outside the sandbox.

Matthew Eidelberg: 19:45

Here's the reason why. Instead, it kinda gets pushed to the users, and then it's like, oh, wait, we're having problems? Well, I'm gonna have to do a security patch to fix it. And I had to do some deep digging to even find this type of reference, because this kind of swept under the rug. But to kinda go back, how do we weaponize this?

Matthew Eidelberg: 20:05

So as I kinda mentioned before about passing the execution at the beginning, what really happens here is you just have to take a definition file. A definition file kinda dictates how the exports operate. And what's interesting is is that you can take an export function file and basically just say, hey. If this function get domain action URL, that's a long string, Go to this DLL, well, domain underscore action dash old, and then the function name. So it's kinda like a mapping of, like, apples to apples.

Matthew Eidelberg: 20:43

So as as they're in the same folder, it kinda says, hey, this function gets called. I'm gonna go take a look at this DLL and their function. And that's pretty much the type of attack you need to perform. So we see right here, here's a quick example of using that same definition file I just showed, dropping it into this folder. I have taken the legitimate domain actions, renamed it to dash old, put ours in, and ours just says, hello, Rust.

Matthew Eidelberg: 21:11

Hello, world from Rust. I then launch again, And as you can see, Teams is running. You can see right here, it's popped up. And if you go and look at the deal that's loaded, you can see all our functions. And then right off to the side, the VA value says, no.

Matthew Eidelberg: 21:28

There's no virtual address. Just go look at this DLL, and that's where you need to go. So it's not that complicated of an attack, but it's quite effective. And if we were to take this a step further, what happens when you weaponize this with shellcode? Well, this is where it gets kinda dangerous because you see right here, we have, in this case, an example of using Outlook.

Matthew Eidelberg: 21:53

Like I said, tons of applications that people use on a day to day are relying on this. So OLK is Microsoft's new Outlook. And so same sort of thing, drop the DLL, put it in. We put a different name on it, and I'll kind of explain that reason why when we talk about the tooling in a moment. But for the most part, it's the same attack we just talked about.

Matthew Eidelberg: 22:21

And if you look, it loaded and we have a callback. We are running as MS Edge web. We are under o l k as a process. All we had to do is drop it in there and have the user run Outlook. So the tooling.

Matthew Eidelberg: 22:40

Last year, as I started down this journey of these types of attacks, I created a tool and we had a webcast called FaceDancer. And this kind of tool did a lot of DLL side jacking, hijacking, side loading, you name it. And it also had a mechanic in there to do the recon to actually build these. So we've just continued by adding these features that we're talking about today into this existing tooling since this tooling is now what we call, like, the Swiss army knife of persistence or the Swiss army knife of DLL sideloading. So I wanna stress here because there's been some confusion.

Matthew Eidelberg: 23:18

We're also gonna talk about how to use it properly now. But I wanna stress this tool is not a payload evasion tool. This is strictly for creating hijackable proxy based DLLs. It has two functionalities. One, you can give it a DLL, and it can scan and create that export definition file.

Matthew Eidelberg: 23:37

So if you find these because there's tons. There's some things I haven't found yet. So if you find them, like maybe third party apps or anything else, you can actually take the same methodology we've just talked about, point FaceDancer at it, and it will create you that definition file that you can then use to create a side loadable DLL. The attack module, which is the second one, takes whatever your DLL shell code is and creates that malicious DLL that you can then use for side loading or any type of attacks. But again, it is not a typical payload tool.

Matthew Eidelberg: 24:15

Doesn't you don't just give it shell code, and it does everything. And the reason why is that this tool is solely focused on DLL attacks. It's not focusing on bypassing EDR. It's not by it's not focused in on dumping LSAAS. It's strictly focused around DLL side loading.

Matthew Eidelberg: 24:32

And the reason why I chose to do it this way is so that way, not only can we focus in on making sure that whatever you're you need going back to that theory of a Swiss army knife, if you need specific bypasses because, you know, maybe no two environments are the same. Maybe you need something special for environment a that's different from environment b. You take all what you need or what you know works best, or maybe it's your own tooling and you like to keep it in house. You can pile that with your shellcode into a DLL. FaceTester takes that DLL and turns it into a side loadable DLL for whatever process you chose based on the arguments.

Matthew Eidelberg: 25:12

This also means that you provide the evasion. There's no real evasion, like EDR unhooking, ETW patching, AMSI bypasses. It's all on the user. So it's very important. And I kinda stress, this is so the operator can bring the right code for the right job.

Matthew Eidelberg: 25:32

So when you do it, you basically specify dash I for the DLL, and you specify that compiled DLL. There's a lot of great tools. There's a lot of great stuff. And as much as I hate to say, if you're struggling to make a DLL, ask your AI overlords. They can help you.

Matthew Eidelberg: 25:49

Not to say to always run and use AI for every malicious code. I wanna stress that. But there are tons of pieces of code out there to help take shellcode and turn it into a DLL. If you're going down this road, it's very important to have some kind of blueprints like that so you can mix and match features. You shouldn't be always using the same toolkit.

Matthew Eidelberg: 26:07

You know? Don't wanna bring an electrician to go fix your plumbing, so to speak. You specify the dash o for the output of the DLL. The d is the type. So in this case, we're gonna be may targeting that DLL domain action.

Matthew Eidelberg: 26:21

But there's many different features in there that you can do process, you can do com based DLL attacks. All the different arguments are there in the help, and then dash x for the export function. And then once you run it, what you can kinda see is a series of instructions of what's going on. You can also see at the end, all the different places you can drop this domain action to date that you could then use to exploit this attack. So right now, there are six places.

Matthew Eidelberg: 26:53

The multiple applications use the same place, Office Hub. That's a lot of the Office tools. MS Team is different than Outlook. Edge is its own thing, but there's tons more there. As I kinda mentioned, I was gonna talk about a bit about how to use this.

Matthew Eidelberg: 27:09

And so I kinda gathered a bunch of the common questions I get asked. So, again, why does it take shellcode? And we talked about bringing the right tools, but from a more development point of view. And the reason for this is that when we look at detections or preventative attacks, a lot of times what happens here is tools that are public get IO seed or or detections built that are solely focused around some kind of mechanic or the shell code itself. This approach avoids a lot of that, and it actually forces detection or any type of detection engineers to look for the behavior of sideloading rather than some kind of indicator of, you know, NT DLL being unhooked, MZ being loaded, or something else like that.

Matthew Eidelberg: 27:55

So it really puts the onus on how to detect this on sideloading itself. And that's really important because that's where the value is. You can always bypass EDR. You can always bypass a specific static detection. But looking at the behavior that we're trying to exploit is a lot harder to do.

Matthew Eidelberg: 28:15

Another common question, what's with that random word? So as I mentioned, we have to drop the file into this into the same folder as the legitimate one, but you can't have two files that have the same name. So what happens here is you have to change one. So when you do that mapping, you have to create a mapping to a name that you know. So by adding some kind of random word to the front of it or to the back, FaceTime allows you to do both.

Matthew Eidelberg: 28:43

You can choose what side, you know, at the front of the of the DLL's name or at the end. You not only change you prevent it from overriding itself, but you also prevent any type of detections, again, that rely on static names. As I mentioned, there's many different places. So if there's a rule that said block or alert on domain actions .dll being loaded, there would be a 100 false positives because it's so widely used by such critical applications in an OS that it would flood any type of analyst or SOC team. So that's not the right way to approach detecting this.

Matthew Eidelberg: 29:22

And it also helps prevent any types of business interruptions because if you block or have any type of EDR rules that say block loading this DLL, you're gonna cause your users not to be able to work, and then companies can be pretty upset. So there is business applications and reasoning behind this, but also offset controls. And you can kinda see right here again, focus in. That's why we have this is so that way you can have the same DLL that does the same sort of thing. But without the name collision, they're able to run and coexist in harmony in the same folder.

Matthew Eidelberg: 30:01

So the last kind of question is kind of the more critical one is, okay. I have that DLL you want me to create. How do I tell FaceTancer the export function name to run that will trigger my shell code? And that's very simple. I've kinda made this really easy.

Matthew Eidelberg: 30:18

It's just the dash capital x flag. You can specify anything from run, execute, do bad things. And Face Sensual will say, okay. When I load this DLL that's embedded, I'm going to find the export function name, whatever you gave me, and that's the one I'm gonna call. So it makes everything kinda seamless.

Matthew Eidelberg: 30:38

So with all of that, now let's kinda switch over to the disclosure part that I mentioned. I know I've thrown a lot at you, and this is a large wall of text, so I'll kinda quickly highlight over it, but you can read it. We discovered this back in September last year, and we once we kinda gathered and figured followed through and figured out all the large understanding of this attack, we informed Microsoft. We went back and forth for several weeks, and they confirmed the behavior. It was quite impactful and warranted remediation immediately and a possible CVE.

Matthew Eidelberg: 31:16

It's great. While we went back and forth, we kept on finding new applications. As I mentioned, these were kinda popping up like whack a mole that were vulnerable. And we did we did three rounds of this, of multiple applications. And they said, that's great.

Matthew Eidelberg: 31:34

Please stop sending these. We get it. So I stopped sending them. Around 12/03/2025, I got a message saying that the team needed more time to work on the vulnerability and that the fix would probably need another ninety days. So they were asking for an extension and that they were targeting a patch Tuesday closer around March.

Matthew Eidelberg: 32:01

Excuse me. So we discontinued monitoring the situation and everything else, but it seemed very promising until March, where I received an email that Microsoft had re reviewed the case, and this is almost a week before the the expected date of everything going live, and said that they reclassified the impact, and the new filing fell below the threshold to awarding type of CV. And unfortunately, because of that, they were gonna no longer move forward with a fix at this time. I wanna stress at this time. But we went through a six month long disclosure process and only to have it at the last minute reclassified.

Matthew Eidelberg: 32:53

And what's kinda startling is, as I mentioned, they actually went through a long portal of we need more time. The edge team needs an extension. We are actively working on it to after almost half a year. We reclassified it's not that impactful, which as the developer who's played ball, you know, all the information they gave all six months worth of back and forth was quite frustrating. And there there is a lot of impact for enterprises as we kinda discussed.

Matthew Eidelberg: 33:32

So what is the current result or status? These are being classified as forever days, which are vulnerabilities that will be exploitable in Windows 10 and Windows 11 forever due to the fact the vendor does not intend to fix them. As of right now, that might change, I wanna stress. But as of last communication, they have no plans on fixing this. So all Windows endpoints right now that run Windows 10, Windows 11 are vulnerable to these types of attacks.

Matthew Eidelberg: 34:06

So I'm sure you're wondering that doesn't seem right. Well, if you've been following the news, this isn't the first time. In fact, for me, this is just normal. This has happened to me so many times and many other researchers I've talked to at various different other companies. Microsoft's disclosure process is quite flawed these days.

Matthew Eidelberg: 34:25

And as a result, what we are starting to see is developers and researchers being frustrated. And if you followed the news a couple weeks ago, BlueHammer got dropped. If you're unfamiliar, very high level. BlueHammer was a local privilege escalation attack that is inside of Microsoft's Defender AV agent that's on every Windows machine that allows the user to go from low privilege to elevated. The developer or researcher, I should say, who disclosed this was tired of the kind of the same story that I just described to you that happened to me.

Matthew Eidelberg: 35:03

And so provided the code, detailed instructions, information on it, but just went public with it rather than let Microsoft sweep it on the rug. And this is happening more and more. I just before last week, I talked to another friend who had a very similar experience with Microsoft kind of changing their their their mode or reclassifying the vulnerability days before they were supposed to have it fixed and pushed into patch Tuesday. And as a researcher, it sucks. But if we all take a step back and realize there's actually a bigger issue here.

Matthew Eidelberg: 35:40

The bigger issue here is that enterprises are suffering because of this. Attacks are still happening. And what is going to happen is these forever days are going to constantly be used as a point of attack against companies, and companies are not gonna be properly equipped to defend because they're relying on a vendor to fix these bugs, but they're kind of pushing them off to the side. They're acknowledging them, but they're not doing anything about that. So that's great for them, but businesses suffer.

Matthew Eidelberg: 36:14

And that means their customers suffer from breaches and stuff and the loss of their own data that the the company that they give, whether it's payment information, you name it, wherever they're processing, that thing gets leaked. So at the end of the day, we end up suffering as well. So what can you do? Well, with regards to what we've discussed today, here are some steps we found that our clients from the anti SAR team. So that's our continuous testing where we do twenty four seven red team pen tests, where we we we kinda discovered these.

Matthew Eidelberg: 36:48

We worked with their defensive teams to see how they would mediate. We've seen how they've reacted, and there's been some very positive information that I wanna share. So we've seen where the blocking and detecting of not only DLL is being downloaded, but even in a ZIP format. We've seen clients who were tested against this, who then implemented something like this, and then on tests, they may not have been able to block the initial attack, but they gained greater insight, which means that they were able to react faster. So from, hey.

Matthew Eidelberg: 37:20

I can't block this to at least I can detect on this, and now I can react faster to this. Cutting that dwell time down to a minimal amount, we've seen a lot. But at a high level, the things you're gonna have to do is whether what security controls you have in place, you have to look for several things, and most of them are luckily very similar. It all revolves around the user's app data space and looking for anomalous things, specifically DLLs. So how can you tell an anonymous anomalous DLL in an app data from a legitimate one?

Matthew Eidelberg: 37:52

So these are, like, the kind of the three common things we've seen where that can kinda give a defensive team some kind of information to start investigating first. Any DLL that has had a recent compile time, any DLL that's not signed or signed by Microsoft or a trusted vendor, and then ones that have a unique cache that haven't been seen on other machines. So if you have your security teams systems that are indexed, and say the domain underscore actions DLL hash is different on Joe's machine than it is on the one you're investigating, that that should be something where you start leaning into it and looking into it. But these are all things focused around trying to be proactive or reactive rather than mitigate. So to kinda wrap up, I tried to keep this quick short because I know there's a lot of technical content here.

Matthew Eidelberg: 38:44

DLL sideloading is still very impactful. It bypasses application allow listing controls, which was kind of what they were supposed to prevent. We're finding new ways around and new techniques or new attacks every day. Windows apps were supposed to be the new secure sanitized way of containerizing applications, but they're susceptible to DLL side loading just the same way, using legacy attacks because of MS Edge WebView. Microsoft is not gonna be fixing this anytime soon, leaving enterprises vulnerable.

Matthew Eidelberg: 39:17

If you wanna take a look at how to exploit this, test it, play around in your own environment, FaceDancer is your number one to go to. There are other tools to do this, but it's already there. And if you wanted more information, you can look at the blog or even at the the GitHub repo. Any questions? Or is anyone awake?

Matthew Eidelberg: 39:44

I might have put people to sleep. If I do, I apologize.

Ryan Poirier: 39:50

Very well done there, Matthew.

Ashley Knowles: 39:55

Great job, Matt. Thank you for that.

Matthew Eidelberg: 39:58

Thank you.

Ashley Knowles: 40:00

Woo hoo. So we talked about what did we talk about? Face the antidote. There it is. Yep.

Matthew Eidelberg: 40:08

Seriously, man. We talked about something.

Ashley Knowles: 40:11

I was I was poor. I was partially paying attention. I was trying to listen to you while looking at other work stuff that was happening. But what if you want to come to Black Hills and have someone like Matt supporting our pen testers and doing like, an assumed compromise with with the tools that he demoed today. How does that look, Tom?

Tom Smith: 40:32

Oh, man. Well well, I'll tell you there's a couple of ways you could do it. I know. Yeah. Way to switch.

Tom Smith: 40:37

Set me up. Jeez. No. It was great. No.

Tom Smith: 40:41

No. It's it's good. I mean, you know, so so it's funny. We have a few people on this meeting who who actually do that

Matthew Eidelberg: 40:47

sort of work, Ashley.

Tom Smith: 40:48

I think we have we have somebody somebody named Matt and another person named Ashley, both of whom do that.

Ashley Knowles: 40:54

Shocking. What's going on.

Tom Smith: 40:55

Yeah. I know. So if you wanna reach out and have BHIS, you know, have fun doing this stuff with, you know, on on your environment, then all you gotta do really is is is you gotta go through me, and I promise I'm not scary. I'm easy. But, yeah, essentially, you go out to our website, you hit the contact us form, they get in touch with my team, and we end up getting on the call, and, you know, I ask you questions about, like, what do you what do you what are you doing

Matthew Eidelberg: 41:24

now? What are your hopes? What are your desires?

Tom Smith: 41:26

What are dreams? You know?

Ashley Knowles: 41:28

Yeah. That's what keeps you up late at night? Is it DLP? Is it, you know, what what Do

Tom Smith: 41:35

you like long walks along the beach? Candlelit dinners?

Matthew Eidelberg: 41:38

Yeah.

Tom Smith: 41:38

Cheeseburgers, you know?

Matthew Eidelberg: 41:40

Do you just want

Ashley Knowles: 41:41

to tell us about security and

Matthew Eidelberg: 41:43

Hard cooking.

Ashley Knowles: 41:44

Years of AI?

Tom Smith: 41:45

Yeah. Or or food, that's another thing. Yeah. Yeah. We're happy to do all that, all the above.

Tom Smith: 41:52

No. It's good. Yeah. So that's what it is. I mean and ultimately, I mean, when we're working these you know, when we're working with a client, I mean, we're we're the reason we do these webcasts and stuff is because really when security at one organization, you know, at an you know, in be it private, public, whatever, is you know, takes a step up.

Tom Smith: 42:12

When whenever somebody ups their game in terms of security, everybody wins. Right? You know? So so BHIS is a for profit company. I mean, you know, like, we wanna we wanna make money so that we can get paid and, you know, put food on our tables, more cheeseburgers and smoked meats and things.

Ryan Poirier: 42:31

Wanna get more free webcasts.

Tom Smith: 42:34

Yeah. More free yeah. Try more free webcasts. So but yeah. So, I mean, you know, we're pretty low pressure when it comes to business.

Tom Smith: 42:39

We don't have, like, a formal marketing team or anything. I don't I am I am, like, a sales guy, but I get no commission. So if we get on the phone and you ultimately don't wanna work with us, like, I it doesn't snow skin off my back or or back anybody here. So yeah. That's that that's the long and short of it, Ash.

Tom Smith: 42:57

You know? So Cool. Yeah, man.

Ashley Knowles: 43:02

Thanks for explaining that. We had a really great question. Does anyone have any questions? I don't see any questions in Zoom.

Ryan Poirier: 43:13

But Someone is saying that the blog link is not working right now.

Matthew Eidelberg: 43:21

Well, the other alternatives, if you're following BHIS on Twitter, there is the post that was done yesterday on International Bananas Day.

Tom Smith: 43:34

I have I do see some questions on

Ashley Knowles: 43:38

Yes. I just seen them. Yeah. So Ah, okay. How do we get the DLL onto the victim's system?

Ashley Knowles: 43:44

I I guess that is chef's choice there. Matt, do you wanna do you wanna go into the nitty gritty, or do we wanna keep it vague?

Matthew Eidelberg: 43:55

I mean, it all depend like I said, it all depends on your situation. If you're spearfishing, it all depends on your ruse. A lot of times what we find is rather than, you know, having direct click payload, having some kind of thing that kind of drops it to disk or installing something innocuous or having something where it's just like, hey. We're going to make it look like we're doing a bunch of visual updates, but in the background, it's just, you know, almost w getting down a file and putting it in the right place can work. Macros, VB, it all depends on your rules.

Matthew Eidelberg: 44:30

If you have the ability to get file access or you're trying to move laterally, and a great way to do that is just by dragging and dropping or, you know, using whatever tools you need to. Trying to keep that vague, but what we kind of avoid is rather than it being a secondary thing where it's like, hey. I'm gonna get a beacon first via shell code or some kind of attack. We use this as our initial rule. Like, hey.

Matthew Eidelberg: 44:54

We're from IT. We need to do some updates or send some kind of email that forces them to click. While the application itself is not there's no shell code. There's no unhooking. Things, like I said, that would normally trip up.

Matthew Eidelberg: 45:07

All it's doing is pulling down a file from the Internet, putting in the right place, making those changes, and then the next time the user boots up or runs something, our DLL kicks in. So that's from the very stealthy kind of view. If you're already inside the network, say, maybe you're doing, like, a pivot, breach, or soon comp, whatever you can your team calls it. If you have access, it's as simple as, you know, using the file share, even, like, you know, slash slash computer name slash the path, changing the files there. So this attack allows you to do it in many different ways depending on your situation.

Matthew Eidelberg: 45:42

It just comes down to write access. Can you script it into, like, a ruse, or do you have the ability to manually do it yourself? So it's those different perspectives.

Ashley Knowles: 45:52

On the flip side, how do how does the blue team easily detect an attack like this?

Matthew Eidelberg: 45:59

So if I go back in my slides a sec, these two major things have been what we've seen being very effective by actual field tests where we've used this on clients. One client in particular, they they made custom rules the second time around when we did another round where it was not only just blocking the download of DLLs, any type of zips that had a DLL in there. That was one great trick because, you know, as I just just described with the, like, type of lure red teaming sort of thing, if they can detect the the download, the byte stream, and all of this byte stream, it has the headers of a DLL. Bam. Alert.

Matthew Eidelberg: 46:45

Whether or not it's something like that, they're not blocking, but then they investigate it, and it goes from, you know, being completely unaware to, hey. I got access for twenty seconds, and then I lost access. That's the difference. Sometimes in especially when you get down to how nitty gritty or cutting edge these techniques are, it's not so much, hey. We have to block everything right off the bat.

Matthew Eidelberg: 47:05

It comes down to dwell time. We talk about this a lot with our clients, which is how long do we dwell in an environment before you know or see something weird or some kind of, you know, spidey sense goes off? Is it a minute? Is it an hour? That's alright.

Matthew Eidelberg: 47:19

Like, you know, there's natural things like data aggregation, everything else. But if it's like a day, a week, a month, think about how much time an attacker can do in a day in your environment without you knowing. Think about how long or devastating it can be for two days or three days. So having proactive control is not so much as say, block, block, block, but detect things, and then have an analyst go investigate, which comes to the second point. Looking at those past, looking at the app data.

Matthew Eidelberg: 47:47

Hey, all of a sudden we saw a weird, you know, on Joe's computer, his Outlook loaded a weird domain underscore actions file. It has it was compiled yesterday. It's not even signed by Microsoft. Like, things like that. Oh, wow.

Matthew Eidelberg: 48:03

That's we should go take a look at it. Let you know? Okay. Wait. That the hash of that file is different than the one on my computer.

Matthew Eidelberg: 48:08

That's really weird. All of those types of questions or narratives kinda lead to, I need to go investigate something's off. And the more that happens, we say well, I I tell especially a lot of malware devs and stuff and people in BHIS. If those questions are being asked by a team, a security team, you've already lost. Because eventually, that's the snowball that goes down the hill until it turns into an avalanche of detections.

Matthew Eidelberg: 48:33

When they start questioning things or seeing things that you've done, even if it's a small thing, maybe it's not like l s s being dumped. The more a security team asks a question or starts looking at something you've done, the more they're gonna follow the breadcrumbs. So it comes down to that dwell time. So the ideal world is these types of alerts are proactive measures. Or I just I just jokingly move to Mac.

Matthew Eidelberg: 49:03

No one hacks a Mac.

Ashley Knowles: 49:04

No one hacks a Mac. Have you seen any, like, packaged EDR solutions that are capable of of detecting this? Any vendors that we know of that have caught this, or is this really still kind of flying under the radar that we have to create or blue teams have to create custom rule sets for?

Matthew Eidelberg: 49:26

I wouldn't say there's an EDR out there. I'm sure if Microsoft is ever paying attention to anything I say or tell them, maybe one day they'll listen, smarten up, and write some kind of rule in MDE. But for now, we we've seen this get around attack surface reduction rules, carbon blacks, application allow listing blocking, because of the simple fact that all you have to do is drop it in the file into the folder, and the next time, it's a trusted application. Where we've seen alerts is beyond that is, hey. You know, Outlook loaded a file.

Matthew Eidelberg: 50:02

It had a signature for, say, something maybe super signature like brutal retell or b r c shell code. And that's where it's like, again, going back, this tool is only designed to do the side loading. You have to bring the stealth. So if you're going against, like, you know, say, CrowdStrike, which can catch a lot of known or has a lot of indexes or signatures for a lot of various common commercial c twos using those commercial c two shell code, that's that's where your problem is. But from a strictly this prod this EDR can block it?

Matthew Eidelberg: 50:32

No. Where we do see a lot of controls are limiting, you know, the ability to launch applications. In some cases, if, like, companies don't even allow Outlook or they don't allow Teams or things like that, that's where these things but generally speaking, this has kind of been like a point and shoot type of attack, which is why we've really been raising the flags with Microsoft to say, this is really important. You need to fix it.

Ashley Knowles: 50:56

Yeah.

Ryan Poirier: 50:59

Speaking of fix it, we are fixing the URL in the slides. Perfect. Getting that updated. I posted the the correct blog post link in the chat for Discord and Zoom.

Ashley Knowles: 51:12

Awesome. So another question. Does this just allow running a process convertly covertly in the user context, or was there a privilege escalation component that they missed?

Matthew Eidelberg: 51:26

With this one, not right now, but we've I've seen where the same type of logic and philosophy with finding these DLLs or even using the com based ones that are prebuilt into FaceTancer can allow the low privilege user to load a DLL into SVC host and other things like that. But this is strictly today's talk was strictly around these new discoveries. But DLL sideloading as a whole can be used for privilege escalation.

Ashley Knowles: 51:50

Mhmm. Okay. Let's see. There's there's quite a few questions in here still, but let's go to a fun one. Any recommended reading?

Matthew Eidelberg: 52:03

I mean, there's the first article where I where I talked about a lot of this stuff, but there's so much stuff already done about this. The kind of big sort of thing I would I would kinda say here is if you're looking to learn up on it, whether it's from a research side or from a defensive side, starting with what MITRE has. Because MITRE has a lot of great references, and and so do we with our articles that I've posted. But if you really wanna get more technical into this, it's not that hard to find. That's what's really funny and why I always am flabbergasted that these things still exist.

Matthew Eidelberg: 52:39

This all you need is process monitor. I just go back over to my slides. Alright. All you need to do is use process monitor, and this what I would do, especially throughout this whole disclosure process, is ironically, I'd RDP into a demo box using my iPad every patch Tuesday after everything got updated, and just launch process monitor with my filters to look for load images and app data, and just turn everything off and turn everything back on, like applications. And I would find these popping up all the time.

Matthew Eidelberg: 53:15

Next week, repeat the process, same thing. That's how I kept on finding more and more of these as I was disclosing to Microsoft over that six month process. So there's tons of ways to do it, but I would say if you're interest if you're looking from a defensive, there's great reading. We have a great stuff MITRE has as well. If you're interested in, I wanna find my own, go set up a VM.

Matthew Eidelberg: 53:40

Go download, you know, latest stuff, set up process monitor, turn things off, turn things on, like, use the task manager, kill, like, things, watch it reload, watch the process hierarchy. You'll see so many things happen, whether it's com based, you know, registry calls that don't exist to these DLLs. And you'd be surprised. Like, Copilot is vulnerable to this.

Ashley Knowles: 54:04

Of course, it is. Actually, that's a really good question that goes into another question that someone had, or a really good point. Where did it go? Does this mean Windows apps are different from Windows native apps?

Matthew Eidelberg: 54:18

So I I wish I could know what their definition of native app Microsoft changes terminology. But if we actually look like Microsoft has created these Windows apps themselves, and they're in a folder called Windows apps. Now I don't know if they're native, but if you're referring to the ones that are normally found, like, part of the OS, yes, these are. Like, calculator, notepad, even the search feature inside the explorer window of Windows 11, which is native, our Windows apps and Windows app like, the search widgets even. These are all Windows apps that are preinstalled into the OS and are vulnerable.

Ashley Knowles: 55:06

Cool. How many more questions do you have time to answer?

Matthew Eidelberg: 55:10

I have time to answer as many as we can afford. I mean, I'm sure people here don't wanna hear me all four

Ashley Knowles: 55:17

or

Matthew Eidelberg: 55:17

five hours. Not even my family can handle that many hours. And I get it, but I will say, going back to the disclosure thing, I wanna hammer that. This this is very important information. So the more people ask, the more it's going around because it is such a big issue.

Ashley Knowles: 55:35

Mhmm. Did The Sorry. Go ahead.

Matthew Eidelberg: 55:40

I was gonna say the the big thing here is getting the information out. And the hope here is that the more noise and the more people, vendors, customers, and stuff who raise the concern and kind of talk to Microsoft and, you know, kind of say, what what are you doing about this? Mhmm. That's the only way these things are gonna get fixed is if there's enough of an of an uproar from Microsoft's customers. That's the only way I've ever seen these forever days get fixed.

Matthew Eidelberg: 56:05

So the more people know, the more people get upset about it, the more people challenge Microsoft on their decision on this, the more we can change things for the better.

Ashley Knowles: 56:14

Forever days. I like that term. Was codesigning even a hurdle for this?

Matthew Eidelberg: 56:20

For most organizations, no. We have seen it where they where some organizations going back to to retests, they they've definitely kinda locked down. And this is what I would say are more mature clients who have been year over year. They've kinda seen all of my tricks. They know all the stuff.

Matthew Eidelberg: 56:39

Like, oh, I see that. That must be Eidelberg in our network, so to speak. Those are the ones where it's like, okay, code signing. I'm like, Okay. Yeah.

Matthew Eidelberg: 56:49

Late night drawing board sort of speak like that. So I wouldn't say you have to. It is a big, large endeavor. There are ways, though, to look at it. I mean, check the legitimate ones that are on your system.

Matthew Eidelberg: 57:04

Create a almost like a rule, like, hey. If this DLL is loaded, does it meet these requirements? And it doesn't have to be the ones I list here. It can be very creative because, you know, security is a circular thing of cat and mouse. You know, they catch us.

Matthew Eidelberg: 57:17

We get around. They catch us again. So these are things we've just seen customers implement and have great success that I wanted to share with everyone.

Ashley Knowles: 57:28

Yeah. Good. Another good question about sideloading. What's your take on sideloading from system 32 DLLs?

Matthew Eidelberg: 57:37

So system 32 DLLs, what we've done is and it's in FaceDancer, is use calm based attacks. Now that's in the first iteration, then there we have a blog about it. It's also linked in the GitHub repo. But those are very prevalent because of developer coding issues where they will basically let the system try to find things like kernel 32 or anything else. And so what the first place is the application checks and goes, hey.

Matthew Eidelberg: 58:08

Is it in the current user's registry file, the path? It isn't? Okay. Let's go to the local machine. And so in FaceDancer, there's actually a module called com based DLL silo, where it generates the DLL.

Matthew Eidelberg: 58:21

You can pick any of the system 32 DLLs, and it gives you that DLL. And it also then tells you, hey, write this registry key. Give it the path of whatever wherever you put this DLL, and you can then get DLL, you know, payloads raining from the skies. Think, Ashley, we've done that actually on an engagement. So you can probably speak to the effectiveness of how many shells came in.

Ashley Knowles: 58:46

It was quite a lot. I think I think it was like 10 to 15 ish. Was a lot. Yeah. It was a lot.

Matthew Eidelberg: 58:54

And so sideloading system 32 DLLs are wildly impactful. They are I like to call it the shotgun blast approach.

Ashley Knowles: 59:05

Shotgun. Yes. That's true. So next question. Looking ahead, do you plan to release additional tooling, updated face to answer features, or further research on WebView2 related issues?

Matthew Eidelberg: 59:23

Yes. And if I ever, you know, disappear, it means I might have been silenced by maybe some hired people in black suits. But, no, I plan to keep pushing the envelope on this. I mean, there's a lot more stuff I've been kind of slowly peeling back, trying to see what the impact of weaponization. But I I will tell you this is a house of cards, and I encourage anyone to take a look at it.

Matthew Eidelberg: 59:47

And I think if you're worried about what the next sort of thing could be, I think the bigger kind of question you need to start having with your your team, your security, your IT administrators is what they're doing and what they're allowing. Is this are you being are you letting Microsoft dictate your new applications, your new code, or are you saying, I'm I don't know where this is coming from. I don't know if this has been vetted. I don't know how like, how new is this? How trusted is this?

Matthew Eidelberg: 01:00:13

And looking at alternatives, there's a lot of great application replacements out there, not just everyone having to live in Microsoft's ecosystem.

Ashley Knowles: 01:00:25

Someone asked if this has been written into popular c two frameworks like Empire's liver, Rutile, etcetera. My my answer was you have to take the shell code and

Matthew Eidelberg: 01:00:37

Yes. I I do know that a lot of other companies, SpectroOps, for instance, have written articles about using FaceDancer and weaponizing their own. So c two specific, no. But there are a lot of how to's, weaponizing, finding their own. And so whatever it is, it's pretty much grab your c two of choice, get the DLL, plug it into FaceDancer, have free access.

Ashley Knowles: 01:01:09

We've got two ish more questions. Let's see. Could this be used as a covert channel between hosts or would Windows Firewall get in the way? For example, like Teams.

Matthew Eidelberg: 01:01:22

Honestly, I don't think it would get blocked because if they blocked with Firewall, there would be no communication with Teams, which then means whoever it is is gonna call the help desk instantly. Like, my Teams is not working. I can't work.

Ashley Knowles: 01:01:37

True.

Matthew Eidelberg: 01:01:38

So that's that's where, like, the flip side of convenience. That's why, like, I look at these sort of things. It's like, you can't just kill Microsoft Teams. You can't just kill Outlook because then the business can't run. And if the business is not gonna run, like I always say there's that triangle of pain, is accessibility, cost, security.

Matthew Eidelberg: 01:01:56

You can only pick two corners to live in.

Ashley Knowles: 01:02:00

Mhmm.

Matthew Eidelberg: 01:02:00

And no one is going to ever stop accessibility because that prevents you from making money.

Ashley Knowles: 01:02:07

Yeah, and your bottom line, woof.

Tom Smith: 01:02:10

I

Matthew Eidelberg: 01:02:10

don't wanna touch that.

Ashley Knowles: 01:02:12

So this one's a little spicy. This seems to highlight the tension of Microsoft shipped to sandboxed Windows apps. They reduce some traditional risks, but reintroduce others via shared run times like WebView2. Are there other shared components beyond domain_actions.d l l that you suspect could have similar weaknesses?

Matthew Eidelberg: 01:02:33

Short answer is yes. Long answer is you'll have to wait and see, and you can always find out yourself. But this is this was the first thread of a large YARM, and I suspect there's gonna be a ton more. I truly think that they're gonna have to go back to the architecture and rebuild this entire thing. When we were going back and forth with Microsoft, one of the comments on one of them was, it's not our fault.

Matthew Eidelberg: 01:02:58

It's Google's fault. And we even reached out to Google trying to talk. It's like, no. That's they took the open source component of our Chromium engine, and they've done something. Like so what I truly think the problem here is that how Microsoft split their teams for development, none of them are talking to each other, but they have to coexist with each other's rules.

Matthew Eidelberg: 01:03:20

Multiple little castles that dictate one line or one component or may one sub child process. And they're not working together, and it's creating these issues.

Ashley Knowles: 01:03:32

Interesting. Another question is process hackers source for GitHub or SourceForge?

Matthew Eidelberg: 01:03:41

GitHub always compile yourself, don't trust.

Ashley Knowles: 01:03:46

Check your receipts. Last question that I see. So this guy says, I know you would need to already have access to compromised hosts, but could this be used as a covert channel between hosts? Oh, he already asked that. Never mind.

Ashley Knowles: 01:04:01

No. This was already asked and answered. We

Matthew Eidelberg: 01:04:04

we use this often just to summarize as initial access. We use it for persistence. Those are our kinda go to drivers for it. Like, if we can kind of social engineer, we have some amazing people who are who can talk, you know, anyone into doing anything. So we get we just get them to, you know, be on the phone, convince someone, you know, this is trusted.

Matthew Eidelberg: 01:04:25

This is right. They do the dirty work for us. And we've we've seen it where it's like a user in one case is on a laptop, and every day they would shut it down, and we'd lose our beacon. But 07:30 eastern, beacon a new beacon would come back up because we were in Outlook. The user needed Outlook, so we always had access.

Matthew Eidelberg: 01:04:45

Even when they were traveling, even when the user was, you know, shut down, if the user lost power for the day, the next time they booted back up. So it's quite impactful.

Ashley Knowles: 01:04:55

That's pretty awesome. I really enjoyed it when we used it together.

Matthew Eidelberg: 01:04:59

Yeah.

Ashley Knowles: 01:05:00

It was fun. And the client was like, mind boggled by it. I do remember that. This was my Yeah.

Matthew Eidelberg: 01:05:10

It's kind of like, I mean, this has been a two year process. And it's just funny to look at because before that, was DLL sideloading is dead. It really isn't. And just the sheer impact of who was saying that, which were the vendors who magically solved it with x, y, or z things, and just find out we're still using the old legacy ways of attacking just in a new different way. Mhmm.

Matthew Eidelberg: 01:05:34

So if you're sitting there wondering, wish I could do something like this, look at any application. Look at old school, well documented techniques and see if you can put a new twist on it. I guarantee you'll find something, and you'll probably be doing a webcast soon.

Ashley Knowles: 01:05:50

Sounds good. That's all I have for questions. Thank you, Matt.

Matthew Eidelberg: 01:05:56

No problem. Anytime.

Ryan Poirier: 01:05:57

We got one we got one last minute. We're moving the DLL into the same container. Fix anything.

Matthew Eidelberg: 01:06:07

That would be an architectural ish solution that Microsoft would have to implement. Because what we've noticed is if that folder gets deleted or the DLL is not there, the application itself kind of does its opens up another process. It's almost like a repair system process, if you will. And within maybe a minute or two, the DLL will be put back. In some of these cases with some of the vendors, they they've tried to delete it.

Matthew Eidelberg: 01:06:38

Delete it if it's there. And within a few seconds, it just pops up, and we've watched them just like, you know, circular thing of delete it, comes back. Dammit. Delete it. Oh, why does this keep happening?

Matthew Eidelberg: 01:06:50

Yeah. So that was one of our recommendations to Microsoft was this should be moved in a container. But unfortunately, they've chosen not to listen to our recommendations.

Ashley Knowles: 01:06:59

Someone asked a question about that. But I thought it was too spicy to talk about on air. So I left it alone.

Matthew Eidelberg: 01:07:10

I mean, I'll someone's gotta wear the mask. I'll take the blame.

Ryan Poirier: 01:07:15

I think that is all the questions we

Ashley Knowles: 01:07:17

have. Mhmm. Almost like

Ryan Poirier: 01:07:20

And it's past it's past the hour.

Ashley Knowles: 01:07:22

Way past.

Ryan Poirier: 01:07:24

We are past the hour and we probably have to get back to work. So we're gonna wrap things up here. Ashley, thank you so much for taking these questions. Especially knowing more than than I obviously do about this topic. And thank you Matthew for walking us through this topic and this attack vector could be really interesting from here.

Ryan Poirier: 01:07:46

So we will see. Maybe there's gonna be a part two, part three, who knows?

Matthew Eidelberg: 01:07:50

I hope so. Part seven, part eight.

Ryan Poirier: 01:07:52

Seven. Oh, man. We got a whole saga.

Matthew Eidelberg: 01:07:55

Yeah. Just as long as Lord of the Rings and Star Wars.

Ashley Knowles: 01:08:04

The the yeah. Exactly. Anyway, I was gonna say, Ryan, someone correctly guessed why you have the shirt that you have. Yes.

Ryan Poirier: 01:08:12

Yeah. I know some I know people out there know.

Ashley Knowles: 01:08:15

Yeah. Mhmm.

Ryan Poirier: 01:08:16

But we'll save that for another webcam.

Ashley Knowles: 01:08:18

To join the Discord. Mhmm.

Ryan Poirier: 01:08:21

There we go. The the community can tell you.

Ashley Knowles: 01:08:23

Yep.

Ryan Poirier: 01:08:24

But until next time, we're gonna say so long. And Megan.

Ashley Knowles: 01:08:31

Making some meat, Matthew.

Matthew Eidelberg: 01:08:33

Go make a burger. Oh, it's stormy out like it's sheet rain right now where I'm at. So

Ryan Poirier: 01:08:40

Just get the umbrella. You'll be fine.

Ashley Knowles: 01:08:41

Then.

Matthew Eidelberg: 01:08:43

We have we had heavy rain, sunshine, snow, sunshine, heavy rain. It's all the seasons every other day.

Ashley Knowles: 01:08:52

Yep. Welcome. Alright.

Ryan Poirier: 01:08:56

Let's kill the fire. Later.