Event ID 4732: The Case of the Missing Username

Event ID 4732 – A member was added to a security-enabled local group

As described, this Event ID tracks when a member — either a domain user or local user —  is added to any security-enabled local group. 

There are many local groups, but the most commonly monitored local group is the local Administrator group. Membership to this group will grant users elevated privileges to this specific endpoint and, as a result, give them full permissions to make any changes to the system that they would like. 

Event ID 4732: Stats

Local Users vs. Domain Users vs. Security-Enabled Local Groups

First, let’s define the types of accounts and groups we’re dealing with.

Domain user accounts are any accounts that are created and stored on a domain controller. In use or seen in logs, these accounts are usually prepended with the domain name. These accounts can be used to log in to any domain-joined endpoint.

MyDomain\JohnSmith

JohnSmith@MyDomain

Local users are created and stored only on the endpoint itself. The endpoint, in this case, is a workstation or laptop running a Microsoft Windows operating system. Local user accounts will be prepended with the name of the endpoint. These accounts can only be used on the endpoint they are created and stored on. In the following example, our workstation name is “WKSTN009”.

WKSTN009\JohnSmith

JohnSmith@WKSTN009

.\JohnSmith

Security-enabled local group is a group created and stored only on the endpoint itself. It does not grant access to any domain resources, only to resources and permissions on the local endpoint. The most commonly used local groups are Administrators and Remote Desktop Users. Local groups are typically prepended with “BuiltIn”.

BuiltIn\Administrators

BuiltIn\Remote Desktop Users

What To Know About Event ID 4732

During testing and research of a detection to track changes made to the local administrators group, we found a small quirk with Event ID 4732: the security log itself does not contain the username of who got added to the local group. This creates some difficulties when those event logs are forwarded and reviewed elsewhere and not on the originating endpoint itself.

When viewed inside Windows Event Viewer, in the General view, all looks good and you get all the additional information you could possibly want, such as group domain, event ID, security ID, keywords, and account domain.

However, if we review that same exact log in the xml view, we see that the Security ID is shown in the less user-friendly format.

This same behavior is exhibited when a domain user is added to a local group as well. Another interesting finding is that “Account Name” under the Member field always just shows a hyphen. This results in the “MemberName” entry in the xml format to be a hyphen as well and provide us with no usable name. 

Here’s looking at this same log, but just focusing on the target user portion:  

General View

XML View

When viewing this log in the General view, we can see that the username and domain are easily readable. However, in the XML view, the Security ID is shown in its original, more complex form. Similar to how DNS converts IP addresses into websites that are easier to remember, there is an internal lookup happening on this local endpoint that associates the Security ID with the username. It’s great that this happens because, depending on your use case, you may prefer to have a Security ID over a plain username or vice versa. You can read more about the purpose of Security IDs (SIDs) and how they’re generated here. 

However, it seems there is some sort of bug that prevents these logs from ever displaying anything under “Account Name.” I’ve reviewed a ton of live data as well as other articles online that show screenshots with the same results – always showing a hyphen. I have a feeling the system attempts to log changes to this group, so it asks the group to tell it which member is being targeted. Since the user is being added to the group and isn’t a member yet, it doesn’t exist in the group until after the change happens. When the log is taken, the group doesn’t know who the user is, so the group reports a hyphen back to Event Viewer. This isn’t so much a problem if you can view these logs in the General view, but that’s not always possible. 

If these logs are being shipped to a security information and event management (SIEM) or some other tool, you may only end up with the XML data. This leaves us with just a Security ID and a broken Account Name field to work with. Not ideal.

Learn how to look up a user with only their Security ID.

Going Beyond Windows Event Viewer

While Windows Event Viewer can be used to investigate single instances on an endpoint, the ability to correlate that data can be a large advantage to any security team. The default logging enabled on a Microsoft AD Domain and all endpoints doesn’t include a fraction of the helpful data that you can obtain — enabling Sysmon can extend those capabilities, however.

Here are a few modifications that can offer a deeper look into your Windows environment.

To learn more about Windows logging, download our free Guide To Microsoft Security.