Ravindra BagaleCourses & study guides

26. Privilege Escalation

26.7 Red vs Blue, Project and Real Incidents

Chala mitrano, sudo -l, SUID, cron, linPEAS, least privilege – aata Purple Team loop. Red lab madhe low-priv foothold nantar ONE safe misconfig ne root dakhavto; Blue careful sudoers, unnecessary SUID strip, patch (sudo yum update), non-root service accounts ani unexpected uid=0 shells audit karto. Tumhi Sahyadri Traders style OWN Metasploitable/.20 kiwa weak lab user madhe build → hack → fix karun Purple report liha. Escalation awareness; fix + prove = career. Samjla ka? Dusryacha server – kadhi nahi.

Red Team vs Blue Team – privilege escalation

Red team (attacker) does Blue team (defender) detects / stops
After foothold: id, sudo -l, uname -a Least privilege everywhere; service accounts never run as root
find / -​perm -​4000 -​type f 2>/​dev/​null (SUID list) Strip unnecessary SUID bits; inventory allowed SUID set
Abuse planted sudo NOPASSWD for shell/editor/find (GTFOBins-style awareness) Careful sudoers: no NOPASSWD for shells, editors, interpreters, find, nmap
Writable cron script that root runs Cron scripts owned root, mode 755/644, not world-writable
linPEAS / LinEnum highlights (read red/yellow; confirm manually) Patch OS: sudo yum update; close known local CVEs
Kernel / local CVE awareness (name only – no 0-day recipes) Patch SLA; monitor unexpected uid=0 shells in auth/audit logs

Defender chi simple checklist: least privilege → tight sudoers (no shell/editor NOPASSWD) → minimal SUID → root-owned cron → sudo yum update → non-root services → prove sudo -l / SUID list is clean. Enumeration Kali/lab shell var; bachav sudoers + patch Blue var. Interview madhe "I got root" peksha "I found a sudo misconfig, got a lab root shell, then fixed sudoers/SUID and re-proved the path was gone" jast strong.

# OWN lab only – Kali 192.168.56.10 → Metasploitable 192.168.56.20 (or your OWN weak lab user)
mkdir -p ~/labs/sahyadri-privesc
# After you already have a low-priv shell on .20 (earlier chapters):
id
sudo -l
find / -perm -4000 -type f 2>/dev/null | tee ~/labs/sahyadri-privesc/suid-before.txt
# If YOU planted a safe lab sudo rule (example idea only – on YOUR VM):
#   user ALL=(root) NOPASSWD: /usr/bin/find
# Demo ONE path you control (do NOT paste kernel 0-day recipes):
#   sudo find . -exec /bin/sh \; -quit    # lab misconfig you planted – then exit
# Blue fix on the same OWN host (Amazon Linux style helpers use yum/service):
#   sudo visudo   # remove NOPASSWD for shells/editors/find; keep only needed commands
#   sudo chmod u-s /path/to/unnecessary-suid-binary   # only after you confirm it is not required
#   sudo yum update
#   sudo service <web> status   # confirm app runs as non-root
# Re-verify as the same low-priv user:
sudo -l
find / -perm -4000 -type f 2>/dev/null | tee ~/labs/sahyadri-privesc/suid-after.txt
# Unexpected root shells – Blue note (SOC later): watch auth.log / audit for uid=0

Ravindra Bagale's Tip

Students pahile kernel exploit Google kartat ani sudo -l visartat – motha waste. Dusri chuk: GTFOBins chi full weaponized recipe notebook madhe paste karun "I hacked root" mhanne, pan Blue fix nahi. Rule: enumerate → ONE safe lab path you planted or already know on Metasploitable → root evidence → FIX sudoers/SUID/permissions same day → re-prove path closed. Escalation chapter = least-privilege chapter. Ghabru naka, practice ne yetay.

Lab

Metasploitable 192.168.56.20 (kiwa swatahchi lab VM) var low-priv shell ghyayla. sudo -l, SUID list, cron writable check, linPEAS highlights – notes ~/labs/sahyadri-privesc/. Ekach safe path choose kara (planted sudo misconfig OR known Metasploitable local misconfig from earlier labs). Root dakhavla – mag sudoers/SUID/permissions FIX karun punha sudo -l / SUID compare. Kernel 0-day PoC paste naka. Public/internet targets nahi.

Project: Build it, hack it, fix it

Build: For fictional Sahyadri Traders (Pune) on host-only Metasploitable 192.168.56.20 or a deliberately weak user on a VM you own:

  1. Confirm low-priv foothold (shell from earlier chapters) – record id and groups
  2. Optional: on YOUR helper VM only, plant one safe sudo misconfig (e.g. NOPASSWD for /usr/bin/find) that you will remove the same day
  3. Ethics card: host-only / OWN VM only; no internet targets; no kernel exploit PoCs pasted into notes for others to misuse

Hack (lab awareness – OWN systems only): From Kali 192.168.56.10 (or local shell on the target):

  • Enumerate: sudo -l, SUID find, cron writables, linPEAS highlights (read, then confirm manually)
  • Demonstrate ONE safe path to a root shell (planted sudo misconfig, or a known Metasploitable local misconfig already taught) – screenshot/id as root
  • Name GTFOBins / SUID concepts in the report; do not paste weaponized kernel 0-day recipes

Do not attack third-party servers, do not leave NOPASSWD shell rules overnight, do not publish exploit PoCs.

Fix:

  • Edit sudoers (sudo visudo): remove NOPASSWD for shells, editors, interpreters, find, nmap
  • Strip unnecessary SUID bits; fix world-writable cron scripts (root-owned, correct mode)
  • sudo yum update on Amazon Linux helpers you own; keep service accounts non-root (ps aux check)
  • Document Blue monitoring: alert on unexpected uid=0 interactive shells

Re-verify: Same low-priv user – sudo -l no longer offers the abuse path; SUID before/after lists differ; id stays non-root for that path. 1-page Purple report for owner Shraddha: finding → risk → sudoers/SUID/patch fix → evidence. Peer-review with Amir / Ravina. IT Act: only systems you own or are authorised to test.

Real incident: Dirty COW – CVE-2016-5195 (2016)

In 2016, researchers publicly disclosed Dirty COW (CVE-2016-5195), a race condition in the Linux kernel's copy-on-write memory handling. A local unprivileged user on an affected unpatched kernel could, in reported cases, gain write access to read-only memory mappings and escalate to root. Weakness: a kernel memory-management bug reachable by any local account, so a low-priv foothold became full compromise until patches landed. What would have reduced it: timely kernel patches (sudo yum update / vendor advisories), least privilege so fewer untrusted local users exist, and monitoring for unexpected root shells after a foothold. Lab lesson: enumeration finds misconfigs first; kernel CVEs remind Blue that patching closes paths no sudoers tweak can fully replace. Source: CVE-2016-5195 / dirtycow.ninja and major Linux-vendor advisories (2016); verify current summaries.

Real incident: Baron Samedit – sudo CVE-2021-3156 (2021)

In 2021, Qualys publicly disclosed Baron Samedit (CVE-2021-3156), a heap-based buffer overflow in sudo when processing certain command-line arguments (the famous sudoedit -s class trigger in reporting). On many default Linux installs, a local user could obtain root. Weakness: a critical, widely installed setuid helper (sudo) with a memory-safety bug – "we use sudo carefully" was not enough until the package was patched. What would have reduced it: rapid sudo package updates from the vendor, inventory of sudo versions across servers, least privilege (fewer local accounts), and change control that does not delay security patches. Lab lesson: your Sahyadri project fixes misconfig and keeps sudo patched – Blue answers both. Source: Qualys Baron Samedit / CVE-2021-3156 advisory and vendor sudo patches (2021); verify current summaries.

Interview model (clean English): "After a low-privilege lab foothold I enumerate with sudo -l, SUID finds and linPEAS highlights. I demonstrate one safe misconfiguration path to root on my own Metasploitable or lab VM, then I fix sudoers and SUID permissions, patch with yum, and re-prove the path is closed."

Thodkyaat: escalation shika, pan least privilege + careful sudoers + patch shika. Aata pudhe social engineering – mansachi fasavnuk. Chala pudhe, mitrano!

Thodkyaat sangaycha tar

  • Privilege escalation turns a limited foothold into full control; vertical = higher rights, horizontal = another user's access.
  • Enumerate first: sudo -l, SUID binaries, cron jobs, writable files, kernel version, history.
  • Common Linux paths: sudo misconfig, SUID abuse (GTFOBins), writable cron scripts, kernel exploits (riskiest).
  • linPEAS/LinEnum automate enumeration; read the red/yellow highlights, then confirm manually.
  • Windows uses the same idea with different weaknesses (WinPEAS).
  • Defend with least privilege, careful sudo, minimal SUID, correct permissions, patching and monitoring.

Samjla ka? Root milvaycha ani ti shakyata band karaychi – donhi kalale. Pudhchya chapter madhe manasachi fasavnuk – social engineering ani tyachi awareness. Chala pudhe, mitrano!