- Product
Product Overview
Sophisticated security with unmatched simplicityCloud SIEM
Pre-configured detections across your environmentHoneypots
Deception technology to detect lateral movementEndpoint Visibility
Real-time monitoring with added detection & responseSecurity Reports
Data visualizations, compliance reports, and executive summariesAutomated Response
Detect, prioritize, and neutralize threats around the clockIntegrations
Cloud, on-prem, and open API connectionsXDR Platform
A complete view to identify risk, and things operational
- Pricing
- Why Blumira
Why Blumira
The Security Operations platform IT teams loveWatch A Demo
See Blumira in action and how it builds operational resilienceUse Cases
A unified security solution for every challengePricing
Unlimited data and predictable pricing structureCompany
Our human-centered approach to cybersecurityCompare Blumira
Find out how Blumira stacks up to similar security toolsIntegrations
Cloud, on-prem, and open API connectionsCustomer Stories
Learn how others like you found success with Blumira
- Solutions
- Partners
- Resources
As we noted in a previous article, Windows Event Viewer displays limited information for the Event ID 4732 in XML view, leaving you with just a Security ID, and a broken Account Name field to work with.
We’re not always given the exact data we want or how we want it, but when the dust settles and this is the only log we have to work with, we still need to be able to answer the question: Who was added to the admin group?
But First: What is a Security ID?
According to Microsoft, a Security ID (SID), or Security Identifier, uniquely identifies a security principal or security group. A security principal is anything — such as a user account or computer account — that the operating system can authenticate.
Security IDs are stored in a security descriptor data structure, along with any access control lists (ACL) and system ACLs. SIDs are comprised of four parts:
- revision level
- identifier authority
- domain identifier
- relative identifier
Microsoft Windows depends on SIDs for authentication. When users log on to a Windows system, that system creates an access token. This access token includes the user SID, the user’s privilege level, and the SID of groups that the user is in. Then, the access token is authenticated against an ACL to determine what the user has access to.
The whole purpose of Security IDs is to uniquely identify and track users in your environment. It may not be as straightforward as a plain username, but the benefit is that each Security ID is unique for each user. This is helpful if you have users with similar or exact same user names.
Finding a User With Only Their Security ID
Having visibility over users’ permissions in your environment is crucial for Windows security. Let’s go over several different options for finding users, since everyone’s environment and situation is different. This is not an exhaustive list, I just wanted to point out the methods I prefer to use.
The Quickest Method: WMIC
Windows Management Instrumentation Command (WMIC) is a command-line interface for the built-in Microsoft tool, Windows Management Instrumentation, that serves as the infrastructure for management data and operations on Windows operating systems.
This technique is good because it’s a simple one-liner that can give you exactly what you’re looking for. It will find the user account no matter if it’s a domain or a local user. This isn’t always the easiest option because some security controls may be in place that block successful execution. This should be run in an elevated command prompt on the endpoint where the action took place.
Locally:
WMIC useraccount where SID='{member_sid}' get domain,name
Note – it’s possible to perform remote WMIC queries, but that may require some additional configuration that is outside the scope of this article. If you’d like to try remote WMIC or know that you already have it enabled on the target endpoint, this is the command you would send:
WMIC/NODE:{workstation name or IP}/USER:{yourdomain\administrator}useraccountwhere SID='{member_sid}' get domain,name
PowerShell
This method works well and can be a little more straightforward than WMIC. The one disadvantage of this method is that it only finds the user if it exists on the machine you’re running the code on. For domain users, you need to run on a domain controller. For local users, it must be run on the local endpoint where the action occurred.
Local user (run on endpoint):
Get-LocalUser -SID'{member_sid}'
Domain user (run on domain controller):
Get-ADUser -Identity '{member_sid}'
If you want to figure out domain vs local account before running any of these commands, you can run a quick PowerShell command to find your domain ID. The Security ID consists of the domain ID (same for all users accounts in the domain) and the unique user ID (the last four numbers). If the SID you’re working with contains the domain ID, it’s a domain user. If it doesn’t, it’s a local user.
Run on a domain controller:
(Get-ADForest).Domains| %{Get-ADDomain -Server $_}|select name, domainsid
Domain user (SID contains Domain ID):
Local user (SID does not contain Domain ID, instead it uses the Computer SID):
PsTools: PsGetSid
Lastly, I wanted to mention the PsGetSid tool since it was created with this situation in mind and who doesn’t love to use a tool created by Mark Russinovich when they get the chance?
Download and instructions can be found PsGetSid download on Microsoft Sysinternals. This tool works remotely as well, but with the same caveats as WMIC; some security configurations may block the query. In those situations, you have to download and run locally.
Domain user (run on domain controller):
*the command is the same for local users, you just run it on the local endpoint instead
Local user (remote query from a computer on the same network):
PsGetSid has a few other very useful features so I encourage you to check it out and play around with its different options.
That’s it! Not too bad, right? Security IDs are super useful in the right context, but it’s not always what we’re looking for. It may take a little effort to convert a Security ID to its associated user, but, as you can see, there are many methods and tools to help us out.
Learn More About Windows Security
To learn more about Windows logging and security, download our free Guide To Microsoft Security. You’ll learn:
- How to use built-in Windows tools like System Monitor for advanced visibility into Windows server logs
- How to configure Group Policy Objects (GPOs) to give you a deeper look into your Windows environment
- Free, pre-configured tools from Blumira you can use to easily automate Windows logging to enhance detection & response
- What indicators of security threats you should be able to detect for Microsoft Azure and Office 365
You can also try Blumira to quickly and easily detect threats in your Microsoft 365 environment. Signup takes a matter of minutes.Sign Up Free
Frequently Asked Questions
How do I convert a Windows SID to a username using PowerShell?
Run this command: (New-Object System.Security.Principal.SecurityIdentifier("S-1-5-21-xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxxx-1001")).Translate([System.Security.Principal.NTAccount]).Value. Replace the SID string with the actual SID you are investigating. This returns the DOMAIN\Username format. If the command throws an IdentityNotMappedException, the account has been deleted from Active Directory or the local SAM database. For deleted accounts, check the AD Recycle Bin with Get-ADObject -Filter {objectSid -eq "S-1-5-21-..."} -IncludeDeletedObjects if it is enabled. For accounts from untrusted domains, the translation will also fail because your domain controller has no way to resolve a SID it has never seen.
What do the common Windows SID prefixes mean?
The SID structure tells you exactly what type of account you are dealing with. S-1-5-21 followed by three sub-authority numbers is a domain or local machine SID. The last number (the RID) identifies the specific account: 500 is always the built-in Administrator (even if renamed), 501 is Guest, 502 is krbtgt, and 512-519 are built-in domain groups. S-1-5-18 is Local System (the highest-privilege local account), S-1-5-19 is Local Service, and S-1-5-20 is Network Service. S-1-5-32 prefixes are built-in local groups (544 is Administrators, 545 is Users, 546 is Guests). When you see S-1-5-21-...-1000 or higher, those are regular user or machine accounts created after the domain was set up.
Why do Windows security logs show SIDs instead of usernames?
Windows logs the SID at the time the event occurs because SIDs are immutable identifiers. Username resolution happens at display time when you view the event, not when the event is recorded. If the account has been deleted or renamed since the event was logged, the SID remains in the raw event data but the display name lookup fails. This is why you often see unresolved SIDs in older log entries or on systems that have lost trust with the domain controller. It also happens when events reference accounts from external or untrusted domains. The log viewer (Event Viewer, PowerShell, or your SIEM) attempts the translation each time you open the event, so an unresolved SID today might resolve later if the domain trust is restored.
How do I find all SIDs associated with a specific user account?
For the currently logged-in user, run whoami /user to see the primary SID, or whoami /all to see the primary SID plus all group SIDs the token contains. For all local accounts on a machine, use wmic useraccount get name,sid (or Get-LocalUser | Select-Object Name,SID in newer PowerShell). For domain accounts, use Get-ADUser -Identity username -Properties SID,SIDHistory to retrieve both the current SID and any SID history entries (which appear after domain migrations). SID history is important during investigations because a user who has been migrated between domains carries old SIDs that still grant access to resources in the source domain.
How do I investigate orphaned SIDs in Windows security logs?
Orphaned SIDs appear when accounts are deleted but audit logs still reference the original SID. Start by extracting the RID (the last number in the SID). Compare it against known RID ranges: below 1000 suggests a built-in or early-created account, above 1000 is a standard user or computer account. If the AD Recycle Bin is enabled, query it with Get-ADObject -Filter {objectSid -eq "S-1-5-21-..."} -IncludeDeletedObjects -Properties * to recover the original account name and deletion timestamp. If the Recycle Bin is not enabled, check tombstone objects (retained for 60 or 180 days depending on forest functional level). Cross-reference the SID's timestamp in your logs with the account deletion timestamp to determine whether the account was used after it should have been disabled, which is a common indicator of compromise.
Jake Ouellette
Jake is an Incident Detection Engineer at Blumira, where he contributes to research and design efforts to continuously improve the detection, analysis, and disruption capabilities of the Blumira platform.
More from the blog
View All Posts
Product Updates
7 min read
| November 14, 2023
Now Available: Blumira Agent for Windows, Mac & Linux
Read More
Security Trends and Info
12 min read
| October 21, 2021
Firewall vs Antivirus: What’s The Difference?
Read More
Security How-To
16 min read
| October 18, 2022
Event ID 4732: The Case of the Missing Username
Read MoreSubscribe to email updates
Stay up-to-date on what's happening at this blog and get additional content about the benefits of subscribing.






