Einleitung: Die Evolution des Phishings beim Gaming und der BitB-Vektor
Über ein Jahrzehnt lang basierten Phishing-Angriffe auf PC-Gamer – insbesondere auf Nutzer von Steam, Epic Games und Discord – auf leicht erkennbaren Täuschungsmustern: Tippfehler in Domainnamen (wie staemcommunitly.com), unverschlüsselte HTTP-Verbindungen und optisch minderwertige Nachbildungen von Login-Portalen. Sicherheitsbewusste Spieler verinnerlichten eine universelle Grundregel: Vor der Eingabe von Anmeldedaten stets die Adresszeile des Browsers auf die exakte Domain und das grüne SSL-Schlosssymbol überprüfen.
Die organisierte Cyberkriminalität im Gaming-Sektor hat diese Hürde jedoch überwunden. Mit dem Aufkommen von Browser-in-the-Browser-Phishing (BitB) wurde die klassische Sichtprüfung der Adresszeile wirkungslos. Bei einem BitB-Angriff wird das Opfer nicht auf eine externe verdächtige Domain weitergeleitet. Stattdessen rendert die manipulierte Website direkt im Document Object Model (DOM) ein pixelgenau nachgebildetes Betriebssystemfenster.
Dieses simulierte Fenster verfügt über eine gefälschte Adressleiste mit der Anzeige https://steamcommunity.com, ein scheinbar gültiges SSL-Schlosssymbol und die gewohnten Fenster-Schaltflächen (Minimieren, Maximieren, Schließen). In Kombination mit serverseitigen Browser-in-the-Middle-Relays (BitM), die auf Reverse-Proxy-Architekturen basieren, umgeht dieser Angriff selbst den mobilen Steam-Guard-Authenticator (Zwei-Faktor-Authentifizierung), fängt autorisierte Session-Cookies ab und leert Spielinventare vollautomatisiert innerhalb weniger Sekunden.
Technische Anatomie des BitB-Angriffs: DOM-Simulation und Reverse-Proxy-Relays
Der BitB-Angriff vereint eine täuschend echte clientseitige Benutzeroberflächen-Simulation mit serverseitiger Datenweiterleitung in Echtzeit.
[Browser-Viewport des Opfers: Phishing-Website "cs2-tournament-bracket.com"]
│
├─► [Simulierter BitB-Fenster-Container (DOM-Knoten [div])]
│ ├── Gefälschte Titelleiste und OS-Fenster-Bedienelemente
│ └── Gefälschte statische Adressleiste: "https://steamcommunity.com/openid/login"
│
└─► [Eingebettetes Iframe / Login-Formular / WebSocket-Relay]
│
▼ (Echtzeit-Erfassung von Zugangsdaten und Steam-Guard-Code)
[Reverse-Proxy-Server des Angreifers (z. B. Evilginx oder Muraena)]
│
▼ (Leitet gültige Anmeldedaten an offizielle Valve-Server weiter)
[Offizieller Steam-Authentifizierungsendpunkt (valve / steamcommunity.com)]
│
▼ (Valve stellt authentifizierte Session-Cookies aus: steamLoginSecure, sessionid)
[Angreifer fängt Cookies ab -> Vollautomatisiertes Leeren des Inventars und API-Kapern]
Die clientseitige Illusion: Fenster-Simulation im DOM
Bei einem regulären Steam-OpenID-Verfahren nutzt die Drittanbieter-Website den JavaScript-Befehl window.open(), um das Betriebssystem anzuweisen, ein echtes, eigenständiges Browser-Unterfenster zu öffnen, dessen Adressleiste vom Betriebssystem selbst gerendert wird.
Bei einem BitB-Angriff wird dagegen kein neuer Betriebssystemprozess erzeugt:
- Der modale Container: Die Webseite generiert über CSS-Eigenschaften (
position: fixedoderabsolute) einen übergeordnetendiv-Block, der exakt wie ein Desktop-Fenster formatiert ist. - Klonen der Browser-Leiste: Der Angreifer baut Navigationsschaltflächen, Ladesymbole und ein gefälschtes URL-Feld mit dem Text
https://steamcommunity.comaus SVG-Grafiken und CSS-Typografie nach. Diese Zeile ist in Wahrheit lediglich ein uneditierbares Textfeld auf der Webseite. - Dynamische Plattformanpassung: Moderne BitB-Frameworks werten
navigator.userAgentaus. Sie erkennen das Betriebssystem (Windows 10/11, macOS, Linux) sowie die Browser-Engine des Opfers und passen Titelleiste, Schriftarten und Schließen-Schaltflächen passgenau an die gewohnte Desktop-Optik an.
Die serverseitige Erfassung: Reverse-Proxy und 2FA-Bypass
Sobald der Nutzer seine Steam-Zugangsdaten und den mobilen Steam-Guard-Code in die Maske eingibt:
- Aushebelung der Zwei-Faktor-Authentifizierung: Einmalkennwörter (TOTP) basieren darauf, dass Angreifer den 30 Sekunden gültigen Code nicht erraten können. Bei einem Reverse-Proxy gibt das Opfer diesen Code jedoch selbst ein. Der Server des Angreifers leitet Nutzername, Passwort und Einmalcode binnen Millisekunden an Valves offizielle Authentifizierungs-API weiter.
- Abfangen hochprivilegierter Session-Cookies: Nach erfolgreicher Bestätigung sendet Valve die Authentifizierungs-Cookies
steamLoginSecureundsessionidzurück. Der Reverse-Proxy speichert diese Werte in seiner Datenbank ab, bevor er das Opfer auf eine beliebige Folgeseite leitet. - Vollautomatisches Session-Hijacking: Mit dem Cookie
steamLoginSecurebenötigt der Angreifer kein Passwort mehr. Ein automatisierter Headless-Browser loggt sich direkt in die Session ein, widerruft vorhandene API-Schlüssel, generiert einen bösartigen Steam-Web-API-Key, transferiert wertvolle CS2- oder Dota-Skins auf Strohmann-Accounts und versendet den Phishing-Link an sämtliche Kontakte der Freundesliste.
Warum visuelle Prüfungen versagen und technische Erkennungsmethoden
Da die imitierte Adresszeile für das menschliche Auge nicht von einer echten zu unterscheiden ist, müssen Spieler strukturelle Funktionstests anwenden.
1. Der Viewport-Ziehtest (Physikalische Fenstergrenzen)
Der schnellste und zuverlässigste Praxistest ist der Versuch, das Anmeldefenster über den Rand des Browsers hinaus zu ziehen:
- Echtes Fenster: Ein eigenständiges OS-Fenster kann beliebig über den Desktop, an den Bildschirmrand oder auf einen Zweitmonitor verschoben werden.
- BitB-Phishing-Fenster: Da es sich lediglich um ein HTML-Element der aktuellen Webseite handelt, kann es den Anzeigebereich (Viewport) des Browsers nicht verlassen. Beim Ziehen an den Rand stößt es an oder wird durch Container-Grenzen (
overflow: hidden) abgeschnitten.
2. Prüfung über Passwort-Manager
Seriöse Passwort-Manager (wie Bitwarden, 1Password oder die browserintegrierte Passwortverwaltung) verlassen sich niemals auf Textinhalte der Website, sondern ermitteln die Herkunft anhand der kryptografischen Domänenprüfung (window.location.origin):
- Auf einer echten Steam-Login-Seite erkennt der Passwort-Manager die Domain
steamcommunity.comund bietet gespeicherte Logins an. - Im BitB-Fenster erkennt der Manager die tatsächliche Herkunftsdomain der Phishing-Seite (z. B.
fake-turnier.org). Aufgrund der abweichenden Domain verweigert der Passwort-Manager das automatische Ausfüllen strikt. - Grundregel: Reagiert ein Passwort-Manager auf einer gewohnten Login-Seite plötzlich nicht und schlägt keine Zugangsdaten vor, handelt es sich mit nahezu absoluter Sicherheit um ein eingebettetes Phishing-Element.
3. DOM-Inspektion per Entwicklerwerkzeuge
Das Drücken der Taste F12 oder ein Rechtsklick auf die angebliche Adresszeile mit anschließender Auswahl von Element untersuchen entlarvt die Fälschung sofort:
- Die Adressleiste eines echten Browsers gehört zum Betriebssystem und kann nicht durch Web-Entwicklertools analysiert werden.
- Beim BitB-Fenster markiert der Inspektor gewöhnliche HTML-Elemente wie
divoderspan, die den simulierten Text der URL enthalten.
Vergleichsmatrix: Echtes OpenID-Fenster vs. BitB-Phishing-Frame
| Merkmal | Offizielle Steam-OpenID-Authentifizierung | Simulierter BitB-Phishing-Rahmen |
|---|---|---|
| Fensterursprung | Eigenständiger OS-Prozess via window.open | DOM-Element (div / iframe) innerhalb der Seite |
| Bewegungsradius | Frei beweglich über alle Monitore | Streng auf den Viewport der Website begrenzt |
| Adresszeilen-Sicherheit | Sichere OS-Adressleiste mit echtem SSL-Zertifikat | Nachgebildeter Textblock mit statischer SVG-Grafik |
| Passwort-Manager | Erkennt Domain und bietet Zugangsdaten an | Erkennt Fremddomain und blockiert Autofill |
| Sitzungsstatus | Erlaubt 1-Klick-Anmeldung bei aktiver Steam-Sitzung | Erzwingt stets Neueingabe von ID, Passwort und 2FA |
| Rechtsklick-Menü | Standard-Systemmenü des Browsers | Öffnet DOM-Inspektor auf Webseiten-Ebene |
Sofortmaßnahmen: Notfallprotokoll nach einem Datenabfluss
Besteht der Verdacht, Zugangsdaten oder Steam-Guard-Codes in ein BitB-Fenster eingegeben zu haben, müssen umgehend folgende Schritte in exakter Reihenfolge durchgeführt werden:
- Sämtliche aktive Gerätesitzungen widerrufen:
- Die Steam-App auf dem Smartphone oder den Steam-Client auf einem sauberen Rechner öffnen und die Steam-Guard-Optionen aufrufen.
- Den Befehl Alle anderen Geräte deautorisieren ausführen. Dadurch werden alle aktiven
steamLoginSecure-Cookies serverseitig ungültig und der Angreifer verliert sofort den Zugriff.
- Steam-Web-API-Schlüssel prüfen und löschen:
- Im Browser direkt
https://steamcommunity.com/dev/apikeyaufrufen. - Sollte dort ein API-Schlüssel eingetragen sein (reguläre Spieler benötigen keinen), sofort auf Meinen Steam-Web-API-Schlüssel widerrufen klicken. Angreifer nutzen diesen Schlüssel zum Umleiten von Handelsangeboten.
- Im Browser direkt
- Passwörter ändern:
- Das Steam-Hauptpasswort sowie das Passwort des hinterlegten E-Mail-Kontos von einem sicheren Gerät aus ändern.
- Handels-URL erneuern:
- In den Steam-Handelseinstellungen eine neue Handels-URL generieren, um automatisierte Bot-Anfragen abzuwehren.
Die Absicherung moderner Gaming-Accounts erfordert ein grundlegendes Verständnis von Web-Authentifizierungsmechanismen. Die technischen Leitfäden auf 365Finds bieten Orientierung, um DOM-Injektionen und Reverse-Proxy-Angriffe rechtzeitig zu erkennen, bevor Konten oder virtuelle Besitztümer kompromittiert werden. Das Misstrauen gegenüber reinen Bildschirminhalten und der konsequente Einsatz von herkunftsbasierten Passwort-Managern bilden das verlässlichste Schutzschild gegen modernes Phishing.