Friday, January 29, 2010

What Bob Did. What Alice Saw - Part 2

This is the 2nd part of the story which is all about Bob the evil hacker and Alice the overworked Sys Admin.

In the previous post Bob was using some of his command line Kung Fu to carefully analyse the Walliford Active Directory before creating some very inconspicuous admin and user accounts. Bob being the careful kind of guy that he is also attempted to cover his tracks by deleting the logs on the victim server.

In this post I'll be looking at how Alice might have spotted all Bobs actions if she was following 2 best practices:

1) Analysing the logs.
2) Logging to another server.


Part 2 - What Alice Saw

Alice turns up at the office a few minutes early as usual. She likes to get in, grab her coffee and then start on her daily tasks. First she checks her emails for anything urgent, then the helpdesk, and finally she gets to her server logs. The information that windows logs can be pretty overwhelming, luckily Alice has a few filters that she can apply to look for key events.

What Alice ideally wants to know is what accounts have been added or deleted and what groups have been modified. She keeps a list of the events that she needs to watch out for to spot these types of activities. Other interesting events that Alice keeps a close eye on are those for people logging into servers, bad passwords and account lockouts.


Her daily log analysis isn't her favorite job, but it's an important one. She would love to get her boss to pay for a tool to do the log correlation but unfortunately he doesn't see it as an important enough task. As soon as Alice finds the time and starts looking through the logs she starts to worry. She see's a whole bunch of login failures from earlier that morning.



On closer inspection Alice sees some very strange looking account names like metasploit.



After those entries Alice sees an event 624 Which indicates a new account has been created for a user called Bob Ball.



Alice checks the helpdesk to see if a call was raised for a new employee called Bobby Ball, it wasn't.

Next Alice can see an event 632 that shows that the new account has been added to the HR group.



She makes a quick call to HR and finds that they know nothing of this mysterious account. Alice disables the account until she can get to the bottom of what's going on.

Just as Alice finds a few minutes to spare she goes back to her logs and then her phone rings. As she's summoned to a project meeting she thinks that the logs will have to wait. Unfortunately the meeting takes up the rest of her day.

The next day Alice gets to the office extra early so she can catch up with her tasks. However, on connecting to her server she finds the logs are almost completely empty. All the entries from the previous day had been cleared. The oldest event is a event 517 which shows that the logs have been cleared.



As Alice sits back and thinks about things she convinced that some evil hacker has tried to break into her network, she counts her lucky stars that she spotted the hackers account and disabled it quickly before any damage was done.

The End



Okay, I know my story is pretty crap but I bring all this log stuff up because had recently had a conversation with someone who didn't realise just how much useful information was contained in the Windows security event logs. This post is just really to highlight 2 things. Get your logs off the server, there are plenty of great tools to do that, unfortunately they all cot a bit. Secondly, build time into your day to analyse the logs. Find out the important events and find a way to filter the logs to spot when something is wrong.

If you want to learn more about the Windows Event Logs check out Randy Franklin Smiths site Ulitimate Windows Security. His site is without doubt the best resource for learning about the windows security logs I have ever found, and his webcasts are pretty amazing.

5 comments:

S├ębastien Duquette said...

You can replicate logs without paying. On Linux, syslog-ng is the way to go. On Windows, you can use SNARE to send the logs to a syslog server, however this option does not support encryption so you'll need to use IPSEC or something similar.

SynJunkie said...

Many thanks for that tip Sebastien. I had never heard of SNARE so I'll be sure to check it out.

Cheers

Syn

Ramki B Ramakrishan said...

Snare is a awesome tool; also you can consider Splunk for searching...

Robert said...

I use Event comb, it's free with the Windows Server 2003 resource kit tools. I have it read from a txt file of the systems on my domain. I can look for specific events on all my systems.

SynJunkie said...

Ramki - Snare does look pretty good but isn't the Snare server a paid for program and only the agents are free?

Robert - I'm with you on Eventcomb, i love that tool. If it was only faster across some pretty crappy WAN links. In a smaller network it's a pretty decent tool. Maybe LogParser with some decent Logparser Fu is the way to go in a very distributed network?