Category Archives: WLS

Event logs with control characters


A WLS user contacted me and was having issues parsing a date from a data field in EventID 6008 (unexpected shutdown). Taking a look at my logs everything looked fine, even in a viewer like Notepad++ with Show View->Show Symbol->Show All Characters. Since I use Splunk, on the record in question I selected Event Actions->Show Source, and it looked fine there too. Next I did a right-click and Inspect on the web page and there it was: “‎” aka u200e, aka E2808E, aka “Left-To-Right Mark”.

lrm

Saving the event text to a file and opening it with a hex editor also shows the control character in question (e2 80 8e):

e2808e

Indeed these control characters are included in at least 8 other events and all appear to be in date fields.

In Splunk you can use rex/sed or replace to remove control characters before attempting a strptime or other function.

`wlslogs` EventID=6008 | rex field=Data1 mode=sed "s/\p{C}//g" | eval NewDate=strptime(Data1,"%m/%d/%Y")

or

`wlslogs` EventID=6008 | eval NewDate=strptime(replace(Data1,"\p{C}",""),"%m/%d/%Y")

WLS 3.5 Released!


WLS 3.5 is here! Aside from the continual improvements to the core, here are a few highlights for this release.

File Tailing

This long requested feature was finally incorporated, primarily to support PowerShell v5 history and IIS logs, but should work well for a wide variety of logs. An example configuration for PowerShell v5 and IIS is included in the recommended configuration.

PE File Information

If specified, when encountered, ImpHash and the header fields defined below are now available for PE files. For non-PE files the Signature will be logged.

PE File

Example PE file with ImpHash and the compile/link time (TimeDateStamp):

[host] Security:  LogType=”WLS”, BaseFileName=”charmap.exe”, Channel=”Security”, CommandLine=”‘C:\WINDOWS\system32\charmap.exe'”, CompanyName=”Microsoft Corporation”, Computer=”[host].[domain]”, CreatorProcessName=”explorer”, EventID=”4688″, EventRecordID=”44735942″, ExecutionProcessID=”4″, ExecutionThreadID=”8992″, FileDescription=”Character Map”, FileVersion=”5.2.3668.0″, ImpHash=”7831775B376A2587FCB1CCB3E1EE37BF”, InternalName=”charmap.exe”, …, TimeDateStamp=”10/30/2015 2:37:15 AM”, TokenElevationType=”TokenElevationTypeDefault (1)”, ValidSignatureDate=”True”, Version=”2″, WindowStation=”Winsta0\Default”, Zone=”0″

Non-PE File

Example of a non-PE (16-bit!) file present in Windows 10 64-bit:

[host] WLS_FileData:  LogType=”WLS”, BaseFileName=”compobj.dll”, …, SHA1=”2BE21636F3C2899F1217C289351B106118A5E197″, Signature=”NE”, WLSKey=”3012″

Additions

  • CommandMonitor default support for netsh.exe and nslookup.exe
  • DecodeClientAddress
    • Logs with the ClientAddress field can be decoded to their actual values (IP, Port, and Scope)
  • DriveMonitor
    • Added DriveLogInterval to log drive details at regular intervals
  • ExistingProcess
    • Added the fields SubjectUserSid, SubjectUserDomain, and SubjectUserName
  • FileMetadata
    • CatHash available for PE files
    • File header fields available for PE files
    • IgnoredList option to prevent specific files from having metadata collected
    • ImpHash available for PE files
  • FileTail
    • Monitor flat files
  • Filters
    • Support for wildcard characters
  • Heartbeat
    • Reports LogsSent
  • LogRouting
    • CSV output
    • LogsSent is reported per-destination
  • LogRouting\Servers
    • SDID can be set per-server
    • UTC available via the UseUTC option
  • RegistryMonitor
    • Filtering by key Name and Value
  • PortMonitor
    • Added ResolveRemoteHostName option
  • SessionMonitor
    • Added SecurityUserID and Certificate fields

Changes

  • FileData
    • Internal logs can be routed through FileData to collect file metadata based on file names contain in logs
  • FileMetadata
    • Errors countered during metadata collection are now reported
  • FileMonitor
    • Delete events now report BaseFileName
  • PortMonitor
    • Removed port summarization
  • SSDeep (fuzzy hash)
    • Calculation was replaced. Now supports incremental hashing!

Fixes

  • CertificateMonitor
    • Certificates with invalid public key algorithms were not reported
  • CommandMonitor
    • Certain errors caused commands to not be reported
  • File permissions issues
  • FileMetadata
    • SSDeep was not calculated properly for some files
  • Filtering
    • The NewHash field wasn’t available to use in a filter
  • Heartbeat
    • Setting the interval to 0 did not disable the heartbeat
  • RegistryMonitor
    • Invalid registry paths would invalidate the entire group
  • ReplaceProviderString
    • Replacement strings containing multiple values with a comma delimiter were not replaced
  • SessionMonitor
    • SessionUser was not set to the actual session user when an invalid user was initially presented
  • Tags
    • All fields were not available to use for tagging

For more information on WLS, click “WLS Information” at the top, or here: WLS Information

If you’d like licensing or other information about WLS, send me a note via the contact form. WLS is currently available to US entities, but does require a signed license agreement.

Determine if a Smart Card Was Used for Logon


This method can only determine if a logon used Public Key Cryptography for Initial Authentication (PKINIT); successive locks / unlocks will continue to report the information from the initial logon.

According to this article: http://social.technet.microsoft.com/wiki/contents/articles/11844.find-out-if-a-smart-card-was-used-for-logon.aspx, a special security group is injected into the user’s access token when a smart card is used. Comparing the current user token group members between a password and smart card authenticated session revealed the group “NT Authority\This Organization Certificate” (S-1-5-65-1). (PowerShell for this below)

A search for S-1-5-65-1 returned this article: https://msdn.microsoft.com/en-us/library/cc980032.aspx, with the following information:

THIS_ORGANIZATION_CERTIFICATE

S-1-5-65-1

A SID that indicates that the client’s Kerberos service ticket’s PAC contained a NTLM_SUPPLEMENTAL_CREDENTIAL structure (as specified in [MS-PAC] section 2.6.4). If the OTHER_ORGANIZATION SID is present, then this SID MUST NOT be present. <25>

Following the link to section 2.6.4 leads to the description: “The PAC buffer type is included only when PKINIT [MS-PKCA] is used to authenticate the user”

So, by what I can find and test, the presence of “NT Authority\This Organization Certificate” (S-1-5-65-1) in the user’s access token groups positively indicates whether the initial authentication used PKINIT, e.g., smart card.

This can be tested with the following PowerShell code:

$objGroup = New-Object System.Security.Principal.SecurityIdentifier("S-1-5-65-1")
([System.Security.Principal.WindowsIdentity]::GetCurrent()).Groups.Contains($objGroup)

WLS now uses a similar method with SessionMonitor. Any time a session changes, the AuthenticationType, CredentialProvider, and PKINIT will now be reported.

2015-11-18T07:16:54-06:00 [host] WLS_SessionMonitor: LogType=”WLS”, ApplicationName=””, AuthenticationType=”Kerberos”, BuildNumber=”0″, ClientAddress=””, ClientDirectory=””, ClientName=””, CredentialProvider=”Smartcard Credential Provider”, EncryptionLevel=”High”, HardwareId=”0″, InitialProgram=””, Message=”SessionUnlock”, PKINIT=”True”, ProductId=”0″, Protocol=”Console”, Resolution=”640×480″, SessionId=”10″, SessionName=”Console”, SourceAddress=””, SourceName=””, User=”[domain]\[user]”, WLSKey=”677″, WorkDirectory=””


For more information on WLS, click “WLS Information” at the top, or here: WLS Information

If you’d like additional information about WLS, send me a note via the contact form. WLS is currently available to US entities, but does require a signed license agreement.

WLS 3.4 Released!


New

  • CommandMonitor support for wmic.exe
    • Ability to add other binaries
  • FileMetadata
    • File buffer size
    • File size and time limits for calculating hashes and entropy
  • FileMonitor special folder support which follows the interactive user
  • Heartbeat
    • Configurable interval. Reports DBSize, ConnectionErrors, LogsWLSError, WLSVersion
  • Log filtering
    • Per log route destination
  • LogFormats
    • All formats are now defined by the configuration
    • Custom formats can be added, existing ones changed, etc.
  • LogRouting
    • Simultaneous multi-destination sending of logs with per-server log formatting
  • Performance counters
    • Filtering by condition
  • ShowEntryTypeDescription
  • ShowLogonTypeDescription
    • Defaults to True for legacy compatibility
  • TrackHashes
    • Tracking of hashes to set the NewHash=True flag can be enabled / disabled
      • Tracking hashes takes space in the database and time during database writes

Changes

  • CertMonitor – FullReportInterval for interval based reporting
  • Entropy and hash calculations integrated to reduce file iterations and support timeouts
  • FileData logs the CreatorProcessName and CreatorProcessId
  • FileMetadata searches for non-rooted files iterating through the PATH variables
  • MaxLogLength now simply truncates the log if it is oversize

Fixes

  • Command Monitor – Fixed bug with greater than 16-bit PIDs
  • ConfigurationHash calculation
  • IPv6 parsing when specified as a log destination

For more information on WLS, click “WLS Information” at the top, or here: WLS Information

If you’d like additional information about WLS, send me a note via the contact form. WLS is currently available to US entities, but does require a signed license agreement.

Windows 7/2008 + RDP8 = Incorrect source network address


A few months ago I noticed some odd IP addresses in the WLS SessionMonitor logs for a few of our hosts. After confirming that this was not the result of a compromise I began digging further into the issue.

Our networking team had started investigating usage of RDP8 to improve the user experience for remote users, and had installed RDP8 and enabled the RDP8 protocol via policy on their Windows 7 systems. When an RDP connection was made, the Source Network Address was incorrect in Security Event ID 4624 (successful logon events), TerminalServices-RemoteConnectionManager Event ID 1149, and TerminalServices-LocalSessionManager Event ID 25. Usually this was reported as “0.0.0.0”, but sometimes contained random numbers. WLS uses WinStationQueryInformationW to retrieve the source network address for the session and it returned the same information that is reflected in the event logs.

Further testing showed that this only impacted Windows 7/2008 systems with RDP8 installed and enabled. Disabling the RDP8 protocol in the policy forces the connection to fall back to RDP7 which reports the IP address as expected. Changing the RDP transport protocols did not appear to have any effect.

The RDP8 protocol policy is located at:

Computer Configuration\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Remote Session Environment\Enable Remote Desktop Protocol 8.0

The RDP transport protocols policy is located at:

 Computer Configuration\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Connections\Select RDP transport protocols

Due to the way RDP was previously implemented, there will not be a fix provided that allows the Source Network Address to be properly reported in event logs, or a way to retrieve it via an API call. Here’s the associated KB for the issue detailed above: https://support.microsoft.com/en-us/kb/3097467

WLS 3.3 Released


New

  • Burn folder support for FileMonitor
  • FileData
    • Log file metadata for files found in command line parameters and event logs
  • Fixed (non-removable) disk monitoring
  • Load balancing
  • Network location awareness by joined domain
  • Optional host name set by DNS resolution
  • Optional alternate static host name
  • Monitoring UDF optical media changes
  • Support for non-FIPS hashing algorithms when FIPS mode is enabled
  • Suspended process checking (potential process hollowing)

Changes

  • Command line string handling
  • Database quota handling and maintenance
  • Error reporting
  • Event log extra data parsing
  • Event log XML parser
  • Installer
  • Network adapter reporting
  • New event log provider string resources (dynamic loading)
  • NewHash checking accuracy
  • Optimized syslog string generation
  • SessionMonitor reporting
    • All available session data logged for each session change event
    • Source IP address, optional source name (by resolution)
  • SQLite driver update
  • WMI reporting
    • Array handling
    • Nested WMI object support
    • Result count and index

Fixes

  • Database over quota issues
  • Drive monitor errors for unsupported file systems (HFS+, etc.)
  • Event log subsystem error detection
  • Potential WTS memory leak

For more information on WLS, click “WLS Information” at the top, or here: WLS Information

If you’d like additional information about WLS, send me a note via the contact form. WLS is currently available to US entities, but does require a signed license agreement.

WLS 3.2 – new process creation data: ConsoleProcessId, SessionId, WindowStation


WLS 3.2 introduces a few new pieces of data for process creation events.

ConsoleProcessId

A process can define an associated console process. The value, if provided by the process, is logged.

[host] Security: LogType=”WLS”, BaseFileName=”cmd.exe”, Channel=”Security”, CommandLine=”‘C:\Windows\system32\cmd.exe'”, CompanyName=”Microsoft Corporation”, Computer=”[host].[domain]”, ConsoleProcessId=”0xd08″, CreatorProcessName=”explorer”, EventID=”4688″, EventRecordID=”13010758″, ExecutionProcessID=”4″, ExecutionThreadID=”64″, FileDescription=”Windows Command Processor”, FileVersion=”6.1.7601.17514 (win7sp1_rtm.101119-1850)”, InternalName=”cmd”, Keywords=”0x8020000000000000″, Language=”English (United States)”, Length=”345088″, Level=”0″, MD5=”5746BD7E255DD6A8AFA06F7C42C1BA41″, NewProcessId=”0x1250″, NewProcessName=”C:\Windows\System32\cmd.exe”, Opcode=”0″, ProcessId=”0x15a4″, ProductVersion=”6.1.7601.17514″, ProviderGuid=”{54849625-5478-4994-A5BA-3E3B0328C30D}”, ProviderName=”Microsoft-Windows-Security-Auditing”, SessionId=”2″, SHA1=”0F3C4FF28F354AEDE202D54E9D1C5529A3BF87D8″, Signed=”Catalog”, SSDeep=”6144:NVl7yDR2iaGcsVXFBM6IT77aVebJWC1jIdDWCoCX9Sm:jdyDRwpmFq6ITSebJWwjIdDbNS”, SubjectDomainName=”[domain]”, SubjectLogonId=”0x940ee”, SubjectUserName=”[user]”, SubjectUserSid=”[SID]”, Task=”13312″, TokenElevationType=”TokenElevationTypeDefault (1)”, ValidSignatureDate=”False”, Version=”0″, WindowStation=”Winsta0\Default”, Zone=”0″

[host] Security: LogType=”WLS”, BaseFileName=”conhost.exe”, Cached=”True”, Channel=”Security”, CommandLine=”\??\C:\Windows\system32\conhost.exe ‘-1619064235-21228482731568564810739129054211757705058345892-390116831-1302099848#000″, CompanyName=”Microsoft Corporation”, Computer=”[host].[domain]”, CreatorProcessName=”csrss”, EventID=”4688″, EventRecordID=”13010759″, ExecutionProcessID=”4″, ExecutionThreadID=”64″, FileDescription=”Console Window Host”, FileVersion=”6.1.7600.16385 (win7_rtm.090713-1255)”, InternalName=”ConHost”, Keywords=”0x8020000000000000″, Language=”English (United States)”, Length=”338432″, Level=”0″, MD5=”BF95EA5809E3BBF55370F7CB309FEBD0″, NewProcessId=”0xd08″, NewProcessName=”C:\Windows\System32\conhost.exe”, Opcode=”0″, ProcessId=”0x1194″, ProductVersion=”6.1.7600.16385″, ProviderGuid=”{54849625-5478-4994-A5BA-3E3B0328C30D}”, ProviderName=”Microsoft-Windows-Security-Auditing”, SessionId=”2″, SHA1=”1BD846AA22B1D63A1F900F6D08D8BFA8082AE4DB”, Signed=”Catalog”, SSDeep=”6144:MvAVUtrTB1pzQdTOKnJoWafxXyn1U+8kbYzwFH1mbRBlOxm:MaaTpzSLSffxXyp8kb5ElY”, SubjectDomainName=”[domain]”, SubjectLogonId=”0x3e7″, SubjectUserName=”[host]$”, SubjectUserSid=”S-1-5-18″, Task=”13312″, TokenElevationType=”TokenElevationTypeDefault (1)”, ValidSignatureDate=”False”, Version=”0″, WindowStation=”Winsta0\Default”, Zone=”0″

SessionId

Previous versions of WLS provided data in regards to session information which could be correlated with the environmental variable SESSIONNAME, but was a bit awkward when viewing child processes that carry forward these variables even when the session has changed. SessionId is now reported for each process and can positively correlate to the correct session, without worrying about inherited environmental variables.

WindowStation

WindowStation is now reported for each process, providing insight into how the process was executed. WinSta0 can display a user interface and can receive user input. Other window stations are non-interactive, and can be used to enforce security restrictions, such as providing a sandboxed environment.

Chrome, for example, makes use of other window stations:

[host] Security: LogType=”WLS”, BaseFileName=”chrome.exe”, Cached=”True”, Channel=”Security”, CLIENTNAME=”[remote_host]”, CommandLine=”‘C:\Program Files (x86)\Google\Chrome\Application\chrome.exe’ –type=renderer –lang=en-US –force-fieldtrials=’BrowserBlacklist/Enabled/ChromeSuggestions/Most Likely with Kodachrome/EmbeddedSearch/Group6 pct:10f stable:pp2 prefetch_results:1 reuse_instant_search_base_page:1/ExtensionInstallVerification/Enforce/GoogleNow/Enable/OmniboxBundledExperimentV1/StandardR4/Prerender/PrerenderEnabled/PrerenderLocalPredictorSpec/LocalPredictor=Disabled/QUIC/Disabled/SafeBrowsingIncidentReportingService/Default/ShowAppLauncherPromo/ShowPromoUntilDismissed/Test0PercentDefault/group_01/UMA-Dynamic-Binary-Uniformity-Trial/default/UMA-Dynamic-Uniformity-Trial/Group6/UMA-Population-Restrict/normal/UMA-Session-Randomized-Uniformity-Trial-5-Percent/group_10/UMA-Uniformity-Trial-1-Percent/group_06/UMA-Uniformity-Trial-10-Percent/group_08/UMA-Uniformity-Trial-100-Percent/group_01/UMA-Uniformity-Trial-20-Percent/group_03/UMA-Uniformity-Trial-5-Percent/group_12/UMA-Uniformity-Trial-50-Percent/group_01/VoiceTrigger/Install/’ –extension-process –renderer-print-preview –device-scale-factor=1 –enable-threaded-compositing –enable-delegated-renderer –channel=’616.4.232552611\176135091′ /prefetch:673131151″, CompanyName=”Google Inc.”, Computer=”[host].[domain]”, CreatorProcessName=”chrome”, EventID=”4688″, EventRecordID=”13010449″, ExecutionProcessID=”4″, ExecutionThreadID=”64″, FileDescription=”Google Chrome”, FileVersion=”37.0.2062.103″, InternalName=”chrome_exe”, Keywords=”0x8020000000000000″, Language=”English (United States)”, Length=”852808″, Level=”0″, MD5=”0706DDBD4EA0D122CA069FF2552E20FD”, NewProcessId=”0x1d84″, NewProcessName=”C:\Program Files (x86)\Google\Chrome\Application\chrome.exe”, Opcode=”0″, ProcessId=”0x268″, ProductVersion=”37.0.2062.103″, ProviderGuid=”{54849625-5478-4994-A5BA-3E3B0328C30D}”, ProviderName=”Microsoft-Windows-Security-Auditing”, SessionId=”2″, SESSIONNAME=”RDP-Tcp#0″, SHA1=”627A52C64711BE8132E1D32FD482178E7422CF4F”, Signed=”True”, SSDeep=”12288:59obX26I5VZVX5LTqLEOtPf5R/38i//lIaJJ7XtvKiI245OtCYQpl/ARG4KHFBnk:59GLtXtTRolaKlBnk”, SubjectDomainName=”[domain]”, SubjectLogonId=”0x940ee”, SubjectUserName=”[user]”, SubjectUserSid=”[SID]”, Task=”13312″, TokenElevationType=”TokenElevationTypeDefault (1)”, ValidSignatureDate=”True”, Version=”0″, WindowStation=”Service-0x0-940ee$\sbox_alternate_desktop_0x268″, Zone=”0″

MSDN – Window Stations


For more information on WLS, click “WLS Information” at the top, or here: WLS Information

If you’d like additional information about WLS, send me a note via the contact form. WLS is currently available to US entities, but does require a signed license agreement.