Event Log Managment

Logs .. Logs and More Logs

Micorsoft Patch Research Site

I was watching a Randy F. Smith webinar today and he showed a section of his website that he uses to track the Microsoft patches.  So I thought this would be good information to share.

September 16, 2009 Posted by | Microsoft Patches | | Leave a comment

More Info on Tracking Down File Deletes

Quite awhile ago I wrote a blog entry on Tracking Down File Deletes, it continues to be one of my most read blogs.  I came across another blog entry that does a good job of explaining the same thing.  The author is Ned Pyle, in his post he covers not only the Windows 2003 but also the Windows 2008 auditing so I thought I would share it with you.

August 5, 2009 Posted by | Audit Policy, Event Log, File Deletes, Log Management, Object Access | , , , , , | Leave a comment

Recommended Windows 2008 Audit Policy

Randy F. Smith has a good resource for the Windows 2008 Audit Policy.

May 27, 2009 Posted by | Audit Policy, Windows 2008 | | Leave a comment

IIS status code

Here is a link to some good information about the IIS status / sub-status codes for IIS 5 and 6.

Chris Crowe’s blog on IIS.

May 21, 2009 Posted by | IIS, 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

Detecting Insider Threats

Over the last few weeks I have been putting together a whitepaper on detecting insider threats (on a Windows network).  The paper is finished and is available here.  In the next few days I will be setting up a webinar that will cover this topic watch  <<removed>> for a link to the webinar.

**Some how I missed the links in this post and found it because someone clicked on the whitepaper link.  So July 23, 2011;  Do to some unforseen issues at Prism I can no longer in good faith promote their product or services and I have removed all links to their website.

April 29, 2009 Posted by | Audting, Hacking, Log Management | , | Leave a comment

Tips on Tracking Down a Hack Attempt

On Tuesday March 17, 2009 I conducted a webinar for Prism Microsystems on how Log Management can help you track down a hack attempt.  Now I know there are multiple ways to hack a network, the purpose of this webinar was to show that if you are collecting the log data from ALL your sources, network equipment/Unix/Linux/Windows that you can track down these attempts very quickly.  Log Management can also help you become more proactive vs always being reactive. 

**Feb 14, 2011; Do to some unforseen issues at Prism I can no longer in good faith promote their product or services and I have removed all links to their website.

March 20, 2009 Posted by | Hacking, Log Management | , | Leave a comment

‘Tigger’/Syzor Trojan

Good article at darkreading.com about the ‘Tigger’/Syzor Trojan written by Tim Wilson.  In this article he points to a blog by Michael Kassner with more info on ‘Tigger’/Syzor trojan.

March 6, 2009 Posted by | Misc | | Leave a comment

Analyzing ID 537 and the Status Codes

When looking through the logs have you ever come across that generic login failure event id 537?  Doesn’t really give you much at first glance, 90% of the time the user name in description field is blank.  This event comes in 2 forms, the workstation version and the DC version.

First I’m going to show the workstation version followed by the DC version.

As seen in the security log from Wrkstation1:

Event Type:        Failure Audit

Event Source:    Security

Event ID:              537

User:                     NT AUTHORITY\SYSTEM

Computer:          Wrkstation1

Description:

Logon Failure:

                Reason:                                An error occurred during logon

                User Name:       

                Domain:                              

                Logon Type:       3

                Logon Process:  Kerberos

                Authentication Package:               Kerberos

                Workstation Name:       

                Status code:       0xC000006D

                Substatus code:                0xC0000133

 

As seen in the security log on DC1:

 

Event Type:        Failure Audit

Event Source:    Security

Event ID:              537

User:                     NT AUTHORITY\SYSTEM

Computer:          DC1

Description:

Logon Failure:

                Reason:                                An error occurred during logon

                User Name:       

                Domain:                              

                Logon Type:       3

                Logon Process:  Kerberos

                Authentication Package:               Kerberos

                Workstation Name:       

                Status code:       0xC000006D

                Substatus code:                0xC0000133

                Caller User Name:          

                Caller Domain:  

                Caller Logon ID:

                Caller Process ID:            

                Transited Services:         

                Source Network Address:            192.168.1.144

                Source Port:       0

 

 

When you get the information from the DC you will be able to track down the system that generated the logon failure either by the Source Network Address or by the Workstation Name in the description field.  The part of this event that holds any real data is the status code (and thank you Microsoft for using HEX codes instead of plain English).

Most of the time you will beat your head against a wall trying to figure out what in the world these codes mean.

Well stop looking I have found a MSDN reference to the NTSTATUS codes. 

 

Now in the above 2 examples the Status code: 0xC000006D means that “The attempted logon is invalid. This is either due to a bad username or authentication information.”  Since we already know this look at the Substatus code:  0xC0000133 which means “The time at the primary domain controller is different from the time at the backup domain controller or member server by too large an amount.”  Now the “too large an amount” refers to 5 minutes.  Check the system time on the DC where the event happened and check the workstation (Source Network Address).

 

Hope this helps.

February 24, 2009 Posted by | Event Log | , , , | Leave a comment