„Das Web ist kaputt“ – Was, wenn mein Gerät Teil eines Botnets wird, das andere angreift? AI-Crawling und das verborgene Proxy-Ökosystem

• Einige AI-Unternehmen integrieren zur Datensammlung eine „botnetisierte P2P-Proxy-SDK“ in Apps, wodurch Nutzer ohne ihr Wissen Teil ihrer Web-Crawling-Infrastruktur werden
• Diese SDK „verkauft“ ohne Zustimmung einen Teil der Netzwerkbandbreite der Nutzer (120–150 kbps) und verschafft Entwicklern Einnahmen (18 Cent pro Person), während sie anomale Aktivitäten wie Crawling und Brute-Forcing von Mailservern ausführt
• Dieses Botnet nutzt zehntausende Residential- und Mobile-IPs zur Umgehung der Erkennung, wobei pro IP nur ein Angriffsversuch pro Tag erfolgt, um Sicherheitssysteme wie fail2ban zu umgehen
• Ein bekanntes Beispiel ist das Infatica SDK; Entwickler, die es einbinden, infizieren ihre Nutzer faktisch mit einem Botnet
• Der Markt für „Residential Proxies“ wächst durch die Nachfrage nach AI-Crawling rasant und ist faktisch eine nicht autorisierte Crawling-Infrastruktur
• Diese Botnet-Struktur ist eine neue Form von Stealth-Cyberangriffen, an der sich App-Entwickler in diesem Ökosystem beteiligen
• Der Autor stuft Web-Crawling selbst als einen Angriff auf die Grundlagen des Webs ein und fordert Verantwortung von Entwicklern und Plattformunternehmen sowie eine vollständige Blockierung allen Crawlings

---

Stealth-Botnets, was dahintersteckt: Botnet Part 1

Botnet-Angriffe auf einen privaten Mailserver

• Der Mailserver des Autors wird fortlaufend mit SMTP-Brute-Force-Angriffen attackiert
• Ziel der Angriffe: Konten zu kompromittieren und Spam-Mails zu versenden
• Die meisten Versuche scheitern, aber die Angriffe selbst sind dauerhaft und hartnäckig

Die wahre Natur des Botnets: Infektion von Geräten über SDKs

• App-Entwickler erhalten Geld für die Einbindung eines SDKs
  • Beispiel: 18 Cent pro Nutzer und Monat
• Dieses SDK vermietet einen Teil des Datenverkehrs der Nutzer (120–150 kbps)
• Es wird als „P2P-Proxy“ oder „Residential Proxy“ vermarktet, tatsächlich aber werden die Geräte der Nutzer als Botnet-Knoten genutzt

Die Angriffsmethode: Verteilter Angriff zur Umgehung der Erkennung

• Nur ein Login-Versuch pro IP und Tag → Umgehung automatischer Erkennung durch fail2ban, UFW usw.
• Gleichzeitig verfügt das Botnet über zehntausende IPs und führt die Angriffe dauerhaft und verteilt aus
• Der Autor weist darauf hin, dass diese Methode gängige Sicherheitswerkzeuge wirkungslos macht

Warum das Blockieren nach ASN ineffektiv ist

• Es wurde analysiert, ob sich IPs bei bestimmten Providern (ASN) konzentrieren
  • Ergebnis: Im Durchschnitt weniger als 4 Angriffs-IPs pro ASN → Das Blockieren ganzer ASNs ist wirkungslos
• Derzeit bleibt nur der Ablauf tägliche Log-Analyse → E-Mail mit neuen Befehlen zum Sperren von IPs → manuelles Blockieren

Reaktion und Grundhaltung

• Automatisierung wäre möglich, aber der Autor prüft und reagiert bewusst selbst, um Muster zu erkennen und wachsam zu bleiben
• Zahl der Angreifer-IPs: derzeit mehr als 50.000 blockiert
• Die meisten davon sind IPv4, IPv6-Angriffe sind bislang selten

Die Realität des Botnet-Ökosystems

• Eine legal wirkende Vertriebsstruktur nach dem Muster „SDK einbinden → Umsatzbeteiligung“
• Tatsächlich wird der Datenverkehr der Nutzer ohne Zustimmung für Spam, Angriffe, Crawling usw. genutzt
• Solche Botnets werden von gewöhnlichen Antiviren- oder Sicherheitssystemen nicht erkannt

Fazit

• Wenn App-Entwickler solche SDKs integrieren, beteiligen sie sich faktisch am Aufbau eines Botnets
• Normale Nutzer können nicht erkennen, ob eine App ein solches SDK enthält, und werden automatisch Teil des Botnets
• Vor diesem Hintergrund warnt der Autor vor einem Zusammenbruch des Web-Ökosystems

„Ich vertraue Unternehmen, die behaupten, das sei eine ‚normale SDK‘, überhaupt nicht. Das ist ein Botnet.“
— Jan Wildeboer, Februar 2025

---

# Das Web ist kaputt: Botnet Part 2

Die rasante Zunahme von Web-Crawlern und ihr Hintergrund

• In jüngster Zeit ist die Nachfrage nach großskaliger Datensammlung zum Training von AI-Modellen stark gestiegen
• AI-Unternehmen kratzen stillschweigend sämtliche Webinhalte zusammen und verursachen Überlast durch Traffic
• Normale Webmaster und Serverbetreiber werden von Crawlern geplagt, wissen jedoch oft nicht, wer diese Crawler tatsächlich betreibt

Eine neue Form des Botnets: Infektion von Nutzern über SDKs

• Einige Unternehmen bezahlen App-Entwickler für die „Einbindung eines SDKs“
• Nutzer, die Apps mit diesem SDK installieren, merken nicht, dass ihr Traffic für AI-Crawler verwendet wird
• Solche SDKs lassen sich in iOS-, Android-, MacOS- und Windows-Apps integrieren

Beispiel: Infatica

• Website: https://infatica.io
• Auf einer Infoseite für Entwickler wird damit geworben, dass man über das Netzwerk der Nutzer crawlen könne
• Das Unternehmen behauptet, Millionen rotierender (Residential/Mobile) IPs bereitzustellen

Warum das problematisch ist

• Unternehmen wie Infatica behaupten zwar, zu überwachen, welche Befehle ihre Kunden (z. B. AI-Unternehmen zum Crawling) ausführen, tatsächlich ist das aber eine Struktur zur Verantwortungsabwälzung
• Auch der Bericht von Trend Micro aus dem Jahr 2023 bestätigt ähnliche Fälle
• Teilweise werden SDKs heimlich in kostenlose Software eingebettet und ohne Zustimmung der Nutzer installiert

Der Schaden: für Privatnutzer und kleine Server gleichermaßen

• App-Entwickler: bauen aus finanzieller Verlockung das SDK ein und werden damit faktisch zu Verbreitern von Malware
• Nutzer: Ihr Gerät und ihr Netzwerk werden für Web-Crawling und DDoS eingesetzt
• Serverbetreiber: Sie werden unbemerkt zum Ziel übermäßiger Anfragen
  • Beispiel: Auch die Forgejo-Instanz des Autors wurde wegen zu viel Bot-Traffic auf privat umgestellt

Die Verpackung als „Residential Proxy“

• Proxies, die Geräte von Nutzern als Ausgangspunkte verwenden, werden „Residential IPs“ genannt
• Beispiel einer Review-Seite für Proxy-Dienste:
  https://proxyway.com/reviews
• Oberflächlich wirkt das wie eine „legitime Infrastruktur“, tatsächlich ist es jedoch eine Struktur der unerlaubten Verbreitung und Proxy-Nutzung

Fazit: Web-Crawling hat inzwischen ein Missbrauchsniveau erreicht

• Der Autor fordert, jede Form von Web-Crawling als böswilliges Verhalten zu betrachten
• Er sieht darin, dass Web-Crawler die Fundamente des Webs angreifen
• AI ist der zentrale Treiber dieser Struktur, und er weist die Behauptung entschieden zurück, das sei „legal“

Forderungen und Problembewusstsein

• App-Entwickler, die solche SDKs integrieren, müssen zur Verantwortung gezogen werden
• Plattformbetreiber wie Apple, Google und Microsoft müssen gegen diesen Markt vorgehen
• Für normale Nutzer ist es nahezu unmöglich, dies zu erkennen oder zu blockieren
• Webbetreiber versuchen zwar, Crawler technisch zu stoppen, stoßen dabei aber an Grenzen

„Dank AI wird das Web zu einem Ort, dem man nicht mehr vertrauen kann. Danke, AI.“
– Jan Wildeboer, April 2025

[GN⁺]

Hacker-News-Kommentare

• Dass App-Entwickler aus Profitgründen SDKs von Drittanbietern einbinden, ist Teil des Problems, und ich finde, sie sollten dafür verantwortlich gemacht werden, den Nutzern Malware auszuliefern

  • Ich vermute, dass viele SDKs solche Probleme haben
  • Ich persönlich vermeide lieber eine Abhängigkeitssucht und entwickle es selbst
  • Böswillige Akteure nutzen die Abhängigkeitssucht moderner Entwickler aus und stellen Fallen auf

• Auf iOS, Android, MacOS und Windows gibt es einen Markt dafür, App-Entwickler Bibliotheken einbinden zu lassen, die die Netzwerkbandbreite der Nutzer verkaufen

  • Das hängt damit zusammen, warum Cloudflare und Google CAPTCHAs verlangen
  • Ich verstehe nicht, warum Play Protect, MS Defender und Apples Antivirenlösungen solche Malware nicht erkennen
  • Wenn eine SDK-Bibliothek das Gerät eines Nutzers zu einem Teil eines Botnets macht, ist das ein offensichtliches Beispiel für ein Trojanisches Pferd

• Das Problem des Webs ist, dass ein bestimmter Systemadministrator einen Server betreiben muss, damit Daten lesbar bleiben

  • Mit einem inhaltsadressierten Modell könnte man die Einzigartigkeitsbeschränkung aufheben
  • AI-Scraper würden Daten untereinander teilen und die ursprüngliche Quelle nicht belasten

• Software zum Teilen von Netzwerken sollte als unerwünschte Anwendung eingestuft werden

  • Sie wird zusammen mit dem installiert, was der Nutzer eigentlich installieren wollte, und missbraucht Ressourcen
  • Ich würde das gern mit Wireshark auf verdächtige Aktivitäten prüfen
  • Es braucht ein öffentliches Repository für Apps, die sich so verhalten

• Apps, die Malware enthalten, sollten sofort isoliert werden

  • Auch wenn sie keinen direkten Schaden verursachen, ist es Malware

• Web-Scraping sollte als Missbrauch betrachtet werden, und Webserver sollten es blockieren

  • Plattformen wie Youtube würden dem wahrscheinlich zustimmen

• Ich frage mich, ob jemand eine Liste von Software zusammengestellt hat, die solche Bibliotheken verwendet

  • Es wäre gut zu wissen, welche Apps man meiden sollte

• Residential-IP-Proxys haben die Schwäche, dass sich ihre IP-Adressen häufig ändern

  • IPs desselben Proxy-Anbieters lassen sich leicht erkennen
  • Ich entwickle eine Open-Source-Plattform zur Betrugsprävention, und die Erkennung gefälschter Nutzer aus Residential Proxys ist einer der Anwendungsfälle

• Bisher gibt es keine klaren Beweise, aber dieses Verhalten lässt sich leicht erkennen

  • iOS hat Funktionen, mit denen man Verbindungen einer App überprüfen kann
  • Android hat so etwas nicht, aber man kann Drittanbieter-Firewalls wie pcapdroid verwenden
  • Unter MacOS kann man Little Snitch verwenden, unter Windows Fort Firewall
  • Es gibt nicht viele Leute, die solche Apps nutzen, aber sie würden wahrscheinlich Apps melden, die ihre Geräte als Botnet verwenden

• Ich frage mich, ob es eine Liste von c&c-Servern gibt, die man zu Pihole usw. hinzufügen kann