Lorsque le botnet Necurs s’est soudainement retrouvé aux abonnés absents en début de mois, il en fut de même pour les campagnes d’e-mailing véhiculant le ransomware Locky et le malware Dridex. D’où l’interrogation des observateurs sur les motifs de cette interruption et combien de temps elle allait se prolonger. Il semble que ce deuxième point ait hélas aujourd’hui trouvé une réponse : le 21 juin, les chercheurs de Proofpoint ont ainsi pu observer la première campagne d’e-mailing d’un volume de plusieurs millions d’envois, véhiculant Locky, depuis le 31 mai dernier. Si l’on se base sur les adresses IP réutilisées, il semble bien que cette campagne ait été initiée par le botnet Necurs. À l’heure de la rédaction de ce billet, le 22 juin, une deuxième campagne Locky était en cours, et de bien plus grande ampleur. Signifiant donc un « retour aux affaires » manifeste de Locky et de Necurs.

Juste avant l’hibernation de Necurs, les auteurs de Locky avaient mis en place de nouvelles techniques de détection et d’évasion de sandbox. Des techniques qui sont présentes dans les nouvelles campagnes d’e-mailing et qui sont détaillées ci-après.

Campagne d’e-mailing

Le 21 juin, Proofpoint a détecté une vaste campagne Locky, contenant en pièce jointe une archive avec du code JavaScript. L’ouverture de cette archive entraîne le téléchargement et l’installation de Locky, avec l’ID d’affiliation « 1 » et la seed 7743 pour le DGA. Les messages de cette campagne avaient comme objet « Re: », et étaient accompagnés d’une pièce jointe intitulée « services_[nom]_[série aléatoire de 6 chiffres].zip », « [nom]_addition_[série aléatoire de 6 chiffres].zip » ou bien « [nom]_invoice_[série aléatoire de 6 chiffres].zip ». Cette archive zip contenait des fichiers JavaScript intitulés « addition-[série aléatoire de chiffres].js. »

Figure 1 : L’e-mail contenant le code JavaScript zippé entraînant la diffusion du ransomware Locky

Figure 2 : Le code JavaScript protégé par obfuscation, présent dans la pièce jointe

Analyse

Locky a introduit fin mai un nouveau loader, qui déploie au moins trois nouvelles techniques anti-analyses. La première cible les machines virtuelles (VM) qui peinent à maintenir des valeurs réalistes au niveau du compteur de cycles d’horloge (compteur TSC). Le malware compare le nombre de cycles d’horloge nécessaires à l’exécution de certaines API Windows. Comme vous vous en doutez, la plupart des fonctionnalités Windows requièrent davantage de cycles dans un environnement de type VM. Cette tendance à la hausse n’est cependant pas uniforme, certaines instructions nécessitant bien plus de temps que d’autres. Les auteurs du malware mesurent donc ces ratios afin de détecter les environnements virtualisés.

La deuxième technique intervient au niveau du code JavaScript de Locky. Celui-ci est exécuté avec l’argument « 123 », qui est converti en nombre entier dans le code du loader, puis utilisé pour assurer son obfuscation dans l’environnement d’exécution.  Mais ce même argument est notamment exploité pour assurer la désobfuscation de certaines portions de code du loader.  Or, ce code étant à la fois exécutable et accessible en écriture dans l’environnement d’exécution, l’absence des instructions adéquates va entraîner une exception, se traduisant par l’arrêt du malware, empêchant ainsi sa détection. La gestion de cette interdépendance peut s’avérer problématique pour certaines plates-formes d’analyse.

Figure 3 : JavaScript exécute le loader de Locky (après désobfuscation) avec l’argument « 123 »

La troisième technique contribue à camoufler certains secrets du loader lors de l’analyse rapide, en appliquant une méthode intéressante d’exécution intermodule. Une fois les contrôles du loader terminés, celui-ci décompresse le code binaire de Locky via la fonction RtlDecompressBuffer, puis écrase l’image d’origine du loader. Après un chargement manuel dans l’environnement d’exécution, le loader exécute le point d’entrée de Locky, qui finit par appeler la fonction présentée à la Figure 4. Celle-ci recherche des hooks sur la fonction NtQueryVirtualMemory. Si elle n’en trouve pas, elle en crée un pour prétendre que les ressources exécutables sont de type MEM_IMAGE. Elle génère ensuite une version du code binaire Locky à la fois exécutable et accessible en écriture, stockée dans l’exécutable principal. Puis elle définit des redirections vers cette version et appelle une fonction qui va modifier le pointeur d’instruction enregistré, afin qu’il renvoie l’image cible de la redirection. Comme le pointeur d’instruction enregistré, qui cible le code associé au point d’entrée dans l’exécutable principal, existe toujours dans la pile, la fonction va redéfinir également ce pointeur. L’exécutable principal n’ayant alors plus aucune utilité, elle remet tout à zéro dans la fonction, sauf l’en-tête PE, ce qui rend plus difficile l’analyse manuelle des dumps mémoire.

Figure 4 : La troisième technique anti-analyse utilisée par Locky exploite une méthode intéressante d’exécution intermodule

Conclusion

Bien que le volume de la campagne d’e-mailing du 21 juin représente seulement 10 % de celles observées avant l’hibernation de Necurs, celle-ci n’en reste pas moins de très grande ampleur par rapport à celles recensées au cours des trois dernières semaines. En parallèle, l’introduction de nouvelles techniques d’évasion et de techniques anti-VM, dans le loader du ransomware Locky, génère de nouveaux défis pour les analystes, les sandbox et les éditeurs de solutions anti-malwares, qui cherchent à détecter la toute dernière version de Locky et à en réduire au maximum les répercussions.

L’analyse des IP émettrices associées à cette campagne révèle que le fléau Necurs s’est réveillé et que malheureusement, Dridex tout comme Locky devraient faire leur prochaine réapparition dans de nouvelles campagnes d’e-mailing. La preuve par l’exemple : nous recensons déjà une campagne Locky bien plus importante, dès le deuxième jour d’activité de Necurs, et allons bien entendu continuer à suivre de très près la situation.

Indicateurs de compromission