Instructor Runbook - Lab 02 Controlled OAuth Consent
Working Decision
Use controlled OAuth consent as the Phase 2 primary lab. Keep device code phishing as threat context or instructor demo only. Keep AitM / Evilginx as a boundary discussion unless John explicitly approves a controlled advanced path.
Teaching Intent
Students should learn to read a consent prompt and understand how the resulting service principal, OAuth grant, and sign-in observations affect the attack chain. The lab should not become a reusable phishing playbook.
Setup Notes
- Use a dedicated training tenant.
- Use a clearly named controlled application.
- Request only low-risk delegated permissions for the student exercise.
- Keep any admin-consent or application-permission demonstration instructor-led.
- Prepare cleanup commands or portal steps before class.
Timing
- Target: 25 minutes.
- Shortcut: use screenshots and a pre-created service principal if the tenant is
unstable.
- Deepening path: show how the same app model becomes more dangerous when app
roles or broad application permissions are granted.
Observation Prompts
Ask students to identify:
- What did the user consent to?
- Was the permission delegated or application permission?
- Which service principal appeared in the tenant?
- Which user or admin action would be visible to defenders?
- Which setting could block, restrict, or route this request for review?
Do not collect flags or student submissions. Use discussion, instructor review, or live walkthrough questions to confirm understanding.
Cleanup Checklist
- Revoke OAuth permission grants created during the lab.
- Remove or disable the controlled enterprise application if it is no longer
needed.
- Confirm no reusable secrets, tokens, or client credentials were shared in
student material.
- Keep screenshots de-identified before committing them.
Sources
MS-CONSENTMS-USER-CONSENTMS-ADMIN-CONSENT-WORKFLOWMS-DEVICE-CODE-FLOWMS-STORM-2372
Original Markdown source
# Instructor Runbook - Lab 02 Controlled OAuth Consent
## Working Decision
Use controlled OAuth consent as the Phase 2 primary lab. Keep device code
phishing as threat context or instructor demo only. Keep AitM / Evilginx as a
boundary discussion unless John explicitly approves a controlled advanced path.
## Teaching Intent
Students should learn to read a consent prompt and understand how the resulting
service principal, OAuth grant, and sign-in observations affect the attack chain.
The lab should not become a reusable phishing playbook.
## Setup Notes
- Use a dedicated training tenant.
- Use a clearly named controlled application.
- Request only low-risk delegated permissions for the student exercise.
- Keep any admin-consent or application-permission demonstration instructor-led.
- Prepare cleanup commands or portal steps before class.
## Timing
- Target: 25 minutes.
- Shortcut: use screenshots and a pre-created service principal if the tenant is
unstable.
- Deepening path: show how the same app model becomes more dangerous when app
roles or broad application permissions are granted.
## Observation Prompts
Ask students to identify:
- What did the user consent to?
- Was the permission delegated or application permission?
- Which service principal appeared in the tenant?
- Which user or admin action would be visible to defenders?
- Which setting could block, restrict, or route this request for review?
Do not collect flags or student submissions. Use discussion, instructor review,
or live walkthrough questions to confirm understanding.
## Cleanup Checklist
- Revoke OAuth permission grants created during the lab.
- Remove or disable the controlled enterprise application if it is no longer
needed.
- Confirm no reusable secrets, tokens, or client credentials were shared in
student material.
- Keep screenshots de-identified before committing them.
## Sources
- `MS-CONSENT`
- `MS-USER-CONSENT`
- `MS-ADMIN-CONSENT-WORKFLOW`
- `MS-DEVICE-CODE-FLOW`
- `MS-STORM-2372`