Social Engineering & Phishing.

Pretext-design — what works

• Aligned with real work. Reference an actual ticketing system, an actual vendor, an actual quarterly process. OSINT first, write second.
• Plausible CTA. "Confirm your timesheet by Friday" beats "Verify your password now." The action requested is something the target would expect to do anyway.
• No escalation pressure. "Urgent — locked account in 1 hour" trips the training reflex. Legitimate IT rarely uses countdown threats.
• Look like the system, not like an attacker. Office 365 legitimate notification → copy the HTML structure, headers, footer, unsubscribe link. Diff vs. a real one until they're indistinguishable.
• Right sender. Spoofed display name + neighboring-domain typosquat. Targets read the display name; only ~5% check the actual From: header.

Channel tradeoffs

• Email. Highest volume, lowest conversion. Defended by mail gateways, sandbox detonation, URL rewriting. Plan for 5–15% click rate on first send.
• SMS (smishing). Lower volume capacity, higher conversion. Sandbox doesn't exist for SMS the way it does for email. Plan for 20–35% click rate when pretext is sharp.
• Voice (vishing). Highest conversion against helpdesk staff. Hardest to script. Most effective on Monday mornings when ticket volume is highest.
• In-person / physical. Tailgating, dropped-USB. Highest legal/scope risk. Always written-authorized with on-call white cell contact.
• Supplier impersonation. Email from a known vendor with a known payment-detail change request. Very high conversion against finance teams; high legal scrutiny.

Targeting admins specifically

• Tooling-trust. Admins click links from tools they use daily — Jira, Confluence, PagerDuty, GitHub. Pretext that looks like a notification from one of those.
• Helpdesk pretext. Reverse the direction. You call as a user with an authentic-looking ticket reference; ask helpdesk to push an MFA, claim "phone broke", get a temporary code.
• Console-link redirect. URL that lands on a real admin console first, then redirects to your harvester. Browser security indicators show "secure" because the first hop was real.
• OAuth consent phishing. Don't phish password; phish an OAuth scope grant. The target sees a real Microsoft consent page and clicks Allow.

Operational guardrails (don't burn the engagement)

• Written scope, named targets only. No improvising new recipients mid-campaign.
• Credentials handled by one operator. Captured creds never sit in a shared inbox or chat. Hash them at capture, store the hash, decrypt only at use.
• Sender infra cleanly attributable on request. Don't reuse domains across clients. Don't reuse the SAME domain you used for actual blue-team work last quarter.
• Kill switch. Single command that takes down all landing pages, revokes captured tokens, and notifies white cell. Test it before campaign launch.