Vous êtes dans : Accueil > Tribunes libres >

Anthem medical data breach : retour sur l’une des plus grosse fuite de données de santé

Charles Blanc-Rolin, MARDI 14 MAI 2019

   

anthem_data_leak

Jeudi 7 mai, le Ministère de la Justice américain a rendu publique un acte d’accusation [1] contre deux résidents Chinois, accusés de faire partie du groupe d’attaquants ayant réussi à dérober 78,8 millions de dossiers médicauxà l’assureur Anthem [2] et plusieurs de ses filiales.

Les deux suspects, Fujie Wang, connu également sous le pseudo « Dennis », ainsi qu’un autre membre de ce fameux groupe Chinois, dont le vrai nom n’est pas connu, mais opérant sous les pseudos, « John Doe », « Deniel Jack », « Kim Young » ou encore « Zhou Zhihong », auraient activement participé à l’intrusion dans le système d’information de l’Assureur Anthem, le maintien dans ce système et l’exfiltration de près de 79 millions de dossiers médicaux d’assurés sur une période allant de mai 2014 à janvier 2015. Ils sont accusés de complot en vue de commettre une fraude, de vol d’identité et de dégradations volontaires sur des systèmes d’informations.

Quelles leçons tirer de cette attaque ?

Les attaquants auraient mis en œuvre une campagne de phishing très ciblée, envoyant des messages contenant des liens vers des logiciels malveillants de type « cheval de Troie », permettant d’établir des liens persistants avec leurs serveurs de commandes et de contrôle dès lors que les victimes ont eu la mauvaise idée de « cliquer ».

→ Une fois de plus, la messagerie, reste une porte d’entrée privilégiée pour les attaquants, et le manque de sensibilisation des utilisateurs est toujours un point faible important. 

Après avoir pris le contrôle de quelques postes, ils ont réussi à se déplacer latéralement dans le réseau de l’assureur, ainsi que dans ceux de ses filiales. Puis réaliser des élévations de privilèges sur le SI afin d’accéder aux données. On peut donc imaginer, que des réseaux à plat sans cloisonnement ni filtrage avaient été mis en œuvre. Nous pouvons également supposer que la configuration de l’annuaire utilisateur Active Directory n’était pas optimale et que la politique de mot de passe était faible.

→ Le cloisonnement des réseaux est crucial. Un durcissement de la configuration Active Directory et une révision de sa politique d’authentification (sujet abordé avec Michel Dubois lors du dernier Congrès de l’APSSIS [3]) sont également des remparts nécessaires. 

L’acte d’accusation nous révèle également que les « intrus » ont été patients et ont su se faire discrets. Ils ont avancé très lentement leurs pions sur l’échiquier et auraient attendu plusieurs mois entre différentes étapes de la compromission, afin d’éviter de « déclencher des alarmes ». Ils auraient ensuite placé les données dérobées dans des archives chiffrées, qu’ils auraient d’abord fait transiter par les serveurs C2 hébergés en Californie et dans l’Arizona, configurés par Fujie Wang pour réaliser cette attaque, avant de les exfiltrer vers la Chine. 

→ Si une surveillance accrue du réseau (consommation de bande passante, indicateurs de compromission…) reste de mise. Il est très difficile de lutter dans le cas d’attaques très ciblées comme celle-ci, avec des attaquants qui n’agissent pas en mode « gros bourrin ».

Si l’acte d’accusation ne détaille pas les répercutions de cette attaque pour l’assureur, il est important de les rappeler :

En 2017, Anthem a versé 115 millions de dollars aux victimes ayant participé à un recours collectif. Nous pouvons aisément imaginer que l’assureur à perdu de nombreux clients suite à cet incident et son engouement médiatique, et également que les pertes financières ne s’arrêtent pas aux indemnités versées.

L’actualité a toujours de quoi nous faire méditer.

[1] https://www.justice.gov/opa/press-release/file/1161466/download

[2] https://en.wikipedia.org/wiki/Anthem_medical_data_breach

[3] https://www.apssis.com/actualite-ssi/338/le-mot-de-passe-est-mort-vive-l-authentification-votre-cle-est-elle-sous-le-paillasson-le-compte-rendu-de-gerard-peliks.htm

#medical#data#apssis#peliks