Successful Local User Account Creation

The sequence of security events that appears in the security event log when new user account is created using the standard Computer Management snap-in is discussed in this section. The standard user Computer Management snap-in user creation window is shown in Figure 5-1.

The events shown in Listing 5-1 appear in the Windows security event log when a new local user account is successfully created:

The first step in local user account creation is that CreateUser access (along with other access types) is requested for the local Security Account Manager (SAM) database, where all local account objects are stored. As a result, an object handle for the SAM database will be returned, which can be used to perform the required operation. The event in this example is an Audit Success event, which means that requested access types were successfully granted.

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 user accounts, their passwords (stored as hashes), parameters, and so on. You can find more information about Security Account Manager in Chapter 4.

Object Type:SAM_DOMAIN represents a type of SAM object for which a handle was requested. The SAM_DOMAIN object type represents an entity of the SAM database domain, usually the machine itself.

This event shows you that the account with the name Administrator originated from domain 2016DC (it's a machine name in this case) and requested the %%5392 (ReadPasswordParameters), %%5396 (CreateUser), and %%5401 (LookupIDs) access permissions for the Security Account Manager's SAM_DOMAIN object named 2016DC (machine name). The request was sent by the process named C:WindowsSystem32lsass.exe and Process ID 0x30c.

The Windows Event Viewer automatically resolves all access type constants into values. For example, the %%5392 constant will be shown in the Windows Event Viewer as ReadPasswordParameters.

The Access Mask field contains a hexadecimal value for the sum of requested access rights. Table 5-1 contains a list of constants and access mask values that are defined for SAM_DOMAIN object type in Windows operating systems.

Access Mask in the current event has a value of 0x2110, which is a sum of the following hexadecimal access right constants: 0x200 (LookupIDs) + 0x10 (CreateUser) + 0x01 (ReadPasswordParameters).

The Subject:Security ID field contains the Security Identifier (SID) of the security principal that performed this access request. The Windows Event Viewer automatically resolves SIDs whenever possible.

Listing 5-2 is the main event, which shows you that the new account was successfully created.

This event contains answers for some of our initial questions:

• Who created the user account? Answer: Subject: Account Domain + Subject: Account Name.
• When was the user account created? Answer: the event creation time.

The important information here is the New Account: Account Name field, because it contains the name of the newly created account.

Note that any local user account created using the Computer Management snap-in, by default, is created in a disabled state and has the Password Not Required flag set. Both these attributes/flags will be changed after the account is created, as you see later in this chapter. Also, the default global primary group for all newly created local accounts is the built-in local None security group. You can see it in the Primary Group ID attribute value 513, which is a Relative Identifier (RID) of the built-in local None security group. It means that account has no global primary group. It is interesting to know that in an Active Directory environment, an RID of 513 corresponds to the default Domain Users group, instead of None for non–domain-joined machines. You see more information about the “None” local security group in the next section.

By default, if you use the Computer Management snap-in, local user accounts are created with a blank/empty password and then the password reset operation is performed. That is why the Password Last Set attribute for newly created accounts has a value of %%1794 (<never>).

The Display Name attribute, by default, is %%1793 (<value not set>).

New user accounts, by default, are created with the following account properties:

• %%2080 (Account Disabled)
• %%2082 ('Password Not Required' - Enabled)
• %%2084 ('Normal Account' - Enabled)

Table 5-2 contains a complete list of user account UAC setting constants and access mask values defined in Windows operating systems.

You can also see these flags in a hexadecimal mask in the New UAC Value field. It's equal to 0x15 in our example. Table 5-2 contains all hexadecimal values for all possible UAC flags for user account objects. All flags are disabled by default. You will see more information about Old UAC Value and New UAC Value fields in the “Local User Account Change” section later in this chapter.

This event also contains many other attributes, but they are not as important as those discussed in this section.

As shown in Listing 5-3, immediately after creation, the new user account (Member: Security ID) becomes a member of the built-in global None security group, which, basically means this account is not a member of any global group. This built-in group is not displayed by the whoami /groups command or the Computer Management snap-in, but it is a valid local security principal and has an RID of 513.

The term global security group is applicable to the Microsoft Active Directory environment. Local accounts are not members of any global security groups, but local accounts still have the Global Group property, which can be shown using the net user command as shown in Figure 5-2.The Global Group property might be used by some non-Microsoft systems for specific purposes.

Listing 5-4 shows the account being enabled, because by default all local user accounts that are created using the Computer Management snap-in are created in the disabled state.

Listing 5-5 shows a password reset event, which informs you about a password set operation performed on a newly created account. The password, which you typed during account creation, is set at this step.

The 4738 event shown in Listing 5-6 informs you that the Password Not Required UAC flag was set to Disabled. Unfortunately, the 4738 event doesn't really show you which attribute was changed; it just shows you a value, which can be a newly set value or an unchanged current value. For example, in this case it's not clear whether Password Last Set changed or still shows its previous/current value. The User Account Control section shows only information about changes; if no changes were made, this section will be empty.

This event also shows that the Display Name user account property got the same value as the SAM Account Name field.

The 4738 event will be covered in more detail later in this book.

The event in Listing 5-7 informs you that the previously opened handle with ID 0x184580fcf70 was closed. This handle was opened for the CreateUser operation for the Security Account Manager SAM_DOMAIN 2016DC object.

The event in Listing 5-8 exists only on Windows Server 2016 and Windows 10 operating systems. Multiple 4798 events are shown in the security event log during new local user account creation.

Event 4798 informs you that the Administrator account (Subject) enumerated the local group membership of the NewUser account (User) using C:WindowsSystem32mmc.exe. This means that one of the Microsoft Management Console (MMC) tools were used—in this case it was usermgmt.msc.

This event is informational only in the case of new user creation.

Listing 5-9 shows that at this time some access types (Accesses) are requested for the Security Account Manager's SAM_USER object with the name DOMAINSAccountUsers00003EA.

The SAM_USER object type represents a local user account entity.

DOMAINSAccountUsers00003EA is a path in the Security Account Manager database to the object to which access was requested.

000003EA represents the account's RID in hexadecimal format, which is 1002 in decimal. It is the RID of our newly created account.

You can use the following PowerShell code to get the SID of a specific local user account:

$objUser = New-Object System.Security.Principal.NTAccount
                                         ("ACCOUNT_NAME")
$strSID = $objUser.Translate([System.Security.Principal.
                                    SecurityIdentifier])
$strSID.Value

Figure 5-4 shows an example of an output of this script for the “newuser” local account.

The Accesses field contains a list of access rights requested for the SAM_USER object. Table 5-3 contains a list of access right constants that are defined for SAM_USER object types in Windows operating systems.

The Access Mask field contains the hexadecimal value for the sum of requested access rights.

The Access Mask in the current event is 0x601B4, which is a sum of the following SAM_USER object access rights: 0x04 (WritePreferences) + 0x10 (ReadAccount) + 0x20 (WriteAccount) + 0x80 (SetPassword (without knowledge of old password)) + 0x100 (ListGroups) and the standard access rights 0x20000 (READ_CONTROL) + 0x40000 (WRITE_DAC). The following sidebar contains information about standard access rights.

Returning to the event in Listing 5-9, basically speaking, it shows you that some access types were successfully requested for our newly created user account SAM object.

The event in Listing 5-10 shows us that the user account's Display Name property was changed to Andrei Miroshnikov. But, as I already mentioned, for some properties (Display Name is one of them) this event always shows a value, whether was it changed or not, and in this case you can only guess whether this property changed or not. In this example we know that it was changed only because we made the change. In practice, you wouldn't know by looking at this.

Then, as Listing 5-11 shows, the handle with ID 0x184580fc100 was closed.

Next, a handle request event is issued for the Security Account Manager's SAM_USER object with the name DOMAINSAccountUsers00003EA. Refer to Listing 5-9; this request is identical.

The event in Listing 5-12 is absolutely the same as the previous 4738 event in Listing 5-10. One of the problems related to the “4738: A user account was changed” event is that for some actions it triggers but doesn't show the real change that causes it. For example, when the user account description (Description property) changes it triggers a 4738 event, but doesn't show the Description property change in the event itself. Because there is no information about this change in the event, you can only guess what really was changed.

So, this event shows us that something was changed in the user account NewUser but it does not tell us what exactly was changed.

Listing 5-13 shows that the handle, which was opened for the previous account change operation, was closed.

The event in Listing 5-14 shows that some access permissions (Accesses) are requested for the Security Account Manager's SAM_ALIAS object with the name “DOMAINSBuiltinAliases0000221”.

The SAM_ALIAS object type represents the local security group entity.

DOMAINSBuiltinAliases0000221 is a path in the Security Account Manager database to the object to which access was requested. You already know how you can view the real object in the SAM database using regedit.exe application. The hexadecimal value 0x221 converts into decimal 545 and belongs to the built-in local Users security group.

This event shows you that the handle for the local Users security group was requested, which allows the following: operations: AddMember, RemoveMember, ListMembers, and ReadInformation.

The Access Mask field contains a hexadecimal value for the sum of the requested access permissions. Possible access permissions for the SAM_ALIAS object are listed in Table 5-5.

The Access Mask in the current event is 0xF, which is a sum of the following SAM_ALIAS object access rights: 0x01 (AddMember) + 0x02 (RemoveMember) + 0x04 (ListMembers) + 0x08 (ReadInformation).

Listing 5-15 shows the next event which, as expected, tells you that the account with SID S-1-5-21-3815211123-123488468-2019406087-1002 (NewUser) was added to the security group with SID S-1-5-32-545 (Users) by the Administrator account. Unfortunately, the Member: Account Name field is designed to show information only about domain accounts, not local accounts. For domain accounts it shows the account's distinguished name (DN).

Listing 5-16 shows that the handle, which was opened for the previous group membership change operation, was closed.

Now you know the sequence of events that shows in the Security event log each time a new local user account is created using the Computer Management snap-in. And now you know the answers for the following questions (see Listing 5-2: Event ID 4720: A user account was created.):

• Who created the user account? The answer is in the event Subject section.
• When was the user account created? Event 4720 provides the event creation time.
• The name of newly created account? The account name is shown in the event New Account section.
• How was this account created? There is no easy way to detect how exactly the account was created, using which tools, scripts, applications, or other methods. A general recommendation here is to inspect all events prior to the account creation event and try to find any information about methods being used to create the account. For example, you may search for the “4688: A new process has been created” event to find the name of the application that was run right before the account was created.

  Sometimes you may find some useful events in the “Application” event log that were generated at the same time the user account was created.

Unsuccessful Local User Account Creation: Access Denied

The unsuccessful local user account creation events sequence, where the Subject account had no required permissions to create new local account, has only one event in it, shown in Listing 5-17.

This is a failed handle request event. It is almost the same as the 4656 handle request event that you saw for the successful local user account creation operation in the Listing 5-1, but in this case it has an Audit Failure event type.

This event shows you that account amirosh (Subject) requested ReadPasswordParameters, CreateUser, and LookupIDs access types for the SAM_DOMAIN 2016DC Security Account Manager object and the request failed.

Here are the answers for the most important questions you might have about a failed local account creation event, where the reason for the failure is “access denied” (see Listing 5-17: Event ID 4656: A handle to an object was requested):

• Who tried to create new user account?

  The answer is in the Subject section.

• When did this happen?

  4656 is the Audit Failure event creation time.

• How did it happen?

  In an Audit Failure event you can see information about the process that was used for the handle request operation (Process Information section).

• Where can I find more details about the account that is supposed to be created?

  There is no event in the security event log that provides this information You might try to find this information in the application-specific logs.

Unsuccessful Local User Account Creation: Other

If the Subject account has all required permissions to create a new local user account but the creation operation failed for some other reason (for example, a user account with the same name already exists), you will find the event shown in Listing 5-18 in the security event log.

Because the Subject account has all required permissions to create new local user accounts, it will not have any problems getting a handle to the SAM_DOMAIN COMPUTER_NAME Security Account Manager object with the CreateUser access permission.

However, after the handle is received by Subject, the account creation operation may fail at the application level and no more events will be recorded in the security event log. In this situation only the “ID 4658: The handle to an object was closed” Audit Success event will be recorded after a successful “ID 4656: A handle to an object was requested” event.

But this event still must be considered a new local user account creation attempt by an account with sufficient permissions, which failed for some other reason.

Monitoring Scenarios: Local User Account Creation

Useful events to monitor for successful and unsuccessful local user account creation are shown in Table 5-6.

Any successful local user account creation events should be monitored on high-value and critical hosts. Usually, after initial system setup, no local user accounts are created. Each local account creation event must be investigated and the root cause of this operation must be found.

Some scenarios in which a new local user account needs to be created include:

• By malware, as persistence method for the malware to remain in the system
• By software, server role, or feature installation
• Manually, as a dedicated account for system service or scheduled tasks

You should monitor for any “4720: A user account was created” Audit Success events.

On high-value and critical hosts, monitor for any unsuccessful local user account creation event that fails due to insufficient access permissions. Each such attempt is important because someone or something tried to create a local user account without having required permissions.

In this case you should monitor for “4656. A handle to an object was requested” Audit Failure events with an Access Mask field equal to "0x211" and the Object Type field equal to SAM_DOMAIN.

• The XPath filter for this is shown in the following code:

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

It is recommended that you have a list of accounts (domain and local) that are allowed to create local user accounts. If you have such a list, you should compare every “4720: A user account was created” event Subject field with this list.

For example, you know that only Domain Admins should be used to create local user accounts on domain-joined machines. You should compare the Security ID field with the SIDs of all Domain Admins accounts in order to verify that. In this case you should set an event importance level to “High” if any other account was used to create a local user account.

For non–domain-joined machines, for example, only the built-in local Administrator account should be used to create new local user accounts by default. In this case you could check the Account Name field in the 4720 event—it should have an “Administrator” value. Or, you can check that the Security ID value has an RID of 500.

Monitor these events:

• Monitor for “4720: A user account was created” Audit Success events.
• Monitor for “4656: A handle to an object was requested” Audit Failure events with an Access Mask field value equal to "0x211" and the Object Type field value equal to SAM_DOMAIN.
• Monitor for “4656: A handle to an object was requested” Audit Success events where the Access Mask field value equals "0x211" and the Object Type equals SAM_DOMAIN. Unfortunately, in this case, there is no information in the event about whether the account creation operation completed successfully or not. You need to also verify whether there are any “4720: A user account was created” events in the event log after the “4656: A handle to an object was requested” event. If not, the account creation attempt was not successful.

All local user accounts created using built-in Windows operating system tools (such as the Computer Management snap-in, the net user command, and so on) have the following default property values in the “4720: A user account was created” event:

• Primary Group ID: 513
• New Uac Value: 0x15, which means:
  • Account Disabled
  • ‘Password Not Required’ - Enabled
  • ‘Normal Account’ - Enabled

Check that all “4720: A user account was created” events have these properties set to their default values using the following snippets. This method might help you to detect local user account creation actions that were performed using nondefault system tools/applications.

The XPath filter for Primary Group ID != 513 is:

*[System[band(Keywords,9007199254740992) and (EventID=4720)]] and 
*[EventData[Data[@Name='PrimaryGroupID'] !='513']]

The XPath filter for NewUacValue != 0x15 is:

*[System[band(Keywords,9007199254740992) and (EventID=4720)]] and 
*[EventData[Data[@Name='NewUacValue'] !='0x15']]

You can verify that all newly created local user accounts follow a specific naming convention. Check the New Account: Account Name field value in the “4720: A user account was created” event for naming convention rules.

Successful Local User Account Deletion

To better understand the local user account deletion process, look at the events that appear in the Windows security event log when a local account is deleted using the standard Computer Management snap-in.

The event shown in Listing 5-19 exists only on Windows Server 2016 and Windows 10.

It is mostly for informational purposes and informs you that account Administrator (Subject) enumerated the group membership of the NewUser account (User) using C:WindowsSystem32mmc.exe.

Listing 5-20 shows an important access request event for the DOMAINSBuiltinAliases0000221 SAM_ALIAS SAM object (you already know that it is the built-in local Users group) for the RemoveMember access permission.

This user account should be removed from all groups when it's deleted. This handle request action for one of the groups the deleted user belongs to is a first step in the user deletion process. In this example the deleted user is a member of only one local security group: Users.

The event shown in Listing 5-21 informs you that the account with SID S-1-5-21-1913345275-1711810662-261465553-1002 was successfully removed from the BuiltinUsers local group.

The handle 0x184580fd910, which was previously opened to remove the deleted user from the “Users” local security group, was closed (Listing 5-22).

As you saw in the “Successful Local User Creation” section earlier in this chapter, during account creation, the account is added to the None global security group. When an account is deleted, it also needs to be removed from this None global security group (Listing 5-23).

Listing 5-24 is a handle request for DELETE access for the local SAM_USER account DOMAINSAccountUsers00003EA object (NewUser) in the SAM database. This handle will be used later for an account deletion operation.

Listing 5-25 is the main security event, which informs you about successful user account deletion. In this event you can see who (Subject) deleted which (Target Account) account. There is no information about how or using which tool the account was deleted in this event.

Event 4726 is the most important event for account deletion, which shows you the fact that account was successfully deleted.

Because a user account object in the SAM database was deleted, there is also a separate 4660 event (Listing 5-26) that informs you about changes in the SAM database.

There is no detailed information about the object that was deleted, but it is possible to find a “4656: A handle to an object was requested” event with the same handle ID (0x184580fc5d0) and get the details. You already saw the corresponding 4656 event in Listing 5-24.

Listing 5-27 shows that the handle 0x184580fc5d0, which was previously opened to delete the NewUser account, was closed.

Here are the answers to the questions posed at the beginning of this section about a successful account deletion operation (see Listing 5-25: Event ID 4726: A user account was deleted):

• Who deleted the user account?

  The answer is in the Subject section.

• When was the user account deleted?

  Event “4726: A user account was deleted” provides the event creation time.

• Which account was deleted?

  The answer is in the Target Account section.

• How was this account deleted?

  There is no easy way to detect how exactly the account was deleted, using which tools, scripts, applications, or other methods. A general recommendation here is to inspect all events prior to the account deletion event and try to find any information about methods being used to delete the account. For example, you may search for the “4688: A new process has been created” event to find the name of application that was run right before the account was deleted.

  Sometimes you may find some useful events in the “Application” event log at the same time when the user account was deleted.

Unsuccessful Local User Account Deletion - Access Denied

This section provides information about an event that is triggered when the NewUser account tries to delete the amirosh user account, but fails due to insufficient access rights.

An unsuccessful local user account deletion operation using the standard Computer Management snap-in leaves only the two events shown in Listings 5-28 and 5-29 in the Windows security event log.

The event in Listing 5-28 is triggered no matter which method is used to delete the account. It informs you that amirosh's account group membership was enumerated.

Listing 5-29 shows an unsuccessful attempt to open a handle to the DOMAINSAccountUsers00003EC SAM_USER SAM database object for DELETE access. In this event you can see an access to the object (Object) that was requested and by which account (Subject).

The answers to initial questions about this account deletion operation are (see Listing 5-29: Event ID 4656: A handle to an object was requested):

• Who tried to delete the user account?

  The answer is in the Subject section.

• When was the attempt made?

  Event “4656: A handle to an object was requested” provides the event creation time.

• The name of the target account?

  The answer is in the Object section.

• How was this account deleted?

  There is no information about this in event 4656. You should use the methods described in the “Successful Local User Account Deletion” section earlier in this chapter to find this information.

Unsuccessful Local User Account Deletion - Other

Sometimes, a user account has all required permissions to delete another local user account, but fails for some other reasons.

One example of such a scenario is when an account with sufficient permissions tries to delete a built-in system account, such as the built-in local Administrator account, and gets a delete operation error, because system accounts cannot be deleted using standard Windows account management tools.

In this case the events in Listings 5-30 and 5-31 will be displayed in the Windows security event log.

The Administrator (Subject) account successfully obtained a handle with DELETE access to the DOMAINSAccountUsers00001F4 SAM_USER SAM object, which is a built-in local Administrator account SAM object (0x1F4 = 500).

Right after the “4656: A handle to an object was requested” event you will see “4658: The handle to an object was closed” in which the just-opened handle to the DOMAINSAccountUsers00001F4 SAM_USER SAM object was closed.

Account deletion failure occurs at the application level and is not recorded in the Windows security event log. Unfortunately, built-in Windows applications, such as the net user command or the Computer Management snap-in, have no dedicated event logs to verify why an account deletion operation failed.

There is no information in the security event log explaining why a target account was not deleted, and you will not find a “4726: A user account was deleted” event in the security event log if the target account was not successfully deleted when error occurs on the application level.

Monitoring Scenarios: Local User Account Deletion

Useful events to monitor for successful and unsuccessful local user account deletion are shown in Table 5-7.

All successful local user account deletion operations should be monitored, especially on high-value and critical hosts. The main reason why these operations are important is that there are not many local user account delete operations performed during a machine's lifecycle. Such operations might be an indicator of someone trying to:

• Remove all signs of compromise after the machine is compromised
• Delete some important accounts to facilitate performing denial of service attacks
• Hide or correct configuration errors or mistakes

This is not an exhaustive list. There can be other reasons for account deletion operations that are dependent on a variety of circumstances.

You should monitor for “4726: A user account was deleted” Audit Success events.

All unsuccessful local user account “access denied” deletion attempts must be monitored on all categories of hosts. All attempts to delete a local user account without having required permissions might be an indicator of malware activity or other suspicious activity. There is also a chance that someone forgets to run an application using administrative privileges, that is, with a nonelevated token, and the operation fails. This should be considered a false positive alert.

You should monitor for “4656: A handle to an object was requested” Audit Failure events where the Accesses field has a %%1537 (DELETE) access type and the Object Type field equals SAM_USER.

Monitor for this using the following XPath filter:

*[System[band(Keywords,4503599627370496) and (EventID=4656)]] and 
*[EventData[Data[@Name='ObjectType'] and (Data='SAM_USER')]] and 
*[EventData[Data[@Name='AccessList'] 
='%%1537
				']]

It is recommended that you have a list of accounts (domain and local) that are allowed to delete local user accounts. If you have such a list, you should compare every “4726: A user account was deleted” event's Subject fields with this list.

Refer to the examples for this monitoring recommendation in the “Monitoring Scenarios: Local User Account Creation” section earlier in this chapter.

It is recommended that you have a list of critical local user accounts that should never be deleted—for example, service accounts or accounts for scheduled tasks. Monitor all “4726: A user account was deleted” events where the Target Account section fields contain any of your critical local account names or SIDs.

Local User Account Unlock

Following are two typical scenarios for user account unlock operations:

• Manual unlock
• Automatic unlock after the number of minutes, defined in the “Account lockout duration” local policy setting, passed

A manual local user account unlock operation will trigger the events shown in Listings 5-50 through 5-53 in the Windows security event log.

The event in Listing 5-50 shows you that someone (Subject) requested a handle for the SAM account DOMAINSAccountUsers00003EC (local NewUser account) object with multiple access rights, and one of the access rights requested is WriteAccount.

Listing 5-51 shows that Subject account unlocked Target Account.

The “A user account was changed” event shown in Listing 5-52 is generated because the account has changed (become unlocked), but, unfortunately, there is no information about this change in the event itself.

No events are generated in Windows security event log for automatic local user account unlocks.