[Autogenerated] The it team at Bethany's Pie shop has been
noticing an uptick in security alerts related to failed
login attempts on their domain.
Specifically,
they're concerned that a user account might be
targeted for a route force account.
You're tasked with auditing failed login events in the
security log if the suspicions are correct.
So let's do some sleuthing.
Let's dive in and see how we can leverage PowerShell to audit those
security logs and protect users from Bethany's Pie Shop.
We'll protect those users from brute force password
attacks with this kind of log investigation.
I'm connected to my domain controller here directly via
PowerShell noting as a domain admin.
So to start off,
let's first replicate a login attempt just to make sure we have one here.
I'm just trying to connect to a non-existent, share it with the username.
A fake user that does not exist.
Oh, darn failed login attempt.
Let's now see if that attempt was recorded.
I've already enabled auditing on the domain controller.
All failed login attempts are recorded on the domain
controller with an id of 4625.
We can use get wint to do that and filter on the
security log for all 4625 event I DS.
And here I'm only selecting the 1st 10 because there might be a bunch.
You can see that there are some accounts failing to authenticate,
but that's a lot more failures than the one I just produced.
But we need to dig deeper to confirm if any specific count is being targeted.
First, let's inspect one of the events to see what it looks like to do that.
I have to use select object and I want to view the
first one and view all the properties.
You can see that there's a ton of information logged in a single event.
If I scroll up here, you'll see the message property in the message property.
You'll see the accounting that was denied the reason,
the failure occurred and where the denial came from.
You'll see that the account of a minister.
This is actually on the internet because it's just a demov
M and it looks like someone is actually trying to brute
force their way in as we speak.
Let's narrow down this output to only show the pertinent details.
We're after this will require a bit of text parsing.
Since the typical info we want is Barry,
I just pasted this code snippet in here for now.
And this is just using a single event to test this code.
You can see that I'm piping,
get wint to select the object in the first line and only
selecting the first object return,
get onet returns that message and property property
that contain the information.
We're after the failed login message is hidden in the message
property on the first line of a multi line string.
So we must split that message string on a new line
and then choose the first one.
The account name and source network address are
stored in the property's property.
Luckily,
the property's property is an array so we can pick up the index for
both of those values and for a failure reason.
Well, it's safe to say you have to do some ninja moves to get this.
The code is splitting the message text into an array again and then
finds a line that contains the failure reason,
label and then removes that label and what's left is the actual reason.
So let's run this code and see what it comes back with.
Great.
It's working.
You can see that we have the administrator,
the user account failed login message, the reason and the source network address.
It got all four elements I was looking for,
but there's no way I'm going to just copy and paste this
text into my console every time I want to see this info and
it's just set up for one event.
Anyway, let's create a script from it.
I'm down directly on the server and I've created a script
from that refactor code that we just went over instead of
only processing a single event here.
I'm using a for each loop to process each event.
Found it then creates a PS custom object and provides
labels to each of the values we're after.
So let's now run this and see what happens since there may be a lot of failures.
I'll only look at the top three events and there we go,
we have the message account, failure, message and source IP address.
It will pull all of these for all of the events.
Now, so now that you have a script to pull only the necessary information,
we can then filter on this just like any other
PowerShell object using where object.
So maybe I just want all of the failed attempts for the username of admin.
And now you can see it's starting to return some information.
There's no need to figure out how to parse that message property anymore.
So now you have a script to audit the old login attempts
you can build from and make better.