ReliaQuest social-engineering attempt (August 2026)

incident · incident:reliaquest-social-engineering-attempt-2026-08 single-source-victim

Social-engineering attempt against the managed-detection vendor ReliaQuest, disclosed in its own account of 2026-08-23, which describes the attempt, sets out its investigation findings, and then states that circulating claims it had been compromised or hit by ransomware are false. Per that account: a lookalike domain and counterfeit single-sign-on page behind a content delivery network, cold calls to multiple employees impersonating a named member of ReliaQuest's own security staff, one password entry and MFA-push approval yielding a view-only identity-dashboard session, and every onward application-access attempt denied by a device-trust policy requiring a managed device. ReliaQuest names no actor, and its article does not describe the claim it denies (ReliaQuest, 2026-08-23).

Coverage

first 2026-08-24 → last 2026-08-24

Latest activity

2026-08-24

ReliaQuest denies a compromise claim and documents a vishing call that got one MFA push approved…

Peak priority

notable

1 notable

Targets

technology

sectors: technology

Sources cited

1 hosts

Defender insights

What each entry about ReliaQuest social-engineering attempt (August 2026) tells a defender to do, newest first.

2026-08-24NOTABLEReliaQuest denies a compromise claim and documents a vishing call that got one MFA push approved; device-trust binding is what capped it

Defender takeaway

The transferable lesson is a control boundary, not a technique. Multi-factor authentication did not stop this (it was satisfied, by a real user approving a real push) and what did was treating a successful identity-provider sign-in as necessary but not sufficient, with a separate managed-device requirement in front of every business application. For a public-sector or critical-infrastructure identity estate that is a concrete question to put to its own configuration: after a valid sign-in from an unrecognised device, what is actually reachable? If the answer is "the application portfolio", then push-approval phishing is a full compromise rather than a contained one. The secondary lesson is about the phone as a channel: the impersonation was of a named internal security staff member, which is worth carrying into awareness content because it defeats the usual heuristic that internal support never calls out of the blue; this caller had done the homework to sound like a colleague.

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.

Story timeline

2026-08-24An 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
active-threatsReliaQuest denies a compromise claim and documents a vishing call that got one MFA push approved; device-trust binding is what capped it

Hunting pivots

Resource Development TA0042

T1583.001Acquire Infrastructure: Domains×1

Adversaries may acquire domains that can be used during targeting. Domain names are the human readable names used to represent one or more IP addresses. They can be purchased or, in some cases, acquired for free.

Evidence: 2026-08-24/reliaquest-vishing-mfa-push-device-trust-contained · ATT&CK page ↗

Initial Access TA0001

T1078.004Valid Accounts: Cloud Accounts×1

Valid accounts in cloud environments may allow adversaries to perform actions to achieve Initial Access, Persistence, Privilege Escalation, or Defense Evasion. Cloud accounts are those created and configured by an organization for use by users, remote support, services, or for administration of resources within a cloud service provider or SaaS application. Cloud Accounts can exist solely in the cloud; alternatively, they may be hybrid-joined between on-premises systems and the cloud through syncing or federation with other identity sources such as Windows Active Directory.

Evidence: 2026-08-24/reliaquest-vishing-mfa-push-device-trust-contained · ATT&CK page ↗

T1566.004Phishing: Spearphishing Voice×1

Adversaries may use voice communications to ultimately gain access to victim systems. Spearphishing voice is a specific variant of spearphishing. It is different from other forms of spearphishing in that it employs the use of manipulating a user into providing access to systems through a phone call or other forms of voice communications. Spearphishing frequently involves social engineering techniques, such as posing as a trusted source (ex: Impersonation) and/or creating a sense of urgency or alarm for the recipient.

Evidence: 2026-08-24/reliaquest-vishing-mfa-push-device-trust-contained · ATT&CK page ↗

Persistence TA0003

T1078.004Valid Accounts: Cloud Accounts×1

Evidence: 2026-08-24/reliaquest-vishing-mfa-push-device-trust-contained · ATT&CK page ↗

Privilege Escalation TA0004

T1078.004Valid Accounts: Cloud Accounts×1

Evidence: 2026-08-24/reliaquest-vishing-mfa-push-device-trust-contained · ATT&CK page ↗

Stealth TA0005

T1078.004Valid Accounts: Cloud Accounts×1

Evidence: 2026-08-24/reliaquest-vishing-mfa-push-device-trust-contained · ATT&CK page ↗

T1684.001Social Engineering: Impersonation×1

Adversaries may impersonate a trusted person or organization in order to persuade and trick a target into performing some action on their behalf. For example, adversaries may communicate with victims (via Phishing for Information, Phishing, or Internal Spearphishing) while impersonating a known sender such as an executive, colleague, or third-party vendor. Established trust can then be leveraged to accomplish an adversary’s ultimate goals, possibly against multiple victims.

Evidence: 2026-08-24/reliaquest-vishing-mfa-push-device-trust-contained · ATT&CK page ↗

Credential Access TA0006

T1621Multi-Factor Authentication Request Generation×1

Adversaries may attempt to bypass multi-factor authentication (MFA) mechanisms and gain access to accounts by generating MFA requests sent to users.

Evidence: 2026-08-24/reliaquest-vishing-mfa-push-device-trust-contained · ATT&CK page ↗

Entries about ReliaQuest social-engineering attempt (August 2026) (1)

2026-08-24 · view entry permalink →

NOTABLENATOB2

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.

Defender takeaway

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.

ReliaQuest 2026-08-23

incident24 Aug 09:17Zsingle-source · victim disclosureOpen finding →

Sources: ReliaQuest

explore in graph

Where this entity is cited

Threats1

Source distribution

reliaquest.com1 (100%)

All cited sources (1)

reliaquest.comReliaQuesthttps://reliaquest.com/blog/threat-spotlight-social-engineering-attempt-against-reliaquest-what-we-found
source profile · cited in 2026-08-24