We did a bunch of account and service creations to trick an
attacker, and from the attacker's perspective,
if there is an AD account in the domain admins group with a password
that is 10 years old, I'm pretty sure we caught their attention. But
to avoid detection, there are some key user attributes they will
want to investigate first.
So it is on us to stay on top of those to tell the full story.
An attacker will likely want to check the following to
avoid stepping into your honeypot.
When was the user account created? Accounts created in
the past year or so may be suspect.
When did the account last log in?
If the account has not logged on or hasn't logged on since the creation date,
this may be a honeypot account. When was the password last changed? If
the password has not changed since the creation date,
this may be suspect.
Finally, if it is an admin account,
is there a correlated user account that is active?
If there's just an admin account called
JSmith_admin, but there is no user account,
JSmith, and all other AD admin accounts can now be correlated in this manner,
this may be a honeypot account. With all that said, this is where the PowerShell
course gets a little tricky, as these are not all attributes that can be
automated directly with a script, so they will need to be updated with things
like scheduled tasks and other methods.
For example, the account creation date,
there is no script to set the creation date back, so it requires you to
manually push the clock back to the server, 5‑10 years,
create the account, and then pull it back forward again.
Same goes for the non‑admin correlation, you just
have to create two honey accounts.
But what I can affect with PowerShell, sort of, is the last login date.
What we can do is run a scheduled task that runs the following PowerShell script
to set the credentials of the honey account to auto login in the registry. Then,
another scheduled task that restarts the server.
If we have more than one honeycred, we can do this across multiple tasks and
scripts. Schedule the reset times so many minutes apart, and obviously, this
will be on a server that is not production impacting. To visualize this, I have
my host with Virtualbox set up. I then have a Windows virtual machine inside. On
that virtual machine, I have a scheduled task that calls a script. That script
edits a registry record.
I then have another scheduled test that restarts the machine. By
restarting the machine and having the autol ogin set, I'm going
to log in as that honeycred account.
Now for security purposes, you want to script the server to
turn off when this work is done so the scripts are not
accessible since they contain passwords.
If you set this up on a virtual machine,
say Virtualbox,
you can create a couple of tasks on the host machine that will start the server
up every morning at the specific time just before the scripts are scheduled to
run, and shut down the server after the set time so the scripts are not exposed.
Now, the VBoxManage function allows you to set a scheduled task to start and
stop specific VMs on request.
If you're not sure the name or the ID of the VM,
you can run the VBoxManage list, then vms job, to list out the options.
The startvm will allow you to start the VM at the beginning of the day.
Remember, the last registry setting to auto login will be set,
allowing the machine to log in automatically.
The script inside the VM will then kick off on a schedule to cycle
through logging in as different users, changing the dates in the AD
profile, then, after a certain amount of time, the controlvm function
will be called with the shutdown parameter to nicely take the server
offline again at the end.
Now to visualize all this, the only part that I really added on
was a scheduled task inside the host that calls the scripts to
start and stop the Virtualbox.
Now here's a script for automating the password
change to the honeycred accounts.
You can group the code into one script to update multiple passwords,
but this will need to be ran on a server with the AD PowerShell add‑on. I
would recommend scheduling this to run once a year, and if you can't run all
these scripts on a server that can be started daily,
maybe adding a snippet of code to alert you when it runs with the new password,
so the previous scripts can be updated accordingly.