ScarCruft greift Gaming-Plattform-Lieferkette an und installiert BirdCall

Jeder Plattformverantwortliche, der in den nächsten zwei Quartalen einen nativen Gaming-Client ausliefert, muss sich eine Zahl aus diesem Vorfall einprägen: sieben Versionen einer Android-Backdoor, die früheste datiert auf Oktober 2024, lagen rund zwanzig Monate lang in einem aktiven Gaming-Distributionskanal, bevor es zur öffentlichen Enthüllung kam. Das ist die Verweildauer, die die Branche derzeit in Kauf nimmt, wenn sie APKs über die eigene Infrastruktur ausliefert. Die wirtschaftlichen Kosten nativer Distribution sind gerade gestiegen – und dafür zahlt nicht das Sicherheitsteam.

Die Zahlen

Die Kampagne, wie The Hacker News berichtete, wurde im Oktober 2025 vom slowakischen Anbieter ESET entdeckt und ScarCruft zugeschrieben, einer staatlich geförderten Gruppe mit Verbindung zu Nordkorea. Ziel war sqgame[.]net, ein Nischen-Gaming-Portal für ethnische Koreaner in der Yanbian-Region Chinas – ein Korridor an der Grenze zu Nordkorea und Russland, der als bekannter Transitpunkt für Überläufer über den Tumen-Fluss gilt. Die geopolitische Spezifität ist relevant, denn sie erklärt, warum eine kleine Plattform mit einem schmalen Publikum eine Multi-Plattform-Implant-Kette wert ist.

Der technische Fußabdruck: zwei trojanisierte Android-APKs (ybht.apk und sqybhs.apk), die über manipulierte Download-Seiten bereitgestellt wurden, sowie eine trojanisierte Windows-DLL, die seit mindestens November 2024 über das Update-Paket des Desktop-Clients verteilt wurde. iOS-Spiele auf derselben Plattform blieben unberührt. Das Windows-Update war zum Zeitpunkt der Berichterstattung nicht mehr bösartig, doch die Android-APKs waren noch live, als ESETs Filip Jurčacko mit Reportern sprach. Das muss man sich vergegenwärtigen: Die Bereinigung ist unvollständig, und der Betreiber weiß es entweder nicht oder kann nicht reagieren.

BirdCall selbst wird als fortgeschrittene Evolution von RokRAT beschrieben, dessen Windows-Varianten seit 2021 in freier Wildbahn aktiv sind. Aus derselben Linie stammen CloudMensis für macOS und RambleOn für Android – eine Malware-Familie mit fünf Jahren aktiver Weiterentwicklung. Die Windows-Kette prüft auf Analysetools und VM-Umgebungen, bevor sie Shellcode herunterlädt, der RokRAT lädt, das dann BirdCall nachholt. Komponenten werden mit einem gerätespezifischen Schlüssel verschlüsselt, der Loader startet aus einem Ruby- oder Python-Skript. Die Android-Variante sammelt Kontakte, SMS, Anruflisten, Medien, Dokumente, Screenshots und Umgebungsaudio und beackert pCloud, Yandex Disk und Zoho WorkDrive für C2. Die Windows-Variante nutzt Dropbox und pCloud. Keine dieser Infrastrukturentscheidungen ist exotisch – und genau das ist der Punkt. Sie gehen im legitimen Datenverkehr unter, kein DLP-Produkt wird bei einem Betreiber mit normalem SaaS-Fußabdruck anschlagen.

Zum Kontext: ESET fand sieben eigenständige Android-Versionen in der Linie. Das ist keine opportunistische Crimeware, das ist ein Produktteam.

Was wirklich neu ist

Zwei Dinge sind hier wirklich neu, und nur eines davon ist die Malware. Die interessante Verschiebung ist, dass ScarCruft – historisch ein Windows-zentrierter Akteur – einen Supply-Chain-Angriff gezielt nutzte, um auf Android zu wechseln. Frühere BirdCall-Versionen zielten auf Windows-Nutzer. Der Einbruch bei sqgame[.]net verschaffte ihnen einen Android-Distributionskanal, und sie vergifteten nur die APKs, nicht die iOS-Builds. Das zeigt: Die Distributionsarchitektur des Betreibers war die Einschränkung, nicht die Fähigkeit der Malware-Autoren. Sie gingen dorthin, wo der unsignierte, sidegeladene Installationsflow existierte.

Dieses Muster sollte jedem iGaming-Plattformleiter bekannt vorkommen, der sich mit dem Google-Play-Richtlinienminenfeld rund um Echtgeld-Gaming auseinandergesetzt hat. Betreiber in Märkten, in denen die Play-Store-Distribution eingeschränkt oder unpraktisch ist, betreiben häufig ihre eigene APK-Distribution über die eigene Domain – oft mit benutzerdefinierter Updater-Logik, die Play Protect vollständig umgeht. Das ist strukturell dasselbe Auslieferungsrohr, das ScarCruft gerade missbraucht hat. Das Bedrohungsmodell eines auf Yanbian ausgerichteten Spieleportals und das Bedrohungsmodell eines Tier-2-Sportwettenanbieters, der APKs an Spieler in eingeschränkten Märkten ausliefert, liegen näher beieinander, als die meisten Vorstände ahnen.

Das zweite neue Element ist das konkret gewordene Verweildauerproblem. Die trojanisierte Windows-DLL ging rund um November 2024 live und wurde etwa elf Monate später entdeckt. Die Android-APKs sind noch live. Wer eine Build-Pipeline betreibt, bei der ein einziger kompromittierter Signing-Key, Build-Agent oder CDN-Ursprung ein vergiftetes Binary an jeden installierten Client ausliefern kann, hat dieselbe Risikooberfläche geerbt – und hat mit hoher Wahrscheinlichkeit noch kein Tabletop-Exercise für ein zwanzigmonatiges Erkennungsfenster durchgeführt. Die meisten Betreiber, die ich sehe, planen Incident Response auf der Annahme eines dreißig- bis neunzigtägigen Fensters. Die Zahlen dieser Kampagne stützen diese Annahme nicht.

Was nicht neu ist: die C2-Wahl. Cloud-Speicher-Missbrauch für Exfiltration ist seit Jahren Standard-Tradecraft. Zoho WorkDrive ist der einzig leicht interessante Hinweis, weil es laut ESET in ScarCruft-Kampagnen immer häufiger auftaucht. Wenn Ihre Egress-Allow-Lists Zoho standardmäßig enthalten, weil jemand im Finanzbereich es nutzt, ist das nun ein wiederkehrender blinder Fleck.

Was iGaming-Betreiber bereits einkalkuliert haben

Der Markt hat einkalkuliert, dass mobile Clients eine Angriffsfläche sind. Was er nicht einkalkuliert hat, sind die Kosten, als regulierter Betreiber einen eigenen Android-Distributionskanal zu betreiben. Die MGA und die UKGC stellen zwar technische Anforderungen an die Spielintegrität und den Spielerschutz, aber die Supply-Chain-Integrität des Client-Binaries selbst wird eher als betriebliche Hygienefrage und nicht als Lizenzierungsfrage behandelt. Diese Lücke wird sich schließen, und Betreiber mit eigener APK-Auslieferung sollten innerhalb des nächsten Lizenzzyklus mit Fragen von technischen Compliance-Auditoren rechnen.

Bereits einkalkuliert: Code-Signing, reproduzierbare Builds, SBOM-Hygiene. Die meisten Betreiber ab Series B aufwärts haben zumindest die Präsentationsversion dieser Controls. Was nicht einkalkuliert ist: Third-Party-Risiko bei White-Label-Plattformanbietern. Wer als Betreiber auf einer Turnkey-Plattform läuft, dessen APK wird in der Pipeline des Anbieters gebaut, mit dessen Schlüsseln signiert und von dessen CDN ausgeliefert. Das Incident-Response-Runbook für einen sqgame-artigen Angriff ist in der Praxis ein Anruf beim Account Manager des Anbieters. Das sind die Unit Economics, die niemand auf die Folie schreiben will: Die Kosten eines Supply-Chain-Angriffs auf ein White-Label trägt der Lizenznehmer, aber die Controls liegen beim Anbieter.

Der General Counsel jedes lizenzierten Betreibers sollte seinem VP Engineering diese Woche eine konkrete Frage stellen: Wer hat Commit-Zugriff auf das Repository, das unseren Mobile Client baut, wer hat Zugriff auf den Signing-Key, und können wir diese Liste in unter einer Stunde vorlegen? Wenn die Antwort einen Dritten und ein Support-Ticket umfasst, ist das regulatorische Risiko größer als das technische. Zwanzig Monate Verweildauer bei einem regulierten Client würden eine Section-166-Benachrichtigung nicht überstehen.

Eine andere Perspektive

Die einfache Lesart ist, dass diese Kampagne ein Weckruf für jede Gaming-Plattform ist. Das stimmt nicht. ScarCruft wählte sqgame[.]net, weil das Opferprofil in Yanbian ansässige ethnische Koreaner waren – eine Bevölkerungsgruppe von nachrichtendienstlichem Interesse für Pjöngjang. Ein lizenzierter iGaming-Betreiber in Malta oder im Vereinigten Königreich ist nicht in diesem Zielspektrum, und der operative Aufwand eines staatlichen Akteurs, eine Multi-Plattform-Implant-Familie gegen einen regulierten kommerziellen Betreiber zur Spielerüberwachung einzusetzen, ist durch keinen plausiblen Ertrag gerechtfertigt.

Die realistische Bedrohung für iGaming aus diesem Bericht ist nicht ScarCruft. Es sind die Techniken, die innerhalb von zwölf bis achtzehn Monaten von finanziell motivierten Akteuren kopiert und für Credential-Diebstahl und Account-Takeover umgewidmet werden. Cloud-Speicher-C2 über Dropbox und pCloud, mehrstufige Loader mit maschinenbezogenem Schlüssel, trojanisierte Updater-DLLs – das ist kein nordkoreanisches Exklusivhandwerk, und sobald ein Ransomware-Affiliate das Playbook gegen den Android-Client eines regionalen Sportwettenanbieters vermarktet, ändert sich die Diskussion. Bauen Sie das Bedrohungsmodell dafür, nicht für die APT-Schlagzeile.

Die wichtigsten Erkenntnisse

• Sieben Versionen der Android-BirdCall-Variante ab Oktober 2024 deuten auf ein etwa zwanzigmonatiges Verweildauerfenster in einem aktiven Distributionskanal hin – das sollte die Incident-Response-Planungsannahmen jedes Betreibers, der native Clients ausliefert, neu kalibrieren.
• Nur die Android-APKs und die Windows-DLL wurden vergiftet; iOS blieb unberührt. Die Distributionsarchitektur, nicht die Plattformsicherheit, bestimmte die Angriffsfläche – mit direkten Implikationen für Betreiber in Märkten, in denen die Play-Store-Distribution eingeschränkt ist.
• BirdCalls Nutzung von Dropbox, pCloud, Yandex Disk und Zoho WorkDrive für C2 macht die Egress-Erkennung für jeden Betreiber mit normalem SaaS-Fußabdruck erheblich schwieriger. Allow-Lists müssen geprüft werden.
• White-Label-iGaming-Lizenznehmer erben das Supply-Chain-Risiko ihres Plattformanbieters, ohne die dazugehörigen Controls zu erhalten. Das vertragliche und regulatorische Risiko liegt beim Lizenznehmer.
• Die für iGaming relevante Bedrohung ist nicht ScarCruft direkt, sondern das Playbook, das von finanziell motivierten Akteuren innerhalb der nächsten zwölf bis achtzehn Monate adaptiert wird. Teams sollten diesen Verzug modellieren, nicht die aktuelle Schlagzeile.

Teams, die ihre Mobile-Client-Distributionsstrategie evaluieren, sollten sich jetzt eine schärfere Frage stellen: Wenn unsere APK-Pipeline morgen kompromittiert würde – wie lange, bis wir es wüssten, und wer in der Organisation hat sowohl die Befugnis als auch den Zugang, einen Signing-Key noch am selben Tag zu widerrufen? Wenn die Antwort ein Meeting erfordert, ist die Architektur das Problem.