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.

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

Auditing Drive Mappings

Windows does not track drive mappings for auditing out of the box. 

To audit drive mappings you will need to do the following steps:

1.       Turn on Object Access Auditing via Group Policy on the system(s) in question

You will need to perform the following steps on each system that you want to track the drive mappings

2.       Open the registry and drill down to HKEY_CURRENT_USER\Network

3.       Right click on Network and choose Permissions  (if you click on the plus sign you will see each of your mapped drive listed)

4.       Click on the Advanced button

5.       Click on the Auditing tab then click on the Add button

6.       In the Select User or Group box type in Everyone

7.       This will open the Auditing dialog box

8.       Select the settings that you want to audit for; stay away from the Full Control option and Read Control.  I recommend the following settings: Create Subkey, Create Link and Delete.

Windows will now generate event id 560, 567 and 564 when the drive mappings are added or deleted.  564 will be generated when a mapping is deleted, 567 will be created when a mapping is deleted or added and 560 will be generated both times as well.  Event ID’s 567 and 564 will not give you the full information that you are looking for, they will tell you what was done to the mappings but not WHICH mapping.  To determine which mapping you will need the Handle ID code that will be found in the event description on the 564/567 events.  The Handle ID will allow you to track back to the 560 event which will give you the mapping that is being added/deleted.  Event ID 567 will only be generated on Windows XP or Windows 2003 systems, Windows 2000 will not generate 567.

March 13, 2008 Posted by | Audit Policy, Audting, Event Log, Object Access | , , | Leave a comment