ReliaQuest/ShinyHunters. Let’s have a chat about this. Here’s what you need to know.
The attacker reportedly got the password and the MFA approval, and still couldn’t get where they wanted to go. MFA shouldn’t be the finish line for identity security. And device trust and conditional access can contain an attack even after an attacker gets through the front door.
The company put up a blog post here: https://reliaquest.com/blog/threat-spotlight-social-engineering-attempt-against-reliaquest-what-we-found/
Kevin Surace, CEO, Token (https://www.linkedin.com/in/ksurace)
“The ReliaQuest incident is a perfect example of why MFA can no longer be treated as proof of identity. The attacker reportedly obtained valid credentials and convinced the employee to approve the MFA request. At that point, the authentication system had effectively accepted the attacker as the employee. ReliaQuest’s additional device trust controls appear to have prevented that authenticated session from reaching critical applications, which is exactly why identity security has to extend beyond a password plus an approval prompt.
“The ultimate direction is dedicated hardware biometric assured identity. Instead of asking an employee to decide whether a push notification is legitimate, the system requires cryptographic proof from a registered physical authenticator, a biometric match from the authorized user, the correct application or domain, and ideally physical proximity to the device being accessed. There is no code to give away and no push notification to approve. Even if an attacker steals the password and completely fools the employee, they still cannot produce the required identity proof.
“That is where enterprise authentication is heading. Device trust is an excellent additional control, but dedicated biometric hardware moves the protection to the very beginning of the attack chain. Rather than detecting that the wrong device is being used after an attacker has already authenticated, biometric assured identity is designed to prevent the attacker from ever becoming an authenticated user in the first place. Attackers may steal credentials, call the help desk, or manipulate an employee, but without the authorized hardware and the authorized person, there is no entry.”
Noelle Murata, Chief Operating Officer, Xcape, Inc. (https://www.linkedin.com/in/nmurata)
“A compromised set of credentials or an approved multi-factor authentication (MFA) push does not have to result in a catastrophic breach when identity architectures enforce strict post-authentication boundaries. The bad news is that a user made a poor decision to approve the MFA push request; the good news is that the organization’s defense-in-depth posture worked as designed and prevented further unauthorized access. When threat actors bypass initial login protections to access an identity dashboard, downstream conditional access policies act as the true containment boundary. Single technical controls will eventually fail, making post-authentication conditional access essential for effective breach containment. Valid user credentials paired with approved MFA push requests should never grant unvetted access to downstream enterprise applications without device trust verification. Defense-in-depth strategies succeed when security architectures automatically isolate non-compliant or untrusted endpoints from core operational assets. This incident is a testament to how defenders can remain successful in preventing attacks if they assume that any single technical control can be bypassed. Security leaders must mandate managed device certificate validation, require hardware-bound security keys, and automatically isolate untrusted endpoints from core enterprise applications.
“Relying solely on human judgment for authentication is a strategy destined to fail, which is why real defense-in-depth ensures that failure stays contained.”
Jacob Krell, Sr. Director: Secure AI & Cybersecurity, Suzu Labs (https://www.linkedin.com/in/jacob-krell)
“Social engineering stops working when it runs into a gate that doesn’t involve a human. ShinyHunters got a valid password and an approved Multi-Factor Authentication (MFA) push from a ReliaQuest employee, and it still wasn’t enough to reach a single application. The session landed in Okta, the identity dashboard loaded, and device-trust controls blocked every attempt to go further because the attacker’s device wasn’t enrolled.
“ShinyHunters has made a career out of valid-looking access. Legitimate API calls against misconfigured Salesforce deployments. Stolen credentials against Snowflake customers. A phished MFA session against ReliaQuest. The first two turned into data breaches. The third didn’t, because device trust doesn’t care how legitimate your session looks.
“MFA push approval is a human decision, and social engineering targets human decisions. An attacker calls, creates urgency, and the employee taps “approve.” Device trust removes the human from that chain entirely. Conditional access policies that verify managed device certificates, Mobile Device Management (MDM) enrollment, or endpoint compliance are machine-to-machine checks.
“You can talk someone into approving a push notification. You can’t talk a laptop into passing a device compliance check.
“I’ve seen this with clients running Microsoft Entra ID. Phishing attempts that cleared MFA stopped dead at the device gate because the attacker’s machine wasn’t enrolled in the organization’s MDM. The credentials were valid, the session was live, and nothing happened. ReliaQuest’s Okta setup produced the same result.
“Too many organizations treat conditional access as a phase-two project they’ll configure after their identity migration finishes. This incident shows why it should be phase one.”
Basically the takeaway from this incident is that companies need to look at non-MFA solutions like passwordless solutions. That way companies are better protected from hacks like this.
Related
This entry was posted on August 26, 2026 at 8:15 am and is filed under Commentary with tags Hacked. You can follow any responses to this entry through the RSS 2.0 feed.
You can leave a response, or trackback from your own site.
The attacker had the password + MFA approval. Here’s why they still couldn’t get in
ReliaQuest/ShinyHunters. Let’s have a chat about this. Here’s what you need to know.
The attacker reportedly got the password and the MFA approval, and still couldn’t get where they wanted to go. MFA shouldn’t be the finish line for identity security. And device trust and conditional access can contain an attack even after an attacker gets through the front door.
The company put up a blog post here: https://reliaquest.com/blog/threat-spotlight-social-engineering-attempt-against-reliaquest-what-we-found/
Kevin Surace, CEO, Token (https://www.linkedin.com/in/ksurace)
“The ReliaQuest incident is a perfect example of why MFA can no longer be treated as proof of identity. The attacker reportedly obtained valid credentials and convinced the employee to approve the MFA request. At that point, the authentication system had effectively accepted the attacker as the employee. ReliaQuest’s additional device trust controls appear to have prevented that authenticated session from reaching critical applications, which is exactly why identity security has to extend beyond a password plus an approval prompt.
“The ultimate direction is dedicated hardware biometric assured identity. Instead of asking an employee to decide whether a push notification is legitimate, the system requires cryptographic proof from a registered physical authenticator, a biometric match from the authorized user, the correct application or domain, and ideally physical proximity to the device being accessed. There is no code to give away and no push notification to approve. Even if an attacker steals the password and completely fools the employee, they still cannot produce the required identity proof.
“That is where enterprise authentication is heading. Device trust is an excellent additional control, but dedicated biometric hardware moves the protection to the very beginning of the attack chain. Rather than detecting that the wrong device is being used after an attacker has already authenticated, biometric assured identity is designed to prevent the attacker from ever becoming an authenticated user in the first place. Attackers may steal credentials, call the help desk, or manipulate an employee, but without the authorized hardware and the authorized person, there is no entry.”
Noelle Murata, Chief Operating Officer, Xcape, Inc. (https://www.linkedin.com/in/nmurata)
“A compromised set of credentials or an approved multi-factor authentication (MFA) push does not have to result in a catastrophic breach when identity architectures enforce strict post-authentication boundaries. The bad news is that a user made a poor decision to approve the MFA push request; the good news is that the organization’s defense-in-depth posture worked as designed and prevented further unauthorized access. When threat actors bypass initial login protections to access an identity dashboard, downstream conditional access policies act as the true containment boundary. Single technical controls will eventually fail, making post-authentication conditional access essential for effective breach containment. Valid user credentials paired with approved MFA push requests should never grant unvetted access to downstream enterprise applications without device trust verification. Defense-in-depth strategies succeed when security architectures automatically isolate non-compliant or untrusted endpoints from core operational assets. This incident is a testament to how defenders can remain successful in preventing attacks if they assume that any single technical control can be bypassed. Security leaders must mandate managed device certificate validation, require hardware-bound security keys, and automatically isolate untrusted endpoints from core enterprise applications.
“Relying solely on human judgment for authentication is a strategy destined to fail, which is why real defense-in-depth ensures that failure stays contained.”
Jacob Krell, Sr. Director: Secure AI & Cybersecurity, Suzu Labs (https://www.linkedin.com/in/jacob-krell)
“Social engineering stops working when it runs into a gate that doesn’t involve a human. ShinyHunters got a valid password and an approved Multi-Factor Authentication (MFA) push from a ReliaQuest employee, and it still wasn’t enough to reach a single application. The session landed in Okta, the identity dashboard loaded, and device-trust controls blocked every attempt to go further because the attacker’s device wasn’t enrolled.
“ShinyHunters has made a career out of valid-looking access. Legitimate API calls against misconfigured Salesforce deployments. Stolen credentials against Snowflake customers. A phished MFA session against ReliaQuest. The first two turned into data breaches. The third didn’t, because device trust doesn’t care how legitimate your session looks.
“MFA push approval is a human decision, and social engineering targets human decisions. An attacker calls, creates urgency, and the employee taps “approve.” Device trust removes the human from that chain entirely. Conditional access policies that verify managed device certificates, Mobile Device Management (MDM) enrollment, or endpoint compliance are machine-to-machine checks.
“You can talk someone into approving a push notification. You can’t talk a laptop into passing a device compliance check.
“I’ve seen this with clients running Microsoft Entra ID. Phishing attempts that cleared MFA stopped dead at the device gate because the attacker’s machine wasn’t enrolled in the organization’s MDM. The credentials were valid, the session was live, and nothing happened. ReliaQuest’s Okta setup produced the same result.
“Too many organizations treat conditional access as a phase-two project they’ll configure after their identity migration finishes. This incident shows why it should be phase one.”
Basically the takeaway from this incident is that companies need to look at non-MFA solutions like passwordless solutions. That way companies are better protected from hacks like this.
Share this:
Like this:
Related
This entry was posted on August 26, 2026 at 8:15 am and is filed under Commentary with tags Hacked. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.