-
Notifications
You must be signed in to change notification settings - Fork 373
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
Support for Mythic C2 #63
Comments
Great to see this initiative. Would be great to achieve this. The stated list is still valid for any type of C2. With the exception of the rtops name fields check. We've been very busy working to a v2 of RedELK that is C2 agnostic. Progress can be found in the maindev branch and the v2 beta1 release we put out just a few days ago. But before the list above can be worked on, Mythic should be able to output some logs. Cobalt Strike actually is a great example of the detail of desired logging. It has very detailed logs on the red team operator's actions on the implants (primary focus) and logs on generic events (secondary focus). Once there are logs, we can check on filebeat configs, logstash rules and all the others. But it starts with the logs :) Let me know if there are any questions on the logging setup. Happy to help. (tagging @its-a-feature with his correct handle :-) ) |
Mythic tracks a lot more data than cobalt strike and is a lot more descriptive about it too. It'll be pretty easy for me to push an update for it. I'm looking at an output like this:
extra newlines added by me for clarity. Essentially, they'd all be JSON entries (one per line) with a timestamp (UTC), a |
This capability is included in Mythic 2.1.1. Specifically, I initially only included the following types:
I can add more things, just figured that was a decent start. To enable the feature within Mythic, add the desired log name to There's a lot of stuff to parse, so I'm hoping that these values ( |
Great to see a C2 creator that has already thought about logging 👍 JSON log format should be workable. Havent used it yet, but Elastic has support for incoming JSONs. I expect no issues there. Looking at your example logs I see a lot of data that can be mapped to the fields that we track for RT operations. Could you have a look at the FieldNames list of rtops as well (https://github.com/outflanknl/RedELK/blob/maindev/example-data-and-configs/RedELKFieldnamesV2.md#Index-rtops) and let me know if there are data points missing within Mythic? I assume not, but just to be sure. Another aspect besides the logs are the actual screenshots and downloaded files. I assume these are also stored on the c2 server. Typically we would like to also transfer these over to the RedELK server. ao for easy accessing from the Kibana interface. With Cobalt Strike we take the approach of periodic rsyncing the files from C2 back to RedELK server, and presenting them in the /var/www folder, where Kibana has clickable links to the specific files. Would this approach fit Mythic as well? |
Glancing through it, I think pretty much everything is covered. Since Mythic has everything broken out into individual Docker containers, the C2 profile information might need to be pulled from the C2 container itself vs via a specific log that Mythic generates. This is because all the C2 profiles govern how their own stuff works within their Docker containers, so the HTTP profile for example is pretty straight forward with static headers, port, etc, but the dynamicHTTP profile (think CS' malleable c2) is a JSON configuration that's a lot more expressive, so we'd just have to think about how we'd want to handle it. For the files, Mythic stores all files in
^ notice the |
@its-a-feature that should be enough to start with, looking quickly at the sample log you posted it looks like we'll have plenty of information to put in 👍 |
Awesome! Yup, here's examples:
|
Is RedELK updated with the latest MITRE ATT&CK Sub-Techniques? That's one piece that I still need to update. I'm hoping it won't change the messages too much, but I haven't looked into it yet from a programming/logging perspective. |
Thanks for the example data! Really helps us getting started (when we find the time). Wrt ATT&CK nrs, there are two parts:
So if Mythic still does old style, you are on par with our slow dev speed :-D But even if you would get ahead of us, RedELK would be ready for parsing new style. |
Has there been any progress on this? Was curious in using this integration for a red vs blue exercise. |
AFAIk there hasn't been any movement on this side, but Mythic 3.0 now has logging as a separate docker container (ex: https://github.com/MythicC2Profiles/basic_logger), so you have full control over logging formats and what to do with the data. The container just listens for logging events over RabbitMQ and by default just writes them to stdout and optionally a file. Since you control that docker container though, you can update it to change formats and submit to RedELK in any format (or any SIEM). It would be cool if there was a supported RedELK logging container that did the format adjustments (if any are needed) for you |
Apol for the extreme delay by us on this. We have not made progress on this. Just many other things in life and work that require our attention. We appreciate any input from others on this though! |
Support for Mythic C2 - https://github.com/its-a-feature/Mythic
I just starting following the conversations to support Covenant C2 (#23) and immediately saw the same issues exist for Mythic (everything in a DB, no log files). I'd love to see Mythic support for RedELK, so can you all outline exactly what you'll need from Mythic to support log ingestion?
For Ghostwriter, we went the route of building Mythic Sync as a standalone tool that connects and listens for events to get the data where we want it, but isn't an ideal solution.
Is the list below (from Covenant Feature Request) the same items you'll need from Mythic/any other C2?
CC @its_a_feature
The text was updated successfully, but these errors were encountered: