What are these SIDs of the form S-1-15-2-xxx?

Raymond Chen

May 2nd, 20225 2

If you are the curious sort of person who looks at security descriptors, you may find SIDs of the form S-1-15-2-xxx. What are these things?

SIDs of the form S-1-15-2-xxx are app container SIDs. These SIDs are present in the token of apps running in an app container, and they encode the app container identity.

According to the rules for Mandatory Integrity Control, objects default to allowing write access only to medium integrity level (IL) or higher. App containers run at low IL, so they by default don’t have write access to such objects.

An object can add access control entries (ACEs) to its access control list (ACL) to grant access to low IL. There are a few security identifiers (SIDs) you may see when an object extends access to low IL.

S-1-15-2-1: All Application Packages (SDDL abbreviation: “AC”)

Packaged apps, also known as Universal Windows apps. This covers all classic Windows Store apps.

I’ve seen some web pages where people speculate that “All Application Packages” is some sort of malware. It’s not. It’s just a security group.

S-1-15-2-2: All Restricted Application Packages

I’m not sure what this means or how it differs from All Application Packages.

S-1-15-2-x1-x2-x3-x4-x5-x6-x7: Specific app

This is a SID for one specific app. The seven numbers that come after the S-1-15-2 are 32-bit decimal numbers that collectively represent the first 28 bytes of the SHA256 hash of the app package family name.

You can ask the system to calculate this SID for you by calling Derive­App­Container­Sid­From­App­Container­Name:

PSID sid;
if (SUCCEEDED(DeriveAppContainerSidFromAppContainerName(
        L"Contoso.Deluxe_yda3mdg2t4ngp", &sid)))
{
    // you have the sid in "sid"
}

You use this SID to grant access to a resource for one specific app. Of course, if you want to allow multiple apps, you can add multiple ACEs, one for each SID you want to allow.

Since the value comes from a cryptographic hash, there is no known way to reverse the SID back to the original package family name.¹ If you find one of these and are curious which app it applies to, you could enumerate all the apps that are installed on the system and feed each one into Derive­App­Container­Sid­From­App­Container­Name looking for a match. But even then, you may not find it, because the SID may refer to an app that isn’t currently installed: It may have been applied in anticipation of installing an app, or it may have been applied at a time when the app was present, but you have since uninstalled it.

There’s another family of SIDs related to app containers that you may also run across. We’ll look at them next time.

¹ If you find a way to do that, you’ll probably use your new discovery to do much more lucrative things than reversing package family names.

Raymond Chen

Read next

5 comments

Discussion is closed. Login to edit/delete existing comments.

  • Ian Boyd 1

    This is similar to how scheduled tasks will run under a virtual user account based on the service name (i.e. NT TASK\[Task name]). The SID of this virtual account is dynamically generated based on a hash of the task name, and runs under the `S-1-5-87` authority. This is why you can’t rename or move existing scheduled tasks – it would change the SID and all the security settings you’ve deployed. You can generate the sid of any arbitrary task name by running:

    >schtasks /showsid /TN "Contoso\The quick brown fox jumped over the lazy dog"
SUCCESS: The SID "S-1-5-87-2634381056-3711325779-3967898769-4058759293-3493767943" for the user name "Contoso-The quick brown fox jumped over the lazy dog" has been computed successfully.

    Services have a similar idea. Services can run under a *”virtual service account’* based on the name of the service (e.g. NT SERVICE\MSSQLSERVER). And the user’s SID is based on the hash of the service name, and is issued under the `S-1-5-80` authority. You can generate the SID of an arbitrary service name using:

    >sc showsid "The quick brown fox jumped over the lazy dog"
SERVICE SID: S-1-5-80-2312335432-65297056-3549082870-2589977271-250352331
STATUS: Inactive

    And IIS has the same thing for application pools. They run as a virtual user named `IIS APPPOOL\[App Pool Name]`, with an SID issued under the `S-1-5-82` authority, and based on the hash of the name of the application pool.

  • Georg Rottensteiner 0

    The best SIDs are 6581 and, to a lesser extent, 8580.

    • Charles Dye 0

      A sound opinion….

  • Paul Jackson 0

    > S-1-15-2-2: All Restricted Application Packages
    > I’m not sure what this means or how it differs from All Application Packages.

    Now you got us curious. Maybe your friends from Microsoft know, call them for help.

    • MR 1

      “ALL RESTRICTED APPLICATION PACKAGES” is for all less privileged AppContainers (LPACs). Those are AppContainers that get even less permissions by default, which were introduced in Windows 10 version 1703.

      The old Microsoft Edge used LPACs for its sandboxed processes, and they are being explored as well for Chromium-based browsers like Google Chrome, new Edge, Brave, etc. Unfortunately, LPACs have virtually no documentation from Microsoft itself, but if you search the web for “chromium sandbox” you can read the design doc for Chrome’s Windows sandboxing, which includes a good description of LPACs.

      (Reposting in case the link in the previous version got it blocked.)

Feedback usabilla icon