Event Log Managment

Logs .. Logs and More Logs

Logging, Logging

Here lately we’ve been hearing a lot about Stuxnet and Duqu.  Well this week is no different, but there is some insight into how one of these could have been slowed down if not prevented.  In an article released on Nov 30, 2011 at eWeek.com, Duqu Attackers Wiped All Linux CandC Servers to Cover Tracks, there are some good insights even though it’s almost just a side note.  The article mainly discusses what the Duqu attackers did to help cover their tracks.  The part of the article that caught my eye was the last paragraph.

Even though there was a possibility of a zero-day, the researchers thought it was more likely that the servers’ root passwords were brute-forced, based on a log of a user attempting to log in as root multiple times over an 8-minute period from an IP address in Singapore before finally succeeding.

It all comes down to logging and then doing something with those logs.  Having a solution (www.logrhythm.com) that can help point out these types of items is critical.  Just to have logging turned on gets you nothing, you need to do something with these logs.  Having a solution in place and watching for anomalies like this could have helped to slow Duqu down.  Logs won’t stop the attackers but if we are being proactive and watching (with the correct solution) we would at least slow them down some.

As this also shows that attackers aren’t worried about people logging their activities because they know most organizations/admins aren’t doing anything with the logs until well after the fact.

One of the things that you need to be asking your SIEM/Log Management provider is how would they have picked up on something like this?  Can it be correlated/detected that it was coming from the same IP address and repeated attempts?  Most SIEM/Log Management vendors will tell you “sure we can do that”.  Well my next question would be: What if this was across multiple Operating Systems, could you detect it then?  Now for my shameless plug, with LogRhythm the answer is yes.  Some vendors expect you to be a subject matter expert across all Operating Systems, network devices and applications.  With LogRhythm you don’t need to be, our normalization handles that for you.  We can take being proactive to the next level with advanced correlation and SmartRemediation.

Advertisements

December 2, 2011 Posted by | Audting, Event Log, Hacking, Log Management, Uncategorized | , , , , , | Leave a comment

Inside and Outside Hack Attempts

Over the last several years I have conducted quite a few webinars with Randy F. Smith on a variety of topics that relate to Windows Audit Policies and Log Management.  Two of these truly drive home the point about why you need to be looking at your logs (not just Windows but all sources; *NIX and Network Devices as well).  The first of these was conducted on Jan 20, 2009 entitled “Anatomy of a Hack: Tracking an Intruder with Security Logs” and most recently on Feb 4, 2010 entitled “Insider Gone Bad: Tracking Their Steps and Building Your Case with the Security Log “.

March 3, 2010 Posted by | Audit Policy, Audting, Event Log, Hacking, Log Management | , , , , , , , | Leave a comment

Monitoring Network Shares

I had a discussion today with a customer who was trying to monitor when their users tried to access network shares and failed.  He had all the correct accesses setup, removed “Everyone” and gave access to only those groups that needed access.  He even turned on the correct Object Access auditing, but his problem was that when anyone outside the correct groups tried to access the folder they got the message that ”  \\<server name>\<share> was not accessable.  You might not have permission … ” but the Audit Failure 560 events (his server is W2k3) were not being generated. 

This is something that I’ve seen quite often, the issue comes from the  Share Permissions that have been set.  Because he removed the Everyone group from the Share Permission the Audit Failure events for 560 (Object Access Auditing) were not being generated. 

So if you need to be able to track when unauthorized users are attempting to access shares for which they do not have access, leave the Everyone group with Read permission under the Share Permissions tab on the folder (as seen in the screen shot below). 

Share Permission

 

Now on the Security tab make sure that you turn on the correct Object Access auditing  (stay away from FULL CONTROL; you will flood yourself with noise events).  Now since in this example we want to track when people fail to open the network share, goto the Security tab, then click on the Advanced button, then the Auditing tab.  Click the add button and set this auditing for Everyone and check Traverse Folder and List Folder boxes under the Failed column.

Audit Settings

Now when users attempt to open this network share event id 560 Audit Failure event will be generated telling you who, what, when.  Now the from where is not going to be listed in the 560 event but can be tracked down by looking at the Client Logon ID hex code listed in the event description.

Looking at the Object Name will tell you what file/folder the user was trying to access.  If the Image File Name is blank then you know they were attempting to access the resource from the network, if this field has a value then they used the program listed to access the resource locally.  Client User Name will tell you who the user was if they accessed remotely (if they are accessesing locally then look at the Primary User Name).  The Client Logon ID (or Primary Logon ID) will help you link back to the logon event (528 or 540 in the case of W2k3 and older OS).  Looking at the Accesses list we can see the ReadData/ListDirectory which is what we are auditing for.

560 Failure

May 20, 2009 Posted by | Audting, Event Log, Object Access | , , , , | Leave a comment

Security Log Resource

This week has been a busy one for me.  I have had several web training sessions and 2 onsite training sessions with customers this week.  A question came up during one of onsites this week and I thought I would share it.  The question was where did I get all my knowledge about the Windows Event Log and the various Event ID’s.

The answer is a simple 2 part answer. Part 1 –> Repetition, repetition, repetition.  I have been analyizing event logs for more than 3 years now and before that I was a Sys Admin.  Looking at the events day in and day you tend to get them stuck in your head.  Part 2 –> Resources such as the information that I’ve learned from reading Randy F. Smith’s book and reviewing his course documentation and visiting his web site: www.ultimatewindowssecurity.com.  I have put a link to a new feature on Randy’s site, WinSecWiki, under my Blogrolls.  I also attend his webinars to get more info.  Randy has good insite to the Security log.  I have also had several conversations with Randy.

From time to time I will contribute to Randy’s Wiki, I will be posting under my first name on his site. 

If anyone has any questions about Windows Events or the Windows Audit Policy feel free to ask.

January 17, 2008 Posted by | Audit Policy, Event Log, Log Management | , , | Leave a comment

Great info from Eric Fitzgerald

Here is a link to a blog by Eric Fitzgerald, with the Windows Auditing Team.  http://blogs.msdn.com/ericfitz/

Thanks for your great info Eric.

September 1, 2007 Posted by | Log Management | , | Leave a comment