Retex sur une alerte cyber ratée

Publié le par

Dans mon univers professionnel, Retex signifie “Retour d’expérience” (on dit aussi Rex). Je vais donc vous faire le retour d’expérience d’une alerte cyber ratée. Ce blog me permet en effet de partager mes expériences, et en particulier mes peines.

A 12h22 ce jour là, je reçois une alerte curieuse en provenance de ma supervision “Microsoft Defender for Cloud Apps” : une adresse IP suspecte détourne du trafic de mes utilisateurs.

Aussitôt, je procède à quelques vérifications : cette adresse IP est repérée par Microsoft comme utilisée par un “Serveur C&C pour la propagation de programmes malveillants”.

Pour le lecteur profane en la matière, il faut comprendre qu’aujourd’hui les pirates attaquent souvent leurs cibles avec l’aide de botnets, c’est-à-dire avec l’aide de réseaux de machines qu’ils contrôlent à l’insu de leurs propriétaires. Et pour contrôler ces ensembles de machines, ils utilisent des serveurs de commande et de contrôle (les serveurs C&C ou C2). Ces botnets sont utilisés pour des actions malveillantes, comme par exemple des exfiltrations de données, des envois de spam ou de malwares, ou des attaque DDOS…

Je poursuis mes investigations : avec l’interface de Microsoft Defender for Cloud Apps, je filtre les journaux d’activité de mes utilisateurs reliés à ce serveur piraté. Le constat est grave : plusieurs dizaines de comptes de mes utilisateurs sont utilisés avec des authentifications valides, et cela depuis plusieurs applications Microsoft (Teams, Outlook, Sharepoint…)

Le pirate contrôle et utilise plusieurs dizaines de comptes de mon entreprise !

Je remonte un peu dans le temps, et je constate que le pirate a pénétré l’entreprise depuis au moins un mois ! Mon sang se glace.

Être RSSI (Responsable de la Sécurité du Système d’Information), c’est être en permanence sur le qui-vive. Tous les RSSI le savent, leur entreprise n’est pas à l’abri d’une attaque cyber de grande ampleur. Non seulement ils s’y préparent, mais ils savent que cette attaque majeure, celle qui mettra tout le système d’information par terre, ARRIVERA.

Nul ne sait quand, ni comment, ni l’aspect qu’elle prendra. Mais tout s’arrêtera.

Le RSSI est donc comme Giovanni Drogo, personnage central du “Désert des Tartares”, roman de Dino Buzzati : il se prépare toute sa vie à la grande attaque finale…

Me voici donc en train d’observer de l’intérieur cette prise de contrôle des comptes de mes utilisateurs.

Après quelques minutes de sidération, je prends la décision de faire cesser l’attaque : je demande à l’équipe en charge des parefeux d’isoler les flux en provenance et vers ce serveur C&C, à l’équipe d’admin de modifier tous les mots de passe des utilisateurs concernés, à l’équipe support de s’attendre à un grand nombre d’appel d’utilisateurs en détresse et j’active la pré-alerte pour les participants à la cellule de crise cyber.

Tous mes messages sont conditionnels par précaution, mais je ne cache à personne la gravité potentielle de la situation.

Je révise mes fiches de procédure dans mon classeur de gestion de crise fraîchement créé, je retrouve les numéros de téléphone des personnes à appeler pour les différentes phases de la crise.

L’un des ordinateurs compromis est rapidement récupéré par le support grâce à la rapidité d’un des utilisateurs. Je m’apprête à en faire une image disque pour analyse ultérieure.

Il est 12h30, j’ai déclenché tout ce que j’avais à déclencher.

Non : je contacte l’hébergeur gérant l’adresse IP compromise, via son formulaire “abuse” pour qu’il agisse afin d’isoler ce serveur C&C.

12h45, les ingénieurs réseaux commencent à me remonter de l’information. Nous faisons un point en conférence téléphonique pour évoquer toutes les causes possibles. Le SIEM on prem n’a pas réagi, mais le serveur de logs montre bien la présence de l’adresse IP du serveur C&C.

Et elle est présente en nombre.

Je me prépare à un week-end difficile.

13h, les ingénieurs réseaux m’informent que parmi les ordinateurs concernés, le mien en fait partie. Ils me donnent la date et la plage horaire exacte pendant laquelle tout le flux de mon poste est passé par le serveur C&C. J’arrête mon ordinateur.

Depuis mon ordinateur de secours (un vieil Apple perso que je garde vivant et à jour via ma 4G perso et sans mes comptes professionnels), je vérifie ce que j’ai fait au moment indiqué par les équipes réseaux.

J’étais en train de travailler dans le train.

Avec cette information cruciale, et après quelques vérifications techniques, voici donc le message que j’ai envoyé à toutes les personnes impactées par cette alerte :

[...explications sur le contexte de l'attaque...]
Suite aux investigations techniques plus approfondies, menées avec diligence par l’équipe  Réseaux, il s’avère que Microsoft s’est trompé en indiquant que l’adresse IP XXX est malveillante.

Il s’agit en fait d’une adresse IP utilisée par le service Wifi de la SNCF.

L’alerte était donc un faux positif : je peux donc vous annoncer que votre compte n’a pas été compromis, ni piraté.

La rapidité est un élément clé dans une attaque informatique, et j’assume seul la responsabilité de cette décision. Néanmoins, j’ai conscience du dérangement important occasionné et je vous présente mes excuses les plus sincères.
[Zythom]

Fin du Retex, vous pouvez relire le billet avec la solution en tête et vous moquer autant que vous voulez, mais le soir, toute honte bue, j’ai ouvert une bouteille de champagne.

PS:
– Toujours utiliser le conditionnel quand on explique aux utilisateurs que leur compte a été compromis.
– Ne pas faire confiance aveuglément aux classifications des outils d’alerte.
– Garder à l’esprit que nos raisonnements restent faillibles, surtout sous la pression.
– Lorsque les utilisateurs ont pu lire mon message après avoir récupéré le contrôle de leur compte suite au changement de mot de passe, la plupart m’ont remercié et encouragé.
– Je pense que si quelqu’un lit les remontées des formulaires “abuse”, et s’il fait les vérifications, il doit parfois bien rire…

14 réflexions sur « Retex sur une alerte cyber ratée »

  1. Utiliser un wifi extérieur sans vpn est surprenant, non ? Pour un rssi ou autre personne précautionneuse de ses données, j’entends.

    • Vous voyez, vous aussi vous tirez des conclusions erronées basées sur vos a priori. Bien sur que j’utilise un VPN sur toutes mes connexions Wifi, y compris sur les bornes Wifi de mon entreprise. C’est d’ailleurs dans les logs du VPN pro que les admins réseaux ont trouvé les traces de ma connexion lors de mon utilisation du hotspot Wifi de la SNCF.

    • Donc par votre connexion vpn, vous contrôlez le compte de dizaines de personnes de l’entreprise ? Ou bien les accès vpn ne sont pas individuels ?
      Un C&C qui passe par une machine cliente et le service vpn, c’est peu commun. Dommage que l’outil Microsoft n’ait pas indiqué ce à quoi était connecté ce C&C.
      Leçons à tirer : ne pas forcément faire confiance aux outils sur lesquels on n’a pas la main et vérifier (c’est-à-dire de prendre le temps). Chose, malheureusement, qui n’est pas forcément possible et ne peut pas s’improviser.
      Merci pour la piqûre de rappel.

    • Nous avons 500 accès VPN individuels qui se connectent sur notre baie de serveurs VPN. Cela représente autant d’accès à l’entreprise qu’il y a de postes connectés via ces VPN. C’est la raison pour laquelle aucun de ces postes n’est considéré comme fiable, ce qui est une difficulté pour le télétravail. Mais difficile ne veut pas dire impossible : aujourd’hui, aucun poste n’est plus considéré comme fiable, et l’intérieur d’une entreprise ne peut plus être considéré comme sûr, surtout quand 90% des terminaux ne sont pas managés du fait du BYOD.

  3. Tiens, je suis curieux : un WHOIS ne retournait pas d’indication concernant la SNCF ?
    Après, dans le feu de l’action… Peut-être que ça a été oublié 😉

    • Non, le whois ne retourne aucune information. Nous avons juste vérifié ensuite si un site web était hébergé sur cette IP. Nous n’avons fait aucun scan en profondeur avec nos outils d’analyse Kali pour ne pas éveiller les soupçons d’un pirate.

  4. Bonjour et merci pour ce retour !

    Pas de honte à faire un excès de zèle et de vouloir assurer au maximum à mes yeux.

    Par contre le vrai problème est souvent dû à des énormes boîtes de type Microsoft, qui au nom de la sécurité laissent des outils automatiques faire leur analyse, donnant des situations rocambolesques où les honnêtes gens sont bloqués et les robots autorisés.

    J’en ai fait les frais en essayant d’héberger un serveur web maison sur une box dédiée, que Microsoft n’a jamais voulu considérer comme autre chose que du spam, malgré toutes les sécurités mises en place… (SPF, DKIM, DMARC, etc.)

    • Il est très difficile d’héberger un serveur de mail chez soi, en particulier lorsque l’on n’a pas la maîtrise du reverse DNS.

    • C’était mon cas aussi au départ (quand j’ai emménagé sur mon IP), mais de souvenir Microsoft (Outlook) envoie un bounce qui explique que l’IP est filtrée et délistable.

      Avez-vous eu ce mail et tenté un délistage chez Outlook mail ?
      Outlook, c’est les derniers qui m’em****aient.

      Mais maintenant, j’suis fier : j’ai une IP super propre, 10/10 sur mail tester ! J’suis même pas dans SORBS 🙂

  5. Bonjour,

    J’ai surtout l’impression que vous pus que tres bien géré la situation! vous avez réussi à anaylyser/canaliser,circonsrire/gérer vos équipes/communiqer/gérer la pression en même temps. Et tout ca sans faire d’erreur à première vue. Chapeau bas inspecteur gadget 🙂

    Je serai plus qu’interessé à pouvoir lire vos fiches de procédure ou avoir des détails sur comment vous les avez élaborées?

    Je suis sur que dans mon cas, comme un “couillon”, la première chose que j’arriverai à faire c’est couper mon accès au SI… 🙂

    Bonne nuit, la journée a été longue!
    Vincentt

  7. La threat Intel (Ou connaissance de la menace) est une science difficile. D’expérience on est pas loin de 90% de faux positif (alerte sonnant à tort) si on ne prend que cela en compte. Vous en verrez encore bien d’autres, et il faut veiller à ne pas trop crier au loup, au risque de perdre la confiance de ses utilisateurs.
    Les défenseurs se trompent souvent, l attaquant lui n’a besoin d avoir raison qu’une seule fois
    Courage et merci pour ce partage

  8. Excusez mais pouvez vous préciser pour un non-expert:
    Vous voulez dire que l’alerte était due à toute les fois où un employé de votre entreprise (vous y compris) travaillait en passant par le wifi de la SNCF? Et que vu que le wifi de la sncf est identifié comme inconnu au bataillon, msoft le considérait comme douteux? (ce qui imho pourrait être possible: je n’ai pas souvenir que le wifi en question ait été très sécurisé).

    Première considération :
    Dans ce cas là (1) mieux vaut une fausse alerte sur un truc pareil que l’inverse. Question de bénéfice risque, il me semble?
    Imaginez que vous n’ayez rien fait et que l’attaque soit légitime, vu ce qui se fait en ce moment, je n’ose pas imaginer les conséquences…
    IMHO, vous avez bien agis: si j’étais votre patron je vous verserais une prime. 🙂

    Deuxième considération:
    “cette adresse IP est repérée par Microsoft comme utilisée par un “Serveur C&C pour la propagation de programmes malveillants”.”
    A mon niveau de simple geek, avec mes deux ordis connectés aux réseau, face à une telle alerte j’aurais commencé par prendre mes précautions à mon échelle comme vous l’avez fait (on coupe tout et on passe en alerte).
    Mais comme vous j’aurais fichtrement employé le conditionnel: “Risque “possible” d’accident grave, attention, on vérifie”.
    Mes raisons?
    – adresse IP identifiée par msoft… ben j’ai une confiance modérée dans msoft, donc je vérifierais si msoft est le seul à considérer cette IP comme dangereuse, des fois que… J’ai des souvenirs d’antivirus qui flaggaient comme dangereux des programmes légitimes ou appartenant à la concurrence, alors…
    Donc dans ce cas, je me demanderais si ce n’est pas du faux positif.
    – ca peut être aussi une appli mal configurée ou je ne sais quelle ânerie de cet acabit qui fiche la zone. Justement, historiquement les applis faites pour ou par msoft étaient très douées dans ce domaine. Genre utiliser un port non standard, accéder à des fichiers auquel elles ne sont pas censés accéder, etc. Je ne jette pas nécessairement la pierre à msoft: chez droid l’équivalent se traduit, par exemple, par une appli de calculatrice qui va demander des droits d’accès aux fichiers parce que le dev ne s’est pas em…bêté à faire son travail correctement. Et ce n’est pas parce que l’appli est payante que ça diminue les risques, même si c’est un peu moins fréquent (ou pas?). Y a des fois je me dis que des gens ont reçu du fric pour faire un truc si mal torché et que ça me déprime.
    – etc.
    D’un autre coté, ça ne concernerait que ma machine, donc le stress est moindre. Vous, en cas d’erreur c’est toute l’entreprise que vous coulez… Respect pour le sang froid.

    En parlant de stress, après avoir réalisé que c’est une fausse alerte, dans votre cas j’irais pousser une méchante gueulante auprès du commercial de msoft rapport à son logiciel qui vous a fait passer des heures à bosser sur une fausse alerte, chiffrage à l’appui des frais (n professionnels mobilisés pendant x heures à un salaire de z euros horaire… 🙂 ). Quand on file du pognon pour qu’un logiciel fonctionne, me semble logique qu’il fonctionne correctement…

    Bref, pas de honte à avoir de votre part IMHO.

    Déclaration de conflits d’intérêt:
    Jamais eu très confiance en msoft. Ni en droid d’ailleurs. Ni en pas grand chose en fait. 😀

    (1) le cas contraire: les nombreuses attaques nucléaires évitées de justesse. Ex: fausse alerte nucléaire soviétique de 1983.

Les commentaires sont fermés.