Skip navigation
All Places > Products > RSA NetWitness Platform > Blog
3 4 5 6 7 Previous Next

RSA NetWitness Platform

620 posts

Did you know that you can use Respond for data exploration, even if you aren't using it for Incident Management?  While the naming convention certainly does not suggest it, Respond can be just as useful outside of incident response a place for analysts to group events of interest during investigation and hunting efforts.    Using Respond as more of an analyst workspace can help teams collaborate better, track streams of thought, and take advantage of Respond's new and improved visualization capabilities as of 11.4 (see Visualization Enhancements in RSA NetWitness Platform 11.4  for details).  




Step 1 - Create an "Incident" from Events view

Once you have a set of data that carries significance, you can select any set or subset of events contained in a data set and use it to create a new "Incident".  For our purposes here, you'll have to look past the current naming conventions of Alerts and Incidents and just think of it as a grouping of events (log, endpoint, or network sessions).


What data sets to use is largely up to you, but this type of approach is particularly useful when following a methodology that requires systematically carving larger data sets into smaller, more manageable ones.  The example above is based on RSA's Network Hunting Guide, details of which can be found here: RSA NetWitness Hunting Guide 


Step 2 - Open in Respond

Once opened, all of the capabilities available when using Respond for Incident Management are available.  It doesn't mean you have to use all of them, but you may find some of them to be a handy way to tag in other analysis (Tasks) and keep track of your analysis (Journal).  And if you do happen to find something malicious in the data set, all of the relevant information is already contained.


In the example above, we're seeing if anything interesting shows up in the data set for "All outbound HTTP sessions using the POST method".  The nodal diagram can be a useful way to see how the data is distributed between entities (larger bubbles meaning a larger number of events), which sub data sets within the larger one are dealing with disjoint sets of entities (Files, Hosts, IPs, Users, MAC Addresses), and can key your eye towards groupings that lead to deeper levels of inspection.  


Step 3 - Use Respond Tools to Track, Pivot, and Collaborate

View Event Cards

In-line Event Reconstruction (eg. Network Reconstruction)

Entity Details - Pivot To Other Views 



Add New Events 

And don't forget that you can always add more events to the same Respond incident to expand investigation if more leads are uncovered. Simply start from the top, and "Add To Incident".


As always, if you have any feedback or suggestions on how to make this experience even better, please leave a comment or, better yet, search, submit, and vote on product enhancements on the RSA Ideas portal: RSA Ideas for the RSA NetWitness Platform 


Happy Hunting!

The newest version of the RSA NetWitness Platform is almost here!


We’re excited to release the 11.4 version of the RSA NetWitness Platform very soon. We’ve worked hard on many new features and enhancements that will help users detect, investigate, and understand threats in their organizations.


This version introduces new features in analyst investigation, UEBA, Respond, administrative functions, and RSA NetWitness Endpoint, that collectively make security teams more efficient and arm them with the most relevant and actionable security data. Some of the more noteworthy 11.4 features include:


  • Enhanced Investigation Capabilities: Fully integrated free-text search, auto-suggestion, & search profiles
  • Smarter Network Threat & Anomaly Detection: UEBA expanded to analyze packet data with 24 new indicators
  • Improved Visualization of Incidents: Respond visualizations are clearer with enhanced relationship mapping
  • Expanded Functions for Endpoint Response: Powerful Host forensic actions and dynamic analysis directly from the RSA NetWitness Platform
  • Simplified File Collection from Endpoint Agents
  • Single Sign-on Capability
  • Distributed Analyst User Interfaces
  • New Health and Wellness (BETA)

This is not an exhaustive list of all the changes, please see the Release Documentation for the nitty gritty of the release details and to understand the full list of all the changes we’ve made in this release.


In the coming days and weeks, we’ll be publishing additional blog entries that demonstrate how this new functionality operates, and the benefits customers can expect to realize in 11.4.


The RSA Product team is excited for you to try this new release!

HA is a common need in many enterprise architectures, so NetWitness Endpoint has some built-in capabilities that allow organizations to achieve a HA setup with fairly minimal configuration and implementation needs.


An overview of the setup:

  1. Install Primary and Alternate Endpoint Log Hybrids (ELH)
  2. Create a DNS CNAME record pointing to your Primary ELH
  3. Create Endpoint Policies with the CNAME record's alias value


The failover procedure:

  1. Change the CNAME record to point to the Alternate ELH


And the failback procedure:

  1. Change the CNAME record back to the Primary ELH


To start, you'll need to have an ELH already installed and orchestrated within your environment.  We'll assume this is your Primary ELH, where your endpoint agents will ordinarily be checking into, and what you need to have an alternate for in the event of a failure (hardware breaks, datacenter loses power, region-wide catastrophic event...whatever).


To install your Alternate ELH (where your endpoint agents should failover to) you'll need to follow the instructions here:  under "Task 3 - Configuring Multiple Endpoint Log Hybrid".

**Make sure that you follow these instructions exactly...I did not the first time I set this up in my lab, and so of course my Alternate ELH did not function properly in my NetWitness environment...**


Once you have your Alternate ELH fully installed and orchestrated, your next step will be to create a DNS CNAME record.  This alias will be the key to entire HA implementation.  You'll want to point the record to your Primary ELH; e.g.: 


**Be aware that Windows DNS defaults to a 60 minute TTL...this will directly impact how quickly your endpoint agents will point to the Target Host FQDN in the CNAME record, so if 60 minutes is too long to wait for endpoints to be available during a failover you might want to consider setting the TTL lower...** (props to John Snider for helping me identify this in my lab during my testing)


And your last step in the initial setup will be to create Endpoint Policies that use this alias value.  In the NetWitness UI, navigate to Admin/Endpoint Sources/Policies and either modify an existing EDR policy (the Default, for instance) or create a new EDR policy.  The relevant configuration option in the EDR policy setting is the "Endpoint Server" option within the "Endpoint Server Settings" section:


When editing this option in the Policy, you'll want to choose your Primary ELH in the "Endpoint Server" dropdown and (the most important part) enter the CNAME record's alias as the "Server Alias":


Add and/or modify any additional policy settings as required for your organization and NetWitness environment, and when complete be sure to Publish your changes. (Guide to configuring Endpoint Groups and Policies here: NetWitness Endpoint Configuration Guide for RSA NetWitness Platform 11.x - Table of Contents)


You can test your setup and environment by running some nslookup commands from endpoints within your environment to check that your DNS CNAME is working properly and endpoints are resolving the alias to the correct target (Primary ELH at this point), as well as creating an Endpoint EDR Policy to point some active endpoint agents to the Alternate ELH (**this check is rather important, as it will help you confirm that your Alternate ELH is installed, orchestrated, and configured correctly**).


Prior to moving on to the next step, ensure that all your agents have received the "Updated" Policy - if any show in the UI with a "Pending" status after you've made these changes, then that means they have not yet updated:


Assuming all your tests come back positive and all your agents' policies are showing "Updated", you can now simulate a failure to validate that your setup is, indeed, HA-capable. This can be quite simple, and the failover process similarly straightforward.


  1. Shutdown the Primary ELH
  2. Modify the DNS CNAME record to point to the Secondary ELH
    1. This is where the TTL value will become important...the longer the TTL the longer it may take your endpoints to change over to the Alternate ELH
    2. Also...there is no need to change the existing Endpoint Policy, as the Server Alias you already entered will ensure your endpoints
  3. Confirm that you see endpoints talking to the Alternate ELH
    1. Run tcpdump on the Alternate ELH to check for incoming UDP and TCP packets from endpoints
    2. See hosts showing up in the UI
    3. Investigate hosts


After Steps 1 and 2 are complete, you can confirm that agents are communicating with the Alternate ELH by running tcpdump on that Alternate ELH to look for the UDP check-ins as well as the TCP tracking/scan data uploads: well as confirm in the UI that you can see and investigate hosts:



Once your validation and testing is complete, you can simply revert the procedure by powering on the Primary ELH, powering off the Alternate ELH, and modifying the CNAME record to point back to the Primary ELH.


Of course, during an actual failure event, your only action to ensure HA of NetWitness Endpoint would be to change the CNAME record, so be sure to have a procedure in place for an emergency change control, if necessary in your organization.

A couple of months ago, Mr-Un1k0d3r released a lateral movement tool that solely relies on DCE/RPC ( This tool does not create a service and drop a file like PsExec or similar tools would do, but instead uses the ChangeServiceConfigA function (and others) to edit an existing service and have it execute commands; making this a fileless lateral movement tool.


SCShell is not a tool designed to provide a remote semi-interactive shell. It is designed to allow the remote execution of commands on an endpoint utilising only DCE/RPC in an attempt to evade common detection mechanisms; while this tool is slightly stealthier than most in this category, it’s also a bit more limited in what an attacker can do with it.


When we first looked at this, we didn't have much in terms of detection, but with a prompt response from William Motley from our content team, he produced an update to the DCERPC parser that is the basis of this post.


The Attack

In the example screenshot below, I run the SCShell binary against an endpoint to launch calc.exe, while this is of no use to an attacker, it is just an example that we can use to visually confirm the success of the attack on the victim machine:



It could also be used to launch a Metasploit reverse shell, for example, as shown in the screenshot below. We will cover some of the interesting artifacts leftover from this execution in a seperate post. Obviously, this is not something an attacker would do, in their case something like launching an additional remote access trojan or tool would be more likely:


SCShell edits an existing service on the target endpoint, it does not create a new one. Therefore the service needs to already exist on the target. In the above example, I use defragsvc as it is a common service on Windows endpoints.


RSA NetWitness Network Analysis

There was a recent update to the DCERPC parser that is available via RSA NetWitness Live (thanks to Bill Motley), this parser now extracts the API calls made over DCE/RPC - which can be useful in detecting suspect activity over this protocol. If you have setup your subscriptions correctly for this parser (which you should have), it will be updated automatically, otherwise you will have to push it manually.


So, to start my investigation (as per usual) I take a look at my compromise meta keys and notice a meta value of, remote service control, under the Indicators of Compromise [ioc]

 meta key. This is an area that should be regularly explored to look for anomalous activity:


Pivoting on this meta value and opening up the action and filename meta keys, we can see the interaction with the svcctl interface that is being used to call API functions to query, change, and start an existing service:



  • StartServiceA - Starts a Service
  • QueryServiceConfigA - Retrieves the configuration parameters of the specified service.
  • OpenServiceAOpens an existing service
  • OpenSCManagerWEstablishes a connection to the service control manager on the specified computer and opens the specified service control manager database
  • ChangeServiceConfigAChanges the configuration parameters of a service


The traffic sent over DCE/RPC is encrypted, so reconstructing the sessions will not help here, but given that we have full visibility we can quickly pivot to endpoint data to get the answers we need. The following logic would allow you to identify this remote service modification behaviour taking place in your environment and subsequently the endpoints of interest for investigation:

service = 139 && filename = 'svcctl' && action = 'openservicea' && action = 'changeserviceconfiga' && action = 'startservicea'


RSA NetWitness Endpoint Analysis

A great way to perform threat hunting on a dataset is by performing frequency analysis, this allows us to bubble up outliers and locate suspect behaviour with respect to your environment - an anomaly in one environment, can be common in another. This could be done by looking for less common exectuables being spawned by services.exe in this instance - the following query would be a good place to start, device.type='nwendpoint' && filename.src='services.exe' && action='createprocess' - we would then open up the Filename Destination meta key and see a large number of results returned:



Typically, we tend to view the results from our queries in descending order, in this instance, we want to see the least common, so we switch the sorting to ascending to bubble up the anomalous executables. Now we can analyse the results and as shown in the screenshot below, we see a couple of interesting outliers, the calc.exe, and the cmd.exe:



Pivoting into the Events view for cmd.exe, we can see it using mshta to pull a .hta file, clearly this is not good:



This activity whereby services.exe spawns a command shell is out of the box content, and can be found under the Behaviors of Compromise [boc] meta key, so this would also be a great way to start an investigation as well:



Now that we have suspect binaries of interest, we have files and endpoints we could perform further analysis on to get our investigation fully underway, but for this post I will leave it here.



It is important to ensure that all your content in NetWitness is kept up to date - automating your subscriptions to Lua parsers for example, is a great start. It ensures that you have all the latest metadata being created from the protocols, and improves your ability as a defender to hunt and find malicious behaviours.


It is also important to remember that while sometimes there may not be a lot of activity from the initial execution of say a binary, at some point, it will have to perform some activity in order to achieve its end goal. Picking up on said activity will allow defenders to pull the thread back to the originating malicious event.

DNS over HTTPS (DoH) was introduced to increase privacy and help prevent against the manipulation of DNS data by utilising HTTPS to encrypt it. Mozilla and Google have been testing versions of DoH since June 2018, and have already begun to roll it out to end-users via their browsers, Firefox, Mozilla, and Chrome. With the adoption rates of DoH increasing, and the fact that C2 frameworks using DoH have been available since October 2018, DoH has become an area of interest for defenders; one C2 that stands out is goDoH by SensePost (


goDoH is a proof of concept Command and Control framework written in Golang that uses DNS-over-HTTPS as a transport medium. Currently supported providers include Google and Cloudflare, but it also contains the ability to use traditional DNS.


The Attack

With goDoH, the same binary is used for the C2 server, and the agent that will connect back to it. In the screenshot below, I am setting up the C2 on a Windows endpoint - I specify the domain I will be using, the provider to use for DoH, and that this is the C2:



On the victim endpoint I do the same, but instead specify that this is the agent:



After a short period of time, our successful connection is made, and we can begin to execute our reconnaissance commands:



RSA NetWitness Platform Network Analysis: SSL Traffic

Given its default implementation using SSL, there is not a vast amount of information we can extract, however, that does not mean that we cannot locate DoH in our networks. A great starting point is to look at who currently provides DoH - after some Googling I came across a list of DoH providers on the following GitHub page:



These providers could be converted into an application rule (or Feed) to tag them in your environment, or utilised in a query to retroactively view DoH usage in your environment. This would help defenders to initially pinpoint DoH usage: ends '','','','','','','','','','','','','','','','','','','','','','','','','','','','','','',''

NOTE: This is by no means a definitive list of DoH providers. You can use the above as a base, but should collate your own.


Running this query through my lab, I can see there is indeed some DoH activity for the Cloudflare provider:

As this traffic is encrypted, it is difficult to ascertain whether or not it is malicious, but there are a couple of factors that may help us. Firstly, we could reduce the meta values to a more manageable amount by filtering on long connection, which is under the Session Analysis meta key, this is because C2 communications over DoH would typically be long lived:



We could then run the JA3 hash values through a lookup tool to identify any outliers (in this instance I am left with one due to my lab not capturing a lot of data):


For details on how to enable JA3 hashes in the RSA NetWitness Platform, take a look at one of our previous posts: Using the RSA NetWitness Platform to Detect Command and Control: PoshC2 v5.0 

Running the JA3 hash (706ea0b1920182287146b195ad4279a6) through OSINT (, we get results back for this being Go-http-client/1.1, this is because the goDoH application is written in Golang - this stands out as an outlier and the source of this traffic would be a machine to perform further analysis on:




RSA NetWitness Platform Network Analysis: SSL Intercepted Traffic

Detecting DoH when SSL interception is in place becomes far easier. DoH requests for Cloudflare, for example

, supply a Content-Type header that allows us to easily identify it (besides the value):


Also determining whether the DoH connections are malicious becomes far easier when SSL interception is in place, this is because it allows defenders to analyse the payload that would typically be encrypted. The following screenshot shows the decrypted DoH session between the client and Cloudflare - here we are able to see the DNS request and response in the clear, which divulges the C2 domain being used, We can also see that the JA3 hash we previously reported was correct, as the User-Agent is Go-http-client/1.1:



The session for this DoH C2 traffic is quite large, so I am unable to show it all - this is due to the limited amount of information that can be transmitted via each DNS query. An example of data being transmitted via an A record can be seen below - the data is encrypted so won't make sense by merely viewing it:



Within this session there are hundreds of requests for the domain with a very high variability in the FQDN seen in the name parameter of the query; this is indicative behaviour of C2 communication over DNS. Below I have merged five of the requests together in order to help demonstrate this variability:



Given the use of TCP for HTTPS vs the common use of UDP for DNS, the traffic shows as a single session in the RSA NetWitness Platform due to TCP session/port reuse, normally this type of activity would present itself over a larger number of RSA NetWitness Platform sessions when using native DNS.


RSA NetWitness Endpoint Analysis

Looking at my compromise keys, I decide to start my triage by pivoting into the Events view for the meta value, runs powershell with http argument as shown below.



From the following screenshot, we can see an executable named, googupdater.exe, running out of the users AppData directory is executing a PowerShell command to get the public IP of the endpoint. We also get to see the parameter that was passed to the googupdater.exe binary that reveals the domain being contacted:


NOTE: googupdater.exe is the goDoH binary and was renamed for dramatic effect.

We could have also pivoted on the outbound from unsigned appdata directory meta value which would have led us to this suspect binary, as well. While from an Endpoint perspective this is just another compiled tool communicating over HTTPS, the fact that it will need to spawn external processes to execute activity would lead us to an odd parent process:



Given this scenario in terms of Endpoint, this would lead us back to common hunting techniques, but in the interest of brevity, I won't dig deeper for this tool. The key items would be an uncommon parent process for some unusual activity, and the outbound connections from an unsigned tool. While both can at times be noisy, in conjunction with other drills, they can be narrowed down to cases of interest.



This post further substantiates the requirement for SSL interception as it vastly improves the defenders capability to investigate and triage potentially malicious communications. While it is still possible to identify suspect DoH traffic without SSL interception, it can be incredibly difficult to ascertain its intentions. DNS is also a treasure trove for defenders, and the introduction and use of DoH could vastly deplete the ability for them to protect the network effectively.

When performing network forensics, all protocols should be analysed, however, some tend to be more commonly abused than others; one of these being DNS. While not as flexible as say HTTP, it does flow through, and outside of networks a lot easier due to its configuration. This means that DNS can be utilised to encapsulate data that would be routed outside the network to an attacker-controlled name server allowing data exfiltration or the download of tools. In this post, I will cover how we can use NetWitness Network to analyse the DNS protocol effectively, to do so we will use a tool called DNS2TCP ( in our lab to generate some sample traffic.


DNS record types

The DNS standard defines more than 80 record types, but many of these are seldom used. The most common are:

  • A Record - used to map a host and domain name to the IP address (forward lookup)
  • PTR Record - used to map an IP address to host and domain name (reverse lookup)
  • MX Record - to return host and domain mapping for mail servers
  • CNAME Record - used to return an alias to other A or CNAME records
  • TXT Record - used to provide the ability to associate arbitrary text with a host or other name


In this post, we will focus on TXT records being used to encapsulate data. TXT records are typically utilised as the size of this field allows for larger amounts of data to be transferred in a single request compared to A, or AAAA records. This field is also legitimately used to provide SPF records, specify the domain owner, return the full name of the organization, as well as other similar uses.


How Does NetWitness Network Analyse DNS?

The DNS_verbose_lua parser is available from RSA Live, it extracts metadata of interest from the DNS protocol that can help a defender in the identification of anomalous DNS traffic. We suggest that you subscribe to this parser (and others), as they are updated regularly.



Which metadata can help with the analysis?

The following meta keys are particularly useful for identifying, and subsequently analysing the DNS protocol:

Meta KeyDescriptionIndexed by default
serviceThe protocol as identified by NetWitnessYes
alias.hostThe hostnames being resolvedYes
alias.ipThe IP address that the hostname resolves toYes
service.analysisMeta values surrounding the characteristics of the protocolYes
tldThe top-level domain extracted from the hostnameYes
sldContains the part of hostname directly below the top-level domain (second level domain)No
dns.resptextThe response for the DNS TXT recordNo
dns.querytypeThe human readable value for the DNS Query type performed in the requestNo
dns.responsetypeThe human readable value for the DNS Query type returned by the responseNo


You will notice from the table above that some of the meta keys are not indexed by default. The following entries would therefore need to be added to the Concentrators index file so that they can be used in investigations:

<key description="SLD" format="Text" level="IndexValues" name="sld" defaultAction="Closed" valueMax="500000" />
<key description="DNS Query Type" format="Text" level="IndexValues" name="dns.querytype" valueMax="100" />
<key description="DNS Response Type" format="Text" level="IndexValues" name="dns.responsetype" valueMax="100" />
<key description="DNS Response TXT" format="Text" level="IndexValues" name="dns.resptext" valueMax="500000" />

NOTE: Details regarding the Concentrator index, such as how it works, ensuring optimal performance, and how to add entries can be found here:



DNS2TCP is a tool that encapsulates TCP sessions within the DNS protocol. On the server side, we configure the tool to listen on UDP port 53, as per the DNS standard, we also specify our domain, "", and the resources. Resources are a local or remote service listening for TCP connections - in the example below, I specify a resource named SSH for connections to port 22 on

The client will act as a relay for a specific resource, SSH in our example, and will listen on the specified port (2222) and forward traffic from the local machine to the remote server via DNS TXT records:

Once the communication between the client and server has been established, we can then connect to the server using SSH that will be encapsulated in DNS:


NetWitness Network Analysis

Homing in on DNS traffic is incredibly easy with NetWitness, we merely need to look for DNS under the Service meta key, or execute the query "service = 53". To place a focal point on possibly encoded DNS TXT records, we can pivot on the meta values, "dns base36 txt record", and "dns base64 txt record", located under the "Session Analysis" meta key. These tools will encode the data in the TXT record due to the limitations placed on the record type, such as only allowing printable ASCII symbols and a maximum length of 255 characters. 

From the screenshot below, we can see a suspicious sounding SLD with a large number of NetWitness sessions that would be worth investigating.

From here, I like to open the "SLD", "Hostname Alias", and "DNS Response Text" meta keys. What you can see from the screenshot below is a large number of unique "" or "dns.resptext" values to a single SLD; which is indicative of possible DNS tunnelling. The requests are highly unique, so they are not to be resolved by the local DNS cache, or the cache on the internal DNS servers.

The screenshot below shows the elevated number of different TXT records are related with the single SLD "slbwyfqzxn".

NOTE: Some commercial software packages such as antivirus and antispam tools show a similar behaviour and exchange data over DNS TXT record for their own security checks.


Reconstructing the sessions, we can see the TXT records and use the in-built Base64 decoding capability to see what data was encapsulated. In the screenshot below, we can see the initialisation of an SSH session:



DNS is commonly overlooked and an area that defenders should pay more attention toward, it is a great way to exfiltrate data out of an otherwise “secured” network. DNS2TCP is just one of the tools that allows data to be encapsulated within DNS, there are many others, but they all have similar behaviour and can be identified using similar techniques as shown in this post.

In order to defend their network effectively, analysts need to understand the threat landscape, and more specifically how individual threats present themselves in their tools. With that in mind, I started researching common Remote Access Trojans/Tools (RAT) that are publicly available for anyone to use. This will walk you through Gh0st RAT (, its footprint, and how the RSA tools help you detect its presence from both the endpoint and packet perspective. 


Just like any malware, a Gh0st infection will consist of some sort of delivery mechanism. Most mature SOCs with mature tools should get an alert on either its delivery (using common methods such as phishing, drive-by download, etc) or subsequent presence on an endpoint. However, let’s assume that it does not get detected, and as an analyst you are proactively hunting in your environment.  How would you go about detecting the presence of such a Trojan?


Gh0st Overview and Infection

Gh0st is a very well-documented RAT but you’ll find a quick overview of some of the functionality and way it was configured for testing purposes belowAlso, I will show you how our tools can help identify Gh0st.  The Gh0st server component is a standalone portable executable (PE) file, which gives you a simple interface when executed.  Once executed, the server component is used not only to control infected systems, but also used to configure the client component that is delivered to victims.



Figure 1: Gh0st Interface


The build tab that is used to configure the client executable had some default HTTP settings, which I changed to use “gh0st[.]com” for simplicity.  I also created an entry in DNS for this domain to point to our command and control (C2) server.



Figure 2: Gh0st HTTP and Service Options


You can also see that the Build tab contains options for the service display name and description.  After I created the malicious client component sample, I crafted an email using Outlook Web Access on Exchange and sent it to the victim.



Figure 3: Phishing Email


The victim setup had Windows 10 installed using all default settings.  Once the user received the email, I was surprised to learn that this wasn’t flagged by local Antivirus or any other tools.    Even after I executed the PE file, it was not flagged as malicious.  It installed the service as seen here but there was no initial identification and no “alarms” were raised. 


Figure 4: Service Installed


 The malware executed fine, and I could see the connection through the Gh0st Dashboard on the server component.



Figure 5: Successful Client Connection


From here, I used some of the built-in features of Gh0st to control and interact with the endpoint.  Here are some of those features:



Figure 6: Options Once Connected


I first opened a “Remote Shell” which basically just gives you a command prompt with System level permissions.



Figure 7: Remote Shell


From there, I executed net user commands through the remote shell.  The net user commands are for reconnaissance and used to identify what users are on the machine.  They can be used in conjunction with a username to identify what groups the user belongs to.



Figure 8: Running Commands Using Remote Shell


Next, I modified the registry to allow for cleartext credential storage in memory. I then copied procdump over to the machine using the “File Manager” feature, and then I used procdump to dump the lsass.exe memory into a .dmp file.  I finally copied that .dmp file back over to my C2 server.  This a common technique for getting credentials out of memory in cleartext.  The attacker can use these credentials to access other parts of the network.



Figure 9: File Manager


Figure 10: Procdump on LSASS


RSA NetWitness Endpoint 4.4 Detection

Prior to performing any of the aforementioned steps, I installed RSA NetWitness Endpoint on the victim and created a baseline of the IIOCs.  This was also prior to performing any additional interaction with the hosts.  These IIOCs were coming from multiple machines since I had Windows 10 and Windows 7 victims with agents installed.  There was only one level 1 IIOC and not much else going on.

Once the email was opened and the file was clicked, there were some additional IIOCs that fired including:

  • Unsigned writes executable
  • Unsigned writes executable to appdata local directory
  • Unsigned writes executable to Windows directory
  • Renames files to executable


Figure 11: IIOCs Fired in RSA NetWitness Endpoint



These are all great indicators for hunting and that should be checked daily, the results triaged, and appropriate measures taken for each hit.

Then I pivoted from those IIOCs and looked for the “invoice.exe” module in the tracking data.  This showed me the “FastUserSwitchingCapability” service being created.


Figure 12: Service Created


Also, this is where the net user commands were found. 


Figure 13: Net User Commands Found in RSA NetWitness Endpoint


Once the registry change for cleartext credential storage was executed, the IIOC for that fired as seen here.


Figure 15: More IIOCs


So, going back to the service we can see that it created an Autorun entry and gave it a high IIOC score.


Figure 16: Autoruns in RSA NetWitness Endpoint


It’s was also listed in the modules.


Figure 17: Modules Listed


RSA NetWitness Endpoint 11.3 Detection

Here’s how things look in RSA NetWitness Endpoint 11.3.  First here is the baseline IOC, BOC, EOC, and File Analysis meta fields after the agent has been installed.


Figure 18: RSA NetWitness Endpoint 11.3 Baseline


This is the risk score for the host which is based on the windows firewall being disabled.


Figure 19: Initial RSA NetWitness Endpoint 11.3 Risk Score


After I executed the dropper there was some additional meta generated including:

  • Unsighted writes executable to appdatalocal directory
  • Runs service control tools
  • Starts local service
  • Auto unsigned hidden
  • Auto unsigned servicedll


Figure 20: Additional Meta after Dropper Execution

Figure 21: Invoice.exe Creating Files in AppData Folder


We can also see this alert for “Autorun Unsigned Servicedlls” which is related to the “autorun unsigned servicedll” meta in the Navigate view.


Figure 22: Risk Score Increase

Figure 23: Autoruns with Four DLLs

Figure 24: Autorun Unsigned Servicedll Meta


Next, I opened up a remote shell using the Gh0st dashboard and executed some basic reconnaissance commands (whoami, net user /domain, etc) just like in RSA NetWitness Endpoint 4.4.


Figure 25: Reconnaissance Commands


Again, I executed the registry command to enabled cleartext credential storage and procdump on the lsass.exe process.  That triggered a critical alert in RSA NetWitness Endpoint 11.3 which gave a risk score of 100 just like in RSA NetWitness Endpoint 4.4.


Figure 26: Registry Command to Enable Cleartext Credential Storage


Also, going back to look at the navigate view, there was some additional meta generated for these commands.

  • Enumerates domain users
  • Modifies registry using command-line registry tool
  • Runs registry tool
  • Enables cleartext credential storage
  • Gets current user as system
  • Gets current user


Figure 27: Additional Meta


RSA NetWitness Network Detection

While there are obviously various detection capabilities for identification of delivery of the gh0st executable, the purpose of this post is to discuss presence of the gh0st RAT once a system is infected.  As such, the RSA NetWitness Packets (NWP) Gh0st parser detected the presence of the Gh0st trojan, based on the communications between the gh0st server and client. Just by looking in the “Indicators of Compromise” the Gh0st traffic is listed there.  With just one click I was able to find the C2 activity using RSA NetWitness Platform packet data.


Figure 18: IOC Meta in the RSA NetWitness Platform


As mentioned earlier, one of the benefits of doing this is that when we identify gaps, we work with people like Bill Motley in our content team to create appropriate content.  Initially the parser wasn’t detecting this specific gh0st activity but that has been fixed. An updated parser is now available in RSA NetWitness Live.


Here we can see some of the Gh0st C2 traffic that generates the IOC meta mentioned before.


Figure 19: Gh0st C2 Seen in the RSA NetWitness Platform


Also here is the HTTP traffic which is  heart beat callout to check and make sure it’s still connected.  It does this HTTP get request about every two minutes and only the string “Gh0st” is returned.


Figure 20: Heartbeat Traffic


Even without this parser, Gh0st C2 traffic can be found with as little as three pieces of metadata.  First, looking at service metadata labeled as ‘OTHER’ which can be a good place to start hunting because it’s network traffic that doesn’t have a known parser and/or doesn’t follow the RFCs for known protocols.  Then, in the IOC meta there was ‘binary indicator’ which can help limit the dataset.  Finally, in the analysis.service metadata the ‘unknown service over http port’ value stuck out.  Performing these three pivots from the full dataset found all of the gh0st traffic, including some additional traffic not seen previously.  That can be seen in the screenshot below under the Indicators of Compromise column.  There are IOCs showing gh0st but there are also some that only show the traffic as binary.


Figure 21: Additional Traffic Not Seen Previously



Gh0st is one of the simplest and easiest RATs to use.  The RSA NetWitness Platform had no trouble finding this activity.  Though this is a publicly available and commonly used RAT, it frequently goes unidentified by AV and other technologies, as referenced in my example.  This is where the power of regular threat hunting comes in, since it helps you detect unknown threats that your regular tools don’t necessarily pick up on. Some of these can be automated, as we did with the parser changes.


This means that, in the future, you no longer need to look for this specific threat but rather follow this process, which will hopefully lead you to newer unknown threats. Using the right tools coupled with the right methodology will help you better protect your network/organization, unfortunately not all of this can be fully automated and some of the automation will still require appropriate human triage.

A couple of days ago on Github, Hackndo released a tool ( that is capable of dumping the memory of LSASS using LOLBins (Living of the Land Binaries) - typically we would see attackers utilising SysInternals ProcDump utility to do this. Lsassy uses the MiniDump function from the comsvcs.dll in order to dump the memory of the LSASS process; this action can only be performed as SYSTEM, so it therefore creates a scheduled task as SYSTEM, runs it and deletes it.


We decided to take this tool for a spin in our lab and see how we would detect this with NetWitness.


The Attack

To further entrench themselves and find assets of interest, an attacker will need to move laterally to other endpoints in the network. Reaching this goal often involves pivoting through multiple systems, as well as dumping LSASS to extract credentials. In the screenshot below, we use the lsassy tool to dump credentials from a remote host that we currently have access to:


The output of this command shows us the credentials for an account we are already aware of, but also shows us credentials for an account we previously did not, tomcat-svc.


NetWitness Network Analysis

I like to start my investigation every morning by taking a look at the Indicators of Compromise meta key, this way I can identify any new meta values of interest. Highlighted below is one that I rarely see (of course in some environments this can be a common activity, but anomalies of what endpoints this takes place on can be identified):


Reconstructing the session, we can see the remote scheduled task that was created and analyse what it is doing. From the below screenshot, we can see the task created will use CMD to launch a command to locate LSASS, and subsequently dump it to \Windows\Temp\tmp.dmp using the MiniDump function within the comsvcs.dll:


cmd.exe /C for /f "tokens=1,2 delims= " ^%A in ('"tasklist /fi "Imagename eq lsass.exe" | find "lsass""') do C:\Windows\System32\rundll32.exe C:\windows\System32\comsvcs.dll, MiniDump ^%B \Windows\Temp\tmp.dmp full

This task also leaves other artifacts of interest behind. From the screenshot below, we can see the tmp.dmp LSASS dump being created and read:


This makes the default usage of lsassy easy to detect with simple application rule logic such as the below. Of course the names and location of the dump can be altered, but attackers typically tend to leave the defaults for these types of tools:

service = 139 && directory = 'windows\\temp\\' && filename = 'tmp.dmp'


NetWitness Endpoint Analysis

Similarly with Endpoint, I like to start my investigations by opening up the Compromise meta keys - IOC, BOC, and EOC. From here I can view any meta values that stand out, or iteratively triage through them. One of the meta values of interest from the below is, enumerates processes on local system:

Pivoting into the Events view for this meta value, we can see cmd.exe launching tasklist to look for lsass.exe - to get proper access, the command is also executing with SYSTEM level privileges - this is something you should monitor regularly:


After seeing this command, it would be a good idea to look at all activity targeted toward LSASS for this endpoint. To do that, I can use the query filename.dst = 'lsass.exe' and start to investigate by opening up meta keys like the ones below. Something that stands out as interesting is the usage of rundll32.exe to load a function called minidump from the comsvcs.dll:

Pivoting into the Events view, we can see the full command a lot easier. Here we can see that rundll32.exe is loading the MiniDump function from comsvcs.dll and passing some parameters, such as the process ID for dumping (which was found by the initial process enumeration), location and name for the dump, and the keyword full:


This activity could be picked up by using the following logic in an application rule. This will be released via RSA Live soon, but you can go ahead and implement/check your environment now:

device.type = 'nwendpoint' && category = 'process event' && (filename.all = 'rundll32.exe') && ((param.src contains 'comsvcs.dll' && param.src contains 'minidump') || (param.dst contains 'comsvcs.dll' && param.dst contains 'minidump')



It is important to consistently monitor network and endpoint behaviour for abnormal actions taking place, and not solely rely on out of the box detections. New attack methods/tools are consistently being devleoped, but the actions these tools take always leave footprints behind, it is down to the defender(s) to spot the anomalies and triage accordingly. With that being said, RSA are consistently updating detections for attacks such as the one laid out in this post - we have been working with the content team to have this tool usage detected with out of the box content.


Having recently moved into the IR team – where I now have to actually do stuff as opposed to just talking about stuff in technical sales – I have found that the best way to get up to speed with detecting attacker behaviours is to run the tools they are likely to use in my lab so I can get familiar with how they work. Reading blogs like this and the others in Lee Kirkpatrick's excellent Profiling Attackers Series is great, but I find I learn much faster by doing things and interacting with systems myself.


Covenant is an open source C2 framework ( that can be viewed as a replacement for PowerShell Empire, since its retirement.

In this blog series, Lee Kirkpatrick has already covered some examples of how to get the payload delivered and installed on the target, so we’re going to dive straight in to how our Hunting Methodology can be used to detect the activity. We are going to hunt for activity using data generated by both NetWitness Network and NetWitness Endpoint.

For the purpose of this exercise, we have used the default http settings for the Listener profile in Covenant, and only changed the default beacon setting from 5 seconds to 120 seconds to represent a more realistic use of the tool. The settings can be easily changed (such as the user-agent, directory and files used for the callback etc) but quite often the defaults are used by attackers too! We have also used the Power Shell method for creating our Launcher.

NetWitness Network Analysis

Covenant uses an HTTP connection for its communication (which can optionally be configured to run over SSL with user provided certs). By using our regular methodology of starting with Outbound HTTP traffic (direction = ‘outbound’ && service = 80), we can review the Analysis meta keys for any interesting indicators:



Reviewing the Service Analysis keys (analysis.service) we can see some interesting values:



Check the RSA NetWitness Hunting Guide for more information on these values in Service Analysis


By drilling into these 6 values we reduce our dataset from over 4,000 sessions to 69 sessions – this means that these 69 sessions all share the same “interesting” characteristics that suggest that they are not normal user initiated web browsing.



With 69 sessions we can use Event Analysis to view those sessions in more detail, which reveals the bulk of traffic belongs to the same Source & Destination IP address pair:



This appears to be our Covenant C2 communications. Opening the session reconstruction, we can see more details. Some things that we can observe that could be used to enhance detection of this traffic would be the strange looking User-Agent string:



The User-Agent string is strange as appears to be old. It resolves to Chrome version 41 on Windows 7 – the victim in this case is a Windows 10 system, and the version of Chrome installed on the host is version 79. If you attempt to connect to the Listener with a different User-Agent it returns a 500 Error:



Don't poke the Bear (or Panda, Kitten, Tiger etc) - if you find these indicators in your environment, don't try to establish a connection back to the attacker's system as you will give them a tip-off that you are investigating them.

Also, the HTTP Request Header “cookies” appears in all sessions:



The HTTP Request Header “cookie” also appears in all sessions after the initial callback … so sessions with both “cookies” and “cookie” request headers appear unique to this traffic:



The following query (which could be used as an App rule) identifies the Covenant traffic in our dataset:

client = 'mozilla/5.0 (windows nt 6.1) applewebkit/537.36 (khtml, like gecko) chrome/41.0.2228.0 safari/537.36' && http.request = 'cookies' && http.request = 'cookie'

Another indicator we could use is the Request Header value SESSIONID=1552332971750, as this also appears to be a static string in the default HTTP profile for Covenant - as shown in this sample that has been submitted to… 



NetWitness Endpoint Analysis

When hunting with NetWitness Endpoint, I always start with my *Compromise keys – Behaviours of Compromise, Indicators of Compromise, and Enablers of Compromise, as well as reviewing the Category of endpoint events.



Here we can see 4 meta values related to running PowerShell – which we know is the method used for creating our Covenant Launcher.

Upon viewing these events in Event Analysis we can see the encoded PowerShell script being launched



Analysis shows that we have a very large encoded parameter being passed. It’s too large for us to decode and manage in the NetWitness GUI, so we can paste the command into CyberChef and decode it from there.



We can further decode the string to reveal the command:



The output here appears to be compressed, so we can add an Inflate operation to our recipe to reveal the contents:



Looks like we have some executable code. A quick search for recognisable strings yields a URL which matches our network traffic for the callback to the Covenant server, as well as a template for the html page that should match what is served by the Covenant Listener



Also the block of text can be Base64 decoded to reveal the Request Headers to be sent by the Grunt when communicating with the Listener:



This also matches what we observed in our network analysis for a Grunt check-in:



And the command being sent to the Grunt via the response from the Listener:


Decoding the &data= section of the above Post shows the encrypted data being returned to the Listener - known as the GruntEncryptedMessage:




Happy Hunting!


In this blog post, I am going to cover a C&C framework called ReverseTCP Shell,. This was recently posted to GitHub by ZHacker:


With this framework, a single PowerShell script is used and PowerShell is the server component of the C2. This is also a little different from other C2's as it doesn't use a common protocol such as HTTP, this is why we thought it would be a good idea to cover, as it allows us to demonstrate the power of NetWitness with proprietary or unknown protocols.


The Attack

Upon execution of the ReverseTCP Shell PowerShell script, it will prompt for a couple of parameters, such as the host and port to listen for connections:


It will then supply options to generate a payload, I chose the Base64 option and opted to deploy the CMD Payload on my endpoint. At this point, the C2 also starts to listen for new connections:


After executing the payload on my endpoint, I recieve a successful connection back:


Now I have my successful connection, I can begin to execute reconaissance commands on the endpoint, or any commands of my choosing:


The C2 also allows me to take srceenshots of the infected endpoint, so let's do that as well:


NetWitness Packets Analysis

NetWitness Packets does a fantastic job at detecting protocols and has a large range of parsers to do so. In some cases, NetWitness Packets can not classify the traffic it is analysing, this could be because it is a proprietary protocol, or is just a protocol there is not a parser for, yet; in these instances, the data gets classified as OTHER


This traffic will still be analysed by the parsers in NetWitness, and should therefore be analysed by you as well. So to start the investigation, we would focus on traffic of type OTHER, using the following query, service=0 - from here, we can open other meta keys to see what information NetWitness parsed out. One that instantly stands out as a great place to start investigating is the windows cli admin commands metadata under the Service Analysis meta key:


Reconstructing the sessions, it is possible to see raw data being transferred back and forth, there is no structure to the data and therefore why NetWitness classified it as OTHER, but because NetWitness saw CLI commands being executed, it still created a piece of metadata to tell us about it:

NOTE: You may notice that the request and response in the above screenshot are reversed, this can happen for a number of reasons and an explanation as to why this occurs can be found in this KB article: 000012891 - When investigating sessions in RSA NetWitness, the source and destination IP addresses appear reversed.


The following query could be used to find suspect traffic such as this:

service = 0 && analysis.service = 'windows cli admin commands'


Further perusing the traffic for this C2, we can also see the screenshot taking place:


Which returns a decimal encoded PNG image:


We can take these decimal values from the network traffiic and run them through a recipe in CyberChef ( to render the image, and see what the attacker saw:


NetWitness Endpoint Analysis

In NetWitness Endpoint, I always like to start my investigation by opening the IOC, BOC, and EOC meta keys. All of the metadata below should be fully investigated, but for this blog post, I will start with runs powershell decoding base64 string:

Pivoting into the Events view, and analysing all of the sessions, I come across the command I used to infect the endpoint, this event should stand out as odd due to the random capitalisation of the characters, which is an atempt to evade case sensitive detection machanisms, as well as the randomised Base64 encoded string, which is to hide the logic of the command:


Due to the obfuscation put in place by the creator, we cannot directly decode the Base64 in the UI, this is because the Base64 encoded string has been shuffled. For instances like this were large amounts of obfuscation are put in place, I like to let PowerShell decode it for me by replacing IEX (Invoke-Expression) with Write-Host - so rather than executing the decoded command, it outputs it to the terminal:

Always perform any malware analysis in a safe, locked down environment. The method of deobfuscation used above does not neccessarily mean you will not be infected when performing the same on other scripts.

After decoding the initial command, it appears there is more obfuscation put in place, so I do the same as before, replacing IEX with Write-Host to get the decoded command. This final deobfuscation is a PowerShell command to open a socket to a specified address and port - I now have my C2, and can use this information to pivot to the data in NetWitness Packets (if I had not found it before):


The above PowerShell was a subset of the first decoded command, the final piece of the PowerShell is a while loop that waits for data from the socket it opens, this is why the IEX alteration would not work here, it is just obfuscation by using multiple poorly named variables to make it hard to understand:


Flipping back over to the Investigation UI, and looking at other metadata under the BOC meta key, it is possible to see a range of values being created for the reconaissance commands that were executed over the C2:


As of 11.3, there is a new Analyze Process view (Endpoint: Investigating a Process), it allows us to visually understand the entire process event chain. Drilling into one of the events, and then using the Analyze Process function, it is possible to see all of the additional processes spawned by the malicious PowerShell process:



Analysing all traffic and protocols is important, it is true that some protocols will be (ab)used more than others, but excluding the analysis of traffic classified as OTHER, can leave malicious communications such as the one detailed in this blog post to go under the radar. Looking for items such as files transferred, cli commands, long connections, etc. can all help with dwindling down the data set in the OTHER bucket to potentially more interesting traffic.

Over the past year, I have posted multiple blogs whereby I perform APT (Advanced Persistent Threat) emulation and analyse the forensic footprint left behind after the attack using the NetWitness platform. In this post, I take a look at an adversary emulation framework from MITRE named CALDERA - Cyber Adversary Language and Decision Engine for Red Team Automation:

This framework allows you to automate the adversary based around the MITRE ATT&CK framework (, and takes out a lot of the preparation work required to setup the attack scenarios.


For the purposes of this post / demo, I used a service that exposes local servers behind NATs and firewalls to the public internet over secure tunnels. In this case, the service used is ( - I've covered others in the past and all of these should be blocked for corporate environments. With this in mind I did not blur the URL in the screenshots, but I've since killed that connection so this address may now belong to someone else if you try to reach it, for security reasons I would suggest you don't.


This is not an attack framework like the other posts have covered, it is more of an emulation framework, however, this could be more suitable if you are just starting out in APT emulation and want to see what you can and can't detect. As like the other cases, in this post I will not go into detail on how to setup CALDERA as there is plenty of information regarding that already available.



CALDERA ships with an agent named Sandcat, also referred to as 54ndc47. This agent is written in GoLang for cross platform compatibility, and is the agent we will deploy on the endpoint(s) we want to execute our operations against. Navigating to the Sandcat plugin, we are presented with two options to deploy the agent.

  • Option one will generate commands on the fly for the specific operating system selected
  • Option two supplies a URL in which you can visit from the endpoint to download and execute Sandcat manually


For this blog post, I opted for the PowerShell command to deploy the agent. I ran this on my endpoint and you can see the connection was successful and it starts to beacon:


I chose one of the default adversaries, hunter, for my operation, the output of which can be seen below. A high level overview of this emulation is the search for sensitive files, which it collects, stages, and exfiltrates:



NetWitness Packets

Firstly, let's take a look into NetWitness Packets. Focusing on outbound traffic (direction='outbound') and the HTTP protocol (service=80), we can place a focal point on outbound HTTP communication. From here, we can view the characteristics of the HTTP traffic by opening up the Service Analysis meta key. Drilling into http suspicious 4 headers, http post no get, and http suspicious no cookie we are left with 20 events:


Next, we can start to view other metadata related to this traffic. Opening the Client Application meta key we can see a user agent of go-http-client/1.1 - this is because the agent is built on GoLang and it is not altered from the default. The server is Python/3.7 AIOHTTP/3.4.4, which is also worth noting. The filenames associated with this traffic are also interesting: instructions, results, and ping. These are very descriptive and are basically the agent receiving instructions, returning the results, or simply checking in:


This traffic could easily be picked up by adding the following logic to an application rule:

(client begins 'go-http-client') && (directory = '/sand/') && (filename = 'instructions','ping','results') && (server contains 'aiohttp')



Delving into the Event Analysis view, we can see Base64 encoded data in the body of the HTTP POST's. As of NetWitness 11 and upward, decoding Base64 can be done directly from within the UI by simply highlighting the text and selecting Decode Selected Text from the popup:


The Sandcat agent uses Base64 encoding for the whole instruction being sent to the endpoint, this instruction is in JSON format. The actual commands that will be executed are again Base64 encoded within the JSON record. To decode the commands within, I chose to run the additional Base64 through another tool called CyberChef (


The traffic for Sandcat is very easy to detect in NetWitness Packets. It does not attempt to hide itself or blend in with normal traffic, this is most likely by design as this is not an attack framework, but an emulation framework.


NetWitness Endpoint

Drilling into boc = 'runs powershell' and boc = 'in root of users directory', we can see a file called, sandcat.exe, executing out of C:\Users\Public with arguments to connect to the CALDERA server, and we can see a large number of PowerShell commands being executed by it - these PowerShell commands are the commands executed by the sandcat agent to perform the operation laid out at the beginning of this post. The metadata writes executable to root of users directory, or evasive powershell used over network under the BOC meta key would've also led to sandcat.exe and all of its associated commands:



Custom Attack

The out of the box adversaries are great for getting to grips with CALDERA, but I decided to crank it up a notch and make my own. This operation involved some discovery of systems, dumping of credentials, and lateral movement as can be seen below. These were all out of the box operations, I just added them to make my own adversary:



Delving into NetWitness Endpoint, we can see that there is a large quantity of metadata under the BOC meta key that tags all of the actions CALDERA performed:


CALDERA Ability ExecutedTechniqueNetWitness Metadata CreatedDescription


Find system network connections


enumerates network connectionsAdversaries may attempt to get information about running processes on a system. Information obtained could be used to gain an understanding of common software running on systems within the network.

Find user processes



queries users logged on local systemAdversaries may attempt to get a listing of network connections to or from the compromised system they are currently accessing or from remote systems by querying for information over the network.
Run PowerKatzT1003runs powershell with http argumentThe download of Mimikatz
Run PowerKatzT1003runs powershell downloading contentThe download of Mimikatz
Run PowerKatzT1003evasive powershell used over networkThe PowerShell command used to download Mimikatz
Run PowerKatzT1003powershell opens lsass processCredential dumping is the process of obtaining account login and password information, normally in the form of a hash or a clear text password, from the operating system and software. Credentials can then be used to perform Lateral Movement and access restricted information.
Net useT1077maps administrative shareAdversaries may use this technique in conjunction with administrator-level Valid Accounts to remotely access a networked system over server message block (SMB) to interact with systems using remote procedure calls (RPCs), transfer files, and run transferred binaries through remote Execution
Net useT1077lateral movement with credentials using net utilityThe lateral movement using net.exe and explicit credentials


To get a better view of the commands that took place, I like to open the Events view, from here I can see what was executed in an easier to read format:



Getting into APT emulation is not an easy task, CALDERA however, makes this a whole bunch easier. It is a great tool for testing your platforms abilities against the MITRE ATT&CK matrix and seeing what you can, and can't detect, as well as getting a better understanding as to how some of those techniques are actually performed; which will massively improve you as an analyst and improve your organisation defense posture. We only covered a subset of the available techniques, as the full content is too extensive to cover completely in a single post.

I was doing some hunting through our lab traffic today and came across some strange looking traffic, it turned out to be Rui Ataide playing around with a new DNS C2. It is named WEASEL and can be found here: GitHub - facebookincubator/WEASEL: DNS covert channel implant for Red Teams. From this, we decided to put together this quick blog post to go over how the traffic looks in NetWitness Packets, therefore, this is in a slightly different format to my usual posts in this topic. We may at some point update this to a full post if needed.



NetWitness Packets Analysis

As this tool uses DNS for its communication, we first need to place our focus on DNS traffic, we can do this with a simple query like so, service=53 - from here, I like to open the SLD (Second Level Domain) meta key and look for suspicious sounding SLD's, or SLD's that are quite noisy. From the screenshot below, doh stands out as a good candidate:


It is also a good idea to do the same with TLD to see if anything suspect stands out. We blurred out the domain we were using in this instance, but the .ml TLD should stand out as suspect as it is free to register and commonly used for malicious purposes:


Upon drilling into the suspect SLD (sld='doh'), we can then open the Hostname Alias Record meta key to see how many unique values are associated with that SLD. This type of DNS activity requires uniqueness in the requests it makes in order for the DNS queries not to be resolved by the cache, and this is why you would have a large number of unique values to a single SLD when performing this type of activity using the DNS protocol. This is depicted nicely by the below screenshot:

You would also typically see a large number of these DNS requests over a small period of time, however, this would be entirely dependent on the C2 and the beaconing interval set. For the above, the time range was over ~12 hours:



This traffic could easily be detected by using the following logic in an application rule:

( regex'^[0-9a-vx-z-]{2,52}w{0,6}\.[0-9a-f]{2}\.[0-9a-f]{4}\.') && (dns.querytype = 'aaaa record')


For other tools, the following regex should work too, it may however need some adaptation for each specific tool:



With that being said, altering the behavior of C2 communications like WEASEL can easily be done, which would then mean this application rule / regex would not trigger, and thus why it is always important to review the behaviors of protocols and not rely solely on signatures.



DNS C2's are becoming a more prevalent way to exfiltrate information in and out of a network. It is a transmission medium that often gets forgotten about as most would tie malicious communications with protocols such as HTTP or SSL and tend to only block those. DNS in nature can be very noisy, more so in this case as there is a finite amount of information you can transfer in AAAA records, and by design WEASEL also opted for shorter query names to evade detection, both these in conjunction increase even further the amount of DNS traffic being generated. Additionally, DNS requests are also cached for a period of time, they therefore need to be unique and names can't easily be reused, in order to avoid them being resolved by a cache instead of making it back to the attackers infrastructure. This inherent noisy behavior of DNS C2 makes it slightly easier to detect when the right tools are in place.

UPDATE 31 Mar 2020: Amazon Detective has been made officially GA by AWS as of today!  See the notes at the end of this post for links to the official documentation with more details on usage and implementation.


Amazon Detective is an Amazon Web Services (AWS) threat hunting platform that offers a deep, cloud-native view of AWS resource data and history, optionally in the context of an AWS-generated alert (such as from Amazon GuardDuty).   Amazon Detective augments threat detection systems like RSA NetWitness Platform by providing details about the size and scope of AWS specific security threats, and to help reconstruct “security events” affecting cloud assets and infrastructure.


We are pleased to announce the release of a new RSA NetWitness Platform integration with Amazon Detective.  This integration will allow an analyst to pivot from a RSA NetWitness investigation directly into Amazon Detective to view the related AWS resource as needed.  In addition, any RSA NetWitness logs customers who are consuming AWS GuardDuty alerts can also pivot directly to a related finding in Amazon Detective.





Typical use case scenario for this integrationTypical use case scenario for this integration



This integration provides several benefits:


  • Reduced investigation time due to eliminating the manual pivot (RSA NetWitness takes you right to the entry)
  • Get the added cloud-native visibility of Amazon Detective to dive deeper into an investigation
  • Enable the analysts to use both tools for increased context around the incident, likely resulting in increased speed of investigations


How does the integration work?

Customers can enable this integration via the built-in custom context menu actions feature within RSA NetWitness.  These actions will show up when you right-click on an appropriate meta key's value (e.g. IP address, domain name, GuardDuty finding ID) within the Investigate view and Event Reconstruction view. 


Configuring a custom right-click action using the UI wizard


Configuring a custom right-click action using the UI wizard


Clicking one of these will open a new browser window directly into Amazon Detective and query the meta key value in the appropriate context.  From there the analyst can move around and investigate related data.


User pivoting on meta within the Events view


User pivoting on meta within the Events view




Landing page user is directed to by the browser


Landing page user is directed to by the browser



What kind of things can I pivot on?

There are a number of pivot options. Most searchable data points within Amazon Detective which have an equivalent meta key within RSA Netwitness Platform can be integrated.  Below are the types of entities we have identified as candidates to start with:


AWS Concept

RSA NetWitness Meta Key

Finding (id)

Entity (IpAddress)


Entity (AswAccount)  Accountid


Entity (AwsRole) Principalid

Entity (AwsUser) Principalid

Entity (UserAgent)


Entity (Instanceid)



Through tight UI integration, this enables RSA NetWitness analysts with a powerful addition to their threat hunting arsenal in Amazon Detective.  The integration is straightforward and easy to implement and customize and will save your analysts valuable investigation time.




Good hunting!


Command and Control platforms are constantly evolving. In one of my previous blog posts, I detailed how to detect PoshC2 v3.8:



Since then, Nettitude have revamped PoshC2 and released v5.0. This blog post takes a look at the new and improved version, and goes into some detection mechanisms, but this time, solely over SSL.



Reviewing the configuration for PoshC2, it appears it still generates a certificate with the same default information as its predecessor. This is not to say that it is not easy to change as you could simply edit the Python file that generates this certificate, or that it will not alter in the future, but it's worth noting:


Delving into NetWitness Packets, we can see this information is extracted and gets populated under the meta keys shown below:


This would make detecting the default certificates of PoshC2 with application rules a simple task. We would need only to look for one of the metadata values above being created due to them being very unique: = 'p18055077' || = 'pajfds' || ssl.subject = 'pajfds'

The certificate is also self-signed and generated when the PoshC2 sever is started, so we also see some interesting metadata values populated under the analysis.service meta key:


The certificate issued within last day is a relatively new metadata value and something to look out for within your environment. There are also other relatively new metadata values that will be populated based upon the analysis NetWitness performs against the certificate, these are shown below:

certificate long expirationCertificate expires more than two years since issued.Certificate validity is usually capped at two years. Longer-lived certificates may be suspicious.
certificate expiredCertificate was expired when presented.Expired certificates are invalid and won't be presented by most legitimate hosts.
certificate expired within last weekCertificate was expired by less than a week when presented.Expired certificates are not expected to be presented by most legitimate hosts.
certificate issued within last dayCertificate was presented less than a day since issued.New certificates may be suspicious in combination with other characteristics of the session.
certificate issued within last weekCertificate was presented less than a week since issued.New certificates may be suspicious in combination with other characteristics of the session.
certificate issued within last monthCertificate was presented less than a month since issued.New certificates may be suspicious in combination with other characteristics of the session.
certificate anomalous issued dateCertificate issued date is malformed, nonsensical, or invalid.Invalid or malformed certificates are suspicious.
certificate anomalous expiration dateCertificate expiration date is malformed, nonsensical, or invalid.Invalid or malformed certificates are suspicious.


Looking further into the configuration there are a few other interesting default settings. The User Agent string is hard coded, but of course you would need SSL inspection to see this, or for the beacons to be over HTTP - with that being said, it is a very common User Agent string and not a great indicator anyway. The default sleep, or beacon, is set 5 seconds, and the jitter to 0.20 seconds - this would make the beacons stand out in NetWitness Packets:


Looking into the Navigate view, and pivoting on the suspiciously named certificate, = 'pajfds' - it is possible to see a beacon type pattern for this traffic:


Delving into the Event Analysis view for this, we can obtain a better view of the cadence of communication. From here you can see the very obvious beacon pattern coupled with a payload size that does not vary greatly. Two great indications of automated check-in type behaviour:


With, there is a new feature available that provides the ability to generate JA3 hashes for SSL traffic. They are not enabled by default, but the following configuration guide details how to enable them:


For more details on what JA3 hashes are, and how they can be useful, there is a great explanation of them from the creators available on Github:


In this instance, a PowerShell payload was dropped onto the endpoint, and therefore it is PowerShell making the web requests. The way PowerShell sets up its TLS sessions has a unique(ish) JA3 fingerprint:


Perusing the available open source JA3 hash lists, we can see that we indeed have a match for this hash and it is PowerShell (Miscellaneous/ja3_hashes.csv at master · marcusbakker/Miscellaneous · GitHub ). While this is not a atomic indicator for PoshC2, it is a great way to detect PowerShell making web requests, and a great starting point for your threat hunting that could lead you to find C&C servers, such as PoshC2 where a PowerShell payload was used:


The following screenshot shows the PowerShell payload created by PoshC2 and the one I used to infect the endpoint:


These JA3 hashes could be pulled in as a Feed, so the associated hash values get generated under a meta key of your choosing, or you could also create a right-click context menu action (attached to this post):


While not much as changed in terms of endpoint indicators and analysis, in this post we opted to cover the encrypted (by default) traffic generated by this framework a bit in more detail, while also highlighting some of the new certificate analysis characteristics on the product. Endpoint analysis of this framework can be found in the previous post regarding Posh C2: Using RSA NetWitness to Detect Command and Control: PoshC2



With the new release of PoshC2 v5.0, it appears that not much has changed in the grand scheme of things. With that being said, it is a good idea to regularly revisit known attack frameworks as they are constantly adapting and evolving to evade known detection mechanisms. It is also important to keep up to date with the latest features of NetWitness to ensure you have every chance to detect the bad traffic in your network.


MuddyWater is a state-sponsored threat group suspected to be linked to Iran. It has mainly been targeting organizations in the Telecommunications, Government and Oil sectors across the Middle East region.

The group relied on spear phishing emails with macro infected Word documents in the past (as seen in a previous post) and has recently been using similar techniques using Excel documents in a new wave of attacks during October-November 2019.


In this post we will look at one of those Excel files used in the latest campaign and identify ways to detect it using RSA NetWitness Network and Endpoint.


The following is the file used in this article:









In a real attack, the file would be delivered via email to its target. In our case, we will manually execute it.

This particular sample must be named “Report.xls” or would fail to execute.

By opening the file, the user will get the following message telling him to enable editing and content. This is to trick the user into enabling Macros.



Once content is enabled, the following 2 files are dropped in “C:\Users\<user>\AppData\Local\Temp”.






Endpoint Visibility

By leveraging RSA NetWitness Endpoint, we can quickly see that Excel, even though a known legitimate file, has an elevated risk score based on its behavior.




By tracking the events on the endpoint, we can see the below behaviors:


  1. Excel creates the “wucj.exe” file
  2. The “wucj.exe” file is executed
  3. “wucj.exe” loads the “zdrqgswu” file, which appears to be a VB script, which leads to 2 network connections over TCP/80 to the “” domain.



By looking at the registry changes done by Excel, we can also see that a key has been created to run at startup for persistence after reboots.




If we look more closely at the “wucj.exe” file, we can notice that it is a known and valid Microsoft file. We can confirm this by searching for the hash on VirusTotal. The file is actually “wscript.exe” used to load VB scripts (which is in line with the behavior seen).





Network Visibility

In the previous steps, we have seen that the VB script has initiated a connection over TCP/80 to the “” domain.

If we look at the details of this network connection on RSA NetWitness Network, we can see that the domain is hitting one of the Threat Intelligence feeds.



If we then reconstruct the session to look at the raw data, we can identify that the malware is sending within the HTTP GET Request:

  • The username: rsa
  • The hostname: DEMO-USER-1
  • The Operating System: Windows (32-bit) NT 6.01







Indicators of Compromise

The following are some additional indicators that can be used to detect the presence of a compromise.


File Hashes





































Command & Control Domains







Filter Blog

By date: By tag: