competition-mailbox-abuse

Traces OAuth consent, mailbox rules, and transport abuse into persistence or exfiltration evidence.

7|4|Updated Jun 22, 2026
One-click install
npx skills add https://github.com/dbx0/skills --skill competition-mailbox-abuse-dbx0
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: competition-mailbox-abuse
Source: https://github.com/dbx0/skills/tree/main/skills/identity-access/collection/competition-mailbox-abuse
Command: npx skills add https://github.com/dbx0/skills --skill competition-mailbox-abuse-dbx0

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? In CTF and sandboxed enterprise-mail scenarios, it is hard to connect identity artifacts (tokens, consent grants, delegate edges) to concrete mailbox effects like silent forwarding, deletion, or rerouting. This Skill provides a structured workflow for proving exactly which rule, token, or transport configuration caused an observed mail behavior. ## Core Features & Use Cases - Mail Trust Path Mapping: Identifies principals, mailboxes, tokens, consent grants, delegate edges, shared mailbox relationships, and app registrations involved in an abuse chain. - Mailbox Effect Proof: Correlates consent logs, sign-ins, message traces, inbox rules, transport rules, and audit events to show which mechanism produced forwarding, deletion, marking read, or rerouting. - Abuse Chain Reduction: Compresses findings into the smallest replayable sequence proving persistence, exfiltration, or delegate access. - Use Case: During a CTF, you obtain an OAuth token and suspect inbox-rule persistence. Use this Skill to tie the consent scope, rule predicate, forwarding target, and message IDs into one evidence block that proves the exfiltration path. ## Quick Start Ask the assistant to trace how the captured OAuth consent grant and inbox rule produce silent forwarding for the target mailbox, keeping message IDs aligned across logs.

Frequently Asked Questions about competition-mailbox-abuse

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I trace malicious inbox rules in a mailbox investigation?

Correlate inbox rule predicates and forwarding targets with message traces and mailbox audit events tied to the same message IDs. Show which rule produced the observed effect such as silent forwarding, deletion, or marking read.

How to prove OAuth consent grant abuse leads to mailbox access?

Link the consent grant's scopes and sign-in events to the token's actual mailbox effect, such as reading mail or creating rules. Possession of a token alone is not evidence; demonstrate the concrete mailbox mutation it enables.

What is the difference between inbox rules and transport rules in abuse investigations?

Inbox rules are per-mailbox actions like forwarding or deletion, while transport rules reroute messages at the organization level. The Skill requires proving which mechanism caused the observed message flow rather than mixing them.

Can shared mailbox permissions be abused without the owner logging in?

Yes, delegate and shared mailbox permissions allow access independent of the owner's sign-in activity. The Skill flags this as a common pitfall and directs you to record delegate edges and shared mailbox relationships as separate evidence.

When should I not use this mailbox abuse workflow?

Do not use it before the ctf-sandbox-orchestrator has established sandbox assumptions and routed the task. If the path broadens into host pivots or Kerberos acceptance, switch back to the broader identity skill instead.