Intro
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.
Scenario
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_namegenerate_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 4dcd8c6d.ngrok.io 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 1where 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 4dcd8c6d.ngrok.io 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 profile.py file:
#!/usr/bin/python3
# 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.
Observations
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.
Conclusions
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.
3 Comments
