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.
Password Never Expires and Account Set to Expire
Recently I was asked, “What type of user account changes do you watch for?” There are several but I wanted to focus on 2 changes that most people ask for. 1 “How can I tell if someone’s password has been set to never expire?” and 2nd “How can I tell if an account has been set to expire?”. We will look at both the Windows 2003 and older Windows OS event (id 642) and the Windows 2008/Vista event (id 4738). Sure there are scripts that you can run against your AD and Local System accounts to gather this information. But if you have the correct auditing turned on (Audit Account Mgmt) you can get this information via the event logs and if you are collecting your logs using a log management tool you can get this info in real time. I’m not going to show the entire event descriptions for id’s 642 and 4738, but I will show the sections that are important to us. What’s nice about both of these events is that they appear whenever an account has been changed; this can be at the time of account creation or after an account is created.
For id 642 you need to look at the following:
Target Account Name: joe.user (User whose account was changed)
Target Domain: Acme (Users domain ; can also indicate local account)
Caller User Name: bob.admin (Admin who made the change)
For id 4738 look at the following:
Subject:
Account Name: bob.admin (Admin who made the change)
Target Account:
Account Name: joe.user (User whose account was changed)
Account Domain: Acme (Users domain; can also indicate local account)
This information holds true for any change to the account either local or one that is part of your AD. The next information will tell you What changed on the account. So for question 1, password set to never expire you need to watch for the following.
For id 642 and 4738:
Changed Attributes:
User Account Control:
‘Don’t Expire Password’ – Enabled (Box has been checked for password to never expire)
Now when you reverse the change and uncheck the password never expires box you will see ‘Don’t Expire Password’ – Disabled
Now for question 2, determine when an account has been set to expire.
For id 642 and 4738:
Changed Attributes:
Account Expires: x/xx/xxxx xx:xx:xx PM (This gives you the Date/Time that the account will expire)
If an account is setup to never expire then the Account Expires will have a dash (-) after it.
I’m now on Twitter
For those who want to follow along here is the link to my twitter:
twitter.com/eventlogguru
Webinar hosted by Whitehatworld
The other day I conducted a webinar that was hosted by Whitehatworld.com. I have been asked by several people if I would post a link to the recording, so click here to view the webinar. The webinar topic was “Security Beyond the Windows Event Log – Monitoring Ten Critical Conditions”.
-
Archives
- December 2009 (1)
- November 2009 (1)
- October 2009 (1)
- September 2009 (1)
- August 2009 (1)
- May 2009 (3)
- April 2009 (1)
- March 2009 (2)
- February 2009 (4)
- September 2008 (1)
- August 2008 (1)
- June 2008 (1)
-
Categories
-
RSS
Entries RSS
Comments RSS