Skip navigation
All Places > Products > RSA NetWitness Platform > Blog > 2020 > May


Several changes have been made to the Threat Detection Content in Live. For added detection you need to deploy/download and subscribe to the content via Live. For retired content, you must manually remove those items.


For detailed configuration procedures to setup RSA NetWitness Platform, see the Content Quick Start Guide



RSA NetWitness Lua Parsers:

  • TLS_lua Options – Optional parameters to alter the behavior of the TLS_lua parser.

Available Options:

"Overwrite Service": default value false

Default behavior is that if another parser has identified a session with service other than SSL, then this parser will not overwrite the service meta.

If this option is enabled,  the parser identifies all sessions containing SSL as SSL even if a session has been identified by another parser as another service.


"Ports Only": default value false

Default behavior is port-agnostic: that is, the parser looks for all SSL/TLS sessions regardless of which ports a session uses.  This allows identification of encrypted sessions on unexpected and non-standard ports.

If this option is enabled,  the parser only searches for SSL/TLS sessions using the configured ports.  Ports on other sessions will not be identified as SSL/TLS.  This may improve performance, at a cost of possibly decreased visibility.


Note that a session on a configured port that is not SSL/TLS will still not be identified as SSL/TLS.  In other words, the parser does not assume that all sessions on configured ports are SSL/TLS.

Read more about SSL and NetWitness 


More information about Packet Parsers:


RSA NetWitness Application Rules:

  • Creates Run Key – New application rule is added to detect creation of new run keys. Creating new run key can be an indication of someone trying to use startup configuration locations to execute malware, such as remote access tools, to maintain persistence through system reboots.

This rule addresses MITRE’s ATT&CK™ tactic – Persistence; Technique - Registry Run Keys / Startup Folder


  • Execute DLL Through Rundll32 – New application rule is introduced to detect DLL execution using Rundll32 program. Rundll32 program can be called to execute an arbitrary binary. Attackers may take advantage of this for proxy execution of code to avoid triggering security tools.

This rule addresses MITRE’s ATT&CK™ tactic – Execution, Defense Evasion; Technique - rundll32


  • Runs DNS Lookup Tool for TXT Record – New application rule is added to detect possible covert command and control channels. Running nslookup.exe to query TXT records can be used to establish a covert Command & Control channel to exchange commands and other malicious information. These malicious commands can be later executed on the target system.

This rule addresses MITRE’s ATT&CK™ tactic – Discovery, Command and Control; Techniques - System Network Configuration Discovery, Commonly Used Port, Standard Application Layer Protocol


For more information about NetWitness 11.4 New Features and Alerting: ESA Rule Types 




RSA NetWitness Lua Parsers:

  • ethernet_oui - The list of registered OUI in the parser is updated for added detection.

Read more about Lua - Mapping MAC to Vendor (Logs/Netflow and Endpoint)  


More content has been tagged with MITRE ATT&CK™ metadata for better coverage and improve detection.

For detailed information about MITRE ATT&CK™:

RSA Threat Content mapping with MITRE ATT&CK™  

Manifesting MITRE ATT&CK™ Metadata in RSA NetWitness  




We strive to provide timely and accurate detection of threats as well as traits that can help analysts hunt through network and log data. Occasionally this means retiring content that provides little-to-no value.

List of Discontinued Content 


RSA NetWitness Application Rules:

  • Stealth Email Use - Marked discontinued due to performance-to-value tradeoff.


For additional documentation, downloads, and more, visit the RSA NetWitness Platform page on RSA Link.


EOPS Policy:

RSA has a defined End of Primary Support policy associated with all major versions. Please refer to the Product Version Life Cycle for additional details.

Delving back into the C2 Matrix to look for some more inspiration for blog posts, we noticed there are a number of Remote Administration Tools (RATs) listed. So we decided to start taking a look at these RATs and see how we can detect their usage in NetWitness. This post will cover QuasarRAT which is an open-source, remote access tool that is developed in C#. It has a large variety of features for controlling the victim endpoint and has been used by a number of APT groups.


The Attack

QuasarRAT can be compiled in two modes, debug and release - for this blog post we compiled QuasarRAT in debug mode as it is the quickest and easiest way to get up and running. Once our agent had been compiled, we dropped it onto our victim endpoint in the C:\PerfLogs\ directory and executed:


Shortly after execution we get a successful connection back to QuasarRAT from our victim endpoint:


QuasarRAT has a large feature set, here we are using the Remote Shell feature to execute some commands:


There is also a file explorer that allows us to easily navigate the file system, as well as upload and download files:


It even has a Remote Desktop feature to view and control the endpoint:



The Detection Using NetWitness Network

QuasarRAT does not have an option for insecure communication and all traffic will be over SSL, it also uses a custom TCP protocol for its communication so if intercepted the protocol would be tagged as OTHER and you would have to look for indicators similar to those outlined in our CHAOS C2 post: Using RSA NetWitness to Detect Chaos C2.


Under the Service Analysis meta key, we get some interesting meta values generated regarding the certificate. QuasarRAT upon compilation generates a self-signed cert, this means the certificates age is low, as is identified by the certificate issued within last week meta value, and the self-signed meta value is, ssl certificate self-signed - you'll also notice that there is an ssl over non-standard port meta value, this is generated as the default port for QuasarRAT is 4782 (this is easily changed however and would more commonly be over 443 to bypass firewall restrictions). With that being said, these are some great pivot points to start a hunt in SSL traffic to look for suspect SSL communication:


Looking into the parsed data from the certificate, we can see that the SSL CA and SSL Subject identify this as a Quasar Server, which are the default values given to the certificate created by QuasarRAT: = 'quasar server ca' || ssl.subject = 'quasar server ca'


Another interesting meta value is located under the Versions meta key, where we can see that QuasarRAT uses an outdated version of TLS, tls 1.0 - this could be another starting point to look for this tool, or other applications using outdated protocols for that matter:


The SSL JA3 hash for this comes back as, fc54e0d16d9764783542f0146a98b300, which according to JA3 OSINT maps to, PowerShell 5.1;Invoke-WebRequest. While there is often overlap with JA3 hashes, it would still be a good place to start a hunt from:


On initial execution the RAT will also make an HTTP call to to obtain the public IP address of the endpoint. It would be worth hunting through the network traffic for requests to this domain and others that provide the same function:


The Detection Using NetWitness Endpoint

When we were setting up QuasarRAT, we modified the persistence settings to true, the following two meta values were generated based off of this. This is because QuasarRAT will copy itself to the \AppData\Roaming\ directory and use the \CurrentVersion\Run key to start it upon boot:


If you are using the new ATT&CK meta keys, we also see this persistence mechanism described there as well with the following meta values:


As stated in the network detection section, the RAT will make an HTTP connection to to get the public IP of the victim, we can also see that in the network endpoint data as shown below:


We can also drill into the meta value, console.remote, which is located under the Context meta key. This will show us commands executed by cmd.exe or powershell.exe as a result of inter-process communication through anonymous pipes, i.e. a reverse shell - here we can see client.exe executing suspect commands:


It is important to triage through all the commands executed in order to identify and follow the attackers intentions. An interesting command seen above is in relation to the esentutl.exe; this binary provides database utilities for the Extensible Storage Engine but can also be used to copy locked files for example. Drilling into this command, we can see it was used to copy the SAM hive (which is a locked file) to the C:\PerfLogs\ directory - it does this by using the volume shadow copy service (as noted by the /vss switch in the command below) to make a backup of the locked file which we are then able to copy:


This is an interesting LOLBin (Living off the Land Binary) as it would allow an attacker to copy any locked file from the system, this is activity that should be monitored and the following application rule logic would detect the usage of this command to copy files using the volume shadow copy service:

(filename.src = 'esentutl.exe' || filename.dst = 'esentutl.exe') && (param.src contains '/vss' || param.dst contains '/vss')

NOTE: Not all usage of esentutl.exe will necessarily be malicious, this could be a legitimate technique used by backup software for example. It is down to the defender to determine the legitimacy of the tool executing the command.




QuasarRAT has been around for some time and has been used in a number of targeted attacks against organizations and it is easy to see why. Remote access tools such as this pose a real risk to organizations and monitoring for their activity is paramount to ensuring the security of your network. It is also important as a defender that when these tools are found, that all command are triaged to gain a better understanding of the attackers intentions and end goal.

To round out our series explaining how to use the indicators from ASD & NSA's report for detecting web shells (Detect and prevent web shell malware | ) with NetWitness, let's take a look at the endpoint focused indicators. If you missed the other posts, you can find them here:


Signature-Based Detection

To start with, the guide provides some YARA rules for static signature based analysis. However the guide then quickly moves on to say that this approach is unreliable as attackers can easily modify the web shells to avoid this type of detection. We couldn't agree more – YARA scanning is unlikely to yield many effective detections.


Endpoint Detection and Response (EDR) Capabilities

The guide then goes on to describe the potential benefits of using EDR tools like NetWitness Endpoint. EDR tools can be of great benefit to provide visibility into abnormal behaviour at a system level. As the paper notes:

For instance, it is uncommon for most benign web servers to launch the ipconfig utility, but this is a common reconnaissance technique enabled by web shells.

Indeed - monitoring process and commands invoked by web server processes is a good way to detect the presence of web shells. When a web shell is first accessed by an attacker, they will commonly run a few commands to figure out what sort of access they have. Appendix F of the guide includes a list of Windows Executables to watch for being launched by web server processes like IIS w3wp.exe (reproduced below):

NetWitness endpoint provides OOTB monitoring for many of these processes, and produces meta data when execution is detected. The examples below shows some of the meta generated for the execution of cmd.exe, ipconfig.exe and whoami.exe from a web shell - the Behaviors of Compromise key shows values of interest:

An important detail to be wary of is that in many cases the web server process like w3wp.exe may not invoke the target executable directly. So simply running a query looking for filename.src = 'w3wp.exe' && filename.dst = 'ipconfig.exe' won’t work. In the example below, we can see that the web server process actually invokes a script in memory, which then invokes cmd.exe to run the desired tool ipconfig.exe, similarly for whoami.exe:

The event detail shows the chain of execution across the two events:

We can see the full meta data includes the command to run ipconfig.exe passed as a parameter between the two processes:


We can get a clearer picture of the relationship between these processes usng the NetWitness Endpoint process analyser, which shows the links between the processes:


NetWitness Endpoint generates a lot of insightful metadata to describe actions on a host. It is well worth reviewing the metadata generated and which meta keys it is placed under. There is a great documentation page with all the details here: RSA NetWitness Endpoint Application Rules 

Not just IIS

Of course, web shells don't only run on IIS! The same principles can be used for detecting web shells installed on Apache Tomcat and other web servers. Application rules in NetWitness Endpoint also look for command execution by other web server processes. Make sure you check your environment for your web server daemons and add them to the rules as well:


That’s it for this series where we’ve gone through the indicators published by ASD & NSA in their guide for detecting web shells and transcribed how to use them in NetWitness.While the indicators in the guide serve as a starting point, real life detection can get very complicated very quickly. As we stated in a previous post:

Not all indicators are created equally, and this post should not be taken as an endorsement by this author or RSA on the effectiveness and fidelity of the indicators published by the ASD & NSA.

My colleague Hermes Bojaxhi recently posted about another example involving web shells from one of our cases. He goes into great detail showing the exploitation of Exchange and the installation of a web shell: Exchange Exploit Case Study – CVE-2020-0688 


Let me know in the comments below if you’ve used any of these techniques in your environment and what you've found - or let me know if there's anything else you'd like to see.


Happy Hunting!

Josh Randall

Postman for NetWitness

Posted by Josh Randall Employee May 17, 2020

If you've ever done any work testing against an API (or even just for fun), then you've likely come across a number of tools that aim to make this work (or fun) easier.


Postman is one of these tools, and one of its features is a method to import and export collections of API methods that enable individuals to begin using those APIs much more easily and quickly than if, say...they only have a bunch of docs to get them started.


As NetWitness is a platform with a number of APIs and a number of docs to go along with them, a Postman collection detailing the uses, requirements, options, etc. of these APIs should (I hope) be a useful tool that individual and teams can leverage to enable more efficient and effective use of the NetWitness well as with any other tool that you may want to integrate with NetWitness via its APIs.


With that in mind, I present a Postman Collection for NetWitness.  This includes all the Endpoint APIs, all the Respond APIs, and the more commonly used Events (A.K.A. SDK) APIs --> Query, Values, Content, and Packets. Simply import the attached JSON file into Postman, fill in the variables, and start API'ing.


A few notes, tips, and how-to's....

  • upon importing the collection, the first thing you should do is update the variables to match your environment

  • the rest_user / rest_pass variables are required for the Endpoint and Respond API calls
    • the NW account you use here can be created/managed in the NW UI in Admin/Security --> Users & Roles tabs
    • the role assigned to the account must have the integration-server.api.access permission, as well as any underlying permissions required to fulfill the request
    • e.g.: if you're querying Endpoint APIs, you'll need integration-server.api.access as well as endpoint-server permissions
  • the svc_user / svc_pass variables are required for the Events API calls
    • the NW account you use here can be created/managed in the NW UI in Admin/Services --> <core_service> --> Security --> Users & Roles tabs
    • the role assigned to the account must have the sdk.content, sdk.meta, and sdk.packets permissions, as well as any additional permissions necessary to account for Meta and Content Restriction settings you may be using
  • every Respond and Endpoint call will automatically create and update the accessToken and refreshToken used to authenticate its API call
    • so long as your rest_user and rest_pass variables are correct and the account has the appropriate permissions to call the Respond and/or Endpoint node, there is no need to manually generate these tokens
    • that said, the API calls to generate tokens are still included so you can see how they are being made
  • several of the Endpoint APIs, when called, will create and update variables used in other Endpoint APIs
    • the first of these is the Get Services call, which lists all of the endpoint-server hosts and creates variables that can be used in other Endpoint API calls
      • the names of these variables will depend on the names of each service as you have them configured in the NW UI
    • the second of these is the Get Hosts call, which lists all of the endpoint agents/hosts reporting to the queried endpoint-server and creates a variable of each hostname that can be used in other Endpoint API calls

      • this one may be a bit unwieldy for many orgs, though, because if you have 2000 agents installed, this will create 2000 variables - 1 for each host - if you have 20,000 agents installed, or 200,000.... 
      • you may not want all those hostname variables, so you can adjust how many get created, or disable it altogether, by modifying or deleting or commenting out the javascript code in the Tests section of the Get Hosts call

Any questions, comments, concerns, suggestions, etc...please let me know.

We are back again with another C2 framework called, Chaos: CHAOS is a PoC written in Go and comes with a healthy number of features for controlling the remote endpoints. It supports agents for Windows, Mac, and Linux, however, the feature availability does differ depending on the platform the agent is deployed on. This C2 only allows control of one agent, and all communication is over TCP sockets. More information surrounding this C2 can be found over at the C2 Matrix: C2Matrix - Google Sheets.


This C2 reminds a lot of one we previously covered called, HARS: Using RSA NetWitness to Detect HTTP Asynchronous Reverse Shell (HARS) - so check that post out as well if you haven't already.



The Attack

As always, we're keeping this super simple to place more of a focal point on the C2 traffic itself, rather than the delivery mechanism. So to deploy the agent, we simply copy the binary to the victim endpoint and execute it from the C:\PerfLogs\ directory:


After execution, we see our successful connection back to Chaos as is evident from the [+] Connected! message displayed:


Now we have our connection, we can use one of the available built-in features to set up persistence for Chaos to ensure it starts up again should the system reboot:


From here, we can start to execute commands to get information regarding the endpoint we are controlling:




The Detection Using NetWitness Network

Chaos has no direct support for HTTP and all communication between the C2 and the agent is over TCP sockets. As there is no structure to the traffic being generated, it is not possible to classify it under a specific service, so NetWitness tags this traffic as service = 0 - otherwise known as OTHER. The service OTHER is often overlooked as an area for hunting but should still be analysed by defenders to look for malicious traffic using proprietary protocols, or TCP sockets like Chaos. From the below, we can see that there are some meta values of interest for the Chaos C2 traffic that would stand out during the hunting process:

NOTE: The unknown service over http port meta value is interesting here, as attackers often use typical ports for web browsing to get around firewall policies that block everything but web access for endpoints.


Drilling into the possible base64 windows shell meta value, we can see the structure of the Chaos C2 traffic. The commands are sent as typed to the agent, but the output from the command is Base64 encoded and sent back to the C2, hence why NetWitness generated the possible base64 windows shell meta value:


This gives us the ability to easily observe the commands being executed, and to Base64 decode the output of the commands directly within the UI:


For this type of C2 there is no need to create additional detections for NetWitness Network, the detection is already there and just requires that defenders triage traffic of type OTHER where interesting meta values are generated, such as the ones shown here.



The Detection Using NetWitness Endpoint

As always, when these C2 frameworks are deployed, they have to execute and do things in order to achieve their end goal, and with NetWitness Endpoint it is easy to detect these actions. Below are the meta values generated from the small number of commands that were executed through the C2:


  • chaos > whoami - gets current username
  • chaos > tasklist - enumerates processes on local system
  • chaos > ipconfig - enumerates ip configuration
  • chaos > hostname - gets hostname
  • chaos > persistence_enable - runs registry tool, runs xcopy.exemodifies run key, modifies registry using command-line registry tool


Opening the Events view for the meta values of interest, we can get a better view of all the commands being executed:



The Detection Using NetWitness Logs

In order to better identify suspicious activities taking place on the endpoint, we have chosen to install Sysmon, and to include the detections available through its logging. More information surrounding Sysmon can be found at the following link: The collection of these logs is performed via the NetWitness Endpoint agent itself and more detail on how that was set up can be found here:


There are multiple starting points for using Sysmon to find malicious activities, but for now we are going to start with the following logic which would detect the usage of whoami being executed on a system, this is normaqlly evidence of attacker activity after successful exploitation or privilege escalation and is not overly common for most users to execute regularly:

(event.source = 'microsoft-windows-sysmon') && ( ends'whoami.exe') && ( = '1')

NOTE: The ='1' shown in the above query is for process creations.


Upon executing this query in NetWitness, we can see we get hits for the whoami command being executed from the C:\PerfLogs\ directory:


This is a suspicious directory for processes to be created from, so we can take a look at all processes being created out of this directory by slightly modifying our query to look for all process execution out of the C:\PerfLogs\ directory:

(event.source = 'microsoft-windows-sysmon') && (directory = 'c:\\perflogs\\') && ( = '1')


Here we can see a suspect executable running from the C:\PerfLogs\ directory named chaos.exe, and we can also see that there is a number of other suspicious commands being executed from this directory, as well:




We could also create an application rule that identifies the persistence that was created by looking for edits being made to the \CurrentVersion\Run key using the following logic:

(event.source = 'microsoft-windows-sysmon') && ( = '1') && (param contains 'reg  add hkcu\\software\\microsoft\\windows\\currentversion\\run')


NOTE: While we covered Sysmon as a free alternative to EDR, our recommendation would still be to use one, as Sysmon may require a considerable amount of configuration and tweaking, and will not provide as many capabilties or visibility as an EDR solution would. We covered it here just to offer an alternative for those that don’t use EDR.




Chaos C2 is an easy-to-use framework that gives the attacker great control over the victim endpoint, it does not provide much in terms of obfuscation and does not attempt to blend in with normal traffic, so this should make this an easy detection for defenders whether you have NetWitness Network, Endpoint or Logs. Just remember to not shy away from the traffic type OTHER when hunting through those packets!


Octopus was presented at Black Hat London 2019 by Askar. The github page is available here. It is a pre-operation C2  for Red Teamers, based on HTTP/S and written in python. This blog post will show the detection of Octopus (over http) with NetWitness Endpoint and Network.



The attacker sets up an HTTP listener in Octopus and generates an exe payload. He then builds a webpage where he embeds the payload and spreads the webpage through social media and email spam campaigns. The victim opens the webpage from his Windows 10 machine and a pop-up message is immediately shown on the browser stating the current version of Adobe Flash plugin is outdated and needs to be updated to install latest security patches. Thus the victim clicks on the pop-up and installs the update which infects his machine.


Part 1 -  Attack phase

Once Octopus is started this is how the attacker creates a listener and generates the payload, in this case an exe payload (hta and powershell payloads are also an option):



More in detail we have:

listen_http listen_ip port hostname interval page listener_name
generate_unmanaged_exe listener_name output_path

The attacker uses the popular ngrok tunneling service as a proxy, that is once the victim machine is infected it will communicate with the address which will  in turn create a secure tunnel to the attacker box.


Next the attacker uses a technique known as browser hooking to embed the exe file into a webpage. To achieve this the attacker used the BeEF framework. Explaining this whole process is out of the scope of this post but if you are interested to know more about it you should have a look at the  Autorun Rule Engine BeEF github page.


The victim, using a Windows 10 machine, sees an interesting website about organic food on social medias and clicks on the webpage:



As shown above once the webpage is loaded a message pops up warning to install a new version of Adobe Flash plugin which included new security updates. Interestingly the message also warns to ignore the missing certificate signature and that it is a known issue which Adobe is working on.



The victim then clicks on Install missing Plugins and then on Run ignoring the signature warning as advised. Windows Defender is activated and did not detect the exe file.


On the other side of the wall the attacker receives a connection to the listener.


To interact with the victim the attacker runs the following command:

interact 1

where 1 is number of the session.


The attacker also runs some other commands such as "whoami", "quser", and "report". The latter is a command built-in in Octopus which provides some additional information about the victim machine. After a little of browsing within the victim machine folders the attacker also finds a file containing potential sensitive information (TopSecret.txt) and downloads it using Octopus download command.


Part 2 - Detection phase with the RSA NetWitness Platform

NetWitness Endpoint

The analyst receives an email alert about a high priority incident generated in the NetWitness Respond module so he starts investigating:



The incident is generated by the NetWitness Endpoint incident rule "High Risk Alerts: NetWitness Endpoint".  However, the rule originates from an App Rule which is part of a bundle content pack available in RSA Live. More information about this bundle is available here.


The App Rule condition is the following:

device.type = 'nwendpoint' && category = 'network event' && context = 'network.outgoing' && direction = 'outbound' && context != 'network.nonroutable' && context.src = 'file.unsigned' && dir.path.src = 'appdatalocal','appdataroaming'

and it basically alerts if an unsigned file initiated from the Windows AppData/local or AppData/roaming directory has made an outbound network connection. The alert in turn generates an incident since it is marked with High Risk.


It is apparent from the incident that the file adobe_flash_update.exe made a connection to which is the name of the ngrok server the attacker uses to tunnel the connection to his machine. The fact that file is unsigned and makes a connection to a website that is not from Adobe makes things extremely suspicious.

Drilling down into the events with NetWitness Endpoint and analyzing them in details the analysts also notices this:



which clearly shows the adobe_flash_update.exe spawned few other processes among which whoami.exe and quser.exe that are Windows utilities typically used by attackers for enumeration. 


NetWitness Network

With the information retrieved from the incident, the analyst investigates further with NetWitness Network filtering by hostname:


The analyst notices some potentially malicious HTTP requests under the Service Analysis meta key. While analyzing these meta keys he finds the following event under the "http1.1 without user-agent header" meta value.



The above is the initial communication of the victim machine with the Octopus C2. Note that "home.php" in the GET request is the name the attacker used in the command to setup the listener we saw in the beginning. The response to the request contains a powershell payload that intends to setup the communication with the C2 . We can see an AES key and its Initialization Vector used to encrypt the communication. This structure looks very similar to the Ninja C2, described by my colleague Lee Kirkpatrick in another blog post available here.


After the agent/C2 communication has been setup the next request is the "GET /login" where the encrypted communication is established:



each further request is a beacon to the C2 and the analyst notices that the request includes the victim machine name "WINEP1" followed by a 5 characters random name:



The below two requests show the command quser launched from the C2 in the previous steps and its response (the response is contained on a separate GET request):


Note that when the C2 requests something we see "/bills" in the GET request.


The below figure shows the decryption of the above strings using the powershell decryption function seen in the very first request (GET /home.php):


With the same process the analyst was able to see other commands the attacker ran but more importantly was able to see the attacker exfiltrated a file named TopSecret.txt from the infected machine:



The beaconing pattern can also be observed with 120 seconds intervals and same size:



It is important to note different destination IP addresses in the above figure. This is because ngrok resolves to different IP addresses in round robin.


Another interesting thing to note is that the URL parameters we saw in the GET requests can be customized via  the Octopus file:



# this is the web listener profile for Octopus C2
# you can customize your profile to handle a specific URLs to communicate with the agent
# TODO : add the ability to customize the request headers

# handling the file downloading
# Ex : /anything
# Ex : /anything.php
file_receiver_url = "/messages"

# handling the report generation
# Ex : /anything
# Ex : /anything.php
report_url = "/calls"

# command sending to agent (store the command will be executed on a host)
# leave <hostname> as it with the same format
# Ex : /profile/<hostname>
# Ex : /messages/<hostname>
# Ex : /bills/<hostname>
command_send_url = "/view/<hostname>"

# handling the executed command
# Ex : /anything
# Ex : /anything.php
command_receiver_url = "/bills"

# handling the first connection from the agent
# Ex : /anything
# Ex : /anything.php
first_ping_url = "/login"

# will return in every response as Server header
server_response_header = "nginx"

# will return white page that includes HTA script
mshta_url = "/hta"

# auto kill value after n tries
auto_kill = 10


Lastly, while inspecting the network for C2 traffic the analyst  finds the following:



These are HTTP beacons. Requests are sent on port 3000 which is the default port the BeEF framework uses.



Looking at one of the sessions the analyst sees it contains several requests like the one in the above screenshot. In the Referer field we can see the address of the phishing website used by the attacker and the GET request contains the hook to the BeEF C2. The victim will be hooked to the C2 until he closes the browser. The attacker can leverage the hook to performs social engineering attacks like the fake Adobe Flash update among many others.



A client-side attack vector was used to get initial foothold to the victim machine. Once the victim opened the legitimate-looking webpage his browser was "hooked" to the attacker BeEF C2. The attacker had also set an automatic rule that pushed a fake pop-up message suggesting the victim to install Adobe Flash security updates. Once the victim installed the fake Adobe Flash update the incident was created in NetWitness Respond module because of the App Rule discussed earlier.

Threat actors usually use multiple techniques to distribute their malicious payloads. What would have happened if the user had downloaded the file by a different mean on his machine? The same incident would have probably not been generated in NetWitness because that specific app rule relied on the fact that an unsigned file was started from appdatalocal directory in Windows. However, even without the incident the analysts would have identified suspicious network activity with NetWitness Network such as the beaconing to the C2 and also indicators of compromise and suspicious activities in NetWitness Endpoint . For example, the Behavior of Compromise meta key of NetWitness Endpoint would have shown following values:


    queries users logged on local system (1)  related to the whoami command
    gets current username (1)    related to the quser command


The same applies if the attacker had set an HTTPS listener instead of the HTTP one. In this case the analysts would not have been able to see the content of the communication between the C2 and the victim (unless there is an interceptor in place) but they would have noticed the beaconing and the indicators of compromise in NetWitness Endpoint.



Octopus is quite new but showed similarities to other recent C2 frameworks. It is customizable and modular (external modules can be plugged-in) and can run both on HTTP and HTTPS. This article showed that the NetWitness Suite can be of great use when it comes to C2 detection with the combination of both NetWitness Network and Endpoint by providing a very granular level of visibility. In the case of HTTPS an SSL/TLS interceptor would help providing more visibility but without it NetWitness can still identify C2 patterns and indicators of compromise that will help analysts detect potential malicious activities.

Following on from my last post that focused on analysing web server logs ASD & NSA's Guide to Detect and Prevent Web Shell Malware - Web Server Logs , this time we are going to look at the network based indicators from the ASD & NSA guide Detect and prevent web shell malware | .

There are already some fantastic resources posted by my colleague from the IR team Lee Kirkpatrick and the NetWitness product Documentation team that provide great details on the different ways we can detect web shells using NetWitness for network visibility:

The focus of this post is taking the indicators published by the ASD & NSA in their guide, and showing how to use them in NetWitness.

Not all indicators are created equally, and this post should not be taken as an endorsement by this author or RSA on the effectiveness and fidelity of the indicators published by the ASD & NSA.

Now that’s out of the way, lets take a look at the network indicators.

Web Traffic Anomaly Detection

This is really focused on the URIs being accessed on your servers and the user agents that are being used to access those pages. An easy way to detect new user agents, or new files being accessed on your website (depending on how dynamic your content is) is to use the show_whats_new report action. The show_whats_new action will filter your results from a query to only show new values that did not appear in the database prior to the timeframe of your report. Here’s an example from my lab – if I run a report to show all user agents seen in the last 6 hours I get 20 user agents in my report:

Using show_whats_new in the THEN clause of the rule filters the results and shows me only 2 user agents (which makes sense as my chrome browser recently updated):

Obviously just because a user agent is new doesn’t automatically mean it is a web shell, as web browsers get updates all the time. But it is another method for highlighting anomalies and changes in your environment.

One of the common techniques we use in the IR team is to review the HTTP request methods used against a server – finding sessions that do not follow the pattern of normal user web browsing are a good indicator for web shells. Normal user generated browsing will consist of GET requests followed POST. Sessions that have a POST action with no GET request and no referrer present are a good indicator as Lee covers in his post mentioned above.

Signature-Based Detection

As the ASD & NSA guide states itself, network signatures are an unreliable way to detect web shell traffic:

From the network perspective, signature-based detection of web shells is unreliable because web shell communications are frequently obfuscated or encrypted. Additionally, “hard-coded” values like variable names are easily modified to further evade detection. While unlikely to discover unknown web shells, signature-based network detection can help identify additional infections of a known web shell.

The guide nevertheless includes some Snort rules to detect network communication from common, unmodified web shells:

RSA NetWitness has always had the ability to use Snort rules on the Network Decoder, and that capability was recently enhanced with the 11.3 release adding the ability to map meta data generated by the snort parser to the Unified Data Model. For the steps required to install and configure Snort rules on your network decoder, follow these guides for details and more information:

Here’s the short version:

  1. Create a new folder on your Network Decoder /etc/netwitness/ng/parsers/snort
  2. Create a snort.conf file in that directory. Here’s a simple configuration to get you started:
  3. Copy the rules from the ASD & NSA guide into a file called webshells.rules
    Mitigating-Web-Shells/network_signatures.snort.txt at master · nsacyber/Mitigating-Web-Shells · GitHub 

  4. Go to the Explore view for your Decoder, and go to decoder > parsers > config and add Snort=”udm=true” to the parsers.options field

  5. While in Explore view, right click on decoder > parsers, select properties, then choose reload and hit Send to reload the parsers and activate your Snort rules.

Here we can see the Snort rules successfully loaded and available on the Network Decoder:

Unexpected Network Flows

The ASD & NSA guide suggests monitoring the network for unexpected web servers, and provides a snort signature that simply alerts when a node in the targeted subnet responds to an HTTP(s) request by looking for traffic on port 80 or 443 with a destination IP address in a given subnet:

alert tcp [443,80] -> any any (msg: "potential unexpected web server"; sid 4000921)

Rather than updating this rule with the right subnet details for your environment (that will only be available to be used by this rule), we can do this natively in NetWitness utilising the Traffic Flow parser and its associated traffic_flow_options file to label subnets and IP addresses. Using the traffic_flow_options file to do this labelling means the resulting meta can be used by other parsers, feeds, and app rules as well.

For more details on the Traffic Flow parser, go here: Traffic Flow Lua Parser 

To configure your traffic_flow_options file, start with the subnet or IP addresses of known web servers and add them as a block in the INTERNAL section of the file, and label them “web servers”. When traffic is seen heading to those servers as a destination, the meta ‘web servers dst’ will be registered under the Network Name (netname) meta key.

Once the traffic_flow_options file is configured, we can translate the Snort rule from the guide into an app rule that will detect any HTTP or HTTPS traffic, or traffic destined to port 80 or 443, to any system that has not been added to our definition for web servers:

(service = 80,443 || tcp.dstport = 80,443) && netname != ‘web servers dst’


That covers the network based indicators included in the ASD & NSA guide. For more techniques to uncover web shell network traffic, check out the pages linked at the top of this blog, as well as the RSA IR Threat Hunting Guide for NetWitness: 

Stay tuned for the next part where we take a look at the endpoint based indicators from the guide, and see how to apply them using NetWitness Endpoint.


Happy Hunting!

Filter Blog

By date: By tag: