We started with a phone call, the opening move of a vishing attack. Turns out their security verification was a surname and an email address. That’s it.
We stayed in overnight. Over 15 hours.
The MSP never raised a single alert.
This is what a vishing attack looks like when the weakest link isn’t your staff: it’s the company you outsourced security to.
There was no elaborate hack here. We walked in through the front door.
Then we stayed there. Overnight. Completely undetected.
The client had outsourced their IT security to a managed service provider. The MSP had processes, verification procedures, and all the boxes ticked for compliance. On paper, everything looked secure.
In reality? We bypassed their entire security model with two phone calls and publicly available information. That’s vendor risk in practice: contracts and checklists, but no one watching the door.
The vishing attack begins
It started with a call to a small client site chosen deliberately for the test. No technical jargon. No probing questions. Just a friendly voice asking about IT support.
“Who handles your tech issues?”
The answer came without hesitation. The name of their MSP, handed over like we were asking for the weather forecast.
We made a follow-up call, this time to the MSP’s service desk. Armed with the client’s name and a bit of pretexting, we sounded instantly legitimate. Now came the critical question:
“What do you normally verify for password resets?”
The answer was almost comical in its simplicity: just an email address.
Our operator even suggested they might need an employee number. Turns out that was unnecessary optimism. No employee numbers, no manager names, no security questions.
Verification theatre
The credential-reset call was the second half of the same vishing attack, and it was textbook simple.
“Hi, I need to reset my password. I’m locked out.”
Verification consisted of a surname and which site they worked at. Both about as secret as the weather.
The service desk approved the password reset without hesitation.
Then came the MFA prompt. Worse, the MFA bypass took even less effort than the reset. Time for the classic pretext:
“Silly me, gave my phone to my son for uni and now need a new one added.”
The service desk added the new MFA device straight away. No callbacks, no alerts to the real employee, no awkward questions.
They granted full access.
At this point, most penetration tests would wrap up with a report and a pat on the back. Job done. Vulnerability proven.
We were just getting started.
The ghost in the inbox
With client permission, we began enumerating. Emails. Files. SharePoint.
And then we found them: pages of clear-text passwords sitting quietly in SharePoint. Credentials for systems, applications, third-party tools. All stored in plain text, like a shopping list.
We documented everything and informed the client that access was still active.
On top of which, the MSP never even opened a ticket. No alerts. No detection. Nobody looked into it.
Fast forward to 08:00 the next morning, and we were still in.
Turns out the employee had noticed their email wasn’t working the night before. They’d tried logging in a few times, failed, and then made a decision that would make any attacker smile: “I’ll deal with it tomorrow.”
Tomorrow problem. Attacker’s favourite time window.
By the time we prompted the client to close our access, we’d been inside for over 15 hours. A full overnight of undetected compromise.
The awkward truth
The big takeaway here isn’t how clever the vishing attack was. It wasn’t.
This is what social engineering testing looks like when the simplest approach works. We didn’t exploit a zero-day, crack encryption, or run a sophisticated script.
We made two phone calls and asked nicely.
The consequence is what happened after. We changed the credentials and MFA. That broke the employee’s access.
Nobody was alerted, escalated, or even mildly concerned. This means the entire detection chain failed at every link, not just one.
Think about that for a moment. An employee’s password was reset. Their MFA device was changed. Their email stopped working. And for over 15 hours, nobody in the security chain noticed, investigated, or raised a flag.
When your MSP verifies identity with publicly available information, adds new MFA devices without callbacks, and fails to detect suspicious credential changes, you don’t have a security provider. You have a liability wearing a compliance badge.
The reckoning
The client’s response was immediate and decisive.
They now audit their MSP’s verification procedures quarterly. Every credential reset requires multi-factor confirmation. MFA device changes trigger mandatory security alerts sent to both the employee and their manager. The client now monitors access anomalies in real time, not a day later.
As their Head of IT put it:
“We thought outsourcing security meant we were covered. This test proved we were just outsourcing risk. Now we verify our verifiers.”
The truth is uncomfortable but necessary: your security is only as strong as your weakest link. And if that link is a third party who can’t detect a compromised account for 24 hours, you’re not secure. You’re just lucky.
Real attackers don’t send a courtesy email when they’re done. Given this level of access, they could just as easily have stayed for months, exfiltrated data, or pivoted to other targets on the network.
We walked in through the front door because it was unlocked. And nobody noticed we were there until we told them.
Traditional penetration testing stops at the initial compromise. CovertSwarm’s Constant Cyber Attack™ shows you what happens when vulnerabilities are exploited, how long you stay compromised, and, most importantly, whether anyone notices.
Because the scariest part of this story isn’t that we got in.
It’s that we stayed there for a day and nobody cared.
How long would your MSP take to notice?
If your provider verifies identity with information anyone could find, and adds MFA devices without a callback, you already know the answer.
Unleash the Swarm and find out exactly how long you’d stay exposed before anyone noticed.