Phishing Simulation & Awareness
Vishing and Voice Social Engineering
The service desk exists to help people who are locked out, and an attacker phoning as a locked-out executive is asking it to do exactly what it is for. Every major identity-based breach of recent years has a phone call in it somewhere. This assessment tests the verification process under the conditions that actually break it: urgency, seniority and a caller who sounds right.
Methodology
- 01
Scope and safeguards
Agreed with a small control group: which numbers, which teams, what an operator will never ask for, and the phrase that ends a call immediately if a target becomes distressed.
- 02
Reconnaissance
Public sources for staff names, role titles, reporting lines, internal terminology and the details a legitimate caller would know.
- 03
Pretext development
Scenarios matched to what the service desk routinely handles — password reset, MFA re-enrolment, new device, urgent access before a board meeting.
- 04
Service desk testing
Calls to the service desk attempting password reset, MFA re-enrolment or access grant, measuring which verification steps are applied and which are waived under pressure.
- 05
Staff testing
Calls to general staff attempting to obtain information or induce an action: credential disclosure, remote access approval, or confirming a fraudulent payment.
- 06
Voice cloning assessment
Where explicitly authorised, a synthesised voice of a known executive built from public audio, testing whether voice recognition is used as an authentication factor in practice.
- 07
Debrief
Individual debriefs conducted supportively, with emphasis on the process gap rather than on the person who followed it.
- 08
Reporting
Technical report on verification process and controls, executive summary on outcome and risk.
Approach to testing
- Operators never ask for a password directly and never record a call without consent. The objective is testing the process, not collecting credentials.
- Calls are scripted to a stopping point. If a target becomes distressed the operator discloses immediately, regardless of where the call had reached.
- The service desk is the primary target because it is the control point. General staff testing is secondary and often less informative.
- Voice cloning requires separate written authorisation and the consent of the person whose voice is cloned. It is powerful, it is uncomfortable, and it is not done quietly.
- Findings are attributed to the process, not the agent. A service desk agent who resets a password under pressure from a convincing executive is following the incentives the organisation created.
Types of assessment
Service desk assessment (default)
Calls to the service desk attempting account recovery actions. The highest-value scope, because it is a single control point.
Staff social engineering
Calls to general staff for information disclosure or action. Broader, noisier, and usually less actionable.
Executive impersonation by voice
Calls purporting to be from a senior figure, testing whether authority overrides verification.
AI voice cloning assessment
Synthesised voice from public audio. Requires separate written authorisation and the consent of the cloned individual.
Frameworks and standards
- MITRE ATT&CK T1598.004 / T1656
- Spear phishing by voice and impersonation technique references.
- NIST SP 800-63-3
- Identity assurance and the verification requirements for account recovery.
- ISO/IEC 27001 Annex A.5.17
- Authentication information handling, where the client maintains an ISMS.
- Social engineering engagement ethics guidance
- Consent, disclosure and welfare practices governing how the engagement is run.
Tools used
Tooling is where testing starts, not where it ends. Every automated result is reproduced by hand before it reaches a report.
VoIP with caller ID control
Demonstrating that displayed caller ID is not an authentication factor.
Open-source reconnaissance tooling
Staff names, roles, reporting lines and internal terminology from public sources.
Voice synthesis tooling
Where authorised, cloning from publicly available audio such as conference recordings or earnings calls.
Call logging
Documenting each attempt, the verification applied and the outcome, for the report.
Checklist approach
The checklist is the floor, not the ceiling. It guarantees coverage so nothing standard is missed; the findings that matter usually come from what a tester does after it is complete.
Service desk verification
- Verification steps documented and actually applied
- Whether verification is waived for senior callers
- Knowledge-based verification using information available publicly
- Out-of-band callback to a number held on record
- MFA re-enrolment process and its verification strength
- Escalation path when a caller cannot be verified
Resistance to pressure
- Behaviour under time pressure and claimed urgency
- Behaviour when the caller claims seniority
- Behaviour when the caller expresses frustration
- Whether agents feel able to refuse
- Whether refusing has ever led to a complaint against an agent
Caller identity
- Caller ID treated as evidence of identity
- Voice recognition used informally as authentication
- Internal extension spoofing acceptance
- Verification of callers claiming to be from IT to staff
Staff behaviour
- Information disclosed to unverified callers
- Remote access sessions approved on request
- Willingness to confirm payment or supplier details
- Reporting of suspicious calls, and to whom
Process and logging
- Call records retained for account recovery actions
- Alerting on password and MFA reset for privileged accounts
- Whether a fraudulent reset would be detected afterwards
- Post-reset notification to the account owner
How findings are scored
Every finding is scored on CVSS 3.1 and placed in one of five levels. The executive summary adds a sixth band — Compliant — so components that passed appear on the same chart as those that did not.
- Critical
- Immediate measures must be taken. These vulnerabilities can allow an attacker to take complete control of the application or server — stealing user data, tricking users into supplying sensitive information, or defacing the site.
- High
- Maximum risk associated with a specific vulnerability instance. May enable an attacker to compromise the application and its data, partially or completely, or to modify application behaviour beyond its intended purpose. To be handled with utmost priority.
- Medium
- Considerable risk. May enable an attacker to exploit the application to a particular level, gaining low-level information that can be used to craft more specific attacks.
- Low
- Lowest risk. May allow an attacker to gain some information about the application that was not intended to be known, without an exploitation technique currently available at that instance.
- Informational
- A functionality or component is missing best-practice implementation. Not a risk today, but may become one as the application changes or as exploitation techniques, policy or legal requirements evolve.
Scan types selected
- Safe Checks
- Standard / OWASP Top 10
- Destructive
- SANS Top 25
- Business Logic Vulnerability Testing
Standard toolset by stage
- OSINT
- Datasploit, Google Dorks, Shodan
- Enumeration & Scanning
- Nmap, Wfuzz, Unicornscan
- Domain Enumeration
- Nikto, DnsRecon, Knock
- Crawling & Fuzzing
- Burp Suite, Acunetix, Netsparker
- Vulnerability Analysis
- OpenSSL, sqlmap, CVE-Details
- Exploitation
- Metasploit, Netcat, Exploit-DB
How CSS tests
A unified swarm of agents, for blind spot detection
AI agents drive several testing tracks against the same target at once, then cross-check each other. A single tester works one hypothesis at a time; parallel agents cover the space a sequential pass leaves behind.
Reconnaissance for pretexts — names, reporting lines, internal terminology, project names — is breadth work across public sources.
Analysing which verification steps were applied across many calls produces a per-step compliance figure rather than an anecdote.
Correlating call attempts against the client's own service desk ticket records shows how many attempts were recorded at all, which is frequently fewer than were made.
Voice sample discovery across public audio sources is search rather than craft.
No agent makes a call. Every call is placed and conducted by a human operator working to an approved script, with disclosure the moment a target is distressed. Agents support reconnaissance and analysis only. Voice synthesis, where used, requires the consent of the cloned individual.
Why this differs
What CSS does that most vendors do not
Every one of these is checkable. Ask any vendor for the same and compare the answers.
Process, not people
Findings are attributed to the verification process and the incentives around it. An agent who complies under pressure from an executive is behaving as the organisation has trained them to.
Welfare is designed in
Scripts have a stopping point, operators disclose the moment a target is distressed, and debriefs are supportive. Engagements that traumatise staff produce staff who conceal real incidents.
Voice cloning done openly
Where in scope it requires the consent of the person cloned. CSS will not clone an executive's voice without telling them, which some vendors will.
Both reports, always
Technical report on process and controls, executive summary on outcome and exposure.
Reporting
Two documents, two audiences
Both are produced for every engagement. They are not the same document at two lengths — they answer different questions and are written separately. The structure below is the one CSS actually issues.
Technical assessment report
For the engineers who will fix it
- Disclaimer, and Limitations on Disclosure and Use
- Risk Level & Description — the five levels above, scored on CVSS 3.1
- Scan Type — which of the five assessment types were selected
- Assessment Scope — the control areas covered
- Assessment Date — the exact testing window
- Objective of the Assessment — objectives listed against completion status
- Tools Utilization — manual and automated tooling by stage
- Summary of the Assessment
- Overall Recommendations, split into Must Have and Should Have
- Vulnerability Overall Classifications as per Organization
- Security Issues Highlighted
- The Key Findings — each with evidence and detailed recommendation
- Summary of Findings & Conclusion
For this assessment specifically
- Scope, pretexts, numbers called and the engagement window
- Per-call record: pretext, verification steps applied, steps waived, outcome
- Verification compliance as a per-step figure across all attempts
- Reconnaissance findings that made the pretexts plausible
- Voice cloning outcome where in scope, with the consent record
- Logging and detection findings: which attempts were recorded or alerted
- Process recommendations with example verification scripts
Executive summary
For the people who will fund the fix
- Objectives, each against a completion status
- Overall Finding of the Assessment — total threats identified, broken down by component and severity
- Summary of the Assessment
- Artefacts of the Assessment — the key findings as a numbered register with severity
- Observation of the Assessment — the major attacks the organisation should be prepared for, given what was found
- Overall Recommendation, including a Business Enabling Recommendation sequence
- Must Have and Should Have actions
For this assessment specifically
- Whether an attacker could obtain account access by telephone today
- Whether seniority or urgency causes verification to be waived
- Whether a fraudulent reset would be detected afterwards
- The three changes that most strengthen verification
- One page
Case studies
What this finds in practice
Representative engagement patterns. Sector and scale only — no client is named, and no detail is included that could identify one.
A financial services firm with an in-house service desk of twelve agents.
- Finding
- Seven of ten calls resulted in a password reset. The documented process required callback to a number on record; in practice agents accepted employee ID and date of birth, both discoverable. Every call claiming urgency before a board meeting succeeded.
- Recommendation
- Mandatory callback to the number held in the directory for every reset, no exceptions for seniority, and explicit management backing so agents can refuse without fear of complaint.
- Outcome
- Callback made mandatory with a documented exception process requiring manager approval. The retest achieved one reset out of ten, and that one was correctly flagged afterwards.
A healthcare provider with an outsourced service desk.
- Finding
- MFA re-enrolment required only the employee number. Three successful re-enrolments were achieved, giving full account access despite MFA being enforced. None generated an alert, and the account owners were not notified.
- Recommendation
- Treat MFA re-enrolment as a privileged action requiring out-of-band verification, alert the security team on every re-enrolment, and notify the account owner immediately.
- Outcome
- Verification and alerting implemented within a month. Owner notification caught a genuine unauthorised re-enrolment attempt within the first quarter.
A manufacturer, authorised voice cloning assessment with the CFO's written consent.
- Finding
- A synthesised CFO voice built from a publicly available earnings call convinced two of three finance staff to confirm supplier bank details, and one to begin a payment amendment. Staff reported afterwards that they had recognised the voice and treated that as verification.
- Recommendation
- Establish explicitly that voice is not an authentication factor, require out-of-band confirmation via a separate channel for any payment change, and brief finance staff specifically on voice synthesis.
- Outcome
- The out-of-band rule was implemented immediately. The CFO's decision to consent and then discuss the result openly with the finance team was, per the client, what made the lesson stick.
Next
Scope this assessment
Most scopes are settled in one call. Tell us what the application does and who uses it, and we will tell you what testing it properly involves.