Détection des attaques cachées en ligne de commande

Les cybercriminels cachent souvent leurs actions en utilisant une méthode appelée Obfuscation de ligne de commande. Ça consiste à changer l'apparence des Commandes tout en s'assurant qu'elles fonctionnent. Ces tactiques rendent la tâche difficile à de nombreux systèmes de sécurité, car ils reposent généralement sur la reconnaissance de motifs ou de signatures spécifiques pour identifier les commandes malveillantes.

Cet article parle d'une nouvelle approche pour détecter ces commandes cachées grâce à un Modèle de langage conçu spécifiquement pour comprendre les activités sur les lignes de commande. Nos résultats montrent que le modèle peut repérer efficacement l'obfuscation même dans de grandes quantités de données provenant d'environnements variés comme des universités et des entreprises.

#Le problème avec les méthodes traditionnelles

Beaucoup de méthodes de sécurité cherchent des signes de logiciels malveillants en vérifiant les identifiants uniques des programmes ou le texte des commandes qu'ils exécutent. Un problème se pose quand les attaquants utilisent des programmes disponibles couramment qui sont déjà sur un ordinateur, appelés living-off-the-land binaries (LoLBins). Comme ces programmes sont utilisés pour des tâches quotidiennes, il devient impossible de les traquer avec des méthodes traditionnelles.

Quand les LoLBins sont utilisés, le matching de signatures sur les lignes de commande est l'une des rares options restantes pour détecter des malwares cachés. Même là, les attaquants essaient de masquer leurs actions. Ils peuvent changer la casse des lettres, ajouter des espaces inutiles ou insérer des caractères spéciaux qui ne changent pas le fonctionnement de la commande. Ces astuces sont connues sous le nom de techniques d'obfuscation.

Écrire des signatures pour l'obfuscation est compliqué à cause des innombrables façons de combiner différentes techniques. Cette complexité rend difficile pour les méthodes traditionnelles de repérer ces actions malveillantes, donc une nouvelle approche de Détection est nécessaire.

#Notre approche

Dans notre travail, on s'est concentré sur la détection de l'obfuscation dans les journaux de commandes, surtout ceux des LoLBins. Comme les lignes de commande ressemblent à des phrases, on a décidé d'utiliser un modèle de langage pour la détection. L'article détaille comment on a entraîné ce modèle depuis le début et nos tests approfondis sur des données du monde réel, en particulier concernant les activités malveillantes.

Pour montrer à quel point notre méthode de détection fonctionne bien, on inclut des études de cas qui démontrent que le modèle a réussi à identifier des échantillons de Malware connus et inconnus qui auraient sinon échappé à la détection par des méthodes traditionnelles.

#Méthodes d'obfuscation

Pour comprendre les formes courantes d'obfuscation de ligne de commande, il est important de voir comment les attaquants déguisent leurs actions. Ils peuvent s'appuyer sur des outils et des techniques bien connus, en altérant le texte des commandes de manière apparemment triviale mais efficace pour échapper à la détection.

Les attaquants changent la casse des lettres, insèrent des espaces ou utilisent des caractères qui n'affectent pas l'exécution des commandes. Ces changements compliquent la tâche des systèmes de sécurité qui dépendent de signatures fixes.

Écrire des signatures spécifiques à ces techniques d'obfuscation est un travail énorme à cause des combinaisons infinies possibles. Cette nature compliquée de l'obfuscation crée une lacune que notre modèle de détection proposé peut combler.

#Création du modèle de langage

Créer un modèle de langage depuis zéro nécessite plusieurs étapes : préparation des données, entraînement du tokenizer, pré-entraînement du modèle et ajustement fin.

#Préparation des données

Avant que notre modèle puisse analyser les données de ligne de commande, on doit décomposer le texte en unités plus petites appelées tokens. Ça aide le modèle à comprendre comment ces unités se rapportent les unes aux autres dans le contexte. Cependant, les lignes de commande contiennent souvent des éléments non pertinents pour nos objectifs, comme des valeurs spécifiques comme des adresses IP ou des dates. Pour optimiser notre modèle, on remplace ces parties non essentielles par des tokens génériques pendant la phase de préparation initiale.

#Entraînement du tokenizer

Une fois les données préparées, il faut les casser en tokens à l'aide d'un tokenizer entraîné. On a entraîné un tokenizer personnalisé spécifiquement pour les journaux de commandes parce que les tokenizers préexistants se concentrent sur le langage naturel, qui a des structures différentes.

Les tokenizers personnalisés ont prouvé leur efficacité pour compresser les données qu'ils traitaient, permettant une analyse plus rapide. Après plusieurs tests, on a déterminé qu'un tokenizer avec une taille de vocabulaire de 20k nous donnait les meilleurs résultats en termes de qualité de tokens et de vitesse de traitement.

#Pré-entraînement du modèle

Ensuite, on a commencé le pré-entraînement du modèle de langage, où il apprend la structure des données de ligne de commande sans avoir besoin d'exemples étiquetés. On a spécifiquement choisi une méthode d'entraînement qui est efficace et alignée avec nos objectifs de détection.

Cette phase nécessite une grande quantité de données, que l'on a rassemblées à partir de différents journaux d'exécution représentant l'activité normale de commandes. Le modèle apprend à repérer les différences dans les structures de commandes à travers ce processus, ce qui est vital pour détecter l'obfuscation.

#Ajustement fin du modèle

La phase d'ajustement fin implique de régler le modèle pour qu'il puisse classifier avec précision les commandes obfusquées. Un défi courant dans ce domaine est la distribution inégale des données, où peu de commandes obfusquées existent par rapport à celles bénignes.

Pour résoudre ce déséquilibre, on a modifié notre ensemble de données d'entraînement pour inclure plus d'échantillons obfusqués. On a également incorporé des techniques d'entraînement spéciales qui aident le modèle à se concentrer sur des commandes plus difficiles à classifier, en veillant à ce qu'il ne classifie pas simplement tout comme bénin.

#Tests en conditions réelles

La véritable épreuve de notre approche est sa performance dans des scénarios du monde réel. On a évalué notre modèle en utilisant trois jours de nouvelles données pour tester ses capacités de détection parmi un grand nombre de commandes bénignes.

Dans cette évaluation, le modèle a signalé environ 1600 échantillons comme potentiellement obfusqués. On a catégorisé ces résultats pour déterminer leur précision. Malheureusement, la nature de la télémétrie du monde réel a conduit à un taux de précision plus bas que prévu à cause de l'énorme volume de commandes bénignes présentes dans les données.

Pour améliorer la précision de notre modèle dans la détection d'activités malveillantes, on l'a réentraîné en utilisant les échantillons étiquetés, en mettant l'accent sur les commandes malveillantes obfusquées tout en conservant un ensemble large d'exemples bénins.

#Résultats

Après avoir apporté les ajustements, on a procédé à de nouveaux tests sur quatre jours supplémentaires de données. Les résultats ont montré une amélioration marquée de la précision du modèle, atteignant une précision significative dans l'identification des commandes malveillantes qui étaient auparavant cachées.

En augmentant le seuil de détection, on a également pu maintenir un haut niveau de précision tout en minimisant le nombre de faux positifs, soulignant l'efficacité du modèle même dans des environnements complexes.

#Études de cas

La force de notre modèle réside non seulement dans sa capacité à détecter des techniques d'obfuscation connues mais aussi dans sa capacité à reconnaître de nouvelles que l'on n'a jamais vues. Deux études de cas mettent en valeur cette efficacité.

Étude de cas 1 : Malware Raspberry Robin

Raspberry Robin est un ver qui repose sur divers binaires système communs. Malgré le fait qu'il existe de nombreuses méthodes connues pour détecter sa stratégie malveillante, notre modèle a identifié des signatures de commande que les méthodes traditionnelles ont ratées, montrant sa robustesse face à l'obfuscation.

Étude de cas 2 : Malware Gamarue

À l'instar de Raspberry Robin, Gamarue utilise des méthodes établies pour exécuter des commandes. Notre modèle a reconnu de légers changements dans ces commandes, comme des ajustements mineurs dans l'utilisation des caractères qui échappent à la détection des signatures.

Dans les deux cas, notre modèle a efficacement identifié diverses étapes de l'activité du malware, offrant des aperçus précieux sur leurs opérations.

#Conclusion

Cet article présente une nouvelle approche pour détecter des lignes de commande obfusquées en utilisant un modèle de langage petit et entraîné sur mesure. On a détaillé le processus d'entraînement et montré qu'il pouvait identifier efficacement l'obfuscation à travers divers environnements et journaux d'exécution.

Notre modèle a démontré sa valeur pratique en identifiant deux familles de malware répandues qui utilisent beaucoup l'obfuscation. On a atteint une haute précision même au milieu de grands ensembles de données, positionnant cette méthode comme un avancement significatif par rapport aux techniques de détection traditionnelles.

En regardant vers l'avenir, on prévoit d'élargir nos capacités de détection pour couvrir aussi les systèmes basés sur Unix. Le soutien continu des analystes en cybersécurité a été crucial dans notre recherche, ouvrant la voie à d'autres avancées dans la détection de l'obfuscation.