During a Red Team engagement, doing the technical work is only one part of the job.
The harder part is often keeping everything organised while the engagement is still moving. You collect scan results, screenshots, notes, identities, access paths, and evidence from different tools. A few days later, you may need to remember exactly when something was discovered, which output proved it, whether it was in scope, and whether temporary changes were cleaned up.
I built OpLog because I wanted a small tool for that part of the work.
OpLog is not a scanner, an exploitation framework, or a C2 platform. It does not try to replace the tools that operators already use. Its purpose is simpler: keep an engagement ledger that is easy to review later.
The project creates a local workspace for each engagement. It records important events, links them to evidence files, calculates hashes for artifacts, and generates simple Markdown reports for the timeline, evidence register, and cleanup status.
One of the main ideas behind OpLog is separating two kinds of information.
The first is report-safe information: what was observed, which host was affected, which evidence supports the finding, and what cleanup was completed. This is the information that should help with reporting and internal QA.
The second is operator-only information: passwords, hashes, tickets, tokens, and other sensitive values that may be needed during an engagement but should never appear in a report or normal evidence folder. OpLog keeps those short values in a separate encrypted Vault.
I also wanted cleanup to be a first-class part of the workflow. In real engagements, it is not enough to prove access. You also need to know what temporary artifacts were used, where they were deployed, when they expire, and whether they were removed.
OpLog is still small and early. At the moment, it can store and hash outputs from tools such as Nmap, ffuf, Burp, BloodHound, Certipy, and Nessus, but it does not parse them automatically yet. That is planned for later.
The goal is not to build another oversized Red Team platform. The goal is to build a practical, local-first tool that helps an operator answer a simple question at the end of an engagement:
What happened, what proves it, what is still sensitive, and did we clean up properly?
The project is available on GitHub:
