Master the full SE threat assessment methodology — mapping the human attack surface through organisation profiling, email enumeration, and breach data correlation, then modelling realistic attack vectors, understanding the psychological principles behind social engineering, and producing professional reports that drive measurable security improvements.
OSINT and Social Engineering Threat Assessment
A social engineering threat assessment combines deep OSINT research on a target organisation with analysis of how that information could be weaponised. The output is a professional report helping organisations understand their human attack surface and prioritise awareness training. This goes beyond simple enumeration — it requires correlating findings across sources, identifying highest-risk employees, and modelling realistic attack scenarios with believable pretexts.
Why Social Engineering Succeeds Where Technical Attacks Fail
The reason social engineering remains one of the most effective initial access techniques in real-world adversarial operations is not that it exploits unknown vulnerabilities — it exploits properties of human cognition that are adaptive in normal social contexts but create predictable weaknesses under adversarial conditions. Authority, urgency, familiarity, reciprocity, and fear all override careful decision-making in ways that no security patch can address.
A technically well-defended organisation — patched systems, MFA deployed, EDR on every endpoint — can still be penetrated by a well-researched social engineering campaign that either extracts credentials directly from a user, or convinces an administrator to take an action (installing software, changing a configuration, approving a payment) that a technical control would otherwise block. Social engineering is in this sense the meta-attack: it weaponises the humans who administer and use the technical controls, rather than attacking the controls themselves.
Imagine a fortress with impenetrable walls, guarded gates, and sophisticated alarm systems. An attacker who tries to scale the walls or pick the locks will trigger every defensive layer. But a different attacker, dressed as a delivery driver with a convincing uniform and a plausible story about an urgent package for the commander, is simply walked through the gate by a guard who has no reason to suspect deception. The fortress's designers built their defences against direct attack — they didn't build them against someone who uses human trust and process familiarity as their entry vector. That is precisely the gap a social engineering threat assessment maps and helps organisations close.
SE Threat Assessment Framework
Phase 1: Organisation Profiling Employee names, roles, reporting structure from LinkedIn Technology stack from job postings and press releases Partners, vendors, clients from public announcements Phase 2: Individual Targeting Email pattern discovery and verification Social media for personal details to build pretexts Breach data correlation for credential stuffing risk Phase 3: Attack Vector Analysis Which employees respond to which pretexts? Which departments have access to which systems? Phase 4: Reporting Pretext scenarios with believability ratings High-risk employee profiles (access + susceptibility) Recommended awareness training and process controls
OSINT and SE Assessment in Practice
Job postings, LinkedIn, and press releases reveal far more than organisations realise — including full technology stack and internal structure.
# Job posting intelligence: Senior DevOps Engineer requires: AWS (EKS, RDS, S3), Kubernetes, Terraform, Ansible, Jenkins, GitLab CI Reports to: Director of Engineering (John Martinez) # Full tech stack and org chart exposed in a single job posting # LinkedIn reconstruction: Sarah Chen -- IT Manager (manages 3 sysadmins) Tom Walsh -- Finance Director (ERP system access) HR contact visible: hr@targetcorp.com
Identifying the email naming convention allows generating valid addresses for any employee found on LinkedIn.
# Samples discovered from press releases and speaker bios: j.martinez@targetcorp.com s.chen@targetcorp.com t.walsh@targetcorp.com # Pattern confirmed: f.lastname@targetcorp.com # Verify validity without sending (SMTP verification): python3 smtp_verify.py cfo@targetcorp.com Valid: True (SMTP server accepted recipient) # Now generate emails for all 847 LinkedIn employees -- full target list
Using gathered OSINT, construct believable pretexts with contextually accurate details that would challenge even a trained employee.
Target Sarah Chen, IT Manager, 7 years at TargetCorp, reports to CTO Pretext 1 - IT Vendor Impersonation "Hi Sarah, this is Mike from Cisco TAC. We're seeing anomalous traffic on your ASA at the Denver office. Can you confirm the admin credentials so we can run diagnostics remotely?" Believability: HIGH (IT role, vendor contact normal, specific detail) Pretext 2 - Internal Security Audit "Sarah, security team here -- CTO-requested access review. Can you share the current admin list for the Jenkins server?" Believability: HIGH (references known reporting line, plausible)
Past breaches of external services may contain employee credentials reused for corporate access.
# HaveIBeenPwned domain search: targetcorp.com found in 4 breaches: LinkedIn 2012: 23 accounts | Adobe 2013: 8 accounts Collection #1 2019: 44 accounts | Gravatar 2020: 19 accounts s.chen@targetcorp.com:Summer2020! (from LinkedIn breach) j.martinez@targetcorp.com:Welcome123 (from Collection #1) # ~23% of people reuse passwords -- test against VPN, O365, Citrix immediately
The output is a professional report with findings, risk ratings, and actionable recommendations prioritised by business risk.
Executive Summary Overall SE Risk: HIGH Key Finding: 44 corporate emails in breach databases Immediate Action: Force password reset for all affected accounts High-Risk Profiles 1. Sarah Chen (IT Manager) -- system access + 2 pretext vectors 2. Tom Walsh (Finance Director) -- ERP access + email in 3 breaches 3. HR department (4 staff) -- all employee data + salary info Attack Scenarios by Likelihood CRITICAL: Credential stuffing (44 accounts in breach data) HIGH: IT vendor impersonation (tech stack fully enumerated) MEDIUM: CEO fraud BEC (executive hierarchy mapped) Recommendations Phishing simulation programme (quarterly), MFA on all portals, Call-back verification procedure for IT vendor requests
What You Need to Know
The Psychology Behind Social Engineering — Why It Works
Effective social engineering is not primarily a technical discipline — it is an applied psychology discipline. Understanding the cognitive mechanisms that make people vulnerable to manipulation is essential both for constructing realistic threat scenarios in an assessment and for designing training programmes that actually change behaviour rather than just raising abstract awareness.
The psychological principles exploited in social engineering attacks have been extensively studied and documented. They are not quirks or failures of the people targeted — they are adaptive shortcuts that help humans function efficiently in normal social contexts. The problem is that they were developed for an environment where impersonation and deception were costly and relatively rare, not for one where a sophisticated adversary can research a target for weeks and construct a highly plausible false context.
The Six Principles Most Commonly Exploited
- Authority: People comply with requests from perceived authority figures — managers, executives, regulators, law enforcement, vendor support teams. The "IT vendor impersonation" and "CTO-requested audit" pretexts in Example 03 both exploit authority directly. A request from an authority figure creates a psychological obligation to comply that overrides normal scepticism.
- Urgency: Time pressure degrades decision quality. A request that "requires immediate action to prevent a serious incident" is harder to verify carefully than one with no deadline. Most social engineering pretexts include an urgency element — "we're seeing anomalous traffic right now" — specifically to prevent the target from pausing to verify.
- Familiarity: People are more compliant with individuals and organisations they already know or recognise. OSINT-driven pretext development specifically exploits this — using the target's actual manager's name, the correct vendor name, and accurate internal terminology creates a sense of familiarity that makes the request feel legitimate.
- Social proof: People look to others for cues about how to behave. "I've already spoken with your colleague James and he confirmed the procedure" invokes social proof to reduce the target's need for independent verification.
- Reciprocity: People feel obligated to return favours. An attacker who opens with something helpful ("I noticed an anomaly on your network and wanted to let you know") creates a sense of obligation that makes the subsequent request feel reasonable.
- Scarcity/Fear: Fear of negative consequences motivates action. "If we don't run this diagnostic in the next 30 minutes, your systems may be compromised" combines fear and urgency to override careful thinking.
High-Risk Role Identification — Access Meets Susceptibility
Not all employees represent equal risk in a social engineering threat assessment. Risk is the product of two factors: the access a successful attack against this person would yield, and the plausibility and number of pretexts that could be credibly directed at someone in this role. The intersection of high access and high pretext availability defines the highest-priority profiles in any assessment.
| Role | System Access | Pretext Vectors | Risk |
|---|---|---|---|
| IT Administrator / Sysadmin | Domain admin, all servers, firewall, VPN config | Vendor support calls, security audit requests, emergency access, software licensing | Critical |
| Finance Director / AP Clerk | ERP system, banking portals, payroll, wire transfer authority | CEO fraud (BEC), supplier invoice fraud, auditor requests, payroll verification | Critical |
| HR Manager / HR Staff | All employee PII, salary data, org chart, access provisioning | Payroll diversion, background check requests, candidate verification, benefits admin | High |
| Executive Assistant | Executive calendar, travel, high-trust email proxy, often executive system access | Executive impersonation (acting on behalf of), vendor management, facility access | High |
| Receptionist / Facilities | Physical building access, visitor management, delivery acceptance | Vendor deliveries, maintenance contractors, courier pickup, IT equipment delivery | High |
| Developer / DevOps | Source code repositories, CI/CD pipelines, cloud infrastructure, API keys | Code review requests, deployment issues, security researcher contact, repository access | Medium-High |
The Convergence Profile — When Access and Pretext Vectors Combine
The highest-value targets in any assessment are individuals whose role provides multiple independent pretext approaches, each of which would yield different high-value access. An IT Manager who handles vendor relationships, has domain admin credentials, and whose email appears in breach databases is simultaneously a credential stuffing candidate, an IT vendor impersonation target, and an authority-based access request target. Three distinct attack vectors converge on one person — any one of which succeeds provides different but equally serious access.
Identifying these convergence profiles — and communicating them clearly to the client — is one of the highest-value outputs of an SE threat assessment. The client cannot protect against threats they don't know are specifically aimed at specific individuals. Naming names (within the constraints of the engagement scope and with appropriate client authorisation) makes the abstract concrete and is what separates a useful assessment from a generic risk overview.
Business Email Compromise and Targeted Attack Modelling
Business Email Compromise (BEC) is one of the highest-impact social engineering attack categories, consistently responsible for billions of dollars in annual losses according to FBI IC3 reporting. It deserves specific coverage in any SE threat assessment because it is directly enabled by the OSINT methodology — the executive hierarchy, reporting lines, and financial process information that a thorough assessment collects maps directly to the intelligence an attacker needs to execute it.
How BEC Works — The Executive Impersonation Chain
A BEC attack typically follows a sequence: OSINT identifies the CEO, CFO, and finance processing staff and maps the approval chain for wire transfers or vendor payments. The attacker either compromises an executive's actual email account (through phishing or credential stuffing) or registers a lookalike domain (targetcorp.co vs targetcorp.com). They then send a time-pressured payment instruction to the finance team from what appears to be a senior executive, invoking authority and urgency to bypass normal verification procedures.
The reason BEC assessments are so important is that the attack requires no technical exploitation — no malware, no vulnerability, no access to any system. It is a pure social engineering attack driven entirely by publicly available information. An organisation can have perfect technical security and still lose millions through a BEC attack if their financial processes do not include out-of-band verification requirements.
Demonstrating to a client how the publicly available information from their LinkedIn and company website directly enables a BEC attack — making the abstract threat concrete and reportable.
# OSINT collected in Phase 1 and 2 that enables BEC: CEO: David Park (LinkedIn: 847 connections, posts regularly) CFO: Maria Santos (LinkedIn profile: "final approval on all payments") AP Manager: James Lee (LinkedIn: "processes vendor payments daily") # Lookalike domain detection (should flag in threat assessment): dnstwist targetcorp.com targetc0rp.com -- registered 3 months ago (active MX records!) targetcorp.co -- available targecorp.com -- available # BEC scenario modelled in report: Attack chain: From: david.park@targetc0rp.com (lookalike domain) To: james.lee@targetcorp.com Subject: URGENT - Confidential acquisition payment James -- finalising acquisition today, need you to process $247,000 wire to our legal counsel before close of business. Maria has approved. Do not discuss with others -- NDA required. Wire instructions attached. Confirm when sent. # Authority + Urgency + Familiarity + Secrecy = high success probability
A practitioner begins an SE threat assessment for a mid-sized professional services firm. Starting only from the company name and website, ninety minutes of structured OSINT produces the following: the full executive team (CEO, CFO, COO, CTO) identified by name and photographed from conference speaker bios; the AP manager and two AP clerks identified from LinkedIn, along with their stated responsibilities; the email naming pattern confirmed as firstnamelastname@firm.com from three press release signatory emails; the primary banking relationship inferred from a "proud to partner" LinkedIn post; and a lookalike domain (firm-payments.com) registered two months prior with active MX records.
This information, assembled entirely from public sources in under two hours, is sufficient to construct a highly credible CEO-to-AP-clerk BEC scenario. The lookalike domain finding elevates the assessment from theoretical risk to active threat — someone has already done the preparatory work for this attack. The report recommendation is immediate: deploy DMARC p=reject, implement dual-approval requirements for all wire transfers over $10,000, and conduct mandatory out-of-band verification training for the AP team specifically.
Reducing the Human Attack Surface — Organisational Controls
The goal of an SE threat assessment is not simply to enumerate vulnerabilities in the human layer — it is to produce recommendations that the organisation can actually implement. Unlike technical vulnerabilities, which have specific patches or configuration fixes, social engineering risk requires a combination of process controls, technical mitigations, and ongoing behavioural training. Understanding which controls address which specific threat vectors allows practitioners to give prioritised, actionable guidance rather than generic "train your employees" advice.
Credential stuffing: Breached passwords tested against corporate portals.
IT vendor impersonation: Attacker poses as known vendor support staff.
CEO fraud / BEC: Executive impersonation targeting finance staff.
Phishing / spear-phishing: Targeted emails delivering malware or harvesting credentials.
Vishing: Voice-based social engineering targeting help desk or IT staff.
MFA on all portals. Breached passwords alone are insufficient — second factor required. Phishing-resistant MFA (FIDO2/WebAuthn) preferred.
Vendor call-back verification. Any request for credentials or config changes from a vendor must be verified by calling back on a number from the official vendor website — not one provided by the caller.
Out-of-band payment verification. Any wire transfer request by email requires a phone call to the requestor using a stored number — regardless of stated urgency. No exceptions.
Email authentication (DMARC p=reject). Prevents domain spoofing. Anti-phishing training for targeted staff with role-specific examples.
Help desk identity verification protocol. Standardised script requiring identity verification before any access change — cannot be bypassed regardless of urgency claimed by caller.
Why MFA Is the Highest-ROI Single Control
Of all the controls available against the social engineering threat vectors mapped in this assessment methodology, MFA provides the highest return on investment for a single control. It does not prevent social engineering — a phishing campaign can harvest MFA-protected credentials and OTPs through real-time phishing proxies (Evilginx-style attacks). But it eliminates the entire credential-stuffing attack class entirely, which in a typical assessment represents the highest-likelihood immediate threat (credentials already in breach databases, testable today).
Phishing-resistant MFA (FIDO2 hardware security keys or platform authenticators like Windows Hello and Touch ID) goes further — it eliminates real-time phishing proxy attacks too, because the authentication is cryptographically bound to the legitimate domain. A FIDO2 credential registered on corp.example.com cannot be used on corp.examp1e.com regardless of how convincing the phishing page is. For high-value targets (executives, IT administrators, finance staff), phishing-resistant MFA is the recommended standard.
Scope, Consent, and Ethical Boundaries in SE Assessments
Social engineering assessments occupy a uniquely sensitive ethical space within penetration testing. Unlike network scanning or web application testing — which affect systems — SE assessments target human beings: real employees with real psychological responses to being deceived, even in an authorised professional context. The ethical framework governing these assessments requires more careful consideration than most other testing types.
What Requires Explicit Scope Definition
A general penetration testing authorisation does not automatically include social engineering assessment. The statement of work for an SE engagement should explicitly address:
- What is in scope: Specifically authorised activities — passive OSINT only, or does the assessment include simulated phishing? Vishing (phone calls)? Physical pretext testing? Each has different risk profiles and requires separate authorisation.
- Which employees can be targeted: Some clients authorise full-population targeting; others restrict to specific departments. Targeting an individual not listed in the scope without authorisation is not acceptable regardless of how relevant they appear.
- What information can be collected and retained: SE assessments collect personal data about employees — names, email addresses, roles, personal social media content, breach data. The statement of work should specify how this data is handled, stored, and destroyed after the engagement.
- Notification protocol: If an employee responds to a phishing simulation, do they receive immediate notification that it was a test? Or is the data collected for aggregate reporting without individual feedback? Both approaches are used in the industry; both require explicit client decision and consent.
Core Concepts Summary
You've covered the theory. Now apply it hands-on in the simulated environment.
Start Lab — OSINT & SE Threat Assessment→← Return to all labs