Author Archives: digirati82

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.

WLS 3.2 Released

Performance

  • Replaced WMI calls with native API calls where applicable
  • Faster database maintenance procedures

Features

  • CPU utilization tracking and reporting
  • New process metadata
    • ConsoleProcessId
    • SessionId
    • WindowStation

Fixes

  • Disconnected client resource utilization
  • Additional handling of SEHExceptions
  • Errors for EventRecordIDs > int32.Max

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.1 Released

Performance

  • Over 10x increase in internal throughput
  • Reduced internal latency
  • Improved read/write concurrency
  • Reduced I/O writes

Features

  • Advanced log filtering
  • Detailed statistic logs of log filter matches
  • Certificate monitoring enhanced – all stores now available
  • Configuration hashing – ensure hosts are running the correct configuration
  • Enhanced CommandMonitor – Faster memory searches, includes process name, support for cmd, powershell, and more!
  • Detailed network interface logs on start-up and network change
  • Display names for coded values
  • ETL monitoring for Event Logs and files
  • Per server bandwidth and maximum log length settings
  • Full SSL connection details logged on first connection
  • Input rate limiting – prevent unexpected log floods
  • PrivateMBLimit – prevent WLS from consuming resources on a troubled system
  • SSDeep hashing
  • SessionMonitor – now includes all remote session details for RemoteConnect
  • User SID resolution to user name when present in log
  • Versioning changed – Major.Minor.[Year][DayOfYear].[MinuteOfDay]
  • Registry and file locations now restricted to Local System and Administrators

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.

Finding vulnerable OpenSSL DLLs (Heartbleed) with WLS and Splunk

If you are running WLS with ModuleMonitor enabled, you already have logs of all loaded DLLs.

Simply run the following search:

WLS_ModuleMonitor “openssl” FileVersion=”1.0.1*” NOT FileVersion=”1.0.1g”

Results will look similar to:

2014-04-24T11:28:38-05:00 [host] WLS_ModuleMonitor: LogType=”WindowsEventLog”, BaseFileName=”ssleay32.dll”, ChangeType=”Added”, CompanyName=”The OpenSSL Project, http://www.openssl.org/”, FileDescription=”OpenSSL Shared Library”, FileName=”C:\Program Files\MakerBot\MakerWare\ssleay32.dll”, FileVersion=”1.0.1e”, InternalName=”ssleay32″, Language=”English (United States)”, Length=”343040″, MD5=”A49B52FB216AD1524C902A41A433A1E1″, Process=”makerware”, ProductVersion=”1.0.1e”, SHA1=”F21CBCC5F291C1D841581FDBBBF854B315D71248″, WLSKey=”35505″, Zone=”0″


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.

Decoding Event Log Provider Message IDs

When reviewing event logs in Event Viewer, the General tab shows event details in a human readable format, including displaying localized strings.

general_tab

However, when viewing the log on the Details tab in Friendly or XML view some of this “decoding” is not performed.

detail_friendly detail_xml

The Problem

WLS uses the XML version of logs, so these same codes were passed along instead of the localized string. For many logs this was OK since it was fairly easy to find the code in question and the corresponding value. While exploring this further (at customer request), I found that for some logs these values can change by host and version of the software generating the logs, as it is dependent on the provided message files. This made my previous plan to use static lookup tables unfeasible.

The Solution

The files that contain localized event log messages are identified for each event source in the registry at HKLM\SYSTEM\CurrentControlSet\services\eventlog\$logname$\$channel$. For example, Security log message files are identified at:

HKLM\SYSTEM\CurrentControlSet\services\eventlog\Security\Security

registry_eventlog_parameter_file

If you open the file identified as the ParameterMessageFile in a resource viewer you’ll see a message table for each language code with a list of messaged IDs and values.

resource

Now that we have the message IDs and the file to decode them, decoding them is easy with a call to FormatMessage, which expects a handle to the message file and a message ID. The message file is loaded as a data file with LoadLibraryEx and the returned handle and a message ID are passed to FormatMessage. If successful, our string buffer now contains the message.

WLS performs the above actions if DecodeProviderString is enabled. A new field will be created with the decoded value, or if ReplaceProviderString is enabled, the original field value will be replaced with the decoded value.

Example

Field added:

[host] Security: LogType="WLS", BaseFileName="audiodg.exe", Channel="Security", CompanyName="Microsoft Corporation", Computer="[host].[domain]", CreatorProcessName="svchost", EventID="4688", EventRecordID="11668699", ExecutionProcessID="4", ExecutionThreadID="56", FileDescription="Windows Audio Device Graph Isolation", FileVersion="6.1.7600.16385 (win7_rtm.090713-1255)", InternalName="audioadg.exe", Keywords="0x8020000000000000", Language="English (United States)", Length="126464", Level="0", MD5="D5CCA1453B98A5801E6D5FF0FF89DC6C", NewProcessId="0x3188", NewProcessName="C:\Windows\System32\audiodg.exe", Opcode="0", ProcessId="0x214", ProductVersion="6.1.7600.16385", ProviderGuid="{54849625-5478-4994-A5BA-3E3B0328C30D}", ProviderName="Microsoft-Windows-Security-Auditing", SHA1="F033FD30AACD0183BFC30861891A92B56AC2468B", Signed="Catalog", SubjectDomainName="NT AUTHORITY", SubjectLogonId="0x3e5", SubjectUserName="LOCAL SERVICE", SubjectUserSid="S-1-5-19", Task="13312", TokenElevationType="%%1936", TokenElevationTypeValue="TokenElevationTypeDefault (1)", ValidSignatureDate="False", Version="0", Zone="0"

Value replaced:

[host] Security: LogType="WLS", BaseFileName="audiodg.exe", Channel="Security", CompanyName="Microsoft Corporation", Computer="[host].[domain]", CreatorProcessName="svchost", EventID="4688", EventRecordID="11668699", ExecutionProcessID="4", ExecutionThreadID="56", FileDescription="Windows Audio Device Graph Isolation", FileVersion="6.1.7600.16385 (win7_rtm.090713-1255)", InternalName="audioadg.exe", Keywords="0x8020000000000000", Language="English (United States)", Length="126464", Level="0", MD5="D5CCA1453B98A5801E6D5FF0FF89DC6C", NewProcessId="0x3188", NewProcessName="C:\Windows\System32\audiodg.exe", Opcode="0", ProcessId="0x214", ProductVersion="6.1.7600.16385", ProviderGuid="{54849625-5478-4994-A5BA-3E3B0328C30D}", ProviderName="Microsoft-Windows-Security-Auditing", SHA1="F033FD30AACD0183BFC30861891A92B56AC2468B", Signed="Catalog", SubjectDomainName="NT AUTHORITY", SubjectLogonId="0x3e5", SubjectUserName="LOCAL SERVICE", SubjectUserSid="S-1-5-19", Task="13312", TokenElevationType="TokenElevationTypeDefault (1)", ValidSignatureDate="False", Version="0", Zone="0"


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.0.0.58 Released

WLS 3.0.0.58 has been released!

New Features

Database alternate location

An alternate DB location can now be specified.

Decoding for provider message IDs

Some Vista+ logs contain values that start with %%. These can now be optionally decoded and added as a field or replace the %% values.

Disk space limits

A minimum disk space may now be specified, and if the disk space falls below the threshold, WLS will stop queuing logs and send a notification directly to the syslog server. Normal behavior will resume when disk space returns above the threshold.

Enhanced network interface logs

Logging of network interfaces on start-up and after a network change now includes more data about each adapter.

Legacy log parsing

Optionally now include the remaining log data from XP logs after all replacement strings have been parsed.

MemberName resolution

When a user is added or removed from a group, the log did not always contain the user name. Now when a log contains MemberSid but not MemberName, WLS will fill-in MemberName.

Workstation IP resolution

Disabling workstation IP resolution for logs containing WorkstationName is now an option.

Improvements

CommandMonitor

CommandMonitor now includes the user name associated with each command.

DebugMode

When debugging interactively, output now includes greater detail.

JSON

JSON output has been improved.

Rewritten log parsers and db caching

Faster parsers for XP and Vista+. Higher concurrency log processing through the caching database.

SessionMonitor

SessionMonitor now caches information where applicable to maintain user tracking.


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.0.0.57 Released

WLS 3.0.0.57 has been released!

New Features:

Command Monitor

As detailed in a previous post, commands entered at the command prompt are now monitored and reported along with the cmd.exe process ID. This includes tracking the last command added and last command displayed; if command processes exist when WLS is started, all existing commands will be logged, then as they change.

Drive Monitor

Monitor removable drive file system changes; monitor fixed disk file system changes by interface type (1394, IDE, SCSI, USB); optionally log the interactive user

Licensing

License information must now be entered for WLS to run.

Log Backfill

When enabled, Event Logs generated while WLS was not running (OS startup, shutdown, etc.) will be processed on WLS startup. On the first run, no logs are backfilled.

Session Monitor

When running as a service as LocalSystem (normal operation), user session changes will be logged. The logs will be tagged with WLS_SessionMonitor and include the session ID and associated user. This includes ConsoleConnect, ConsoleDisconnect, RemoteConnect, RemoteDisconnect, SessionLock, SessionLogoff, SessionLogon, SessionRemoteControl, and SessionUnlock.

Signed Binary Detection

Signed binary detection by catalog. Previously files were only checked for an embedded signature; now if a file’s hash is included in a signature catalog, the Signed flag will be set to Catalog. Signed flag options are now Catalog, False, True.

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.

Monitoring command line executions

A new feature coming to WLS is the ability to monitor commands executed at the command prompt. Using methods similar to Volatility’s cmdhistory.py and Extracting Windows Cmd Line Details from Physical Memory (pdf), commands and their associated cmd.exe PID can now be logged in near real-time.

Update: Here’s a video showing the results:

On WIndows XP, each cmd.exe process has it’s history stored in csrss.exe, which you can see using Process Explorer or Process Hacker:

csrss

On Windows Vista+, each cmd.exe process has it’s own conhost.exe:

conhost

The only correlation (that I could find) between the cmd.exe process and the process that holds it’s command history, is that csrss.exe / conhost.exe has an open handle to the associated cmd.exe process.

Finding the handle

NtQuerySystemInformation is used to obtain a list of handle entries which contain: OwnerPID, ObjectType, HandleFlags, ObjectPointer, and AccessMask. Each entry is checked for an ObjectType of Process, an OwnerPID belonging to csrss.exe / conhost.exe and a HandleValue that references a cmd.exe process. The HandleValue will be used to correlate this entry with a command history structure.

Finding the history structure

Scanning for the command history structure in memory involves searching for a known value, typically the maximum command history, then checking if the data surrounding it matches the structure definition. Invariably there will be false positives which can mostly be weeded out by value checking the first four values in the structure, and that the pointer in the structure points to it’s start address. This structure also contains the process handle value found in the handle entry above.

Address Description
x86 x64
0x00 0x00 Command Count (0 – Max)
0x02 0x02 Last Added (0 – Max)
0x04 0x04 Last Displayed (0 – Max)
0x06 0x06 First Command (0 – Max)
0x08 0x08 Max History
0x0C 0x10 Virtual Address / Handle
0x10 0x18 Pointer to this structure @ 0x00
0x14 0x20 Pointer to this structure @ 0x00

Now there is a 1:1 relationship between a cmd.exe instance and the command history in memory. Aside from the obvious benefit of knowing the ProcessId, scanning memory for new structures is no longer needed once each relationship is known, eliminating the most resource intensive part of the monitoring process.

Example!

cmd.exe opened with a ProcessId of 8884 (0x22B4), conhost.exe 14868 (0x3A14) has it’s command history.

cmd_open

conhost2

A handle entry scan returns an entry with an OwnerPID matching that of conhost.exe and an ObjectType of 0x07, which is a Process on Vista+. The cmd.exe PID is obtained by duplicating the handle in HandleValue and calling GetProcessId. Since OwnerPID equals 0x3A14 and the value returned from GetProcessId is 0x22B4, we have a match.

AccessMask: 0x1FFFFF
HandleFlags: 0x00
HandleValue: 0x94
ObjectPointer:&HFFFFFA8010AEB170
ObjectType: 0x07
OwnerPID: 0x3A14

A memory scan for the max history value (typically 0x32) finds the following structure, indicating 1 executed command, a virtual address of 0x94 which matches the HandleValue above, and two pointers that correctly identify the location in memory of the structure.

Address Value Description
0x00 0x01 CommandCount
0x01 0x00 CommandCount
0x02 0x00 LastAdded
0x03 0x00 LastAdded
0x04 0x00 LastDisplayed
0x05 0x00 LastDisplayed
0x06 0x00 FirstCommand
0x07 0x00 FirstCommand
0x08 0x32 MaxHistory
0x09 0x00 MaxHistory
0x0A 0xEF
0x0B 0xFF
0x0C 0xFC
0x0D 0xFC
0x0E 0xFC
0x0F 0xFF
0x10 0x94 VirtualAddress
0x11 0x00 VirtualAddress
0x12 0x00 VirtualAddress
0x13 0x00 VirtualAddress
0x14 0x00 VirtualAddress
0x15 0x00 VirtualAddress
0x16 0x00 VirtualAddress
0x17 0x00 VirtualAddress
0x18 0x78 StructurePointer1
0x19 0xE8 StructurePointer1
0x1A 0x16 StructurePointer1
0x1B 0x00 StructurePointer1
0x1C 0x00 StructurePointer1
0x1D 0x00 StructurePointer1
0x1E 0x00 StructurePointer1
0x1F 0x00 StructurePointer1
0x20 0x78 StructurePointer2
0x21 0xE8 StructurePointer2
0x22 0x16 StructurePointer2
0x23 0x00 StructurePointer2
0x24 0x00 StructurePointer2
0x25 0x00 StructurePointer2
0x26 0x00 StructurePointer2
0x27 0x00 StructurePointer2

The next section of the command history structure contains a list of pointers to simple structures containing the length of the command and the command itself in unicode.

0x28 &H70 Command1
0x29 &HDA Command1
0x2A &H16 Command1
0x2B &H0 Command1
0x2C &H0 Command1
0x2D &H0 Command1
0x2E &H0 Command1
0x2F &H0 Command1

The structure found by following the pointer above correctly indicates a length of 14 and the unicode encoded command “echo hi”, which was the command executed.

Address Value
0x00 0x0E 14
0x01 0X00
0x02 &H65 e
0x03 &H00
0x04 &H63 c
0x05 &H00
0x06 &H68 h
0x07 &H00
0x08 &H6F o
0x09 &H00
0x0A &H20
0x0B &H00
0x0C &H68 h
0x0D &H00
0x0E &H69 i
0x0F &H00

cmd

The resulting log from WLS looks like this:

2013-10-27T12:28:43-05:00 [pc] WLS_CommandMonitor: LogType=”WLS”, Command=”echo hi”, ProcessId=”0x22b4″, Type=”Executed”

WLS tracks the LastAdded and LastDisplayed values, and logs them when a change occurs, noting the Type in the log entry. Here I entered some more commands, arrowed up through history, then appended a character to a previous entry and executed it.

2013-10-27T13:28:30-05:00 [pc] WLS_CommandMonitor: LogType=”WLS”, Command=”echo hi2″, ProcessId=”0x22b4″, Type=”Executed”

2013-10-27T13:28:32-05:00 [pc] WLS_CommandMonitor: LogType=”WLS”, Command=”echo hi3″, ProcessId=”0x22b4″, Type=”Executed”

2013-10-27T13:28:33-05:00 [pc] WLS_CommandMonitor: LogType=”WLS”, Command=”echo hi2″, ProcessId=”0x22b4″, Type=”Displayed”

2013-10-27T13:28:37-05:00 [pc] WLS_CommandMonitor: LogType=”WLS”, Command=”echo hi24″, ProcessId=”0x22b4″, Type=”Executed”

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.