Sliver Bindings

[ntdelta]

Would you accept a pull request for Sliver bindings? I am happy to maintain a fork however it would be great to get it in. It would also be great to have a more abstract way of connecting other C2 frameworks too.

[neonbunny]

Yes! The less forks we have that force people to pick between them the better the end-user experience. This was kind of the idea with making more things "plugins", so that a single code base can be extended with (potentially private) functionality without needing to wrangle core updates between forks.

The CS integration (sadly) wasn't designed with other C2 extensibility in mind, but it certainly is something I'd love to see in SteppingStones. If you're still at the design stage, lets have a chat - otherwise fire over a PR as the basis for discussion.

[ntdelta]

I've been thinking about this a little and think the best solution would be a generic C2 connector, and then a small shim for each. The small shims could be submoduled in, allowing for private connectors. I also like the submodule method because then you can checkout tags that work with whichever version of the C2 you are using, then we don't need ifdefs for breaking changes to the API.

I think I'll make the generic connector more simple than the CS one, with just "collected files" and beacons as structured data for now. We can also have a generic JSON result type too as I think it's still important to be able to log all tasking activity.

Let me know what you think.

[neonbunny]

The submodules you describe sound like the existing "plugin" system which allows code to live in separate repos (or the main one), abide by a specific interface and then be added by a single line in the settings.py file.

As well as a core C2 interface, if we have extension points for "C2 menu items" then any additional functionality can hang off that. This is how things like reporting plugins work at the moment - with the interface just providing a way of wiring your own Django views & templates into the UI.

[ntdelta]

I've put together a rough example of how I see this working on my fork:

main...ntdelta:SteppingStones:main

Screenshot:

To summarise, I've used your plugin system to create a generic connector type, which can be implemented by submodules (In its current case, I've just made an example_connector for demonstration purposes). If none are submoduled, the feature will be hidden from the user as to not bloat the interface.

If a connector is present, it will become available in the menu:

Free-form JSON will be passed straight through to the constructor that will enable auth with the server. The poll mechanism uses the existing process_tasks functionality and follows a "connect, health_check, retrieve data, disconnect" loop for each active C2 Server.

Before I continue (I still need to add the type converters for Beacons and Files etc and add the reporting bits), I'd like your feedback!

[neonbunny]

Hey - great progress! A couple of things come to mind from your description (without looking at the code yet), but they're not show stoppers...

The JSON config feels a little too user unfriendly/error prone. Assuming a submodule is an "app" in Django terminology it can have its own migrations and templates, so we should be able to create custom config model(s) in the DB and provide a dedicated config page for each module. This is how I have implemented a current (private) "EventSource" based on the EventStreamSourcePluginPoint.

The polling cycle might need to be more flexible. For example, Cobalt Strike's mechanism currently uses a single, long-lived connect to a Team Server, and when I looked at integrating Outflank C2, it wanted to use a push mechanism, requiring Stepping Stones to host some kind of service to receive events.

[ntdelta]

I'm going to give the polling cycle some thought, as I can't think of a nice way to share instances of connectors between the background worker process and the normal Django processes.

This is an issue as the health check button would need to be able to be able to access the object with the active connection to the team server in your example. I could schedule tasks from the main process and retrieve the results from the database but that gets very messy.

As for the JSON point, I was hoping custom connectors wouldn't touch the database migrations at all, making the connectors manage state themselves. You'll see what I mean in the diff. User-interface wise, the JSON would usually just be IP, Username, Password so hopefully not too ugly. Although maybe I can support a way of connectors registering UI components that map to the JSON in the backend or something.

Making them as lightweight and quickly dev-able is the aim as that's my barrier to using other C2. This is why I'm trying to do all the heavy lifting in the Abstract Base Class.

I'm very busy over the next few weeks but will look as the polling problem at some stage.