Updates to Ghostwriter: UI and Operation Logs
Sep 30 2020
By: Daniel Heinsen • 7 min read
Read First:
If you’re new to Ghostwriter, start with this blog post to understand the project’s goals: https://posts.specterops.io/introducing-ghostwriter-part-1-61e7bd014aff
For those of you lacking the desire or the attention span to read another blog post, here’s the gist:
- Ghostwriter is a web-based red team report generation tool
- Ghostwriter can keep track of clients, projects, findings, and infrastructure.
- Ghostwriter automates routine assessment reporting tasks allowing operators to focus their time on analysis and custom content creation rather than formatting.
Intro
For the past couple months, a few of us at SpecterOps have focused on updating Ghostwriter to improve usability, enhance reporting, and enable the project to serve a more central role in the red team engagement process. We’d like to highlight some of these changes and initiatives as we are eager to get them into your hands. We’re pretty excited about this and hope you will be too!
Updated User Interface and Experience
First, we are working towards a cleaner code base and a better user experience. Many of these changes are live right now on GitHub, but we have an official release planned for later this year that will contain many more enhancements and performance improvements. Ghostwriter now uses more AJAX requests to submit requests in the background and reduce page loads and refreshes. This alone is a big improvement to the overall user experience.
As you will see below, we have also added support for WebSockets, and we’re using them for some neat things! You can expect to see new real-time toast notifications and page updates. The most exciting use of WebSockets is certainly the new operation logging application.
Operation Logging
Any professional red teamer quickly understands the importance of tracking and keeping detailed logs of their actions during an engagement. If you ever have to deconflict red team activity with a client, accurately document a finding, or reconstruct an attack timeline, you’ll have detailed information about what command was executed at what time by whom. We refer to this as operation logging or “oplog” for short. At SpecterOps, we’ve historically aggregated any operator activity (action performed via a C2 tool, web browser, or operator terminal, etc) into a web-based internally hosted spreadsheet. Any actions against a client’s network are recorded here in a running list of timestamped activities. As a result, the engagement lead, team members, or other stakeholders can see a complete timeline and picture of the engagement.
Unfortunately, this completely manual approach of a shared oplog sheet is tedious to maintain and error prone. Furthermore, the vast majority of our red team activities are post-exploitation related and occur through C2 tooling (Mythic, Cobalt Strike, etc) that already have built-in logging. Since operators must enter these commands by hand into a log, it routinely shifts focus away from operating. In the best case, it reduces their efficiency, and in the worst case, results in inconsistent logging throughout the engagement. Additionally, during the reporting phase, any command, evidence, or timestamp that we want to include would still need to be manually copied over from the spreadsheet to Ghostwriter or the final report.
Operation Logging (Oplog) for Ghostwriter has a few goals:
- Reduce the manual logging overhead and automatically log each operator command, regardless of tool used via a standard API
- Enable operators to go back and add context\detail\follow-up actions their entries within the oplog
- Must allow addition of manual entries when they make sense (e.g., web browser interactions, non-instrumented tools, social engineering attempts, deconfliction requests, etc)
- Enable reporting automation and analytics with oplog data
- Easy import data from “offline” tools and export oplog data
Operators now have a central log of all commands performed on an engagement in an easily importable/exportable format that can also be automatically included in report generation (not yet implemented). Operators can manually create an entry, or they can be automatically created using the exposed REST API. This allows C2 frameworks like CobaltStrike and Mythic to seamlessly integrate and allow the operator to keep their mind on the engagement and not on bookkeeping. We envision the Ghostwriter oplog page will be a staple in your red team engagement workflow and have a permanent spot on your coveted screen real estate.
Oplog Features
Complete documentation for Ghostwriter’s oplog feature can be found at https://ghostwriter.wiki/features/operation-logs, we’ll cover some of the basic features here. Out of personal pride and a matter of principle, we refuse to read the documentation of a new project unless we have already struggled with it for at least 45 minutes, and we don’t expect any less from you.
Backend Operation Overview
The oplog page uses websockets and async.io on the back end, so changes are immediately pushed to all those who are viewing the oplog. This allows for easy collaboration and immediate feedback. When an operator enters a command in a CobaltStrike beacon, the command, time, operator, user context, and hostname are all immediately logged and displayed on the oplog page. In the case of Mythic, whenever the command produces output, that output is also logged. Similar to a spreadsheet editor, the user can double click into any cell and modify the contents. Every modification is immediately sent over a persistent websocket connection and reflected for everyone using the page. This provides operators with immediate feedback when a command has finished or another operator added a comment.
REST API
Ghostwriter operational logging has a rudimentary REST API that allows external entities to create, update, and delete oplog entries. This allows us to integrate any C2 framework with relative ease. As we continue development, we plan on adding other commonly used tools such as proxychains, web browsers, and popular shells.
Real Time Operation Log Updates
An entry being auto-populated from the mythic sync utility
Easy to import/export operation logs
If you have a set of commands from another tool, they can be imported into Ghostwriter with (probably) minimal modifications. Ghostwriter can import/export CSV files for operation logging. There are times when our CobaltStrike teamservers are on a client VPN and we can’t access our internal infrastructure, including Ghostwriter. In this scenario, we have an aggressor script that will log each command to a properly formatted CSV file that can then be imported into Ghostwriter at the end of the engagement.
Simply upload a CSV to import commands that were logged to a CSV file.
Easy to copy entries
If you ever had to manually enter commands to a log, you’ll know how much you will end up repeating yourself. To aid in that, Ghostwriter has a copy button at the very right of the row. If you do need to manually create a bunch of entries, say a web based form submit, then you wont need to hand copy/paste everything, saving you time.
See only the columns you want
We know that not all the columns in the oplog table are helpful all the time. In order to save some screen space and present you with the most pertinent information, you can select the columns which you want to display and hide all the rest. Nobody wants to read the comments anyways.
The Future for Operation Logs in Ghostwriter
- Many red teams, ours included, have sensitive data age-off policies. Data should be tagged with appropriate sensitivity levels and automatically aged-off (deleted) when appropriate.
- Oplog extensions for more red team tools like bash (operator command line history), ssh, proxychains, etc.
- Objective IDs — Users will be allowed to associate a command with a particular objective. This will make report generation easy as one can easily export all the commands executed in support of a particular objective.
- Finding IDs — Users will be able to associate oplog entries with a specific report finding
- MITRE ATT&CK ID — Users will be able to associate TTPs with each oplog entry (this will be automatic for some tools that already track this data)
- Evidence — Attach evidence directly to an oplog entry (e.g., screenshot)
- Daily activity summary
- Engagement timeline
- Automatically map evidence from oplog entries to their associated findings
- TTP Roll-up
What do you think of the latest updates? What suggestions do you have for these new features? Reach out on the project’s GitHub page or on Twitter:
