Another script in our arsenal similar to the Kerberoasting
attack on the Services account is a honeypot for bad
credentials called a honey cred.
This script comes from the WiredPulse GitHub,
but again,
I have provided a forked update version in this course
exercise file that works on PowerShell 7.
Fernando Tomlinson, who provided the original script,
has a write‑up on the Cyber Fibers site that talks through the
configuration setting and options you can set and what they mean,
because the script actually feels secure and blocks accounts it
feels are brute forcing the honey credentials,
so it's important that you take a hard look at the configurations
and make sure they meet your organization's needs.
You don't want to accidentally block the wrong accounts.
To mitigate this,
you are going to create a fake user account that will be your honey cred.
In this instance, I named it hcadmin just to have it stand out.
It is up to you what you want to name this.
It also doesn't matter the password set,
because you should never use this account,
so just mash on that keyboard.
Once you create this, you can pepper this account into things like scripts,
the unattended.xml file that is left behind after images,
and other various interesting files that may catch
the attention of the attacker.
Be sure to reference it as a domain admin.
That will really get their attention.
The hacker will likely try it once, and if that doesn't work,
will drop it into a brute‑forcing script to crack it.
This is where the script fires off.
So first, a couple updates I made in the fork version.
Let me open the script here.
The first change from the script found on the GitHub site is on line 17.
I added line 17,
as the Microsoft.PowerShell.Management module is
needed for the new event cmdlet, which is only available in Windows PowerShell.
You will find these down at the bottom here on lines 439 and 466,
which writes an event stating to block the IP useful for SIEM or an
MDR service that alerts you that a block took place.
One of the most important changes is adding the criteria to limit results to
the hcadmin assigned to the data parameter here on line 449.
This is the honey cred account and will only block IPs of
systems brute forcing the honey cred.
You do have the option to comment the line out and uncomment line 448 instead,
which will block any system that produces a failed
login three times in a 30 second, regardless of the user.
So just one last item of note.
Down at the bottom here,
I commented out lines 455 and 482 because I wasn't using any
whitelisting for the demo here and it was just throwing me a
bunch of errors at runtime, so I just commented them out to ignore it.
If you want whitelisting turned back on,
you can uncomment these two lines back and be sure to set up the whitelisting.
So for this demo, I'm running on the Windows Desktop VM.
I'm also going to bring up a few screens to follow
along with the actions of the script.
First, I'm going to open both the Firewall Inbound Rules,
then also the Event Viewer to the Security events,
and filter on event 4625.
Now that everything is set up in PowerShell 7,
I have already navigated to the scripts\Fail2Ban folder,
and I'm ready to call the script.
There are no parameters, so it is a simple .\Invoke‑Fail2Ban.ps1.
Now give it a second, if it doesn't pop up immediately,
maybe hit the Enter key once to give it a kick to go.
Okay, once ready, from my host machine,
I'm going to attempt to rdp into the VM desktop.
So now that the rdp made a connection,
let me try logging in a few times unsuccessfully,
and if everything works, in a second here,
I should see the script fire that it blocked the IP
address of the attempted brute force.
I can also see this in the firewall rules that I've been blocked.
And when I try to ping the host,
I am no longer able to see the endpoint. Success!