2026-08-24 · view entry permalink →
An MDR vendor denies a circulating compromise claim and publishes what actually happened: a phone-call phishing attempt that got one MFA push approved, and a device-trust policy that made the resulting session useless
ReliaQuest published an account of a security incident on 2026-08-23 (ReliaQuest, 2026-08-23). It describes a social-engineering attempt against the company, sets out what its investigation found, and then states flatly that "Claims that ReliaQuest was compromised or targeted by ransomware are false" — so something to that effect was evidently circulating. The article never describes that claim: not where it came from, what it asserted, or what it offered as proof. Neither does this entry. What it does describe is the attempt, and the interesting part is where that attempt stopped.
Per that account, on 22 August 2026 an attacker registered a lookalike domain, stood up a counterfeit single-sign-on page fronted by a content delivery network, and then cold-called multiple ReliaQuest employees, each time impersonating a named member of ReliaQuest's own security staff, to steer the target toward the fake page. "One teammate entered their password and approved the push notification on their phone," which handed the attacker a session on the identity dashboard. "The extent of the access was view only." ReliaQuest states the attacker then made further attempts to move from that dashboard into business applications and was consistently denied by security controls — specifically a device-trust policy that blocks any device the organisation does not manage from reaching applications or systems, regardless of a successful identity-provider sign-in. Containment terminated the session, expired the compromised password and reset every authentication factor on the account. Its investigation — described as a complete audit of control fidelity, device trust, on-network access and any suspicious subsequent activity in the preceding 48 hours, so a lookback window rather than a statement about how long the work took — found no other identities accessed, no business applications reached, no customer or company data reached beyond that one user's login credentials, and no persistence established.
ReliaQuest then places the episode in a wider pattern rather than claiming novelty for it, and the distinction matters for what a reader should take as observed: the playbook it says this is consistent with across the industry runs an impersonation call, a throwaway lookalike domain registered and burned within the hour, a harvesting page behind a content delivery network, MFA push abuse, and a rapid attempt to enrol a new authenticator. The authenticator-enrolment step is named there, as part of the pattern — the article does not record it as a step the attacker took in this case, and it should not be read as one.
Triage: the high-fidelity signal in identity-provider audit logs is a sequence, not an event: a successful primary authentication and MFA-push approval, followed within the same session by repeated application-access denials keyed to device compliance or device trust. Authentication succeeding while every downstream authorisation fails on device state is a far better phishing indicator than the sign-in alone, because a legitimate user on a managed device does not generate it — and it is a pattern worth building a rule on precisely because it fires on the successful phish rather than on the attempt. Because the harvesting domain in this case was registered and burned inside an hour, domain-age and reputation signals are unlikely to be the thing that catches the next one; the identity-side sequence is.
Claims that ReliaQuest was compromised or targeted by ransomware are false.
One teammate entered their password and approved the push notification on their phone.
The extent of the access was view only.