A few days ago there was some banter online about Microsoft breaking stuff (as is tradition). Specifically, some users were trying to open Notepad, but Windows was displaying an error code.
If you have no idea what I'm referencing, I'll attach the post and discussion below this post so you can understand the lore.
Anyway, some nerd named "xakpc" on Twitter commented about Windows "App Execution Aliases". I jokingly commented, "wtf new malware idea". I changed my mind. This isn't a joke.
To the best of my knowledge, and please correct me if I'm wrong, no one has abused Windows App Execution Aliases for malware persistence.
In Windows 11 if you go to:
-> Settings
-> Apps
-> Advanced App Settings
-> App execution aliases
You'll see "aliases". Hence, when a user types something into Powershell, or CMD, or Windows search, it defaults to whatever is aliased. Upon further review, it turns out that a good chunk of these are stored in HKEY_CURRENT_USER, meaning it does not require administrative privileges to create, modify, or delete some app execution aliases.
It's stored under: "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\App Paths"
On my machine, notepad.exe has an app execution alias for (God save me) the new fancy Windows Notepad thingie which was giving people problems. It does NOT default to the one in SYSTEM32 like I initially thought.
On the contrary... and something I don't understand, although these settings are stored in the registry, they contain a stub in %LOCALAPPDATA% in
%LOCALAPPDATA%\Microsoft\WindowsApps
I don't understand how they're connected. I have no idea how this all works still. However, this can be abused and we must abuse it for malware persistence.
Under ideal conditions, it should be possible to programmatically modify an App Execution Alias (i.e. Notepad) which in actuality points to a malicious payload. When the malicious payload is triggered it should then subsequently execute Notepad.exe to give the illusion the user executed Notepad and not the payload
tl;dr
Old alias:
notepad -> notepad.exe
New (bad) alias:
notepad -> malware.exe -> notepad.exe
We must poke it with a stick and make malware.
If you have no idea what I'm referencing, I'll attach the post and discussion below this post so you can understand the lore.
Anyway, some nerd named "xakpc" on Twitter commented about Windows "App Execution Aliases". I jokingly commented, "wtf new malware idea". I changed my mind. This isn't a joke.
To the best of my knowledge, and please correct me if I'm wrong, no one has abused Windows App Execution Aliases for malware persistence.
In Windows 11 if you go to:
-> Settings
-> Apps
-> Advanced App Settings
-> App execution aliases
You'll see "aliases". Hence, when a user types something into Powershell, or CMD, or Windows search, it defaults to whatever is aliased. Upon further review, it turns out that a good chunk of these are stored in HKEY_CURRENT_USER, meaning it does not require administrative privileges to create, modify, or delete some app execution aliases.
It's stored under: "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\App Paths"
On my machine, notepad.exe has an app execution alias for (God save me) the new fancy Windows Notepad thingie which was giving people problems. It does NOT default to the one in SYSTEM32 like I initially thought.
On the contrary... and something I don't understand, although these settings are stored in the registry, they contain a stub in %LOCALAPPDATA% in
%LOCALAPPDATA%\Microsoft\WindowsApps
I don't understand how they're connected. I have no idea how this all works still. However, this can be abused and we must abuse it for malware persistence.
Under ideal conditions, it should be possible to programmatically modify an App Execution Alias (i.e. Notepad) which in actuality points to a malicious payload. When the malicious payload is triggered it should then subsequently execute Notepad.exe to give the illusion the user executed Notepad and not the payload
tl;dr
Old alias:
notepad -> notepad.exe
New (bad) alias:
notepad -> malware.exe -> notepad.exe
We must poke it with a stick and make malware.
🥰51❤21🤝6🎉2💯2🔥1
vx-underground
A few days ago there was some banter online about Microsoft breaking stuff (as is tradition). Specifically, some users were trying to open Notepad, but Windows was displaying an error code. If you have no idea what I'm referencing, I'll attach the post and…
X (formerly Twitter)
vx-underground (@vxunderground) on X
This is very silly.
Windows has a very different types of error codes. Most notably you have Win32 (native API error codes), NT (kernel mode error codes), and HRESULT (COM, WinRT error codes). For sale of argument, you have other error codes too, like for…
Windows has a very different types of error codes. Most notably you have Win32 (native API error codes), NT (kernel mode error codes), and HRESULT (COM, WinRT error codes). For sale of argument, you have other error codes too, like for…
🥰22❤5
vx-underground
>wake up >take a shit >get out of bed >slide trash off desk >get on beep boop machine >powered by lots of hamsters >get on internet >check news >russia malwares poland >something about clawd idfk >windows is dumb >some other stuff probably >thank God it's…
HAVE U SEEN LATEST AI THING?
No, because every other day some fucking AI company pops out the bushes and tries yelling in my face about how they're going to "change everything". I can't keep up. I'm busy with malware, cats, a big stinky baby (he fucking STINKS)
No, because every other day some fucking AI company pops out the bushes and tries yelling in my face about how they're going to "change everything". I can't keep up. I'm busy with malware, cats, a big stinky baby (he fucking STINKS)
❤49😁19🥰6💯3🫡2
In you missed it (I did, I don't know how), Microsoft is aiming to phase out UAC and replace it with a more secure thingie called "Administrative Protection".
They're doing this because UAC currently has over 81 bypasses and, for reasons unknown to me, Microsoft decided to scrap UAC in totality and redo the entire thing from the ground up. Why? I have literally no idea. Maybe you stinky nerds can educate me.
AP is now in preview mode for Windows Insider builds (testing stuff). Big brain security researchers from Google Project Zero poked it with a stick and discovered eight vulnerabilities that allowed them to bypass AP. Microsoft has since patched it. AP has yet to be deployed to Windows 11 as of this writing.
AP on paper, when reading about it, seems like a good idea and seems like it unironically would be a massive security improvement for Windows. However, the new architecture would bamboozle some legacy applications. Making it work with older stuff will require lots of science from Microsoft. Additionally, and maybe I'm being a bit pessimistic, I am concerned Microsoft will vibe code slop their new security module and make it one massive cluster fuck disaster.
Please read the research performed by Tirando (can't find his social media profile) and the other nerds at Project Zero. It's interesting. They're all very talented security researchers and make feel like an imbecile.
https://projectzero.google/2026/26/windows-administrator-protection.html
They're doing this because UAC currently has over 81 bypasses and, for reasons unknown to me, Microsoft decided to scrap UAC in totality and redo the entire thing from the ground up. Why? I have literally no idea. Maybe you stinky nerds can educate me.
AP is now in preview mode for Windows Insider builds (testing stuff). Big brain security researchers from Google Project Zero poked it with a stick and discovered eight vulnerabilities that allowed them to bypass AP. Microsoft has since patched it. AP has yet to be deployed to Windows 11 as of this writing.
AP on paper, when reading about it, seems like a good idea and seems like it unironically would be a massive security improvement for Windows. However, the new architecture would bamboozle some legacy applications. Making it work with older stuff will require lots of science from Microsoft. Additionally, and maybe I'm being a bit pessimistic, I am concerned Microsoft will vibe code slop their new security module and make it one massive cluster fuck disaster.
Please read the research performed by Tirando (can't find his social media profile) and the other nerds at Project Zero. It's interesting. They're all very talented security researchers and make feel like an imbecile.
https://projectzero.google/2026/26/windows-administrator-protection.html
projectzero.google
Bypassing Windows Administrator Protection - Project Zero
A headline feature introduced in the latest release of Windows 11, 25H2 is Administrator Protection. The goal of this feature is to replace User Account Cont...
❤37🥰12😁7💯4🤣2😱1🤩1
Last time on Dragon Ball Z: I did a sort of long post discussing wanting to abuse Windows Application Execution Aliases for malware.
To make this schizo rant short, I'll call it AEA (App Execution Alias).
Refresher:
In Windows 11 if you go to:
-> Settings
-> Apps
-> Advanced App Settings
-> App execution aliases
You'll see "aliases". Hence, when a user types something into Powershell, or CMD, or Windows search, it defaults to whatever is aliased (see image 1)
Windows did a pretty good job at making this a convoluted mess. I am lost and confused. I am in places I have never been on Windows (as is tradition).
All of the execution aliases are the result of Microsoft store apps because they're from AppX and/or MSIX packages (although technically it doesn't NEED to come from the Microsoft app store, it's just the most common). MSIX is a Windows program installation file format. If you're not familiar with it, look it up online. It's nothing crazy. It's pretty common.
However, the MSIX installation thingie has package manifest elements, and this is where AEA come from. It's an element called "uap5:AppExecutionAlias".
The MSIX installer creates an NTFS reparse point in %LOCALAPPDATA%\Microsoft\WindowsApps\*
Inside that directory you'll see all the aliased programs, but they're 0 bytes in size. However, if you use fsutil you'll see this (image 2)
It was at this point I began researching "0x8000001B", which translates to "IO_REPARSE_TAG_APPEXECLINK". This lead me to discovering James Forshow (tiraniddo) reversed engineered AEA in 2019 as a result of people on social media arguing about Windows executing the incorrect Python as a result of AEA (see subsequent post for his write-up).
.... which coincidentally we're here discussing THIS RIGHT NOW because people on social media were arguing about Windows executing the wrong Notepad. It's been 7 years and people are still rustled by it.
He concludes his technical write-up with the message, "I'm sure there's probably some exploitable security bug in the code here, but I'm too lazy to find it :-)"
Now I am in a situation where I can continue to poke AEA with a stick, to find a mechanism to abuse for malware, or I could give up and go back to watching Dragon Ball Z.
To make this schizo rant short, I'll call it AEA (App Execution Alias).
Refresher:
In Windows 11 if you go to:
-> Settings
-> Apps
-> Advanced App Settings
-> App execution aliases
You'll see "aliases". Hence, when a user types something into Powershell, or CMD, or Windows search, it defaults to whatever is aliased (see image 1)
Windows did a pretty good job at making this a convoluted mess. I am lost and confused. I am in places I have never been on Windows (as is tradition).
All of the execution aliases are the result of Microsoft store apps because they're from AppX and/or MSIX packages (although technically it doesn't NEED to come from the Microsoft app store, it's just the most common). MSIX is a Windows program installation file format. If you're not familiar with it, look it up online. It's nothing crazy. It's pretty common.
However, the MSIX installation thingie has package manifest elements, and this is where AEA come from. It's an element called "uap5:AppExecutionAlias".
The MSIX installer creates an NTFS reparse point in %LOCALAPPDATA%\Microsoft\WindowsApps\*
Inside that directory you'll see all the aliased programs, but they're 0 bytes in size. However, if you use fsutil you'll see this (image 2)
It was at this point I began researching "0x8000001B", which translates to "IO_REPARSE_TAG_APPEXECLINK". This lead me to discovering James Forshow (tiraniddo) reversed engineered AEA in 2019 as a result of people on social media arguing about Windows executing the incorrect Python as a result of AEA (see subsequent post for his write-up).
.... which coincidentally we're here discussing THIS RIGHT NOW because people on social media were arguing about Windows executing the wrong Notepad. It's been 7 years and people are still rustled by it.
He concludes his technical write-up with the message, "I'm sure there's probably some exploitable security bug in the code here, but I'm too lazy to find it :-)"
Now I am in a situation where I can continue to poke AEA with a stick, to find a mechanism to abuse for malware, or I could give up and go back to watching Dragon Ball Z.
❤35🥰8💯1
vx-underground
Last time on Dragon Ball Z: I did a sort of long post discussing wanting to abuse Windows Application Execution Aliases for malware. To make this schizo rant short, I'll call it AEA (App Execution Alias). Refresher: In Windows 11 if you go to: -> Settings…
www.tiraniddo.dev
Overview of Windows Execution Aliases
I thought I'd blogged about this topic, however it turns out I hadn't. This blog is in response to a recent Twitter thread from Bruce Dawso...
❤22
vx-underground
Last time on Dragon Ball Z: I did a sort of long post discussing wanting to abuse Windows Application Execution Aliases for malware. To make this schizo rant short, I'll call it AEA (App Execution Alias). Refresher: In Windows 11 if you go to: -> Settings…
> be me
> have idea
> look inside
> james forshaw, or x86matthew, or hexacorn, or grzegorz tworek did it
/me flips desk
> have idea
> look inside
> james forshaw, or x86matthew, or hexacorn, or grzegorz tworek did it
/me flips desk
🥰39😁24❤7
vx-underground
Photo
i got https without winsocks working by communicating directly with drivers. i said i wouldnt do it, but i did. everything hurts inside
❤54🥰13🤓10❤🔥4🤔3😁2🔥1🤣1
>poking windows with stick
>want to learn how handles tls http stuff
>look inside
>secu32.dll - QueryContextAttributesW
>look inside
>sspi.dll - QueryContextAttributesW
>look inside
>sspi provider virtual table QueryContextAttributes
>look inside
>LsaQueryContextAttributesW
>look inside
>NtDeviceIoControlFile
>talks to driver kdsecdd
>Kernel-mode Security Device Driver
tl;dr
>want to learn how handles tls http stuff
>look inside
>secu32.dll - QueryContextAttributesW
>look inside
>sspi.dll - QueryContextAttributesW
>look inside
>sspi provider virtual table QueryContextAttributes
>look inside
>LsaQueryContextAttributesW
>look inside
>NtDeviceIoControlFile
>talks to driver kdsecdd
>Kernel-mode Security Device Driver
tl;dr
🤣58🫡8❤7🥰5👍2
Chat, I've done it.
I've managed to get Windows Sockets (Winsock) functionality working by communicating directly with AFD (Ancillary Function Driver for WinSock) by IO control codes AND used it with HTTPS by using SSPI (Microsoft Security Support Provider Interface).
By doing this, this completely eliminates the need for WININET or WINHTTP for malware payloads. It also removes the weird telemetry and ETW stuff present in Winsocks, WININET, and WINHTTP.
My code is still in a debug state at the moment, but I'll eventually release a non-fucked-up version (no SYSCALLs, no position independence) so people can look at it, study it, or review it.
Currently this is only supports GET requests for simple pages (not even file downloads...). However, I'm having so much fun with this I think I am going to expand on it to do the following:
- HTTPS authentication
- HTTPS upload
- HTTPS download
- ???
I'll make it all open source, non-crazy, in a format people can copy pasta and have fun with it. I'll also probably make a fork where it's the crazy schizo version.
I hope all my malware development friends, reverse engineer friends, and anime friends, look at it and appreciate it. This is some of my favorite code I've written and I think it has a lot of applicability to Red team engagement. Conversely, it also offers insight to defenders on detecting this sort of functionality.
I've managed to get Windows Sockets (Winsock) functionality working by communicating directly with AFD (Ancillary Function Driver for WinSock) by IO control codes AND used it with HTTPS by using SSPI (Microsoft Security Support Provider Interface).
By doing this, this completely eliminates the need for WININET or WINHTTP for malware payloads. It also removes the weird telemetry and ETW stuff present in Winsocks, WININET, and WINHTTP.
My code is still in a debug state at the moment, but I'll eventually release a non-fucked-up version (no SYSCALLs, no position independence) so people can look at it, study it, or review it.
Currently this is only supports GET requests for simple pages (not even file downloads...). However, I'm having so much fun with this I think I am going to expand on it to do the following:
- HTTPS authentication
- HTTPS upload
- HTTPS download
- ???
I'll make it all open source, non-crazy, in a format people can copy pasta and have fun with it. I'll also probably make a fork where it's the crazy schizo version.
I hope all my malware development friends, reverse engineer friends, and anime friends, look at it and appreciate it. This is some of my favorite code I've written and I think it has a lot of applicability to Red team engagement. Conversely, it also offers insight to defenders on detecting this sort of functionality.
🥰69❤24🤯4👍3🔥2👏2🤔1🫡1