A good real world example rule is based off the rule template Critical Account Logon Failure. This rule is great at catching someone trying to guess user passwords without locking accounts.
For instance PEN testers/hackers will have a script that will attempt a logon twice using a common password or variation and then move to the next IP on the network to keep from locking accounts. Commonly they will try hitting the default local administrator account “administrator”. This account by default is in the user defined group, but if you rename that account on your PC’s/servers you should add that account to the user defined group.
The default rule is built as
- UserLogonFailure.DestinationAccount contains User Defined Group(Admin Accounts)
By default the User defined group Admin Accounts contains “Root” and “Administrator”
If you rename that account on your PC’s/servers you should add that account to the user defined group.
You should also add any none Active Directory based privileged account to the User Defined group
I then like to expand the rule to cover my privileged Active Directory accounts
UserLogonFailure.DestinationAccount contains UDG(Admin Accounts)
OR
UserLogonFailure.DestinationAccount contains DirectoryService Group(Enterprise Admins)
OR
UserLogonFailure.DestinationAccount contains DirectoryService Group(Domain Admins)
OR
UserLogonFailure.DestinationAccount contains DirectoryService Group(Schema Admins)
Etc…. for any other Active Directory user group that has privileges
The rule by default creates an incident alert, which will create a record in the incident report. If you are looking at your incident report daily a scripted attack such as described above will be very obvious.
If you change the action to something else like creating an email, you can easily watch the scripted attack move through a network. This is great fun when you can tell your Pen Tester exactly where they are at, on your network.
