#13 LinPEAS Cheat Sheet: Linux Privilege Escalation Enumeration untuk Security Assessment

Kalau artikel-artikel sebelumnya membantu kita menemukan host, service, endpoint, account, dan attack path, sekarang kita masuk ke pertanyaan yang biasanya membuat suasana terminal sedikit lebih serius:

Kalau sudah punya akses sebagai user biasa, sebenarnya seberapa jauh akses itu bisa berkembang?

Di Linux, jawaban atas pertanyaan tersebut sering tersembunyi di banyak tempat: permission file, sudoers, cron, service, capability, credential yang tercecer, environment variable, container boundary, sampai kernel dan package yang tertinggal.

Di sinilah LinPEAS berguna.

LinPEAS adalah script enumeration untuk membantu mengidentifikasi kemungkinan jalur Linux privilege escalation. Ia bukan tombol ajaib yang otomatis memberi root, dan output-nya bukan vonis final. LinPEAS lebih tepat dipandang sebagai peta awal: luas, cepat, dan kadang berisik—seperti teman yang sangat rajin mencatat tetapi belum tentu tahu mana yang paling penting.

Artikel #13 Red Team Cheat Sheet Series ini membahas cara menggunakan LinPEAS secara aman pada lab atau security assessment yang memiliki authorization, cara membaca hasilnya, bagaimana memvalidasi temuan tanpa merusak sistem, serta bagaimana Blue Team mendeteksi dan mengurangi risiko yang ditemukan.

Authorization first. Gunakan contoh hanya pada sistem milik sendiri, lab terisolasi, CTF, atau scope assessment yang tertulis jelas. Jangan mengunduh dan menjalankan script enumeration pada server publik secara sembarangan.

Apa yang Dilakukan LinPEAS?

Secara umum, LinPEAS mengumpulkan informasi lokal yang relevan untuk menilai kemungkinan privilege escalation, seperti:

• identitas user dan group;
• kernel dan distribusi Linux;
• proses yang berjalan;
• service dan timer;
• konfigurasi sudo;
• file dengan permission berisiko;
• SUID/SGID binary;
• Linux capabilities;
• writable directory atau file;
• cron job;
• credential dan secret yang terekspos;
• konfigurasi container atau virtualization;
• software version dan patch context;
• koneksi network dan socket lokal.

Tujuan utamanya bukan “mencari satu bug besar”. Tujuannya adalah menghubungkan beberapa fakta kecil.

Contoh sederhana:

user biasa
   ↓
menjalankan service tertentu
   ↓
service membaca file konfigurasi writable
   ↓
file diproses oleh account dengan privilege lebih tinggi
   ↓
terdapat jalur privilege escalation

LinPEAS membantu kita menemukan potongan-potongan puzzle tersebut. Manusia tetap harus menyusun gambarnya.

LinPEAS Bukan Exploit Framework

Perbedaan ini penting.

LinPEAS fokus pada enumeration dan triage. Ia tidak dirancang sebagai platform eksploitasi otomatis. Output-nya memberi indikator yang perlu dianalisis lebih lanjut.

Misalnya LinPEAS menandai:

• binary SUID;
• sudo rule yang longgar;
• file konfigurasi yang writable;
• capability tertentu;
• secret dalam environment variable.

Apakah itu otomatis berarti kita bisa menjadi root? Belum tentu.

Setiap temuan perlu diverifikasi dari sisi:

1. apakah benar dapat diakses oleh user saat ini;
2. apakah kondisi tersebut aktif atau hanya sisa konfigurasi;
3. apakah ada mitigasi lain;
4. apakah eksploitasi akan berdampak pada service;
5. apakah temuan tersebut relevan dengan objective assessment.

Dalam laporan profesional, “indikator potensial” harus dibedakan dari “jalur yang tervalidasi”.

Setup Lab Aman

Lab minimal untuk mengikuti artikel ini:

• satu VM attacker atau workstation assessment;
• satu VM Linux target;
• satu user non-root pada target;
• snapshot sebelum pengujian;
• jaringan host-only atau VLAN terisolasi;
• logging dasar diaktifkan.

Contoh target dapat menggunakan Ubuntu Server, Debian, atau distro lain yang memang Anda kelola sendiri. Gunakan service dummy dan account lab. Hindari memasukkan secret produksi ke dalam VM pembelajaran.

Di sisi Blue Team, siapkan pula:

• auditd atau journald;
• process monitoring;
• file integrity monitoring jika tersedia;
• baseline package dan service;
• catatan waktu pengujian.

Tujuan lab bukan sekadar “mendapat root”. Tujuannya adalah membandingkan apa yang dilakukan tool, evidence yang tertinggal, dan kontrol apa yang bisa mempersempit jalur tersebut.

Mendapatkan LinPEAS Secara Aman

Gunakan repository resmi atau source yang dapat diverifikasi. Jangan mengunduh script dari forum acak lalu menjalankannya sebagai root.

Di lab, Anda dapat menyalin file ke target menggunakan metode yang sudah disetujui dalam scope, misalnya shared folder, secure copy, atau web server internal lab.

Contoh konseptual:

scp linpeas.sh labuser@10.10.10.15:/tmp/linpeas.sh

Lalu pada host target:

chmod 700 /tmp/linpeas.sh

Perhatikan prinsipnya:

• simpan di lokasi sementara;
• beri permission minimum;
• catat hash file bila diperlukan;
• hapus sesuai prosedur cleanup setelah pengujian.

Menjalankan LinPEAS

Untuk menjalankan secara normal:

./linpeas.sh

Jika shell tidak memiliki permission execute:

bash linpeas.sh

Simpan output ke file agar dapat dianalisis dan dilaporkan:

./linpeas.sh | tee linpeas-$(hostname)-$(date +%F).txt

Pada assessment yang sensitif terhadap resource, pilih mode yang lebih ringan dan hindari menjalankan banyak proses tambahan tanpa alasan. Jangan menjadikan “scan paling lengkap” sebagai dogma.

Membaca Output: Mulai dari Konteks

Output LinPEAS cukup panjang. Jangan membacanya seperti novel dari baris pertama sampai terakhir sambil berharap ada suara narator.

Mulai dari konteks dasar:

User        : appuser
Groups      : appuser www-data
OS          : Ubuntu 22.04
Kernel      : 5.x
Hostname    : web-01

Informasi dasar ini membantu menjawab:

• user apa yang kita miliki;
• group apa yang memberi akses tambahan;
• sistem ini server aplikasi, database, atau jump host;
• apakah host berada di container;
• apakah temuan yang muncul masuk akal untuk fungsi server tersebut.

Sebagai contoh, membership pada group tertentu bisa lebih relevan daripada puluhan warning generik. Konteks memperkecil noise.

Area Penting yang Perlu Ditriage

1. sudo dan Sudoers

Periksa apakah user dapat menjalankan command tertentu sebagai user lain atau root.

Audit manual yang aman:

sudo -l

Output perlu dibaca hati-hati. Rule dengan wildcard, binary yang dapat memproses file, atau command yang seharusnya tidak diberikan ke user biasa layak ditinjau.

Jangan langsung mencoba “membuktikan” semuanya pada production. Dalam banyak kasus, evidence konfigurasi sudah cukup untuk rekomendasi hardening.

2. SUID dan SGID Binary

SUID memungkinkan program berjalan dengan effective user ID pemilik file. Itu berguna untuk beberapa operasi sistem, tetapi juga memperluas attack surface bila binary salah konfigurasi atau rentan.

Pencarian manual:

find / -perm -4000 -type f 2>/dev/null

Yang perlu diperhatikan:

• apakah binary memang diperlukan;
• apakah berasal dari package resmi;
• apakah versinya masih didukung;
• apakah ada custom binary;
• apakah permission dapat dikurangi.

Temuan SUID tidak otomatis menjadi vulnerability. Ia adalah candidate for review.

3. Linux Capabilities

Capabilities memecah privilege root menjadi unit-unit lebih kecil. Secara desain ini lebih granular, tetapi capability yang salah diberikan dapat menciptakan risiko besar.

Pencarian manual:

getcap -r / 2>/dev/null

Audit harus menjawab:

• binary apa yang memiliki capability;
• mengapa capability itu dibutuhkan;
• siapa yang dapat mengeksekusinya;
• apakah binary dapat memengaruhi proses atau file sensitif.

4. Cron dan Timer

Jadwal otomatis sering menjadi sumber masalah ketika script atau directory yang dipanggil dapat ditulis oleh user biasa.

Audit dasar:

ls -la /etc/cron* 2>/dev/null
systemctl list-timers --all

Cari hubungan antara:

scheduled task
      ↓
script/config path
      ↓
permission
      ↓
execution identity

Laporan yang baik menjelaskan chain tersebut. Bukan hanya “cron ditemukan”.

5. Process dan Service

Proses yang berjalan memberikan gambaran nyata tentang workload host.

Gunakan:

ps auxww
systemctl --type=service --state=running

Perhatikan:

• service berjalan sebagai root padahal tidak perlu;
• binary atau script dari path writable;
• argument command line yang mengandung secret;
• custom service tanpa unit hardening;
• proses debug yang tertinggal.

Process enumeration juga membantu menghubungkan hasil LinPEAS dengan artikel berikutnya, #14 pspy, yang fokus pada observasi proses secara real-time.

6. File Permission dan Writable Path

Salah satu temuan paling penting biasanya bukan file “aneh”, melainkan permission yang terlalu longgar.

Contoh audit terarah:

find /etc /opt /var/www -type f -writable 2>/dev/null

Jangan menjalankan pencarian seluruh filesystem tanpa pertimbangan pada server besar karena dapat menambah beban I/O.

Pertanyaan yang perlu dijawab:

• siapa pemilik file;
• siapa yang dapat menulis;
• proses apa yang membaca file;
• apakah file berada di jalur eksekusi;
• apakah perubahan dapat mengubah perilaku service.

7. Credential dan Secret Exposure

LinPEAS dapat menandai kemungkinan secret dalam file konfigurasi, history, environment, atau command line.

Temuan ini harus diperlakukan sebagai sensitive evidence.

Jangan menyalin secret mentah ke laporan. Gunakan redaction:

DB_PASSWORD=[REDACTED]
API_TOKEN=[REDACTED]

Yang perlu dicatat:

• lokasi secret;
• jenis credential;
• account atau service yang terdampak;
• apakah credential masih aktif;
• tindakan rotasi dan revocation yang diperlukan.

8. Container dan Boundary

Jika target berjalan dalam container, pertanyaannya bukan hanya “apakah user bisa menjadi root di container?”, tetapi juga “apa boundary yang benar-benar ada?”

Audit harus melihat:

• privileged container;
• mounted host filesystem;
• exposed Docker socket;
• capability tambahan;
• secret mount;
• service account pada orchestrator.

Container root tidak selalu sama dengan host root, tetapi misconfiguration tertentu dapat memperbesar dampak secara signifikan.

Menentukan Prioritas Temuan

LinPEAS cenderung menampilkan banyak hal. Prioritaskan dengan matriks sederhana:

High Priority

• jalur tervalidasi menuju privilege lebih tinggi;
• secret aktif pada account penting;
• root service membaca file writable oleh user biasa;
• privileged container dengan boundary lemah;
• custom SUID binary yang tidak terdokumentasi.

Medium Priority

• package lama dengan exposure yang perlu verifikasi;
• administrative group membership yang berlebihan;
• cron atau service configuration yang berisiko tetapi belum tervalidasi;
• debug setting pada service internal.

Low Priority

• informational finding;
• banner atau versi yang tidak berdampak langsung;
• konfigurasi yang memang sesuai desain tetapi perlu dokumentasi.

Severity bukan ditentukan oleh warna output saja. Gunakan konteks business impact dan exploitability.

Studi Kasus: Service Backup yang Terlalu Ramah

Misalkan LinPEAS menunjukkan:

User: reportuser
Service: backup-agent berjalan sebagai root
Config: /opt/backup/agent.conf writable oleh reportuser

Kita tidak perlu langsung melakukan eksploitasi agresif. Validasi aman dapat dilakukan dengan:

1. mencatat owner dan permission file;
2. memeriksa unit service;
3. memeriksa kapan service berjalan;
4. memverifikasi apakah file dibaca setiap eksekusi;
5. mendokumentasikan dampak teoretis dan bukti konfigurasi.

Attack path-nya:

reportuser
   ↓
config writable
   ↓
root backup-agent membaca config
   ↓
potensi command/config injection
   ↓
privilege boundary melemah

Detection:

• perubahan file di /opt/backup;
• restart service tidak biasa;
• child process baru dari backup-agent;
• perubahan owner/permission;
• akses ke path sensitif setelah service restart.

Hardening:

• ubah ownership dan permission;
• pisahkan config yang boleh diubah operator;
• jalankan service dengan dedicated unprivileged account;
• gunakan systemd hardening seperti NoNewPrivileges, ProtectSystem, dan ProtectHome bila kompatibel;
• lakukan file integrity monitoring;
• rotasi secret bila config pernah terekspos.

Kita mendapatkan evidence yang bernilai tanpa harus merusak service.

Attack → Evidence → Detection → Hardening

Attack / Activity

Pada konteks assessment, aktivitas LinPEAS meliputi pembacaan file permission, enumerasi proses, query system configuration, pencarian file sensitif, dan pemeriksaan capability atau SUID.

Evidence

Potensi artifact:

• proses shell atau interpreter yang menjalankan script;
• akses beruntun ke banyak path;
• pembacaan /proc, /etc, /var, dan lokasi konfigurasi;
• file script pada /tmp, home directory, atau shared path;
• koneksi transfer file sebelum eksekusi;
• command history atau shell audit record.

Detection

Blue Team dapat mengamati:

• auditd file access;
• process creation telemetry;
• EDR behavior analytics;
• perubahan file sementara;
• anomalous traversal oleh account aplikasi;
• penggunaan find, grep, getcap, sudo -l, atau interpreter tertentu dalam sequence tidak biasa.

Detection yang terlalu literal—misalnya hanya mencari nama linpeas.sh—mudah dilewati karena script dapat diganti nama atau teknik dilakukan manual.

Hardening

• least privilege;
• review SUID/SGID dan capabilities secara berkala;
• batasi writable path;
• gunakan service account non-root;
• perketat sudoers;
• hapus credential dari file dan environment bila memungkinkan;
• patch package dan kernel sesuai lifecycle;
• gunakan systemd sandboxing;
• segmentasi host dan management plane;
• terapkan file integrity monitoring pada konfigurasi sensitif.

Cheat Sheet LinPEAS untuk Lab

# Jalankan normal
./linpeas.sh

# Jalankan melalui bash
bash linpeas.sh

# Simpan output
./linpeas.sh | tee linpeas-$(hostname)-$(date +%F).txt

# Identitas dan group
id
whoami
groups

# Sudo policy
sudo -l

# SUID files
find / -perm -4000 -type f 2>/dev/null

# Linux capabilities
getcap -r / 2>/dev/null

# Process enumeration
ps auxww

# Running services
systemctl --type=service --state=running

# Timers
systemctl list-timers --all

# Cron files
ls -la /etc/cron* 2>/dev/null

# Writable files in selected application paths
find /etc /opt /var/www -type f -writable 2>/dev/null

Command di atas tetap harus digunakan sesuai scope dan kapasitas host.

Best Practices untuk Red Team

Pahami Scope Lokal

Pastikan host, account, dan waktu pengujian tercatat.

Gunakan Prinsip Minimum Impact

Jika evidence konfigurasi sudah cukup, jangan melakukan perubahan.

Jangan Menjalankan sebagai Root Tanpa Alasan

Menjalankan enumeration sebagai root dapat mengubah hasil dan memperbesar dampak.

Simpan Evidence dengan Aman

Redact secret dan batasi akses file hasil scan.

Validasi Temuan Prioritas

Tidak semua warning LinPEAS layak menjadi finding.

Cleanup

Hapus script, output, dan file temporary sesuai RoE.

Hubungkan dengan Tool Lain

LinPEAS memberi snapshot. pspy membantu melihat process execution. GTFOBins membantu memahami risiko binary secara konseptual. Lynis membantu audit dan hardening. Gunakan masing-masing sesuai tujuan.

Best Practices untuk Blue Team

• buat baseline normal untuk service dan process;
• audit permission file secara berkala;
• review root-owned writable path;
• pantau perubahan sudoers, cron, systemd unit, dan capability;
• gunakan EDR atau auditd untuk process/file telemetry;
• deteksi sequence enumeration, bukan hanya nama tool;
• batasi akses ke secret dan rotasi ketika exposure terindikasi;
• dokumentasikan exception agar hasil audit tidak penuh false positive;
• lakukan retest setelah remediation.

Hubungan dengan Artikel Lain dalam Seri

Artikel ini melanjutkan konteks dari:

• #12 Evil-WinRM — remote administration dan identity boundary;
• #06 BloodHound — attack path dan privilege relationship;
• #07 Windows Credential Exposure — dampak credential yang bocor.

Setelah #13, kita akan masuk ke:

• #14 pspy — mengamati proses Linux secara real-time;
• #15 GTFOBins — memahami binary Linux yang dapat menjadi jalur risiko;
• #16 Chisel — tunneling, pivoting, dan segmentation.

Dengan begitu, LinPEAS tidak berdiri sendiri. Ia menjadi bagian dari workflow: enumerate → validate → observe → detect → harden.

Penutup

LinPEAS sangat berguna karena Linux privilege escalation jarang disebabkan oleh satu tombol ajaib. Sering kali masalahnya adalah gabungan dari permission yang longgar, service yang terlalu privileged, secret yang tertinggal, dan boundary yang tidak jelas.

Gunakan LinPEAS untuk mempercepat pengumpulan konteks, bukan untuk menggantikan analisis.

Pahami setiap temuan. Verifikasi dengan dampak minimum. Simpan evidence dengan aman. Lalu ubah output tersebut menjadi tindakan defensif yang konkret.

Karena tujuan assessment bukan sekadar menjawab:

“Bisa jadi root atau tidak?”

Pertanyaan yang lebih berguna adalah:

“Mengapa privilege boundary dapat ditembus, artifact apa yang tertinggal, dan kontrol apa yang harus diperbaiki?”

Itulah titik ketika cheat sheet mulai berubah menjadi security engineering.

Referensi Resmi

• LinPEAS — https://github.com/peass-ng/PEASS-ng/tree/master/linPEAS
• Linux man-pages — https://man7.org/linux/man-pages/
• sudo Manual — https://www.sudo.ws/docs/man/sudoers.man/
• systemd.exec — https://www.freedesktop.org/software/systemd/man/latest/systemd.exec.html
• systemd.service — https://www.freedesktop.org/software/systemd/man/latest/systemd.service.html
• Linux capabilities — https://man7.org/linux/man-pages/man7/capabilities.7.html
• MITRE ATT&CK, Exploitation for Privilege Escalation — https://attack.mitre.org/techniques/T1068/
• MITRE ATT&CK, Scheduled Task/Job — https://attack.mitre.org/techniques/T1053/
• CIS Linux Benchmarks — https://www.cisecurity.org/benchmark/distribution_independent_linux