Internal Honey Pots/Honey Accounts

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.)AD_create

3) Go to the Account tab and select Logon Hours and set Logon Denied to 24 hours/7 days a week. Time_restriction.png

Setting Group Policy

Verify the following Group Policy options are set…

  1. Edit the Default Policy.
  2. 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 eventsDefault_DomainDefault_Domain2

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:

XML

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!

-DarkHorseSec

 

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s