The signals looked legitimate. The person was not verified.

Two recent investigations describe different attacks with the same trust failure: the employee saw something familiar, but had no independent proof that the person giving the instruction was authorized IT or security staff.

Two attacks borrowed legitimate-looking signals

ReliaQuest disclosed that it was targeted in a social-engineering attempt on August 22, 2026. According to the company's account, an attacker registered a lookalike domain, placed a counterfeit ReliaQuest single-sign-on page behind a content delivery network, and called several employees while impersonating a named member of the security team.

One employee entered a password and approved a genuine MFA push. That produced a brief, view-only session on ReliaQuest's identity dashboard. ReliaQuest says its device-trust controls denied subsequent attempts to reach applications, and that no customer data was accessed, no persistence was established, and no broader compromise was found.

Expel documented a separate attack that began inside Microsoft Teams. An account using an onmicrosoft.com address appeared as IT Service Desk and convinced the target to install an MSI presented as “PowerShell Cleaner.” The file came from Azure Blob Storage, giving the download a Microsoft-hosted appearance.

The installer delivered SynkLoader. Expel found modules for persistence, interactive PowerShell, remote desktop control, a fake Windows lock screen designed to capture the user's password, and a reverse proxy capable of routing activity through the infected computer. Expel encountered the loader after endpoint detection alerted on a scheduled task, then reverse-engineered its command-and-control protocol to observe additional tooling.

The payloads and outcomes were different. The social decision was the same: an employee was asked to trust a person because the surrounding systems looked familiar.

McKesson breach: data exfiltration confirmed, vishing claim unconfirmed

On August 29, McKesson confirmed unauthorized access to certain third-party applications and data exfiltration affecting a subset of customers in two business units. ShinyHunters separately claimed that voice phishing led to compromised Okta accounts; BleepingComputer reported the claim and a company-mimicking domain while noting that it had not independently verified the group's account. McKesson has not confirmed the initial-access method. For now, the McKesson breach is a developing example in this control discussion, not proof that vishing caused the incident.

A legitimate system does not authenticate the person

Microsoft Teams can establish where a message appeared. It does not establish that the sender is the target organization's helpdesk. An onmicrosoft.com address shows that an account belongs to a Microsoft 365 tenant, not that it belongs to the employee's authorized IT team.

Azure Blob Storage establishes where a file is hosted. It does not establish that the organization approved the software or that the person asking for its installation is authorized.

An MFA prompt establishes that an enrolled factor participated in an authentication event. It does not establish that the caller initiated a legitimate support request or that the employee should follow the caller's instruction.

These signals are useful inside their proper control boundaries. None of them answers the employee's immediate question: Is this person really IT?

Put controls before, during, and after the instruction

No single control covers the complete attack path. Organizations should combine:

• collaboration policy that limits or clearly identifies external Teams communication;
• managed software distribution, application control, endpoint detection, and response for caller-supplied tooling;
• phishing-resistant authentication, contextual prompts, device trust, and session policy appropriate to the application; and
• a known, organization-controlled way for employees to verify someone claiming to be IT or security before following a sensitive instruction.

ReliaQuest's account demonstrates why post-authentication policy matters: device trust constrained what an attacker could reach after an employee approved the prompt. Expel's investigation demonstrates why endpoint controls matter after an employee installs a malicious package.

Caller verification belongs earlier. It creates a decision point before the employee approves a prompt, installs a tool, grants remote access, or shares information.

Give employees a verification path they already know

The safe path cannot depend solely on a link, telephone number, domain, file, or code supplied by the person making the request. The employee should open an established company support or verification destination and confirm a current request associated with the purported IT representative.

With Fctr's two-way caller verification, an IT or support caller proves their identity through organization-managed evidence, and the employee receives the verification result before continuing the sensitive interaction. The same model works in the conventional direction when an employee calls the helpdesk.

Fctr does not classify Teams messages, inspect installers, determine whether an endpoint is trusted, or replace endpoint protection, conditional access, or incident response. It addresses the person-to-person trust decision that those systems do not answer.

The practical policy is broader than “do not click unexpected links”:

Before approving a prompt, installing a tool, or granting remote access, verify the person who asked.

Sources

• ReliaQuest Threat Research — A Social Engineering Attempt Against ReliaQuest: What We Found
• Expel Threat Research — SynkLoader: when you throw in everything but the kitchen sink
• McKesson — Customer Cybersecurity Information Center
• BleepingComputer — New SynkLoader malware pushed in Microsoft Teams phishing campaign