Okay, now let's look at a more targeted,
less noisy attack called Kerberoasting that will have very few false positives
if executed correctly. Down the attack path, if the attacker can get their
hooks into some misconfigurations service accounts,
they will try to elevate their privilege.
One way to do this is with a Kerberoasting attack.
Amanda Berlin and the kind folks at Blumira have released this
script to their GitHub account that allows you to set up a
honeypot to catch this activity.
I have also made the script available in the course materials. You will need to
set this up with the administrator if you do not have access already, and I have
only tried this in PowerShell 7 with admin rights. Now unlike the port listener,
this script requires some setup and a single run of the script, and the rest is
handled by the SIEM or logging tool to monitor exploit of the specific token
account created. So, the setup first. The PowerShell script should be executed
by a user account with privileges for creating Active Directory accounts and
SPNs, a SIEM that will generate alerts related to matching on the following,
event ID 4769 with the encryption and ticket options seen here.
But to avoid the noise, because this is a very common event, you want
to capture in the log the SPN name and only alert when it matches a
honeytoken account. To make all this work,
you need to turn on auditing of the Kerberos Service Ticket
Operations in Group Policy. It needs to be set to Success and
Failure audit events. By default, as you see here,
it is set to Not Configured. Now once that is set up,
you're ready to kick off the script.
It is not a complicated script.
So first, I'm going to walk you through how to manually perform the steps in it.
First, you want to create an account to be used. In this example, I created
the backupexec standard user. I then, in step 2, add the SPN to the account
with the command setspn ‑a, the service backupsvc on the server
Win2019Server, then assign it to the account backupexec. Once I do that, you
will see it registering, and at which time I run the same SPN account, but
this time with a ‑Q so I can query the SPNs and find that my backupexec
account has been assigned.
Now once this is verified,
you are good to go; otherwise, it is just a matter of running the PowerShell
script, which will generate a random account with preauthentication for the
purpose of detecting the AS‑REP roasting, which you see, once I do that, I'm
given these names with a random string on the end.
If I now open the Users of the domain,
I will see the accounts I just created. I have more than you likely as
I've ran this a few times without clearing the users, but you probably
only want to have one or two in here as not to draw attention that these
may be potential honeypots. From here, just like with the ports,
pull the logs looking for the 4769 event with that user
just created. Once an alert is fired off,
it is an indication of a Kerberoasting attack is underway.