Skip navigation
All Places > Products > RSA NetWitness Platform > Blog
1 2 3 Previous Next

RSA NetWitness Platform

516 posts

I have recently been posting a number of blogs regarding the usage of the RSA NeWitness Platform to detect attackers within your environment. As the list of the blogs grow, it is becoming increasingly difficult to navigate through them easily. In order to combat this, this blog post will contain references to all other blog posts in the Profiling Attackers Series, and will be updated when new posts are made.




WireGuard is a new open-source VPN protocol used to create point to point tunnels. It uses the most modern cryptographic protocols and it works on the network layer for both IPv4 and IPv6.
One of the advantages of WireGuard implementation is the size of it's code. It uses just 4000 rows of code, which is much smaller compared with openVPN or IPsec implementations.  Initially released for the Linux kernel, it is now cross-platform and widely deployable.  All these aspects make the WireGuard protocol a perfect software for those who need to create a secure channel.


Considered it's easy implementation and it's wide availability, I tried to create a parser to help to identify this type of traffic.


For our purpose we can ignore the header of the packet and concentrate on the payload data only.

first packet

From the payload analysis we see that the first packet starts with 01 00 00 00. The same pattern is used on the following packets, 02 00 00 00 on the response and 04 00 00 00 on the rest of the traffic.

second packet

third packet

If we cross reference this with Wireguard’s documented protocol, we can confirm that the data begins with an 8-bit pattern (0100 0000, 0200 0000, 0400 0000), so we can assume that these pattern will help to identify this type of traffic.


With some suggestion from Christopher Ahearn, I started to create my LUA parser.


The entry point for my parser is the token 01 00 00 00

    [nwevents.OnSessionBegin] = WireGuard.sessionBegin,
    ["\001\000\000\000"] = WireGuard.tokenMATCH, -- find the token 1 0 0 0

Once the token is identified inside a session, it's necessary to understand its position as we are looking for the payload that have that token on the first 4 bytes of the payload. 

function WireGuard:tokenMATCH(token, first, last)
    -- check if the token is on the first 4 bytes
    if first == 1 and last == 4 then

If this is the case, then I go to define the request stream and the response stream, then I look for the pattern that I identified before: 02 00 00 00 on first packet of the response stream and 04 00 00 00 on all the other packets.

if requestStream and responseStream then
    -- the first 4 bytes on the first packet response are 2 0 0 0
    if nwstream.getPayload(responseStream,1,4):find("\002\000\000\000",1,4) then
-- the first 4 bytes on the other packets are 4 0 0 0
if (nwpacket.getPayload(requestPacket,1,4):find("\004\000\000\000",1,4) and
    nwpacket.getPayload(responsePacket,1,4):find("\004\000\000\000",1,4)) then

If all the first 4 packets respect the pattern, it means that the analyzed session is a WireGuard session and the parser set the service type as 51820. WireGuard doesn't use a specific port for the communication, so i decided to use the 51820 because it's the value used on the configuration sample available on the WireGuard website.

nw.createMeta(self.keys.ioc, "WireGuard VPN")


Once I deployed the parser on the Network Decoder, it allows us to quickly identify if WireGuard VPN traffic is established on the network.



WireGuard is evolving and it is possible that something will change, but this parser can help to identify some VPN traffic that otherwise would not have been defined properly using RSA NetWitness.  


Lateral movement is a technique that enables an adversary to access and control remote systems on a network. It is a critical phase in any attack, and understanding the methods that can be used to perform lateral movement, along with how those protocols display themselves in NetWitness, is paramount in detecting attackers moving laterally in your environment. It is also important to understand that many of the mechanisms used by attackers for lateral movement, are also used by administrators for legitimate reasons, and thus why it is important to monitor these mechanisms to understand what is typical behaviour, and what is not.



In this blog post, Smbexec will be used. the Impackets implementation of Smbexec will be used. This sets up a semi-interactive shell for the attacker.


The Attack

The attacker has successfully gained access to your network and dumped credentials, all without any detection from your Security Operations Center (SOC). The attacker decides to move laterally using Smbexec, they connect to one of the hosts they had previously identified and begin to execute commands:


The Detection in NetWitness Packets

Smbexec works a little differently to some of the more common lateral movement tools such as PsExec. Instead of transferring a binary to the target endpoint and using the svcctl interface to remotely create a service using the transferred binary and start the service, Smbexec makes a call to an existing binary that already lives on that endpoint to execute its commands, cmd.exe.


NetWitness Packets does a great job at pulling apart packet data and pointing you in directions of interest. One of the metadata we can pivot on to focus on traffic that is of interest to us for lateral movement is, remote service control:


NetWitness also creates metadata when it observes windows cli commands being run, this metadata is under the Service Analysis meta key and is displayed as, windows cli admin commands. This would be another interesting pivot point for us to look into to see what type of commands are being executed:


NOTE: Just because an endpoint is being remotely controlled, and there are commands being executed on the endpoint, this does not mean that your network is compromised. It is up to the analyst to review the sessions of interest like we are in this blog post, and determine if something is out of the ordinary for your environment.


Looking into the other metadata available, we can see a connection to the C$ share, and that a filename called __output was created:


This does not give us much to go on and say that this is suspicious, so it is necessary to reconstruct the raw session itself to get a better idea of what is happening. Opening the Event Analysis view for the session we reduced our data set to, and analysing the payload, a suspicious string stands out as shown below:


Tidying up the command a little, it ends up looking like this:

%COMSPEC% /Q /c echo dir > \\\C$\__output 2>&1 > %TEMP%\execute.bat & %COMSPEC% /Q /c %TEMP%\execute.bat & del %TEMP%\execute.bat

  • %COMPSEC% - Environment variable that points to cmd.exe
  • /Q - Turns echo off
  • /C - Carries out the command specified by string and then terminates
  • %TEMP% - Environment variable that points to C:\Users\username\AppData\Local\Temp


We can see that string above will echo the command we want to execute (dir) into a file named "__output" on the C$ share of the local machine. The command we want to execute also gets placed into execute.bat in the %TEMP% directory, which is subsequently executed, and then deleted.


Analysing the payload further, we can also see the data that is returned from the command that was executed by the attacker:


Now that suspicious traffic has been observed, we can filter on this type of traffic, and see other commands being executed, such as whoami:


Smbexec is quite malleable, a vast majority of the indicators can easily be edited to evade signature type detection for this behaviour. However, using NetWitness Packets ability to carve out behaviours, the following application rule logic, should be suitable to pick up on suspicious traffic over SMB that an analyst should investigate to detect this type of behaviour:

(ioc = 'remote service control') && (analysis.service = 'windows cli admin commands') && (service = 139) && (directory = '\\c$\\','\\ADMIN$\\') 


The Detection in NetWitness Endpoint

NetWitness Endpoint does a great job at picking up on this activity, looking at the Behaviours of Compromise meta key, two pieces of metadata point the analyst toward this activity, services runs command shell and runs chained command shell:


Opening the Event Analysis view for these sessions, we can see that services.exe is spawning cmd.exe, and we can also see the command that is being executed by the attacker:


The default behaviour of Smbexec could easily be detected with application rule logic like the following:

param.dst contains '\\\C$\__output'


Understanding the Tools, Techniques, and Procedures (TTP's) used by attackers, coupled with understanding how NetWitness interprets those TTP's, is imperative in being able to identify them within your network. The NetWitness suite has great capabilities to pull apart network traffic and pick up on anomalies, which makes it easier for the analysts to hunt down and detect these threats.

In RSA NetWitness 11.3, one of the behind-the-scenes changes to the platform was moving the script notification server from ESA onto the Admin Server.


This change opens up a number of possibilities for scripting and automating processes within the NetWitness environment, but also requires a few changes to existing, pre-11.3 scripts.


Prior to 11.3, the raw alert data would be passed to the ESA script server as a single argument which could then be read, written to disk, parsed, etc. e.g.:


#!/usr/bin/env python 
import json
import sys

def dispatch(alert):
   with open("/tmp/esa_alert.json", mode='w') as alert_file:
      alert_file.write(json.dumps(alert, indent=True))

def myFunction():
   esa_alert = json.loads(open('/tmp/esa_alert.json').read())

if __name__ == "__main__":



But in 11.3, the raw alert gets broken up into multiple arguments that need to be joined together.  One possible solution to this change could be something like this:


#!/usr/bin/env python
import sys
import json

def dispatch():
   with open("/tmp/esa_alert.json", mode='w') as alert_file:
      a = sys.argv
      del a[0]
      alert_file.write(' '.join(a))

def myFunction():
   esa_alert = json.loads(open("/tmp/esa_alert.json").read())

if __name__ == "__main__":


As I mentioned above, moving the script server onto the Admin Server opens up a number of possibilities for certain queries and tasks within the NW architecture.  Some that come to mind:

  • automating backups
  • pulling host stats and ingesting them as syslog events
  • better ESA Alert <--> Custom Feed <--> Context-Hub List <-- > ESA Alert enrichment loops


However, one restriction I've been trying to figure out a good solution for is that the Admin Server will run these scripts as the "netwitness" user, and this user has fairly limited access.


I've been kicking around the possibility of adding this user to the sudoers group, possibly adding read/write/execute permissions for this user to specific directories and/or files depending on the use case, or sudo-ing to a different user within the script.


Each of these options present certain risks, so I'd be interested in hearing what other folks might think about these or other possible solutions to run scripts with elevated permissions in as secure a manner as possible.


Lateral movement is a technique that enables an adversary to access and control remote systems on a network. It is a critical phase in any attack, and understanding the methods that can be used to perform lateral movement, along with how those protocols display themselves in NetWitness, is paramount in detecting attackers moving laterally in your environment. It is also important to understand that many of the mechanisms used by attackers for lateral movement, are also used by administrators for legitimate reasons, and thus why it is important to monitor these mechanisms to understand what is typical behaviour, and what is not.



In this blog post, Winexe will be used. Winexe is a GNU/Linux based application that allows users to execute commands remotely on WindowsNT/2000/XP/2003/Vista/7/8 systems. It installs a service on the remote system, executes the command and uninstalls the service. Winexe allows execution of most of the windows shell commands.


The Attack

The attacker has successfully gained access to your network and dumped credentials, all without any detection from your Security Operations Center (SOC). The attacker decides to move laterally using Winexe, they connect to one of the hosts they had previously identified and begin to execute commands:


The Detection in NetWitness Packets

The use of Winexe is not overly stealthy. Its use creates a large amount of noise that is easily detectable. Searching for winexesvc.exe within the filename metadata returns the SMB transfer of the executable to the ADMIN$ share:


Using the time the file transfer took place as the pivot point to continue investigation, it is also possible to see the use of the Windows Service Control Manager (SCM) directly afterward to create and start a service on the remote endpoint. SCM acts as a remote procedure call (RPC) server so that services on remote endpoints can be controlled:


Reconstructing the raw session as text, it is possible to see the service name being created, winexesvc, and the associated executable that was previously transferred being used as the service base, winexesvc,exe:


Continuing to analyse the SMB traffic around the same time frame, it is also possible to see another named pipe, ahexec, being used. This is the named pipe that Winexe uses:


Reconstructing these raw sessions as text, it is possible to see the commands that were executed:


As well as the output that was returned to the attacker:


Based on the artefacts we have seen leftover from Winexe's execution over the network, there are multiple pieces of logic we could use for our application rule to detect this type of traffic. The following application rule logic would pick up on the initial transfer of the winexesvc.exe executable, and the subsequent use of the named pipe, ahexec:

(filename = 'ahexec','winexesvc.exe') && (service = 139)

The Detection in NetWitness Endpoint

Searching for winexesvc.exe as the filename source shows the usage of Winexe on the endpoints, this is because this is the executable that handles the commands sent to over the ahexec named pipe. The filename destination meta key shows the executables invoked via the use of Winexe:


A simple application rule could be created for this activity by simply looking for winexesvc.exe as the filename source:

(filename.src = 'winexesvc.exe')


Additional Analysis

Analysing the endpoint, you can see the winexesvc.exe process running from task manager:


As well as the service that was installed via SCM over the network:


This service creation also creates a log entry in the System event log as event ID 7045:


This means if you were ingesting logs into NetWitness, you could create an application rule to trigger on Winexe usage with the following logic:

( = '7045') && ( = 'winexesvc')

We can also see the named pipe which Winexe uses by executing Sysinternals pipelist tool:


Lateral movement is a technique that enables an adversary to access and control remote systems on a network. It is a critical phase in any attack, and understanding the methods that can be used to perform lateral movement, along with how those protocols display themselves in NetWitness, is paramount in detecting attackers moving laterally in your environment. It is also important to understand that many of the mechanisms used by attackers for lateral movement, are also used by administrators for legitimate reasons, and thus why it is important to monitor these mechanisms to understand what is typical behaviour, and what is not.


What is WMI?

At a high level, Windows Management instrumentation (WMI) provides the ability to, locally or remotely, manage servers and workstations running Windows by allowing data collection, administration, and remote execution. WMI is Microsoft's implementation of the open standard, Web-Based Enterprise Management (WBEM) and Common Information Model (CIM), and comes preinstalled in Windows 2000 and newer Microsoft Operating Systems.



In this blog post, the Impackets implementation of WMIExec will be used. This sets up a semi-interactive shell for the attacker. WMI can be used for reconnaissance, privilege escalation (by looking for well-known misconfigurations), and lateral movement.


The Attack

The attacker has successfully gained access to your network and dumped credentials, all without any detection from your Security Operations Center (SOC). The attacker decides to move laterally using WMIExec, they connect to one of the hosts they had previously identified and begin to execute commands:


The Detection in NetWitness Packets

NetWitness Packets can easily identify WMI remote execution. All the analyst needs to do is open the Indicators of Compromise (IOC) meta key and look for wmi command:


Pivoting on the wmi command metadata, and opening the Action meta key, the analyst can observe the commands that were executed, as these are sent in clear text:


NOTE: Not all WMI commands are malicious. It is up to the analyst to understand what is normal behaviour within their environment, and what is not. The commands seen above are typical of WMIExec however, and should raise concern for the analyst.


The following screenshot is of the raw data itself. Here it is possible to see the parameter that was passed and subsequently registered under the action meta key:


Looking at the parameter passed, it is possible to see that WMIExec uses CMD to execute its command and output the result to a file (which is named the timestamp of execution) on the ADMIN$ share of the local system. The following screenshot shows an example of whoami being run, and the associated output file and contents on the remote host:


NOTE: This file is removed after it has been successfully read and displayed back to the attacker. Evidence of this file only exists on the system for a small amount of time.


We can get a better understanding of WMIExec's function from viewing the source code:


To detect WMIExec activity in NetWitness Packets, the following application rule logic could be created to detect it:

action contains'\\admin$\\__1'

Lateral traffic is seldom captured by NetWitness Packets. More often than not, the focus of packet capture is placed on the ingress and egress points of the network, normally due to high volumes of core traffic that significantly increase costs for monitoring. This is why it is important to also have an endpoint detection product, such as NetWitness Endpoint to detect lateral movement.


The Detection in NetWitness Endpoint

A daily activity for the analyst should be to check the Indicators of Compromise (IOC), Behaviours of Compromise (BOC), and Enables of Compromise (EOC) meta keys. Upon doing so, the analyst would observe the following metadata, wmiprvse runs command shell:


Drilling into this metadata, and opening the Event Analysis view, it is possible to see the WMI Provider Service spawning CMD and executing commands:


To detect WMIExec activity in NetWitness Endpoint, the following application rule logic could be created to detect it:

param.dst contains '\\admin$\\__1'


Understanding the Tools, Techniques, and Procedures (TTP's) used by attackers, coupled with understanding how NetWitness interprets those TTP's, is imperative in being able to identify them within your network. The NetWitness suite has great capabilities to pull apart network traffic and pick up on anomalies, which makes it easier for the analysts to hunt down and detect these threats.


WMI is a legitimate Microsoft tool that is used within environments by administrators, as well as by 3rd party products, it can therefore be difficult to differentiate normal from malicious, and why it is a popular tool for attackers. Performing Threat Hunting daily is an important activity for your analysts to build baselines and detect the anomalous usage from the normal activity.

Eric Partington

Sigma for your SIEM

Posted by Eric Partington Employee Apr 8, 2019

Over the last year a few trends have emerged in detection ruleset sharing circles.  Standards or common formats of sharing detective rulesets have emerged as the defacto way teams are communicating rulesets to then convert into local technologies.


  • Yara for file based detections
  • Snort/Bro/Zeek rules for network based detections
  • Sigma for SIEM based detections


Along with MITRE ATT&CK these appear to be a consistent common foundation for sharing methodologies.


Given that, taking a shot at using Sigma to create RSA NetWitness rules based on the rulesets in the github repo was the next logical step.  The hard work of creating the backed and the initial mappings for fields was done by @tuckner and my work was just adding on a few additional fieldmappings and creating a wrapper script to help make the process of running the rules easier.


There are still some issues in the conversion script that I have noticed and not all capabilities in Sigma have been ported over (or can be ported over programatically) but this is enough of a start to get you on your way to developing additional rulesets with this capabilities.


*** <disclaimer>

Please note this is not an official RSA product, this is an attempt to start the conversion process of these rules to something NetWitness can begin to understand. There will be mistakes and errors in this community developed tool, feel free to contribute fixes and enhancements to the Sigma project to make it better and more accurate

</disclaimer> ***


You will need to install python3 to make the Sigmac tool run, NetWitness appliances don't have the right version of python so you will need somewhere to install it, these are my instructions that i fumbled through to make it work...


Once you have the tool running you should take a look at the rules that exist in the Sigma repo to see which ones you want to take a crack at converting.


Those rules exist here:


The tool you will use to convert the rules is sigmac and lives under tools/sigmac

The backend you will refer to is netwitness and lives under tools/sigma/backends

The last item you need to know about is the template that will be used to convert the rule using the backend which is located here tools/config/netwitness.yml


running the command on a single file looks something like this:

python36 sigmac -t netwitness ../rules/network/net_mal_dns_cobaltstrike.yml
(query contains 'aaa\.stage\.', 'post\.1')


You can use this to run individual conversions but what if you want to bulk convert all the rules in a folder?

This wrapper script will help you do that, place it in the root folder and adjust the directory paths as needed, this will output the name of the file as well as the conversion so that you know what file you are converting


Which gets you something like this:


((device.class='windows hosts') && (event.source='microsoft-windows-security-auditing') && ( = '4656', '4663', '4658') && ( contains '.AAA', '.ZZZ'))
((device.class='windows hosts') && (event.source='microsoft-windows-security-auditing') && ( = '4656', '4663', '4658') && ( contains '.AAA', '.ZZZ'))
((device.class='windows hosts') && (event.source='microsoft-windows-security-auditing') && ( = '517', '1102'))
((device.class='windows hosts') && (event.source='microsoft-windows-security-auditing') && ( = '517', '1102'))
((device.class='windows hosts') && (event.source='microsoft-windows-security-auditing') && ( = '517', '1102'))
((device.class='windows hosts') && (event.source='microsoft-windows-security-auditing') && ( = '517', '1102'))


Some items to be aware of:

  • IP addresses appear to be quoted which should not occur for our latest requirements
  • Keep an eye on regex usage
  • Haven't checked to far into the escaping of slashes for importing via the UI vs. the .nwr method.  Be careful which method you use that the right number of slashes are respected.


So far this looks like a useful method to add a bunch of current SIEM detections to the RSA NetWitness Platform, feel free to test and contribute to the converter, fieldmappings or other functions if you find this useful.

RSA NetWitness has a number of integrations with threat intel data providers but two that I have come across recently were not listed (MISP and Minemeld) so I figured that it would be a good challenge to see if they could be made to provide data in a way that NetWitness understood.


Current RSA Ready Integrations



Install the MISP server in a few different ways


VMWare image, Docker image or on an OS are all available (VMware image worked the best for me)


Authenticate and setup the initial data feeds into the platform

Set the schedule to get them polling for new data


Once created and feeds are being pulled in you can look at the attributes to make sure you have the data you expect


Test the API calls using PyMISP via Jupyter Notebook

  • you can edit the notebook code to change the interval of data to pull back (last 30 days, all data or such to limit impact on the MISP server)
  • You can change the indicator type (ip-dst, domain etc.) to pull back the relevant columns of data
  • You can change the column data to make sure you have what you need as other feed data


Once that checks out and you have the output data you want via the notebook you can add the python script to the head server of NetWitness


Install PyMISP on the head server of the NetWitness system so that you can crontab the query.

  • Install PyMISP using PIP

(keep in mind that updating the code on the head server could break things so be careful and test early and often before committing this change in production)

yum install
yum install python-pip
OWB_FORCE_FIPS_MODE_OFF=1 pip install pymisp
OWB_FORCE_FIPS_MODE_OFF=1 pip install --upgrade pip
yum repolist
vi /etc/yum.repos.d/epel.repo
change enabled from 1 to 0

Make sure you disable the epel repo after installing so that you don't create package update issues later


Now setup the query that is needed in a script (export the Jupyter notebook as python script)


Crontab the query to schedule it (the OWB is required to work around FIPS restrictions that seem to break a number of script related items in python)

23 3 * * * OWB_FORCE_FIPS_MODE_OFF=1 /root/rsa-misp/ > /var/lib/netwitness/common/repo/misp-ip-dst.csv


Now setup the NetWitness recurring feed to pull from the local feed location

map the ip-dst values (for this script) to the 3rd column and the other columns as required





Minemeld is another free intel aggregation tool from Palo Alto Networks and can be installed many ways (i tried a number of installs on different Ubuntu OSes and had difficulties), the one that worked the best for me was via a docker image.


Docker image that worked well for my testing


docker run -it --tmpfs /run -v /somewhere/minemeld/local:/opt/minemeld/local -p 9443:443 jtschichold/minemeld

to make it run as daemon after testing add the -d command to have it continue running after you exit the terminal


After installing (if you do this right you can get a certificate included in the initial build of the container that will help with the Certificate trust to NW) you will log in and set up a new output action to take your feeds and map them to a format and output that can be used with RSA NetWitness.


This is the pipeline that we will create which will map a sample threat intel list to an output action so that NetWitness can consume that information

And it gets defined by editing the yml configuration file (specifically this section creates the outboundhcvalues section that NetWitness reads)

- aggregatorIPv4Outbound-1543370742868
output: false
prototype: stdlib.feedHCGreenWithValue

This is a good start for how to create custom miners


Once created and working you will have a second miner listed and the dashboard will update


You can test the feed output using a direct API call like this via the browser


the  query parameters are explained here:


in this case:


translate IP ranges into CIDRs. This can be used also with v=json and v=csv.


returns the indicator list in CSV format.


The list of the attributes is specified by using the parameter f one or more times. The default name of the column is the name of the attribute, to specify a column name add |column_name in the f parameter value.


The h parameter can be used to control the generation of the CSV header. When unset (h=0) the header is not generated. Default: set.


Encoding is utf-8. By default no UTF-8 BOM is generated. If ubom=1 is added to the parameter list, a UTF-8 BOM is generated for compatibility.


F are the column names from the feed

This command testing drops a file in your browser to look at and make sure you have the data and columns that you want


Now once you are confident in the process and the output format you can script and crontab the output to drop into the local feed location on the head server (I did this as i couldn't figure out how to accept the self signed certificate from the docker image).

# 22 3 * * * /root/rsa-minemeld/

Now create the same local recurring feed file to pull in the information as feed data on your decoders.

Define the column to match column 1 for the IP in CIDR notation and map the other columns as required




Now we have a pipeline for two additional threat data aggregators that you may have a need for in your environment.

There are a myriad of post exploitation frameworks that can be deployed and utilized by anyone. These frameworks are great to stand up as a defender to get an insight into what C&C (command and control) traffic can look like, and how to differentiate it from normal user behavior. The following blog post demonstrates an endpoint becoming infected, and the subsequent analysis in RSA NetWitness of the traffic from PowerShell Empire. 


The Attack

The attacker sets up a malicious page which contains their payload. The attacker can then use a phishing email to lure the victim into visiting the page. Upon the user opening the page, a PowerShell command is executed that infects the endpoint and is invisible to the end user:



The endpoint then starts communicating back to the attacker's C2. From here, the attacker can execute commands such as tasklistwhoami, and other tools:


From here onward, the command and control would continue to beacon at a designated interval to check back for commands. This is typically what the analyst will need to look for to determine which of their endpoints are infected.


The Detection Using RSA NetWitness Network/Packet Data

The activity observed was only possible due to the communication happening over HTTP. If this had been SSL, the detection via packets would be much more difficult. This is why introducing SSL Decryption/Interception/Offloading is highly recommended. SSL inspection devices are nothing more than a well-designed man-in-the-middle attack that breaks the encryption into two separate encrypted streams. Therefore, they still provide an adequate level of protection to end-users while allowing security analysts and devices to properly monitor and alert when malicious or unwanted activity takes place, such as the web shells shown here. In summary, if you are responsible for protecting your organization’s assets, you should definitely consider the pros and cons of using this technology.


The analyst begins their investigation by placing a focus on looking for C2 traffic over HTTP. The analyst can then look into pulling apart the characteristics of the protocol by using the Service Analysis meta key. From here they notice a couple interesting meta values to pivot on, http with binary and http post no get no referer directtoip:


Upon reducing the number of sessions to a more manageable number, the analyst can then look into other meta keys to see if there are any interesting artifacts. The analyst look under the Filename, Directory, Client Application, and Server Application meta keys, and observes the communication is always towards a microsft-iis/7.5 server, from the same user agent, and toward a subset of PHP files:


The analyst decides to use this is as a pivot point, and removes some of the other more refined queries, to focus on all communication toward those PHP files, from that user agent, and toward that IIS server version. The analyst now observes additional communication: 


Opening up the visualization, the analyst can view the cadence of the communication and observes there to be a beacon type pattern:


Pivoting into the Event Analysis view, the analyst can look into a few more details to see if there suspicions on this being malicious are true. The analyst observes a low variance in payload, and a connection which is taking place ~every 4 minutes:


The analyst reconstructs some of the sessions to see the type of data being transferred, the analyst observes a variety of suspicious GET and POST's with varying data being transferred:


The analyst confirms this traffic is highly suspicious based of the analysis they have performed, the analyst subsequently decides to track the activity with an application rule. To do this, the analyst looks through the metadata associated with this traffic, and finds a unique combination of metadata that identifies this type of traffic:


(service = 80) && (analysis.service = 'http1.0 unsupported cache header') && (analysis.service = 'http post missing content-type')


IMPORTANT NOTE: Application rules are very useful for tracking activity. They are however, very environment specific, therefore an application rule used in one environment, may be of high fidelity, but when used in another, could be incredibly noisy. Care should be taken when creating or using application rules to make sure they work well within your environment.


The Detection Using RSA NetWitness Endpoint Tracking Data

The analyst, as they should on a daily basis, is perusing the IOC, BOC, and EOC meta keys for suspicious activity. Upon doing so, they observe the metadata, browser runs powershell and begin to investigate:


Pivoting into the Event Analysis view, the analyst can see that Internet Explorer spawned PowerShell, and subsequently the PowerShell that was executed:


The analyst decides to decode the base64 to get a better idea as to what the PowerShell is executing. The analyst observes the PowerShell is setting up a web request, and can see the parameters it would be supplying for said request. From here, the analyst could leverage this information and start looking for indicators of this in their packet data (this demonstrates the power behind having both Endpoint, and Packet solutions):


Pivoting in on the PowerShell that was launched, it is also possible to see the whoami and tasklist that was executed as well. This would help the analyst to paint a picture as to what the attacker was doing: 



The traffic outlined in this blog post is of a default configuration for PowerShell Empire; it is therefore possible for the indicators to be different depending upon who sets up the instance of PowerShell Empire. With that being said, C2's still need to check-in, C2's will still need to deploy their payload, and C2's will still perform suspicious tasks on the endpoint. The analyst only needs to pick up on one of these activities to start pulling on a thread and unwinding the attackers activity,


It is also important to note that PowerShell Empire network traffic is cumbersome to decrypt. It is therefore important to have an endpoint solution, such as NetWitness Endpoint, that tracks the activities performed on the endpoint for you.


Further Work

Rui Ataide has been working on a script to scrape data looking for instances of PowerShell Empire. The attached Python script queries the API looking for specific body request hashes, then subsequently gathers information surrounding the C2, including:


  • Hosting Server Information
  • The PS1 Script
  • C2 Information


Also attached is a sample output from this script with the PowerShell Empire metadata that has currently been collected.

Often times, Administrators and Content Managers alike need more information regarding their current parser status (both Logs and Network [formerly Packets]). There is an older, fancier interface for Log parser meta keys located here:

The script in this blog post is a bit more real-time and allows you to gain some additional visibility into your meta keys.




Please ensure you have run the on your SA Server (10.x) or NW Server / Node0 (v11). The script requires access to downstream services using SCP for the log parsing functionality.




Log Parser -> Meta Key Mapping:
When run in Log mode with a specific parser as a parameter, this will output all of the meta keys used in that parser. It will also output the format and whether that key is "Passed to the Concentrator", that is, if the key has flag set to is Transient (not passed to Concentrator in the session) or None (passed to the Concentrator).


Network Parser -> Meta Key Mapping:
When run in Network mode with IP of the Network Decoder, will output all of the Enabled parsers with its respective keys.

White = Enabled
Yellow = Transient
Red = Disabled




To run in Log mode:
Example: ./ -l <PARSER NAME> -i <LOG DECODER IP>
Example: ./ -l rhlinux -i


To run in Network mode:
Example: ./ -n -i <NETWORK DECODER IP>
Example: ./ -n -i

Sample Output


Log Parser -> Meta Key Mapping


Network Parser -> Meta Key Mapping


Hi Everyone,

On behalf RSA NetWitness, we are excited to bring you our first issue of the RSA NetWitness Platform newsletter. 


Our goal is to share more information about whats happening and key things for you to be aware of regarding our products and services. 


This will be a monthly newsletter, so you can expect the next newsletter in early May.  


No, this is not an April fools joke!!


There's a very short survey at the end of the second page in the newsletter.  Please share your thoughts with us so we can continue to improve it over time and make sure it contains useful information for you going forward.  


Thanks everyone!


***  EDIT  *** 

For anyone who does not feel comfortable downloading and viewing the .pdf copy of this newsletter, I've added screenshots of the newsletter so that you can still view the content.  Just note that by doing this, obviously none of the hyperlinks will work for you unless you download the .pdf.




Introduction to MITRE’s ATT&CK™

Adversarial Tactics, Techniques, and Common Knowledge (ATT&CK™) for enterprise is a framework which describes the adversarial actions or tactics from Initial Access (Exploit) to Command & Control (Maintain). ATT&CK™ Enterprise deals with the classification of post-compromise adversarial tactics and techniques against Windows™, Linux™ and MacOS™.

This community-enriched model adds techniques used to realize each tactic. These techniques are not exhaustive, and the community adds them as they are observed and verified.

To read more about how ATT&CK™ is helpful in resolving challenges and validate our defenses, please check this article.


Introduction to MITRE’s ATT&CK™ Navigator

ATT&CK™ Navigator is a tool openly available through GitHub which uses the STIX 2.0 content to provide a layered visualization of ATT&CK™ model.

ATT&CK™ Navigator stores information in JSON files and each JSON file is a layer containing multiple techniques which can be opened on Navigator web interface. The JSON contains content in STIX 2.0 format which can be fetched from a TAXII 2.0 server of your own choice. For example, we can fetch ATT&CK™ content from MITRE's TAXII 2.0 server through APIs.

The techniques in this visualization can be:

  • Highlighted with color coding.
  • Added with a numerical score to signal severity/frequency of the technique.
  • Added with a comment to describe that occurrence of technique or any other meaningful information.

These layers can be exported in SVG and excel format.


How to View a JSON in ATT&CK™ Navigator?

  1. Open MITRE’s ATT&CK™ Navigator web application. (
  2. In Navigator, open a New Tab through clicking '+' button.

  3. Then click on 'Open Existing Layer' and then 'Upload from Local' which will let you choose a JSON file from your local machine (or, the one attached later in this blog).


  4. After uploading JSON file the layer will be opened in Navigator and will look like this:



This visualization highlights the techniques covered in the JSON file with color and comments.


RSA Netwitness Endpoint Application Rules

The Rule Library contains all the Endpoint Application Rules and we can map these rules or detection capabilities to the tactics/techniques of ATT&CK™ matrix. The mapping shows how many tactics/techniques are detected by RSA NetWitness Endpoint Application Rules.

We have created a layer as a JSON file which has all the NetWitness Endpoint Application Rules mapped to techniques. Then we have imported that layer on ATT&CK™ Navigator matrix to show the overlap. In the following image, we can see all the techniques highlighted that are detected by NetWitness Endpoint Application Rules:




The JSON for Endpoint Application Rules is attached with this blog and can be downloaded.


While hovering mouse over each colored technique you can see three things:

  1. Technique ID: Unique IDs of each technique as per ATT&CK™ framework.
  2. Score:  Threat score given to each technique.
  3. Comment: We can write anything related in comment to put things in perspective. In this case, we have commented pipe (‘|’) delimited names of application rules which cover that technique.


To quantify how much RSA NetWitness Endpoint Application Rules spread across the matrix we can refer to the following plot:




We have already mapped RSA ESA Rules with ATT&CK™ framework as described in this article. We can update these ATT&CK™ coverage periodically which will help us to give us a consolidated picture of our complete defense system and thus we can quantify and monitor the evolution of our detection capabilities.








This is not an April Fools’ Day joke – RSA Charge registration fees go up from $595 to $995 on April 2. Trust us, you will not want to miss this year’s Charge event. REGISTER TODAY!


RSA Charge 2019 will provide you a place to discover game-changing business-driven security solutions to meet today’s greatest business challenges. Attendees will explore best practices and have opportunities to problem-solve and discuss ideas for product and service innovation to increase productivity. From customer case studies to training as well as one-on-one consultations and motivating keynotes, this year’s conference has something for everyone!


RSA Charge 2019 will deliver a host of new content and exciting opportunities through:

Customer-led case studies and hands-on workshops to share trends and issues specific to your industry

Thought-provoking keynote presentations that provides insights on RSA’s products, solutions and customer successes

Partner Expo highlights solutions that are driving high-impact business benefits using RSA’s solutions

Unparalleled Networking invites you to exchange ideas with your peers and RSA experts and save – early bird rates are $595 and available through April 1, 2019, then the regular registration price kicks in at $995. The RSA Charge 2019 website should be your go-to destination for all ‘Charge’ information - Call for Speakers, Agendas at a Glance, Full Agendas and speakers, Keynotes, and so much more.


RSA Charge 2019 will be in Orlando from September 16-19, 2019 @ Walt Disney World Dolphin & Swan Hotel, Orlando. 


REGISTER before April 2, save $400 and check out the RSA Charge 2019 website for continual updates like the one below:


Just Added: Looking for pre-conference training? Due to RSA Charge starting on a Monday and being on the Disney grounds, RSA has decided not to offer any pre-conference training this year but instead offer a whole RSA University track dedicated to your favorite training topics at no extra cost. That’s right, no additional cost!


There will also be RSAU representatives, onsite to talk shop and answer any and all of your questions, just another reason to attend RSA Charge 2019. We look forward to seeing you all in Orlando.

Cisco Umbrella uses the internet’s infrastructure to block malicious destinations before a connection is ever established.  By delivering security from the cloud, not only do you save money, but also provide more effective security.  Cisco Umbrella observes your internet traffic, blocks any malicious destinations and logs the activities. Our Cisco Umbrella plugin is meant to collect these logs into the NetWitness Platform which helps the security analysts to analyze the different kinds of attacks, security breaches etc.


For more information please refer to:


Logs from Cisco Umbrella cloud can be exported to an AWS S3 bucket which can be managed by Cisco or the customer.  Cisco Umbrella plugin uses Amazon's API to fetch the logs from AWS s3 bucket.





Configuration Guide:  Cisco Umbrella Event Source Configuration Guide 

Collector Package on RSA Live: "Cisco Umbrella Log Collector Configuration"

Parser on RSA Live: CEF

On a recent engagement, I took a different approach to finding possible malicious files entering the customer's network.  Rather than focusing on the e-mail, I looked for any RAR, macro-enabled office documents, and portable executable files (PE) entering the network where no service was specified.  Of course, this was done using RSA NetWitness and immediately I found a RAR file which contained a malicious executable.  Although, this was a different vector by which it entered the network.  It didn't appear to be a link that someone clicked from an e-mail and it wasn't an attachment from an email either.  It was from a customer configured, cloud based support site.  You can find many customers who use these types of sites.


So here's how I believe this was attempted.  A malicious actor goes to the <customer name>.<customer support site>.com site where they open a support ticket for an order they placed. (Of course they probably didn't place an actual order)  Then using the support interface, they upload what appears to be an order list.  In this instance I found the file name was "OrderList_Xlsx.arj" which is a RAR file and inside was a file called "OrderList.exe" all of which was downloaded by the customer support representative using their admin console to the site.


It's a simple approach.  It involves the actor opening a support ticket on the customer's site but whether they are actually doing this or using a script/automation is another question.  In this instance, I didn't see it as being targeted towards this customer but maybe they're testing the waters.  Without having access to this customers admin console to this service it's hard to determine whether this is happening more frequently because from our perspective, we only see where the employee downloads the file and enters into the customer's network. 


I created a quick and easy search to find this type of activity. = '<customer name>.<customer support site>.com' && (filetype = 'rar' || filetype = 'windows executable' || ((filetype = 'zip' || filetype contains 'office') && filename contains 'vbaproject.bin') || extension contains 'docm','xlsm','pptm' || content contains 'macro')

Filter Blog

By date: By tag: