IT Impersonation Simulations
Your service desk exists to restore access to people who cannot prove who they are.
An authorized help desk impersonation and IT support impersonation attack simulation, run in both directions. A cloned voice calls your service desk asking for a reset, and a cloned IT support voice calls your users asking for an approval. We measure whether identity verification happened before the action completed, not whether anyone clicked. Runs externally, with nothing installed in your identity stack.
Built for CISOs, identity teams, and the service desks that carry the reset procedure.
Why the service desk is the target
The one team in your organization whose job is to help a stranger who has lost access.
The output is a working credential
A successful reset does not look like an attack. It looks like a ticket closed inside SLA. There is no malware to detect, no exploit to patch, and no alert, because every system in the path did exactly what it was designed to do.
Verification questions are answerable
Employee ID, manager name, department, last four of a number, date of birth. All of it is in a data breach, on a public profile, or obtainable in one earlier call. A knowledge-based check is not identity verification once the knowledge is public.
The voice removed the last friction
Agents are measured on handle time and empathy. A familiar, distressed, senior-sounding voice pushes hard against both. Voice cloning made that voice free, and the accent and hesitation cues agents were told to listen for are gone.
What we run, and what it proves
Six scenarios across both directions of the IT relationship. Run the full set, or scope to the procedure you are least sure about.
A cloned voice calls your service desk as an employee locked out ahead of something that matters, and asks for a password reset or an MFA device re-enrolment. Tests which verification procedure the agent actually applies under pressure, and whether an out-of-band check is performed before the credential changes.
The reverse direction, and the one most programs never test. A cloned IT support voice calls an employee about a security issue on their account and walks them toward a credential, a code, or an approval. Tests whether users have any way to verify that IT is IT.
Repeated push prompts followed by a call explaining them away as a sync issue that will stop once the user approves. Tests whether number matching is enforced, whether an unexpected prompt is treated as an incident, and how long the refusal actually lasts.
A support pretext that ends with the user installing or launching remote assistance software so the caller can fix the problem. Tests application control, the approval path for support tooling, and whether an unexpected remote session is questioned by anyone once it is running.
IT support impersonation inside the collaboration platform your people are told to trust, with a voice or video call arriving through the same channel to close the loop. Tests external tenant controls, the internal support channel convention, and whether the platform itself confers legitimacy.
A cloned senior voice applying authority and urgency to the service desk, or to the agent's manager, to move a privileged action through without the standard check. Tests whether the procedure survives seniority, which is the condition under which it is most often waived.
How the engagement runs
The service desk variant of OSES™, our orchestrated simulation framework. The cloned voice is the vehicle. The subject under test is the identity verification procedure that stands between a phone call and a working credential.
Every engagement runs under signed authorization against your own environment, with agreed target populations, calling windows, named approvers, and documented abort conditions. Where a scenario requires cloning the voice or likeness of a named executive or employee, documented written consent from that individual is required before any asset is generated. Recording is configured to the consent rules of every jurisdiction in scope. Reporting is organizational, never individual: no named agents, no team leaderboards. For the voice channel as a standalone program, see AI vishing simulation, and for the payment and approval chain, CEO fraud simulation.
Service desks with real authority
Organizations where a reset restores access to something worth taking, and the desk is measured on speed.
What makes this different
Both directions, one engagement
Most testing runs one way. Attackers run both: impersonating the user to the desk, and impersonating the desk to the user. Running them together is what exposes the gap where each side assumes the other performed the check.
Live conversation, not a recording
Calls are answered, questions are handled, and the inbound callback is picked up. A voicemail drop cannot test a verification procedure, because the procedure only engages when there is someone on the line to push back against.
The measured outcome is the action
Not a click rate. Whether the reset completed, whether the enrolment went through, whether the session was established, and whether a procedure stopped it in time. That is what feeds the score, and it is what a board can act on.
Real engagements, real findings
A short, focused assault on internal support workflows using deepfake audio and agentic AI. Findings and remediation in days, not quarters.
Read it Case StudyA cloned executive voicemail dropped silently onto company phones at a North American financial services firm. The full engagement, step by step.
Read it Field FindingsWhat actually happens when a cloned voice calls a process owner, drawn from live engagements rather than a threat report.
Read it Case StudyA quarterly engagement against a multinational financial services firm. Cloned executive voice, agentic AI behind it, run against corporate mobile.
Read itCommon questions
What is an IT impersonation simulation?
An authorized engagement in which a cloned voice impersonates IT support to your users, and impersonates your users to IT support, in order to test whether identity verification is performed before a consequential action. The measured outcome is whether a reset, an enrolment, an approval, or a remote session was granted, not whether anyone clicked.
What is help desk impersonation?
An attacker calls the service desk posing as an employee and asks for a password reset, an MFA device re-enrolment, or removal of a security control, usually with a plausible reason and mild time pressure. It is one of the most reliable initial access routes in current intrusions because it produces a legitimate credential rather than a detection event.
How is this different from a phishing simulation?
A phishing simulation ends when someone clicks. This engagement starts where that ends. It follows the interaction into the procedure that acts on it: the verification questions the agent asked, whether the callback went to a number on record or a number the caller supplied, and whether the reset completed. Click rate measures individual detection. This measures whether the procedure held.
Do you clone the voice of a real employee or executive?
Only with documented written consent from that individual, obtained before any asset is generated, with the named person written into scope. Many scenarios need no real likeness at all, because a generic synthetic voice with the right pretext is usually sufficient to test a verification procedure. Where a named executive is in scope, the consent record forms part of the engagement file.
Is this authorized, and how is scope controlled?
Every engagement runs under signed authorization against your own environment, within an agreed scope, target population, and calling window, with named approvers and documented abort conditions. Call volumes and the stop line are agreed in advance, and the engagement halts on the abort signal from either side without argument.
Will this disrupt the service desk?
No. The engagement runs externally with no software installed and no integration into your ITSM or identity stack. Call volumes and windows are set so that queue times and agent workload stay within normal range, and a named contact can pause the engagement at any point.
What actually gets measured?
Whether a consequential action occurred, whether a verification procedure stopped it before it completed, whether anyone reported the attempt and how quickly relative to the action, and how many channels produced a failure. Those observed outcomes feed the OSES™ Score, which is reported alongside your sector position rather than on its own.
What do we receive at the end?
A findings report covering which verification procedure was applied and which was skipped, the point at which the interaction could have been stopped, an OSES™ Score with the sector position alongside it, prioritized remediation written against the specific procedure that broke, and evidence suitable for auditors and cyber insurers without a rewrite.
Find out what your service desk would do
Thirty minutes. We will walk your reset and enrolment procedures and identify which one is worth calling first.
Or read the full assessment methodology.
support@breacher.ai
