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?
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:
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.
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.
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
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):
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 here. 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.
You can also try Blumira’s Free Edition to quickly and easily detect threats in your Microsoft 365 environment. Signup takes a matter of minutes.
