#14 pspy Cheat Sheet: Monitoring Process Linux Tanpa Root untuk Security Assessment

#14 dalam seri Red Team Cheat Sheet membawa kita ke tool kecil yang sering dianggap sederhana, padahal sangat berguna untuk memahami apa yang benar-benar terjadi di sebuah host Linux: pspy.

Kalau LinPEAS membantu menginventarisasi konfigurasi dan potensi jalur privilege escalation, pspy membantu kita melihat process yang berjalan secara real time, termasuk process yang dipicu oleh cron, systemd timer, job backup, atau automation lain yang mungkin tidak terlihat dari pemeriksaan statis.

Tool ini menarik karena dapat memantau process tanpa membutuhkan root pada banyak skenario. Itu bukan berarti pspy bisa melihat semuanya tanpa batas. Visibility tetap dipengaruhi permission, konfigurasi kernel, namespace, container boundary, dan cara process dijalankan. Seperti biasa di dunia security: tidak ada tombol “lihat semua” yang bekerja universal.

Catatan penggunaan: contoh dalam artikel ini hanya untuk lab, CTF, atau sistem yang secara eksplisit diotorisasi. Jangan memasang binary monitoring pada host production tanpa persetujuan, change record, dan rencana cleanup.

Daftar Isi

Apa itu pspy?
Mengapa process monitoring penting?
Perbedaan pspy dan tool sistem bawaan
Setup lab aman
Cara membaca output pspy
Workflow assessment yang rapi
Memahami cron, systemd timer, backup, dan automation
Studi kasus: job backup dengan permission lemah
Detection dan perspektif Blue Team
Hardening dan mitigasi
Cheat sheet penggunaan aman di lab
Best practices
Kesimpulan

Apa Itu pspy?

pspy adalah tool untuk memonitor process Linux tanpa memerlukan root dalam banyak kondisi. Ia memanfaatkan mekanisme yang tersedia di userspace untuk mengamati process baru dan argumen command line yang terlihat dari environment tersebut.

Dalam konteks security assessment, pspy membantu menjawab pertanyaan seperti:

apakah ada cron job yang berjalan berkala?
apakah systemd timer memanggil script tertentu?
apakah ada backup job dengan path yang writable?
apakah ada automation yang menjalankan binary dari lokasi tidak aman?
apakah process privileged memanggil script atau executable yang dapat dimodifikasi user biasa?
apakah credential atau secret muncul dalam command line?

Jawaban atas pertanyaan tersebut sering menjadi penghubung antara temuan statis dan perilaku nyata.

LinPEAS dapat menunjukkan bahwa /opt/scripts/backup.sh writable. Namun pspy dapat menunjukkan bahwa script tersebut benar-benar dijalankan setiap lima menit oleh service account. Konteks inilah yang membuat triage menjadi lebih akurat.

Mengapa Monitoring Process Penting?

Banyak privilege escalation path tidak terlihat hanya dari file permission atau daftar service.

Contoh sederhana:

/opt/backup/backup.sh writable oleh group ops
        ↓
script dijalankan setiap 5 menit
        ↓
service berjalan dengan privilege tinggi
        ↓
ada risiko command execution melalui workflow backup

Tanpa process monitoring, assessor mungkin hanya melihat file writable lalu membuat asumsi. Dengan pspy, kita bisa melakukan validasi bahwa file tersebut memang dipanggil dalam runtime.

Ini penting karena assessment yang baik membedakan tiga hal:

indikasi — sesuatu terlihat berpotensi berisiko;
validasi — ada bukti bahwa kondisi itu benar-benar digunakan oleh workflow;
impact — apa dampaknya terhadap asset dan objective.

pspy terutama membantu pada tahap kedua.

pspy vs Tool Bawaan Linux

Linux sudah memiliki banyak tool process monitoring:

ps
top
htop
pgrep
pstree
journalctl
audit framework
eBPF-based observability tools

Lalu mengapa masih menggunakan pspy?

Karena pspy cukup praktis untuk mengamati process baru yang muncul, termasuk argumen command line, tanpa harus memasang agent atau melakukan konfigurasi audit yang panjang.

Namun pspy bukan pengganti auditd, EDR, SIEM, atau telemetry kernel. Ia cocok sebagai alat observasi ringan untuk lab dan assessment terkontrol, bukan sebagai kontrol keamanan permanen.

Setup Lab Aman

Gunakan lab terisolasi. Contoh sederhana:

VM-Scanner : Ubuntu/Kali
VM-Target  : Ubuntu Server
Network    : host-only atau VLAN lab

Pada target, siapkan job yang aman dan mudah dihentikan, misalnya script status backup yang hanya menulis timestamp ke log lab.

Contoh file:

sudo install -d -m 0755 /opt/lab-jobs
sudo tee /opt/lab-jobs/heartbeat.sh >/dev/null <<'EOF'
#!/usr/bin/env bash
date -Is >> /var/tmp/lab-heartbeat.log
EOF
sudo chmod 0755 /opt/lab-jobs/heartbeat.sh

Kemudian buat timer atau cron yang memanggilnya dalam lab. Pastikan tidak ada data produksi, credential, atau koneksi eksternal di dalam script.

Tujuan setup ini bukan membuat exploit. Tujuannya hanya memberi kita process event yang dapat diamati.

Menyiapkan pspy di Lab

Gunakan binary dari sumber resmi project atau release yang telah diverifikasi checksum-nya. Jangan mengunduh executable keamanan dari mirror acak lalu menjalankannya pada host penting. Supply-chain risk bukan plot twist yang menyenangkan.

Simpan binary pada folder kerja lab, lalu beri permission execute.

Contoh pola umum:

chmod +x ./pspy64

Jalankan dengan tampilan yang cukup rinci untuk observasi:

./pspy64 -pf -i 1000

Makna flag yang umum digunakan:

-p menampilkan process event;
-f menampilkan informasi file system event yang didukung;
-i 1000 mengatur interval observasi dalam milidetik.

Nama flag dapat berubah antar versi. Selalu cek --help pada binary yang benar-benar Anda gunakan.

Cara Membaca Output pspy

Output pspy biasanya memperlihatkan timestamp, PID, UID, dan command yang dijalankan.

Contoh ilustratif:

2026/09/03 04:10:00 CMD: UID=0 PID=1842 | /bin/sh -c /opt/lab-jobs/heartbeat.sh
2026/09/03 04:10:00 CMD: UID=0 PID=1843 | /usr/bin/date -Is

Dari satu event ini, kita dapat mengajukan beberapa pertanyaan:

process berjalan sebagai UID berapa?
siapa parent process-nya?
path script absolut atau relatif?
apakah script berada di directory yang writable oleh user lain?
apakah ada parameter yang berisi secret?
apakah command dipanggil melalui shell?
seberapa sering event muncul?

Jangan langsung menyimpulkan bahwa semua process UID 0 berbahaya. Banyak service legitimate memang berjalan sebagai root. Yang penting adalah hubungan antara privilege, path, input, dan kontrol akses.

Workflow Assessment yang Disarankan

1. Tentukan Objective

Misalnya objective kita adalah memeriksa apakah ada scheduled job privileged yang bergantung pada file non-privileged.

2. Inventarisasi Statis

Gunakan pemeriksaan aman untuk melihat:

cron directory;
systemd timer;
service unit;
script path;
file owner dan mode;
group membership;
writable directory.

3. Jalankan pspy dalam Window Observasi

Biarkan pspy berjalan cukup lama untuk menangkap interval job. Jangan berasumsi bahwa cron yang berjalan setiap jam akan terlihat dalam satu menit.

4. Korelasikan dengan Waktu

Catat timestamp event dan cocokkan dengan:

jadwal cron;
timer unit;
backup window;
deployment window;
batch processing.

5. Validasi Dampak Secara Aman

Dalam lab, gunakan marker harmless seperti file timestamp atau output ke log. Hindari memodifikasi process privileged pada sistem nyata.

Memahami Cron dari Perspektif pspy

Cron dapat menjalankan command pada interval tertentu. Dari sudut pandang assessment, kita tertarik pada:

user yang menjalankan job;
script yang dipanggil;
path binary;
environment variable;
lokasi output;
permission semua komponen dalam path.

Misalnya output menunjukkan:

CMD: UID=0 PID=2101 | /bin/sh -c /opt/backup/run.sh

Selanjutnya audit:

ls -l /opt/backup/run.sh
namei -l /opt/backup/run.sh

namei -l membantu melihat permission setiap komponen path, bukan hanya file terakhir.

Hal yang dicari bukan “apakah file ini writable?” saja, tetapi juga:

apakah directory parent writable?
apakah symlink dapat diganti?
apakah binary yang dipanggil menggunakan relative path?
apakah output diarahkan ke lokasi yang dapat dimodifikasi?

Memahami systemd Timer

Modern Linux sering menggunakan systemd timer daripada cron.

Beberapa command audit defensif yang aman di lab:

systemctl list-timers --all
systemctl list-unit-files --type=service
systemctl cat nama-service.service
systemctl cat nama-timer.timer

Jika pspy menangkap event seperti:

CMD: UID=0 PID=3000 | /usr/bin/python3 /opt/ops/report.py

kita dapat menelusuri unit yang memanggil report.py, memeriksa owner file, dan memastikan path interpreter serta dependency tidak dapat dipengaruhi user yang tidak berwenang.

Automation dan Backup Job

Backup adalah contoh yang bagus karena sering memiliki privilege tinggi, akses ke banyak directory, dan jadwal otomatis.

Sebuah backup job yang sehat seharusnya:

memakai account khusus dengan privilege minimum;
menggunakan path absolut;
memanggil binary dari lokasi trusted;
memiliki permission ketat;
tidak menyimpan secret di command line;
memiliki logging yang cukup;
memiliki proses review dan rotasi credential.

pspy dapat membantu menemukan pola seperti:

UID=0 | /usr/bin/rsync ...
UID=0 | /bin/sh -c /opt/backup/rotate.sh
UID=0 | /usr/bin/curl ...

Dalam assessment, pola terakhir patut ditinjau lebih jauh karena network call dari job privileged bisa memperluas blast radius jika endpoint atau konfigurasi salah.

Studi Kasus: Job Backup dengan Permission Lemah

Bayangkan lab memiliki komponen berikut:

Timer       : setiap 5 menit
Service UID : root
Script      : /opt/backup/rotate.sh
Owner       : root:ops
Mode        : 0775

Sementara user biasa termasuk group ops.

Dari pemeriksaan statis, kita sudah memiliki indikasi bahwa group dapat memodifikasi script. pspy kemudian menunjukkan:

04:15:00 CMD: UID=0 | /bin/sh -c /opt/backup/rotate.sh
04:20:00 CMD: UID=0 | /bin/sh -c /opt/backup/rotate.sh

Sekarang temuan kita jauh lebih kuat:

file berada dalam jalur eksekusi privileged;
eksekusi terjadi otomatis;
interval dapat diprediksi;
group non-root memiliki hak tulis.

Untuk laporan, jangan menuliskan secret atau payload. Dokumentasikan:

asset;
unit atau schedule;
owner/mode;
timestamp event;
screenshot atau potongan output yang disanitasi;
business impact;
rekomendasi remediation.

Remediation

ubah owner dan group;
gunakan mode 0750 atau lebih ketat sesuai kebutuhan;
pisahkan directory script dan output;
hindari group write pada file privileged;
gunakan service account khusus;
review path dependency;
tambahkan monitoring perubahan file;
lakukan retest setelah perbaikan.

Detection: Apa yang Bisa Dilihat Blue Team?

Dari perspektif defender, aktivitas process monitoring dan scheduled execution meninggalkan telemetry berbeda-beda.

Host Telemetry

process creation event;
parent-child relationship;
command line;
UID atau security context;
file access;
perubahan pada cron dan systemd unit;
checksum atau metadata file.

Log yang Relevan

systemd journal;
audit log;
shell history, dengan catatan keterbatasan;
file integrity monitoring;
EDR telemetry;
SIEM correlation.

Detection Idea

Beberapa ide detection defensif:

service privileged memanggil script dari path writable;
job root menjalankan binary dari directory user;
cron entry baru dibuat di luar change window;
process privileged memulai network utility yang tidak biasa;
command line berisi credential atau token;
perubahan permission pada script yang dipanggil timer.

Detection bukan hanya mencari nama pspy. Tool bisa berganti. Yang lebih penting adalah perilaku: siapa menjalankan apa, dari mana, kapan, dan dengan hak apa.

Hardening dan Mitigasi

Principle of Least Privilege

Scheduled job tidak otomatis harus berjalan sebagai root. Evaluasi kembali kebutuhan privilege-nya.

Secure File Ownership

Gunakan owner dan group yang tepat. Hindari 0777, 0775, atau group-write pada script privileged kecuali benar-benar diperlukan dan telah dikompensasi kontrol lain.

Absolute Paths

Gunakan path absolut untuk binary dan script. Relative path memperbesar risiko path hijacking.

Restrict Directory Write

Audit semua parent directory dengan namei -l. File aman tidak cukup jika directory induknya dapat dimodifikasi.

Secrets Management

Jangan menaruh password, token, atau private key di command line, script plaintext, atau environment yang terlalu terbuka. Gunakan secret manager atau mekanisme yang sesuai.

File Integrity Monitoring

Pantau perubahan pada:

/etc/cron*;
/etc/systemd/system;
/usr/local/bin;
directory automation;
script backup dan deployment.

Logging dan Retention

Pastikan event process dan perubahan konfigurasi tersedia bagi tim operasi dan SOC.

Cheat Sheet pspy untuk Lab

# Cek bantuan dan versi
./pspy64 --help

# Observasi process dengan interval 1 detik
./pspy64 -p -i 1000

# Observasi process dan file event yang didukung
./pspy64 -pf -i 1000

# Daftar timer systemd
systemctl list-timers --all

# Lihat definisi service
systemctl cat nama-service.service

# Audit permission sepanjang path
namei -l /opt/backup/rotate.sh

# Periksa owner dan mode file
stat /opt/backup/rotate.sh

# Periksa cron directory
ls -la /etc/cron.d /etc/cron.daily /etc/cron.hourly

# Tampilkan process tree saat ini
pstree -ap

Gunakan command tersebut untuk observasi dan audit pada sistem yang diotorisasi. Hindari perubahan konfigurasi pada production tanpa prosedur change management.

Best Practices Saat Menggunakan pspy

Gunakan Binary Terverifikasi

Verifikasi sumber, checksum, dan versi.

Batasi Durasi Observasi

Tetapkan window pengamatan. Jangan meninggalkan binary monitoring tanpa kebutuhan.

Sanitasi Evidence

Hapus atau redaksi token, password, path sensitif, dan data pelanggan dari laporan.

Jangan Menyamakan Visibility dengan Kepastian

Tidak terlihat di pspy bukan berarti process tidak pernah terjadi.

Gabungkan dengan Sumber Lain

Korelasi pspy dengan journal, audit log, systemd, cron, file permission, dan konfigurasi endpoint.

Simpan Konteks

Catat hostname, waktu, timezone, user, dan command yang dijalankan. Evidence tanpa konteks cepat berubah menjadi teka-teki.

pspy untuk Red Team, Blue Team, dan Purple Team

Red Team

Menggunakan pspy untuk menemukan process privileged yang bergantung pada konfigurasi lemah.

Blue Team

Menggunakan pola event yang sama untuk membangun detection terhadap scheduled execution yang anomali.

Purple Team

Menguji apakah process creation, file modification, dan scheduled task monitoring benar-benar menghasilkan alert yang dapat ditindaklanjuti.

Inilah alasan tool sederhana seperti pspy tetap relevan. Ia membantu mempertemukan konfigurasi, perilaku, dan telemetry.

Hubungan dengan Artikel Seri Lain

#06 BloodHound membantu memahami relationship dan attack path pada Active Directory.
#07 Windows Credential Exposure membahas risiko credential pada Windows.
#08 Kerbrute dan #09 Kerberoasting berfokus pada identity serta service account di AD.
#10 AD CS membahas certificate-based privilege path.
#11 LLMNR/NBT-NS dan #12 Evil-WinRM membahas exposure serta remote management.
#13 LinPEAS menjadi pasangan paling dekat artikel ini untuk enumeration Linux.

Jika #13 menjawab “konfigurasi apa yang mungkin berisiko?”, maka #14 membantu menjawab “apa yang benar-benar berjalan saat host digunakan?”.

Penutup

pspy bukan tool ajaib. Ia tidak menggantikan auditd, EDR, SIEM, atau analisis manual. Namun dalam lab dan security assessment terotorisasi, pspy sangat membantu mempersempit jarak antara temuan statis dan perilaku runtime.

Kebiasaan yang perlu dibawa dari artikel ini sederhana:

Jangan hanya bertanya file apa yang terlihat. Tanyakan juga process apa yang benar-benar berjalan, dengan privilege siapa, dari path mana, pada waktu kapan, dan apakah Blue Team dapat melihatnya.

Itulah cara mengubah output tool menjadi insight keamanan yang berguna.

Artikel berikutnya dalam seri adalah #15 GTFOBins Cheat Sheet: Menganalisis Binary Linux, Sudo, dan Jalur Privilege Escalation Secara Aman.

Referensi Resmi dan Dokumentasi

pspy — https://github.com/DominicBreuker/pspy
systemd Timers — https://www.freedesktop.org/software/systemd/man/latest/systemd.timer.html
systemd Service Units — https://www.freedesktop.org/software/systemd/man/latest/systemd.service.html
crontab(5) — https://man7.org/linux/man-pages/man5/crontab.5.html
Linux Audit Documentation — https://linux-audit.com/
MITRE ATT&CK T1053 Scheduled Task/Job — https://attack.mitre.org/techniques/T1053/
NIST SP 800-53 Rev. 5 — https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final