Finding Failed Logon Attempts With Log2Timeline While You’re Searching For Your FTK Dongle

I have recently been thinking through ideas for some quick and dirty initial processes one can do at the start of an investigation.

This would typically be whilst you’re doing one of the following:

1. Waiting on full disk (including VSS) log2timeline processing to complete.
2. Waiting on Axiom to run the ‘build connections’ module because you forgot to enable the option prior to the initial processing phase.
3. Waiting on EnCase 8.07 to finish processing, although it’s been sitting at 100% for the last 2 hours.
4. Trying to figure out where you last saw your FTK dongle.

This brings us to a New Blog Series:

The aim of this post (and hopefully this series) is to play around with things you can do at the beginning of an investigation, while for example, waiting for processing to complete. Specifically things that could be of value to know at the beginning of an investigation.

 

And, that brings us to today’s post:

Finding failed logon events.

Identifying failed logon events in the Security event log of a system could mean a couple of things:

1. Someone is attempting to brute force an account.
2. <add a list of more possible reasons here>

The above extensive list provides good reason why it could be of value to have a quick squiz through a system’s Security Event logs for failed logon attempts.

As such, I wanted to know the following relating to failed logon events:

• How many (if any) failed logon attempts were recorded in the system’s security event log.
• Which accounts were attempted to log on with the most, as well as the logon types.
• What were the top failed source IP addresses recorded.
• What date(s) did the most failed logon attempts occur on.

Side note: The sample data I used for this post came from the image provided by Dave and Matt (The Forensic Lunch) as part of the MUS CTF. More about the MUS CTF and the image, check here.

To answer these questions, here’s one quick and dirty way:

Step 1:

Process the Security event log with Log2Timeline (this took just over a minute to process 33,000 events from Security.evtx) :

$ log2timeline.py mus.sec.evtx.l2t securityevt/

 

Step 2:

Run psort across the output using the l2tcsv  format (this took 30 seconds to run):

$ psort.py -o l2tcsv -w mus.sec.evtx.csv mus.sec.evtx.l2t

 

Step 3: Grep & Awk

This is where the fun starts. Because it is expected that the output from running log2timeline / psort on a Security event log should provide the same output structure each time, the same commands should work. (I tested this with Security Event logs from Server 2012, Windows 7 and Windows 10 and seems to work on all the different outputs).

This may appear ugly, but it works.

Total Failed Logons: grep “EventID>4625” mus.sec.evtx.csv | wc -l

Top Failed Accounts: grep “EventID>4625″ mus.sec.evtx.csv | awk -F”xml_string: ” ‘{print $2}’ | awk -F”TargetUserName\”>” ‘{print $2}’ | awk -F”<” ‘{print $1}’ | sort | uniq -c | sort -n -r | head

Top Failed Logon Accounts: grep “EventID>4625″ mus.sec.evtx.csv | awk -F”xml_string: ” ‘{print $2}’ | awk -F”LogonType\”>” ‘{print $2}’ | awk -F”<” ‘{print $1}’ | sort | uniq -c | sort -n -r | head

Top Failed IP Address Origins:
grep “EventID>4625″ mus.sec.evtx.csv | awk -F”xml_string: ” ‘{print $2}’ | awk -F”IpAddress\”>” ‘{print $2}’ | awk -F”<” ‘{print $1}’ | sort | uniq -c | sort -n -r | head

Top Dates With Failed Logons: grep “EventID>4625″ mus.sec.evtx.csv | awk -F”xml_string: ” ‘{print $2}’ | awk -F”TimeCreated SystemTime=\”” ‘{print $2}’ | awk -F”T” ‘{print $1}’ | sort | uniq -c | sort -n -r | head

 

And the end result:

Success.

We can now see that there were 612 failed Type 3 logon attempts, all on May 5th 2018. It also shows us that the Administrator account was most often attempted to log in with, as well as the top IP addresses where the logon attempts came from.

All this in less that 5 minutes.