Author Archives: Michael Karsyan

Invalid dates inside some events

You have probably heard that due to a date bug, it is easy to brick iPhone by changing its system date to Jan 1, 1970. If you are not aware of this issue, you may read it here. We found a very similar problem with event logging. Fortunately, nothing crashes, but the problem may stop a log from being loaded.

Recently we received a bug report that Event Log Explorer breaks loading the system event log on Windows 10 with error: “Invalid argument to date encode”. This happened only sometimes and if a log was loaded using New API. Researching the issue, we discovered that the problem is linked with Event ID = 107 of Microsoft-Windows-Kernel-Power (“The system resumed from sleep”). Moreover, in our time zone (GMT+3) all seems to work fine, but in GMT-5 it fails to load this event. However, Event Viewer loads this event without problems in all time zones. Really strange…

What is event 107 of Microsoft-Windows-Kernel-Power? At first glance, this is an absolutely harmless event – event date and time are correctly stored in the event log. The description of this event has no parameters.  But let’s investigate it deeper. The event details contain additional parameters:

<EventData>
  <Data Name="TargetState">6</Data>
  <Data Name="EffectiveState">5</Data>
  <Data Name="WakeFromState">5</Data>
  <Data Name="ProgrammedWakeTimeAc">1601-01-01T00:00:00.000000000Z</Data>
  <Data Name="ProgrammedWakeTimeDc">1601-01-01T00:00:00.000000000Z</Data>
  <Data Name="WakeRequesterTypeAc">0</Data>
  <Data Name="WakeRequesterTypeDc">0</Data>
</EventData>

That’s it! Although event description doesn’t refer any event parameters, there are 7 parameters stored with the events. And the problem is obviously linked  with ProgrammedWakeTimeAc and ProgrammedWakeTimeDc. Unfortunately Microsoft doesn’t have the detailed description of this event it the knowledgebase, but I suppose these parameters linked with a programmable system wake up when computer plugged in or on battery.

What is the exact reason of the problem? Windows Event Viewer displays all these parameters as is. But Event Log Explorer is smarter than Event Viewer. It automatically corrects times according to your time zone. So, if you are in the Western hemisphere (more correctly you are in UTC –xx time zone), Event Log Explorer will subtract something from Jan 1, 1601 (which is a starting point for Windows time) causing an error (negative value). It’s very similar to the iPhone date bug with 2 differences: the starting point for iPhone time (Unix time) is Jan 1, 1970 and Event Log Explorer does no harm.

Nevertheless it is a bug, and we immediately fixed it by checking the date/time value. If it is Jan 1, 1601 00:00, we do not apply time correction, and now it works correctly.

An updated version of Event Log Explorer is available from our site at

http://eventlogxp.com/download/elex_setup.exe

 

facebooktwittergoogle_plusredditpinterestlinkedinmail

Logon type – what does it mean?

In my previous post, I explained how to display logon type for logon events in Security log and described meaning of some values. Here I will give you more information about logon types.

The descriptions of some events (4624, 4625) in Security log commonly contain some information about “logon type”, but it is too brief:

The logon type field indicates the kind of logon that occurred. The most common types are 2 (interactive) and 3 (network).

Microsoft provides more detailed description of logon types at https://technet.microsoft.com/en-us/library/cc787567(v=ws.10).aspx (Audit Logon Events).
This topic at the Microsoft site is about logon events auditing for pre-Vista operating systems, but it looks like Logon Type constants are valid for all Windows operating systems.

Therefore, I will copy Microsoft descriptions here and add my own comments.

Logon Type 2: Interactive. A user logged on to this computer.

An event with logon type=2 occurs whenever a user logs on (or attempts to log on) a computer locally, e.g. by typing user name and password on Windows logon prompt. Events with logon type = 2 occur when a user logs on with a local or a domain account. However, if a user logs on with a domain account, this logon type will appear only when a user really authenticated in the domain (by a domain controller). In case if the DC not available, but the user provided valid domain credentials cached in the local PC, Windows will log an event with logon type = 11.

Logon type 3:  Network.  A user or computer logged on to this computer from the network.

The description of this logon type clearly states that the event logged when somebody accesses a computer from the network. Commonly it appears when connecting to shared resources (shared folders, printers etc.). As we learned in the previous post, the connection with logon type = 3 could be established even from a local computer.

Logon type 4: Batch.  Batch logon type is used by batch servers, where processes may be executing on behalf of a user without their direct intervention.

This event type appears when a scheduled task is about to be started. E.g. if you use Windows Task Scheduler and it’s time to start a task, Windows may create a new logon session to execute this task and register logon events (4648, 4624/4625). If a task is scheduled to run only when a “designated” user is logged on, a new logon session won’t be opened and logon events won’t be logged.

Logon type 5: Service.  A service was started by the Service Control Manager.

When Windows starts a service which is configured to log on as a user, Windows will create a new logon session for this service. This happens only if the service uses a “common” user account. If it uses special accounts, e.g. “Local System”, “NT AUTHORITY\LocalService” or “NT AUTHORITY\NetworkService”, Windows won’t create new logon sessions. The opened logon session will be closed when the service stops and a logoff event (4634) will be registered.
Note that event description doesn’t contain any information about the service name, process information lists only name of the service control manager (services.exe).  When Audit Failure logon event (4625) is registered with logon type = 5, this commonly means that the “designated” user has changed password, and you should update service logon details.

Logon type 7:  Unlock. This workstation was unlocked.

An event with logon type = 7 occurs when a user unlocks (or attempts to unlock) a previously locked workstation. Note that when a user unlocks computer, Windows creates a new logon session (or 2 logon sessions depending on the elevation conditions) and immediately closes it (with event 4634). When you are switching between logged on user accounts with Fast User Switching feature, you may think that such switching generates event 4624 with logon type = 7 because it looks like you lock and unlock workstation. However Windows generates events 4624 with logon type = 2 (interactive). When Audit Failure logon event (4625) is registered with logon type = 7, this commonly means that either you made a typo when entering the password, or someone is trying to break into the computer.

Logon type 8:  NetworkCleartext. A user logged on to this computer from the network. The user’s password was passed to the authentication package in its unhashed form. The built-in authentication packages all hash credentials before sending them across the network. The credentials do not traverse the network in plaintext (also called cleartext).

I believe that you should never see logon events with logon type = 8. This event is generated when a password comes from the net as a clear text. Such events may occur when a user logs on IIS (Internet Information Services) with basic access authentication method. Transferring passwords in plaintext format is dangerous because the passwords could be sniffed and revealed. So if basic authentication is the only option for you, you should protect your network connection (using encryption protocols like SSL/TLS, creating virtual private network etc.).

Logon type 9:  NewCredentials. A caller cloned its current token and specified new credentials for outbound connections. The new logon session has the same local identity, but uses different credentials for other network connections.

This event occurs when using RunAs command with /netonly option. Let’s say you need to run a program, but grant it extra permissions for network computers. E.g. you may want to run Event Log Explorer and give it additional permissions for a specific computer or a domain  (this may be helpful e.g. if you want to use a specific computer as a description server in Event Log Explorer, but your current permissions is not enough to access admin resources from this server). In this case you can run Event Log Explorer normally (using your current credentials), but specify special credentials for network connections. Let’s say your computer name is “WORK” and the description server name is “SERVER”. On WORK computer you type:

runas.exe /netonly /user:server\Administrator “c:\program files\event log explorer\elex.exe”

and provide administrator’s password when prompted.

This will run Event Log Explorer even if you provided a wrong password. This happens because it uses a cloned current credentials to run the program (a new logon session will be opened). And logon event 4624 will be logged with logon type = 9 (logoff event will be logged when you quit the application). But what about SERVER? The server will register 4624 or 4625 events in Security log with logon type = 3 but only when the application from WORK computer will try to access a shared resource on the server, e.g. Event Log Explorer will try to open resource file with event descriptions.

Logon type 10: RemoteInteractive. A user logged on to this computer remotely using Terminal Services or Remote Desktop.

This logon type is similar to 2 (Interactive) but a user connects the computer from a remote machine via RDP (using Remote Desktop, Terminal Services or Remote Assistance).

Logon type 11:  CachedInteractive. A user logged on to this computer with network credentials that were stored locally on the computer. The domain controller was not contacted to verify the credentials.

When users logon a domain, Windows caches users’ credentials locally so that they can log on later even if a logon server (domain controller) is unavailable. By default Windows caches 10 or 25 last logon credentials (it depends on the operating system and can be increased up to 50). When a user attempts to logon with domain account while DC is not available, Windows checks the user’s credentials with these stored hashes and logs security events 4624 or 4625 with logon type = 11.

facebooktwittergoogle_plusredditpinterestlinkedinmail

Exploring who logged on the system

One of the most important tasks in the security event log analysis is to find out who or what logs your system on. Here I will explain how Event Log Explorer helps you to solve this task.

First, you need to make sure that Windows security auditing is enabled for logon events. You can do this using Local Security Policy or Group Policy, depending on your network environment.

Read more about Windows Security Auditing at http://eventlogxp.com/essentials/securityauditing.html

Open Security event log with Event Log Explorer. As a rule, you will get too many different events, but now we are interested in events with the following Event IDs:

4624 An account was successfully logged on
4625 An account failed to log on

There are several ways to filter events by Event ID, I prefer using Log Loading Filter:

From the main menu select View->Log Loading Options and then in Event IDs filed type
4624, 4625
then press OK.
Log Loading Filter

Now you can see only several interested events, but it is still not very clear. User column displays nothing for both successful and failure events (in fact, User column is useless for Security log since Windows 2008/Vista).
filteredevents

All the event details are available in the event description:
event details

One of the advantages of Event Log Explorer is Custom Columns feature. It lets you extract information from the event details and display it as a column in the event list.
Let’s add user name and logon type to the list:

Select View->Custom columns from the main menu

Adding User Name:

Give a name of the column (e.g. User Name)

You can set Event source to Microsoft-Windows-Security-Auditing and Event ID(s) to 4624, 4625, but since the log already filtered by these parameters you may leave these fields blank.

Now you should set Value.

There is a difference in event description between events 4624 and 4625:

New Logon:
             …
             Account Name:              Administrator
             Account Domain:            MIKE-HP
Account For Which Logon Failed:
             …
             Account Name:              Administrator
             Account Domain:            localhost

So, Account Name or Domain cannot be referenced by name, but fortunately they have the same index number, so we can reference them by index:
type
{PARAM[7]}\{PARAM[6]}
In Value field.
custom columns

Adding Logon Type

In Custom Columns dialog switch to Column 2.

Give a name of the column (e.g. Logon Type).

You may leave Event Source and Event IDs empty.

Type {Logon Type}
in Value filed.

Press OK in Custom Columns dialog.
Events with username and logon type

To make the view more perfect, remove useless User column:
Select View->Configure Columns and switch User off.

Now you can see that we have several successful interactive logons (Logon Type=2), two logons by a service (Logon Type=5) and a lot of failed logon attempts with Logon Type = 3 (Network logon).

Let’s check from which computers somebody tried to connect to our host:

Select View->Custom Columns from the menu.

Switch to Column 3

Give a name of the column (e.g. Remote Station).

Set Event IDs to 4625 (we need this information for invalid logon attempts only)

Type {Network Information\Workstation Name} 
in Value filed.

Press OK.
Remote Worskation

Now we can find an invalid logon attempt from a remote workstation, but we also found many network logon attempts from our local computer.

Security event log contains information about the process that attempted to logon. We can also display it as a custom column:

Select View->Custom Columns from the main menu.

Switch to Column 4.

Give a name of the column (e.g. Caller Process).

Set Event IDs to 4625 (we need this for logon attempts only)

Type {Process Information\Caller Process Name}
in Value filed.

Press OK.
4625-caller process

So, now we can see which local processes tried to logon the system as Administrator, from which workstations users tried to logon our system and who and when logged on successfully and other logging on details.

facebooktwittergoogle_plusredditpinterestlinkedinmail