## https://sploitus.com/exploit?id=28693732-E33F-5C52-B1F0-8E2C24F9F5A9
# eJPT Mission Framework
An evidence-backed Markdown workflow for running authorized penetration-testing labs without losing the plot.
## What the hell is this?
This is **not** a scanner, exploit framework, command collection, or automated hacking tool.
It is an external memory and state-management system for a penetration-testing engagement. One person operates the tools; an architect—human or AI—maintains a small, auditable model of what is known, what is merely suspected, what access still works, and what should happen next.
The framework was developed during a real randomized eJPT-style training engagement. The repository contains both:
- a [blank engagement template](Engagements/_TEMPLATE/index.md) you can copy; and
- a [sanitized completed case study](Engagements/CURRENT/index.md) showing the framework under real operational pressure.
The basic idea is simple:
```text
Operator executes actions.
Architect maintains mission state.
Evidence decides what is true.
CURRENT records the one thing happening now.
```
## How to actually use this
1. Download or clone this repository.
2. Open the repository folder as an Obsidian vault.
3. Open Obsidian's local graph and keep it visible next to Codex. The graph is
the visual mission map; the Markdown files remain the source of truth.
4. Open Codex and give it access to the same repository folder.
5. Tell Codex:
```text
Read AGENTS.md and follow its bootstrap instructions.
Explain the current engagement state, then wait for my question.
```
6. Ask a normal question or give Codex the latest operator output. For example:
```text
Where are we, what is currently confirmed, and what should I do next?
```
Codex should read `CURRENT`, follow the active mission and phase links, use only
the relevant evidence, and return one next action. You operate the tools and
give the resulting output back to Codex. Codex updates the engagement state.
### Start a new engagement
The repository includes a completed sanitized engagement so you can see the
system working. To start your own, tell Codex:
```text
Read AGENTS.md. Preserve the included completed case study, then create a new
Engagements/CURRENT from Engagements/_TEMPLATE. Walk me through SCOPE.md and
OPERATOR_ENV.md, create the initial mission node and phase, and stop before any
testing begins.
```
Define authorization and scope before doing anything against a target. Once the
workspace is initialized, continue by asking questions normally and returning
evidence as you collect it.
### Resume after closing everything
Reopen the same folder in Codex and Obsidian, then say:
```text
Read AGENTS.md, recover the current engagement, and tell me the active question,
current access, blocker, and next action.
```
You should not need the previous chat. Recoverable state lives in the repository.
## Why it exists
Long technical engagements tend to decay into chat transcripts, terminal history, screenshots, half-finished notes, duplicated credentials, stale routes, and conclusions nobody can trace back to evidence.
That creates predictable failure modes:
- enumeration gets repeated because nobody remembers what was already checked;
- dead sessions are treated as live access;
- credentials are copied into several files and drift out of sync;
- guesses gradually turn into “facts”;
- the operator regains a shell but not the path required to resume the objective;
- a context reset, new chat, or second operator destroys continuity;
- reports contain claims that cannot be traced to raw output.
This framework keeps the operation recoverable. After a break, the team should be able to open a few files and answer:
1. Where are we?
2. What access and routes are currently valid?
3. What exact question are we trying to answer?
4. What evidence supports the current belief?
5. What is the next single useful action?
## The mental model
The engagement is treated as an evidence-backed mission-state machine.
| Component | Purpose |
|---|---|
| `STATE/CURRENT.md` | The operational pointer: current position, active question, blocker, and next action |
| `MAP/` | The mission graph: meaningful access states and transitions |
| `PHASES/` | One operational question per file, with its answer and evidence |
| `OBJECTS/HOSTS.md` | Canonical host registry |
| `OBJECTS/CREDENTIALS.md` | Canonical credential and hash registry |
| `OBJECTS/ROUTES.md` | Canonical reachability and access-regain registry |
| `EVIDENCE/` | Curated evidence notes and the command ledger |
| `EVIDENCE/RAW/` | Preserved tool output before interpretation |
| `STATE/ARCHIVE/` | Snapshots of meaningful mission transitions |
| `log.md` | Chronological narrative of the engagement |
| `tools/vault_lint.py` | Read-only structural drift and broken-reference checks |
In shorthand:
```text
CURRENT is HEAD.
MAP is the mission graph.
PHASES answer operational questions.
OBJECTS preserve identity.
ROUTES preserve reachability.
EVIDENCE supports claims.
ARCHIVE preserves transitions.
```
### Mission state is not question state
This distinction is the core of the architecture.
A **mission state** is a durable operational position, such as:
```text
EXTERNAL -> WEB_ACCESS -> HOST_USER -> HOST_ADMIN -> INTERNAL_ROUTE
```
A **question state** is temporary reasoning inside that position:
```text
Can the current account access the administrative share?
```
Mission states belong in `MAP/`. Questions belong in `PHASES/`. Failed hypotheses do not become graph nodes. This keeps the graph readable even when the investigation contains dozens of attempts.
## Who does what?
### Operator
The operator touches the environment. They run the command, use the browser, manage shells, and return the actual output. The operator does not need to maintain the whole state model in their head.
### Architect
The architect maintains the engagement model. They preserve evidence, separate facts from inference, update the correct owner files, resolve phase questions, and recommend one next action.
The architect can be a person, an AI assistant, or a combination of both. If an AI is used, the Markdown vault—not the chat history—is the source of truth.
## How an action moves through the system
Every useful action follows the same loop:
1. Read `STATE/CURRENT.md`.
2. Open the active `MAP` node.
3. Open the active `PHASE`.
4. Give the operator one bounded action.
5. Preserve important raw output in `EVIDENCE/RAW/`.
6. Extract only confirmed facts into the active phase.
7. Mark the phase `confirmed`, `rejected`, or `still_open`.
8. Update the owning host, credential, route, or command registry.
9. Snapshot a meaningful transition in `STATE/ARCHIVE/`.
10. Move `CURRENT` and record exactly one next action.
```text
Action
-> raw output
-> confirmed evidence
-> phase decision
-> registry update
-> mission transition
-> next action
```
The ordering matters: **state first, advice second**.
## Quick start
### Requirements
- an environment you are explicitly authorized to test;
- any Markdown editor;
- Python 3 only if you want to run the included lint checks;
- optionally [Obsidian](https://obsidian.md/) for wiki-links and graph navigation.
Obsidian is convenient, not required. Plain Markdown is the source of truth.
### 1. Download and inspect the real example
Download the repository with GitHub's **Code → Download ZIP** option, or clone it
using the URL shown by GitHub. Then open the repository folder in Codex and
Obsidian.
Read these in order:
1. [Case-study index](Engagements/CURRENT/index.md)
2. [Final current state](Engagements/CURRENT/STATE/CURRENT.md)
3. [Engagement log](Engagements/CURRENT/log.md)
4. [Evidence index](Engagements/CURRENT/EVIDENCE/PUBLIC_INDEX.md)
5. [Sanitized final report](Engagements/CURRENT/REPORT_Syntex_Pentest.md)
6. [Publication and redaction note](Engagements/CURRENT/PUBLICATION_NOTE.md)
Then follow links from a mission node into its phase and supporting evidence. That path shows how the model connects a strategic state to the raw facts that justified it.
### 2. Create a fresh engagement
The repository ships with the completed example in `Engagements/CURRENT`. Preserve or rename it before creating your own live workspace:
```bash
mv Engagements/CURRENT Engagements/EXAMPLE_COMPLETED
cp -R Engagements/_TEMPLATE Engagements/CURRENT
```
Now edit these files:
1. `Engagements/CURRENT/SCOPE.md` — authorization, targets, exclusions, and time limits.
2. `Engagements/CURRENT/OPERATOR_ENV.md` — how tools run and how the lab is reached.
3. `Engagements/CURRENT/STATE/CURRENT.md` — initial state, active question, and first action.
4. `Engagements/CURRENT/MAP/` — create the first real mission node from the supplied template.
5. `Engagements/CURRENT/PHASES/` — create the first operational question from the supplied template.
The full operating rules live in [01_README.md](01_README.md). The compact architecture is in [Framework.md](Framework.md).
### 3. Run the engagement
Do not begin each session by rereading every note. Resume in this order:
```text
CURRENT
-> ROUTES
-> CREDENTIALS
-> active MAP node
-> active PHASE
-> HOSTS only if needed
```
Recovery is complete when the active question can be resumed—not merely when some shell has been regained.
Keep `CURRENT.md` small. It should be a dashboard and pointer, not a transcript.
### 4. Import evidence
When the operator returns scan results, shell output, screenshots, credentials, hashes, or notes:
1. save important original text under `EVIDENCE/RAW/`;
2. add the command and result reference to `EVIDENCE/COMMAND_LOG.md`;
3. summarize confirmed findings in the active phase;
4. update the one canonical registry that owns the new fact;
5. change `CURRENT` only if the operational decision changed.
Never silently upgrade a guess into a fact. Use explicit labels such as `confirmed`, `rejected`, `still_open`, `inconclusive`, or `stale`.
### 5. Validate the vault
Check the active engagement:
```bash
python3 tools/vault_lint.py --engagement Engagements/CURRENT
```
Check the entire repository:
```bash
python3 tools/vault_lint.py --vault
```
The linter is read-only. It looks for structural drift such as missing owner files, broken state references, unresolved active pointers, or malformed phase metadata. It does not prove that a technical conclusion is correct.
## A small example
Suppose the current phase asks:
```text
Can the confirmed web access produce an operating-system session?
```
The operator performs one authorized test and returns output. The architect then:
- stores the original output in `EVIDENCE/RAW/`;
- records what the output proves in the phase;
- marks the phase `confirmed` or `rejected`;
- creates or updates the relevant host/access objects;
- archives the old state if access materially changed;
- moves `CURRENT` to the new mission node;
- recommends the next question, such as local privilege or route discovery.
If the attempt fails, the failure remains evidence in the phase, but it does not clutter the mission graph with a fake state.
## Repository layout
```text
.
├── README.md # You are here
├── AGENTS.md # Codex bootstrap instructions
├── 01_README.md # Full operating constitution
├── Framework.md # Compact design model
├── Graph Groups.md # Suggested Obsidian graph setup
├── Engagements/
│ ├── _TEMPLATE/ # Copy this for a new engagement
│ └── CURRENT/ # Sanitized real completed case study
│ ├── STATE/
│ │ ├── CURRENT.md
│ │ └── ARCHIVE/
│ ├── MAP/
│ ├── PHASES/
│ ├── OBJECTS/
│ └── EVIDENCE/
│ └── RAW/
└── tools/
└── vault_lint.py # Read-only structure check
```
## One fact, one owner
Duplicating facts creates drift. Each kind of fact therefore has one canonical owner:
| Fact | Canonical owner |
|---|---|
| Current objective and next action | `STATE/CURRENT.md` |
| Strategic position and transitions | `MAP/` |
| Answer to an operational question | `PHASES/` |
| Host identity | `OBJECTS/HOSTS.md` |
| Credential or hash | `OBJECTS/CREDENTIALS.md` |
| Access and network route | `OBJECTS/ROUTES.md` |
| Tool output | `EVIDENCE/RAW/` |
| Command history | `EVIDENCE/COMMAND_LOG.md` |
| Operator runtime details | `OPERATOR_ENV.md` |
| Completed transition | `STATE/ARCHIVE/` |
Other files may link to a fact. They should not maintain competing copies of it.
## Git history and mission history are different
Git protects file history. It lets you inspect changes and recover earlier versions.
`STATE/ARCHIVE/` and `log.md` preserve operational history. They explain why the mission moved, what evidence existed at the time, and what could be resumed later.
Use both. A commit hash is not an operational state summary, and a mission
snapshot is not a backup.
Useful commit points include:
- initial reconnaissance imported;
- access confirmed;
- privilege changed;
- a pivot route became usable;
- a new host was discovered;
- the engagement was completed or archived;
- the framework itself changed.
## The included case study
`Engagements/CURRENT` is not a clean fictional walkthrough. It is a sanitized export of the real completed randomized training-lab engagement that shaped the framework.
It intentionally retains complexity:
- mission and route changes;
- phase history;
- failed and inconclusive attempts;
- access regain procedures;
- host and credential relationships;
- transition archives;
- a final report narrative;
- sanitized raw tool output.
It does **not** retain reusable secrets, password hashes, flag values, objective answers, private artifacts, caches, or the unsanitized PDF. Redactions are explicit so the publication boundary is visible. See [PUBLICATION_NOTE.md](Engagements/CURRENT/PUBLICATION_NOTE.md) before interpreting missing values.
The case study demonstrates the workflow. It is not a promised solution path for another lab; randomized environments will differ.
## What this framework does not do
- It does not grant authorization to test anything.
- It does not select or execute exploits for you.
- It does not replace operator judgment.
- It does not verify that evidence was collected correctly.
- It does not make AI conclusions trustworthy by default.
- It does not prevent secret leakage unless the publication review is actually performed.
- It is not a polished multi-user case-management platform.
It is deliberately boring infrastructure: Markdown files, clear ownership, explicit state, evidence links, and a recovery path.
## FAQ
### Do I need an AI assistant?
No. A human can maintain the architect role. AI becomes useful when the engagement is long, evidence-heavy, or spread across many sessions—but the AI must write durable state back to the vault.
### Do I need Obsidian?
No. The framework works in any editor that can open Markdown. Obsidian makes the graph and wiki-style navigation easier.
### Why not just use one big notes file?
One file is easy to start and hard to resume. It mixes current state, evidence, guesses, commands, and old history. This structure separates those concerns while preserving links between them.
### Why is `CURRENT` singular?
Because an operator needs one unambiguous resumption point. Alternatives may exist in the active phase, but only one question drives the next action.
### Can this be adapted to bug bounties or client work?
Yes. The state model is domain-independent. Replace exam objectives with scoped assets and hypotheses, add program rules and disclosure status, and treat findings as first-class objects. Never publish client or program data without permission.
## Responsible use
Use this repository only in intentionally vulnerable labs or against systems for which you have explicit written authorization. Stay inside the defined scope and program rules. The presence of a technique, command, or case-study artifact is not permission to use it elsewhere.
Do not publish a live engagement: it may contain credentials, tokens, hashes,
internal addresses, personal information, or client data.
## License
No open-source license has been selected yet. Until a license is added, the repository may be viewed, but reuse, modification, and redistribution rights are not granted by default.
Choose and add a license before inviting reuse or contributions.