Insights > Network Visibility + Security

Koadic C3 : Command & Control Decoded

2021-07-28  |  12 min read 

Introduction

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.

Koadic is available open source on Github. It is written in Python and works primarily with JavaScript based payloads. As for encryption techniques in Koadic, it does support TLS but on HTTP it doesn’t use any payload encryption unlike most C2 Frameworks, instead it uses XOR encoding, which can be decoded pretty easily since the XOR key is embedded in the payload itself. We will be using the default mshta or Microsoft HTML Application stager provided by Koadic.

                                                                        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.

Staging

There are 3 main request and responses that are exchanged in the staging phase for Koadic.

STAGE 0

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

We can see the embedded Javascript function has been obfuscated to avoid detection. After analyzing the framework’s source code, we need to understand the obfuscation steps Koadic takes.

  • 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 JavaScript code is then embedded in a html document.

 

The XOR key can also be seen in the payload

                           Fig 3 – Stage 0 XOR Key

 

The logic for the de-obfuscation of the script needs to be provided in the payload itself as the initial stager is executed on the victim. If we extract the entire JavaScript section out of the pcap.

                                                                       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

STAGE 1

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).
 

STAGE 2

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

Beaconing

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


Task Output

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.