Imported from bedkillerspacex-boop/codex-skill-library (rubeus-lab-notes/SKILL.md). Install upstream with npx skills add bedkillerspacex-boop/codex-skill-library --skill rubeus-lab-notes. Copyright stays with the author.

Rubeus Lab Notes

Scope And Authorization

• In scope: AD lab forests you own, CTF AD ranges, or engagements where Kerberos tool use is explicitly authorized.
• Out of scope: production AD without written approval; attacking third-party domains; using stolen tickets outside scope.
• Prefer snapshot-able lab DCs; coordinate blue team if purple-team.
• Tickets and hashes are credentials — encrypt evidence; purge after exercise.
• Pair poisoning labs with responder-lab-only; Windows host privesc with windows-privilege-escalation only when authorized.

When To Use

• Learning Kerberos flows with a well-known lab tool surface (Rubeus).
• Authorized AD assessment where Rubeus is approved in RoE.
• Validating detections for TGT/TGS requests, ticket injection, or delegation abuse in lab.
• Documenting safe command patterns for internal training (never copy into unauthorized ops).

Do Not Use As Primary

Kerberos concepts (lab map)

Rubeus is a post-compromise / credential lab tool — obtain legal foothold first per RoE.

Common lab verb map (illustrative)

Exact flags change by Rubeus version — always --help on your build. Below is conceptual orientation, not a copy-paste attack pack against real orgs.

# Pattern only — run solely in authorized lab
Rubeus.exe <verb> /help

Workflow

1. Lab preflight

1. Confirm domain: lab FQDN, DC IPs, test users, intentionally weak configs documented.
2. Snapshot DC and attacker workstation.
3. Sync clock (Kerberos is time-sensitive) via lab NTP.
4. Define success: demonstrate technique + detection note — not “own everything quietly”.

2. Baseline authentication path

1. Normal interactive login to lab user; capture expected event logs (4624, Kerberos 4768/4769 in lab policy).
2. Note supported etypes (AES vs RC4 lab settings).

3. Exercise one technique at a time

1. Start with asktgt for a lab user you control.
2. Use tickets only against lab SPNs/hosts.
3. Record commands, timestamps, and resulting log events for blue notes.
4. Reset user passwords/tickets between scenarios if needed for cleanliness.

4. Opsec & safety (even in lab)

1. Avoid tooling that spreads beyond lab VLANs.
2. Do not reuse lab passwords on real accounts.
3. Separate training notes from production runbooks that lack authorization gates.

5. Defensive observations (required learning output)

Hardening themes: least privilege, gMSA for services, disable weak etypes carefully, monitor delegation objects, tier admin model.

6. Evidence handling

1. Export lab tickets only to encrypted store.
2. Redact in screenshots for external sharing.
3. Destroy at end of course/engagement.

7. Teardown

1. Revert snapshots; rotate lab krbtgt if exercise requires (lab runbook).
2. Remove persistence if any scenario created it.
3. Write short after-action: technique, logs, control gaps.

Good / Bad

Output Checklist

• Authorization/lab isolation confirmed
• Snapshots and NTP ready
• Technique exercised with recorded commands (lab only)
• Defensive log/detection notes captured
• Tickets/hashes secured then destroyed
• Teardown/revert completed
• No production spillover
• Training notes include authorization warnings

Rules

• Authorized lab/AD only — Rubeus is dual-use; default deny.
• Do not provide or use this as a guide for unauthorized Kerberos attacks.
• Prefer detection and hardening outcomes alongside offensive demos.
• Treat tickets as credentials equivalent to passwords.
• Keep tool versions and flags verified against your binary’s help text.