Koadic C3 : Command & Control Decoded
2021-07-28 | 12 min read
We decoded the Command and Control Framework Empire in our previous blog post and promised to take a similar deep dive into other C2 frameworks. So, in this blog we look at the other popular C2 framework Koadic which has been used by threat groups like APT-28 , MuddyWater and SideWinder.
Fig 1 – Executing mshta on the victim
So first let’s look at the request and responses exchanged in the Staging Phase of the framework.
There are 3 main request and responses that are exchanged in the staging phase for Koadic.
The first one, victim sends a GET beacon with the URI set as the endpoint (45mwl) of the listener, expected from the command executed on the victim. The server sends back a payload which is XOR encoded.
Fig 2 - Stage 0 Request Response
- Variable names are replaced with random characters to make it hard to read.
- Spaces and comments are removed.
- Each byte of the script is XOR'd with a randomly generated key, converted into hex and sent with the XOR key included.
The XOR key can also be seen in the payload
Fig 3 – Stage 0 XOR Key
Fig 4 – Stage 0 JS script
And we copy the pyalod to a script
Fig 5 - Stage 0 JS script
And we replace the marked function name with console.log and run it as a js file, we can decode the script.
Fig 6 – Stage 0 JS Script Decoded
In stage 1, the victim sends a POST request with the URI as in the picture.
Fig 7 – Stage 1 Request Response
Here is what the various parts of the URI named as per Koadic -
- 45mwl - Endpoint
- XM1W23L6ML - Session Name
- 43185669d1b246e2b7359d696bb93260 - Session Key
- GM6YW38MHP - Job Name
We also see in the payload, various victim host related info like -
- DESKTOP-7BSBJKM - hostname
- Ayan - username
- Windows 10 Pro - OS
- AMD64 - OS architecture
And the server responds with a 500 Internal Server Error (Default Reply).
Then the victim once again sends a GET request with the same URI as before with some additional data. The server in response sends another payload, which can be decrypted/decoded in the same way as before.
Fig 8 – Stage 2 Request Response
In most of the C2 frameworks that I have seen until now, the victim manages persistence to the C2 server by sending periodic beacons to the server, which the server may or may not send any task to be performed. This behavior increases the chances of getting detected as there will be lots of unnecessary traffic.
In case of Koadic we see a different approach taken, it keeps one of the TCP connections from previous communication open, so whenever the server needs to contact the victim for any task, it can just reuse that connection to contact.
Here in the staging phase itself, we can see there is a request which is sent by victim to which server doesn’t reply immediately.
Fig 9 – Unclosed TCP connection
But when we issue any task for the victim, server sends a reply in this connection with a hex string, which makes the victim open a new connection for the task related purpose.
Fig 10 – Unclosed TCP connection reused
One thing to note would be that a TCP connection kept opened for longer times can also raise alarms, so after a certain period of time the server close the current connection and instructs the client a new one.
Post Exploitation Module Execution
We now look at the traffic exchanged when the C2 completes its staging phase and the server executes some commands on the victim. We executed ‘dir’ command on the victim, and took a look at the request responses exchanged.
The victim sends a GET request.
Fig 11 – Task Request Response
Here 7fbd0714c892405e9d879877dbb44fe8 is the same hex string which was sent by the server in that unclosed connection to initiate this GET request from the victim. To its response, server replies with a XOR encoded message, which when decoded, becomes a large payload with the ‘dir’ command embedded in the script.
Fig 12 – Task Command Decoded
Victim then executes the command and returns the result in a POST message in plain text, and the server replies with the a 500 Internal Server Error message.
Fig 13 - Task Output
Leverage Subscription Service to Stay Ahead of Attacks
ATI has just released a very detailed implementations of Koadic C2 Framework as part of BreakingPoint System’s recent updates.
The superflows released are heavily customizable allowing users from using their own keys for payload traffic encoding to using one of the many implemented post-exploitation modules supported by Koadic.
Fig 14 – BreakingPoint Koadic Superflow
Use BreakingPoint’s huge collection of Security applications to do robust testing of your DUT against malicious traffic like Koadic and much more. More Command-and-Control applications might be added in the future releases.
For more details about Keysight Breakingpoint, visit BreakingPoint. This concludes our little venture into understanding Koadic from the network perspective.