CronRAT : un malware qui se cache dans les tâches Cron du… 31 février
Le 29 novembre 2021 à 09h02
1 min
Internet
Internet
En se basant sur un rapport de Sansec, Bleeping Computer explique qu’il s’agit d’un Remote Access Trojan (RAT) qui cible « les boutiques en ligne et permet aux attaquants de voler des données de carte de paiement ».
Les développeurs du malware utilisent une nouvelle technique pour se cacher : des lignes syntaxiquement valides pour une tâche Cron (donc acceptées par le système), « mais qui généreraient une erreur lors de leur exécution.Cela n’arrive par contre jamais puisqu’elle devrait avoir lieu le 31 février », une date qui n’existe pas (durant les années bissextiles, février n’a que 29 jours).
Le code, caché sous plusieurs couches de compression et d’encodage, « inclut des commandes d’autodestruction, de synchronisation et un protocole personnalisé qui permet la communication avec un serveur distant ». Au final, le risque est élevé puisque les pirates peuvent exécuter à distance n’importe quelle commande sur le système compromis.
Le 29 novembre 2021 à 09h02
Commentaires (14)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 29/11/2021 à 09h09
En attendant il passe allègrement sous la plupart des radars, en raison de la “relative simplicité de sa configuration”. Comment quoi les
plaisirsprogrammes les plus simples sont les meilleurs…Le 29/11/2021 à 09h21
Comment ? En espérant qu’un admin système (ou une taupe) repositionne la tâche au 28 (ou 29) février ?
S’ils ont réussi à écrire dans le cron, ils auraient aussi bien pu l’exécuter directement.
Le 29/11/2021 à 09h53
Il utilise le cron comme espace de stockage du code pour éviter que les antivirus le détecte. Le code n’est pas exécuté par le cron. C’est probablement combiné à autre chose mais l’article original n’est pas super exhaustif.
Le 29/11/2021 à 09h54
Je pense plutôt que la tâche cron sert à stocker du code “sensible” qui serait facilement détecté par les antivirus. Et le reste du programme ne fait que l’extraire du fichier et l’exécuter. C’est ce que j’ai compris du moins, et ça n’est je pense jamais exécuté depuis cron directement.
Le 29/11/2021 à 09h58
Après avoir lu les tweet du chercheur j’ai finis par comprendre que le cron est utilisé pour les 2. Dans le screenshot on voir une tache qui tourne tout les 30 min et qui est le point de départ. Et le reste du cron est utilisé comme espace de stockage.
Le 29/11/2021 à 09h42
Peut-être que c’est un bug et que l’exécution du 31 février est un “reste” vu qu’il s’auto-supprime.
Sinon, vu la tronche des commandes, dans le cron, je ne pense pas qu’un admin les modifie sans se douter que c’est louche.
Le 29/11/2021 à 10h01
En lisant le code on voit que seul le payload est stocké en base64 dans la cron au 31 février, pour échapper au anti-virus. Mais le morceau de code qui récupère cette payload et l’exécute est dans une cron normale qui tourne toute les 30 minutes.
Ceci dit c’est une brillante idée pour cacher des données. La communication TCP en bash est aussi intéressante à étudier.
Le 29/11/2021 à 10h34
C’est malin ! merci pour l’info
Le 29/11/2021 à 11h13
Donc l’info c’est plutôt que les antivirus ne scannent pas le cron ?
Le 29/11/2021 à 11h23
J’ai rien compris, pas clair leur truc…
EDIT Un article plus clair : https://www.netcost-security.fr/actualites/61728/cronrat-le-dangereux-malware-linux-qui-devrait-sexecuter-le-31-fevrier/
Le 29/11/2021 à 11h37
Bof, guère plus explicite.
Merci à sarbian et sebtx pour leurs explication de texte.
Le 29/11/2021 à 11h43
Oui c’est bizarre ce truc.Bonne pub pour la société de sécu en tout cas.
Le 29/11/2021 à 21h15
Merci, heureusement que vous êtes là :p
Le 30/11/2021 à 06h31
Surtout que cette assertion est imparfaite car incomplète, il manque la définition d’une année bissextile: ce n’est pas simplement une année dont le millésime est divisible par 4; il faut exclure la dernière année du siècle (1900 par exemple) sauf si c’est la dernière année d’un millénaire (2000). C’était un des Y2K bugs possibles.