LAMPSecurity: CTF4

Einführung

Heute geht es um das LAMPSecurity CTF4, eine geile Anfänger-Box. Bevor ich schieße, brauche ich erstmal ein Ziel. Ich bin im lokalen Netzwerk (192.168.1.0/24) und werde einen schnellen Ping-Sweep mit netdiscover oder nmap werfen, Um aktive Geräte im Netzwerk zu finden.

netdiscover -r 192.168.232.0/24
# -r = Sagt netdiscover: "Durchsuche diesen IP-Bereich."
# oder
nmap -sn 192.168.232.0/24
# -sn = "Ping-Sweep" - fragt nur, wer online ist, ohne die Ports zu scannen

Und zack, wir haben 192.168.232.130 gefunden.

Auf diesen Ziel_ip führe ich ein Nmap-Scan durch.

nmap -A 192.168.232.130 -oN nmap_lampsec4.txt

Ich habe die Options -A verwendet. Die -A ist für OS-Erkennung, Versionserkennung, Standard-Scripts. Die Option -oN gibt die Ergebnisse als normale, lesbare Format.

Auf Basis des Nmap-Scans sind genau 3 Ports geöffnet (der Rest ist „gefiltert“ oder „closed“):

Port	Dienst	Version	Status
22/tcp	SSH	OpenSSH 4.3 (protocol 2.0)	🔓 Offen
25/tcp	SMTP	Sendmail 8.13.5/8.13.5	🔓 Offen
80/tcp	HTTP	Apache httpd 2.2.0 (Fedora)	🔓 Offen

Zusätzlich erwähnt der Scan:

631/tcp = closed (nicht offen, also irrelevant)
996 Ports wurden „gefiltert“ (d.h. sie antworten nicht – vermutlich durch eine Firewall geblockt)
Meine Angriffsfläche sind also SSH (22), Mail (25) und Webserver (80). Bei einem Pentest müssen wir jeden offenen Port genauer untersuchen und prüfen, ob der jeweilige Dienst sicher konfiguriert ist und mögliche Schwachstellen aufweist.

Port 22 – SSH

Dann schauen wir uns den SSH-Port (22) mal genauer an. Mein Scan hat gezeigt, dass hier OpenSSH 4.3 läuft. Das ist eine sehr alte Version, die wir uns genauer ansehen müssen.

Wie gehe ich vor, wenn ich SSH-Port (22) sehen?

Phase 1: Reconnaissance & Scanning & Enumeration

Bevor ich etwas angreife, muss ich wissen, was ich genau vor mir habe.

Ich versuche, das Banner abzugreifen -> der einfachste Weg: nc -vn 192.168.232.130 22

Das Ergebniss zeigt, dass Port 22 (SSH) ist offen und zeigt installierte OpenSSH-Version ist OpenSSH 4.3
Weitere Details kann ich auch mit Nmap anfragen -> Klar, mein erster Scan war schon gut aber ich kann jetzt noch spezifische Nmap-Scripts verwenden, z.B.:
- Unterstützte Algorithmen anzeigen:
  - nmap -p 22 –script ssh2-enum-algos 192.168.232.130
  - Das Script ssh2-enum-algos von Nmap sagt mir ganz einfach, welche Schlösser sind verbaut, also welche Verschlüsselungs-Algorithmen der Server unterstützt. Stell dir vor, du willst eine Tür aufschließen und es gibt viele verschiedene Schlüsseltypen:
    - Alte Schlüssel (z.B. DES) = leicht zu knacken -> Ich suche hier Exploits für diese Algorithmen
    - Moderne Schlüssel (z.B. AES-256) = schwer zu knacken
      Das ist wichtig, weil wenn der Server alte, unsichere Algorithmen unterstützt (wie cbc oder 3des), dann gibt es bekannte Angriffe, die diese Schwächen ausnutzen.
- Erlaubte Authentifizierungsmethoden prüfen:
  - nmap -p 22 –script ssh-auth-methods –script-args=“ssh.user=root“ 192.168.232.130
  - Dieses Script (ssh-auth-methods) prüft, welche Login-Methoden der Server für einen bestimmten Benutzer erlaubt. Ob Login mit Password erlaubt ist? oder mit Publik-Key?
  - Das ist wichtig zu wissen, weil:
    - Wenn Passwort-Authentifizierung erlaubt ist -> Brute-Force möglich (Hydra!)
    - Wenn NUR Public-Key erlaubt ist und Password-Authentifizierung deaktiviert ist -> Brute-Force sinnlos, weil ich den privaten Key brauche

Phase 2: Vulnerability Assessment

Hier kommt die alte Version ins Spiel.

Ich benutze dafür das SSH-audit. Das Tool (SSH-audit) prüft die Konfiguration auf unsichere Algorithmen und bekannte Schwachstellen.
- ssh-audit 192.168.232.130
- Das Tool verbindet sich mit dem SSH-Server und fragt nach SSH-Version, Unterstützende Algorithmen und bekannte Schwachstellen ab.
Dann suche ich nach öffentlichen Exploits übers Internet oder mit searchsploit.
- Die Version OpenSSH 4.3 ist sehr alt. Es gab dafür Gerüchte über Exploits, die sogar Root-Zugriff ermöglichen könnten.
  - searchsploit openssh 4.3

seachsploit durchsucht die lokale Exploit-Datenbank (also auf meiner Kali) nach bekannten Angriffen für diese Version.
Für mich sind die ersten 3 Exploits interessant, da OpenSSH-Version 4.3 in den angegebenen Versionsbereichen liegt. Username Enumeration wurde ich aber jetzt erstmal nicht machen. DOS auf gar keinen Fall 🙂
In searchsploit gibt es verschiedene Exploit-Typen, darunter:
– Remote -> Angriff über das Netzwerk möglich -> Das ist für mich Gold wert!
– Local -> Hier brauche ich bereits Zugang zum System -> Erst später relevant.
– Daniel Of Services (dos) -> Damit stürzt der Server ab -> nicht nützlich
– Priviledge Escalation -> Für höhere Rechte -> Auch erst später relevant.

Phase 3: Exploitation – Credential-Angriffe (Brute-Force)

Für mich ist das die wahrscheinlichste Methode, wenn es keine einfachen Exploits gibt. Ich probiere hier (wenn ausdrücklich erlaubt ist und der Server dadurch nicht überlastet wird) viele Kombinationen aus Benutzernamen und Passwörtern durch. Im besten Fall, machen ich erstmal Username Enumeration, dann kann ich das Passwort für die gefundene Usernamen bruteforcen.

Hydra -> Also der Klassiker!
Hier sind typische Befehle:

Der folgende Befehl testet das Passwort admin gegen eine Liste von Passwörtern.
- hydra -l admin -P /usr/share/wordlists/rockyou.txt ssh://192.168.232.130
Und das testet ein Standard-Passwort gegen eine Liste von Benutzern.
- hydra -L users.txt -p 123456 ssh://192.168.232.130
Hier ist die vollständige Suche -> für mich macht das aber wenig Sinn. Ich nutze das, wenn ich spezifische, kleine und gezielte Liste habe.
- hydra -L users.txt -P /usr/share/wordlists/rockyou.txt ssh://192.168.232.130
Hier noch weitere Optionen für Hydra:
- -vV : Zeigt jeden Versuch an (sehr nützlich, um zu sehen, was passiert).
- -t 1 : Verlangsamt den Angriff auf einen Thread, um Sperren (Rate Limiting) zu umgehen.
- -f : Stoppt den Angriff, sobald ein Login gefunden wurde.

Alternatives Tool für Hydra: Medusa

medusa -h 192.168.232.130 -u root -P /usr/share/wordlists/rockyou.txt -M ssh

Phase 4: Gaining Access – Zugang erhalten?

Sobald ich gültige Credentials gefunden habe, kann ich mich ganz normal per SSH verbinden:

ssh benutzername@192.168.232.130

Zusammenfassung für das Port 22

Schritt	Tool / Befehl	Ziel
1. Login-Check	`nmap -p 22 --script ssh-auth-methods 192.168.232.130`	Prüfen, ob Passwort-Login erlaubt ist (sonst ist Hydra sinnlos).
2. Exploit suchen	`searchsploit openssh 4.3`	Checken, ob es einen direkten Remote-Exploit gibt (meist Fehlanzeige).
3. Brute-Force(Laut)	`hydra -l admin -P /usr/share/wordlists/rockyou.txt ssh://192.168.232.130`	Nur wenn du einen User kennst und viel Zeit hast.

Port 25 (SMTP-Dienst)

Jetzt kümmere ich mich um Port 25. Mein Scan hat gezeigt, dass hier Sendmail 8.13.5 läuft. Das ist ein sehr alter Mail-Server.

SMTP-Dienst (Port 25) nimmt Nachrichten an und leitet sie weiter. Aber bei diesem alten Modell kann ich zwei Sachen machen:

User Enumeration -> Ich kann herausfinden, welche Benutzer (root, admin, etc.) auf dem System existieren. Ich frage hier den Server mit SMPT-Befehl (VRFY) nach ihnen fragen.
Ich prüfe die Version des Mailservers auf Schwachstellen -> mit Google oder searchsploit
- Version bestimmen -> bekannte Schwachstellen recherchieren -> prüfen, ob der Server davon betroffen ist.

Die Vorgehensweise ist hier ähnlich wie bei SSH. Ich beginne auch hier erstmal mit dem Sammeln von Informationen.

Phase 1: Reconnaissance & Scanning & Enumeration

Hier versuche ich, gültige Benutzernamen für das System zu finden. Diese Namen brauche ich später vielleicht für den SSH-Zugriff oder für weitere gezielte Angriffe.

Für mich ist der einfachste Weg mit netcat (nc), damit ich sehe, wie der Server reagiert. Ich verbinde mich manuell mit dem SMTP-Dienst. Der Server soll mir einen Banner senden.

nc -nv 192.168.232.130 25

Dann gebe ich folgende Befehle ein und schaue, was der Server antwortet:

VRFY root
- Wenn die Antwort 250 oder 2.0.0 ist -> d.h. der Benutzer existiert.
- Antwortet der Server mit 550 -> heißt das, der User existiert nicht.
EXPN root ->

Methode B wäre noch mit smtp-user-enum-Tool
Dieses Tool macht die Arbeit für dich und probiert eine ganze Liste von Benutzernamen durch. Versuche gezielte Benutzernamen zu verwenden, um die Server Überlastung zu vermeiden.

# Mit der VRFY-Methode
smtp-user-enum -M VRFY -U /usr/share/wordlists/metasploit/unix_users.txt -t 192.168.232.130

# Mit der RCPT-Methode (oft zuverlässiger, weil weniger gesperrt)
smtp-user-enum -M RCPT -U /usr/share/wordlists/metasploit/unix_users.txt -t 192.168.232.130 -D localhost

-M VRFY: Definiert die Methode .
-U <datei>: Die Wordlist mit den Benutzernamen, die getestet werden sollen
-t <ip>: Die Ziel-IP .
-D <domain>: Hängt eine Domain an, um vollständige E-Mail-Adressen zu testen (wichtig für die RCPT TO-Methode) .

Methode C dann mit Nmap Scripts

# Unterstützte Befehle anzeigen. z.B. VRFY, EXPN, etc..
nmap -p 25 --script smtp-commands 192.168.232.130
# Das Script fragt den Server mit `EHLO` und `HELP` ab, was er kann. Wenn in der Ausgabe Befehle wie `VRFY` oder `EXPN` auftauchen, haben wir ein sehr großes Problem (für den Server)

# Die Standard-Enumeration
nmap -p 25 --script smtp-enum-users 192.168.232.130

# Mit eigener Wordlist
nmap -p 25 --script smtp-enum-users --script-args smtp-enum-users.methods={VRFY,EXPN,RCPT},userdb=/usr/share/wordlists/metasploit/unix_users.txt 192.168.232.130

Methode D auch relative einfach mit Metasploit

msfconsole
use auxiliary/scanner/smtp/smtp_enum
set RHOSTS 192.168.232.130
set USER_FILE /usr/share/wordlists/metasploit/unix_users.txt
run

Also wenn ich einen Benutzernamen wie root, admin oder postmaster finde, notiere ich ihn mir. Das ist ein großer Erfolg!

Phase 2: Vulnerability Assessment

Jetzt kommt der spannende Teil für mich. Die Version Sendmail 8.13.5 ist erstmal uralt, daher suche ich direkt nach einem Exploit. Ich beginne mit searchsploit und suche in der lokalen Exploit-Datenbank.

searchsploit sendmail 8.13.5

Dann schaue ich mir den gefundenen Exploit genau an.

# Exploit anzeigen
searchsploit -x linux/dos/2051.py

# Exploit in dein Arbeitsverzeichnis kopieren
searchsploit -m linux/dos/2051.py

Ich lese die Kommentare am Anfang der Datei. Dort steht oft, wie man ihn benutzt und für welche Systeme er funktioniert. Diese Exploits sind alte Proof-of-Concepts.

Phase 3: Exploitation – Credential-Angriffe (Brute-Force)

Zuletzt probiere ich den Exploit aus. -> wichtig hier, dass ich mit erstmal den gasamten Exploit-Code anschaue bevor ich ihn ausführe, damit den Dienst oder das gesamte System nicht abstürzt.

In diesem Fall, werde ich diesen Exploit liegen lassen, weil er bringt den Server nur zum Absturz, gibt mir aber KEINEN Zugang

Zusammenfassung für das Port 25

Schritt	Tool / Befehl	Ziel
1. Benutzer finden	`smtp-user-enum -M VRFY -U users.txt -t 192.168.232.130`	Gültige Benutzernamen finden (für später).
2. Exploit suchen	`searchsploit sendmail 8.13.5`	Bestätigen, dass es einen öffentlichen Exploit gibt.
3. Exploit ausführen	`python exploit.py 192.168.232.130`	Versuchen, eine Root-Shell zu bekommen.

Port 80 (http)

Jetzt nehme ich mir Port 80 (HTTP) genauso detaillt vor wie ich es bei SSH und SMTP gemacht habe.

Da der Server eine uralte Apache 2.2.0 ist und die robots.txt fünf verdächtige Ordner verrät, haben wir hier eine riesige Angriffsfläche.

Phase 1: Reconnaissance & Scanning & Enumeration

Der „Mensch“-Check

Bevor ich hier Tools loslasse, schaue ich mir die Anwendung zuerst einmal manuell an.

Ich öffene den Browser und rufe ich http://ziel_ip:80 auf.
Ich schau mir das Design an. Oft steht da „Powered by XYZ“. Welches CMS (z.B. Drupal, WordPress) oder welche selbstgeschriebene App das ist.
Ich klicke spontan auf die einzelnen Tabs und gucke die Web-Anwendung an.
Ich suche im Quelltext nach Kommentaren oder irgendwas verdächtiges. (Rechtsklick -> Seitenquelltext anzeigen)
Mit Strg+F suche ich nach password, admin, mysql, config oder todo.
Ich schaue mir noch die robots.txt an. Da steht meist drin, welche Ordner der Admin verstecken will. Ich sehe schon 5 Ordner und für mich sind /sql und /admin sehr interessant. -> Ich rufe aber die 5 verbotenen Ordner manuell auf
- Standardmäßig, wenn der Admin vergessen hat, eine Indexseite (index.html) in den Ordner zu legen, zeigt Apache mir den gesamten Ordner-Inhalt an! Dann sehe ich sofort Dateien wie config.inc oder database.sql.

Technologien erkennen, Verzeichnisse & Dateien finden und einfache Scan mit Nikto

Technologien erkennen
Als erstes finde ich heraus, welche Technologien (CMS, Frameworks, Bibliotheken) verwendet werden. Das hilft mir, gezielt nach Exploits zu suchen. Dafür verwende ich auf dem Browser wappalyzer (Browser-Plugin) oder auf meinem Kali whatweb

whatweb -a 3 http://192.168.232.130

Whatweb zeigt mir, ob der Server z.B. PHP-Version 5.x oder ein bestimmtes Framework nutzt. Falls ich da alter Versionen erkenne, prüfe ich, ob dafür bekannte Schwachstellen oder Exploits existieren und ich notiere mir diese infos für weitere Angriffe im Pentest.

Dann lege ich los mit Verzeichnisse & Dateien finden
Hier kommt das Tool Gobuster ins Spiel. Ich verwende gerne Gobuster und Fuff. In diesem Szenario werde ich jetzt Gobuster, damit ich versteckte Ordner oder Dateien finden kann, die für mich interessant sein könnten.

gobuster dir -u http://192.168.232.130 -w /usr/share/wordlists/dirb/common.txt -x php,txt,html,bak,old,inc,sql -t 10

dir: Sagt Gobuster, dass es Ordner und Dateien suchen soll.
-w: Diese Option ist für mein Wordlist. Hier verwende ich common.txt, weil sie klein aber fein ist. Die directory-list-2.3-medium.txt enthält noch mehr. Dadurch kann ich zwar mehr Verzeichnisse und Dateien finden, die Suche dauert aber länger und erzeugt mehr Anfragen an den Server.
-x php,txt,html,bak,old,inc,sql -> Aus meiner Sicht ist das wichtig, wenn nicht der wichtigste Teil!
Der Server zeigt mir vielleicht nicht den Ordner /admin/ an, aber vielleicht gibt es eine Datei namens /admin.php oder /config.inc.bak.
-t 10: 10 Verbindungen bzw. Anfragen an den Server gleichzeitig senden.

Ich habe jetzt diese folgende Pfand, die für mich wichtig sind:

http://192.168.232.130/admin/
http://192.168.232.130/conf/
http://192.168.232.130/sql/ 
http://192.168.232.130/mail/

Einfache alternative für Gobuster ist dirb:

dirb http://192.168.232.130

Last but not least, starte ich nikto für einfache automatisches Schwachstellen-Scan

nikto -h http://192.168.232.130 -ssl -port 80

Ich lese die Ausgabe genau

Rote oder gelbe Meldungen mit OSVDB oder CVE.
Ich suche auch speziell nach /cgi-bin/, weil dort CGI-Skripte liegen können. -> bei Apache 2.2.0 könnte die bekannte Shellshock-Schwachstelle vorhanden sein.
Wenn Nikto sagt: "HTTP TRACE method is active" – das ist ein Informations-Leak, den wir später ausnutzen können.

Phase 2: Vulnerability Assessment

Jetzt kommt der Moment, in dem meine gesammelten Infos (Apache 2.2.0 + PHP 5.x + Ordner /mail/ oder /admin/) zusammenspielen.

Ich suche mit Searchsploit nach öffentlichen Schwachstellen
- # Searchsploit
  searchsploit apache 2.2.0
  searchsploit squirrelmail -> unter /mail/ gefunden
  searchsploit php 5.2
Was noch wichtig ist: die robots.txt sagt ganz klar /conf/ und /sql/. Das sind Konfigurations- und Datenbank-Ordner!
- gobuster dir -u http://192.168.232.130/admin/ -w /usr/share/wordlists/dirb/common.txt -x txt,inc,php,bak

Das ist mir wichtig. Ich kann dort eine Datei wie database.inc oder config.inc.bak finden. Oft stehen da Datenbank-Benutzername und Passwort IM KLARTEXT drin.

gobuster dir -u http://192.168.232.130/sql/ -w /usr/share/wordlists/dirb/common.txt -x sql,backup,old

Hier kann ich eine .sql-Datei finde. Das ist ein Datenbank-Dump. Dort stehen oft Admin-Hashes oder sogar echte Passwörter drin.

Phase 3: Exploitation

Ich starte jetzt mit dem Testen der Webanwendung. Ich schaue mir zum Beispiel Login-Felder, Suchfelder und andere Eingabemöglichkeiten auf der Webseite genauer an. Dann teste ich, ob diese Eingabe für SQLi, XSS, SSRF, SSTI, etc anfällig sind.

Beispiel:
Durch das Durchsuchen auf der WEbseite, sehe ich ein Tab „Blog“, da ist ein der Folgende vollständig url:

http://192.168.232.130/index.html?page=blog&title=Blog&id=2

Für mich heißt id=2, dass der Server eine Zahl aus der URL nimmt und in die Datenbank schickt, um den Blogartikel zu holen. Wenn der Programmierer schöne Augen hat, kann ich hier nicht nur nach der 2 fragen, sondern es könnte hier eine SQL-Injection-Schwachstelle vorhanden sein.

Ich mache ich, was jeder Pentester als erstes macht und zwar ich baue einen Fehler mit ' ein.

http://192.168.232.130/index.html?page=blog&title=Blog&id=2'

Wenn ich statt 2 zum Beispiel 2' eingebe, kann die SQL-Abfrage kaputtgehen. Erscheint danach ein SQL-Fehler, ist das ein Hinweis darauf, dass meine Eingabe die Datenbankabfrage beeinflusst. In diesem Fallkann ich die Schwachstelle anschließend entweder manuell über die URL weiter untersuchen oder dafür ein Tool wie sqlmap verwenden:

sqlmap -u "http://192.168.232.130/index.html?page=blog&title=Blog&id=2" --dbs --batch
- -dbs Zeig mir alle Datenbanken, die es auf diesem Server gibt
- -dbs Der „Keine-Fragen-stellen“-Modus. SQLMap fragt sonst dauernd „Soll ich das testen? Soll ich das umgehen? und mit --batch sagt er einfach „Ja, mach alles!“

Geile Sache! Mein SQLMap-Scan war erfolgreich. Ich habe die Schwachstelle gefunden und die Datenbanken aufgelistet. Ich lege mit den unteren SQLMap-Befehlen los.

SQLMap-Befehle

# Alle Datenbanken auslesen
sqlmap -u "http://192.168.232.130/index.html?page=blog&title=Blog&id=2" --dbs --batch

# In eine bestimmte Datenbank reinspicken und zeigt ihre Tabellen an
sqlmap -u "http://192.168.232.130/index.html?page=blog&title=Blog&id=2" -D ehks --tables --dump --batch

# gezielt die Tabelle `user` auswählen und zeigt ihre Inhalte
sqlmap -u "http://192.168.232.130/index.html?page=blog&title=Blog&id=2" -D ehks -T user --dump

Glück gehabt! Die Passwörter sind so schwach, dass SQLMap sie direkt geknackt hat.

Da ich jetzt den Benutzername und sein Passwort habe, versuche ich mich einfach per SSH einzuloggen.

ssh dstevens@192.168.232.130

somit habe ich jetzt eine normale Shell als Benutzer dstevens. Ich möchte aber Root sein 🙂

Priviledge Escalation

Der erste Befehl, den ich immer eingebe, ist:

sudo -l

sudo -l fragt den Server: „Hey, was darf ich eigentlich mit meinem Benutzer dstevens alles als Administrator (Root) ausführen?“

Und jetzt kommt der absolut dümmste Admin-Fehler aller Zeiten:

Das bedeutet ganz einfach: „Du, mein lieber dstevens, du darfst buchstäblich JEDEN BEFEHL auf diesem ganzen Rechner als Root ausführen. Keine Einschränkungen!“

Das ist so, als würdest du dem Hausmeister einen Schlüssel geben, der alle Türen im ganzen Universum aufschließt.

Also gebe ich den letzten, tödlichen Befehl ein:

sudo su

Da wir das Passwort nicht erneut eingeben müssen (weil wir es gerade schon bei SSH eingegeben haben), wechselt die Shell sofort zu root. Der Prompt ändert sich von $ zu #. Game over für die Box, wir haben den kompletten Server übernommen!

Zusammenfassung für das Port 80

Schritt	Aktion	Tool / Befehl	Warum?
1	Robots.txt-Ordner manuell öffnen	Browser	Ordner-Strukturen entdecken
2	Quelltext nach Kommentaren durchsuchen	`Strg+U` im Browser	Versteckte Pfade finden
3	Standard-Verzeichnisse brute-forcen	`gobuster -x php,bak,old,...`	Backup-Dateien & Admin-Panels finden
4	Schwachstellen-Scan	`nikto -h 192.168.232.130`	Automatisch CVE-Lücken finden
5	Exploit-Datenbank checken	`searchsploit apache 2.2.0`	Fertige Angriffs-Codes nutzen
6	`/conf/` und `/sql/` durchsuchen	`gobuster` auf die Unterordner	KREDENTIALS finden (für SSH!)
7	Web-Applikation testen	`'` (Anführungszeichen) in Eingabefelder	SQL-Injection prüfen

Wichtig: In der Webanwendung gibt es noch deutlich mehr zu testen. Diese Vorgehensweise soll jedoch nur zeigen, wie ein Penetrationstest durchgeführt wird.

ALAKEEL

LAMPSecurity: CTF4

Einführung

Port 22 – SSH

Phase 1: Reconnaissance & Scanning & Enumeration

Phase 2: Vulnerability Assessment

Phase 3: Exploitation – Credential-Angriffe (Brute-Force)

Phase 4: Gaining Access – Zugang erhalten?

Zusammenfassung für das Port 22

Port 25 (SMTP-Dienst)

Phase 1: Reconnaissance & Scanning & Enumeration

Phase 2: Vulnerability Assessment

Phase 3: Exploitation – Credential-Angriffe (Brute-Force)

Zusammenfassung für das Port 25

Port 80 (http)

Phase 1: Reconnaissance & Scanning & Enumeration

Der „Mensch“-Check

Technologien erkennen, Verzeichnisse & Dateien finden und einfache Scan mit Nikto

Phase 2: Vulnerability Assessment

Phase 3: Exploitation

Priviledge Escalation

Zusammenfassung für das Port 80

ALAKEEL