# UWP in the DFIR crosshairs: what modern Windows apps are hiding

Vladislav Azersky · F6

MOSCOW FORENSICS DAY ’25 · Day 2 — Friday, 12 September 2025: information security day · Scheduled 12:15–12:35 · In the recording 05:28:04–05:48:21

Talk transcript · https://2025.moscow-forensics-day.workers.dev/en/transcript/13-azersky
Summary: https://2025.moscow-forensics-day.workers.dev/en/summary/13-azersky · Slides: https://2025.moscow-forensics-day.workers.dev/en/slides/12-azerskii-uwp-dfir · Watch from 05:28:04: https://youtu.be/4V7Wez3L_58?t=19684

---

## Moderator's introduction

Most often, what ends up in the crosshairs of DFIR specialists is all kinds of different things. But our next speaker has put ordinary Windows applications there. How it all works will be explained to us by Vladislav Azersky from F6. Vladislav, please, let's support him with a round of applause.

Clicker, microphone.

*[applause]*

## Talk and Q&A

Hi everyone. Well, I think we can actually get started and talk, for the most part, not even about incident response so much, but more about computer forensics.

Today we'll be talking about, in fact, applications that we often come across in, say, the Microsoft Store, but not just there. We can even build them ourselves, and they'll be packaged the same way as a UWP app. That's exactly what we'll talk about today. A bit about myself. I've been working in information security for 7 years now, mostly doing information security incident response, digital forensics, and I very often run various cyber exercises in the Purple Teaming format. I also like taking part in various conferences, and, accordingly, doing research on both Offensive Security and Defensive topics.

So what is UWP? We can actually start at the very beginning of the story, when it all began. Windows 8 introduced various applications that were called Metro Apps, or Modern Apps, and they were, they ran, so to speak, as containers, isolated, and they had no access to any important system resources of the OS itself. And that's the first part. Then, some time later, Windows 10 came out, and that's where Universal Apps appeared, along with the UWP ecosystem itself, which let us create, essentially, universal applications that could be run, say, on some IoT device where we have a Windows operating system, as well as on a regular Surface Hub or a regular PC.

And at the same time we wouldn't need to recompile all of it, rebuild it, which is nice. But keep the following in mind. Supposedly all of this is isolated. We mostly see these apps, for example, in the Microsoft Store. But let's look at what else Microsoft did. In a certain build, 1607, they implemented a feature called Desktop Bridge, which let us package ordinary Win32 programs as UWP. And at the same time we could set certain permissions that allowed our app to freely access the system components of the OS itself, the functions of various APIs. That is, in this case the isolation was gone. And that's a very important point.

So, how are they represented at the file level? Most often, if we're using the Microsoft Store, we can simply download an app by clicking a button, and we won't see any file that gets installed, we'll just see a progress bar. So what are they, what do they look like? Today, this is an MSIX package being installed. They're essentially a kind of archive, they let us simplify the installation and update process for various apps, in this case, like a regular installer. It's an evolution of APPX, another format that was tied purely to UWP, which had that whole isolation business, but that was dropped later.

What else is important to know? Here on the screenshot you can see, I've highlighted three main files that we'll find in an MSIX package. First is AppxManifest.xml, which spells out how the application will be installed, how it will be launched, and also what permissions can be granted to it. For example, run full trust, which means it has access to all the components of the system itself, like a personal Windows system. Next is the signature itself, because every MSIX package must be signed with a valid certificate. We'll talk about that a bit later. And in that file, in the package, the certificate is also present.

And besides that, another very important thing. It's the BlockMap file, listing all the files in the package with their hashes, which can actually help us.

Let's take a look at how they're classified. We basically have four types of applications, three of which we can find in the Microsoft Store, the last one is signed by the developer themselves. First, system applications, essentially part of the Windows build by default, you can't, say, update them with a button, I mean remove them. And they get updated, for example, through the Microsoft Store. Next we have applications that are developed by Microsoft itself. That's, for example, something like Paint, or Calculator, which we all see often. And these are basically the apps that also often ship with the Windows build, but we can remove them, reinstall them, do whatever we want with these apps.

The next two items are, accordingly, applications that are in the Microsoft Store but aren't owned or developed by Microsoft. And here these are apps like, for example, Netflix, which we can easily install through the Microsoft Store, or the well-known Python interpreter, in various versions, which we can grab from the Microsoft Store and install without any problems. And the last, most important one, which we will encounter, and actually have sometimes seen in various incidents, is an application signed by the developer. And here I made a specific note that most malicious MSIX applications are signed precisely with a developer certificate. This may be a case where the attackers compromised some company, collected their certificates, and then signed their own MSIX package with them.

Why is this needed at all? If we try to install some MSIX package and it isn't signed with a valid signature, what happens is that when the user clicks the Install button, they'll see: oh, sorry, we won't let you run this application, because we couldn't validate your signature. And that's what we're going to talk about. How are MSIX files created in the first place? How can we create them? What software can we use? Here there are actually two main giants. One is the MSIX Packaging Tool, which can also be installed through the Microsoft Store. And also a commercial product, Advanced Installer, which also has a free version that lets us take our regular application and package it as UWP.

Okay. But actually, can we create one without even using this tooling? Yes, in this case we can take the MakeAppx utility. And for this we actually need two main things, maybe even three. First. We have to pick the application we want to package. Second. We have to write the AppxManifest.xml file by hand, which specifies how our application will be installed, how it's launched and what permissions we'll give it. For example, we want to let this application run without isolation and have access to all components. And for that, in the second note, we can specify runFullTrust, which lets the application avoid being isolated in some container.

After we've created our package with MakeAppx, we actually have to sign it. We can go the following route: create a self-signed certificate and sign the package with the SignTool utility. But keep one thing in mind here. Since this certificate is self-signed, it won't actually pass the checks against the various trusted certificate authorities, and before installing the MSIX package itself, we'll need to import the certificate into the system, which we created, into Trusted Root under Local Computer, which will actually require admin rights from the user. But, as I said, we supposedly can't install unsigned MSIX packages, yet with the arrival of Windows 11 the developers decided to do the following: we can easily, using a certain PowerShell cmdlet, install exactly these unsigned applications. To do that, we'll need to specify in the manifest, in the Publisher field, the Organization ID that's shown right here.

It will always be the same, and so this will be one of the indicators to find unsigned applications later on. What can we look at to understand what's going on out in the world? For example, in mid-2023, Microsoft, or rather their Threat Intelligence division, recorded certain activity by some financially motivated groups. And they were distributing MSIX packages, and to launch their installation they used the ms-appinstaller handler. It ended up being disabled by Microsoft some time later, because they saw that, yes, there was a lot of both phishing attacks and distribution via SEO poisoning, where we, in this case the attackers, push their websites up to higher positions in the index of, say, Yandex, Google and so on, search engines. They also distributed it through various ad placements. And, for example, they also used phishing via Microsoft Teams.

How did the whole story unfold here? There's a certain CVE, and honestly, I never found a more detailed description of how it works, but I can assume that in this case the attackers signed with, say, invalid certificates or signatures, but thanks to this vulnerability, they could pass through without issue, and the user got this window where they could hit the Install button. But at the same time, the publisher shown was not at all the company that, so to speak, developed Perimeter 81.

What else to remember? And yes, as I described, there are some financially motivated groups that have looked at this whole thing and used it, but there aren't that many cases. What else do we need to keep in mind? There is a framework that, for example, the FIN7 group used, and they, what did they do? Created an MSIX package and embedded this framework, which lets us, without touching the program's actual source code, for example, run scripts before it executes. And we see that for this we need to write into config.json our PS1 script, for example, or a batch file, really any script at all, and then it will be executed before what we actually need runs, for instance, the application.

So what can we actually see from the DFIR perspective? What we'll mostly care about is the story of which applications were actually installed on our system via MSIX packages. And here there are actually four main points. The first one is the directories, because when an application is installed, a specific directory with its name gets created, plus three other sources of information that we'll talk about now. In the Windows operating system there is an SQLite database called StateRepository-Deployment, and in some of its tables we can find quite useful information. If, for example, the application is installed the way it was in those attacks carried out by financially motivated groups, we'll be able to see the link, in this case the URL, from which our MSIX package was essentially downloaded. And next, if it was simply launched with a double-click from the operating system, we'll just see the full path to that file.

But beyond that, if you dig deeper into the various tables, we can even see the hashes of every file that was in the MSIX packages. And consequently we can also, for example, having some indicators of compromise, search for certain files, or simply collect those indicators of compromise. But you need to keep in mind that this database and the next one mostly contain only information about installed applications, but not information about removed ones. But actually we don't really need the removed ones in this case. The next database is also SQLite 3. It also has a few useful tables, which are listed here. And what do we learn here? For example, I said that Windows 11 lets us install unsigned MSIX packages. Consequently, within one table we can find this Organization ID, which will tell us that yes, the package was installed without a signature.

And in addition to that, find out who the publisher is, which is actually also important. Besides that, we have everyone's favourite event log, which exists in all Windows operating systems. And here I broke down four main cases. The first and second cases are based on the hypothesis that the attackers installed the application using the PowerShell interpreter. In one case a signed package was installed, in the other an unsigned one. And the difference here will mainly be that when an unsigned package is created, event 9545 gets generated, which explicitly tells us that the package is unsigned.

Next, the popular options are when the user simply double-clicks the icon of the package, and it launches. Or using ms-appinstaller. As with the typical cases, the difference will be that in one case the user simply launches it, and we'll see the full path to the file, while in the other it will point to the source link from which the file was downloaded.

Besides that, we also have logs such as the App Installer log. What's important here and what to keep in mind? I said earlier that we can look, for example, in the event logs and see that with PowerShell some signed or unsigned packages were installed. Well, App Installer lacks that information, but it has the third and fourth cases, when we launch it either through the graphical interface or via the ms-appinstaller handler. To tell them apart, we can simply look at the line that is highlighted in green here, and in this case understand how the launch was performed. But besides that, there's one more thing. What if the attacker needs some applications from the Microsoft Store? In that case they'll most likely use the winget utility, which will let them install some package. This doesn't even require administrator rights, and it can be seen right there in the log.

Okay, we've talked about how attackers can deliver some MSIX packages, use some CVEs to launch them without any trouble, import a certificate and all the rest. But sometimes this even requires admin rights. So let's think: what is there in the Microsoft Store that can be installed without admin rights and that would be of interest to attackers? Here I singled out five specific areas. The first is various interpreters. In this case, in the Microsoft Store it's the Python interpreter and the Julia one. Then there are tunnels, which let us build, roughly speaking, a tunnel between our host and the infrastructure, so as to, roughly speaking, have access to the victim. Third is a web browser. For example, some attackers like, as part of an attack, to deliver their own portable versions of browsers and then use them to browse web resources located inside the company.

Fourth is SSH/RDP agents. And the last is the ever-popular Remote Access Tool, or, in other words, legitimate remote administration utilities, which are exactly what lets us help some accountants and so on. In that case support helps them, connects via TeamViewer and then works through and fixes some technical problem. Okay, let's talk about interpreters. I'm looking at interpreters here and, in this case, tunnels. What can we do with interpreters? Let's say the attacker has managed to somehow deliver some payload, or they already have access to the host; they can use the winget command.

The command line is shown here. After the interpreter is installed, they can, for example, either pass the Python interpreter, or Julia, a file with code, or simply specify some payload on the command line. This payload essentially gives the attacker a CMD for interacting with the host, and that's our reverse shell. And the second very important thing is, basically, tunnels. With tunnels the situation is interesting. In almost all cases involving various financially motivated groups that drop ransomware into the infrastructure and run it, they use tunnels.

The most popular, which I also found in Microsoft Store, recently added, are actually ngrok and localtunnel. They can also be installed with winget and then launched. But very often attackers also establish persistence for these utilities. And the very last one, which I saved for the end, is VS Code. VS Code is generally a story about, actually it's a developer IDE, i.e. their environment. And when we install it, we actually also get an additional utility, code.exe, with which we can create a tunnel. But for that we need to authenticate with GitHub. Most often that's no longer a problem for attackers.

And we move on to the main, final block: recommendations, at least the minimum that can be done. First, prohibit users from installing untrusted packages. In this case, packages that were not delivered through the Microsoft Store. And second, prohibit users, unprivileged ones in general, from launching or installing any MSIX packages, even from that same Microsoft Store. So they'll need admin rights for this. That is, at the very least call an administrator to do it. What else can be done? Write detection rules, for example, for a specific elevated cmdlet with a parameter that tells us that an unsigned MSIX package was installed.

And also, for example, collect event 9545, in which, as we also saw, there is an indication: oh, we've got a package installed here. And lastly, if we're saying the company has some SIEM or log management systems, we can simply collect, for example, these four events listed here, and additionally, on top of that, collect various commands, in this case the PowerShell log and the event log, which is also very important. That's actually all. Later I'll even publish the presentation with additional material, which will additionally cover some of the questions from this presentation.

Colleagues, your questions, if there are any. As always, you've broken my whole audience. It happens, it happens. Right, if there are no hands, Vladislav, again, thank you very much. That was super cool.

So, dear guests, we're now going on a short break and we'll meet here again at 1:10 for the second session of talks. Thank you.

*[A break (12:40–13:10 in the program) is cut from the recording; timecodes run without a gap.]*