Incidentul McKesson: aplicații terțe, exfiltrare și afirmații despre vishing

McKesson Corporation a comunicat la 28 august 2026 că investighează un incident de securitate cibernetică descoperit la 25 august. În documentul depus la SEC, compania spune că incidentul i-a afectat sistemele informatice și că investigația este într-o fază timpurie. În informarea pentru clienți, McKesson precizează că sunt implicate aplicații terțe, acces neautorizat și exfiltrare de date.

Ce a confirmat McKesson

• Compania a descoperit incidentul la 25 august și a activat procedurile de răspuns, o investigație și sprijinul unor specialiști externi.
• Informarea oficială descrie aplicații terțe, acces neautorizat și exfiltrare de date, fără să identifice aplicațiile sau categoriile de informații.
• McKesson a raportat că unii clienți puteau observa degradări intermitente ale serviciilor considerate posibil legate de incident.
• La data raportării, compania nu stabilise că incidentul este material sau că are ori este probabil să aibă un impact material asupra situației financiare sau rezultatelor operaționale.
• Investigația era încă în curs, iar compania nu recomanda atunci clienților o acțiune specifică și nu deconecta preventiv sistemele din mediul său.

Ce afirmă ShinyHunters și de ce cifra de 284 de milioane poate induce în eroare

ShinyHunters a declarat pentru BleepingComputer că ar fi folosit apeluri de vishing împotriva mai multor angajați, ar fi compromis conturi Okta SSO și ar fi accesat Salesforce și Snowflake. Gruparea susține că ar fi extras aproximativ un terabyte de date în patru zile și că setul ar conține circa 284 de milioane de rânduri cu informații asociate pacienților.

Un rând de bază de date nu este o persoană. Același individ poate avea mai multe înregistrări pentru programări, rețete, livrări sau alte operațiuni. Chiar ShinyHunters a precizat publicației că nu cunoaște numărul persoanelor unice. Până la rezultatul investigației și notificările oficiale, nu există o bază pentru formularea „284 de milioane de pacienți afectați”.

De ce scenariul de vishing merită exersat chiar dacă atribuirea nu este confirmată

Health-ISAC avertizase încă din 24 iulie asupra unui tipar repetabil în sectorul medical: vishing, resetare de parolă sau MFA ori înrolarea unui dispozitiv, preluarea unui cont SSO, accesarea aplicațiilor SaaS conectate și exfiltrarea rapidă pentru extorcare. Buletinul tratează unele detalii din incidente ca afirmații ale actorului, dar recomandă ruperea lanțului prin verificare independentă, autentificare rezistentă la phishing, controlul aplicațiilor și vizibilitate asupra sesiunilor și descărcărilor.

Deciziile necesare, împărțite pe roluri

• Utilizatorul întrerupe apelul și contactează help desk-ul prin portalul sau numărul cunoscut. Faptul că apelantul știe numele, managerul sau aplicațiile folosite nu îi confirmă identitatea.
• Help desk-ul aplică regula fără resetare în același apel: creează ticket, sună la un număr verificat anterior și cere aprobare suplimentară pentru conturile cu risc ridicat.
• Echipa de identitate verifică resetări MFA, înrolări de dispozitive, sesiuni active și factori noi; la suspiciune revocă sesiunile și tokenurile, nu doar schimbă parola.
• Ownerii SaaS inventariază aplicațiile terțe și granturile OAuth, reduc permisiunile, aprobă explicit accesul sensibil și păstrează loguri pentru exporturi și apeluri API neobișnuite.
• SOC-ul corelează identitatea cu activitatea din aplicațiile cloud: autentificări, device enrollment, consimțământ OAuth, descărcări masive și acces la colecții neobișnuite.
• Privacy și legal stabilesc ce date putea vedea fiecare identitate sau integrare și nu deduc numărul persoanelor din numărul rândurilor ori fișierelor.
• Comunicarea separă incidentul confirmat, impactul încă investigat și afirmațiile atacatorului, indicând data următoarei actualizări.

Tabletop: falsul help desk deschide accesul către mai multe aplicații

Exercițiul trebuie să includă utilizatori, help desk, identity, owneri SaaS, SOC, privacy, legal și management. Nu dezvălui tot lanțul de la început; fiecare inject trebuie să producă o decizie, un owner și o dovadă.

• Inject 1 — un apelant care cunoaște numele managerului spune că repară o problemă urgentă de SSO și cere deschiderea unei pagini. Ce verifică angajatul?
• Inject 2 — apelantul cere help desk-ului reînrolarea MFA pentru un executiv aflat în călătorie. Ce regulă împiedică rezolvarea în același apel?
• Inject 3 — autentificarea pare legitimă, dar apare un dispozitiv nou și un grant OAuth. Cine revocă sesiunea și cine dezactivează aplicația?
• Inject 4 — Salesforce arată exporturi mari, iar alt serviciu cloud indică interogări neobișnuite. Cine stabilește perioada și aria investigației?
• Inject 5 — atacatorul publică o cifră foarte mare de rânduri. Cine validează persoanele distincte și categoriile reale înainte de notificare?
• Inject 6 — serviciile au degradări intermitente, dar investigația nu a stabilit impact material. Ce comunici clienților și când revii cu o actualizare?

Cum măsori dacă exercițiul a redus riscul

• Procentul angajaților care închid apelul și folosesc canalul oficial fără să urmeze instrucțiunile apelantului.
• Procentul resetărilor MFA și al înrolărilor de dispozitive care includ callback verificat, ticket și aprobarea cerută de risc.
• Timpul până la revocarea tuturor sesiunilor și tokenurilor după confirmarea unui cont suspect.
• Timpul până la identificarea aplicațiilor, datelor și granturilor accesibile identității compromise.
• Acoperirea logurilor pentru SSO, aplicații SaaS, OAuth, exporturi și API-uri în perioada necesară investigației.
• Procentul comunicărilor care etichetează separat faptele confirmate, relatările independente, afirmațiile atacatorului și necunoscutele.

Ce rămâne necunoscut

McKesson nu a publicat aplicațiile afectate, mecanismul de acces inițial, categoriile de date exfiltrate sau numărul persoanelor. Nu este confirmat public că Okta, Salesforce ori Snowflake au fost implicate și nu este verificat volumul revendicat de ShinyHunters. Evaluarea materialității se poate schimba pe măsură ce investigația avansează.

Cum transformi cazul într-un modul Learning Awarely

Un modul eficient testează conversația și presiunea, nu doar un e-mail. Utilizatorul exersează refuzul și callbackul, help desk-ul aplică fluxul de verificare, identity revocă sesiuni și factori, iar managementul comunică fără să transforme o revendicare într-un fapt. Scenariile pot fi atribuite pe roluri și repetate până când pașii critici devin măsurabili.

Learning Awarely poate livra exercițiile, evalua răspunsurile și păstra evidențe de finalizare și recertificare. Platforma nu administrează SSO-ul clientului, nu revocă sesiuni și nu inspectează aplicațiile SaaS; măsurile tehnice rămân responsabilitatea echipelor și sistemelor autorizate ale organizației.