Skip to content
← Newsroom
CybersecurityNorth America

ReliaQuest says voice phishing reached an identity dashboard before device-trust checks blocked access

A phone call, a lookalike domain and an approved MFA push got attackers a foothold, and a second identity gate is what stopped them.

Square 1 AI Newsroom5 min read

Cybersecurity company ReliaQuest confirmed on 24 August 2026 that one of its employees was targeted in a social engineering attack in which callers impersonated members of its own security team, BleepingComputer reported. The attackers phoned multiple employees, posing as security staff and in at least one case impersonating a real security employee, and directed recipients to a fake single sign-on page hosted on a lookalike domain, reliaquest.claims, placed behind a content delivery network.

One employee entered credentials on the fake page and then approved a multi-factor authentication notification. That gave the attackers temporary, view-only access to the company's identity dashboard. In the company's account, the sequence was a password, then a push approval, then a limited session that the device check would not allow to go any further. According to ReliaQuest, device-trust controls blocked subsequent attempts to reach applications, and the company stated that no ReliaQuest applications or systems were accessed and no customer data was touched.

The extortion group ShinyHunters claimed responsibility on its leak site and published screenshots that appear to show compromised Okta single sign-on access. The group's own statement described the access as view-only and acknowledged that it did not reach applications, systems or data. BleepingComputer noted that ReliaQuest's threat research team had earlier warned about ShinyHunters using domains on the .claims top-level domain, and that the group responded with the screenshots from this incident.

The company said it had investigated and confirmed the findings above. According to the report, the attackers' use of a .claims domain matched infrastructure that ReliaQuest's own researchers had already described publicly. The report did not give a timeline for the calls or say how many employees were contacted.

Why it matters

Attackers are increasingly bypassing technical controls by targeting people with phone calls that sound routine, and security vendors are not exempt. This case shows that a stolen password plus an approved push notification is enough to get a foothold when MFA relies on a method that can be phished. It also shows that a second gate based on device identity can stop the chain even after the first gate fails. Expect identity providers and enterprises to keep moving toward phishing-resistant authentication and device posture checks as the default.

Attackers are increasingly bypassing technical controls by targeting people with phone calls that sound routine, and security vendors are not exempt.

How the ReliaQuest attack chain unfolded
  1. Phone call posing as security staff

    Attackers called several employees, impersonating a real member of the security team

  2. Lookalike SSO page

    Targets were sent to a fake single sign-on page on reliaquest.claims, hosted behind a CDN

  3. Credentials entered, MFA push approved

    One employee signed in on the fake page and accepted the resulting authentication prompt

  4. View-only access to identity dashboard

    Attackers gained temporary read access to the identity console

  5. Device trust blocks applications

    Attempts to open applications from an unmanaged device were refused; no systems or customer data reached

What you can learn from this

  • Voice phishing exploits authority and routine. A caller who claims to be from the security team and references a plausible internal process is asking the target to do something that feels normal, such as re-authenticating. People defer to authority and prefer to resolve an urgent request quickly, which is exactly what the attacker wants. Training that focuses only on spotting bad links misses this channel entirely. The defence is a procedure rather than intuition: any unsolicited request to authenticate should be verified through a separate, known channel.
  • Push-based MFA can be phished. Codes typed into a page or push prompts approved on a phone prove that the user holds the second factor, but they do not prove that the user is on the legitimate site. An attacker who captures the password on a fake page can trigger the real login and wait for the victim to approve the resulting push. Phishing-resistant methods such as FIDO2 security keys and passkeys solve this by binding the credential to the real site's origin, so a lookalike domain cannot complete the handshake. That is why the industry is shifting toward them for privileged access.
  • Lookalike domains and unfamiliar TLDs. Attackers register domains that combine a real company name with an unusual top-level domain, because most people only check the part of the address they recognise. Placing the page behind a content delivery network gives it a valid certificate and fast loading, which removes the visual cues that once betrayed a fake page. Monitoring newly registered domains that contain your organisation's name is a low-cost early warning. Blocking authentication from unknown origins at the identity provider is the stronger control.
  • Device trust as a second gate. Device-trust or conditional-access policies require that a login come from a managed, compliant device before applications are released, regardless of whether the password and MFA were correct. Because the attacker's machine was not enrolled, the identity provider granted only the dashboard view and refused application access. This is defence in depth applied to identity: each layer assumes the previous one may have failed. It works because device identity is established cryptographically, not by anything the user can be tricked into typing.
  • Understand what an identity dashboard exposes. Even view-only access to an identity console can reveal user lists, group memberships, application inventories and policy settings that help plan a later attack. Treat read access to administrative surfaces as a security event rather than a near miss. Logging and alerting on new sessions to these consoles is as important as protecting the applications behind them.

We teach this

How to use this in practice

  • Inventory your own MFA methods. List every account you hold that matters, note which second factor each uses, and move any that offer passkeys or hardware security keys to those methods this week. Where only push MFA is available, turn on number matching if the provider supports it. Start with email, because password resets for everything else flow through it. Done looks like a table with each account, its current method, and a date for the change.
  • Review sign-in logs for unknown devices. Open the security or activity page of your primary identity provider, whether that is a console you administer or a personal Google or Microsoft account, and look at the last 30 days of sessions. Identify any device, location or browser you cannot explain and revoke it. Turn on login alerts while you are there so the next unknown session notifies you. Done looks like a session list where you can account for every entry.
  • Enumerate lookalike domains. Write a short script that takes a domain name and generates variants across a list of top-level domains, including .claims, .support, .help and .login, then checks whether each resolves. Run it against a domain you own or a project name you use. Add the variants you find to a blocklist or watchlist in your DNS filter or browser. Done looks like a list of registered variants with a note on whether each one is yours.
  • Write a callback rule. Draft a five-line procedure for what you will do when someone phones claiming to be from IT or security: hang up, look up the official number independently, call back, and never enter credentials on a page reached from a call. Add the official IT or support number to your phone contacts so the lookup step takes seconds, and practise the rule once by having a colleague make the call. Done looks like a card you can read aloud in under thirty seconds.

Sources

Our reporting is an original summary; full coverage is at the links above.

Don't just read about it — build it.

Square 1 teaches the skills behind the headlines, with every line of your work graded by AI. Find your starting point in 3 minutes.

Get your free skill report

More in Cybersecurity