Disclaimer: This article is provided strictly for educational purposes and authorized security testing. Only run these techniques against systems you own or have explicit written permission to assess. Unauthorized access to computer systems is illegal in virtually every jurisdiction and can carry severe penalties.
Introduction
Phishing and pretexting are the standard methods for testing an organization’s human layer under an authorized red-team or social-engineering engagement. Where vulnerability scanning and exploitation validate technical controls, a phishing campaign validates the layer that sits in front of every technical control: whether a person will click a link, enter credentials, open an attachment, or take an action (wiring money, resetting a password, granting badge access) because a message or a phone call convinced them it was legitimate. Every major breach retrospective of the last decade features an initial-access phishing email or a pretext phone call somewhere in the kill chain, which is why mature security programs test it deliberately rather than discover it during a real incident.
This article covers phishing and pretexting strictly as an authorized, scoped, documented activity performed under a signed rules-of-engagement (RoE) with a client-side sponsor, legal sign-off, and a clear remediation goal: measuring and improving detection, reporting, and resilience. It does not provide a ready-to-send phishing kit or credential-harvesting page — the mechanics of GoPhish and Evilginx2 are named at the level a program owner needs to understand them, not at the level of a turnkey build. The emphasis throughout is on scoping discipline, infrastructure hygiene, and — most importantly — the defensive and awareness controls that make an organization resilient regardless of how good any single campaign’s pretext is.
Attack Prerequisites
A legitimate phishing/pretexting engagement cannot start without paperwork and guardrails in place first. What has to be true before any message is sent:
- Signed rules of engagement (RoE) — written authorization naming the target org, domains/user population in scope, allowed pretext themes, dates, and an emergency stop clause; without it, phishing real employees is indistinguishable from a crime.
- A named client-side “trusted agent” — someone who can vouch for the test if help-desk/SOC staff escalate, and authorize scope changes.
- A defined objective and success metric — click rate, credential-submission rate, report rate, or whether a specific pretext bypasses a specific control.
- Legal/HR alignment — agreement that individual results won’t drive punitive action against employees, which is what keeps future reporting rates honest.
- Dedicated test infrastructure — sending domains and mail infra separate from any red-team C2, so the blue team’s response doesn’t tangle with a real incident.
How It Works
A phishing engagement is built around a pretext — the story that gives the target a plausible, low-friction reason to act. Effective pretexts exploit routine business processes rather than fear alone: an IT ticket about a mailbox quota, a shared-document notification, a payroll deadline, or a vendor invoice needing approval. Pretexting extends the same principle to voice and physical channels — a help-desk call requesting an MFA push approval (“push-bombing”), a vishing call to reset a password, or tailgating into a facility behind an employee. The common thread is authority, urgency, and a plausible business context that suppresses the target’s instinct to verify.
On infrastructure, a campaign needs a sending path that gets past mail filtering, a tracking/landing mechanism, and — if MFA-protected accounts are in scope — a way to capture a live session rather than a static password. GoPhish is the commonly used open-source campaign manager for the first two: it templates emails and landing pages and tracks per-recipient opens, clicks, and submitted data. Where the objective includes MFA-protected authentication, teams may use a reverse-proxy framework such as Evilginx2, which sits between the victim and the real login page, transparently relaying traffic to capture the resulting session cookie after a successful login — demonstrating that a phishing page can defeat SMS/TOTP MFA (though not origin-bound methods like FIDO2/WebAuthn). Naming these tools is as far as this article goes; operating them requires the RoE and safeguards above.
Email authentication determines whether a spoofed sending domain even reaches the inbox. SPF publishes which mail servers may send for a domain; DKIM cryptographically signs outbound mail so origin and integrity can be verified; DMARC ties the two together and tells receivers what to do on failure (none/quarantine/reject) for the domain in the visible From: header. A target with p=reject DMARC makes exact-domain spoofing hard, which is why real attackers pivot to look-alike domains (corp-it-notify.com) that pass SPF/DKIM/DMARC in their own right, since they are genuinely different domains the attacker controls.
Practical Example / Configuration
A campaign plan is not free-form; it is scoped and tracked like any other test asset. A minimal campaign definition (the kind of record a GoPhish operator or program owner keeps for each pretext, tied back to the RoE) looks like this:
campaign: "Q3 IT-Helpdesk Mailbox Quota"
authorized_scope: "corp.example.com employees, HQ + remote (n=1240)"
pretext_theme: "Mailbox storage full - action required within 24h"
sending_domain: "corp-it-notify.test" # dedicated test domain, not prod
spf_dkim_dmarc: "configured on sending domain to pass filters realistically"
landing_page: "cloned OWA-style login, no real credential storage,
submitted values discarded post-capture-flag"
tracking: "GoPhish - per-recipient open/click/submit timestamps"
excluded_groups: ["Legal", "exec-assistants-medical-leave"]
stop_conditions: "trusted agent notified if help desk ticket volume spikes
or campaign is escalated to SOC as a real incident"
reporting_metric: "click_rate, cred_submit_rate, report_rate, time_to_report"
The defensive counterpart is DMARC enforcement on the org’s own domain, so attackers can’t trivially spoof it back at employees or partners: _dmarc.corp.example.com IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@corp.example.com" combined with an SPF record ending in -all and DKIM signing on every legitimate sending path.
Walkthrough / Exploitation
A typical engagement runs as a sequence of gated stages, each reviewed against the RoE before proceeding:
1. Recon (OSINT only): org chart from LinkedIn/press, public email format
confirmation, vendor/tooling fingerprinting from job postings and DNS.
2. Pretext design: draft 2-3 candidate pretexts scaled low- to high-pressure;
trusted agent approves final wording, sender identity, and target list.
3. Infrastructure: register/age a look-alike or neutral test domain, configure
SPF/DKIM/DMARC, stand up the GoPhish campaign and tracked landing page.
4. Launch and monitor live; trusted agent on standby; stop immediately on scope
creep or if the target escalates the campaign as a real incident.
5. Debrief: aggregate metrics by department/role (never by named individual to
leadership), deliver root-cause findings on the weakest control layer.
For a pretexting (phone/vishing) track run in parallel, the operator follows a scripted call tree approved in advance rather than improvising, and every call is logged with timestamp, target role, and outcome (e.g. “Pretext: urgent password reset, traveling, can’t use normal MFA device -> agent required employee ID + manager callback verification -> PASS”) so the debrief shows patterns instead of anecdotes.
Note: The single most common finding in these engagements is not a clever pretext — it is a help-desk or support process that will reset a password or approve an MFA push based on a plausible phone story with no independent identity verification. Technical email defenses (SPF/DKIM/DMARC, attachment sandboxing) do nothing against a voice pretext, which is why a mature program tests both channels.
Opsec: Never capture and store real credentials or MFA codes beyond the minimum needed to prove the control failed; discard submitted values immediately after logging a pass/fail flag, and never reuse any captured token. Keep engagement infrastructure (sending domains, landing pages, C2 if paired with a broader red-team op) fully separate from anything the client’s real threat intel or takedown processes might already be tracking, and hand over indicators (domains, IPs, email headers) to the blue team at debrief so they aren’t left in threat feeds indefinitely.
Detection and Defense
The controls that actually reduce phishing risk operate at three layers: stopping the message before it lands, making it hard for a user to fall for the message that does land, and limiting the blast radius when someone still does.
- Email authentication enforcement — SPF
-all, DKIM on all sending paths, and DMARC atp=reject; monitor DMARCruaaggregate reports before enforcing. - Mail filtering and detonation — sandboxed URL/attachment analysis, time-of-click link rewriting, and warning banners on external/look-alike domains.
- Phishing-resistant MFA — FIDO2/WebAuthn keys or passkeys bind the credential to the origin, defeating reverse-proxy capture tools like Evilginx2 in a way SMS/TOTP cannot; the single highest-leverage technical control against modern phishing.
- A frictionless one-click “Report Phishing” button with fast SOC triage — report rate and time-to-report are better resilience metrics than raw click rate.
- Out-of-band verification culture — password resets, wire transfers, and MFA re-enrollment require callback verification through a known number, not the number/email in the request itself.
- Detection telemetry — certificate-transparency monitoring for look-alike domains, mail gateway auth-failure logs, and IdP logs for anomalous MFA push patterns (push-bombing).
Measured over repeated campaigns, click rate should trend down and report rate up; a flat click rate with rising report rate is still a legitimate interim signal of progress.
Real-World Impact
Phishing remains the most common initial-access vector cited in annual breach reports, from business-email-compromise wire fraud to ransomware intrusions that began with a single credential harvested via a spoofed SSO login page. MFA-bypass phishing kits using reverse-proxy techniques similar to Evilginx2 have been documented by Microsoft and others in large-scale AiTM (adversary-in-the-middle) campaigns against enterprise email, which is why phishing-resistant authentication (FIDO2) is now a top CISA and identity-provider recommendation rather than a theoretical best practice.
Conclusion
Authorized phishing and pretexting engagements exist to find and fix the same gap attackers exploit for real: a human decision made under manufactured urgency with no verification step. The value of the engagement is not in how convincing the pretext was, but in the metrics and root-cause findings it produces — click rate, report rate, and which specific process (help desk, MFA approval, financial approval) needs a mandatory verification step. Combined with enforced email authentication and phishing-resistant MFA, a well-run program measurably shrinks the organization’s human attack surface over successive campaigns.
You Might Also Like
If you found this useful, these related deep-dives cover adjacent techniques and their defenses:
Comments