Play : automatiser et industrialiser l’estimation des dates d’attaque

Un exercice plus ou moins difficile

L’estimation de la date de survenue d’attaque est plus ou moins aisée, selon les cybercriminels. Début 2024, un affidé de LockBit fournissait des captures d’écran de listes de fichiers et dossiers volés permettant assez aisément d’aboutir à une telle estimation. On a retrouvé plus tard la même habitude avec un affidé RansomHub et avec un autre chez Lynx. À moins que ce ne soit le même, officiant sous diverses bannières.

Chez Safepay, une liste, sous forme de fichier texte, permet très fréquemment d’établir une telle estimation. On retrouve une telle liste pour nombre de victimes revendiquées sous la bannière d’INC Ransom, notamment.

Chez LockBit et RansomHub, les données volées étaient présentées dans une interface Web qui permet de consulter directement les dates de création de dossiers et de fichiers. Là encore, de quoi réaliser assez aisément une estimation.

Mais Play ne procède pas de la sorte. Dans la très grande majorité des cas, les données volées sont diffusées sous la forme d’une archive RAR scindée en plusieurs segments de taille variable selon la taille totale de l’archive. Plus cette dernière est volumineuse, plus les segments sont nombreux, et plus ils sont gros. On compte parfois jusqu’à plusieurs centaines de segments de 500 Mo.

La bonne nouvelle est qu’il est possible d’obtenir une liste du contenu d’une archive RAR sans qu’elle soit complète, voire à partir d’un fragment de segment d’archive. De quoi gagner un temps considérable, comme avec Akira, tout en respectant les victimes et leurs données.

Automatiser le processus

Dès lors, nous avons produit plusieurs scripts visant à automatiser le processus. Seuls quelques segments sont téléchargés, et encore, partiellement (à l’exception du premier et du dernier), et pas plus d’un à la fois.

La liste du contenu de chaque fraction de segment téléchargée est produite dès la fin de son téléchargement. La fraction correspondante est supprimée dans la foulée.

Seules les dates de création de fichiers sont retenues afin d’éviter une date qui pourrait être celle de la décompression d’archive sur un espace de stockage intermédiaire. La date observée la plus proche de celle de la revendication est retenue. Les listes sont supprimées dans la foulée.

Plusieurs cas pour lesquels une date de survenue effective est connue, du fait notamment d’une couverture médiatique ou d’une information réglementée, ont permis de conforter la validité de l’approche, avec néanmoins un certain écart : il n’est pas rare que la date ainsi estimée soit antérieure de quelques jours à celle de la découverte de l’attaque par la victime.

Ce n’est pas une surprise en soi : la date la plus récente obtenue par ce procédé correspond vraisemblablement plus à celle de la fin de l’exfiltration des données qu’à celle du déclenchement du ransomware – à l’occasion de laquelle l’attaque est très généralement découverte.

Enseignements

À date, nous sommes ainsi parvenus à établir une date estimée de survenue de l’attaque pour plusieurs centaines de revendications sous la bannière de Play. Sur les douze derniers mois, cela représente 298 revendications étudiées, soit près de 76 % du total sur la période.

En moyenne, il apparaît ainsi falloir compter environ 4 jours entre la fin d’exfiltration des données et le déclenchement du rançongiciel, puis de l’ordre de 8 jours avant la revendication. Les cas où la revendication est survenue plus tard, jusqu’à trois semaines après la survenue du chiffrement, suggèrent que des discussions ont permis de retarder la revendication.

La reconstruction de la chronologie des attaques impliquant Play fait ressortir un pic d’activité inhabituel en novembre 2024, avant un retour à un rythme plus régulier. Mais les mois de février et de mai 2025 ont été intenses pour l’enseigne.

Reste une interrogation : les opérateurs de Play acceptent-ils de laisser épinglées, sur leur vitrine, des victimes ayant pourtant cédé au chantage ? Nous avons ainsi trouvé trois victimes toujours affichées, pour lesquelles les liens vers les données volées sont toujours inexistants, plusieurs semaines, voire des mois, après la revendication initiale. Pour dix de plus, le lien vers le dossier contenant les segments est là, mais toute tentative d’accès se solde par une erreur 403.