Depuis la découverte de Locky[1] par les chercheurs de Proofpoint il y a trois mois, le ransomware a régulièrement figuré parmi les principales menaces propagées par e-mail en termes de volume chaque semaine. Les propagateurs de Locky recourent à diverses techniques pour contourner les systèmes de sécurité et gagner en flexibilité dans leurs campagnes, leurs méthodes allant de l’utilisation de nouveaux chargeurs de malware tels que RockLoader[2] à l’ajout direct en pièces jointes de fichiers JavaScript malveillants[3] ou à des campagnes volumétriques. Jusqu’ici, toutefois, ces acteurs n’avaient pas encore masqué[4] les téléchargements en employant des méthodes observées pour d’autres campagnes de malware. Or, la semaine dernière, nous avons constaté qu’un acteur Locky (Affid=1) s’était mis à appliquer un masquage XOR et à inverser les octets du code malveillant afin d’échapper à la détection par les outils de sécurité réseau.

Le masquage XOR (OU exclusif) est une technique relativement courante consistant à crypter les octets d’un fichier binaire par rapport à un octet arbitraire qui sert de clé. Par exemple, le caractère ASCII « A » s’écrit 01000001 sous forme binaire. Si le caractère ASCII « B » (01000010 en binaire) est utilisé comme clé de chiffrement pour une opération XOR, leurs bits respectifs sont comparés deux à deux, pour donner 1 s’ils sont différents et 0 s’ils sont identiques, ce qui aboutit au résultat 00000011. Cette technique est simple, rapide et généralement efficace, raison pour laquelle elle est très prisée des auteurs de menaces et au cœur de robustes solutions de cryptage. Les exemples ci-dessous font référence aux équivalents hexadécimaux, l’exemple binaire précédent ayant été fourni par souci de simplicité.

En l’occurrence, nous avons observé des codes malveillants qui ont été à la fois soumis à un masque XOR et inversés. Exemple :

Figure 1 – Échantillon de code masqué par XOR et inversé. A noter que les quatre derniers octets correspondent à une somme de contrôle.

Après retrait de la somme de contrôle et masquage XOR par 0x73 (la lettre « s » minuscule en ASCII), nous obtenons :

Figure 2 – Échantillon après masquage XOR par 0x73

Les octets ayant aussi été inversés, voici ce que donne leur remise dans le bon ordre après masquage XOR :

Figure 3 – Échantillon après masquage XOR et inversion

Cette campagne spécifique ainsi que d’autres qui ont suivi ont également fait appel à plusieurs sites de téléchargement comportant chacun une charge distincte.

Si ce type de masquage peut être particulièrement efficace contre les produits de sécurité réseau qui scrutent principalement les exécutables entrant sur le réseau, il peut également servir à échapper aux « sandbox ».

L’utilisation de plusieurs sites de téléchargement comportant des charges distinctes pour Locky Affid=1 (et avant cela pour Dridex ID 12x) était observée depuis des mois. Cependant, nous avons commencé à détecter des charges masquées par XOR le 23 mai. Celles-ci avaient subi un masquage par 0xFF (11111111 en binaire) mais sans être inversées. Une campagne suivante, le même jour, a été masquée par 0x73 et inversée. Cette technique a été réutilisée pour une autre campagne plus tard dans la semaine, avec l’ajout d’une somme de contrôle de 4 octets à la fin, même si la plupart des codes étaient apparemment fragmentés et ne correspondaient donc pas à leur somme de contrôle. Le 25 mai, une campagne a employé une technique et des paramètres XOR identiques mais toutes les charges ont passé la somme de contrôle. Aujourd’hui même, des acteurs se sont mis à utiliser un générateur de nombres pseudoaléatoires pour créer les octets XOR, ce qui s’apparente bien plus à un cryptage à part entière qu’à un simple masquage.

Ces campagnes démontrent encore une fois la tendance de leurs auteurs à varier les mécanismes de diffusion et à ajouter des niveaux supplémentaires de masquage et d’esquive pour contourner les sécurités. Dans l’exemple ci-dessus, le code initial était en fait le chargeur de malware RockLoader, qui a ensuite tenté d’installer Locky à partir d’une architecture complexe de commande et de contrôle (C&C). Comme toujours, une protection et une vigilance des utilisateurs à plusieurs niveaux sont essentielles pour prévenir une infection par des menaces de plus en plus difficiles à détecter.

Références

[1]https://www.proofpoint.com/us/threat-insight/post/Dridex-Actors-Get-In-the-Ransomware-Game-With-Locky
[2]https://www.proofpoint.com/us/threat-insight/post/Locky-Ransomware-Cybercriminals-Introduce-New-RockLoader-Malware
[3]https://www.proofpoint.com/us/threat-insight/post/beware-javascript-malicious-email-campaigns-with-js-attachments-explode
[4]https://www.proofpoint.com/us/threat-insight/post/Obfuscation-Techniques-In-Phishing-Attacks