Category Archives: WLS

WLS 3.7.22 Released!

WLS 3.7.22 is here! The latest version of SIEM, format, and protocol agnostic Windows event log forwarding with process creation metadata and user defined contextual information, now with LNK parsing, file system minifilter reporting, WBCL reporting, and sysmon configuration management!

CommandMonitor

  • Added support for Windows 11 command history when cmd.exe is launched inside Windows Terminal

FileData

  • Added LNK parsing and reporting
    • Processes launched from a shortcut, when the LNK field is requested, will have LNK details logged along with user-defined metadata

2022-09-26T12:07:18-05:00 host WLS_FileData: LogType=”WLS”, AccessTime=”2/23/2022 3:51:57 PM”, BaseFileName=”Configuration Manager Console.lnk”, CreationTime=”7/27/2021 2:33:52 AM”, CreationTime1=”2/23/2022 9:51:59 AM”, FileAttributes=”ARCHIVE”, FileDataName=”LNK”, FileName=”C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Microsoft Endpoint Manager\Configuration Manager\Configuration Manager Console.lnk”, HotKey=””, IconIndex=”0″, KnownFolder=”7c5a40ef-a0fb-4bfc-874a-c0f2e0b9fa8e”, LastAccessTime=”9/26/2022 12:06:41 PM”, LastWriteTime=”2/23/2022 9:51:59 AM”, Length=”1409″, LinkFlags=”HasLinkTargetIDList, HasLinkInfo, HasRelativePath, IsUnicode”, LinkInfoFlags=”VolumeIDAndLocalBasePath”, LocalBasePath=”C:\Program Files (x86)\Microsoft Endpoint Manager\AdminConsole\bin\Microsoft.ConfigurationManagement.exe”, MacAddress=”F80DAC6E57E8″, MachineID=”host”, MD5=”D82ABC2B24AA63332BE73F80656AD31D”, PropertyStoreCount=”2″, RelativePath=”..\..\..\..\..\..\..\Program Files (x86)\Microsoft Endpoint Manager\AdminConsole\bin\Microsoft.ConfigurationManagement.exe”, SHA1=”08F381B34236F9F12F62FEE6FF88B96D5B6DAEE0″, ShowCommand=”1″, SID=”S-1-5-18″, Size=”434544″, SpecialFolder=”ProgramFilesX86″, User=”NT AUTHORITY\SYSTEM”, VolumeLabel=”Windows”, WLSKey=”11169″, WriteTime=”7/27/2021 2:33:52 AM”

Filters

  • Added filter groups to ease management of related filters

LogFormats

  • Added MACHINEGUID field
    • For use as a unique identifier such as a Splunk HEC channel
  • Added “unix” date format
    • Useful for JSON logs with Splunk HEC

Logging

  • Added file system minifilter logging
    • Enhanced output similar to fltmc.exe with file metadata
    • Example from “Windows Sandbox”WindowsSandboxFileSystemFilters
  • Added LogUserChange parameter
    • Log when the user changes from parent to child process

LogRouting

  • Added support for HTTP servers, including custom headers
  • Added parameters to verify connections meet requirements
    • Useful when using HTTPS destinations and captive portals or other MITM scenarios are encountered

RemoteConfiguration

  • Added parameters to support more destinations and formats
    • Useful when loading remote configuration from version control systems such as gitlab and other non-standard HTTP(s) sources
  • Added sysmon configuration loading
    • The last sysmon configuration found when processing applicable rules will be applied

Windows Boot Configuration Log (WBCL) – New!

  • Initial and periodic reporting of the WBCL

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.

Advertisement

WLS – Windows Boot Configuration Log (WBCL) / TCG

Building on the existing reporting of the TPM status and certificates, WLS now has the ability to report the Windows Boot Configuration Log, also known as the Trusted Computing Group (TCG) measured boot logs. This is the same information used to perform Device Health Attestation (DHA) and that is logged at %windir%\Logs\MeasuredBoot\.

WLS reads this information directly via the API and reports it in the order provided by the OS. Known values are decoded where applicable, others are reported in hexadecimal up to the user specified byte count for later analysis. By default, reporting is enabled for the Current Static Root Trust of Measurement (SRTM), reporting for the Boot, Current, or Resume, SRTM or Dynamic Root Trust of Measurement (DRTM) is also available. These can be logged on startup and at a chosen interval to enable tracking over time of variations.

A Splunk dashboard has been created to analyze and decode these logs for comparison across all systems. This includes Early Launch Anti-Malware (ELAM), Bitlocker state and status changes, virtualization based security (VBS), loaded modules, Extensible Firmware Interface (EFI) actions, and more. Known Platform Configuration Registers (PCR) and common acronyms related to the WBCL can optionally be displayed for reference; the System Integrity Platform Attestation (SIPA) definition was surprisingly hard to find.

Rare loaded modules can help locate systems with a non-standard configuration and potentially malware.

EFI actions may show configuration issues and other important information.

The raw events are shown in-order with decoding for well-known items and hexadecimal to ascii decoding to show readable data where possible. This lets you trace one or more systems through boot process to analyze loaded modules, signing certificates, hypervisor policies, Bitlocker unlock status, and other settings.

This is just one of the new features coming with the WLS 3.7 update; others include shortcut/LNK parsing and reporting for new process events and command line parameters, loaded file system filters (fltmc), HTTP(s) log destinations, and Portable Executable (PE) directory names and values (debug, export, import, etc.).


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.

WLS 3.7 Released!

WLS 3.7 is here! The latest version of vendor-agnostic Windows event log forwarding with process creation metadata and user defined contextual information, now with RemoteConfiguration for dynamic install-time and post-install settings management.

CertificateMonitor

  • TPM SRKPUB information reported if available
  • TPM information reported for EKCERT and EKNVCERT when TPM is selected as a store location to report. EKCERT may be overwritten and/or contain multiple certificates as configured by the organization/user. EKNVCERT should reflect the TPM provided certificate.  Examples:

2021-07-20T08:27:08-05:00 host WLS_CertificateMonitor: LogType=”WLS”, Archived=”False”, ChangeType=”Initial”, Critical=”1,2,3″, EnhancedKeyUsages=”Endorsement Key Certificate”, ExtensionCount=”9″, Extensions=”Authority Information Access,Key Usage,Subject Alternative Name,Basic Constraints,CRL Distribution Points,Certificate Policies,Authority Key Identifier,Enhanced Key Usage,Subject Directory Attributes”, HasPrivateKey=”False”, Issuer=”CN=Infineon OPTIGA(TM) TPM 2.0 RSA CA 042, OU=OPTIGA(TM), O=Infineon Technologies AG, C=DE”, KeyAlgorithm=”RSA”, KeyUsages=”KeyEncipherment”, NotAfter=”12/30/2034 7:05:45 AM”, NotBefore=”12/30/2019 7:05:45 AM”, PublicKeySize=”2048″, SerialNumber=”5FF96D85″, SHA1=”0D8C16C554A825CBEF8B880A4216851F0577724F”, SignatureAlgorithm=”sha256RSA”, StoreLocation=”TPM”, StoreName=”EKNVCERT“, Subject=”TPMVersion=id:0755, TPMModel=SLB 9670 TPM2.0, TPMManufacturer=id:49465800″, SubjectAlternativeName=”Directory Address:TPMVersion=id:0755, TPMModel=SLB 9670 TPM2.0, TPMManufacturer=id:49465800″, User=”Local Computer”, Version=”3″, WLSKey=”1079″

2021-07-20T08:27:07-05:00 host WLS_CertificateMonitor: LogType=”WLS”, Archived=”False”, ChangeType=”Initial”, Critical=”1,2,3″, EnhancedKeyUsages=”Endorsement Key Certificate”, ExtensionCount=”9″, Extensions=”Authority Information Access,Key Usage,Subject Alternative Name,Basic Constraints,CRL Distribution Points,Certificate Policies,Authority Key Identifier,Enhanced Key Usage,Subject Directory Attributes”, HasPrivateKey=”False”, Issuer=”CN=Infineon OPTIGA(TM) TPM 2.0 RSA CA 042, OU=OPTIGA(TM), O=Infineon Technologies AG, C=DE”, KeyAlgorithm=”RSA”, KeyUsages=”KeyEncipherment”, NewHash=”True”, NotAfter=”12/30/2034 7:05:45 AM”, NotBefore=”12/30/2019 7:05:45 AM”, PublicKeySize=”2048″, SerialNumber=”5FF96D85″, SHA1=”0D8C16C554A825CBEF8B880A4216851F0577724F”, SignatureAlgorithm=”sha256RSA”, StoreLocation=”TPM”, StoreName=”EKCERT“, Subject=”TPMVersion=id:0755, TPMModel=SLB 9670 TPM2.0, TPMManufacturer=id:49465800″, SubjectAlternativeName=”Directory Address:TPMVersion=id:0755, TPMModel=SLB 9670 TPM2.0, TPMManufacturer=id:49465800″, User=”Local Computer”, Version=”3″, WLSKey=”612″

CommandMonitor

  • Supports Windows 10 14393 and later

Database

  • Optional in-memory only log caching – intended reduce disk usage on temporal systems such as non-persistent VDI

FileMetadata enhancements

Logging

  • CPU affinity will be used to restrict the processors available to WLS when CPUAffinity or CPULimitCores is set
  • Improved filter performance and added more options. WLS App for Splunk includes Filter Data dashboard
    • FilterData
  • Event descriptions can be reported periodically (LogEventDescriptionInterval). WLS App for Splunk includes a scheduled search, lookup, and macro to build unique event descriptions and return them at search time.
  • Process “tree” information can be reported. WLS App for Splunk contains dashboards for filtering and analysis.
    • ProcessTree
  • Process ID fields present in logs can be resolved to a process name and reported as [ProcessIDField]Name

LogFormats

  • HMAC can be added to logs for later integrity verification. Secret key is encrypted after being set. WLS App for Splunk includes setup and macro for verification.

LogRouting

  • Logs can be output to a text file at a user defined destination
    • This can be the primary output, or a parallel output to other destinations

NamedPipeMonitor

  • Enhanced filtering options
  • Improved filtering performance

Print Monitor – New!

  • Log print jobs processed through the local print spooler

Process / MonitorFilter

  • Monitors that are triggered by process creation/termination can be tuned to reduce resource utilization caused by frequent, expected processes

RemoteConfiguration – New!

  • WLS settings can be read from a file or web URL
    • Remote URL can be set at installation, no predefined configuration is required for deployment
    • Support for XML digital signatures to provide verification of content and that the signing certificate is trusted
  • Rules can be used to load specific settings for hosts based on host attributes and WMI data

ServiceMonitor – New!

  • Monitor Windows services. WLS App for Splunk includes dashboard for viewing the last known status and comparing changes over time.
    • ServiceStatus

SessionMonitor

  • Log user-defined certificate fields if used for authentication
  • Log local non-loopback IP addresses (positive user/IP correlation!)
  • Log user defined WinStationClient fields
    • WLS App for Splunk provides decoding for PerformanceFlags and WSFlags

Task Monitor – New!

  • Log scheduled tasks on startup, periodically, and on-change
    • WLS App for Splunk provides a dashboard for analysis

WinObjectMonitor

  • Enhanced filtering options
  • Improved filtering performance

Misc

  • Added support for decoding additional encoded IP address fields
  • Improved finding files when user specific environmental variables are used
  • Improved finding files when files have relative paths and are located in directories specified in the PATH environmental variable

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.

WLS 3.6 Updated

WLS 3.6.18320 is here!

This release is primarily to address https://fpki.idmanagement.gov/truststores/microsoft/, which affected the digital signature of WLS.

CertificateMonitor

  • Added support for reporting TPM EKCERTs

FileMetadata enhancements

  • Added support for nested x509Certificate2 properties

FileTail

  • Added support for reporting the file path; none, absolute, or relative

Logging

  • Event provider metadata will now attempt to use the specified LogCulture

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.

WLS 3.6 Released!

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

ARP – New!

  • Periodically log the ARP table

DNS Cache – New!

  • Periodically log the DNS cache

CertificateMonitor

  • Log certificate information as specified by Extension FriendlyName OR OID
    • Useful for logging extra information such as the Certificate Template Information

FileMetadata enhancements

  • Added AlternateDataStreamFileMetadata
    • Specify alternate FileMetadata settings to be used for files found in AlternateDataStreams
  • Added ImpSSDeep hash
    • Fuzzy hash of all PE imported libraries and function names
  • Added GetSectionNames
    • Log the section names as defined in the PE header of the file
  • Added ZoneFields parameter to FileMetadata
  • Filtering to prevent specific metadata from being collected

Local Users – New!

  • Periodically log users with specified parameters and their groups
  • Periodically log groups with specified parameters and their users

Misc

  • Added detection for IMAGE_DEBUG_TYPE_REPRO which affects the TimeDateStamp in the file header
  • Enhanced support for alternate data streams and symlinks
  • Enhanced support for version information including languages and codepages
  • Support for TLS 1.1 with .NET 4.5+
  • Support for TLS 1.2 with .NET 4.6+

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.

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