October 26, 2022

    Find a User with Their Security ID in Windows

    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}'

    Windows command prompt whoami /user showing current SID

    Domain user (run on domain controller):

    Get-ADUser -Identity '{member_sid}'

    PsGetSid Sysinternals tool output for SID resolution

    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

    Windows command prompt showing SID lookup with wmic

    Domain user (SID contains Domain ID):

    Registry editor showing SID-to-username mapping

    Local user (SID does not contain Domain ID, instead it uses the Computer SID):

    Active Directory Users and Computers SID lookup

    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):

    PowerShell Get-ADUser command output with Security ID

    *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):

    Windows Event Viewer showing security event with SID

    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

    Blumira Guide to Microsoft Security cover imageTo 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