conducting-social-engineering-penetration-test

name	conducting-social-engineering-penetration-test
description	Design and execute a social engineering penetration test including phishing, vishing, smishing, and physical pretexting campaigns to measure human security resilience and identify training gaps.
domain	cybersecurity
subdomain	penetration-testing
tags	["social-engineering","phishing","vishing","pretexting","GoPhish","SET","OSINT","security-awareness","red-team"]
version	1.0
author	mahipal
license	Apache-2.0
atlas_techniques	["AML.T0088","AML.T0052"]
nist_ai_rmf	["GOVERN-6.2","MAP-5.2"]
nist_csf	["ID.RA-01","ID.RA-06","GV.OV-02","DE.AE-07"]

Conducting Social Engineering Penetration Test

Overview

Social engineering penetration testing assesses an organization's human attack surface through controlled simulation of real-world deception techniques. According to Verizon DBIR 2024, the human element is involved in approximately 68% of all breaches, with phishing remaining the dominant initial access vector. This skill covers phishing, vishing (voice phishing), smishing (SMS phishing), and physical pretexting campaigns using tools like GoPhish, the Social Engineer Toolkit (SET), and Evilginx.

When to Use

• When conducting security assessments that involve conducting social engineering penetration test
• When following incident response procedures for related security events
• When performing scheduled security testing or auditing activities
• When validating security controls through hands-on testing

Most Often Missed & How to Confirm

• Measuring the report/resist rate, not just the click rate — the security outcome that matters is whether anyone reported the attempt and how fast the SOC responded. Campaigns that only track clicks/credentials miss the defensive signal. Time the first report and the SOC's containment action.
• MFA-bypass / session-token phishing — credential-only landing pages overstate safety where MFA exists. Use a reverse proxy (Evilginx/Modlishka) when authorized to prove session-cookie theft defeats MFA, or explicitly note MFA blocked access.
• Vishing and smishing channels — email-only testing ignores the phone/SMS vectors that frequently yield help-desk credential resets and MFA-fatigue approvals. Script a help-desk pretext and track info disclosed.
• Email-auth and gateway reality check — confirm whether the spoof actually bypassed the secure email gateway and what the target's SPF/DKIM/DMARC posture is (weak/missing DMARC = trivial spoofing); this turns a "people problem" into a fixable technical control.
• Physical/tailgating and USB-drop where scoped — badge cloning, tailgating, and dropped-payload pickup expose controls email never touches.
• How to confirm: capture artifacts proving impact — GoPhish event logs (sent/opened/clicked/submitted with timestamps), a captured session cookie replayed into a live session (MFA bypass), a recording/notes of disclosed info on a vishing call, or photos of accessed restricted areas. Don't conclude the workforce is resilient until you have also measured the report rate and tested at least one non-email channel; don't conclude MFA is effective until you have attempted a real-time relay against it.

Prerequisites

• Written authorization from senior management (CISO/CTO)
• Legal review confirming compliance with local laws (CFAA, GDPR, etc.)