Feature Request: Persistent Listener and Agent Information

[th31nitiate]

I am not sure if I am reading the documentation correctly. I feel that Merlin makes a useful post exploitation. It does not however seem to provide capabilities related state management. It seems all data transaction are done in memory which is cool for security when running large nets.

In the interest pen testing I am wondering about what methods are available to manage agent state and if the application is intended to be used in that way.

Issue: Agent information does not persist across application restarts.

Sorry I did not use slack as this may have been something more suited but I dislike, preference is discord, rocket chat or something.

While posting this I came across the following: https://docs.mythic-c2.net/

I still need to read through it but there is a postgres db in their so it may do what I intend to do unless the DB is for use with the ACL for the UI :(

[Ne0nd0g]

Thanks for sharing this feedback. Do you have an example of what "state management" functions you would like to see?

As you mentioned, Merlin intentionally does not use a database. Information does not persist between reboots. Do you have an example of a problem that is caused because of this? What kind of information would be useful to persist? If the server restarts, and old agent can still check in and work.

If you are not a fan of the Merlin server command line interface and capabilities, you can always use Mythic as a controller for Merlin https://github.com/mythicagents/merlin

[th31nitiate]

The key thing I suppose was to have store of agent information and the ability for the agent to possibly reconnect when the merlin restarts. This could be a SQLite db or something that can be encrypted in a particular fashion on the system.

The concept being botnet like feature or something similar how metasploit db stores information. I think it should be fine. In short as long as you set up the listener it should well and agent if it still active will automatically register I believe.

[Ne0nd0g]

There is a store of agent information in the logs directory. It contains a folder for every agent, connection information, and all the executed commands along with the result.

Merlin already has the functionality for the agent to reconnect when the server restarts or goes dark for a while. If the agent is active it will currently automatically register when it checks in next.

Do you have an example use case of where a database would overcome a limitation? Because the server already supports auto register after the server is restarted, that wouldn't be a limitation.

[th31nitiate]

If this works as described it should be fine. Its just when I done a reboot and I went to look the listener was no longer configured. The sessions showed nothing pretty much. It had me wondering that even in this case a configuration file would be useful. Though its not much work to get the listener reconfigured.

I think it should be fine when using just the log file. I don't think a database would necessary in this instance considered the information you have provided.

[Ne0nd0g]

OK, this helps a lot. You want the listener to persist between reboots and the Agent session table to populate based on active agents before the shutdown.

I have contemplated a configuration file, especially because it would ease the startup process. I can look at implementing something to incorporate this.

[th31nitiate]

Yes, that is a perfect description of what I had in mind. Though it is something that may simplify things I am not sure how well it well fair.

I would love to help with this but my go lang is not so great. I wonder how people tend to use this. Is it that they are working on systems that run for a prolonged period of time or creating listeners based on specific requirements at runtime ?

[MavericksGooses]

Just for a bit of clarification on this topic; if the computer that the agent is running on restarts, that agent no longer appears as an active callback on Mythic and therefore cannot be interacted with again? Essentially no agent side persistence?