* même en user-space, le post donnait des IOC pour des fichiers sur le disque, donc des programmes comme chkrootkit et rkhunter devraient pouvoir être rendus capable de détecter cette version;
* en kernel-space, LKRG permet la détection de certaines choses bizarres que réalisent les processus d'implantation de certains rootkits, donc peut-être que ça fonctionnerait pour cette version de ce rootkit; mais bien sûr, LKRG est bypassable par nature.
Pour rendre plus difficile l'installation de ce rootkit, il y a au moins quatre solutions techniques:
* interdire le chargement de modules kernel au-delà d'un certain point du processus de boot: je ne connais pas de distro qui fasse ça, ou de dispositif fréquemment utilisé qui ait cet effet (par exemple, LKRG permet de le faire après son insertion, mais il est rare dans le monde réel);
* utiliser un kernel non modulaire: c'est une solution efficace, d'autant que le nombre de modules dont on se sert réellement sur une machine donnée représente une petite fraction de tous les modules compilés par les distros, mais je ne connais aucune distro qui fasse ça par défaut, et peu de gens compilent eux-mêmes leurs kernels non modulaires;
* utiliser un kernel grsecurity, dont la feature MODHARDEN rend plus difficile le chargement de modules sans privesc préalable, mais ça fait plus d'un an que plus grand monde n'utilise des kernels grsec, hélas;
* activer SELinux avec une politique comprenant un effet similaire à MODHARDEN: là aussi, peu de gens le font parce que c'est très difficile d'obtenir quelque chose qui fonctionne comme on veut (j'ai passé des jours au fil du temps à créer des trous dans la policy par défaut pour un certain contexte au boulot).
Bref, les mitigations ne sont pas du tout populaires... c'est ballot
