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 DeriveAppContainerSidFromAppContainerName:
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 DeriveAppContainerSidFromAppContainerName 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.
> 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.
“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...
The best SIDs are 6581 and, to a lesser extent, 8580.
A sound opinion….
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...