Kraken Fundamentals - I

We are starting a new year and with it comes new opportunities and new challenges!

I want to start this 2023 by presenting a project I have been working on for more than a year. And which will be presented at the next Hackplayers Conference (Hc0n) to be celebrated on February 24 and 25 at La Nave (Madrid).

To start with the explanation, first I need to “seek at the beginning”, where it all started and continue from there.

This will be the first in a series of posts where I will talk about Kraken, how it works internally and how it can be used.

So, grab a snack and… let’s get started!

Introduction #

During one of my Red Team exercises, I was able to compromise many web platforms of client perimeter. The vulnerability I exploited allowed me to deploy a Webshell¹ on each of the compromised servers.

The reason why we deploy a Webshell instead of using another vector, is to provide as well an execution vector ( TA0002) as a way to maintain access ( TA0003) to the compromised machine.

At this point, I was going to start with the reconnaissance, as I was used to do. However, after sharing the findings with my colleagues, I was warned of the possible existence of EDR’s² in the compromised servers.

As these are machines exposed to Internet (Endpoint³), they should have a stronger Hardening⁴ policy than other computers in the organization.

It was at this point that the first problem appeared to me:

How can I verify this premise without attracting attention?
— (because it’s it is highly probable that the command execution was monitored)

In order to solve this problem, I quickly implemented a proof-of-concept “webshell” that would allow me to perform basic operations on the system in order to check it.

After using it on one of the compromised servers, I was able to confirm that there was a Linux agent of a well-known EDR which was in operation.

This complicated the situation, since it was known in advance that the product would detect any attempt of enumeration using traditional webshell actions.

And there is where the next question was discussed:

How I can do a complete reconnaissance without being detected?

And from the answer to this question, a very minimalist version of what Kraken is today was born.

What is Kraken? #

Kraken is a tool that allows you to manage webshells in multiple programming languages. Maybe we could say that it is something like a “webshells orchestrator”.

However, the goal that Kraken follows is: to give you the ability to operate as silent as possible. Using, for this purpose, all resources available by the programming language and the operative system.

How does Kraken work? #

Kraken’s execution flow can be simplified in the following diagram:

On the one hand, we have the Kraken’s Client which is a Python script that can be used to generate webshells and connect to them once they are deployed.

And on the other hand, the Kraken’s Agent with which we get to execute the modules that will allow us to obtain the information we are looking for during the reconnaissance procedure.

Later on we will go deeper into all these components involved in the operation of the tool and why they are there.

What programming languages does Kraken support? #

Currently, Kraken supports:

• PHP (for PHP web services)
• Java (for JSP)
• .NET (for ASPX)

Obviously this is only a part of all the web technologies currently available, however, I have chosen these three ones because they are the most common and it allows face the problems that appear during the development.

Those who cover too much, they obtain too little. — Popular Spanish proverb

On the other hand, Kraken agents or webshells have been tested on the following operative systems:

• Windows (different versions)
• Linux (different distributions)

Then, a question that arises (or has been there from the beginning) is the following:

What makes it different from other well-known webshells? #

Kraken gathers a set of characteristics that have been designed to improve the use of the tool and provide a different view of the use of webshells. Some of the features that make it different from the other tools are:

1. Execution of system commands is prevented (its main feature and the purpose for which it was developed). This property makes it very useful on systems where it exists an active monitoring or with the presence of some security solutions which can detect our movements.

2. Its modular design presents some advantages and strengths against other tools:

   1. It allows to maintain a multi-version system with which, is determined at runtime, those modules that can be loaded based on the information reported by the agent with whom it communicates.
   2. The hierarchy chosen for the module system allows “hot-editing” of the modules in use. In the same way, it’s possible to register modules without stopping program execution.
   3. The development of each module seeks to get the maximum exploitation of the language features to get the best recreation of the commands which have been traced. This tends to generate larger modules but with better results.
   4. The templates provided for each language make it easy to extend Kraken’s functionality and create new modules.
   5. Since modules are managed as files, the use of symbolic links (for cases where the implementation does not vary depending on the version) avoids “duplicity” of the modules.

   

3. Kraken provides a Cross-Compiling system without added dependencies that allows, for the cases in which it is necessary, to compile the modules without having to worry about having the requirements installed on the machine. This has been achieved thanks to the integration with Docker⁵.

4. There are currently two modes of using Kraken:

   1. The “Standard” Mode (ST): which is the traditional way webshells work (request-invoking-response style).
   2. The “Command-and-Control” Mode (C2): whose operation is similar to that of a C2 using the load-invocation-unload method of modules using session variables (to be discussed in detail in future posts).

5. Communication flexibility through the use of connection profiles. It is possible to detail all the information about how the communication between client and agent is going to be from a JSON file that follows a specific schema.

Additionally, Kraken also provides utilities such as:

• A pseudo-terminal with basic console capabilities.
• Error control in Agents, Modules and Client.
• Integrated Logging and History system.
• And other utilities related to the tool.

Conclusions #

This brings us to the end of the first part. In the following posts I will go deeper into the internal structure of Kraken, the elements that influence its operation as well as practical examples of use. So don’t miss what comes next!

I hope you have enjoyed it and see you soon!