Understanding event time in WinRM logs in NetWitness Platform

Issue

Understanding event time in Windows logs collected via WinRM collection method in RSA Security Analytics / NetWitness Logs & Network.

Resolution

WinRM can send data in GMT/UTC time.

If the event time stamp being sent by WinRM has a "Z", as in (It can be also looked into from the Event Viewer -> Application/System/Security -> double-click any event-> opens a new dialog box-> go to the Details tab-> select radio button XML View and then look for the Time Created), then the events in the system are stored in the UTC time and that is what would be sent across.

More on this "Z" and time zone codes can be found at Coordinated Universal Time and an excerpt on the "Z":

The UTC time zone is sometimes denoted by the letter Z - a reference to the equivalent nautical time zone (GMT), which has been denoted by a Z since about 1950. The letter also refers to the "zone description" of zero hours, which has been used since 1920 (see time zone history). Since the NATO phonetic alphabet word for Z is "Zulu", UTC is sometimes known as Zulu time. This is especially true in aviation, where Zulu is the universal standard.[23] This ensures all pilots regardless of location are using the same 24-hour clock, thus avoiding confusion when flying between time zones.

WinRM does not manipulate any time either. To simplify, WinRM is an agent which reads the events stored and sends it across (without manipulation) to the Log Collector / Remote Log Collector:

How the Time is determined ?

The time depends on the way an event is stored by the system or the Event Source not WinRM.

Example

An example of an event in xml format as stored in the system/Event Source as below:

 <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
 
 <System>
 
 <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-a5ba-3e3b0328c30d}" />
 
 <EventID>4672</EventID>
 
 <Version>0</Version>
 
 <Level>0</Level>
 
 <Task>12548</Task>
 
 <Opcode>0</Opcode>
 
 <Keywords>0x8020000000000000</Keywords>
 
 <TimeCreated SystemTime="2024-05-10T19:51:03.9731475Z" />
 
 <EventRecordID>2531542</EventRecordID>
 
 <Correlation ActivityID="{443a75e8-2196-463c-aa25-bcb452e7c228}" />
 
 <Execution ProcessID="1352" ThreadID="27340" />
 
 <Channel>Security</Channel>
 
 <Computer>NW-HMK9CS3</Computer>
 
 <Security />
 
 </System>
 
 <EventData>
 
 <Data Name="SubjectUserSid">S-1-5-18</Data>
 
 <Data Name="SubjectUserName">SYSTEM</Data>
 
 <Data Name="SubjectDomainName">NT AUTHORITY</Data>
 
 <Data Name="SubjectLogonId">0x3e7</Data>
 
 <Data Name="PrivilegeList">SeAssignPrimaryTokenPrivilege
 
 SeTcbPrivilege
 
 SeSecurityPrivilege
 
 SeTakeOwnershipPrivilege
 
 SeLoadDriverPrivilege
 
 SeBackupPrivilege
 
 SeRestorePrivilege
 
 SeDebugPrivilege
 
 SeAuditPrivilege
 
 SeSystemEnvironmentPrivilege
 
 SeImpersonatePrivilege
 
 SeDelegateSessionUserImpersonatePrivilege</Data>
 
 </EventData>
 
</Event>

WinRM would pick it up and send across without changing anything. If you look closely (the line in yellow), the time has a letter "Z" at the end, meaning GMT/UTC time. And that is what is sent across.
Whereas in Agentless collection, the Time Generated is of interest and is an offset of no of ticks since 00:00:00 1st January 1970. This offset is converted into readable time. This readable time is the local time of the collector.

Internal Comments

UserName:shurtj
5/5/2014 2:42:51 PM - Changed Article to "How-To"
Changed article type from corrective to how-to, and added some Goal and Fact statements.

UserName:shurtj
8/7/2014 2:15:30 PM - Updated Article
Updated article and made changes to abide by Primus best practices.

Product Details

Netwitness Product Set: NetWitness Logs and Packets
Netwitness Product/Service Type: Log Collector (WinRM Collection), Windows Legacy Collection
Netwitness Version/Condition: 11.x, 12.x
Platform: CentOS/Alma Linux

Approval Reviewer Queue

Technical approval queue