Microsoft blocks web installation of its own App Installer files – Naked Security


Late last year (November 2021), we reported an unusual campaign of fraudulent emails warning recipients that they were in serious trouble at work.

If you’ve seen one, you’ll probably remember it: A customer had filed a formal complaint and the company was rushing to set up a meeting to investigate your alleged misconduct…

… so you had to follow a link to download and read the complaint against you.

Many of us at Sophos were on the spam list and received emails like this:

Click on the image for the full article.

You are fired!

Some of us then received follow-up messages telling us that we were no longer technically in trouble, for the rather dramatic reason that we had been fired; our “termination letters” were attached, again as a document download link.

The downloads looked like PDF files:

But the download links were unconventional http:// Where https:// downloads; instead, they relied on an unusual link beginning ms-appinstaller://which (on Windows, at least) triggers Microsoft’s App Installer system to orchestrate the download process.

This ms-appinstaller The protocol not only takes you on a very different visual path than a traditional web download, but also reflects the kind of experience you would never have seen before, if you had seen it at all, when using from the Microsoft Store.

Notably, the process insists on a set of digitally signed applications (for bundlethink Android-APK Where Linux package), and therefore begins with a reassuring, if unfamiliar, pop-up assuring you, with a confident-looking green tick (check mark), that this is a trusted appapparently coded by a vendor you know:

Note that in the screenshot above, the publisher name (fraudulently given as “Adobe Inc.”) is just a text string in the app bundle itself; to “verify” the signer, you must click on the blue text Trusted app].

Unfortunately, the signer’s name doesn’t tell you much at all, or at least it didn’t last year when we first saw this trick being used to distribute “trusted” malware. .

Simplified fraudulent signature

In the example above, the app signer claimed to be an accounting firm and was a UK registered business.

But if you had taken it any further, you would have found a company that had never really done business, was located at an unlikely address, and was about to be delisted anyway.

Simply put, based on an online and apparently never-used-for-real business registration that probably only costs a few pounds (and who knows if the attackers actually paid anything for it, or just acquired the company data via hack or prior data breach?), cybercriminals were able to:

  • Acquire a “trusted” signing key and use it to sign App Installer bundles.
  • Distribute an App Installer bundle that presented itself as a trusted appmuch like a curated Microsoft Store app.
  • Trigger the installation via the Appinstaller.exe processno more suspicious through a browser.
  • Install and activate many unsigned applications under the imprimatur of the allegedly trusted signed top level bundle file.

In the sample email you got fired that we encountered here at Sophos, the vendors of the “trusted app” turned out to be the BazarLoader malware gang.

So, if the legitimate-looking, Microsoft Store-like installation process was enough to trap your trust, you would have ended up with persistent backdoor malware – often referred to as a bot or zombie. .

The backdoor bot started by leaking system configuration information to crooks and then waited for remote instructions on what new malware to download and execute next.

Cybercriminals with generic Remote Code Execution (RCE) access like this typically use your computer as a pawn in the underground economy, “renting” it – possibly repeatedly – ​​to others. crooks to carry out other cybercrimes, either against your computer or through your computer, or both.

Sometimes, unfortunately, this type of zombification is only detected by the victim when the bot operators “rent” the infected computer (or use it themselves) one last time for one last round of malware that you don’t. can’t help but notice…

…usually a ransomware attack.

More security implied than an HTTPS certificate

Note that the level of belief in cybersecurity that you are asked to adopt in the event of a ms-appinstaller:// download is significantly superior to the cybersecurity inference you’re supposed to make from a https:// web certificate.

Web certificates, which use the TLS protocol (transport layer security) to encrypt and verify the integrity of data exchanged in an HTTP session between a client and the server, say nothing about the actual reliability of the site on the other end.

Indeed, browser makers have struggled over the past decade to adjust the words, icons, and colors used in the browser itself to describe an HTTPS-protected site.

After all, TLS, by design and definition, provides at the transportation level safety, thus putting the S (for secured) in HTTP (short for hypertext transfer protocol), but does not aim or purport to perform any verification or trust assessment for the contents it is transmitted.

Firefox, for example, still uses a padlock icon to denote a “secure” site, but simply annotates the padlock with the words “Secure connection” and “You are securely connected”without making any statement on the site itself:

The Edge browser does something similar when you click on the padlock on a website, mentioning the privacy of the connection, but not suggesting that you can therefore ultimately trust the content of the site:

This site has a valid certificate issued by a trusted authority. This means that information (such as passwords or credit cards) will be sent securely to this site and cannot be intercepted. Always make sure you are on the intended site before entering information.​

In contrast, the App Installer popup that verifies the digital signature of the App Bundle you download explicitly identifies the software itself as a trusted appalthough it allows the app signer to include entirely bogus vendor data in the app set, and then helpfully display that fraudulent “identification” directly below the “Trusted App” flag.

This implies, in our minds anyway, that a much higher cybersecurity bar has been reached: it acts as a sort of content level assertion that persists after installation, rather than merely denoting some degree of at the transportation level security that only protects the network part of the download.

Recommended workarounds

We have recommended, and still recommend, various security solutions, including:

  • Use a web filter, if you have one, to block the download of likely App Installer bundles. File extensions to block include: .msix, .appx, .msixbundle and .appxbundle.
  • Use a web filter, if you have one, to prevent users from clicking on URLs beginning with ms-appinstaller://. This is the special protocol (called in URL terminology a scheme) used by Windows to launch the App Installer to take over your browser.
  • Use Microsoft Group Policy settings, if possible, to prevent non-administrator users from installing app bundles. If that’s a step too far, lock users down so they can install app bundles from the Microsoft Store only.

For Group Policy tweaks that help resolve this issue (which has been assigned vulnerability ID CVE-2021-43890), you can consult the guidelines published by Microsoft on what settings to use.

One step too far?

Our intermediate recommendation above might seem rather drastic, whether for your internal users if your company relies on vendors who ship their software via App Bundles, or for external customers if you’ve gone the App Bundle path for the software delivery.

After all, App Bundles are meant to have several benefits, especially for vendors offering endpoint products that support a range of different versions of Windows running on different types of computers (e.g. Intel, AMD, ARM) :

  • One signed package to rule them all, digitally signed at the top level.
  • The user does not need to determine which of the many distinct versions to use on their computer, so can’t end up with the wrong version.
  • Web downloads via the App Installer save bandwidth omitting parts that are not needed.

In Microsoft’s own words:

The ms-appinstaller protocol handler was introduced to allow users to seamlessly install an application by simply clicking a link on a website. This protocol handler provides users with a way to install an application without having to download the entire MSIX package. This experience is popular and we are delighted that it has been adopted by so many people today.

What to do?

Despite the upbeat paragraph at the end of the previous section, Microsoft isn’t so thrilled that cybercriminals have embraced this “transparent” process that works “just by clicking a link” as we first documented. Last year.

For now, anyway:

We are actively working to address this vulnerability. For now, we have disabled the ms-appinstaller (protocol) scheme. This means that App Installer will not be able to install an application directly from a web server. Instead, users will need to download the app to their device first and then install the package with App Installer. This may increase the download size of some packages.

In other words, Microsoft itself has entirely given up supporting its own ms-appinstaller:// URL type via web, as he thinks the process is still too easily abused.


  • If you use App Bundles to distribute your own software, you will need to modify either your software packaging process or your installation instructions, or both. Otherwise, potential customers might assume that your software is no longer compatible with their computer or network, and shop elsewhere.
  • If you rely on vendors who distribute programs via App Bundles, you will need to modify your deployment and update procedures. Otherwise, you could end up stale or with disgruntled internal users.


Comments are closed.