AI Pentesting System Roots Active Hard Hack The Box Machines

Most autonomous-pentesting results have a contamination problem.

When a target has been retired and its walkthroughs have been public for years, it is difficult to know whether a model reasoned through the machine or reconstructed a path already present in its training data or retrieval context. Evaluating against active targets reduces that obvious source of contamination. It does not prove that a model had zero prior exposure, but it makes the result more informative.

OPFORA is an autonomous AI pentesting system built to carry authorized host engagements through externally verified completion. It obtained user and system ownership on active Hard Hack The Box machines running both Linux and Windows. Nimbus was an independent Linux solve. Garfield demonstrates the Windows result from the assumed-breach account supplied by Hack The Box.

OPFORA also completed 11 other machines while they were active: Checkpoint, Bedside, Paperwork, Makesense, Enigma, Connected, DevHub, Reactor, SmartHIRE, Helix, and Silentium. Together, the 13 completions are a capability record, not a benchmark success rate; the headline stays focused on the two Hard results.

This is also not a collection of writeups. We are publishing the conditions and evidence for the outcomes without publishing any machine’s solution path.

What was tested

The targets were active Hack The Box machines tested under the platform’s authorization. Each run began from its recorded starting condition. Completion required objective user and system proof accepted by Hack The Box; neither model narration nor a promising terminal message counted as success.

Garfield reached verified user ownership in 1h 04m 27s and verified system ownership in 2h 27m 19s. These are wall-clock times from the start of the successful run to recorded proof. They include model inference, target-side execution, retries, waits, and recovery. A substantial share of the Garfield user interval is not compute at all: the domain path depends on a scheduled action firing on the target’s own schedule, and the runtime spent that period waiting rather than reasoning. They are not human-equivalent labor hours and should not be compared with another system unless the starting conditions and timing method match.

The Garfield run used assisted collective memory and continued across gpt-5.6-luna, gpt-5.6-sol, and gpt-5.6-terra routes and fallbacks with zero recorded human interventions. That condition matters: this was not a sealed, single-model, memory-free experiment.

Nimbus was an independent solve, starting from network access alone rather than a supplied account. It reached verified user ownership in 31m 48s and verified system ownership in 3h 52m 05s, measured the same way. Enumeration and initial access went quickly; the bulk of the runtime sits after the first shell, in the privilege reasoning required to turn that foothold into accepted system proof. The two machines are therefore not comparable to each other on user time: Nimbus front-loads a single fast chain, while Garfield’s early path is gated by a target-side schedule no amount of reasoning speed shortens.

The two HTB pages prove that the preemware account pwned the named machines. They do not, by themselves, prove which software performed the work or establish the run conditions. Those conditions are described here; the run records behind them remain private.

Why active Hard machines are meaningful

A Hard HTB machine is not a production network, and solving one does not prove readiness to replace a professional pentester. It does test more than isolated vulnerability recognition.

Reaching system ownership requires a sustained investigation. Evidence discovered at different times has to be correlated. Weak hypotheses have to be discarded. Failed operations cannot erase earlier facts. Initial access is a midpoint, not the finish: the system must continue through post-exploitation and privilege reasoning until an external verifier accepts the result.

That continuity is relevant to authorized work. An internal or assumed-breach assessment often asks whether modest weaknesses combine into material impact. Remediation testing asks whether a fix broke the complete attack path rather than one visible step. A human team benefits when a system can preserve progress, investigate several plausible leads, and reject its own claims when evidence does not support them.

The Linux and Windows results matter together because identity, privilege, and operating assumptions differ across platforms. They show that OPFORA’s operating envelope is not confined to one host family. They do not establish equal coverage of every enterprise stack or guarantee a repeatable result on any unseen Hard target.

Active status also has a precise, limited value. It reduces the chance that a complete public walkthrough was simply retrieved or reproduced. It cannot rule out private sharing, partial prior exposure, model pretraining artifacts, or accidental assistance. That is why the run conditions matter alongside the target status.

Hard HTB machines do not prove real-world readiness, but they exercise many capabilities that real-world pentesting requires. They also expose the gap between a system that can discuss an attack and one that can carry an engagement to externally verified completion.

The model did not solve these machines by itself

The language model provides tactical intelligence. It interprets evidence, forms hypotheses, selects tactics, and changes course when observations contradict its plan. Better models materially improve those decisions.

OPFORA supplies a different layer: continuity, controlled execution, authoritative state, recovery, and proof.

model reasoning → OPFORA runtime → authorized tools → external proof

Operational facts survive outside model prose and outside any one context window. Actions execute against explicitly scoped targets. Evidence remains attributable to the engagement that produced it. A model cannot complete a run merely by saying it succeeded; the objective must produce checkable proof.

This distinction is also why OPFORA is not simply Codex or Claude Code with a shell. Both are capable coding agents. They can reason well, inspect files, invoke tools, and retain useful context throughout a development task. Used by a skilled operator, either can be an effective tactical interface.

OPFORA’s primary unit of work is different. It is a scoped offensive engagement with durable objectives, identities, evidence, execution provenance, and terminal conditions. The runtime must keep those facts coherent across retries, sessions, model-route changes, and failed operations. Model conversation is useful context, but it is not the authority for what executed or whether the target objective is complete.

Codex or Claude Code can supply excellent tactical reasoning and tool use. OPFORA supplies the engagement semantics around that intelligence: what is in scope, what actually executed, what facts remain authoritative, how work continues after failure, and what proof is required before success is real.

A sufficiently engineered wrapper around a general coding agent could provide the same class of controls. Once durable engagement state, scoped execution, evidence reconciliation, failure recovery, and proof-backed completion have been added, however, the differentiator is precisely that surrounding runtime—not the model name in the middle.

A model can describe a pentest. OPFORA is built to finish one.

Evaluating the boundaries, not just the final flag

“Did it eventually root one machine?” is too coarse a metric to guide engineering. OPFORA uses custom evaluations to measure the components and transitions that make an engagement reliable.

Purpose-built role evaluations score discovery completeness, tactical correctness, false positives, privilege outcomes, research accuracy, identity reasoning, and report quality. Safety evaluations exercise rules of engagement, egress controls, approvals, untrusted output, audit durability, and restart recovery. A performance improvement does not get to bypass those invariants.

A separate transition scorer asks whether the engagement actually progressed through discovery, validation, foothold, access, privilege escalation, proof, and reporting. It deliberately ignores model prose. A sentence describing a future goal cannot become a completed milestone.

Live end-to-end evaluations compare candidate and control configurations under matched conditions. The harness records success, assistance, observed models, interventions, tokens, cost, active duration, handoff latency, and accepted proof. Interrupted engagements can be reconstructed from durable traces, and public claims are reconciled against proof-backed result artifacts rather than hand-edited success tables.

Changes pass promotion gates. Faster is not sufficient. Outcome quality, safety, provenance, confidentiality, cost, tokens, and latency must remain within policy. A cheaper run is a regression if it is less reliable or less controlled.

The performance work follows the same principle. Compact operational facts reduce transcript replay. Task-specific context and tool surfaces reduce noise. Fast, targeted collection precedes expensive depth. Independent, read-only work can overlap while mutation and terminal transitions remain controlled. Noisy output is reduced to bounded evidence, long-running jobs continue outside a model turn, and checkpoints make provider failures recoverable without repeating completed target-side effects.

We publish the dimensions being measured, not the private fixtures, thresholds, routing rules, cache lifetimes, prompts, role graph, or recovery algorithms. Those details would turn an evaluation report into a replication guide.

A different product boundary

Autonomous-security systems already provide meaningful agent orchestration, persistence, sandboxing, exploit validation, and reporting. OPFORA’s advantage is not exclusive ownership of those common capabilities.

This compares published product boundaries, not universal capability. No controlled head-to-head evaluation has been run against an identical sealed target set, so the results do not establish that OPFORA is better, faster, cheaper, or broader in every domain.

The distinction demonstrated here is the terminal objective. OPFORA did not stop at a plausible weakness, generated finding, or working proof of concept. It maintained the engagement until Hack The Box accepted proof of user and system ownership. For host and network assessments, the first execution primitive is often where the interesting work begins.

OPFORA’s competitive advantage is the complete operating envelope: carrying an authorized host engagement from uncertain reconnaissance through access, post-exploitation, privilege escalation, and external proof while keeping scope, durable state, execution, recovery, and completion authority outside the language model.

That makes OPFORA an offensive engagement runtime rather than a vulnerability scanner with a chat interface. It is currently built for authorized penetration-testing engagements. Bug-bounty assistance, continuous security validation, and broader red-team workflows remain future directions, not shipped claims.

Why OPFORA remains closed source

Releasing OPFORA would not merely reproduce the experiment. It would alter the environment the experiment measures.

The system is a capability, not only a research scaffold. Broad release could automate ownership of active machines, distort completion statistics, and spread solution material before retirement. Those paths could enter repositories, retrieval indexes, shared agent memory, and eventually model training data. The active-target freshness used to evaluate OPFORA would erode.

There is also a direct product reason. The implementation is the work. Source, prompts, operational playbooks, state handling, accumulated failures, and control logic represent years of engineering. Publishing them would make the most expensive decisions cheap for another developer—or another coding agent—to copy, distill, and repackage without bearing the research cost that produced them. Protecting that intellectual property makes continued development commercially sustainable.

We can make evidence public without making the engine public. Readers should be able to scrutinize what OPFORA achieved, under what conditions, and where each claim stops. They do not need active-machine paths or a replication package for the product to do that.

Closed source limits independent reproducibility. That tradeoff deserves direct acknowledgment. Platform receipts support narrow outcome claims; they do not substitute for a source audit.

Evidence without spoilers

The public record for each result is the Hack The Box ownership page plus the run conditions described here: starting condition, evaluation condition, memory and research posture, observed models, human-intervention count, and timings. It does not include flags, credentials, target addresses, endpoints, services, commands, transcript fragments, or any observation that narrows a live machine’s path.

The private run records bind each OPFORA run to the proof Hack The Box accepted. Where appropriate, sanitized evidence can be released after a machine retires.

The evidence boundary is intentional. Outcome verification should become easier; reproducing an active solution should not.

Limits

These results are a capability record, not a success rate. A rate needs the complete denominator: all attempts, failures, interruptions, retries, checkpoints, model routes, external research, operator interventions, budgets, and stopping rules.

HTB machines are curated, bounded, resettable, and intentionally solvable. They do not fully model production safety, ambiguous scope, business context, active defenders, stakeholder communication, change control, or the cost of a mistake. An assumed-breach completion is not a black-box foothold. One successful run is not proof of repeatability, and provider or model drift can change later outcomes.

Active status reduces obvious walkthrough contamination; it cannot eliminate exposure uncertainty. Closed source prevents full independent reproduction. Single-machine results do not establish enterprise-network performance.

Solving an active Hard machine therefore does not prove readiness to replace a professional pentester. It shows that the system can sustain a demanding technical investigation through uncertainty, access, post-exploitation, privilege escalation, and externally verified completion.

What comes next: enterprise networks

Individual machines test whether OPFORA can finish a deep technical chain. Enterprise networks test whether it can preserve identity, privilege, scope, and evidence across many interconnected systems.

Our next research program uses Hack The Box Pro Labs, enclosed environments designed to simulate corporate networks with multiple systems, security configurations, vulnerabilities, and attack paths. The evaluation will measure long-running continuity, trust and privilege reasoning, credential handling, lateral movement, recovery, scope enforcement, intermediate proof, human intervention, runtime, model routing, cost, and repeatability.

OPFORA is designed for that larger authorized operating domain. The Pro Labs work will test and quantify the claim; it will not inherit credibility automatically from these single-machine results. We will publish the methodology and results separately without naming an active lab or pre-announcing a positive outcome.

Authorized penetration testing is OPFORA’s current mission. Future work may extend the same evidence-led runtime to bug-bounty research, continuous validation, and broader red-team operations. Each domain will require its own safety rules, evaluation conditions, and proof.

Proof before scale

These results do not show that one language model memorized how to hack active machines. They show what becomes possible when model reasoning operates inside a runtime built to preserve continuity, execute within scope, recover from failure, and require objective evidence.

Nimbus and Garfield demonstrate that potential on active Hard Linux and Windows targets under different starting conditions. They do not establish a universal success rate or production readiness.

We are publishing evidence of what OPFORA accomplished without publishing the machinery or paths that would turn active HTB content into a reusable solver. The additional active-machine completions show breadth beyond the two Hard results, but they do not establish a benchmark success rate.

The next question is whether the same operating model holds across realistic multi-host enterprise networks. That evaluation is next.