Script-Kiddies im Live-Betrieb: Wenn die Phishing-API das Admin-Passwort frei Haus liefert

In der IT-Sicherheitswelt sprechen wir oft von hoch entwickelten, staatlich geförderten Angreifern (APT-Gruppen) und komplexen Verschleierungstaktiken. Die Realität auf den Servern da draußen sieht jedoch oft ganz anders aus.

Von der Daonware-Redaktion

In jüngster Vergangenheit bin ich auf eine aktive Phishing-Kampagne gestoßen, die ein Paradebeispiel für sogenanntes „Vibecoding“ und absolutes Script-Kiddie-Verhalten liefert. Durch eine gravierende Fehlkonstruktion in der API war es mir möglich, die gesamte Operation zu analysieren, die betroffenen Opfer zu warnen und die Infrastruktur in Zusammenarbeit mit dem Hoster dauerhaft vom Netz zu nehmen.

Schritt 1: Die Code-Analyse (Der programmierte Totalschaden)

Die Angreifer nutzen ein fertiges Baukasten-Phishing-Kit namens „Email Gen“ auf der Domain webmailglobal.com. Beim Blick auf die Administrations-Logik der Log-in-Seite (admin.html) offenbarte sich ein programmiertechnischer Totalschaden. Anstatt dass die eingegebenen Admin-Zugangsdaten sicher an den Server gesendet und dort serverseitig abgeglichen werden, passierte Folgendes:

Hier wird schnell klar, dass die „Entwickler“ dieses Kits das absolute Grundprinzip der Websicherheit – die Trennung von Client und Server – nicht verstanden haben:

form.addEventListener('submit', function (e) {
    e.preventDefault();
    var username = document.getElementById('admin-username').value.trim();
    var password = document.getElementById('admin-password').value;

    if (loginBtn) loginBtn.disabled = true;

    // Read password from db.json via api.php (works across all browsers)
    fetch('api.php')
        .then(function (r) { return r.json(); })
        .then(function (db) {
            var correctPassword = (db.settings && db.settings.password) ? db.settings.password : 'admin123';
            if (username === 'admin' && password === correctPassword) {
                localStorage.setItem(NS + 'admin', 'true');
                window.location.href = 'admin.html';
            } else {
                errorEl.textContent = 'Invalid username or password';
                ...

Die drei fatalsten Code-Schwächen:

• 1. Authentifizierung auf der falschen Seite (Client-Side Auth):
  Anstatt die eingegebenen Logindaten zur sichereren Prüfung an den Server zu senden, fordert die Zeile fetch('api.php') den Server auf, die gesamte Konfigurationsdatenbank an den Browser des Besuchers zu schicken. Der eigentliche Abgleich if (password == correctPassword) findet lokal im Browser statt. Wer die Seite aufruft, hat das Admin-Passwort also schon auf dem eigenen Rechner geladen, noch bevor ein einziges Zeichen eingetippt wird.
• 2. Der hartcodierte Fallback (admin123):
  Das Skript erhält einen permanenten Rettungsanker für den Angreifer: Sollte das Passwort in den Servereinstellungen nicht sauber definiert oder die Datenbank beschädigt sein, greift der Code automatisch auf den Standardwert admin123 zurück. Ein gefundenes Fressen für automatisierte Scanner.
• 3. Session-Management via LocalStorage:
  War das Passwort „korrekt“, wird der Zustand einfach lokal im Browser via localStorage.setItem(NS + 'admin', 'true') gespeichert und eine Weiterleitung auf admin.html ausgelöst. Keine verschlüsselten Cookies, keine Tokens, keine serverseitige Session-Validierung. Wer die admin.html direkt ansteuert oder den LocalStorage manuell manipuliert, marschiert im Zweifel einfach ungeprüft durch.

Schritt 2: Die API-Analyse (die nackten Daten der api.php)

Weil die api.php⁣ durch diese fetch()-Logik für jeden im Netz vollkommen offenlag, reichte ein einfacher Aufruf der URL im Browser, um den kompletten Systemzustand als rohen JSON-String auszulesen.

Um zu veranschaulichen, wie kinderleicht man an die sensibelsten Daten der Angreifer herankam, schauen wir uns die Struktur an – bereinigt um echte Nutzerdaten, um keine echten Identitäten zu gefährden:

{
   "pages": [
      {
         "id": "mpy9q7udgpq13gbjz",
         "email": "",
         "welcomeText": "Telekom Login",
         "subtitle": "Passwort eingeben",
         "template": "custom",
         "twoLayerLogin": false,
         "brandImage": null,
         "createdAt": "2026-06-03T16:15:58.261Z"
      }
   ],
   "captures": [
      {
         "id": "mpwsd1jul8a9jq16c",
         "email": "muster-opfer@gmx.de",
         "password": "Das_abgefangene_Passwort",
         "timestamp": "2026-06-03T13:19:48.077Z",
         "userAgent": "Mozilla/5.0 (Linux; Android 10; K) ... Mobile Safari/537.36",
         "seen": true
      }
   ],
   "settings": {
      "password": "Hier_stand_das_Admin_Passwort_im_Klartext",
      "notifyEmail": "n************k@gmail.com"
   }
}

Was uns diese API-Struktur verrät:

• Das Array "pages": Hier verwaltet das Kit die aktuell scharf geschalteten Phishing-Seiten. In diesem Fall handelt es sich um ein nachgebautes, zweistufiges „Telekom Login“-Design.
• Das Array "captures": Das digitale Sündenregister der Scammer. Sobald ein Opfer auf die Phishing-Seite hereinfiel, wurden die E-Mail, das Passwort im Klartext, der exakte Zeitstempel und der userAgent (Gerät und Browser des Opfers) hier ungefiltert hineingeschrieben. Besonders wichtig: Das Feld "seen": true verriet uns im späteren Verlauf, ob der Angreifer diesen spezifischen Datensatz bereits geöffnet und somit aktiv entwendet hatte.
• Das Objekt "settings": Der endgültige Identitäts-Kill für den Betreibern. Neben dem Admin-Passwort im Klartext hinterlegte das Script-Kiddie hier seine private Gmail-Adresse unter "notifyEmail". Das Kit war so programmiert, dass es bei jedem neuen Opfer eine Benachrichtigung dorthin schickte. Damit lag nicht nur die Beute offen, sondern auch der direkte Draht zum Täter.

Schritt 3: Forensische Analyse – Labor vs. Live-Betrieb

Um die Dynamik der Angreifer zu verstehen, musste ich tiefer in die Verzeichnisstruktur eintauchen. Dabei stieß ich auf zwei parallele Instanzen des Kits: /logone/ und /logtwo/. Durch die offene API-Schnittstelle konnte ich ein vollständiges Protokoll in Form einer CSV-Datei (emailgen_captures_2026-06-03.csv) sichern. Ein genauer Blick auf die dort hinterlegten Metadaten brachte die Wahrheit ans Licht:

Das Fazit dieser Instanz: Hier saß das Script-Kiddie an seinem Rechner und hat die Funktion des Phishing-Kits sowie die Weiterleitung an seine Gmail-Adresse mit erfundenen Daten getestet, um zu überprüfen, ob die gefälschten Webmail- und Telekom-Vorlagen wie gewünscht reagieren.

Der scharfe Live-Betrieb (/logtwo/)

Vollkommen anders stellte sich die Situation im Verzeichnis /logtwo/ dar. Hier war die Kampagne „in the wild“ – also scharfgeschaltet. Die Monotonie der Testumgebung brach hier komplett auf, da nun echte, organische Zugriffe protokolliert wurden.

Besonders ein Eintrag stach hervor: ein Zugriff am 3. Juni 2026 um 13:19 UTC. Das Opfer nutzte ein echtes Mobilgerät mit dem SamsungBrowser/30.0 auf einem Android-10-Betriebssystem. Ein Angreifer wechselt im Testlabor nicht mal eben mitten im Lauf auf ein physisches Samsung-Smartphone, um ein komplexes, plausibles GMX-Passwort einzugeben. Wie in der API-Analyse oben zu sehen, stand der Status dieses Eintrags bereits auf "seen": true. Das bedeutet: Gefahr im Verzug. Der Scammer hatte die Zugangsdaten bereits gesichtet und war im Begriff, das Konto zu übernehmen.

Schritt 4: Der digitale Gegenschlag (Incident Response)

Wenn ein System aktiv Schaden anrichtet, zählt jede Minute. Da das Admin-Panel durch die Fehler der Angreifer für mich vollkommen offenlag, beschloss ich, die gesamte Operation von innen heraus zu sabotieren.

1. Die Übernahme des Panels: Ich loggte mich in das Live-Dashboard unter /logtwo/admin.html ein, änderte das Admin-Passwort in eine unbrauchbare Zeichenfolge ab und überschrieb die notifyEmail des Angreifers mit Fantasiedaten (arsch@arsch.de). Ab diesem Moment war der Scammer aus seinem eigenen System ausgesperrt und „blind“ geschaltet – er erhielt keine Benachrichtigungen mehr über neue Eingaben.
2. Daten-Sanitierung: Die echten Zugangsdaten des GXM-Opfers wurden umgehend und vollständig aus der Live-Datenbank gelöscht, um dem Angreifer den permanenten Zugriff über das Web-Interfache zu entziehen.
3. Nachweis der Kontrolle: Um dem Scammer zu demonstrieren, dass sein System kompromittiert wurde, generierte ich über sein eigenes Tool eine neue Login-Page mit der unmissverständlichen Überschrift "THIS IS FAKE". Wenn der Angreifer die api.php oder das Backend aufrief, sah er sofort, dass er die Kontrolle verloren hatte.
4. Die Opfer-Warnung: Da ich die E-Mail-Adresse des betroffenen Nutzers sichern konnte, schicke ich sofort eine dringende, anonyme Warnmeldung über ein sicheres System heraus. Das Opfer wurde detailliert darüber informiert, dass seine Daten um 13:19 UTC auf webmailglobal.com abgefangen wurden, und aufgefordert, alle Passwörter sofort zu ändern. Damit erhielt die betroffene Person den entscheidenden Vorsprung, bevor der Scammer größeren Schaden anrichten konnte.

Schritt 5: „Cease and Desist“ und der finale Hoster-Takedown

Um die Kampagne endgültig zu beerdigen, reichte es nicht, nur das Panel zu sperren. Der Angreifer musste spüren, dass er aufgeflogen war, und der Server musste dauerhaft vom Netz genommen werden.

Zuerst schickte ich eine formelle, unmissverständliche Warnung (Cease and Desist) direkt an die entlarvte Gmail-Adresse des Scammers. Darin wurde ihm klipp und klar dargelegt, dass seine Infrastruktur dokumentiert, seine Opferdaten gelöscht und seine Identität kompromittiert wurden. Die Auswirkungen waren unmittelbar zu spüren: Sobald die E-Mail in seinem Postfach war, wurden alle anderen Aktivitäten und Angriffsversuche plötzlich eingestellt. Er hatte die Operation aus nackter Angst vor rechtlichen Konsequenzen eingefroren.

Den endgültigen Todesstoß versetzte der Kampagne jedoch der zuständige Webhoster. Ich übermittelte einen detaillierten Abuse-Report inklusive der Screenshots der Webseite direkt an das Missbrauchsteam von Hostinger.

Das Abuse-Team von Hostinger reagierte vorbildlich und zügig. Bereits am Morgen des 4. Juni 2026 erhielt ich die offizielle Bestätigung:

Übersetzt auf Deutsch: Sehr geehrter Beschwerdeführer, vielen Dank für Ihre Meldung. Nach Prüfung der Angelegenheit haben wir gemäß unseren Nutzungsbedingungen und den geltenden Gesetzen Maßnahmen in Bezug auf die gemeldeten Inhalte und/oder Aktivitäten ergriffen. Die aufgeführten Dienste wurden gesperrt.

Sehr geehrter Beschwerdeführer, vielen Dank für Ihre Meldung. Nach Prüfung der Angelegenheit haben wir gemäß unseren Nutzungsbedingungen und den geltenden Gesetzen Maßnahmen in Bezug auf die gemeldeten Inhalte und/oder Aktivitäten ergriffen. Die aufgeführten Dienste wurden gesperrt.

Mail vom 04.06.2026

Fazit: Lessons Learned für die Verteidigung

Dieser Fall zeigt auf spektakuläre Weise, wie die Realität im Bereich der Cyberkriminalität oft aussieht. Dank moderner KI-Assistenten ist heute jeder in der Lage, optisch ansprechende Login-Masken und Dashboards zusammenzuklicken („Vibecoding“). Wenn es jedoch an den fundamentalen Grundlagen von Client-Server-Architekturen und Websicherheit fehlt, nützt auch das schönste Interface nichts.

Für uns als Verteidiger zeigt diese Analyse: Hartnäckigkeit und der Blick in die Entwicklertools lohnen sich. Ein einziger genauer Blick auf eine schlampig programmierte API reichte aus, um eine aktive, bösartige Operation komplett kollabieren zu lassen und unschuldige Internetnutzer vor Identitätsdiebstahl zu schützen.