Comment analyser les chevaux de Troie APT sur la base du modèle de cycle de renseignement sur les menaces

À propos du modèle de cycle de traitement des renseignements sur les menaces

Le terme « Cycle de traitement des renseignements sur les menaces » (F3EAD) provient de l'armée et est dominé par l'armée américaine. Méthodes d'organisation des ressources et de déploiement des troupes conçues par les commandants à tous les niveaux des armes de combat. Le Cyber ​​​​Emergency Response Center s'appuie sur cette méthode et traite les informations de renseignement sur les menaces selon les six étapes suivantes :

Première étape : Rechercher

Un certain jour d'un certain mois, le système "Onion" déployé sur le serveur cloud public du partenaire a alerté et a trouvé un programme suspect de cheval de Troie, l'équipe d'intervention d'urgence a donc rapidement lancé le processus d'intervention d'urgence :

Parties prenantes et autres Appuyez sur le bouton pour rejoindre le groupe et appeler. Le système des victimes est isolé pour enquête.

Le système de sécurité et les journaux d'audit sont exportés pour une analyse de traçabilité.

Préparation de l'architecture du système d'entreprise et des informations liées au code, aux violations d'intrusion et aux zones affectées à analyser

Étape 2 : Positionnement#🎜🎜 #

Selon les enregistrements d'audit du système de sécurité, il a été constaté qu'il existe un autre fichier *.ko dans le répertoire de fichiers malveillants, et ce fichier a été transféré depuis un autre serveur via SCP.

On peut voir que l'attaquant obtient d'abord l'autorisation d'accéder à un serveur présentant une vulnérabilité, puis transmet le fichier du cheval de Troie SCP aux machines accessibles via le serveur compromis, y compris la machine victime actuelle, et installe les contrôles. .

Ensuite, nous nous concentrerons sur l'analyse de cet ensemble de fichiers chevaux de Troie. Selon les règles de dénomination du fabricant de l'AV (Annexe 1), nous l'avons temporairement nommé "Backdoor:Linux/Rmgr!rookit", où. "rmgr" vient de Plusieurs fonctions du code du cheval de Troie utilisent le préfixe rmgr.

2.1. Fichiers de chevaux de Troie

Les fichiers de chevaux de Troie maîtrisés jusqu'à présent sont divisés en quatre parties et leurs fonctions sont brièvement décrites comme suit : #🎜 🎜#

2.2 Flux de travail du cheval de Troie

Le cheval de Troie a été adopté de l'implantation à l'exploitation , y compris d'éventuelles activités de pénétration ultérieures. Diverses techniques sont utilisées pour le cacher, ce qui le rend difficile à détecter sans système de sécurité. Dans le même temps, ce cheval de Troie a également fait l'objet de nombreuses confrontations, et les capacités conventionnelles de surveillance de la sécurité pourraient ne pas être en mesure de le détecter. Une brève description de son processus de fonctionnement est la suivante :

Trojan horse workflow

2.3 Principales fonctions de chaque partie du cheval de Troie# 🎜🎜#

1. rmgr.ko

Le rootkit utilise le module commun du noyau LKM. Les principales opérations après le chargement de ce rootkit sont répertoriées ci-dessous.

1) proc_create_data crée un fichier virtuel /proc/.dot3 pour une interaction ultérieure avec le processus en mode utilisateur du cheval de Troie

2) register_kprobe enregistre 4 structures kp : #🎜 🎜# ;

kp_kallsyms_lookup_namekrp_alloc_pidkp_do_exitkp_seq_path, utilisé pour utiliser kprobe pour effacer de manière préventive les opérations sur le processus cheval de Troie lorsque le système exécute ces fonctions ; #3) Le traitement fonction enregistrée par la structure kp ci-dessus, fake_seq_path est utilisée pour supprimer la liste liée des processus du noyau ; fichier "tcp", il est traité par fake_seq_show pour effacer la connexion réseau du cheval de Troie ; Toutes les informations ;

6) Lorsque le système accède aux fichiers liés au cheval de Troie, il sera traité par fake_filldir, et il sera déterminé si l'appelant est considéré comme une opération de cheval de Troie ou non. Renvoyez le résultat correct ; 🎜#

7) Se supprime dans la liste chaînée du module du noyau, kobject_del supprime son propre objet du noyau

# 🎜🎜##🎜 ; 🎜#

8) kthread_create crée le thread du noyau dot_thread

Créer le module de noyau auto-démarré/etc/ sysconfig/modules/ ati_remote3.modules

Écrivez dans le fichier du module du noyau /lib/modules/%s/kernel/drivers/input/misc/ati_remote3.ko

Relâchez rmgr_fake_libc afin de créer un fichier dans. disque

Libérez le fichier rmgr_daemon sur le disque et exécutez-le via call_usermodehelper_exec avec le nom de processus "[khelper]".

2. rmgr__fake_libc.so

Ce fichier de bibliothèque partagée est publié et écrit sur le disque par le rootkit du noyau. Le chemin est /tmp/.tmp_{21 caractères alphanumériques aléatoires} et est utilisé pour l'utilisateur. -mode du comportement du cheval de Troie est masqué.

La fonction du préfixe de subhook est extraite du code open source (Annexe 2). Veuillez vous rendre sur github pour les fonctions détaillées. Cet article n'entrera pas dans les détails.

Les fausses fonctions préfixées sont principalement utilisées pour lutter contre les enregistrements de processus et de commandes des HIDS courants fork et execve sont directement appelés via syscall sans utiliser l'encapsulation glibc, évitant ainsi de s'accrocher à la glibc HIDS.

fake_bash_add_history désactive la fonction d'audit de la commande bash.

3. rmgr_daemon

Ce processus est publié et écrit sur le disque par rmgr.ko, et le chemin est /tmp/.tmp_{21 caractères alphanumériques aléatoires}. Développé en C++, upx est compressé et compressé après compilation. Vous pouvez directement utiliser le logiciel open source upx -d rmgr_daemon pour décompresser sans traitement particulier.

Ses fonctions principales sont :

1) Surveiller l'état du module du noyau et interagir avec les informations du rootkit du noyau ;

2) Mettre à jour ;

3) Générer rmgr_fake_sshd, patchELF et modifier les bibliothèques dynamiques dépendantes, c'est-à-dire ajouter rmgr_fake_libc. donc, la fonction est comme mentionné ci-dessus

Obtenez le chemin du noyau

Renvoyez le chemin

patch ELF

4) Connectez-vous à C2 hm2.yrnykx.com 5) Gérez rmgr_fake_sshd ;

où patchELF Le code est extrait de GitHub - NixOS/patchelf (Annexe 3)

4. rmgr_fake_sshd

Le fichier est écrit sur le disque par rmgr_daemon, le chemin est /tmp/.tmp_{21 caractères alphanumériques aléatoires}, et son fonctionnement est géré par rmgr_daemon .

En tant que porte dérobée, il possède une CLÉ PRIVÉE codée en dur, comme indiqué ci-dessous :

Étant donné que certaines fonctions sont connectées via patchELF, l'exécution de la commande et d'autres comportements après la connexion SSH sont masqués. Le rmgr_fake_sshd lui-même, ainsi que les processus enfants dérivés de la connexion ssh, sont masqués via rmgr.ko via des appels de noyau de correctifs basés sur l'analyse susmentionnée.

rmgr_fake_sshd charge sshd_config codé en dur lorsqu'il démarre, veuillez faire attention à plusieurs configurations clés. Écoutez sur le port local 26657 et rmgr_daemon se connecte à ce port pour transférer la commande ssh de C2. Les protocoles réseau couramment utilisés pour s'adapter aux environnements professionnels sont implémentés ici, de sorte que la logique de détection des NIDS conventionnels soit contournée.

Étape 3 : Éliminer

Cela fait principalement référence au renforcement pour empêcher les attaquants d'attaquer de la même manière. Les méthodes spécifiques sont les suivantes :

Renforcement révolutionnaire, mise à jour du correctif et renforcement de l'ACL.

Canal d'exploitation et de maintenance, désactivez l'ancien compte, modifiez le compte du serveur dans le lien d'attaque et activez l'authentification à deux facteurs.

Limitez la portée du système accessible en fonction des rôles des utilisateurs.

Le système de la victime effectue un dump pour enregistrer l'image de la machine virtuelle pour une enquête plus approfondie.

Réinstallez le système victime et redéployez l'environnement métier.

Le chargement du nouveau module du noyau système nécessite une vérification de signature.

Étape 4 : Utilisez

pour terminer le travail d'intervention d'urgence Après avoir analysé la scène de l'incident et les documents, les informations clés extraites de l'ensemble de l'incident seront précipitées dans les renseignements sur les menaces. Cet article réduit le contenu du modèle pyramidal de renseignement sur les menaces à deux parties : les iocs et les ttps sont résumés à l'aide du modèle matriciel att&ck. Modèle de pyramide de renseignement sur les menaces

1.iocs

1) md5 :

7d859a22f38f0bcd55a46bc8b67c40df

fa73b2fd914a0cfd5e7d3161af903b6c

2) c2 :

hm2.yrnykx.com

2. ttps

Étape 5 : Analyse

Comme le montrent les ttps de la section précédente, la matrice att&ck ne peut pas couvrir complètement toutes les méthodes de dissimulation utilisées par ce cheval de Troie pour lutter contre le système de sécurité.

Une classification approximative de ses méthodes de dissimulation (processus, réseau, fichier) comprend :

C2 évite la détection du NIDS via fake_sshd ;

contourne l'audit de la commande hook libc HIDS via patchELF ;

invalide l'audit du shell via fake_bash_add_history ;

Modify ; le retour par le système des informations sur les fichiers lus sous /proc via le patch seq_show pour masquer les fichiers, les processus et les informations de connexion réseau liés aux chevaux de Troie ;

Masquer les fichiers des chevaux de Troie via le patch vfs_readdir

En supprimant le processus du noyau, les informations de la liste chaînée du module à éviter ; outils de détection de rookit permettant de découvrir des traces de chevaux de Troie dans le noyau

On voit que ce package de chevaux de Troie contient beaucoup de détails techniques pour lutter contre les systèmes de sécurité, mais il cible principalement certains anciens HIDS connus sur le marché et post-événement Outils d'enquête pour la collecte de preuves. Il peut toujours être découvert par les hooks d'appel système dérivés du processus en mode noyau et par l'analyse inotify+cloud.

La dimension de la confrontation entre chevaux de Troie et systèmes de sécurité

Un système cheval de Troie complet ne peut pas être développé simplement à cause d'une intrusion, et il fera inévitablement appel à de nombreux codes open source ou familiaux. Par conséquent, du point de vue de la traçabilité, nous pouvons effectuer un travail d'"archéologie" du code tout en intégrant les styles de code et le comportement des chevaux de Troie pertinents dans la bibliothèque de fonctionnalités du système de sécurité. Faute de place, nous n’entrerons pas dans les détails ici.

Étape 6 : Spread

Spread est l'article lui-même.

Résumé

En fait, la séquence réelle du processus de réponse et de traitement des incidents ne peut pas être complètement cohérente avec le processus ci-dessus. Mais après avoir terminé l'ensemble du processus, l'auteur estime que la gestion des incidents de sécurité peut être considérée comme une conclusion réussie. En fait, le processus F3EAD accorde plus d'attention à l'analyse et à l'application du renseignement (amélioration des capacités de contre-mesures de sécurité), en particulier aux itérations répétées dans la phase « d'analyse ».

La phase d'analyse (itération) du cycle F3EAD

De la veille froide à la mise en œuvre en passant par l'amélioration des capacités de sécurité de nos systèmes de sécurité, telle est la véritable valeur de la veille sur les menaces.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!