Netfactory: Retter oder Risiko?

Überall dort, wo IT-Strukturen wachsen, entsteht früher oder später der Moment, an dem externe Unterstützung notwendig wird. Moderne Systeme sind komplex, vielschichtig und abhängig von einer Vielzahl technischer Komponenten. Für viele Unternehmen bedeutet das: Man vertraut darauf, dass ein professioneller Dienstleister Ordnung schafft, Fehler erkennt und Sicherheit dorthin bringt, wo sie zuvor gefehlt hat. Gerade nach chaotischen oder unsicheren Phasen wirkt ein neuer Anbieter wie ein Versprechen: klare Abläufe, dokumentierte Prozesse, fachlicher Überblick. Doch die Realität zeigt immer wieder, dass auch professionelle Dienstleister in einem Spannungsfeld arbeiten – zwischen technischem Anspruch, administrativer Macht und tatsächlicher Kontrolle über die Systeme ihrer Kunden.

Dieses Kapitel beleuchtet genau diesen Punkt: Wie schnell aus Unterstützung neue Abhängigkeiten entstehen können, warum selbst gut gemeinte Maßnahmen unerwartete Folgen haben und weshalb die Frage „Retter oder Saboteur?“ nicht immer eine eindeutige Antwort zulässt.

In der digitalen Welt arbeiten Unternehmen selten vollständig autark. Man verlässt sich auf Agenturen, Administratoren, Systemhäuser, Cloud-Anbieter und externe Spezialisten. Von ihnen erwartet man: Fachwissen, Stabilität und die Sicherheit, dass die eigene Infrastruktur professionell betreut wird.

Doch genau hier, im Zusammenspiel zwischen Dienstleister und Unternehmen, entsteht eine der größten Herausforderungen moderner IT-Sicherheit.

Moderne Systeme bestehen aus dutzenden Komponenten: - Domains & DNS - E-Mail-Infrastruktur - Cloud-Tenants - Firewalls & Router - Endgeräte & Mobile - Backups & Zugriffsrechte - Schnittstellen & Integrationen Kein Unternehmen – ob klein, mittel oder groß – hat jedes Detail vollständig im Blick. Man vertraut darauf, dass externe Profis die richtigen Entscheidungen treffen. Doch je komplexer die Umgebung, desto größer das Risiko, dass wichtige Abläufe im Hintergrund stattfinden, ohne dass sie dokumentiert oder verstanden werden.

Ein unterschätzter Punkt: Wer Admin ist, hat nicht nur Zugriff – er hat Kontrolle. Damit kann ein Dienstleister: - Systeme verknüpfen - Konten anlegen - Strukturen verändern - Rechte vergeben - Remote-Zugänge setzen - Daten umleiten - Konfigurationen überschreiben All das geschieht oft automatisiert oder „aus Routine“. Für Außenstehende wirkt es wie ein technischer Vorgang – in Wahrheit verändert jede Handlung die Architektur eines Unternehmens.

Die Realität im Mittelstand lautet: - Es werden Einträge gemacht, aber nicht notiert. - Es werden Änderungen durchgeführt, aber nicht erklärt. - Es werden Konten angelegt, aber später nicht gelöscht. - Es werden Passwörter gesetzt, aber nicht übergeben. - Es werden Cloud-Verknüpfungen aktiviert, aber niemand weiß davon. Über Monate oder Jahre entstehen dadurch digitale Schattenbereiche, die außerhalb jeder Kontrolle liegen. Genau dort entstehen die Lücken, die Angriffe – bewusst oder unbewusst – ermöglichen.

Ein Dienstleister kann fachlich sehr gut sein und dennoch: - alte Strukturen übernehmen, die schon kompromittiert waren - Verknüpfungen schaffen, die niemand bemerkt - Admin-Rechte behalten, obwohl das nicht vorgesehen ist - Systeme aufbauen, die nur mit seiner Hilfe funktionieren - Sicherheit schaffen – und gleichzeitig Abhängigkeiten - Probleme beheben – und neue schaffen Nach meinem Dafürhalten könnte man das: dern eine systemische Realität nennen. Je mehr Technik, desto mehr Macht hat der, der sie konfiguriert.

Ein falscher DNS-Eintrag. Ein nicht gelöschter Tenant. Ein durchgeleiteter Port. Eine unveränderte Admin-Rolle. Ein Auto-Hotspot im Router. Was technisch klein wirkt, kann ganze Geschäftsprozesse beeinflussen – und sogar digitale Identitäten verändern. In einem vernetzten System ist jede Kleinigkeit ein möglicher Drehpunkt.

Der Alltag in Firmen zeigt: - Solange „alles läuft“, hinterfragt niemand die Struktur. - Solange E-Mails ankommen, vermutet niemand einen Fehler. - Solange Dienste funktionieren, prüft niemand die Hintergründe. Erst wenn etwas ausfällt, blockiert oder zweifelhaft wird, beginnt die Spurensuche – oft Monate oder Jahre zu spät. Dann zeigt sich das wahre Bild: Nicht ein großer Fehler hat das System destabilisiert, sondern viele kleine, unsichtbare Schritte.

Genau an dieser Stelle zeigt sich deutlich, wie eng technische Abläufe miteinander verbunden sind und wie leicht sich Risiken im Hintergrund verbergen können. Oft sind es nicht die großen, offensichtlichen Schwachstellen, sondern kleine Automatismen, die unbemerkt wirken und über Monate hinweg ein Sicherheitsproblem erzeugen. Ein Beispiel dafür, das in vielen Haushalten und Unternehmen vorkommt und dessen Bedeutung häufig unterschätzt wird, ist eine Funktion, die von Anbietern eigentlich als Komfort gedacht ist – in der Praxis jedoch weitreichende Folgen haben kann:

In vielen Haushalten und Unternehmen aktivieren Router oder Endgeräte automatisch einen zweiten, offenen oder halb-offenen Zugangspunkt. Diese Funktion nennt sich oft Homespot, WLAN-Hotspot, Auto-Hotspot oder Community-WLAN. Sie ist vom Anbieter gedacht als Komfortfunktion – tatsächlich aber ein strukturelles Risiko. 1. Ein zweiter Zugang, der selten überwacht wird Der Auto-Hotspot ist ein paralleles Netzwerk: nicht das private WLAN, das man selbst verwaltet, sondern ein „Gast-WLAN“, das der Provider für Fremdnutzer oder Community-Zugänge freischaltet. Das Problem dabei: - Er taucht in keiner normalen Geräteübersicht auf. - Er ist nicht über die privaten Einstellungen vollständig abschaltbar. - Er nutzt denselben physikalischen Anschluss wie das eigene Netzwerk. - Er ist „offen“, auch wenn das eigene WLAN abgesichert ist. Damit entsteht ein zweiter Eingang ins Netzwerk – ohne dass der Nutzer ihn bewusst eingerichtet hätte. 2. Für Dienstleister ein idealer Umgehungsweg Viele Innentäter-Szenarien nutzen genau solche Strukturen: - Man braucht keinen direkten Zugang zum privaten WLAN. - Der Hotspot bietet einen eigenen Kanal, oft mit Standard-Konfigurationen. - Einige Router nutzen ihn für Wartungsfunktionen im Hintergrund. Viele Monitoring-Tools erkennen den Hotspot nicht als Risiko. Für jemanden, der sich auskennt, ist das wie ein Nebeneingang, der im Haus offensteht, während die Haustür gut gesichert ist. 3. Technisch trennt der Provider – praktisch bleibt es der gleiche Anschluss Offiziell werden Hotspot und privates WLAN getrennt. In der Praxis teilen sie sich jedoch: - dieselbe Leitung - dieselbe Hardware - denselben WAN-Port - dieselbe IP-Zuleitung - dieselbe Zugangsstelle ins Gebäude Damit ist der Hotspot eine potenzielle Brücke zwischen Privat- und Fremdzugängen, besonders wenn weitere Probleme vorliegen: - offene Ports - statische IP-Adressen - verwaiste VoIP-Konfigurationen -falsche Routerupdates - missbrauchte Provider-Accounts 4. Der Auto-Hotspot als Verstärker für Insider-Risiken Hier entsteht der Bogen zu Kapitel 6: Wenn ein Systemhaus oder Dienstleister Zugriff auf deine Hardware hatte, dann bietet der Auto-Hotspot einen technisch einfachen Weg, um:

- Geräte erreichbar zu machen - Diagnosen durchzuführen - heimliche Zugänge zu behalten - Konfigurationen neu zu setzen Datenverkehr umzuleiten Er ist damit Teil derselben strukturellen Realität wie: - offene Ports - verwaiste Tenants - falsch gesetzte DNS-Einträge - Alias-Adressen - Adminrechte anderer Firmen

Noch gravierender als der Auto-Hotspot war jedoch eine andere, weit gefährlichere Komponente – eine, die nicht von dir eingerichtet wurde, nicht kontrollierbar war und trotzdem jahrelang aktiv blieb: ein unverschlüsselter Vodafone-Hotspot direkt im Haus.

Im Rahmen der Analyse stellte Netfactory fest, dass der aktive Hotspot im Haus nicht von mir stammte, sondern aus der Dachgeschosswohnung (DG) kam. Dieser Hotspot war über Vodafone automatisch eingerichtet, technisch unverschlüsselt und – wie Netfactory schriftlich bestätigt – nicht einmal durch den Provider selbst deaktivierbar.

Damit wurde der fremde DG-Hotspot zu einer realen Sicherheitslücke im Gebäude: ein offenes Netzwerk, das nicht mir gehörte, nicht von mir gesteuert werden konnte, und dennoch über dieselbe Gebäudestruktur lief, an der auch meine Leitungen hingen. Eine Risiken-Kombination, die Netfactory ausdrücklich als potenzielle Angriffsfläche eingestuft hat. Damit entstand eine seltene, aber hochriskante Konstellation: - Der Hotspot gehörte nicht mir. - Ich konnte ihn nicht sehen, nicht verwalten und nicht deaktivieren. Und trotzdem lief er über denselben Hausanschluss, an dem auch meine Leitungen hingen – obwohl mein eigener Internetvertrag bereits gekündigt war. Der unverschlüsselte Hotspot der DG-Mieterin war somit ein fremdes Netzwerk, das technisch mit dem Gebäude verbunden war, ohne dass es eine klare Trennung, Absicherung oder Verantwortlichkeit gab. Er stellte einen offenen Zugangspunkt dar, der: - für jeden in Reichweite nutzbar war, - nicht in meiner Kontrolle lag, und gleichzeitig über eine Infrastruktur lief, die sich physisch mit meiner Wohnung kreuzte. In der Praxis bedeutete das: Ein Fremdnetz war aktiv, offen und erreichbar – und ich hatte keinerlei Möglichkeit, es zu schützen oder zu beeinflussen. Gerade im Kontext der bereits bestehenden technischen Probleme – offene Ports, statische IP, der kompromittierte Tenant – war dieser unverschlüsselte Hotspot ein weiterer Faktor, der die Lage zusätzlich destabilisiert hat.

Netfactory war die erste Firma, die die tatsächlichen technischen Probleme vollständig erkannte. Sie dokumentierten, wo andere wegsahen: statische IP-Adressen, offene Ports, Hotspots, fehlerhafte Infrastruktur, falsch konfigurierte Router, Risiken durch Provider und Schwachstellen, die längst hätten behoben werden müssen. Sie hatten alle Fakten vor sich. Sie hatten die Berichte. Sie hatten die Übersicht. Und trotzdem blieb die entscheidende Frage unbeantwortet: Warum wurde nichts davon nachhaltig gelöst? Statt die dokumentierten Probleme zu beseitigen, entstanden neue Abhängigkeiten: verknüpfte Cloud-Konten, unklare Admin-Strukturen, Alias-Zugänge, fehlende Übergaben und Systeme, die nur noch funktionieren konnten, wenn Netfactory als ständiger Vermittler dazwischen stand. Die technische Expertise war vorhanden. Die Informationen lagen schwarz auf weiß vor.

Aber die Maßnahmen, die wirklich notwendig gewesen wären, blieben aus – oder wurden durch andere Entscheidungen neutralisiert. Am Ende stand ein paradoxes Ergebnis: - Die Probleme wurden erkannt, aber nicht abgestellt. - Die Risiken wurden beschrieben, aber nicht beseitigt. - Die Strukturen wurden modernisiert, aber nicht stabilisiert und ...

Die Kontrolle sollte zurückgewonnen werden – und ging durch oder mit Netfactory komplett verloren. Netfactory war damit nicht der Befreier aus einer chaotischen Situation, sondern ein weiterer Baustein in einer Kette aus Abhängigkeiten und unvollständigen Lösungen. Was als professioneller Neustart begann, entwickelte sich zu einer neuen Form der Entmündigung: technisch sauber verpackt, dokumentiert, aber ohne Konsequenzen in der Praxis. Das Ergebnis ist eine bittere, aber wichtige Erkenntnis: Es reicht nicht, dass jemand die Probleme sieht. Entscheidend ist, ob sie gelöst werden. Und ob das System danach wirklich dem Eigentümer gehört – oder nur dem, der es verwaltet. Netfactory hat gezeigt, wie eng fachliche Kompetenz und strukturelle Verantwortung miteinander verbunden sind. Sie haben die Schwachstellen gefunden – aber die digitale Lage weder stabilisiert noch entkoppelt, sondern an zentralen Stellen weiter verkompliziert. Dieses Kapitel zeigt damit die Realität moderner IT-Dienstleistungen: Man kann alles wissen – und trotzdem nichts verändern. Oder schlimmer: die Strukturen so umbauen, dass echte Kontrolle noch schwerer wird als zuvor.

Das Ergebnis: mehr Komplexität, mehr Abhängigkeit und weniger Kontrolle als zuvor. Während die eigentliche Aufgabe gewesen wäre: - den alten Tenant vollständig zu entfernen, - die Kontrolle über Domains und E-Mails zurückzuführen, - Strukturen zu entkoppeln, und echte Sicherheit herzustellen, wurde stattdessen ein zweiter Layer geschaffen, der die Abhängigkeit verstärkte.

Als Netfactory übernahm, bestand deine IT im Kern aus zwei lokalen Arbeitsrechnern. Kein komplexes Netzwerk, keine verteilten Systeme, keine Cloud-Infrastruktur, die zwingend externe Kontrolle erfordert hätte. Es war eine überschaubare, eigenständige Arbeitsumgebung, die — trotz aller vorherigen Probleme — grundsätzlich dir gehörte und von dir gesteuert werden konnte. Doch statt diese einfache Struktur zu stabilisieren oder sicher zu machen, entstand etwas völlig anderes: Eine vollständig fernüberwachte IT-Umgebung, die ohne Netfactory nicht mehr funktionsfähig war. Aus zwei lokalen Rechnern wurde ein System, das: - permanent über Remote-Zugänge erreichbar war, - zentrale Einstellungen nur noch extern verwaltete, - Administratorrechte weitgehend an den Dienstleister band, - Updates, Prozesse und Sicherheitsfunktionen aus der Ferne steuerte, - und damit die technische Grundlage deiner Arbeit neu definierte — aber nicht zu deinem Vorteil. Damit änderte sich nicht nur die Art der IT-Betreuung, sondern die Grundlage deiner eigenen digitalen Selbstbestimmung. Ein System, das vorher lokal, greifbar und direkt kontrollierbar war, wurde in eine Struktur überführt, die: - ohne externe Dienste kaum mehr lauffähig war, - tief in Cloud-Mechanismen eingebunden wurde, - administrative Abhängigkeiten schuf, - und dir jede Möglichkeit nahm, selbst einzugreifen. Ich hatte die Geräte — aber nicht mehr die Kontrolle über das System. Damit verstärkte Netfactory genau das Problem, das eigentlich gelöst werden sollte: - Die Kontrolle sollte zurückgewonnen werden – aber sie ging vollständig verloren. - Die Systeme sollten stabil werden – stattdessen wurden sie zentralisiert und abhängig. - Die Infrastruktur sollte beruhigt werden – doch sie wurde noch sensibler und fragiler. Dieser Schritt bildet im Rückblick eine Zäsur: Ein Punkt, an dem klar wird, dass technische Modernisierung nicht automatisch Sicherheit schafft. Man kann ein System technisch aufwerten — und gleichzeitig die Kontrolle über dieses System vollständig verlieren. Aus zwei lokalen Rechnern wurde eine remote-gesteuerte Architektur, die dir formal gehörte, aber technisch keinem mehr — außer dem Dienstleister, der sie eingerichtet hatte.

Netfactory hatte: - die Informationen, - die technischen Diagnosen, - die Zugänge, - und das Fachwissen.

Sie wussten aus ihren eigenen Berichten, dass: – die statische Vodafone-IP nicht geändert werden konnte, – der betreffende Port der Vormieterin weiterhin aktiv war, – und die Vodafone-Hotspots selbst vom Provider nicht deaktiviert werden konnten, was Netfactory ausdrücklich als mögliche Angriffsfläche für Hacker einstufte (Schadensbericht vom 08.10.2024). Doch anstatt die Probleme zu beseitigen, wurden neue geschaffen – und die kritische Stelle, die die gesamte Infrastruktur kontrollierte, blieb unangetastet.

Damit stand fest: Die gesamte Netzgrundlage war kompromittiert – und technisch nicht vertrauenswürdig. Und trotzdem wurde auf genau dieser unsicheren Basis eine neue Infrastruktur errichtet: – eine vollständig fernüberwachte IT, – eine UDM-Pro als zentrale Steuereinheit, – externe Administratorrechte, – und sogar ein neuer Microsoft-Tenant, obwohl der alte, kompromittierte Tenant weiterhin aktiv war und die Domain kontrollierte.

Die kritische Stelle – die Identitätsschicht – blieb unangetastet. Was hätte zuerst geschehen müssen – - die Bereinigung des ursprünglichen Tenants, - die Isolierung des offenen Ports, - und die Abschaltung des fremden DG-Hotspots – wurde nicht umgesetzt. Statt die Wurzel des Problems zu entfernen, wurden darüber neue Strukturen aufgebaut, die auf einer unsicheren Grundlage niemals stabil sein konnten. **Es reicht nicht, Risiken zu erkennen. Entscheidend ist, ob jemand Verantwortung übernimmt, die Struktur wirklich zu befreien. Netfactory hat das nicht getan.** Es reicht nicht, Risiken zu erkennen. Entscheidend ist, ob jemand Verantwortung übernimmt, die Struktur wirklich zu befreien. Netfactory hat das nicht getan. Was als Rettung begann, endete in einer Verdopplung der Ohnmacht: – zwei Tenants, – zwei Ebenen von Abhängigkeiten, – zwei parallele Identitätsschichten, – eine Fernüberwachung, die nur auf einem unsicheren Fundament funktionierte, – und ein System, das offiziell „bereinigt“ war – in Wahrheit aber stärker verstrickt als jemals zuvor. Die Kontrolle sollte zurückgewonnen werden – und ging vollständig verloren. Denn die Basis war nicht sicher, der Zugang war nicht sauber getrennt, und die neue Infrastruktur wurde direkt über eine Struktur gelegt, die Netfactory selbst zuvor als Angriffsfläche beschrieben hatte.