-
Notifications
You must be signed in to change notification settings - Fork 774
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Feature Request] Logging required for RedELK integration #221
Comments
So Covenant has an "Event Hub" that can be subscribed to, which is a websocket that pushes events happening out to everyone who's subscribed. Is that something that could be used, or does it have to be written out to a log file? |
As far as RedELK goes I would like keep the C2 adapters as simple and default as possible. That means that for current supported C2 frameworks PoshC2 we ingest text based logs with a simple filebeat config (default package part of the Elastic stack). Now, Filebeat can work with txt, json or whatever txt based logging. Websocket is not supported. Theoretically we could make a Covenant specific adapter with whatever fancy code we would like, eg websocket based. But that would 1) deviate from the setup of other C2s, and 2) not placed best at the hands of RedELK developers as we would always be behind the pace of development of Covenant. Ideally this (the fact there is detailed logging to log files) is regarded as new feature of Covenant itself. We as RedELK developers will have a busy time already making sure all the data is properly ingested and indexed within RedELK itself. |
If such "Event Hub" already exists, shouldn't it be possible to integrate a listener in Covenant that writes event to a log file? |
Digging into the code it looks like the concept of logging does exist, however the only time it outputs is if there's a fatal error when starting a listener/covenant. @cobbr, do you have thoughts on expanding the existing loggers to be covenant-wide and include more logging (e.g. Initial Grunt/Brute Callback, Grunt/Brute tasking, etc etc)? |
I agree that it makes more sense for Covenant to implement better logging than for redelk to try to turn websockets events into a coherent log. It's going to take some time to fine tune the logging just right. The last time I tried to enable logging, the logs would eat up all available hard drive space in a matter of days, lol. |
Please don't overdo it ;-) If you can get the same level of details as Cobalt Strike does, it should be good! |
Threw together an initial PR to support logging for this Issue. PR #244, take a look and let me know what you'd like added. Not quite the same level of detail as a CS beacon, but should be a start. |
Awesome! Do you have any examples of the logs it generates? Also paging @fastlorenzo , you may want to take a loot at this |
Really nice, indeed! Let's check what you have in this PR for now and then we'll see if some other things needs to be added/adapted to get an exhaustive view in RedELK 👍 |
Here's a general idea of what the logs output on specific covenant events. I'm open to changing them if that would make parsing easier for you guys or if @cobbr has a preference. By default the PR doesn't include Command Output but the code exists and can be un-commented out if someone wanted to include that in their logs.
I should probably update the OnCreateGrunt log message to include the property names to be consistent too, so that will probably be a change that's coming. |
I think it would be easier to parse in logstash with something else than a newline delimited (if possible for you) 👍 Regarding the logged data, what would be super interesting to have is everything that happens in the target network: tasks launched by operator + output, downloads, retrieved credentials, screenshots, keylogger data, etc. |
Something like this could be more convenient for parsing:
|
I agree, I think that output does look better, I'll work on changing that. Currently the logging does support new credentials, and tasks created by operators, however after discussing with @cobbr we decided on not including command output by default. However, I do have the code in there, which can be un-commented out if someone wanted to implement it. I've basically included all of the "important" data outside of the snippet I pasted here. |
That's great, thanks! I'll give it a try tomorrow and test parsing the output. Why did you decide not to log the command output? |
Just a lot of potential customer data being stored in plaintext logs that I don't really want to make it "the default". The code is still there and can be enabled, but I'd rather leave that up to the users. |
makes sense, could we make this a configuration setting instead? Just to avoid having the users needing to change the code itself to make it work 😄 |
I'll take a look when I have a bit of time, I'm currently revamping the logging logic so I'll look into that as well. |
Alright, so we finally have some movement on logging. Merged in @checkymander's PR, with a slightly altered log format if you want to start to see how it might fit in with RedELK @MarcOverIP |
Great, thank you. Whats the quickest way to get some example logs for us to work with? /cc @fastlorenzo |
@MarcOverIP Here's a few random samples. Might also be helpful to check the references for Covenant/Covenant/Models/Common.cs Line 12 in 5384760
covenant_2021-02-05.00.log |
Thank you, this helps to get started and very much looks like something that we can work with! We'll take this up when we closed off some pending issues on our side. Feel free to ping us if this issue remains open longer than you feel comfortabel with :-) |
Yep, no rush. I sure took my time on it, so don't feel like you have to rush for my sake. |
Awesome, thanks @cobbr ! |
Feature Request
We would want to have Covenant log its actions to a log file so we can work on RedELK integration (https://github.com/outflanknl/RedELK)
Covenant currently has some data in its sqlite db. But the info is not really sufficient and its not really doable for RedELK to parse that file in search for relevant logs.
Expected behavior
Ideally the logging by Covenant is done 1) text based, 2) follows a structured setup per log, 3) does timestamps in UTC, 4) logs operator actions, as well as relevant other actions such as keystrokes and screenshots received.
Overall I could say that if you follow the same approach as how Cobalt Strike does its logging, we should be good.
Additional context
The text was updated successfully, but these errors were encountered: