When ShinyHunters used vishing attacks to compromise multiple McKesson employees and access 284 million data records from Snowflake and Salesforce environments, the healthcare giant learned a hard lesson: your assumptions about social engineering defense are probably wrong.
These myths persist because they're comforting. They let you believe that basic awareness training, email filters, and MFA solve the problem. But when a threat actor registers a domain like mckesson[.]claims to impersonate your help desk and your employees hand over Okta credentials, those assumptions become liabilities.
Let's examine what you're getting wrong about social engineering defense, and what actually works.
Myth 1: MFA Prevents Credential Compromise
The Reality: MFA protects against password theft, not against employees who voluntarily provide their credentials to a convincing voice on the phone.
When ShinyHunters targeted McKesson, they didn't try to crack passwords or exploit authentication vulnerabilities. They called employees, impersonated IT support, and convinced them to share their single sign-on credentials. The employees likely entered those credentials into a phishing site that captured both username and MFA token in real time.
Your MFA implementation probably stops automated attacks. It doesn't stop a human attacker on the phone walking an employee through "verifying" their identity by logging into a fake portal. The threat actor gets the credentials and the active session token simultaneously.
What works instead: Implement phishing-resistant MFA using FIDO2 hardware tokens or certificate-based authentication. These methods don't rely on codes that can be read over the phone or entered into fake login pages. Also, establish a policy that no legitimate IT request will ever ask employees to provide credentials or MFA codes, and reinforce this policy repeatedly.
Myth 2: Third-Party Applications Are Someone Else's Problem
The Reality: Your third-party SaaS platforms are exactly where attackers go once they compromise credentials, because that's where your sensitive data lives.
McKesson's breach involved unauthorized access to third-party applications, specifically Salesforce and Snowflake. These weren't peripheral systems. They contained patient records, support cases, internal communications, and operational data. Once ShinyHunters had valid Okta credentials, they walked straight into these environments with legitimate access.
Your vendor contracts probably include security commitments. Your vendor questionnaires probably ask about encryption and access controls. But those documents don't prevent an attacker from using your own employees' credentials to access those platforms as an authorized user.
What works instead: Treat third-party application access as part of your identity and access management program. Implement conditional access policies that restrict which devices and locations can access sensitive SaaS platforms. Monitor for unusual access patterns, like credential use from unexpected geographic locations or access to applications an employee doesn't normally use. For critical systems like your CRM or data warehouse, require separate authentication that can't be compromised through a single vishing call.
Myth 3: Annual Security Awareness Training Covers Social Engineering
The Reality: A yearly compliance exercise doesn't prepare employees to recognize sophisticated vishing attacks that impersonate your actual help desk using domains that look legitimate.
The threat actors in the McKesson incident used the .claims TLD to create domains incorporating targeted companies' names. When an employee receives a call from someone claiming to be from IT support and sees an email from a domain that includes their company name, annual training from eight months ago doesn't help.
Your training program probably covers phishing emails with obvious red flags: misspellings, urgent threats, suspicious links. It probably doesn't cover voice calls from calm, professional-sounding attackers who know internal terminology, reference real systems, and direct employees to domains that look plausible.
What works instead: Run regular, unannounced vishing simulations that mirror real attack tactics. When employees fail, provide immediate coaching, not just a reminder about the training module. Establish clear verification procedures: if someone calls claiming to be from IT and asks for any action involving credentials or access, the employee should hang up and call IT directly using a known, verified number. Make this procedure part of onboarding, not just annual training.
Myth 4: You'll Detect the Breach Quickly
The Reality: ShinyHunters exfiltrated approximately 1TB of data over four days before McKesson discovered the incident on August 25, 2026.
Your security tools probably generate alerts. Your SIEM probably has rules for unusual data access. But when an attacker is using valid credentials and accessing systems the employee is authorized to use, those tools see normal activity. The threat actor isn't exploiting a vulnerability or triggering an intrusion detection signature. They're logging in as a legitimate user and downloading data they have permission to access.
What works instead: Implement user and entity behavior analytics (UEBA) that baseline normal access patterns for each employee and flag deviations. If an employee who normally accesses five Salesforce records per day suddenly downloads thousands, that's a signal. If a credential typically used during business hours in New York starts accessing Snowflake at 3 AM from a different region, that's a signal. Configure data loss prevention (DLP) tools to monitor for bulk downloads from sensitive SaaS platforms, and set thresholds that trigger immediate investigation, not just logging.
Myth 5: Cyber Insurance Will Handle the Financial Impact
The Reality: Your Stand-Alone Cyber Policy probably has coverage for breach response costs, but social engineering incidents often trigger questions about whether you met your Pre-Bind Requirements around employee training and access controls.
When you completed your Underwriting Questionnaire, you likely represented that you provide security awareness training and implement MFA. If a vishing attack succeeds and your insurer discovers that your training program consisted of an annual video with no vishing simulation or that your MFA implementation allowed real-time phishing, you may face questions about whether your security controls matched your representations.
Your policy's Breach Notification Requirement also means you'll need to notify potentially affected individuals. With 284 million data records stolen from McKesson, even determining how many unique individuals were affected becomes a complex forensic exercise. Your policy may cover notification costs, but the reputational damage and regulatory scrutiny aren't insurable.
What works instead: Document your security awareness program, including vishing simulations and failure rates. Maintain records showing continuous improvement. Implement the phishing-resistant MFA methods that insurers increasingly expect during Cyber Maturity Assessments. When you renew your policy, accurately represent your controls. If you haven't implemented vishing simulations, don't claim comprehensive social engineering defense. The coverage you actually get depends on honest representations.
What to Do Instead
Stop treating social engineering as an awareness problem. It's an access control and monitoring problem.
Implement technical controls that make credential compromise harder: phishing-resistant MFA, conditional access policies, and behavioral analytics. Establish verification procedures that employees can't bypass: no credentials over the phone, ever. Run realistic simulations that mirror actual attack tactics, not just obvious phishing emails.
Review your third-party application access. Which SaaS platforms contain your most sensitive data? What additional authentication or access restrictions do they require? How quickly would you detect unusual access patterns?
Most importantly, test your assumptions. Run a tabletop exercise where attackers compromise employee credentials through vishing. Walk through what they could access, how long it would take you to detect it, and what your response would look like. If the answer makes you uncomfortable, you've identified where to focus your effort.
The myths persist because they're easier than admitting that a convincing phone call can bypass your entire security stack. But admitting the problem is the first step toward actually solving it.
