On August 23, ReliaQuest published a blog post explaining that one employee had fallen for a social engineering attack two days earlier, handed over a password and an MFA approval to a lookalike login page, and that the resulting access was limited to a single, view-only identity dashboard session. “No ReliaQuest applications or systems were accessed, and no customer data was ever touched,” the company wrote. Hours later, the extortion group ShinyHunters posted screenshots it says show access to a ReliaQuest Okta account, taunting the company: “This time the post is about you, not us.” I think the more interesting story here is not who is right. It is that we, as an industry, still treat a vendor’s own account of its breach as the finish line rather than the opening bid.
The case for taking ReliaQuest at its word
The strongest argument against what I am about to say is a fair one: ReliaQuest is, of all companies, exactly the kind of security operations vendor that should be believed when it says its containment worked. It published a same-week, detailed account of the incident, including the attack mechanism (a lookalike domain, a fake SSO page, phone-based impersonation of security staff) and specifically what the compromised session could and could not reach. That is more transparency than most breached companies offer, and demanding endless proof from a company that has already disclosed more than most sets a standard nobody can meet. A defender-first publication should not punish disclosure by treating it as automatically suspect.
Why that is not enough here
But “we investigated ourselves and found nothing beyond what we already said” is a self-report, not independent verification, and the two are not the same thing even when the self-report is detailed and fast. ShinyHunters is a self-interested party too, with every incentive to inflate its access for leverage. Neither account, on its own, is evidence a security leader can act on. What ReliaQuest’s post does not include is any third-party confirmation: no named external forensics firm, no reference to law enforcement engagement, no indicator-of-compromise sharing that would let another organization check its own environment against the same infrastructure. For a company whose entire business is telling other people whether they have been compromised, that gap is the story.
Media Partner
This is not unique to ReliaQuest. It is the default pattern across the industry: an incident happens, the affected company writes its own narrative, and unless a regulator, an independent researcher, or the attacker themselves contradicts it with something checkable, that narrative becomes the record. Security leaders read dozens of these posts a year and, absent the time to interrogate each one, tend to accept the version published by the party with the least incentive to admit a worse outcome. It is the same gap this publication has raised before: containing a breach is not the same as disclosing it, and a fast, confident post is not proof either job was done well.
What it means for the security leader
The practical risk is not that ReliaQuest is lying. It may well be telling the exact truth. The risk is that “the vendor said so” becomes a substitute for verification in your own vendor risk process, especially for a vendor whose access into your environment, in ReliaQuest’s case, threat detection and response tooling, is itself sensitive. When a security vendor discloses an identity compromise, the right response is not to accept or dismiss the claim. It is to ask what evidence beyond the company’s own word exists, and to treat the absence of that evidence as a gap to track, not a question already answered.
What should change
Disclosure posts like ReliaQuest’s should be judged by whether they invite verification, the same standard this publication applied when arguing that patch speed alone cannot tell you who got in first, not just by how fast or detailed they are. That means naming the external firm that reviewed the incident, if one exists, sharing indicators of compromise so peers can check their own logs, and being explicit about what could not be ruled out rather than only what was ruled out. Until that becomes the norm, “we found nothing more” from the breached party and “we found more” from the extortionist will keep landing in the same place: an unresolved dispute that every reader has to guess at, at the exact moment a shared, checkable set of facts would matter most.
Source: ReliaQuest, “Threat Spotlight: Social Engineering Attempt Against ReliaQuest, What We Found”
