Skip navigation
All Places > Products > RSA NetWitness Platform > Blog > 2019 > March > 11

A question was posed to our team by one of the engineers; had we seen the new Chrome and Microsoft zero-day exploits using RSA NetWitness Endpoint?  I honestly didn't even know about these exploits and so I had to do some research.  I found the initial Google Blog post here: Google Online Security Blog: Disclosing vulnerabilities to protect users across platforms.  The first vulnerability (NVD - CVE-2019-5786) is the Google Chrome vulnerability and the second was disclosed to Microsoft by Google but as of the time I am writing this, no patch had been released by Microsoft.


Other articles and blogs that talk about these zero-days say they are being used in conjunction with each other. There was no proof of concept code nor any exploits I could use from the research I did. I did see some articles talking about these being exploited in the wild but I couldn’t find any other details. The second zero day is a Windows 7 32 bit privilege escalation vulnerability which does a null pointer dereference in win32k.sys. I found a similar privilege escalation exploit for CVE-2014-4113 and successfully exploited a box in my sandbox environment while it had an NetWitness Endpoint agent on it. The two IIOCs that fired that would help detect this attack were:


IIOC 1 - “Creates process and creates remote thread on same file”
IIOC 2 - “Unsigned creates remote thread”


The remote thread in this case was on notepad.exe which is common of Meterpreter.


The exploit I used can be found here: It also does a null pointer dereference in win32k.sys similar to the Microsoft zero-day.  Below are some screenshots of what I saw from the attacker side and the NetWitness Endpoint side.


Here you can see the the exploit being injected in process ID 444.



Here is the entry in RSA NetWitness Endpoint.



Another entry is lsass.exe opening notepad.exe after the remote thread creation.  I believe this is the actual privilege escalation taking place.  It also makes sense because the timestamp matches exactly to the timestamp in Kali.



Here are the IIOCs which I believe are the initial meterpreter session based on timestamps.   It's still an indication of suspicious activity and when combined with lsass.exe opening the same remote thread process, it raises even more alarms.



I gave this to the engineer in hopes that the new Microsoft zero-day could be detected in the same way and even though we don't know the details of the Google Chrome vulnerability, we do know they are being exploited together.  This could help possibly identify this attack that has been seen in the wild.  Also, on another note, the fact that two zero-days are being exploited in the wild together just screams of a well-funded advanced adversary and it's a relief to know that our tool out-of-the-box should be able to help find this type of activity.

In line with some of my other integrations, I recently decided to also create a proof-of-concept solution on how to integrate RSA NetWitness meta data into an ELK stack.


Given that I already had a couple of Python scripts to extract NetWitness meta via the REST API, I quickly converted one of them to generate output in an ELK-friendly format (JSON).


Setting up an ELK instance is outside the scope of this post, so with that done all I needed was a couple of configuration files and settings.


Step #1 - Define my index mapping template with the help of curl and the attached mappings.json file.

curl -XPUT http://localhost:9200/_template/netwitness_template -d @mappings.json

NOTE: The mappings file may require further customization for additional meta keys you may have in your environment.


Step #2 - Define my Logstash configuration settings.

# Sample Logstash configuration 
# Netwitness -> Logstash -> Elasticsearch pipeline.

input {
  exec {
    command => "/usr/bin/python2.7 /usr/share/logstash/modules/ -c https://sa:50103 -k '*' -w 'service exists' -f /var/tmp/nw.track "
    interval => 5
    type => 'netwitness'
    codec => 'json_lines'

filter {
   mutate {
      remove_field => ["command"]

output {
  elasticsearch {
    hosts => ["http://localhost:9200"]
    index => "netwitness-%{+YYYY.MM.dd}"

Again a level of ELK knowledge will be required that is outside the scope of this post. However, on the command section a few settings may require additional clarification, the Python code has them documented but for ease of reference, I'm listing them below:


  1. The REST endpoint from where to collect the data
  2. The list of meta keys to retrieve (in the example below '*' refers to all available meta keys)
  3. The SDK query that references the sessions that should be retrieved (in the example below, collect all "packet sessions" meta data)
  4. A tracker file location so only new data is retrieved by each execution on the input command. (i.e. continue from last data previously retrieved)
-c https://sa:50103 
-k '*'
-w 'service exists'
-f /var/tmp/nw.track


There will be additional configuration settings and steps required in ELK, once again, there's plenty of information available on this already as the open source solution that ELK is, so I won't go into that. I'm by no means an expert on ELK.


Finally, all that is left to show you is how the data looks. First, some of my Dynamic DNS events.


List of NetWitness Events in ELK


Below the details of one of those events.

 DynDNS Event Details



As a proof-of-concept all these details and scripts are provided as-is without any implied support or warranty. I'm not really that experienced in ELK as so I'm sure that someone can probably improve on this significantly, if you do feel free to share your experiences below in the comments section.


Thank you,



Filter Blog

By date: By tag: