A SaaS platform with proper authentication, MFA enforced, and monitored infrastructure. None of it mattered. The technical team at Zerotak took over a user account without touching a single piece of software. We registered an email that looked almost identical to the target’s and raised a support ticket.
The helpdesk processed the email change request. No phone callback. No secondary verification. The account was ours.
This is what social engineering looks like when it goes right, and why pentests that stop at the technical layer give you false confidence.
Why Helpdesk Social Engineering Works
Customer support exists to solve problems quickly. That is the entire job. Agents are measured on resolution time, customer satisfaction, ticket volume. The incentive structure rewards trust and speed.
Attackers exploit exactly that incentive structure. A well-written request from someone who sounds like a legitimate customer, with a plausible reason for the change, sits in the same queue as a hundred legitimate requests per day. The agent who pauses to verify is the agent whose KPIs drop.
This is not a training failure. It is a procedural failure.
In this engagement, the target was a SaaS platform operating in the European market. The objective was scoped narrowly: determine whether an attacker could compromise a user account by manipulating the support workflow. The engagement ran for two weeks, remote, against a dummy target account provisioned by the customer.
The result was full account compromise.
The Methodology
The engagement followed a structured methodology designed to produce defensible findings without disrupting real users. The steps:
- Open Source Intelligence (OSINT) research: building a profile of the target organization, its support channels, common request patterns, and publicly available employee and customer information.
- Scenario development: designing a request that the helpdesk would plausibly receive in normal operation.
- Confirmation of scenario by the customer: the client approved the exact attack scenario before execution. No surprise tactics, no ethical ambiguity.
- Pre-execution notification: a small set of stakeholders on the client side were aware that the engagement was active, to avoid escalation to law enforcement or incident response.
- Social engineering execution: the actual attempt, conducted under controlled conditions against a dummy account.
- Observation and response analysis: documenting how the helpdesk processed the request at each step.
- Post-execution success notification: the support team was informed that the engagement had succeeded, as soon as it succeeded.
- Risk analysis: mapping the procedural gaps to the business impact.
- Documentation and reporting: deliverables for both technical and executive audiences.
This sequence matters. Social engineering assessments that skip scenario confirmation produce findings the client disputes. Assessments that skip post-execution notification leave the support team feeling ambushed. Both kill the value of the engagement.
The Critical Finding: Account Takeover via Helpdesk
The successful attack chain was straightforward:
- Registered an email address visually similar to the legitimate user’s address. Common substitutions: zero for capital O, lowercase l for digit 1, domain typosquats.
- Contacted support while impersonating the legitimate user, using the lookalike address as the apparent sender.
- Submitted a professionally formatted request to change the account email to one under attacker control.
- Claimed a prior phone confirmation had already taken place, although no call had ever occurred. This is the social engineering load-bearing element: a plausible reference to a process the agent cannot easily verify.
The support team processed the email change request without performing secondary identity verification.
Full account takeover, achieved purely through procedural manipulation. No phishing payload. No technical vulnerability.
The remediation here is not a software patch. It is a process change: mandatory secondary verification through a channel the original request did not come from, every time.
What This Engagement Demonstrated
Human and procedural weaknesses can bypass otherwise secure technical controls.
The platform had reasonable infrastructure security, modern authentication, monitored systems. None of it was relevant to the attack path that succeeded.
This is the lesson that traditional penetration testing misses. A web application pentest, no matter how thorough, will not test whether your support team verifies identity before changing an account email. A cloud security assessment will not test whether your customer-facing workflows have procedural single points of failure. Those gaps are only found by looking at the human and procedural layer directly.
Mature security posture requires testing across three layers:
- Technical: web applications, APIs, infrastructure, cloud configuration.
- Procedural: support workflows, account recovery processes, internal escalation paths.
- Human: phishing resistance, awareness, willingness to verify under social pressure.
A platform that has tested only the first layer is not secure. It is a platform that knows its software is hard to attack. The attackers will route around it.
Talk to Zerotak
If you run a SaaS platform, a financial service, or anything with a customer support workflow that can change account ownership, your support process needs the same scrutiny you give your code.
We design social engineering engagements with clear scope, customer-approved scenarios, and zero impact on real users. The deliverable is not a list of agents who failed. It is a procedural diagnosis: where the workflow allows takeover, what changes close the gap, and how to verify the fix.
Email: collaboration@zerotak.com