Account Unknown(S-1-15-3-65536-1888954469-739942743-1668119174-2468466756-4239452838-1296943325-355587736-700089176)

I've noticed a few fascinating details you may want to know, folks.
.

1. the sid in question comes with windows 11 22H2 installation image.

How to verify. Extract windows from Win11_22H2_English_x64v1.iso/sources/install.wim, on disk, say, v:\ :

> Dism /apply-image /ImageFile:install.wim /index:6 /ApplyDir:v:\

… then S-1-15-3-65536-1888…9176 will already be in v:\ ACL. Image index doesn't matter: home/pro/edu/…, all have S-…9176 in the root of system drive.

So any PC with windows 11 22H2 should have this sid in a system drive root.
. 2. I removed S-1-15-3-65536-1888…9176 from system drive ACL four of five times, but each time it resurrects after reboot.
. 3. You may wonder, who reverts S-…9176 back into the system drive root. Me too. I've set up audit entry in c:\ ACL to track "Change permissions" events.

Guess what? The audit shows me removing S-…9176 from the system drive root, but does not show who and when adds S-…9176 back.

.

So, we have three independent problems here:

1. MS pollutes security space with “Account Unknown (S-…)” SIDs since … windows 8?

This wasn't so apparent until win11 22H2, when some MS guy sticked such eye-catching unknown directly into the root of system drive.

The problem with unknowns is: the legit and not legit unknowns are undistinguishable. And even legit unknowns are impossible to audit.
. 2. MS fools us when we click “Remove” ACE button in the ACL editor. If “remove” succeeded then the windows promise is: ace has been removed. That is not the case for S-…9176 in the root of system drive.
. 3. NTFS audit is either broken or also fools us, because it does not show who adds S-…9176 into the system drive.

.

Applicable screenshots attached.

Setting up audit, pic.1:

Setting up audit, pic.2

Audit result, after two S-…9176 removal and two reboots. Two events:

authpolchg is a custom view with “Microsoft-Windows-Security-Auditing” source and not related to permissions change events excluded.

Both events are identical, showing only removing S-…9176 from ACL:

Windows version: Windows 11 Pro, English, x64, 22H2, build 22621.1635:![Image](https://learn-attachment.microsoft.com/api/attachments/41dcc235-5e95-4e1b-85c7-0eda7c50eb4d?platform=QnA

is this used to invade privacy of the user? Can you give us specific examples of what these types of users. Is it a backdoor for data retainment? I was happy with this until I saw that.

Yeah its a hostile takeover 100% this is all new

Hi, Chow. This particular sid is probably legit, it looks similar to “capability sid”. But I strongly agree that there must not be “Unknown” actors in the system security configuration.

If you are willing to change this, please vote for the ticket(s) I created on FeedBack Hub (link in the comment above, on 18 May), or create your own ticket(s)

By the way, I completely agree with your estimate of Dave's words.

This is absolutely ticking me off! It's DCOM errors (DistributedCOM errors) that is causing this! Microsoft hasn't fixed this since Windows 10! Every time I restart or update my computer, the unknown user shows up! I read a tutorial on how to fix this issue, but for some reason I get access denied changing the permissions, so it's impossible!

https://answers.microsoft.com/en-us/windows/forum/windows_11-wintop_update/please-microsoft-fix-the-decom-errors/af3b8662-f20f-480a-8a95-d1132c19ed43

Also I delete the unknown user and it's not like my system goes crazy. So technically it's just a Microsoft problem. Fix your errors Microsoft! Do everyone a favor Microsoft, test your updates before releasing them!

You should also notice some LSA warnings from event viewer too! 22h2 has some problems and Microsoft likes to force updates on our computers without consent! I'm going to try this simple fix to see if it alleviates the LSA problem.

https://youtu.be/RbsIGbwqA00

Though fixing DCOM errors is simply Microsoft's problem!