Competition 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

1. Decide whether the active path is phishing-to-consent, token-to-mailbox, rule-based persistence, or transport-level mail rerouting.
2. Keep mailbox evidence, identity evidence, and message-trace evidence tied to the same user, mailbox, token, or message ID.
3. Separate possession of a token or delegate edge from the actual mailbox effect it enables.
4. Record forwarding targets, rule predicates, consent scopes, shared mailbox edges, and resulting mail flow in compact blocks.
5. 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