Recently I’ve been seeing a new-ish method for honeypot deployment and intruder detection on local networks that I thought was pretty neat. It’s a method that uses tools that are already at a network admins disposal, doesn’t require any fancy tools, and teaches people a little more about working with AD in a way that makes their logs provide more specific threat intelligence.
The technique has to deal specifically with admin accounts on your Domain Controller. The idea is that once your network is breached, that attacker is going to do some kind of recon within your network. Obviously the DC is going to get looked at, which is where you’re going to have this low hanging fruit that looks much more like poor administration than a honey pot.
Specifically, an account is created that is a Domain Admin and has horrible password security. Either have some terrible password set or even put the password in the description (which plenty of people are guilty of actually doing). The key to this method though is the login hours are essentially set to never; so this account will never be authorized to login. So any attempts made to login via this account with both fail and also trigger a logged event that is by it’s very nature probably malicious.
Creating The Account
1) Create a new Domain Administrator account
2) Have a horrible password set (Bonus: Leave it in the description.)
3) Go to the Account tab and select Logon Hours and set Logon Denied to 24 hours/7 days a week.
Setting Group Policy
Verify the following Group Policy options are set…
- Edit the Default Policy.
- Navigate to Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Advanced Audit Policy Configuration -> Audit Policies -> Account Logon -> Audit Kerberos Authentication Services and set to audit Failure events
3) Update group policy on your clients by running gpupdate /force
Utilizing Event Viewer
This technique requireed a bit of homework in terms of using Event Viewer and how this gets logged. Typically, failed login events are logged as Event ID 4625; rather, this event is logged under 4768 Kerberos Authentication Ticket Was Requested. The ticket request has plenty of reasons to fail, but in this case it’s the logon hours that’s triggering it. Below is an XML example of the event:
So there it is! Setup your monitoring of these events within whatever apparatus your organization has setup. However you slice it though, the idea of cleverly using assets that are already at an administrators disposal in a way that has an easy and real impact on your situational awareness, to me, is a huge win. Enjoy!