Bei der Virality GmbH, einem Schwesterunternehmen und Auftragsverarbeiter des Schulplattform-Anbieters IServ, hat eine Fehlkonfiguration eines Authentifizierungsdienstes einen unautorisierten Cloud-Zugriff auf Serverdienste ermöglicht. Die inzwischen abgeschlossene interne Untersuchung ergab keine Hinweise auf einen Zugriff auf oder einen Abfluss von Benutzerdaten. Die Spuren deuten jedoch auf eine missbräuchliche Nutzung von Rechenressourcen hin, wie sie etwa beim heimlichen Schürfen von Kryptowährungen vorkommt.
Cloud-Zugriff durch Fehlkonfiguration: Der Ablauf
Ein Authentifizierungsdienst ist der zentrale Wächter für den Zugriff auf Server und Anwendungen. Er prüft, wer welche Rechte hat, und entscheidet, ob eine Anfrage zugelassen wird. Ist diese Prüfung fehlkonfiguriert, können Angreifer Schutzmechanismen umgehen. Genau das ist bei Virality geschehen: Der erste unautorisierte Zugriff erfolgte am 3. August 2026. Das Unternehmen bestätigte, dass weitreichender Zugriff auf das Hostsystem der betroffenen Anwendungen bestand; theoretisch wäre damit auch ein Zugriff auf deren Anwendungsdatenbanken möglich gewesen.
Die Auswertung der Protokolle zeigt, dass die Angreifer die Fehlkonfiguration automatisiert ausgenutzt haben. Bei einem manuellen Rundgang, der weniger als eine Minute dauerte, riefen sie unter anderem aktive technische Benutzersitzungen ab. Weitergehende Erkundungen des Systems lassen sich den Logdaten zufolge nicht erkennen. Anschließend führten sie ein Programm aus, das erhebliche Rechenressourcen beanspruchte – jedoch nicht mit erweiterten Rechten lief. Das Muster aus automatisiertem Zugang, kurzer Sichtung und anschließendem Ressourcenverbrauch ist typisch für Kryptomining, bei dem fremde Rechenleistung für eigene Zwecke genutzt wird.
Betroffene Dienste: IServ-Module in der Cloud
Von der Fehlkonfiguration betroffen waren mehrere IServ-Module, die auf einer gemeinsamen Cloud-Infrastruktur betrieben werden. Diese Module ergänzen die Schulplattform um Funktionen für den Schulalltag und werden von Virality als Auftragsverarbeiter bereitgestellt. Zu den betroffenen Diensten zählen Abwesenheiten, Ganztag, Klassenbuch, Listen, Pinnwände, Stundenplanung sowie Stunden- und Vertretungsplan.
Wichtig ist die Abgrenzung zu den eigentlichen Schulinstanzen: Individuelle IServ-Instanzen der Schulen, Kundensysteme und Server der IServ GmbH selbst waren nicht betroffen. Der Vorfall führte also nicht zu einem Ausfall der gesamten Plattform, sondern zunächst zu einem eingeschränkten Funktionsumfang der genannten Zusatzmodule.
Welche IServ-Dienste waren genau betroffen?
Betroffen waren die Module Abwesenheiten, Ganztag, Klassenbuch, Listen, Pinnwände, Stundenplanung sowie Stunden- und Vertretungsplan. Die individuellen IServ-Instanzen der Schulen sowie die Server der IServ GmbH selbst blieben unberührt.
Keine Anzeichen für Datenabfluss: Die Befunde
Die Unternehmen haben die Vorgänge anhand von Protokoll- und Monitoringdaten nachvollzogen. Demnach fanden sich keine Hinweise auf einen Zugriff auf Kundendaten oder einen entsprechenden Datenabfluss. Auch das festgestellte Netzwerkverkehrsvolumen wäre mit einem Abzug der Anwendungsdatenbanken nicht vereinbar gewesen. Ein Datenabfluss bleibt dennoch eine theoretische Möglichkeit, da technische Protokolle nie vollständig sind. Anzeichen für Manipulationen an Kundendaten oder eine tiefergehende Einnistung der Angreifer in die Systeme haben sich ebenfalls nicht ergeben.
Reaktion: Schnelle Neuinstallation und Information der Schulen
IServ wurde am 10. August 2026 über den Vorfall informiert. Die betroffene Infrastruktur wurde noch am selben Tag abgeschaltet und anschließend aus sicheren Quellen neu installiert. In der Nacht zum 11. August 2026 standen die Dienste wieder zur Verfügung. Zunächst erfuhren die Kunden von einem Ausfall; nach der Wiederherstellung folgte eine ausführlichere Information über den Sicherheitsvorfall. Auch die zuständigen Schulträger wurden informiert.
Weil Virality als Auftragsverarbeiter in die Verarbeitung von Schul- und Schülerdaten eingebunden ist, war der Vorfall meldepflichtig. IServ prüft nun, ob es den Meldeprozess für seine Kunden künftig stärker übernehmen kann. Für Schulen und andere Kunden besteht derzeit kein weiterer technischer Handlungsbedarf.
Welche Maßnahmen ergreift Virality nach dem Vorfall?
Virality hat ein Bündel an Sicherheitsmaßnahmen angekündigt. Geplant sind zusätzliche automatisierte Tests, ein Ausbau der Anomalie-Erkennung und ein weiteres Sicherheitsaudit. Ergänzend sollen Firewall-Regeln verschärft, Logdaten zentral besser ausgewertet, dateibasierte Backups eingeführt und Wiederherstellungsprozesse beschleunigt werden. Damit will das Unternehmen sowohl die Erkennung ungewöhnlicher Zugriffe verbessern als auch die Grundlage für schnellere Reaktionen auf künftige Vorfälle schaffen.
Der Vorfall bei IServ und Virality zeigt, wie weitreichend eine einzelne Fehlkonfiguration in einem Authentifizierungsdienst wirken kann. Die schnelle Abschaltung und Neuinstallation der Systeme hat verhindert, dass die Angreifer tiefer in die Infrastruktur eindringen konnten. Die geplanten Verbesserungen bei Monitoring, Tests und Wiederherstellung dürften die Widerstandsfähigkeit erhöhen. Gleichzeitig bleibt eine theoretische Restunsicherheit, da nicht jeder Zugriff in Protokollen vollständig abgebildet wird – die offene Kommunikation gegenüber Schulen und Schulträgern ist daher der richtige Weg, um Vertrauen zu erhalten.
