Skip navigation
All Places > Products > RSA NetWitness Platform > Blog > 2017 > November

Malspam activity was observed on November 28th delivery a variant of Slingup backdoor. In this blog post, we will go over the network activity in RSA NetWitness Packets.


Submitting the delivery document (purchase order.doc) to RSA pre-release What's This File service scores the maximum threat score:



The embedded obfuscated VBA code launches upon opening the document:




The VBA code launches powershell to download an executable from a delivery domain:






According to VirusTotal scan results, the downloaded binary is a Slingup backdoor variant. Microsoft Windows Defender Security Intelligence has more information on the malware here.


When the malware runs on the infected system, it looks to be reaching out to the delivery domain to download more plugins. While the filename varies from one GET request to another, the directory remains the same /Panel/plugins/:



The server responds with obfuscated payloads as shown below:






  • purchase order.doc (SHA256):

  • loader.exe (SHA256):


All the IOC from those HTTP sessions were added to RSA FirstWatch Command and Control Domains on Live with the following meta:

  • threat.source = ‘rsa-firstwatch’
  • threat.category = ‘malspam’
  • threat.description = ‘delivery-domain’


It was amazing to me to see so many Compliance, Risk and Security professionals in one place, learning from subject matter experts and from each other through technical deep dives and business-driven use cases focused on delivering best practice and lessons learned.  I had the opportunity to speak with so many RSA customers and was inspired by the great work they are doing.    


One of the highlights of the event was that over 100 RSA customers got up on stage during Charge to present their unique use case and the challenges and opportunities they have addressed with the help of RSA solutions.  Thank you for sending us your feedback; it is great to see that overall you felt that the sessions were impactful and of value. 


During Charge you completed evaluations for the sessions that you attended.  These provide us great information, including what sessions you enjoyed the most – you confirmed that one presentation from each RSA Suite clearly stood out as being the BEST! 


Out of 92 outstanding Breakout sessions that took place on Wednesday, October 17 and Thursday, October 18 winners were selected by RSA Charge 2017 attendees for being best overall in:


  • Overall Value
  • Presentation Skills
  • Credibility/Knowledge
  • Engaging/Interactive
  • Avoided Commercialization
  • Relevance


We would like to announce, recognize and sincerely thank the recipients of the RSA CHARGE 2017 Best in Show Award:


            RSA Archer Suite Best in Show Award:

Deanne Dinslage, Sr. Archer Systems Administrator, Assistant Vice President, Bank of the West & Andrea Dollen, Manager, True8 Solutions            

Beyond the Customer - Making RSA Archer Suite Work for YOU! - Tired of hours of documentation for minutes of build?  Let me show you how to use RSA Archer Suite to do this in a few clicks with better results!


RSA Fraud & Risk Intelligence Suite Best in Show Award:

Damon Marracini, Vice President, Citi; Michael O’Connor, eCommerce Principal Product Marketing Manager, RSA; Greg Zaharchuk, Fraud Investigator, Vanguard; Qasim Zaidi, Cyber Process Manager, Capital One; Alma Zohar, Web Threat Detection Product Manager, RSA

Tales from the Trenches: Using Web Threat Detection to Fight Fraud - Learn how RSA Web Threat Detection is helping customers fight real-world cyber fraud.


RSA NetWitness Suite Best in Show Award:

Sean Catlett, SVP, Emerging Services, Optiv

Building a Modern Security Program:  Or… “If I Had to Start Over, What Would I Do?” – Discussion on keys to building your SOC and defending your enterprise using orchestration and automation.


RSA SecurID Suite Best in Show Award:

Michael Duncan, Program/Process Manager, Ameritas Life Insurance Corp; Lisa Ferraro, Developer, Ameritas Life Insurance Corp; Ravi Makam, Principal Consultant, Optiv

Insights and Lessons Learned from Upgrading RSA Identity Governance and Lifecycle and Going Virtual - Ameritas Life Insurance Corporation and Optiv Discuss Upgrading to RSA Identity Governance and Lifecycle Version 7.0.1 and go from a hard appliance to VM's to take advantage of new product capabilities.


Congratulations to all the Best in Show Award winners – RSA Charge 2017 attendees selected these from over 92 sessions!  Great job and thank you!



Pooja Haveri

RSA LogParserDiffTool

Posted by Pooja Haveri Employee Nov 14, 2017

The "Log Parser Diff Tool" is a newly developed tool, by request of our customers, that performs a “difference” operation between any 2 log parsers and produces the result as an html report. The report shows the newly added, updated and deleted headers and message id’s in the parser.


The differences found could be in content definition, functions used in a message or content definition in a header. All of the differences in the value-map section of the parser is also listed.


A user can run the LogParserDiffTool on Microsoft Windows and Apple Mac systems. You must have a version of Python 3 running on your system in order to properly run the tool. You can download Python version 3 here:


Please visit the following sites for more details about using Python in Windows or Apple environments:




Syntax for the Log Parser Diff Tool:

A user invokes the tool slightly different based on the OS where the Python script is being run. 


For example:

On a Mac, the syntax is as follows:

$ python3 <old> <new> [-all]


On Windows, the syntax is as follows:

c:\> <old> <new> [-all]


c:\> python3 <old> <new> [-all]


<old>: Older version of the parser information. It can be a file or the envision content.

<new>: Newer version of the parser information. It can be a file or envision content.


Note: It is important to maintain the parameter expectation of old followed by new ( <old> <new>)



<old> and <new> argument can be the following:

  1. Netwitness /etc folder in the Log Decoder  
  2. Individual Parser files (in *.envision Format when downloaded from Live)
  3. Individual Parser files (in *msg.xml Format)
  4. Table-map xml files can also be compared.


To use the script, you need two of the same items from the above list, one to serve as a baseline (old), and one to serve as the updated version (new) that contains XML differences from the baseline version. 


Without the -all argument, some devices which are mentioned below, will be excluded to reduce execution time and output file size.  These devices are typically signature-based with large and frequent updates; hence their content updated will not be included in the output report unless the user uses the -all argument. 

  1. Ciscoidsxml
  2. dragonids
  3. intrushield
  4. iss
  5. netscreenidp
  6. snort
  7. tippingpoint


You can include these event sources in the report by specifying the -all parameter when you run the script.


Examples of How to Use the Tool:


Example 1

This example assumes:

  • You have two copies of ciscoasamsg.xml, from two different releases.
  • You have placed the older copy (the one from the earlier release) into a folder named 83.
  • You have placed the newer copy (the one from the later release) into a folder named 84.

In this situation, if you are using a PC, you open a Command Prompt and run the following:

c:\temp> $ 83\ciscoasamsg.xml 84\ciscoasamsg.xml

Running this command generates a report that contains the differences (if any) for the ciscoasamsg parser.


Example 2

This example assumes:

  • You have two copies of table-map.xml, from two different releases.
  • You have placed the older copy (the one from the earlier release) into a folder named 83.
  • You have placed the newer copy (the one from the later release) into a folder named 84.

In this situation, if you are using a PC, you open a Command Prompt and run the following:

c:\temp> $ 83\table-map.xml 84\table-map.xml

Running this command generates a report that contains the differences (if any) between the two versions of the tablemap.xml file.


Example 3

This example assumes:

  • You have two copies of ciscoasamsg.envision, from two different releases.
  • You have placed the older copy (the one from the earlier release) into a folder named 83.
  • You have placed the newer copy (the one from the later release) into a folder named 84.

In this situation, if you are using a PC, you open a Command Prompt and run the following:

c:\temp> $ 83\ ciscoasamsg.envision 84\ ciscoasamsg.envision

Running this command generates a report that contains the differences (if any) between the two versions of the ciscoasamsg.envision parser.


Example 4

This example assumes:

  • You have two copies of unzipped envision files in the Log Decoder Directory Structure (…/etc/devices), from two different releases or Log Decoders where there are multiple parsers
  • You have placed the older copy (the one from the earlier release) into a folder named old
  • You have placed the newer copy (the one from the later release) into a folder named new

In this situation, if you are using a PC, you open a Command Prompt and run the following:

c:\temp> $ old\  new\

Running this command generates a report that contains the differences (if any) between the multiple parsers of different versions.


This new tool can come in very handy, as all the necessary changes made can be viewed in a single report, which are demonstrated in the images below.


Sample Reports:


Multiple Parsers report:


Overall Result:

Detailed Header Results:


Detailed Message Results:


Detailed ValueMap Results:

We hope you find this tool useful and welcome any feedback or suggestions for improvement. Please feel free to leave any constructive feedback in the comments below and if you have any questions, please reach out to


Assisted by

Saket Bajoria

The RSA NetWitness Meta Dictionary is a tool developed for describing metadata used in RSA NetWitness Log Parsers.  The RSA NetWitness Log Decoder supports over 300+ unique log event sources.  Each log event source has a respective log parser for parsing the content of each log.  The Meta Dictionary tool describes the metadata used in each of the parsersd.


This blog post is intended to help a user understand how to use the tool so they can see the various metadata used in a parser, description of each of the metadata keys and the number of times each metadata keys appear in a parser.



 You need to download the following attachments from the blog post:

  • data.meta file
  • metadictionary.html file


Supported Browsers

  • Google Chrome version 44 or later
  • Firefox version 36 or later
  • Internet Explorer 10 or later
  • Safari version 7 or later


Viewing Meta Data Definitions

  Once you open metadictionary.html file in a browser you will see something similar to the screenshot below.

The screen contains the following sections:

  • Left Navigation pane: contains a list of all the parsers.
  • Details pane: contains the meta details for the selected parser.


This tool offers the flexibility to search for meta keys, data type, etc. as shown in the image below.

In the above screen, we have searched for ipv4, and three occurrences were found; note that the search is case insensitive.


Screen Reference















Parser Name/Version



Left Navigation Pane, and Details Panedisplays Parser Name and Version








A free text search box that you can use to filter results








Show/Hide Columns



Drop down menu from each Column Header allows you to display or hide column




Column Reference

The following table describes each of the available columns that contain the meta data for the parsers.


Column Name


Investigation Display Name

The value displayed in Investigation Page of RSA NetWitness  UI for each Meta

Parser Metakey(occurrences)

Meta key as used in the Parser and its count in parenthesis. For example, for the


aix parser, the saddr meta key occurs 151 times in the parser definition

SA Metakey

Corresponding Meta Name for the meta key in parser definition. Meta Name is used


in RSA NetWitness  Suite

Metakey Description

The description for the key.


The data type of a meta key, as listed in the default table map.xml.

TableMap Indexed

Whether or not the key is indexed in the table map.


The following examples show the table map details for indexed


and non-indexed meta:
















Not Indexed: <mapping












Whether or not the key is available in the default index-concentrator.xml.


We hope you find this tool useful and welcome any feedback or suggestions for improvement.  Please feel free to leave any constructive feedback in the comments below!

While threat hunting, RSA FirstWatch came across a curious exposure in Windows PCs, involving driver packages provided by a certain manufacture of audio streaming controllers.  These USB audio streaming controllers are found in third-party hardware products used principally by audiophiles and PC game enthusiasts.  Distributed between 2013 and 2017, packages from this chip maker were observed to silently install a self-signed root certificate into the PC’s Trusted Root Certification Authorities store.


The purpose of this post is to briefly describe the exposure of what we have nicknamed “Inaudible Subversion,” discuss root certificate store subversion exposure in the context of NetWitness visibility, and provide remediation steps should you be an audiophile or gamer with an exposed PC.  In the big picture of things, we think that Inaudible Subversion may be a vulnerability of low--if any--consequence, but illustrates the influence of market forces behind hardware vendor sustainment of a still-popular operating system that is no longer supported by Microsoft.


Through reach-out via trusted partners, we established contact with the chip maker who acknowledged the problem, and who then began providing updated driver packages to many of its affected third-party hardware vendors, at least a dozen of which we had identified.  The new driver packages no longer have the root certificate installing routine, at the cost of no longer supporting Windows XP.  Still the updated driver packages do not remove the root certificate(s) in question, which is why we are providing remediation steps necessary at the end of this post.  Mitre assigned this exposure the identifier CVE-2017-9758, but was initially tracked by HITCON ZeroDay project as ZD-2017-00386


Problem details

FirstWatch found that specific driver installer packages provided by Savitech to their hardware vendor customers for distribution to end users, silently installed a SaviAudio root certificate into the PC’s Trusted Root Certification Authorities store (simply: trusted root store). When we say “silently” we mean that the driver installer package installs a self-signed SaviAudio root certificate to the PC’s trusted root store and Trusted Publishers stores, prior to the standard dialog box presented to the user confirming a driver (and trusted publisher certificate if so checked) to be installed (Figure 1). 


SaviAudio self-signed root certificate installed prior to Windows Security dialog box

Figure 1 SaviAudio self-signed root certificate installed prior to Windows Security dialog box


Checking the “Always trust software from [publisher name]” check box would normally be required, prior to a program installing a certificate in to a PC’s trusted publishers store. In our testing, checking the “Always trust software from Savitech Corp.” box in the driver installer routine would install a valid Savitech Corp. Verisign-issued certificate into the trusted publishers store, with the previously “silently” installed self-signed SaviAudio certificate (Figure 2).


Valid Verisign-issued certificate added to same store as the self-signed certificate

Figure 2 Valid Verisign issued certificate added to same store as the self-signed certificate


The executable responsible for the SaviAudio self-signed certificate install, SwCoInst.exe, is named the same in each MSI file package FirstWatch was able to find. It is sometimes branded with the Savitech hardware vendor’s name in the executable file properties. The SwCoInst.exe executable writes the SaviAudio certificate file NewCert.cer, as well as a valid 2009 version of Microsoft’s Certificate Manager tool, CertMgr.exe, embedded inside (Figure 3). Prior to the completion of the driver package installer routine, CertMgr.exe and NewCert.cer are deleted from the program’s folder.


Three components responsible for root store subversion function in affected Savitech driver packages

Figure 3 Three components responsible for root store subversion function in affected Savitech driver packages



An arbitrary certificate added to a Windows trusted root store, breaks the hierarchical trust model of Windows, giving significant power to the owner of the private key corresponding to that certificate, the same as any Certificate Authority (CA) behind certificates normally found on Windows systems.  Usually, only a certificate issued by Microsoft would have “All” in the root certificates Intended Purposes field.  Note: many large enterprises will typically install an “All” purposes root certificate on their Windows PCs to perform SSL decryption at the perimeter for outbound traffic, for network defense purposes, but that is typically the only exception.


An attacker who is able to obtain the corresponding private keys used to create the two known Savitech “SaviAudio” root certificates can generate any number of certificates signed by the otherwise untrusted Savitech private key.  Any system installing the Savitech drivers from any one of many vendors will trust any certificate issued by the SaviAudio CA, for “All” purposes. An attacker may spoof web sites and other online services and applications, sign software and email, as well as decrypt network traffic. Common attack scenarios include impersonating a web site, performing a Man-in-the-Middle (MITM) attack to decrypt HTTPS traffic, and installing malicious software.

In best-case scenarios, Inaudible Subversion is a minor exposure

We assess that the Savitech driver developers were conscious of the affect of driver warning alerts for XP users[i], and subsequently came up with a clever way to seamlessly support Windows XP through Windows 10, using a single driver package, without increasing support calls to their hardware vendors. In spite of being officially un-supported by Microsoft for years, Windows XP is still a rather popular operating system, especially in Asia[ii], and that might generate some substantive demand from end users of Savitech products.  On the other hand, users of Windows XP with even the latest available patches[iii] are already facing such security challenges that a self-signed certificate for which the private key is hopefully carefully guarded by Savitech, provides negligible additional exposure. There are notable incidents[iv][v] where the extractability of corresponding private keys made such kind of exposure much more serious, but this is not the case with the Savitech root certificates.


The crux of the issue is that the workaround specifically designed to accommodate the demand for hardware support for an operating system no longer supported by Microsoft, also effects any other Windows operating system on which the driver installer package is run.  This is the case with the affected all-in-one driver packages from Savitech, which do not discriminate by Windows version in their root store subversion routine.  Which means the exposure to a much more secure operating system than Windows XP, from a subverted trusted root certificate store, probably exceeds a negligible level.


In our testing with actual audio hardware purchased from a Savitech vendor, removing the SaviAudio root certificates from our test Windows XP laptop after the Savitech hardware drivers had been successfully installed, caused no issues. Our test PC with Savitech hi-fi system[vi] worked perfectly at the extremely high 352.8 khz sampling rate of our test audio file, the same as before the root certificate was removed (Figure 4).  And we confirmed that the root certificate was not needed for installing the Savitech drivers for any other Windows version besides Windows XP.


Demonstration that Savitech hardware drivers on Windows XP worked perfectly with SaviAudio root certificate removed

Figure 4 Demonstration that Savitech hardware drivers on Windows XP worked perfectly with SaviAudio root certificate removed


If given the chance, we would pass on to Savitech that they do not necessarily need to stop supporting Windows XP. However, we suggest that they provide a completely separate driver installer package for Windows XP, than for other supported Windows OSs.  Additionally, Savitech should specifically modify the Windows XP driver package installers so that the SaviAudio certificate is removed from the PC’s trusted root store after the drivers have been installed. To caveat our suggestions, we have not tested multiple hardware platforms or the root certificate removal’s compatibility with the SaviAudio mobile applications[i][ii] that can control Savitech PC audio hardware over the network.

So why should we care about an inadvertent vulnerability from a friendly audio chipmaker?

If we have written this much about a nearly inconsequential vulnerability on an RSA product-focused site, you might figure that there is a product tie-in.  And you would be right. In fact, it was Inaudible Subversion research that got multiple analysts and engineers at the RSA NetWitness team pondering.  Specifically, we pondered on the consequences of not being able to observe a self-signed root certificate being maliciously installed in a PC’s trusted root store.  One only needs to point to some notable crimeware campaigns to realize that the consequences could be significant.


Consider the Retefe Banking Trojan campaign[i] as investigated by Palo Alto Unit 42 in 2015.


Retefe uses the Windows PowerShell to execute a series of commands that installs a new root certificate on the system and a proxy configuration to re-route the traffic to the targeted banking websites.

The Retefe Trojan writes the root certificate to the disk and then uses the following command to install it on the system.

certutil -addstore -f -user ROOT ProgramData\cert512121.der


Avast also investigated a Retefe campaign[i] in 2016 with the same characteristic subversion of the target PC’s trusted root store.  FirstWatch also posted on a more recent Retefe campaign last month on RSA Link[ii], the malware of which also installed a fake but realistic-appearing certificate in the infected system’s trusted root store.   Finally, consider the RTM Banking Trojan as dissected by ESET in February of this year[iii]. RTM has a modular command switch specifically used to install a certificate into the infected PC’s trusted root store. 


With these malicious illustrations in mind, we know that it is important for an enterprise security team to be able to detect if a system’s root certificate store has been subverted. Currently, detecting a certificate being added to the trusted root store of a PC protected by NetWitness Endpoint, requires some extra configuration in NetWitness Logs, or Sysinternal Sysmon installed on a PC such that tracking events similar in resolution (Figure 5) to NetWitness Endpoint tracking logs, be sent to a NetWitness log decoder.


Sysmon logs showing root store subversion by Savitech self-signed certificate

Figure 5 Sysmon logs showing root store subversion by Savitech self-signed certificate


Client side Windows logging can be a mixed bag of Windows policies pushed by GPO or other endpoint tools that harvest these specific events.  If your Windows logging policy includes event ID Security/4688 (detailed tracking and audit process creation) you will be able to see these events but beware, event ID 4688 is very high volume.  If covering the endpoint with Sysmon is more your style, with the right template you will be able to capture the events via WMI into NetWitness logs under event ID sysmon/1 which look like Figure 5 above in event viewer and Figure 6 in NetWitness logs.


Sysmon event via NetWitness Logs

Figure 6 Sysmon event via NetWitness Logs


If you have NetWitness Endpoint and are pulling tracking data out via ODBC you will see events like Figure 7.


NetWitness Endpoint tracking data

Figure 7 NetWitness Endpoint tracking data


And if you have the latest NetWitness Endpoint 4.4 you can enable the meta integration service and get tracking data and more, which would get you information like Figures 8 and 9.


NetWitness Endpoint 4.4 meta integration

 Figure 8 NetWitness Endpoint 4.4 meta integration


NetWitness Event Analysis

Figure 9 NetWitness Event Analysis


Having the data available in one single interface is part of the solution, being able to alert on those events proactively is a much more scalable solution.  Using the Application rules below you can create proactive alerts for these events (the first three rules group Sysmon events, NW Endpoint ODBC and NWEndpoint events together).


name="endpoint-event-include" rule="device.type='nwe_tracking' && category='createprocess'" alert=analysis.session type=application


name="endpoint-event-include" rule="device.class='windows hosts' && ='1'" alert=analysis.session type=application name="endpoint-


event-include" rule="device.type='nwe_tracking' && category='createprocess'" alert=analysis.session type=application name="endpoint-event-include"


rule="device.type='nwendpoint' && action='createprocess'" alert=analysis.session type=application name=p3_certmgr-add-local-root-cert


rule="analysis.session='endpoint-event-include' && process ends '\\certmgr.exe' && (param contains '-add' || param contains '/add') && param contains


'localmachine'" alert=analysis.session type=application name=p3_certmgr-add-local-root-cert rule="analysis.session='endpoint-event-include' &&


filename.dst='certmgr.exe' && query contains '-add' && query contains 'localmachine'" alert=analysis.session type=application name=p3_certutil-add-


local-root-cert rule="analysis.session='endpoint-event-include' && filename.dst='certutil.exe' && query contains '-add' && query contains 'root'"


alert=analysis.session type=application


In this case the alert sends information to the Session Analysis metakey (analysis.session) which you could turn into an alert or include in a summary report to review on a daily basis.


Session analysis alert key for root certificate addition

Figure 10 Event Alert


The detection can be mapped to Mitre Att&ck  T1130[i] under Defense Evasion for install Root Certificate.


Not wanting to leave good enough alone, expect a part two to this blog post in the not so distant future.  We don’t think root certificate subversion is going away any time soon, and the subject needs more attention from us before we can rest at ease.



In the big picture of things, Inaudible Subversion might be considered an inconsequential vulnerability, as it effects principally audiophiles and video game enthusiasts of third party hardware vendors.  We also presume that the not insignificant die-hard base of Windows XP users has more pressing security concerns with their PC, than a self-signed root certificate from their friendly audio manufacturer.  While the root certificate routine in these driver packages is not limited to running on Windows XP, additional testing showed that removing the self-signed certificate from the Trusted Root Certification Authorities store did not cause any issues, even on Windows XP.  The certificate was only “needed” during the time that the Windows XP drivers were installed, and on our test platform, the audio hardware worked fine when the self-signed certificate was subsequently removed from the PC.


To Microsoft’s chagrin, we think that the manufacturer would be able to safely support their base of Windows XP users, by including the drivers for Windows XP in an installer package separate from the installer package for Windows 7/8.x/10.  Also, in the separate Windows XP package, they could provide a simple routine to remove the self-signed certificate, following the driver installation.   


Finally, we got to the point of our product-tied post, which is making sure that you can see when someone other than a friendly audio maker subverts a PCs root certificate store.  While we can currently guide you on making your NetWitness products “root subversion ready,” we pledge that it needs to be more out of the box.  So we are working on it.


This post was made possible by special contributions from Eric Partington.


FirstWatch would like to thank Ziv Chang of Trend Micro, Allen Own of HITCON ZeroDay, Asus Product Security Team, EMC Product Security Response Center, and CERT/CC for their assistance.




















Filter Blog

By date: By tag: