Question: How often does your Local Group membership for Servers change?
Question: How often does a local user account get created on a Server?
Answer: Very Rare to never in most enterprise organizations
For that reason these two events are prime SIEM Alert candidates for BlueTeams that offer a low false positive rate paired with a higher risk and potential impact probability.
Local Group Membership – Windows Event ID: 4732
When either a local server user or domain user account is added to any local server group there is a Windows Security event ID 4732 created. Why is this something to monitor? builtin server groups offer additional permissions to perform actions on the server. From the lower end “Remote Desktop Users” which allows users to RDP on to the server, to the high end “Administrators” group with Root access to the system, there are 25 default groups that grant some specific level of user privilege on servers.
The example above is a stock MS image. To Break it down is as follows:
Subject: (source of change)
Security ID: SID of the account making the change
Account Name: Display name
Member: (user affected)
Server Name: Local Server
User: Display name of user added to group
Group: (group info)
Security ID: SID of the group modified
Group Name: Local group display name user was added to
Of course we want notifications for the heavy hitters that have higher server permissions, “Administrators”, “Power Users” and “Print Operators”, but why not just alert on them all since “in theory” none should change very often, if ever. Setting an alert on the overall Security Event ID 4732 will give you notifications for group additions to any of the following builtin Server Local Groups.
*** Note: Windows Event ID 4733 is Group Removal which may come in handy for the same reasons above.
Local User Account Creation – Windows Event ID 4720
There are many advantages to using Active Directory domain user accounts over local server user accounts.
– AD domain user accounts must meet your Default Domain Password Policy requirments (or OU specific password policy if its unique)
– Increased ability to harden user accounts by setting specific restrictions
– Visibility – Authentications take place on your Domain Controllers so inherently logs are easily available to query
– Easier Auditing with one main source of record (AD). Instead of a remote WMI or PowerShell query of 50 servers to check for user accounts, either get-aduser or open the AD mmc and they’re all there
A short list among many reasons. Stay away from local user accounts if at all possible
*** Note: Disable RDP for Managed Service Accounts, there is zero reason for an Admin to ever have to log in as a Managed Service Account. Using “Run as” or “Run as a different user” will work just fine without adding unneeded risk to your network
Again another MS stock photo
Subject: (source of change)
Security ID: SID of the user who made change
Account Name: Display name
New Account: (created account info)
Security ID: SID of the new user account
Account Name: Display name
Attributes: (all attributes set on account)
Any local account created needs to be investigated. It could be a server administrator creating the account for a service to run, innocent enough but take the time to steer them away from local accounts and set up a proper domain account in its place.
Some other Windows Event IDs to pay attention monitor:
4722: A User account was enabled
4724: An attempt was made to reset an accounts password
4738: A user account was changed
Know your network and watch for anomalies
1/11/2021 – Weister Creek InfoSec
WEISTER CREEK 