Contre les ransomwares, la difficile chasse aux signaux faibles
Il ne semble plus y avoir que l’épreuve de la reconstruction à craindre d’une attaque par rançongiciel. De quoi encourager au renforcement des capacités de détection. Mais cela n’a rien de généralisé.
Zeppelin, tout juste détaillé par Morphisec et Cylance, Maze, Sodinokibi, ou encore Snatch ne se contentent plus de chiffrer les données de leurs victimes pour essayer leur soutirer de l’argent : ils en volent au préalable. Pourquoi se priver, d’ailleurs, puisqu’ils ont généralement eu tout le temps voulu pour se promener copieusement dans l’environnement de leur victime, avant de déclencher les opérations de chiffrement. A la clé, des menaces de divulgation, ou simplement de dénonciation publique pour celui qui refuserait de payer, comme avec Maze.
Dans un tel contexte, se reposer sur ses sauvegardes ou concentrer sa détection sur le ransomware lui-même ne sert pas à grand-chose : la partie est déjà perdue, au moins en partie. Mark Arena, Pdg d’Intel 471, ne dit pas autre chose : « je continue d’entendre parler de personnes qui cherchent des IoC [indicateurs de compromission, N.D.L.R.] de ransomware. La réalité est qu’aucun IoC de ransomware ne vous sauvera. Il faut comprendre les précurseurs du rançongiciel déposé, car exemple Emotet, précède Trickbot, qui lui-même précède Ryuk ». Pour ce cas, c’est donc Emotet et Trickbot qu’il convient de rechercher.
Chez FireEye/Mandiant, Andrew Thompson va plus loin, soulignant ce qui vient après le maliciel d’infection initiale : « les téléchargeurs, ou étapes initiales, sont des choses personnalisées comme Dridex, Trickbot, Emotet, Terraloader/Squid », mais la suite passe « par des outils de sécurité offensive [OST, Offensive Security Tool] ». Et d’expliquer ainsi que les « utilisateurs/clients » des outils téléchargeurs initiaux « déploient Empire, Metasploit, Cobalt Strike, PoshC2, etc. ». Le récent témoignage des équipes Talos de Cisco sur des incidents liés à Maze illustre d’ailleurs bien le propos : Cobalt Strike a été utilisé dans un cas étudié après accès initial à l’environnement.
Andrew Thompson est d’ailleurs particulièrement critique à l’égard de ces outils. Pour lui, leur prolifération a un coût, bien réel, supporté notamment par les contribuables : des administrations « se font dévaster par des opérateurs utilisant des OST » et, au final, c’est donc le contribuable qui paie la facture. Plus généralement, il estime que ces outils et leur accessibilité pénalisent particulièrement les organisations à la cybersécurité la moins robuste. Kut Baumgartner, chez Kaspersky, ajoute à la réflexion la question de la redistribution des coûts liés aux indemnisations par des assurances.
Pour plusieurs experts, l’accès initial et le déplacement latéral sont deux éléments clés sur lesquels il convient de concentrer ses efforts de détection. Jon Hencinski, chez Expel.io, estime en particulier qu’il n’y a « qu’un nombre fini de manières de se déplacer latéralement ».
Mais cela ne simplifie pas pour autant vraiment la détection. Samir Bousseaden, chez Deloitte, souligne ainsi que certaines activités de déplacement et de reconnaissance peuvent être très difficiles à différencier d’activités légitimes d’administrateurs système, mentionnant par exemple l’utilisation de RDP pour du déplacement latéral.
Et puis, pour Paul Melson, la pratique n’est pas répandue. Selon lui, assurer une détection régulière est une capacité qui concerne « le top 1 % » des organisations les plus avancées. Et parmi celles-ci… celles qui sont capables de « suivre, analyser et développer des contremesures et détection » par anticipation « ne représentent qu’une petite fraction de ce pourcent ».