Skip to content
KitploitKITPLOIT
OutilsExploitsBlog
Log in
Soumettre
OutilsExploitsBlog
Soumettre

Outils de Hacking, PenTest et Cybersécurité pour votre Arsenal de Sécurité !

Kitploit est un répertoire d'outils de hacking, de cybersécurité et de pentesting. Découvrez les dernières mises à jour des projets pour trouver des vulnérabilités, analyser des systèmes, automatiser les tests et renforcer votre sécurité.

··Flux·Contact·Confidentialité·© 2026 Kitploit

Répertoire d'outils

Catégories

Voir toutes les catégories
Loading categories
TuxResponse — Script automatisé de réponse aux incidents Linux avec triage en direct, acquisition mémoire (LiME), imagerie disque, analyse YARA et génération de rapport HTML. | Kitploit
Outils/GitHubGitHub/la3ar0v/tuxresponse
Criminalistique DisqueCriminalistique MémoireScripting et AutomatisationAnalyse ForensiqueAnalyse de MalwareCriminalistique NumériqueRéponse aux IncidentsAnalyse de Journaux
GitHubla3ar0v/tuxresponse

TuxResponse

Script automatisé de réponse aux incidents Linux avec triage en direct, acquisition mémoire (LiME), imagerie disque, analyse YARA et génération de rapport HTML.

902169il y a 5 moisVérifié par Kitploit

Populaires

Voir tout →

Découvrez les outils les plus utilisés par notre communauté.

Explorer tous les outils

Parcourez notre collection d'outils

Voir tous les outils →
Voir le dépôt
Partager

TuxResponse (v1.1)

Réponse aux incidents Linux

image

TuxResponse est un script de réponse aux incidents pour systèmes Linux écrit en bash. Il peut automatiser les activités de réponse aux incidents sur les systèmes Linux et vous permettre de trier rapidement les systèmes, sans compromettre les résultats. En général, les systèmes d'entreprise disposent d'une certaine forme de surveillance et de contrôle, mais il existe des exceptions en raison du shadow IT et des images non standard déployées dans les entreprises. Ce qui équivaut à taper 10 commandes avec des tests d'essai, peut être fait en appuyant sur un bouton.

Testé sur :

  • Ubuntu 14+
  • CentOS 7+

Objectif principal :

  • Tirer parti des outils et fonctionnalités intégrés de Linux (outils comme dd, awk, grep, cat, netstat, etc.)
  • Réduire le nombre de commandes que le répondant aux incidents doit retenir/utiliser dans un scénario de réponse.
  • Automatisation

Outils externes inclus :

  • LiME
  • Exif
  • Chckrootkit
  • Yara + règles d'analyse Linux (nécessite un réseau pour récupérer le dépôt)

Exemple d'automatisation :
INSTALL LiME
function init_lime(){

  if [ -f /usr/bin/yum ]; then
    yum -y install make kernel-headers kernel-devel gcc
  elif [ -f /usr/bin/apt-get ]; then
    apt-add-repository universe
    apt-get -y install make linux-headers-$(uname -r) gcc
  fi

  rm -f /tmp/v1.8.1.zip
  wget -P/tmp https://github.com/504ensicsLabs/LiME/archive/v1.8.1.zip
  unzip /tmp/v1.8.1.zip
  rm -f /tmp/v1.8.1.zip

  pushd LiME-1.8.1/src
    make
    mv lime-*.ko /tmp/lime.ko
  popd
  rm -rf LiME-1.8.1
}

Lors de la réponse à des incidents, si vous devez installer LiME en tapant manuellement toutes les commandes, cela vous ralentira considérablement.

Fonctionnalités

1) Réponse en direct
1) Empreinte système
   1) Informations système, IP, Date, Heure, fuseau horaire local, dernier démarrage - 'hostnamectl; who -b; uname -a; uptime; ifconfig; date; last reboot'
2) Outils de système de fichiers
    1) Vérifier les systèmes de fichiers montés -'df -h'
    2) Hacher les exécutables (MD5) - 'find /usr/bin -type f -exec file "{}" \; | grep -i "elf" | cut -f1 -d: | xargs -I "{}" -n 1 md5sum {}'
    3) Fichiers modifiés - 'modified_files_period_select' (appel d'une fonction dans tuxresponse.sh)
    4) Lister tous les répertoires cachés - 'find / -type d -name "\.*"'
    5) Fichiers/répertoires sans nom d'utilisateur/groupe - 'find / \( -nouser -o -nogroup \) -exec ls -l {} \; 2>/dev/null'
    6) Fichiers modifiés par rapport aux paquets -'packaged_files_changed' (appel d'une fonction dans tuxresponse.sh)
3) YARA, CHKROOTKIT, EXIFTool
      1) Vérifier les rootkits - exécute 'chkrootkit'
      2) Analyse Yara - appel d'une fonction tuxresponse.sh 'yara_select' (analyse le système avec toutes les règles YARA Linux disponibles dans le dépôt principal)
      3) EXIFTool - appel d'une fonction tuxresponse.sh 'exiftool_select' (installe EXIFTool)
4) Outils d'analyse des processus
      1) Lister les processus en cours - 'ps -axu'
      2) Binaires supprimés encore en cours d'exécution - 'ls -alR /proc/*/exe 2> /dev/null | grep deleted'
      3) Connexions réseau actives (TCP, UDP) - 'ss -tunap | sed "s/[ \t]\+/|/g"'
      4) Vider le processus en fonction du PID - 'dump_process_select' (appel d'une fonction dans tuxresponse.sh)
          1) Entrez le PID à vider : **(ceci est la commande exécutée - gcore -a -o "${DUMP_FILE}" ${DUMP_PID} )**
      5) Processus s'exécutant depuis /tmp, /dev - 'ls -alR /proc/*/cwd 2> /dev/null | grep -E "tmp|dev"'
5) Analyse des connexions réseau
      1) Lister toutes les connexions réseau actives/sockets brutes - 'netstat -nalp; netstat -plant'
      
6) Utilisateurs
      1) Lister tous les utilisateurs connectés au système - 'w' 
      2) Obtenir les utilisateurs avec mots de passe - 'getent passwd'
7) Bash
      1) Vérifier le fichier d'historique bash - 'cat ~/.bash_history | nl'
      
8) Preuve de persistance
      1) Lister toutes les tâches Cron - 'list_all_crontab' (appel d'une fonction dans tuxresponse.sh)
      2) Lister tous les programmes de démarrage - 'list_all_onstartup' (appel d'une fonction dans tuxresponse.sh)
   
9) Vider tous les journaux (/var/log)
      1) Vider le fichier .bash_history des utilisateurs - 'cat_all_bash_history' (appel d'une fonction dans tuxresponse.sh)
      2) Trouver les journaux contenant des binaires -  'grep [[:cntrl:]] /var/log/*.log'
2) Connexion à la cible - utiliser SSH pour transférer le script et analyser le système distant.
      Cette option vous permet de vous connecter à un système distant, de copier tous les scripts et outils et d'analyser le système.
      
3) Prendre un dump mémoire (LKM LiME)
      Cette option vous permet de compiler LiME à partir des sources et de vider la mémoire RAM du système. C'est la façon la plus simple de le faire, car l'autre méthode serait de compiler à partir des sources pour toutes les versions majeures du noyau et d'insérer le LKM.
4) Prendre une image disque (DD)
Cette option vous permet de réaliser une image disque complète du système cible en utilisant l'outil bien connu - dd. La fonction prend la source et la destination comme paramètres et les insère dans la commande suivante 'dd if=${IMAGE_IN} | pv | dd of='${IMAGE_OUT}' bs=4K conv=noerror,sync'. Si vous analysez un système distant, le script va se copier lui-même là-bas. Ensuite, si le paramètre ${TARGET_HOST} est défini, le script va télécharger l'image vers le système de l'analyste en utilisant cette commande >> "ssh -p${TARGET_PORT} ${TARGET_USER}@${TARGET_HOST} 'dd if=${IMAGE_IN} bs=4K conv=noerror,sync' | pv | dd of='${IMAGE_OUT}'" (j'utilise beaucoup pv pour m'assurer que la progression est suivie)
5) Générer un rapport HTML

Tout ce que vous faites est enregistré dans des fichiers texte, ce qui facilite le retour en arrière et la consultation des résultats. La beauté de cela est que vous pouvez le télécharger dans vos outils d'analyse de journaux préférés et en tirer un sens ultérieurement. En plus de cela, vous pouvez utiliser cette fonction pour générer un rapport HTML et visualiser la sortie générée par les commandes de manière plus lisible.

6) Installer des logiciels
      Installer les binaires nécessaires au bon fonctionnement du script.
      1) Dépendances
      2) Yara et règles
      3) ExifTool
      4) Vérification initiale
      5) chckrootkit
      6) LiME

Journal des modifications

v1.1

Passage de durcissement et de robustesse médico-légale sur tuxresponse.sh :

Télécharger l’outil