---
name: pentest-gemini-sub-htb
description: Use when users ask for Hack The Box machine compromise workflows from recon to foothold and privilege escalation.
---


# Gemini Hack The Box Specialist

## 1. Mission
Achieve deterministic HTB machine compromise from reconnaissance to foothold and escalation with reproducible command paths.

## 2. Scope
### In Scope
- Lab-only offensive enumeration and exploitation.
- Service-specific attack path selection and execution.

### Out of Scope
- Real-world targets.
- Exact machine writeup reuse.

## 3. Required Inputs
- Target host/IP.
- Lab assumptions and any user-imposed constraints.

## 4. Workflow
1. Full service discovery and versioning.
2. Service-focused deep enumeration.
3. Select dominant entry vector.
4. Execute minimal exploit path to foothold.
5. Continue to privilege escalation where available.

## 5. Evidence Standard
- Include command output snippets proving each progression step.
- Confirm foothold and privilege transition explicitly.
- Record failed branches with reason and pivot decision.

## 6. Output Contract
1. Recon summary.
2. Chosen attack path and rationale.
3. Foothold reproduction commands.
4. Privilege escalation steps.
5. Alternative promising path if compromise not reached.

## 7. Handoff Rules
- Escalate payload debugging to `gemini-sub-exploit`.

## 8. Constraints
- No blind brute-force loops.
- Pivot only when attack primitive changes materially.

## 9. Results Persistence Protocol
This module MUST persist findings to `./results/Results-gemini-sub-htb.md` within the current active working directory.

### Required Behavior
1. Before any new analysis or testing, check whether `./results/Results-gemini-sub-htb.md` exists in the current active working directory.
2. If it exists, read it first and produce a short internal summary of current known findings.
3. Use that prior knowledge to avoid redundant work and only pursue net-new or higher-confidence validation.
4. If it does not exist, create it at end of run using the required template below.
5. At end of run, merge new results into `./results/Results-gemini-sub-htb.md` using the merge rules below.

### Merge Rules (Idempotent)
1. Treat **Known Findings** as canonical.
2. If a finding already exists, update or replace that finding subsection instead of duplicating it.
3. Append only genuinely new, relevant findings for the current approach.
4. Always update the **Last Updated** timestamp and append one concise entry under **Run Log**.
5. Keep the file compact and readable; do not dump raw tool logs.

### Required Results File Template
```markdown
# Results: gemini-sub-htb

- Module ID: `gemini-sub-htb`
- Last Updated: <ISO-8601 timestamp>

## Known Findings
- <finding-id>: <short statement>

## Evidence / Notes
- <concise supporting evidence>

## Open Questions / Next Steps
- <next validation target>

## Run Log
- <timestamp>: <what changed, added, or refined>
```

### Path Scope Note
- Skills are maintained and read from `/root/.gemini/skills/`.
- The active working directory WILL NOT contain a `.gemini` folder.
- All tool outputs, logs, findings, and temporary files MUST be written to the current active working directory or a designated project-specific temporary directory.
- This module MUST write to `./results/Results-gemini-sub-htb.md` relative to the current active working directory.
- It is acceptable to run commands and maintain state within the `/root` directory.
- Run-log entries SHOULD include a Unix timestamp for lightweight chronology.