Social Engineering Testing: What Phishing Simulations Miss

Introduction

Ask most organisations how they test their people and you will hear about the monthly phishing simulation. A templated email goes out, a percentage of staff click, the click rate is compared with last quarter, and the people who clicked get a short training module. The dashboard trends downwards and the board is told that human risk is improving.

None of that answers the question that matters. If someone rings your service desk tomorrow, sounding confident and knowing the name, manager and job title of a senior finance user, will they leave the call with a new password and a fresh MFA enrolment?

That question is no longer theoretical. In October 2026, ASOS said an unauthorised party had gained access to an employee account "by impersonating a trusted contact to obtain log in credentials", and then used those credentials to reach information on third-party platforms the company relies on. Eighteen months earlier, Marks & Spencer's chairman told MPs that the April 2025 intrusion behind its ransomware attack began with what he called a "sophisticated impersonation", and that a third party was part of the point of entry. Neither attack began with a zero-day. Both began with a conversation.

In our work we keep seeing the same gap. Email phishing gets measured. The telephone, the Teams chat, the password-reset workflow and the outsourced service desk usually do not. This article explains why click-rate simulations miss the attacks that actually cause harm, what a proper social engineering assessment examines, and how to commission one that produces evidence rather than a percentage.

The Attack Has Moved Off the Inbox

Email filtering, link rewriting and attachment sandboxing have made mass phishing less reliable for capable attackers. They have adapted by going where those controls do not reach.

ReliaQuest's threat report for June to August 2026 describes a sustained wave of help desk impersonation. Attackers posed as internal IT support and contacted employees through external Microsoft Teams accounts or voice calls, including calls to personal phones. Once inside, they registered their own devices and authentication methods so that a password reset alone did not remove them. Microsoft has separately warned that external Teams collaboration is being abused for the same purpose: impersonate helpdesk staff, persuade the user to start a Quick Assist or similar remote session, then move laterally with tools that look like ordinary IT support.

The pattern is consistent across sectors. A plausible identity. A familiar channel. A request that staff are trained to fulfil quickly. No exploit required.

After the 2025 retail incidents affecting Marks & Spencer, Co-op and others, the UK National Cyber Security Centre urged organisations to review helpdesk password reset processes, including how the helpdesk authenticates staff before resetting passwords, especially for accounts with escalated privileges. That guidance remains relevant. The October 2026 ASOS disclosure shows the same class of technique still succeeding against large UK organisations.

A phishing simulation that only measures clicks on an email does not test any of this.

What Phishing Simulations Are Good At, and Where They Stop

We are not arguing that email simulations are useless. Done well, they have a clear job.

They exercise staff recognition of common email lures. They generate a metric that training programmes can track over time. They can surface departments that need more attention. For organisations that have never measured human risk at all, they are a reasonable first step.

They stop well short of an adversarial test.

They measure a single channel

Most commercial platforms specialise in email. Some add SMS. Very few operate a convincing telephone pretext against your actual service desk, and almost none attempt a cross-tenant Teams conversation that looks like your own IT function. Attackers now routinely combine channels. A simulation that only covers one of them leaves the others unexamined.

They score individuals, not processes

A click rate tells you how many people interacted with a lure. It does not tell you whether your identity verification policy held when a confident caller demanded a password reset for a privileged account. The control that fails in real incidents is often procedural: the script that the service desk follows, the exceptions that managers authorise under pressure, the outsourced contractor who has never seen your verification standard. People are part of that failure. The process is usually the larger part.

They rarely follow the path to impact

A clicked link and a harvested password are the start of an attack, not the end. A useful assessment asks what happens next. Can the captured session reach SharePoint or a customer system? Does MFA enrolment still accept a new authenticator from an unfamiliar device? Would detection fire if the same account began enumerating files six minutes after a new MFA method was registered? Click-rate reports stop at the click.

They train for the wrong adversary

Generic templates about parcel deliveries and shared documents still catch some staff. They do not resemble the call that names a colleague, references a half-known ticket number, and asks for a Quick Assist session "to finish the patch". Awareness content built only on email lures leaves staff unprepared for the pressure of a live conversation.

What Social Engineering Testing Actually Examines

A social engineering assessment is a scoped, rules-of-engagement-bound attempt to abuse the human and procedural layer of your organisation. It is not a prank. It is not a trap designed to embarrass individuals. It is an evidence-gathering exercise against the pathways a real adversary would use.

At Mongoose Cyber Security, as a CREST-accredited penetration testing company, we treat these engagements with the same structure we apply to technical tests: agreed targets, clear stop conditions, careful handling of personal data, and reporting that focuses on paths and controls rather than naming and shaming.

Reconnaissance that mirrors a real attacker

Before any contact, testers build the same picture an adversary would. Public LinkedIn profiles, job adverts, press releases, conference speakers, leaked credential dumps, and the organisation's own websites reveal names, roles, tools, vendors and vernacular. The goal is not to dox staff. It is to understand which pretexts will sound ordinary to the people who answer the phone.

If your estate looks closed from the internet but your org chart is wide open, that itself is useful intelligence for the report.

Multi-channel phishing and smishing

Email and SMS remain in scope. The difference from a platform simulation is intent and depth. Lures are written for your organisation, your vendors and your current events. Landing pages and credential captures are instrumented so that testers can see whether a session token, not only a password, was obtained. Where rules of engagement allow, a successful capture is followed a short distance to show business impact, then stopped.

The finding that matters is not "twelve people clicked". It is "from a captured finance session, this SharePoint site and this invoice export were reachable without a further challenge".

Vishing against staff and the service desk

Voice phishing is where many organisations have the least evidence. Testers call agreed targets or the service desk itself with pretexts that match real requests: locked accounts, travel MFA failures, urgent month-end access, vendor onboarding. The test measures whether identity is verified before action is taken, whether privileged resets require a second channel, and whether staff push back when the call feels wrong.

In our experience, the service desk is often the highest-value target in the entire engagement. A single successful reset of a privileged or well-connected account can achieve more than a hundred clicked phishing emails.

Collaboration-platform impersonation

Microsoft Teams, Slack and similar tools now sit beside email as primary business channels. External federation, guest accounts and lookalike tenants let an attacker appear as "IT Support" in a chat window that staff use all day. A modern social engineering assessment includes at least a controlled attempt on this surface where the organisation uses it. Restricting external collaboration is a technical control. Testing whether staff still trust an unexpected IT request is a human one.

MFA and identity persistence

The prize is rarely the password alone. ReliaQuest and others have documented attackers registering their own devices and MFA methods so that access survives a password change. A competent test checks whether a socially obtained session can enrol a new authenticator, whether device registrations are reviewed, and whether containment procedures revoke refresh tokens and remove unknown methods, or only reset the password and close the ticket.

Conversion to technical impact

Where authorised, social access is handed to the technical team on the same engagement, or documented as a clear hand-off point. The question for the board is not whether someone answered the phone. It is whether that conversation became a path into email, files, finance systems or the internal network. Connecting the human finding to the technical path is what turns a soft skill exercise into a penetration testing result.

Realistic Patterns From Engagements

The following examples are anonymised composites drawn from assessments we have performed. They are representative, not theatrical.

A professional services firm scored well on quarterly phishing simulations. Click rates sat below five percent. During a scoped vishing exercise, the outsourced service desk reset the password of a finance controller after the caller recited the employee ID and manager name found on LinkedIn. MFA was re-enrolled to an attacker-controlled app in the same call. No email was involved.

A manufacturing client had blocked external email links aggressively. Testers contacted a plant supervisor through an external Teams tenant using a display name that matched the internal IT naming convention. The supervisor started Quick Assist to "complete a patch". From that session, testers demonstrated access to a shared engineering folder and stopped. The organisation had never tested Teams as an initial access channel.

A SaaS company required manager approval for privileged password resets. The approval was a Teams message. Testers social-engineered a busy manager into approving a reset for an account they believed was their own direct report's. The verification step existed on paper. Under time pressure it collapsed into a single chat reply.

None of these required novel malware. They required a plausible story, a channel the organisation trusted, and a process that valued speed over verification.

What This Means for the Business

Social engineering risk is not a training metric. It is an access-control failure that happens to use a human as the interface.

A successful help desk reset of a privileged account is equivalent, in impact, to a broken authorisation check on an admin API. Customer data, invoice systems, source code and identity control planes become reachable through a conversation. For organisations processing personal data under UK GDPR, that conversation can become a reportable incident. For firms selling to enterprise buyers, it is a failed answer on the security questionnaire item that asks how identity changes are verified. For boards preparing ISO 27001 evidence, it is a gap in the controls that assume people follow the procedure.

There is also a cultural cost to getting this wrong in the other direction. Assessments that humiliate staff, publish individual click lists, or treat people as the enemy destroy the reporting culture you need when a real call happens. The point of testing is to harden processes and give people a rehearsal against pressure, not to generate a league table of who failed.

Detection matters as much as prevention. If a new MFA method is registered and six minutes later the same account begins bulk SharePoint downloads, would anyone see it? ReliaQuest has documented exactly that sequence in extortion campaigns. A social engineering test that never asks whether telemetry would have fired leaves half the story untold.

How to Commission a Social Engineering Assessment That Produces Evidence

A useful engagement starts with ethics and scope, not with a clever pretext.

Agree who may be contacted, which channels are in bounds, and what "success" looks like before any call is made. Typical starting points include the service desk, a sample of staff roles, external collaboration surfaces, and any outsourced identity functions. Exclude people in known personal difficulty. Exclude channels that would create safety or legal risk. Put the exclusions in writing.

Provide enough organisational context for the test to be realistic. Tool names, ticket formats, and whether you use Quick Assist or a named RMM product are not cheating. They are the same facts an attacker can often learn from job adverts and support pages. Pure black-box testing that pretends the tester knows nothing often wastes days building a pretext that a real adversary would have assembled from public sources in an afternoon.

Decide how far to follow a successful compromise. Capturing a password and stopping is a weak result. Demonstrating that the session reaches a sensitive system, then stopping under the rules of engagement, is a strong one. Copying entire mailboxes or customer databases is almost never justified. Prove the path. Do not become the incident.

Ask for attack paths in the report. "From an external Teams chat posing as IT, a plant supervisor granted remote access; from that session, the engineering share was readable" is usable. "Thirty-eight percent click rate" on its own is not. Remediation advice should name the control that failed: callback verification before resets, phishing-resistant MFA for privileged roles, restriction of external Teams federation, removal of Quick Assist from standard builds, monitoring for new MFA enrolments followed by unusual Graph or SharePoint activity.

Retest after you change the process. A new script that the night-shift contractor has never seen is not a fixed control. A complimentary retest window, which we include within 90 days of the report on our CREST-accredited engagements, exists for that reason. The finding is not closed until the path is gone under realistic pressure.

Align the work with the rest of your testing programme. Social engineering that hands a foothold to an internal network or cloud assessment tells a complete story. Social engineering run in isolation, with no link to what the access enables, understates the risk and overstates the comfort of a low click rate.

Practical Insights / Key Takeaways

1. Treat the service desk as critical infrastructure. Password and MFA resets are privileged operations. Test them the way you would test an admin API.
2. Click rates are not access-control evidence. They measure one channel under low pressure. Real attacks use voice, chat and process exceptions.
3. Verify identity on a second channel before privileged changes. A callback to a known number, a manager approval in a controlled workflow, or an in-person check beats a confident story on an unknown line.
4. Assume collaboration tools are an initial access surface. Restrict external Teams and similar federation. Train staff that unexpected IT requests in chat are hostile until proven otherwise.
5. Containment must remove devices and authenticators, not only passwords. Attacker-registered MFA methods and refresh tokens survive a reset. Your incident playbook should say so.
6. Ask for paths in the report. Connect the conversation to the data or system it reached. That is what boards and insurers can act on.
7. Protect people while you test processes. No public league tables. No gotcha tactics. The goal is a harder organisation, not a frightened workforce.
8. Retest after procedural change. A rewritten script is a hypothesis until someone tries to social-engineer it again.

Conclusion

Human risk is not a soft alternative to technical testing. It is one of the most reliable paths into modern organisations, and it is the path that monthly phishing dashboards measure least well.

Scanners will not tell you whether your helpdesk will reset a stranger's MFA. Email simulations will not tell you whether a plant supervisor will start Quick Assist for a Teams contact they have never met. Only a scoped, ethical, multi-channel social engineering assessment answers those questions with evidence.

If your current assurance is a click-rate trend and an annual web application test, you have a blind spot that recent UK incidents have already illuminated. Close it with a test that starts from a real pretext, follows the path far enough to show impact, and ends with procedural fixes you can actually implement.

Don't wait for a real adversary to find the pathway. Contact our team today to discuss a tailored manual assessment for your organisation.