Monthly Archives: October 2015

WLS 3.4 Released!

Leave a reply

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.

Advertisement

Windows 7/2008 + RDP8 = Incorrect source network address

Leave a reply

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