Social Engineering Audit

Social Engineering Audit

When to Use

Invoke this skill when assessing:

• Authentication and authorization flows (login, MFA, password reset, account recovery)
• Help desk and customer support procedures
• Identity verification and onboarding processes
• Organizational security posture against targeted attacks
• Account takeover risk via non-technical channels
• Physical access control and personnel security

This is not a penetration test. This is a structured assessment of the human-factor attack surface -- the seams where process, trust, and technology meet.

Attack Surface Taxonomy

1. Pretexting Vectors

• Support channels: phone, email, chat, social media DMs. Each is an identity verification boundary. Map them all. Determine what each channel can do (password reset, account unlock, PII disclosure, plan changes).
• Internal help desk: IT support desks are high-value targets. Assess what credentials or verification they require before acting on requests.
• Vendor/contractor impersonation: third-party relationships create implicit trust. Identify which vendors have elevated access or bypass normal auth.
• Authority exploitation: executive impersonation, "urgent" escalation paths, out-of-band requests that skip normal verification.

2. Authentication Bypass via Social Channels

• Password reset: Does the reset flow rely on email alone? Is there a fallback path through support? Can support override MFA?
• Account recovery: What happens when a user "loses everything"? The recovery path is the weakest authentication path.
• SIM swap / number porting: If SMS is used for 2FA or recovery, the phone carrier is part of your authentication chain.
• Session hijacking via support: Can support generate magic links, session tokens, or bypass codes? Under what verification?

3. OSINT Exposure

• Breached credentials: Check paste sites, breach databases. Credential reuse is the simplest attack.
• Social media: Employee roles, org charts, technology stack, office photos (badges, screens, whiteboards).
• Public records: Domain registrations, DNS records, job postings (reveal internal tooling), SEC filings, patent applications.
• Code repositories: Leaked secrets, internal URLs, employee emails in commit history, CI/CD configurations.
• Metadata: Document metadata (author names, software versions, internal paths) in public PDFs, images, office documents.

4. Phishing Surface

• Email authentication: Check SPF, DKIM, DMARC records. A missing or permissive DMARC policy (p=none) means anyone can spoof the domain.
• Lookalike domains: Check for registered typosquats and homoglyph domains. Use dnstwist or similar.
• Link handling: How does the application handle links in emails, chat, notifications? Are URLs previewed, sandboxed, or blindly followed?
• OAuth consent phishing: Can an attacker register an OAuth app with a deceptive name and request broad scopes?

5. Physical Social Engineering

• Tailgating: Badge-controlled entrances without mantraps or visual verification.
• Badge cloning: Proximity card technology (125kHz HID is trivially cloned).
• Impersonation: Delivery, maintenance, IT support pretexts for physical access.
• Dumpster diving: Document disposal procedures, shredding policy.

Audit Methodology

Execute in order. Each step informs the next.

Step 1: Map human-mediated authentication paths. Enumerate every path where a human (support agent, IT admin, manager) can override, bypass, or supplement automated authentication. Document what each path can do and what verification it requires.

Step 2: Identify identity verification procedures. For each human-mediated path: what questions are asked? What constitutes "sufficient" proof of identity? Is it documented or ad hoc? Can the answers be obtained via OSINT?

Step 3: Assess OSINT exposure. Gather publicly available information that could be used to answer verification questions or craft targeted pretexts. Focus on: employee names and roles, email formats, technology stack, org structure, breached credentials.

Step 4: Evaluate phishing controls. Check email authentication records (SPF/DKIM/DMARC). Enumerate registered lookalike domains. Review whether the organization has phishing-resistant MFA (WebAuthn/FIDO2) or phishable MFA (TOTP/SMS).

Step 5: Review account recovery flows. Walk through every account recovery path as an attacker who controls only public information. Identify which paths leak user existence, accept guessable answers, or defer to a human who can be pretexted.

Step 6: Test help desk resistance. Design pretext scenarios based on Steps 2-3. Assess (or recommend testing) whether support staff follow verification procedures under pressure, urgency, or authority cues.

Code Review Patterns

When reviewing application source, flag these patterns:

User Enumeration

# BAD: Different responses for valid vs invalid users
if not user_exists(email):
    return "No account found"     # Leaks existence
return "Reset link sent"

Fix: Return the same response regardless. Send email only if account exists.

Security Questions for Recovery

Any use of security questions (mother's maiden name, first pet, etc.) is a finding. These are OSINT-retrievable and not secrets.

Support Tooling Without Verification Audit Trail

# BAD: Support action with no identity verification logged
@admin_required
def reset_user_password(user_id):
    user.set_random_password()    # No record of what verification was performed

Fix: Require and log the verification method used before any support action.

OAuth/SSO Misconfigurations

• Open redirect in OAuth callback URLs (enables token theft)
• Wildcard or overly broad redirect URI matching
• Missing state parameter validation (CSRF in OAuth flow)
• Auto-approval of OAuth consent for internal apps (can be abused if app registration is open)

Rate Limiting Gaps

# BAD: No rate limit on verification code endpoint
@app.route("/verify-code", methods=["POST"])
def verify_code():
    if request.form["code"] == stored_code:
        grant_access()

Fix: Rate limit by IP and account. Lock after N failures. Use longer codes.

MFA Bypass in Recovery

Look for code paths where MFA is enforced at login but skipped during account recovery, password reset, or support-initiated access.

Output Format

Structure findings as:

### [SE-001] Finding Title

Severity: Critical / High / Medium / Low / Informational
Category: Pretexting | Auth Bypass | OSINT Exposure | Phishing | Physical
Attack Scenario: Concrete, step-by-step description of how an attacker
  exploits this. Name the pretext. Name the channel. Name what they obtain.
Evidence: What was observed (code path, policy gap, DNS record, etc.)
Remediation: Specific, actionable fix. Not "improve training."
References: Relevant standards (NIST 800-63B, OWASP, etc.)

Severity calibration:

• Critical: Direct account takeover via social channel, no technical skill required.
• High: Account takeover possible with moderate OSINT gathering.
• Medium: Information disclosure that enables targeted attacks.
• Low: Weak controls that increase attack surface but require chaining.
• Informational: Observations that inform security posture but lack direct exploit path.

Related Skills

• entry-point-analyzer -- map technical entry points before assessing human ones
• webapp-testing -- complement social engineering audit with technical testing
• audit-context-building -- establish organizational context and threat model

Converted and distributed by TomeVault — claim your Tome and manage your conversions.