Dual Window Mode

[ghost]

This is a feature request and not an issue with the code.

Dual window mode is using 2 or more terminals to control the agent, one for sending commands and one for receiving output (via tail -f of a log) for example.

This would prevent the intrusions (and prompt overwrites) caused by printing output to the same terminal and would make queuing commands for slower (stealthier) C2 channels much easier.

For even more granularity it would be nice to have the option in the default shells to have different windows for "True Output" (being the responses for the commands sent to the Agent), a debug window (for tracking chunks/messages and garbage recv'd), and then the command input window that would contain whatever info is programed into the prompt.

[operatorequals]

This is a great idea! My opinion on the topic was to create a condition and not print the prompt before getting a value back. But this would be a bummer if a command didn't expect any output. So your solution is crystal clear and would solve the prompt issue for ever!

The only problem is that I doubt the Dual/Multi Window mode can be achieved with just Python2.7 builtins... To resolve this we might follow 2 roads:

• Restructure the whole package to create a dev/full and a min/core version. The dev/full could take useful dependencies (like termcolor for Colorful Shells, or ncurses) and the min/core MUST be dependency free (so it can be minified into payloads, or loaded remotely through httpimport).
• Carefully insert dependencies to Handler-only classes. This is way more dangerous, for the future of the package, but quicker.

Anyway, if you want to implement this feature yourself (I'd appreciate that a whole lot!), you can have a look at BufferingHandler, which provides a thread-safe buffer and automatically stores messages (and streams) to it. Example usage of this class can be found in the SimpleBridge class, where it is used to create an intercommunication between 2 Handler objects.

The onMessage, onChunk and onNotRecognised methods can be hooked using a wrapper function, as you can see in handlerCallbackHook() in baseshell.py, and everything can be extracted from them, without re-implementing or extending them.

[operatorequals]

Just to note some progress, the task will be implemented using the native logging module, most probably wrapped with some arguments in *Shell class __init__() methods.

This approach will also help when a MultiHandler class gets implemented, multiplexing several *Handler objects, for RAT implementations. Its derivative of BaseShell will have a logger object, hence they will be able to log to different places.

Also the verbosity will be modifiable, to also log Valid Chunks, Unrecognized data, and probably stats.

[ghost]

I'm glad I was able to help out with some of the long term planning on this. After multiplexing is implemented are the loggers going to have "agent identifiers" or something similar to differentiate between what agent is interacting with what steam, also is that going to available to the user via a getter type function?

Also with the miltiHandler class: is that going to be able to be used to create different command and data channels? For example !os-shell could send it's commands over icmp while large messages (responses or files) are handled via HTTP or whatever.

Thanks for your work on this project. It's great!

[operatorequals]

Really thank you for your support! Means a lot, since I am new to project management and maintenance. Well, identifiers between Handlers are in way, already implemented through the Orchestrator getIdentity() method. It is not guaranteed to be unique, but it does the trick. Check the Identities part in the Documentation of Orchestrators and the example here.

Now, the multiHandler class, is currently a blank file, and it will remain as such, if ideas like the one you got keep spawning! The part of supporting different data channels for each command type (stream most probably), is really cool. Yet, way difficult to implement in a decent way. It is gonna be needed to install 2 (or more) Handlers to the victim host, each one supporting different extensions (file extension to the HTTP Handler, pythonapi and os-shell to the ICMP Handler, etc). On the handler's side, it is needed to be 2 Handler objects, receiving those connections, and interacting with them, not separately (different processes), but in the same context (same shell, etc).

So, to unify the Agent's Handler objects, and the Handler's Handler objects, another class must be created. This seems to be the MultiHandler class, which will also inherite the BaseHandler (or BufferingHandler so it can bridge messages around).

That MultiHandler, will most probably accept a list (set?) of Handler objects as arguments, so it can be stacked (a MultiHandler can be assigned as a MultiHandler child).

Yet all this needs so much internal modelling, and hopefully little (no?) changes to the already written interfaces (API).

In case you get any ideas for this, you know were to post them...

Thanks again!

[operatorequals]

Progress on this topic can be found in the latest commit 72b5369. The output and debug arguments in the covertutils.shells.impl classes redirect output to 1 or multiple (per-stream) files.

Some commenting on that is highly appreciated. Thanks a lot!