Windows Event Channel misinterpreted event strings

154 views
Skip to first unread message

MC

unread,
Apr 5, 2019, 6:17:15 AM4/5/19
to Wazuh mailing list
Hi guys,
I found something that could be a possible bug. 

When I run
REG QUERY /?

in the Windows command line, I can see the following generated Event with ID 4688 under Security Channel:

  <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-a5ba-3e3b0328c30d}" />
  <EventID>4688</EventID>
  <Version>2</Version>
  <Level>0</Level>
  <Task>13312</Task>
  <Opcode>0</Opcode>
  <Keywords>0x8020000000000000</Keywords>
  <TimeCreated SystemTime="2019-04-05T09:48:59.470586600Z" />
  <EventRecordID>60680289</EventRecordID>
  <Correlation />
  <Execution ProcessID="4" ThreadID="22988" />
  <Channel>Security</Channel>
  <Computer>xxx.xxx.xx</Computer>
  <Security />
 </System>
- <EventData>
  <Data Name="SubjectUserSid">S-1-5-21-1025743433-2324990899-3972942523-26050</Data>
  <Data Name="SubjectUserName">xxx.xxx</Data>
  <Data Name="SubjectDomainName">xxxx</Data>
  <Data Name="SubjectLogonId">0x112f27</Data>
  <Data Name="NewProcessId">0x549c</Data>
  <Data Name="NewProcessName">C:\Windows\System32\reg.exe</Data>
  <Data Name="TokenElevationType">%%1937</Data>
  <Data Name="ProcessId">0x42f8</Data>
  <Data Name="CommandLine">REG QUERY /?</Data>
  <Data Name="TargetUserSid">S-1-0-0</Data>
  <Data Name="TargetUserName">-</Data>
  <Data Name="TargetDomainName">-</Data>
  <Data Name="TargetLogonId">0x0</Data>
  <Data Name="ParentProcessName">C:\Windows\System32\cmd.exe</Data>
  <Data Name="MandatoryLabel">S-1-16-12288</Data>
  </EventData>
</Event>

As it's shown, the NewProcessName is obviously reg.exe.

But in Wazuh Manager logs (archives/archives.log), I receive the following message:

2019 Apr 05 11:49:00 (xxx) any->EventChannel {"EventChannel":{"System":{"ProviderName":"Microsoft-Windows-Security-Auditing","ProviderGuid":"{54849625-5478-4994-a5ba-3e3b0328c30d}","EventID":"4688","Version":"2","Level":"0","Task":"13312","Opcode":"0","Keywords":"0x8020000000000000","SystemTime":"2019-04-05T09:48:59.470586600Z","EventRecordID":"60680289","ProcessID":"4","ThreadID":"22988","Channel":"Security","Computer":"xxx.xxx.xxx","SeverityValue":"AUDIT_SUCCESS","Message":"È stato creato un nuovo processo."},"EventData":{"SubjectUserSid":"S-1-5-21-1025743433-2324990899-3972942523-26050","SubjectUserName":"xxxx.xxxx","SubjectDomainName":"xxx","SubjectLogonId":"0x112f27","NewProcessId":"0x549c","NewProcessName":"C:\\Windows\\System32\\eg.exe","TokenElevationType":"%%1937","ProcessId":"0x42f8","CommandLine":"REG  QUERY /?","TargetUserSid":"S-1-0-0","TargetUserName":"-","TargetDomainName":"-","TargetLogonId":"0x0","ParentProcessName":"C:\\Windows\\System32\\cmd.exe","MandatoryLabel":"S-1-16-12288"}}}

The NewProcessName is eg.exe, and it looks like has been interpreted the string '\r' as a special character, instead of a part of a string.

The same problem happens with the creation of the process of tor.exe, in the CommandLine field.
As it is shown below, the process tor.exe is "interpreted" as a special character \t.

2019 Apr 05 12:00:12 (xxxx) any->EventChannel {"EventChannel":{"System":{"ProviderName":"Microsoft-Windows-Security-Auditing","ProviderGuid":"{54849625-5478-4994-a5ba-3e3b0328c30d}","EventID":"4688","Version":"2","Level":"0","Task":"13312","Opcode":"0","Keywords":"0x8020000000000000","SystemTime":"2019-04-05T10:00:12.393674500Z","EventRecordID":"60685379","ProcessID":"4","ThreadID":"3036","Channel":"Security","Computer":"xxx.xxx.xxx","SeverityValue":"AUDIT_SUCCESS","Message":"è stato creato un nuovo processo."},"EventData":{"SubjectUserSid":"S-1-5-21-1025743433-2324990899-3972942523-26050","SubjectUserName":"xxxx","SubjectDomainName":"xxxx","SubjectLogonId":"0x112f54","NewProcessId":"0x91c","NewProcessName":"C:\\Users\\xxxx\\Desktop\\Tor Browser\\Browser\\TorBrowser\\Tor\\or.exe","TokenElevationType":"%%1938","ProcessId":"0x3c10","CommandLine":"\\\"C:\\Users\\xxxx\\Desktop\\TorBrowser\\Browser\\TorBrowser\\Tor\\or.exe\\\" --defaults-torrc \\\"C:\\Users\\xxxx\\Desktop\\Tor Browser\\Browser\\TorBrowser\\Data\\Tor\\orrc-defaults\\\" -f \\\"C:\\Users\\xxxx\\Desktop\\TorBrowser\\Browser\\TorBrowser\\Data\\Tor\\orrc\\\" DataDirectory \\\"C:\\Users\\xxxx\\Desktop\\Tor Browser\\Browser\\TorBrowser\\Data\\Tor\\\" GeoIPFile \\\"C:\\Users\\xxxx\\Desktop\\Tor Browser\\Browser\\TorBrowser\\Data\\Tor\\geoip\\\" GeoIPv6File \\\"C:\\Users\\xxxx\\Desktop\\Tor Browser\\Browser\\TorBrowser\\Data\\Tor\\geoip6\\\" HashedControlPassword16:dc2669676312c198603b0176fa2a7114a07e586f0a04c9486cffb83602 +__ControlPort 9151 +__SocksPort \\\"127.0.0.1:9150 IPv6Traffic PreferIPv6 KeepAliveIsolateSOCKSAuth\\\" __OwningControllerProcess 15376","TargetUserSid":"S-1-0-0","TargetUserName":"-","TargetDomainName":"-","TargetLogonId":"0x0","ParentProcessName":"C:\\Users\\xxxx\\Desktop\\Tor Browser\\Browser\\firefox.exe","MandatoryLabel":"S-1-16-8192"}}}




cris...@wazuh.com

unread,
Apr 8, 2019, 5:45:50 AM4/8/19
to Wazuh mailing list
Hi MC,

You are right, this is a known issue. Windows formats its messages with '\r', '\n' and '\t', which were escaped wrongly not to be shown at Wazuh alerts. You can find some more information at the Github issue https://github.com/wazuh/wazuh/issues/2715 as well as the associated PR. The fix will be released with version 3.9, Sorry for the inconveniences, I hope this can help you.

Kind regards,
Cristina
Reply all
Reply to author
Forward
0 new messages