Thought Leadership
Eine Gruppe von Cyberkriminellen behauptet, in die Systeme des IT-Sicherheitsunternehmens Resecurity eingedrungen zu sein und interne Daten erbeutet zu haben. Resecurity widerspricht der Darstellung: Betroffen gewesen sei ein gezielt eingerichteter Honeypot mit fingierten Inhalten.
Behauptungen der Angreifer
Die Angreifer, die sich selbst als „Scattered Lapsus$ Hunters“ bezeichnen, veröffentlichten am Dienstag über Telegram Screenshots, die den Einbruch belegen sollen. Nach eigener Darstellung hätten sie vollständigen Zugriff auf Resecurity-Systeme erlangt und dabei unter anderem Mitarbeiterdaten, interne Chats, Threat-Intelligence-Berichte sowie eine vollständige Kundenliste abgegriffen.
Als Beweis zeigten sie unter anderem Aufnahmen einer angeblichen Mattermost-Instanz mit internen Unterhaltungen zwischen Resecurity-Mitarbeitern und Beschäftigten von Pastebin, in denen es um missbräuchlich genutzte Inhalte auf der Plattform geht. Mattermost ist eine Open-Source-Plattform für Teamkommunikation, die vor allem in Unternehmen, Behörden und IT-Teams eingesetzt wird. Sie erfüllt einen ähnlichen Zweck wie Slack oder Microsoft Teams, legt aber großen Wert auf Datenschutz, Kontrolle und Selbstbetrieb.
Nach Angaben der Gruppe sei der Angriff eine Reaktion auf angebliche Social-Engineering-Versuche durch Resecurity. Mitarbeiter des Unternehmens hätten sich demnach als Käufer ausgegeben, um bei einem mutmaßlichen Verkauf einer vietnamesischen Finanzdatenbank kostenlose Proben zu erhalten. Ein Sprecher der bekannten Leak-Gruppe ShinyHunters erklärte gegenüber BleepingComputer, an dem aktuellen Vorfall nicht beteiligt gewesen zu sein. ShinyHunters werden zwar häufig mit dem losen Verbund „Scattered Lapsus$ Hunters“ in Verbindung gebracht, distanzieren sich in diesem Fall jedoch ausdrücklich.
Resecurity: Kein Einbruch in Produktivsysteme
Resecurity weist die Vorwürfe zurück. Bei den von den Angreifern gezeigten Systemen handele es sich um einen bewusst exponierten Honeypot, der ausschließlich der Beobachtung von Angreifern diene. Laut einem internen Bericht hatte das Unternehmen bereits am 21. November 2025 erste Aufklärungsversuche auf öffentlich erreichbare Systeme festgestellt.
Das unternehmenseigene DFIR-Team habe frühzeitig verdächtige Aktivitäten erkannt und mehrere IP-Adressen protokolliert, darunter Verbindungen aus Ägypten sowie über den VPN-Anbieter Mullvad. Daraufhin sei in einer isolierten Umgebung ein spezieller Honeypot-Account eingerichtet worden, der Zugriff auf realistisch wirkende, aber vollständig synthetische Daten erlaubte.
Zu den fingierten Inhalten zählten laut Resecurity mehr als 28.000 künstlich erzeugte Kundendatensätze sowie über 190.000 simulierte Zahlungstransaktionen im Format der offiziellen API von Stripe. Ziel sei es gewesen, das Vorgehen der Angreifer detailliert zu analysieren, ohne echte Daten zu gefährden.
Beobachtung, Auswertung – und Strafverfolgung
Im Dezember hätten die Angreifer begonnen, die vermeintlichen Daten automatisiert abzuziehen. Zwischen dem 12. und 24. Dezember seien mehr als 188.000 Anfragen registriert worden, vielfach über Wohnproxy-Netzwerke. Dabei habe Resecurity umfangreiche Telemetriedaten zu Taktiken, Techniken und Infrastruktur gesammelt.
Nach Angaben des Unternehmens kam es mehrfach zu sogenannten OPSEC-Fehlern, bei denen reale IP-Adressen der Angreifer kurzzeitig sichtbar wurden. Diese Informationen seien an Strafverfolgungsbehörden weitergegeben worden. In einem weiteren Schritt habe Resecurity zusätzliche Fake-Datensätze eingebracht, um das Verhalten weiter zu analysieren und die Infrastruktur der Angreifer genauer einzugrenzen.
Schließlich habe eine ausländische Strafverfolgungsbehörde – ein Partner von Resecurity – auf Basis der gewonnenen Erkenntnisse ein Auskunftsersuchen gegen den mutmaßlichen Angreifer initiiert.
Weitere Enthüllungen angekündigt
Bislang haben die Angreifer keine weiteren Beweise vorgelegt. In einem neuen Telegram-Beitrag kündigten sie jedoch weitere Veröffentlichungen an und spotteten über das Vorgehen des Unternehmens: „Nice damage control Resecurity. More information coming soon!“
Ob es bei Ankündigungen bleibt oder tatsächlich neue Inhalte folgen, ist derzeit offen. Klar ist jedoch: Der Fall zeigt einmal mehr, dass selbst Sicherheitsfirmen zunehmend selbst ins Visier von Angreifern geraten, und dass Honeypots längst nicht mehr nur Forschungsobjekte, sondern aktive Verteidigungsinstrumente sind.
Was sind Honeypots?
Honeypots sind absichtlich so gestaltete IT-Systeme, Dienste oder Benutzerkonten, dass sie für Angreifer verwundbar und besonders attraktiv wirken. Ihr Zweck besteht nicht darin, produktive Systeme zu betreiben, sondern Angriffe gezielt anzuziehen und vollständig zu überwachen. Da legitime Nutzer keinen Grund haben, mit einem Honeypot zu interagieren, gilt jeder Zugriff als verdächtig und liefert wertvolle Hinweise auf Angriffsversuche.
In der Praxis enthalten Honeypots keine echten Unternehmensdaten, sondern realistisch wirkende, künstlich erzeugte Inhalte. Angreifer sollen glauben, auf sensible Informationen oder schlecht gesicherte Infrastruktur gestoßen zu sein, während Sicherheitsverantwortliche ihr Vorgehen im Hintergrund analysieren. Auf diese Weise lassen sich eingesetzte Werkzeuge, Angriffstechniken, genutzte Infrastruktur und typische Fehler der Angreifer erfassen.
Je nach Ausgestaltung simulieren Honeypots nur einzelne Dienste oder bestehen aus vollständig funktionsfähigen, aber isolierten Systemen. Besonders aufschlussreich sind Umgebungen, in denen Angreifer über längere Zeit agieren können, da sie detaillierte Einblicke in Arbeitsweise und Automatisierungsgrad liefern. Die gewonnenen Erkenntnisse fließen häufig in Threat-Intelligence-Berichte, Abwehrregeln und Incident-Response-Prozesse ein.
Honeypots ersetzen keine klassischen Schutzmaßnahmen wie Firewalls oder Endpoint-Schutz, sondern ergänzen sie. Richtig eingesetzt helfen sie, Angriffe frühzeitig zu erkennen, reale Bedrohungen besser zu verstehen und Verteidigungsstrategien gezielt weiterzuentwickeln. Voraussetzung ist allerdings eine strikte technische Trennung von produktiven Systemen, damit die Falle nicht selbst zum Sicherheitsrisiko wird.
