Thread by @Sebdraven

Petit thread sur le nouveau wiper qui a touché l'UA hier que je vais alimenter toute la journée
Ca sera en Fr
This thread is about new wiper targeting Ukraine

I'll update today. Sorry but I write in french in the first time, if you have questions my DMs are opens
#HermeticWiper

premiere constatation, le loader qui cause avec le driver qui sont en ressources est totalement neuf, pas de code réused pour le moment.

le driver va s'occuper du bas niveau piloter par son loader, via les IOCTLs

le driver pour jouer avec le disque c'est EaseUS Partition Master de EaseUS.

c'est lui qui va casser le disque

coté loader, c'est plutôt bien fait notamment, l'utilisation de thread. Le dev maitrise bien son Windows et la prog évènementiel.

Autre techniques smart il utilise &u"::$INDEX_ALLOCATION"

pour accéder au fichier dont il n'aurait pas les droits

le loader récupere les streams NTFS et file les handles au wiper qui s'occupe du reste.

Il démarre par les events logs comme ça by by les équipes de forensics

Pour le moment j'en suis arrivé au meme point que @SentinelOne sentinelone.com/labs/hermetic-…

Le wiper est un soft de suppression sécurisé
fichier.net/processus/epmn…

développé par une société chinoise.

Evidement le premier qui attribue cette attaque à la chine se verra retirer tous ses droits...

Il manipule de maniere indeferente fichiers et device. La diff se fait via les params passer pour savoir si on utilise ou pas les fonctions de devices.

ca complexifie l'analyse car tout est mixé

la fonction du tweet précédent

Coté Crypto, en fait y a juste un nombre random qui est généré suite à un provider crypto classique via l'API Windows et renvoyer au couche à l'appelante.

le buffer est stocké dans une matrice qui est passé passé en param.

Ca va avoir pour effet de random ce qui va wiper le disque, rendant impossible toute récupération.

Pour aller vite il parcours le disque de maniere récursive. Dans differents repertoires.

Et en fonction du type d'entrée, repertoire ou entrée il boucle ou appelle une fonction qu'il a passé en param

La même technique est utilisé pour savoir si c'est un repertoire ou un fichier que #WhisperGate

Apres cette technique est assez connu donc on peut pas vraiment conclure quoi ce soit au niveau de la phylogénie :)

Il recupere les numeros device utilsant l'IOCTL 0X56000 qu'on peut voir ici

cette technique a été documenté par @w4kfu ici
blog.w4kfu.com/public/tdl4_ar…
concernant le bootkit TDL-4.

Lui il infectait la MBR.
Sans parler vraiment de lien entre les deux, parce que ça commence a dater

Ca démontre quand meme de la part des auteurs de cet attaque une très bonne connaissance système.

Un autre loader faisait déjà ça

securitynews.sonicwall.com/xmlpost/apt-33…
utilisé par des wipers Iraniens

l'ensemble des IOCTLs pour la manipulation des disques a été documenté ici

gist.github.com/daaximus/e813a…

La manipulation et donc la destruction du disque se fait au travers la fonction DeviceIOControl et des codes documentés ci dessus et c'est le driver en dessous qui a été chargé via un service qui cassé le disque.

L'avantage d'utiliser un wiper a part avec un driver signé est le bypass des AV et de son chargement. L'OS va vérifier la signature et l'AV va le laisser faire son travail

le loader liste tous les attributs des entrées MFT et de maniere récursive en deux temps. Il a comme ça toutes les entrèes de maniere rapide
pour ensuite les wiper

Le driver est dans la ressource RCDATA qu'il lit et va deposer le driver sur le disque et enregistré son path dans les services.
Il check aussi si il est en sur un systeme 64b

La ressource est compressé. On le voit via l'utilisation de l'API LZ

Le driver est positionné directement dans system32, toutes les manipulations décrites ci dessus obligent l'attaquant d'etre admin de la machine

Fin partiel du thread ! J'updaterai si je trouve des choses !

Ah oui important de le citer par rapport à des operations comme NotPetya, sur cette version là il n'y a pas de latéralisation du wiper. Ca veut dire que d'un point de vue operationnel, il y a eu des choses avant de produite pour lancer ce wiper.

Soit RCE, soit les grands classiques que les gangs de ransomware ont déjà utilisés.

Petit point système Windows et driver. Parce que c'est pas souvent qu'on joue avec ça .

Alors évidemment ce n'est pas exhaustif mais bon ça donne une idée notamment pour ceux qui font du Hunting sur les rootkits.

Un driver pour qu'il sois chargé. Il doit passé par les manager de services.
qui va créer un service associé au binaire et le charger.

Comme ici le driver est signé correctement, ça passe crème Windows va le laisser se charger

Au chargement, il va crée un device avec son petit nom. .\\Device\EPMNTDRV\\

Parce qu'un driver est toujours affilié à un device, même s'il n'existe pas.

C'était le cas par exemple de Stuxnet ou Uroburos de Turla.

Et notre loader va piloter le device en utilisant l'API DeviceIoControl et les codes IOCTL associés.

Donc à chaque fois le loader va récuper le device du driver pour balancer les commandes qui vont bien de transaction.

.@SentinelOne explique très bien ici

"HermeticWiper enumerates a range of Physical Drives multiple times, from 0-100. For each Physical Drive, the \\.\EPMNTDRV\ device is called for a device number."

comment le device est appelé en fonction du numero de disque

Je viens de mettre la main sur une autre souche, le driver sur le disque a l'air de changer de nom