# Social Eng Vishing Pretext

> Run authorized voice-phishing (vishing) and pretext-based scenarios that test whether staff and help desks follow verification procedures — safely and by consent. Load after social-eng-methodology when the objective is phone/live-interaction based (help-desk password reset, MFA-reset abuse, pretext callback). Signals: "vishing", "call the help desk", "pretext", "test our verification process", "MFA reset social engineering".

- Skill: `noorqureshi/social-eng-vishing-pretext` (Agent Skill)
- Install (CLI): `npx skillmds@latest add noorqureshi/social-eng-vishing-pretext`
- Raw SKILL.md: https://api.skillmd.com/api/skills/noorqureshi/social-eng-vishing-pretext/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: NoorQureshi (https://skillmd.com/u/noorqureshi)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/noorqureshi/social-eng-vishing-pretext

---


# Vishing & pretexting

## When it applies
The engagement authorizes live-interaction testing (cleared via `social-eng-methodology`) and the
objective is a process test: will the help desk reset a password or MFA without proper verification?
Will an employee act on a convincing caller? This targets *procedure adherence*, which phishing
email can't measure. Help-desk MFA-reset abuse is a leading real-world initial-access vector, so
testing it is high-value.

## Why it works
Voice adds urgency, authority, and social pressure that written channels lack — a confident caller
with a few true details (from `recon-osint`) and a plausible reason routinely gets a human to skip a
verification step. The finding is the *gap in the verification procedure*, not the individual who
answered.

## Method
1. **Define the process under test** and the pass/fail line with the client: e.g. "help desk must
   require callback-to-known-number + a second factor before any reset." The test measures whether
   that line holds.
2. **Build a proportionate pretext** within allowed themes — a plausible role (a named-role, not a
   real named person, unless consented), a believable reason, and only the OSINT detail needed for
   credibility.
3. **Prepare a call plan and an immediate stand-down.** Script the ask, the escalation, and the
   point at which you disclose. Keep the authorization/emergency contact ready if challenged.
4. **Execute a bounded number of attempts** per RoE, tracking each: target, request, which
   verification steps were performed vs. skipped, and the outcome.
5. **Stop at the objective.** Once a step is bypassed (or correctly refused), you have the result —
   do **not** proceed to actually reset/log in or take any real account action beyond proving the
   procedure gap; disclose per plan.
6. **Debrief.** Capture where the procedure failed and why; hand it to the awareness/report step.

## Gotchas
- **Prove the gap, don't exploit it.** A help desk agreeing to reset MFA *is* the finding — you do
  not complete a real takeover; stop and record it.
- **De-escalate distress.** If a target becomes anxious or suspicious, disclose the assessment and
  reassure them; their cooperation isn't the point, the procedure is.
- **No coercion or protected topics** — the excluded-theme and no-harm rules from
  `social-eng-methodology` apply in full over the phone.
- **Attribute cleanly** — use test lines/tokens so a call can be confirmed as the assessment, and
  coordinate so it isn't mistaken for a real fraud attempt.
- **Recording laws vary** — only record calls where lawful and agreed in the RoE.

## Verify success
A documented result per attempt — which verification steps held or failed and the outcome — with no
real account actions taken and every target debriefed, feeding a procedure-focused report and
remediation (stronger help-desk verification, callback policy, MFA-reset controls).

## References
MITRE ATT&CK T1598.004 (phishing for information via voice), T1656 (impersonation); help-desk
verification / MFA-reset hardening guidance.