ShinyHunters Hit a Cybersecurity Company. A Phone Call Was Enough

• The Mess: Cybersecurity firm ReliaQuest confirmed that it was targeted in a social engineering attack linked to ShinyHunters. The attackers impersonated members of the company’s security team, called employees, sent one of them to a fake SSO page, and got the victim to approve an MFA push notification.

Yes.

A cybersecurity company.

Tracking the attackers.

Warning about their phishing campaign.

Then getting targeted by the same playbook.

The attack itself did not require a zero-day.

No kernel exploit.

No heap overflow.

No RCE chain.

Just a convincing phone call.

According to ReliaQuest’s account, the attackers registered a lookalike domain and created a fake single sign-on page. They then called multiple employees while impersonating a named member of the ReliaQuest security team.

One employee entered their password.

Then approved the MFA push.

That was enough to give the attackers a temporary authenticated session on the company’s identity dashboard.

The good news is that the attackers apparently hit a wall after that.

ReliaQuest says the session only provided view-only access. Attempts to reach other applications were blocked by device-trust and other access controls. The company says no additional identities, business applications, customer systems or customer data were accessed, and investigators found no persistence.

That makes this less of a catastrophic breach than the screenshots posted by the attackers initially suggested.

But it is still a pretty good demonstration of how modern identity attacks work.

The attacker doesn’t always need to break MFA.

Sometimes they just convince you to approve it.

• The Damage: ReliaQuest says customer data and internal applications were not compromised, but the incident shows how stolen credentials plus an approved MFA prompt can still hand attackers a real authenticated session.

And that distinction matters.

This wasn’t an attack stopped at the phishing email.

The victim’s password was entered.

The MFA request was approved.

The attacker got inside the identity layer.

The downstream controls stopped the pivot.

That is the difference between:

“MFA protected us.”

And:

“Other security controls saved us after MFA failed.”

ReliaQuest says the exposed identity was contained, credentials and tokens were reset, and no evidence of persistence or additional compromise was found. The company also rejected claims that it had suffered a ransomware attack or a broader systems compromise.

Still, there is an uncomfortable lesson here.

ShinyHunters didn’t need to discover a vulnerability.

They targeted the humans operating the security infrastructure.

And they apparently knew enough about the organization to impersonate real security personnel during the calls.

That makes the attack more convincing than a random:

“Hello, this is IT. Please click the link.”

The new phishing game increasingly involves phone calls, real names, lookalike domains and MFA fatigue.

Your employees aren’t just fighting bad links anymore.

They’re fighting actors who have done their homework.

• The Fix: Move critical accounts toward phishing-resistant authentication, enforce device and session trust, and train employees to independently verify unexpected security calls instead of approving MFA prompts because someone on the phone sounds convincing.

For defenders, this incident is also a reminder to review what happens after authentication.

Ask a simple question:

If an attacker gets one legitimate employee session, what can they actually reach?

Can they access applications?

Can they reset credentials?

Can they enroll another MFA device?

Can they create persistence?

Can they move into customer environments?

ReliaQuest’s downstream controls appear to have stopped that escalation.

That part of the architecture did its job.

Bugstoday Opinion

This story is better than another CVE.

No patch fixes this one.

No version number saves you.

A cybersecurity company was actively tracking a phishing campaign.

Then someone from the same campaign called its employees.

One person entered a password.

One person approved a push notification.

And suddenly the attacker had a real session.

The interesting part is that the attack didn’t completely succeed. The controls after authentication contained it.

That might be the biggest lesson here.

MFA is not a magical force field.

If an attacker can talk a user into handing over the password and approving the second factor, you need other layers ready to catch the fall.

Bugstoday verdict: sometimes the exploit isn’t in your software. Sometimes it calls you, knows your colleague’s name, and politely asks you to approve the notification.