Successful Local Security Group Creation

The events shown in Listings 6-1 through 6-7 will appear in the Windows security event log when a new local security group is successfully created.

This event represents a handle request invoked by the Subject.

To create a new local security group a request to create a new local group (CreateLocalGroup access type) should be sent to the Security Account Manager SAM_DOMAIN instance.

The Object Server:Security Account Manager represents the Security Account Manager system module, which is responsible for managing the Security Account Manager database. This database contains information about local security groups, local user accounts, user account passwords (stored as hashes), user account parameters, the group's parameters, and so on.

Object Type:SAM_DOMAIN represents a Security Account Manager domain in which a new local security group is created. The Object Name field contains the name of the SAM_DOMAIN object. It can be an Active Directory domain name if it is a domain group created on a domain controller, or a machine name for local security groups.

The access types (Accesses field) requested for the Security Account Manager SAM_DOMAIN are:

• %%5398: CreateLocalGroup
• %%5401: LookupIDs

(See Table 5.1 for the full list of SAM_DOMAIN object access rights.)

The CreateLocalGroup access type is required to create a new local group. The list of requested access permissions in this event might be different, but it must contain CreateLocalGroup access type.

The Access Mask field contains the hexadecimal mask of requested accesses. More information about SAM_DOMAIN access type hexadecimal values is shown in Table 5.1.

This event also shows a Process Information section, which usually contains lsass.exe (Local Security Authority Subsystem Service) as the process that was used to perform a handle request. lsass.exe is a default process that is authorized to manage Security Account Manager objects. This event is not supposed to tell you which process was initially used to request specific accesses. It shows you the process which invoked Security Account Manager functions (lsass.exe). It does not show you which process initially requested a new handle using lsass.exe functions.

There is no information about how a new local security group was created or which tools were used. You can try to track 4688 process creation events, which occur prior to new local group creation events, to find which applications were run before a new local security group was created.

The event in Listing 6-2 informs you about new local security group creation.

There are two types of local groups that you might see in Windows security events:

• Security-enabled: Standard security groups
• Security-disabled: Active Directory distribution groups

In this event you also can find who created a new group (Subject) and some information about the newly created group. For local security groups the Group Name always has the same value as the SAM Account Name.

The SID History attribute is not applicable to nondomain security groups.

This 4731 event contains all important information about successful local group creation:

• Who created a new group: Subject
• The name of newly created group: Group Name
• When new group was created: Event generation time

Listing 6-3 shows a local security group change event. The biggest problem with this event is that it shows changes to only a limited set of attributes: SAM Account Name and SID History. Basically, it shows only changes to SAM Account Name attribute, which is a name of the security group, because SID History field is not applicable to local security groups.

In this event you see that a change was made to the NewGroup local security group, but, unfortunately, there is no information in this event about what exactly was changed. This happens when some attribute of the group was changed, for example Description field or group access permissions (DACL), which is not included in the 4735 event schema.

Listing 6-4 shows that the handle, which was opened to the SAM_DOMAIN entity for a group creation operation, was closed, because all required actions were completed.

The Handle ID field in this event will have the same value as the Handle ID field in the initial handle request 4656 event.

Listing 6-5 is another handle request, but this time it is for the SAM_ALIAS Security Account Manager object. The SAM_ALIAS object type represents the local security group entity.

The Object Name field contains a path to the requested local security group object in the Security Account Manager database. The last part, 000003EA, represents relative identifier (RID) of the group for which the handle was requested in hexadecimal format. Hexadecimal 000003EA is decimal 1002.

You also can see that the WriteAccount access type was requested (Accesses field). The Access Mask field contains the hexadecimal mask value for requested accesses. More information about SAM_ALIAS access type hexadecimal values you can find in Table 5.5.

This event means that the Subject requested WriteAccount access to the local security group with RID = 1002. WriteAccount access means a Write operation to the Security Account Manager object. It can be interpreted as an object modification request.

Listing 6-6 shows local security group change event without any information about what exactly was changed. This change was initiated using the handle requested in the previous 4656 event.

Listing 6-7 shows that the handle, which was opened to the SAM_ALIAS DOMAINSAccountAliases00003EA object, was closed, because all required actions were completed.

Unsuccessful Local Security Group Creation - Access Denied

When an account doesn't have required permissions to create a local security group, the event in Listing 6-8 is recorded in the Windows security event log.

This event is an Audit Failure event that informs you that the Subject failed to get CreateLocalGroup and/or LookupIDs access types for the SAM_DOMAIN Security Account Manager entity. Event 4656 does not show you which access or accesses from the list of requested access types were not granted.

No other events will be recorded for an Access Denied local group creation scenario. After the Subject fails to get the required accesses/access to create a new local security group, no other operations are possible.

Monitoring Scenarios: Local Security Group Creation

A useful event to monitor for successful local security group creation is:

A useful event to monitor for unsuccessful local security group creation is:

In general, all successful and, especially, unsuccessful local security group creation events should be monitored. Highest priority should be given to monitor any security group creation operation on high-importance/critical hosts, such as critical servers, administrative workstations, and so on.

Creation of a new local security group is not a common action performed after initial system setup. After a new system is provisioned and all required roles, components, features, and software are installed, it's not typical for additional local security groups to be created.

Monitor these events:

• Monitor for any “4731: A security-enabled local group was created” event.
• Monitor for “4656: A handle to an object was requested” Audit Failure events with the Access Mask field equal to 0x240 and the Object Type field equal to SAM_DOMAIN.

  Here is the XPath filter for this monitoring:

  *[System[band(Keywords,4503599627370496) and (EventID=4656)]] and 
  *[EventData[Data[@Name='ObjectType'] and (Data='SAM_DOMAIN')]] and 
  *[EventData[Data[@Name='AccessMask'] ='0x244']]
  

Successful Local Security Group Deletion

The events in Listings 6-9 through 6-12 appear in the Windows security event log when a local security group is successfully deleted.

This is the initial handle request for this security group operation.

A handle with DELETE access must be requested for the specific SAM_ALIAS Security Account Manager object that represents the group to be deleted. In this example, the local security group SAM object for deletion is DOMAINSAccountAliases00003EA. The last part of the Object Name field value represents the RID of a local security group.

Event 4734 (Listing 6-10) indicates a successful local security group deletion operation.

This event has answers for the following questions:

• Who deleted the security group: Subject
• Which local security group was deleted: Group

A local security group is an object in the Security Account Manager database. Because an object for specific local security group was deleted, you will see the event in Listing 6-11, which informs you about this.

The only way to get information about which object was deleted is to find the corresponding “4656: A handle to an object was requested” event with DELETE access requested and with the same Handle ID (0x26fddeb73e0) field value.

Listing 6-12 shows that the handle that was opened to the SAM_ALIAS DOMAINSAccountAliases00003EA object for this deletion operation, was closed, because all required actions were completed.

Unsuccessful Local Security Group Deletion - Access Denied

When a user doesn't have DELETE permissions for a specific local security group, a handle request will fail and the event shown in Listing 6-13 will be generated in the Windows security event log.

The Andrei account was not able to get a handle with DELETE permissions for the DOMAINSAccountAliases00003EC SAM_ALIAS object.

The Audit Failure 4656 event is the only event generated when a user account has no required permissions to delete a specific security group SAM object.

Unsuccessful Local Security Group Deletion - Other

When a local security group is not deleted for another reason—for example, if someone tried to delete a built-in local security group such as the local Guests group—the event shown in Listing 6-14 is generated in the Windows security event log.

The “4656: A handle to an object was requested” Audit Success event is the only event generated if a local security group is not successfully deleted and the reason is not insufficient permissions.

From the system's perspective, access to the specific local security group was successfully granted, but then it was denied at the application level, which the system does not monitor. You should verify whether a “4734: A security-enabled local group was deleted” event occurs after a handle request event. If yes, the security group was successfully deleted; if no, it was not deleted, but someone tried to do it.

Monitoring Scenarios: Local Security Group Deletion

A useful event to monitor for successful local security group deletion is:

Useful events to monitor for unsuccessful local security group deletion are:

Any successful and unsuccessful access denied local security group deletion events should be monitored on all hosts. As is true for local security group creation actions, a local security deletion operation is not a common action performed during a system's lifetime. Even at initial system setup, local security group deletion is not usually performed. It's more likely that a group creation operation will be performed.

Monitor these events:

• Monitor for any “4734: A security-enabled local group was deleted” event.
• Monitor for “4656: A handle to an object was requested” Audit Failure events with Access Mask field equals to “0x10000” and Object Type field equals SAM_ALIAS.

  The XPath filter for this monitoring is:

*[System[band(Keywords,4503599627370496) and (EventID=4656)]] and 
*[EventData[Data[@Name='ObjectType'] and (Data='SAM_ALIAS')]] and 
*[EventData[Data[@Name='AccessMask'] ='0x10000']]

Successful Local Security Group Change

Any change to the local security group, except changes in group membership, will generate the events shown in Listings 6-16 through 6-18

To make changes to the local security group object, an account must have WriteAccount permission for this group. The event in Listing 6-15 occurs for any change and shows an access request for a specific SAM_ALIAS Security Account Manager object.

The local security group change event shown in Listing 6-16 provides the following important information:

• Which group was changed: Group
• Who made a change: Subject

Unfortunately, changes to a security group's description field are not shown in the 4735 event. The only included changed attributes are:

• SAM Account Name: Group's name
• SID History: Not applicable to local security groups

Changes in the Description attribute of a local security group will invoke a 4735 event, but this event will not have any information about what exactly was changed.

Group membership delete/add operations do not generate a 4735 event.

If the group's name was changed, both the Group and Changed Attributes sections will show the new group name, but you will not be able to get the group's previous name:

Group:
      Security ID:         S-1-5-21-3212943211-794299840-588279583-1004
      Group Name:          NewGroupName
      Group Domain:        2016SRV

Changed Attributes:
      SAM Account Name:    NewGroupName
      SID History:         -

If the security group name was changed, then in addition to a 4735 event, the 4781 event shown in Listing 6-17 is generated.

The event in Listing 6-18 has an Old Account Name field, which shows you group's previous name. After the group name change is done, the handle, which was requested for this operation, is released (Listing 6-18).

Unsuccessful Local Security Group Change - Access Denied

By default, only local administrators and the Local System account can change a local group's name. If any nonadministrative account tries to change the settings for any local security group, it will get an access denied message and the event shown in Listing 6-19 will be generated in the Windows security event log.

In an “Access Denied” scenario you will see an Audit Failure event, with a WriteAccount access request to a specific Security Account Manager security group object. No other events will be generated.

Monitoring Scenarios: Local Security Group Change

Useful events to monitor for successful local security group change are:

A useful event to monitor for unsuccessful local security group change is:

Security group name modification is a very uncommon operation. Usually it's not critical to monitor security group name changes, but in some scenarios it might be needed. For example, you should track any changes on critical hosts and any changes to specific high-importance local security groups, such as the built-in local Administrators group. In general, security group changes (except operations with group membership) are not important to monitor.

Successful New Local Group Member Add Operation

When a new member is added to a local security group, the messages shown in Listings 6-20 through 6-23 occur in the Windows security event log.

As shown in Listing 6-20 the following access rights are requested by default when a new member is added to the security group using the Computer Management console:

• %%5424 (AddMember)
• %%5425 (RemoveMember)
• %%5426 (ListMembers)
• %%5427 (ReadInformation)

Whether an account is added or removed from the security group, all four access types will be requested by the Computer Management console. The only access permission that must be requested to add a new member is AddMember. It is up to an application which permissions to request for a specific operation.

Listing 6-21 informs you about the addition of a new member to a local security group.

This event has the following information in it:

• Who added the new member to the local security group: Subject
• What new member was added to the group: Member
• To which group was the new member added: Group

The Member: Account Name field is always empty for local security groups, because it's designed to show the distinguished name for Active Directory groups and users. See more information in Chapter 7.

For all built-in local security groups, which were listed at the beginning of this chapter, the Group Domain field is always Builtin. For all manually created local security groups this field has a value equal to the local machine name:

Group:
      Security ID:         S-1-5-21-3212943211-794299840-588279583-1004
      Group Name:          NewGroup
      Group Domain:        2016SRV

Event 4658 in Listing 6-22 shows that a handle opened for a previous operation has been closed.

The event in Listing 6-23 generates each time group membership for a local security group is enumerated.

This event happens, for example, when the Computer Manager (compmgmt.msc) console application gathers information about group members for a specific security group. It happens when you open any group details, as illustrated in Figure 6-4.

If you use other methods to add a member to a local security group, which do not perform group membership enumeration, such as the following PowerShell script:

$group = [ADSI]"WinNT://2016srv/newgroup,group"
$group.Add(„WinNT://2016srv/andrei,user")

then a “4799: A security-enabled local group membership was enumerated” event will not be generated.

Useful information in this event is the Process Name field, which shows the name of the process used to perform the action.

Successful Local Group Member Remove Operation

A group member removal operation, performed using the Computer Management console, has exactly the same events recorded in the Windows security event log as a successful new local group member add operation, except the “4732: A member was added to a security-enabled local group” event is replaced by the event shown in Listing 6-24.

This event has the same fields as the “4732: A member was added to a security-enabled local group” event, and shows you which security principal was removed from the specific local security group.

Unsuccessful Local Group Member Remove/Add Operation - Access Denied

If a user account doesn't have sufficient permissions to add/remove members from a security group it will get an “Access Denied” message. Both add and remove operations generate the event in Listing 6-25 in the Windows security event log.

Both “add member” and “remove member” events have AddMember, RemoveMember, ListMembers, and ReadInformation access types in a handle request when operation is performed using the Computer Management console. There is no ability to differentiate which exact operation was requested: remove member or add member. Member add operations require AddMember permission and member remove operations require RemoveMember permissions.

Monitoring Scenarios: Local Security Group Members Changes

Useful events to monitor for successful local security group members changes are:

A useful event to monitor for unsuccessful local security group members changes is:

It is critically important to perform monitoring of any successful and unsuccessful change to critical and high-privileged built-in and manually created security groups. The following built-in local security groups are considered high privileged:

• Administrators
• Backup Operators
• Network Configuration Operators
• Remote Desktop Users
• Remote Management Users
• WinRMRemoteWMIUsers__

Also, it's unusual to remove or add members to local security groups too often. Usually it happens when a machine joins the Active Directory domain or during role, feature, or application installation or removal. Any successful and unsuccessful member add and remove operations should be monitored.

Monitor these events:

• Monitor any “4733: A member was removed from a security-enabled local group” event.
• Monitor any “4732: A member was added to a security-enabled local group” event.
• Monitor for “4656: A handle to an object was requested” Audit Failure events with Access Mask field equals to “0xF” and Object Type field equals SAM_ALIAS.

  The XPath filter for this monitoring is:

  *[System[band(Keywords,4503599627370496) and (EventID=4656)]] and 
  *[EventData[Data[@Name='ObjectType'] and (Data='SAM_ALIAS')]] and 
  *[EventData[Data[@Name='AccessMask'] ='0xF']]
  

Monitoring Scenarios: Local Security Group Membership Enumeration

A useful event to monitor for successful local security group membership enumeration is:

A local security group membership enumeration event is mostly informational and could be monitored if needed.