Dreaded Unknown Accounts - Have you been hacked?
Do you get accounts like this showing up for file permissions on c:\Windows\Temp:
According to Microsoft (http://msdn.microsoft.com/en-us/library/windows/desktop/aa379649) these are called SECURITY_NT_NON_UNIQUE S-1-5-21 SIDS are not unique.
An attempt at an explaination is a follows of what SIDS are.
S-1-5-21-527237640-484763769-1060284398-500
This more focused SIDS and RIDS list available at http://msdn.microsoft.com/en-us/library/cc980032.aspx, and list SIDs in a table format
This gives a list of well known SIDS and RIDS, and commonly quoted on other sites
http://msdn.microsoft.com/en-us/library/windows/desktop/aa379649(v=vs.85).aspx
Still, I am stuck for my unknown soldier, the value of 1026 for the RID I cannot find.
Determine some quick SIDs on your computer from the Windows CMD line;
But this is not giving me a complete comprehensive list of SIDS.
But know I suspect 1026 is part of IIS installed on my computer, given natural progression of numbers, but it is not listed.
If you suspect a you can try to do a reverse look-up of the SID.
You can do the reverse, how to determine Which Account a SID Belongs to by using a Powershell elevated script from http://technet.microsoft.com/en-us/library/ff730940.aspx.
or
Helge Klein has tried to solve this in the following problem statement:
Running the the above script produced following output.
So at least S-1-15-2-1 in above example I know is a legitimate account and not been hacked.
Still I could not identify this account Account Unknown (S-1-5-21-1796778222-299937555-3999959969-1026) directly - but I did find 1026!!!
For the record this is a list of common SIDs I found using above setACL command.
Let's now check these suspect SIDS
Get-Acl "C:\ProgramData\Microsoft\Microsoft Antimalware\Network Inspection System" | Format-List
Well I did not find 1111111111-222222222-3333333333.
How to reset ACL for a directory
How to add back inheritance to ACL for that directory.
Do you get accounts like this showing up for file permissions on c:\Windows\Temp:
- Account Unknown (S-1-5-21-1796778222-299937555-3999959969-1026)
According to Microsoft (http://msdn.microsoft.com/en-us/library/windows/desktop/aa379649) these are called SECURITY_NT_NON_UNIQUE S-1-5-21 SIDS are not unique.
An attempt at an explaination is a follows of what SIDS are.
A security identifier (SID) is a unique value of variable length used to identify a trustee. Each account has a unique SID issued by an authority, such as a Windows domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group.
Windows security uses SIDs in the following security elements:
- In security descriptors to identify the owner of an object and primary group
- In access control entries, to identify the trustee for whom access is allowed, denied, or audited
- In access tokens, to identify the user and the groups to which the user belongs
S-1-5-21-527237640-484763769-1060284398-500
- SID => S-1-5-21
- Unique Identifier => 527237640-484763769-1060284398
- RID => 500
- The "S-1" part refers to this being a version 1 Security Identifier.
- The "5" identifies the top-level identifier authority as SECURITY_NT_AUTHORITY.
- All Windows SIDs begin with "S-1-5".
- The first sub-authority is "21", which is SECURITY_NT_NON_UNIQUE, and means indicates a domain id will follow. This means that the value of the SID is made unique by the addition of the RID value (the last part of the decimal format).
- The next three sub authorities "527237640-484763769-1060284398" are 32-bit random numbers to uniquely identify the computer.
- The final part of the SID is the Relative Identifier (RID) of the
object. The local Administrator user on all computers has the same well-known
RID, "500".
Note: If the local computer SID prefix values are not unique, then local user accounts on two different computers can have the same objectSID. For example, the local Administrator user, which always has the same well-known RID value of 500, will have the same objectSID value on two different computers if the local computer SID prefix is the same. Permissions granted to one of these users will apply to the other by mistake.the The RID uniquely identifies an account or group within a domain.
This more focused SIDS and RIDS list available at http://msdn.microsoft.com/en-us/library/cc980032.aspx, and list SIDs in a table format
ADMINISTRATOR
S-1-5-21-
|
A user account for the system administrator. By default, it is the only user account that is given full control over the system.
|
This gives a list of well known SIDS and RIDS, and commonly quoted on other sites
Still, I am stuck for my unknown soldier, the value of 1026 for the RID I cannot find.
- Account Unknown (S-1-5-21-1796778222-299937555-3999959969-1026)
Determine some quick SIDs on your computer from the Windows CMD line;
whoami /user - lists your logged-in username SID
whoami /groups - list user group permission as SIDs, see image below
But this is not giving me a complete comprehensive list of SIDS.
But know I suspect 1026 is part of IIS installed on my computer, given natural progression of numbers, but it is not listed.
If you suspect a you can try to do a reverse look-up of the SID.
You can do the reverse, how to determine Which Account a SID Belongs to by using a Powershell elevated script from http://technet.microsoft.com/en-us/library/ff730940.aspx.
returned Some or all identity references could not be translatedPS C:\>$objSID = New-Object System.Security.Principal.SecurityIdentifier ` ("S-1-5-21-1796778222-299937555-3999959969-1026") $objUser = $objSID.Translate( [System.Security.Principal.NTAccount]) echo $objUser.Value
or
PS C:\> [wmi]"win32_SID.SID='S-1-5-21-1796778222-299937555-3999959969-1026'"
__GENUS : 2
__CLASS : Win32_SID
__SUPERCLASS :
__DYNASTY : Win32_SID
__RELPATH : Win32_SID.SID="S-1-5-21-1796778222-299937555-3999959969-1026"
__PROPERTY_COUNT : 5
__DERIVATION : {}
__SERVER : HOGWARTS
__NAMESPACE : root\cimv2
__PATH : \\THUNDERBIRD-W7U\root\cimv2:Win32_SID.SID="S-1-5-21-1796778222-299937555-3999959969-1026"
AccountName :
BinaryRepresentation : {1, 5, 0, 0...}
ReferencedDomainName :
SID : S-1-5-21-1796778222-299937555-3999959969-1026
SidLength : 28
PSComputerName : HOGWARTS
Still the unanswered question remains, I cannot find this account but it exist.
- Account Unknown (S-1-5-21-1796778222-299937555-3999959969-1026)
Helge Klein has tried to solve this in the following problem statement:
"Due to a lack of visibility permission cleanup is performed far less frequently than it could, and probably should. As a result, ghost ACEs (permissions from deleted accounts) linger in the dark corners of the file system, threatening the unsuspecting admin with the horrors of unresolvable SIDs." http://helgeklein.com/blog/2012/07/finding-removing-orphaned-sids-in-file-permissions-or-busting-the-ghosts-built-into-windows-7/He create setACL, a tool to get identify, find SIDS relative to all programs and deleted accounts on your computer.
Running the the above script produced following output.
So at least S-1-15-2-1 in above example I know is a legitimate account and not been hacked.
Still I could not identify this account Account Unknown (S-1-5-21-1796778222-299937555-3999959969-1026) directly - but I did find 1026!!!
For the record this is a list of common SIDs I found using above setACL command.
C:\Program Files\Common Files\Microsoft Shared\VGX
DACL(protected+auto_inherited):
S-1-15-2-1 read_execute allow no_inheritance
S-1-15-2-1 read_execute allow container_inherit+object_inherit+inherit_only
C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\Data\MSSQL10.SHAREPOINT\MSSQL\Template Data
DACL(not_protected+auto_inherited):
S-1-5-21-1111111111-222222222-3333333333-1019 full allow container_inherit+object_inherit
C:\Program Files\Microsoft SQL Server\100\DTS\Binn
DACL(pseudo_protected+auto_inherited):
S-1-5-21-1111111111-222222222-3333333333-1027 read_execute allow container_inherit+object_inherit
C:\Program Files\Microsoft SQL Server\90\Shared
DACL(not_protected+auto_inherited):
S-1-5-21-1111111111-222222222-3333333333-1028 read_execute allow container_inherit+object_inherit
C:\Program Files\Microsoft SQL Server\MSAS10_50.SQLDEVLOPER\OLAP\Config
DACL(protected+auto_inherited):
S-1-5-21-1111111111-222222222-3333333333-1028 full allow container_inherit+object_inherit
C:\Program Files\Microsoft SQL Server\MSAS10_50.SQLDEVLOPER\OLAP\Data
DACL(protected+auto_inherited):
S-1-5-21-1111111111-222222222-3333333333-1028 full allow container_inherit+object_inherit
C:\Program Files\Microsoft SQL Server\MSAS10_50.SQLDEVLOPER\OLAP\Log
DACL(protected+auto_inherited):
S-1-5-21-1111111111-222222222-3333333333-1028 full allow container_inherit+object_inherit
C:\Program Files\Microsoft SQL Server\MSRS10_50.SQLDEVLOPER\Reporting Services\LogFiles
DACL(not_protected+auto_inherited):
S-1-5-21-1111111111-222222222-3333333333-1026 write+read+DELETE allow container_inherit+object_inherit
C:\Program Files\Microsoft SQL Server\MSRS10_50.SQLDEVLOPER\Reporting Services\RSTempFiles
DACL(not_protected+auto_inherited):
S-1-5-21-1111111111-222222222-3333333333-1026 read_execute+write allow container_inherit+object_inherit
C:\Program Files\Microsoft SQL Server\MSRS10_50.SQLEXPRESS\Reporting Services\LogFiles
DACL(not_protected+auto_inherited):
S-1-5-21-1111111111-222222222-3333333333-1011 write+read+DELETE allow container_inherit+object_inherit
C:\Program Files\Microsoft SQL Server\MSSQL10.SQLEXPRESS\MSSQL
DACL(protected+auto_inherited):
S-1-5-21-1111111111-222222222-3333333333-1006 read_execute allow container_inherit+object_inherit
C:\Program Files\Microsoft SQL Server\MSSQL10_50.SQLDEVLOPER\MSSQL
DACL(protected+auto_inherited):
S-1-5-21-1111111111-222222222-3333333333-1029 read_execute allow container_inherit+object_inherit
C:\Program Files\Microsoft SQL Server\MSSQL10_50.SQLDEVLOPER\MSSQL\DATA
DACL(protected+auto_inherited):
S-1-5-21-1111111111-222222222-3333333333-1029 full allow container_inherit+object_inherit
C:\Program Files\Microsoft SQL Server\MSSQL10_50.SQLDEVLOPER\MSSQL\FTData
DACL(protected+auto_inherited):
S-1-5-21-1111111111-222222222-3333333333-1029 full allow container_inherit+object_inherit
C:\Program Files\Microsoft SQL Server\MSSQL10_50.SQLDEVLOPER\MSSQL\JOBS
DACL(protected+auto_inherited):
S-1-5-21-1111111111-222222222-3333333333-1030 full allow container_inherit+object_inherit
C:\Program Files\Microsoft SQL Server\MSSQL10_50.SQLDEVLOPER\MSSQL\Log
DACL(protected+auto_inherited):
S-1-5-21-1111111111-222222222-3333333333-1029 full allow container_inherit+object_inherit
S-1-5-21-1111111111-222222222-3333333333-1030 read_execute+write+FILE_DELETE_CHILD allow no_inheritance
S-1-5-21-1111111111-222222222-3333333333-1030 read_execute+write+FILE_DELETE_CHILD allow container_inherit+object_inherit+inherit_only
S-1-5-80-1111111111-222222222-3333333333-4444444444-555555555 FILE_LIST_DIRECTORY+FILE_ADD_FILE allow no_inheritance
C:\Program Files\Microsoft SQL Server\MSSQL10_50.SQLEXPRESS\MSSQL
DACL(protected+auto_inherited):
S-1-5-21-1111111111-222222222-3333333333-1014 read_execute allow container_inherit+object_inherit
C:\Program Files\Microsoft SQL Server\MSSQL10_50.SQLEXPRESS\MSSQL\DATA
DACL(protected+auto_inherited):
S-1-5-21-1111111111-222222222-3333333333-1014 full allow container_inherit+object_inherit
C:\Program Files\Microsoft SQL Server\MSSQL10_50.SQLEXPRESS\MSSQL\FTData
DACL(protected+auto_inherited):
S-1-5-21-1111111111-222222222-3333333333-1014 full allow container_inherit+object_inherit
C:\Program Files\Microsoft SQL Server\MSSQL10_50.SQLEXPRESS\MSSQL\JOBS
DACL(protected+auto_inherited):
S-1-5-21-1111111111-222222222-3333333333-1015 full allow container_inherit+object_inherit
C:\Program Files\Microsoft SQL Server\MSSQL10_50.SQLEXPRESS\MSSQL\Log
DACL(protected+auto_inherited):
S-1-5-21-1111111111-222222222-3333333333-1014 full allow container_inherit+object_inherit
S-1-5-21-1111111111-222222222-3333333333-1015 read_execute+write+FILE_DELETE_CHILD allow no_inheritance
S-1-5-21-1111111111-222222222-3333333333-1015 read_execute+write+FILE_DELETE_CHILD allow container_inherit+object_inherit+inherit_only
S-1-5-80-1111111111-222222222-3333333333-4444444444-555555555 FILE_LIST_DIRECTORY+FILE_ADD_FILE allow no_inheritance
C:\Program Files (x86)\Common Files\microsoft shared\VGX
DACL(protected+auto_inherited):
S-1-15-2-1 read_execute allow no_inheritance
S-1-15-2-1 read_execute allow container_inherit+object_inherit+inherit_only
C:\Program Files (x86)\Microsoft SQL Server\90\Shared
DACL(not_protected+auto_inherited):
S-1-5-21-1111111111-222222222-3333333333-1005 read_execute allow container_inherit+object_inherit
S-1-5-21-1111111111-222222222-3333333333-1013 read_execute allow container_inherit+object_inherit
C:\Program Files (x86)\Microsoft SQL Server\90\Shared\ASConfig
DACL(not_protected+auto_inherited):
S-1-5-21-1111111111-222222222-3333333333-1013 FILE_ADD_FILE+FILE_ADD_SUBDIRECTORY+READ_CONTROL allow container_inherit+object_inherit+no_propagate_inherit
S-1-5-21-1111111111-222222222-3333333333-1028 full allow container_inherit+object_inherit
C:\ProgramData\Microsoft\eHome\SharedSBE
DACL(not_protected+auto_inherited):
S-1-5-80-1111111111-222222222-3333333333-4444444444-555555555 change+FILE_DELETE_CHILD allow no_inheritance
S-1-5-80-1111111111-222222222-3333333333-4444444444-555555555 change+FILE_DELETE_CHILD allow container_inherit+object_inherit+inherit_only
C:\ProgramData\Microsoft\Microsoft Antimalware\Network Inspection System
DACL(pseudo_protected):
S-1-5-80-1111111111-222222222-3333333333-4444444444-555555555 full allow container_inherit+object_inherit
C:\ProgramData\Microsoft\Network\Connections
DACL(protected+auto_inherited):
S-1-5-80-31111111111-222222222-3333333333-164347954-1900376235 full allow no_inheritance
S-1-5-80-31111111111-222222222-3333333333-164347954-1900376235 full allow container_inherit+object_inherit+inherit_only
C:\Users\Public\Recorded TV
DACL(not_protected+auto_inherited):
S-1-5-80-1111111111-222222222-3333333333-1563395363-459793767 change+FILE_DELETE_CHILD allow no_inheritance
S-1-5-80-1111111111-222222222-3333333333-1563395363-459793767 change+FILE_DELETE_CHILD allow container_inherit+object_inherit+inherit_only
C:\Windows\Downloaded Program Files
DACL(protected+auto_inherited):
S-1-15-2-1 read_execute allow no_inheritance
S-1-15-2-1 read_execute allow container_inherit+object_inherit+inherit_only
C:\Windows\Globalization\ELS\HyphenationDictionaries
DACL(protected+auto_inherited):
S-1-15-2-1 read_execute allow no_inheritance
S-1-15-2-1 read_execute allow container_inherit+object_inherit+inherit_only
C:\Windows\Globalization\ELS\SpellDictionaries
DACL(protected+auto_inherited):
S-1-15-2-1 read_execute allow no_inheritance
S-1-15-2-1 read_execute allow container_inherit+object_inherit+inherit_only
C:\Windows\Offline Web Pages
DACL(protected+auto_inherited):
S-1-15-2-1 read_execute allow no_inheritance
S-1-15-2-1 read_execute allow container_inherit+object_inherit+inherit_only
C:\Windows\Temp
DACL(protected+auto_inherited):
S-1-5-21-1111111111-222222222-3333333333-1011 read_execute+FILE_ADD_FILE+FILE_ADD_SUBDIRECTORY+DELETE allow container_inherit+object_inherit
S-1-5-21-1111111111-222222222-3333333333-1026 read_execute+FILE_ADD_FILE+FILE_ADD_SUBDIRECTORY+DELETE allow container_inherit+object_inherit
SetACL finished successfully.
So the in the above output there are three records ending with 1026. and the last one is revealing since it it begins with same SID=S-1-5-21 and RID=1026 as in our unknown account. But the 3 sub authorities numbers
1111111111-222222222-3333333333 is supposed to be random and this is not!
LOOKS LIKE THIS IS HACKED ACCOUNT - THIS IS NOT GOOD!
At least this unknown account looks normal;
Account Unknown (S-1-5-21-1796778222-299937555-3999959969-1026)
and we have a match kinda. At least we can at a least get permissions of this owner and some programs that use it.
Account Unknown w/
DACL (protected+auto_inherited)
S-1-5-21-<>
|
File Permission
read_execute+FILE_ADD_FILE+FILE_ADD_SUBDIRECTORY+DELETE
allow container_inherit+object_inherit
|
Get-Acl "C:\ProgramData\Microsoft\Microsoft Antimalware\Network Inspection System" | Format-List
Path : Microsoft.PowerShell.Core\FileSystem::C:\ProgramData\Microsoft\Microsoft Antimalware\Network Inspection System
Owner : NT AUTHORITY\SYSTEM
Group : NT AUTHORITY\SYSTEM
Access : S-1-5-80-1469974279-1943423511-1205514815-3290109594-1875557445 Allow FullControl
NT AUTHORITY\SYSTEM Allow FullControl
BUILTIN\Administrators Allow FullControl
Audit :
Sddl : O:SYG:SYD:(A;OICI;FA;;;S-1-5-80-1467924279-1943423510-1205514805-3190109594-1875307435)(A;OICIID;FA;;;SY)(A;OIC
IID;FA;;;BA)
Well I did not find 1111111111-222222222-3333333333.
How to reset ACL for a directory
How to add back inheritance to ACL for that directory.
Well turns out these did now work either to reset some files, so back to another method.
Tried to use free resource toolkit tool SIDwalker and Showaccs but did not produce any results on Windows 7.
Ultimately, I headed back to SysInternals and found a tool called AccessEnum v1.32.
AccessEnum gives you a full view of your file system and Registry security settings in seconds, making it the ideal tool for helping you for security holes and lock down permissions where necessary. Voila !
But the results of that are in my next post, Using AccessEnum to hunt down unkown file SIDs.
Feb 1, 2017 Update
Well known SIDS
https://support.microsoft.com/en-us/help/243330/well-known-security-identifiers-in-windows-operating-systems
.HIDDEN REGISTRY KEYS - SECURITY & SAM
Some of the security and core system related keys are hidden from user even when part of an administrator group cannot see these special keys.
Here are some of the such hidden registry keys
HKEY_LOCAL_MACHINE\SECURITY
HKEY_LOCAL_MACHINE\SAM
SECURITY registry key stores all the system policy and LSA secrets related information. SAM registry key has details for user accounts along with LM/NTLM password hashes for each user.
There are many ways we can view these hidden registry keys. We can use psexec.exe tool (part of pstools package from sysinternals) to launch the regedit.exe as system account as shown below.
psexec.exe -s -i regedit.exe
HKEY_LOCAL_MACHINE\SECURITY - now you can explore SIDs !
You can delete SIDS using the following technique;
https://helgeklein.com/blog/2012/07/finding-removing-orphaned-sids-in-file-permissions-or-busting-the-ghosts-built-into-windows-7/
omgosh, almost a foreign language. just a little grey-haired old lady here with some "orphans" (I'd guess). Still, I am the only user but use various emails (privacy, business, fun, etc.). I read this twice, just need to know how to have just me. me me me. just me. I got hacked maybe because when my PC went to Geek Squacked, they installed win 7 maybe vista, over win 10. What a hoot. I can't get rid of all the win vista/7 files. There are hundreds, thousands of boot files and I can't get rid of any. Not even the foreign language and did look into language cleaner but is there a reason sometimes the PC might need or require another language to read instructions of some sort? Is this an old post? Didn't pay any attention (old people are sometimes like that, sorry) Happy Trails
ReplyDelete1026 is probably COMPUTERNAME/HomeUsers
ReplyDeleteSo while doing a SCCM decom and re-installation, I came across a system OU that has a couple hundred orphaned sids in it.
ReplyDeleteNever seen it before, and it's bad.
What's the best method to clean it up?
It's rather disturbing to see the level of access the sids have, and the shear amount of them!
I'm stressing about their security, as well as stability now.
A lot of shit to read and no real solutions
ReplyDelete