About competition-mailbox-abuse
A skill for analyzing mailbox abuse in CTF sandboxes, focused on mail behavior, consent flows, and message-routing effects. It requires `$ctf-sandbox-orchestrator` to establish sandbox assumptions first, and correlates identity, mailbox, and message-trace evidence.
Key features
- 01Map mailbox and identity trust paths
- 02Correlate consent, tokens, and permissions
- 03Verify rules and mail-flow effects
- 04Track audit events and message traces
- 05Reduce abuse chains to replayable steps
Use cases
- 01Investigate mailbox effects of a consent grant
- 02Verify persistence through forwarding or transport rules
- 03Trace mail access enabled by shared mailbox permissions
Install
Copy the command and run it in a terminal.
npx skills add https:/ / github.com/ zhaoxuya520/ reverse-skill --skill competition-mailbox-abuseAfter installing, type/competition-mailbox-abusein Claude Code to confirm it loaded.
Bundled filesagents/openai.yamlreferences/mailbox-abuse.md
Details
From the project READMECompetition Mailbox Abuse
Use this skill only as a downstream specialization after $ctf-sandbox-orchestrator is already active and has established sandbox assumptions, node ownership, and evidence priorities. If that has not happened yet, return to $ctf-sandbox-orchestrator first.
Use this skill when the decisive path runs through mailbox behavior, consent flow, or message-routing effects rather than generic AD evidence alone.
Reply in Simplified Chinese unless the user explicitly requests English.
Quick Start
- Decide whether the active path is phishing-to-consent, token-to-mailbox, rule-based persistence, or transport-level mail rerouting.
- Keep mailbox evidence, identity evidence, and message-trace evidence tied to the same user, mailbox, token, or message ID.
- Separate possession of a token or delegate edge from the actual mailbox effect it enables.
- Record forwarding targets, rule predicates, consent scopes, shared mailbox edges, and resulting mail flow in compact blocks.
- Reproduce the smallest mail effect that proves persistence, exfiltration, or privilege.
Workflow
1. Map The Mail Trust Path
- Identify the principal, mailbox, token or session, consent grant, delegate edge, shared mailbox relationship, or app registration involved.
- Record consent scopes, mailbox permissions, rule ownership, transport actions, and message-trace identifiers.
- Distinguish client-visible symptoms from server-side mailbox or transport state.
2. Prove The Mailbox Effect
- Correlate consent logs, sign-ins, message traces, inbox rules, transport rules, forwarding settings, and mailbox audit events.
- Show which rule or token produces which concrete effect: silent forwarding, marking read, deletion, delegate access, or message rerouting.
- Keep message IDs, sender or recipient pairs, and timestamps aligned across logs.
3. Reduce To The Decisive Abuse Chain
- Compress the path to the smallest sequence: lure or grant -> token or delegate edge -> mailbox or transport mutation -> resulting mail effect.
- State clearly whether persistence lives in consent, mailbox rules, transport config, or shared mailbox permissions.
- If the task broadens into host pivots or Kerberos acceptance, switch back to the broader identity skill.
Read This Reference
- Load
references/mailbox-abuse.mdfor the consent checklist, rule checklist, and evidence packaging.
What To Preserve
- Consent scopes, token claims, mailbox permissions, rule definitions, forwarding targets, and message IDs
- Message-trace lines, audit events, and mailbox effects tied to the same mail path
- The smallest replayable sequence that proves persistence, exfiltration, or delegate access