Skip to content
KitploitKITPLOIT
OutilsBlog
Soumettre
OutilsBlog
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.

Voir le dépôt
902157il y a 4 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 →
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 :
root@kitploit:~
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
root@kitploit:~
   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
root@kitploit:~
    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
root@kitploit:~
      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
root@kitploit:~
      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
root@kitploit:~
      1) Lister toutes les connexions réseau actives/sockets brutes - 'netstat -nalp; netstat -plant'
      
6) Utilisateurs
root@kitploit:~
      1) Lister tous les utilisateurs connectés au système - 'w' 
      2) Obtenir les utilisateurs avec mots de passe - 'getent passwd'
7) Bash
root@kitploit:~
      1) Vérifier le fichier d'historique bash - 'cat ~/.bash_history | nl'
      
8) Preuve de persistance
root@kitploit:~
      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)
root@kitploit:~
      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.
root@kitploit:~
      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)
root@kitploit:~
      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)
root@kitploit:~
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
root@kitploit:~
      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 :

  • Robustesse médico-légale
    • Les noms de fichiers de preuve utilisent désormais UTC ISO-8601 (YYYYMMDDTHHMMSSZ) au lieu de l'heure locale, pour un horodatage défendable.
    • Chaque fichier de preuve capturé est haché (SHA-256) dans un nouveau evidence/manifest.txt ; les images disque obtiennent un fichier .sha256 associé.
    • modified_files_period_select n'utilise plus touch sur un fichier d'horodatage dans le système de fichiers cible (ce qui contaminait atime/mtime de /tmp avant la recherche find). Il utilise désormais find / -xdev -newermt "1 $opt ago".
  • Corrections de sécurité / injection
    • Suppression de eval ${DD_CMD} dans _create_disk_image ; le pipeline dd/ssh s'exécute directement, et le périphérique source est validé par rapport à ^/dev/[a-zA-Z0-9]+$ avant utilisation.
    • dump_process_select valide que le PID est numérique et que /proc/<pid> existe avant d'invoquer gcore.
    • exec_CMD n'utilise plus eval ; les commandes de pipeline shell provenant du catalogue interne sont envoyées via bash -c.
  • Robustesse
    • Le script s'exécute désormais sous set -euo pipefail avec des variables globales initialisées au préalable.
    • Correction de la faute de frappe DISTO → DISTRO dans la branche de détection Arch Linux (qui nommait auparavant la distribution de manière incorrecte et silencieuse).
    • Correction de l'installation cassée des dépendances Ubuntu : apt-get install netstat → net-tools.
    • Le générateur de rapports HTML itère evidence/*.txt via un glob (plus d'analyse de ls) et ignore le manifeste ; les variables de sortie sont entre guillemets.
  • Autre
    • Ajout de la constante VERSION='1.1' ; la bannière affiche la version.
    • shellcheck -S error est propre.

Note : le mode piloté par menu dépend toujours de .cmds.sh, .menu_en.sh et forensics.sh, qui ne sont pas présents dans ce dépôt. La reconstruction du catalogue de commandes/menus est suivie comme un effort séparé.

Télécharger l’outil