Chat with us, powered by LiveChat

Monthly Threat Report Oktober 2026

Die Konten, die niemand im Blick hatte

Author: Security Lab / 30.10.2026 /

Einleitung

Der Monthly Threat Report von Hornetsecurity by Proofpoint informiert Sie monatlich über Sicherheitstrends in Microsoft 365, E-Mail-basierte Bedrohungen und aktuelle Entwicklungen in der Cybersicherheit. Diese Ausgabe behandelt Ereignisse aus der Branche vom September 2026 bis einschließlich 10. Oktober. Da der Schwerpunkt diesmal auf Nachrichten und Einordnungen liegt, verzichten wir auf statistische Auswertungen und konzentrieren uns auf Forschungsergebnisse und Sicherheitsvorfälle.

Zusammenfassung

  • Microsoft stufte die SharePoint-Schwachstelle CVE-2026-65660 bei ihrer Veröffentlichung zunächst als Spoofing-Sicherheitslücke mittleren Schweregrads mit einem CVSS-Wert von 6,5. Am 27. August änderte das Unternehmen seinen CVE-Eintrag: Nun war von Remote Code Execution die Rede, und der Wert stieg auf 8,8. Previdian registrierte am 24. September erste Angriffsversuche. Am 25. September nahm CISA die Schwachstelle in den Katalog der Known Exploited Vulnerabilities (KEV) auf und setzte US-Bundesbehörden eine Frist von drei Tagen zur Behebung.
  • Microsofts Digital Crimes Unit und ein Partnerbündnis gaben am 22. September bekannt, den Phishing-Dienst EvilTokens zerschlagen zu haben. Auf Grundlage einer Anordnung des US-Bezirksgerichts für den Eastern District of Virginia wurden 50 Websites beschlagnahmt und mehr als 150 zugehörige Domains deaktiviert. Der abonnementbasierte Dienst kombinierte Device-Code-Phishing mit einem KI-Assistenten zur Auswertung kompromittierter Postfächer. Seit Februar war der Dienst mit mehr als 12.000 kompromittierten Postfächern in über 10.000 Unternehmen verknüpft.
  • Previdian meldete innerhalb von zwei Stunden nach Veröffentlichung eines Proof of Concept Angriffsversuche auf die Atlassian-Schwachstelle CVE-2026-21589, die unbefugtes Lesen von Dateien ermöglicht (CVSS v4.0: 9,3). Zum Auslesen der Dateien ist keine Authentifizierung erforderlich. Wenn Jira zur Authentifizierung Crowd verwendet, könnten die Dateien auch Crowd-Zugangsdaten im Klartext enthalten.
  • Proofpoint beobachtete eine Password-Spraying-Kampagne gegen 5.714 Microsoft-365-Konten in 28 Tenants. Sieben Konten wurden kompromittiert. Es handelte sich ausschließlich um Funktionskonten, bei denen zuvor keine menschliche Anmeldung festgestellt worden war. Proofpoint geht davon aus, dass alle sieben noch ihr ursprüngliches oder ein leicht zu erratendes Passwort verwendeten. Für keines war Multi-Faktor-Authentifizierung (MFA) verpflichtend.

Bedrohungsüberblick

Sieben kompromittierte Konten, kein einziger menschlicher Nutzer

Am 22. September veröffentlichte Proofpoint eine Analyse einer Password-Spraying-Kampagne, die das Unternehmen unter der Bezeichnung UNK_CondorFiltration verfolgt. Vom 21. Juli bis zum 16. August richtete sie sich gegen Microsoft-365-Tenants in Lateinamerika, fast ausschließlich in Chile. Die Bilanz: 32.825 Authentifizierungsereignisse, 5.714 unterschiedliche Konten, 28 Tenants, 1.487 Quell-IP-Adressen auf AWS EC2 und sieben kompromittierte Konten.

Sieben kompromittierte Konten also, und bei keinem fand Proofpoint in seinen Telemetriedaten eine vorherige legitime Nutzersitzung. Es waren Funktionskonten, etwa für Ticket-Warteschlangen, Kassensysteme oder Lieferantenzahlungen. Nach Einschätzung von Proofpoint verwendeten sie alle noch das bei der Einrichtung vergebene Passwort oder eine ebenso leicht zu erratende Variante. Für keines war MFA verpflichtend. Sechs wurden innerhalb von sieben Minuten kompromittiert. Bei Mitarbeiterkonten, deren Inhaber ihre Passwörter ändern müssen, konnte Proofpoint dagegen keinen erfolgreichen Angriff dieser Kampagne bestätigen.

Durch Automatisierung war der Aufwand für den Angriff minimal. Melvin Langvik entwickelte TeamFiltration als Penetrationstest-Tool für Microsoft 365. Es prüft über die Teams-API mit rund 300 Anfragen pro Sekunde, ob eine E-Mail-Adresse existiert, ohne eine Kontosperre auszulösen. Über FireProx verteilt sich der Password-Spraying-Traffic auf verschiedene AWS-Regionen. So konnte die Kampagne 1.487 Quelladressen nutzen und IP-Sperrlisten umgehen. Sobald das Tool ein gültiges Passwort finden, kann es selbstständig E-Mails und Dateien abrufen. Proofpoint betont allerdings, dass Anmeldeprotokolle allein keinen Datenabfluss belegen.

Alle sieben Konten wurden am 14. und 15. August in der letzten Phase der Kampagne kompromittiert. Ziel war ein großer chilenischer Einzelhändler, auf den 78,3 % der beobachteten Ereignisse entfielen. Bei einem von Proofpoint detailliert untersuchten Konto wechselte der Angreifer auf deutsche VPN-Infrastruktur und versuchte innerhalb einer Minute, sich am Unternehmens-VPN des Opfers anzumelden. MFA oder Conditional Access verhinderten den Zugriff. Danach folgten Sitzungen im Azure Portal und in SharePoint Online. Etwa 25 Minuten nach der ersten Anmeldung wurde ein Microsoft-Graph-Token angefordert. Beim Öffnen des Azure Portals wurde der Angreifer aufgefordert, MFA einzurichten. Das war der deutlichste Hinweis darauf, dass für das Konto zuvor keine MFA konfiguriert war.

Warum das wichtig ist

Sieben Treffer bei 5.714 Konten sind eine geringe Erfolgsquote. Doch jeder Treffer betraf ein Konto mit einer Ausnahmeregelung. Alle sieben gehörten zu demselben Unternehmen. Das Ergebnis zeigt damit die Bereitstellungspraxis eines einzelnen Tenants, belegt aber keinen Trend über alle 28 Tenants hinweg. Die zugrunde liegende Praxis ist allerdings weit verbreitet: Sicherheitskontrollen für Mitarbeiter können automatisierte Prozesse stören. Daraufhin wird eine Ausnahme eingerichtet, die oft länger besteht als die Zuständigkeit desjenigen, der sie beantragt hat. Das Konto behält sämtliche Berechtigungen, die es im Laufe der Zeit für seine Aufgaben benötigt hat.

„Keine interaktiven Anmeldungen in den letzten 90 Tagen“ bedeutet deshalb nicht zwangsläufig, dass ein Konto inaktiv ist. Es kann ebenso ein Konto beschreiben, das seine Aufgabe zuverlässig erfüllt, seit seiner Einrichtung dasselbe Passwort verwendet und von den Sicherheitsrichtlinien für Mitarbeiter ausgenommen ist.

Die Anmeldeseite ist echt, die Sitzung gehört dem Angreifer

Am 1. Oktober veröffentlichten wir eine Analyse von EvilTokens und Device-Code-Phishing (Englisch). Diese Technik bildete die Grundlage der Plattform, deren Zerschlagung Microsoft neun Tage zuvor bekannt gegeben hatte. In unserer August-Ausgabe hatten wir denselben Ablauf bei einem einzelnen Phishing-Kit beschrieben. Im September gab es dafür bereits ein Preismodell.

Das OAuth-Protokoll bietet einen Autorisierungsablauf für Geräte, auf denen sich Passwörter nur schwer eingeben lassen, etwa Konferenzraumsysteme. Das Gerät zeigt einen Code an, den jemand über den Browser eines Smartphones oder Laptops eingibt. Anschließend erhält das Gerät das Token. Beim Device-Code-Phishing ändert sich lediglich, wer dieses Token erhält. Der Angreifer startet den Ablauf und lockt das Opfer mit einem geschäftlich wirkenden Vorwand auf eine Seite, die einen gültigen Code erzeugt. Das Opfer gibt diesen auf der echten Microsoft-Anmeldeseite hxxps://microsoft[.]com/devicelogin ein und bestätigt gegebenenfalls auch die MFA-Abfrage. Das Token landet daraufhin in der Sitzung des Angreifers. Dieser kann E-Mails lesen, Posteingangsregeln anlegen und über Microsoft Graph die Unternehmensstruktur auskundschaften.

Warum das wichtig ist

Hier ist nichts gefälscht: Die Domain gehört Microsoft, das Zertifikat ist gültig, und der rechtmäßige Kontoinhaber bestätigt den zweiten Authentifizierungsfaktor selbst – allerdings für eine Sitzung, die er nie gestartet hat. Die seit Jahren vermittelte Empfehlung, die Adressleiste zu kontrollieren, hilft hier nicht weiter.

Im August handelte es sich noch um ein einzelnes Kit mit 34 Phishing-Vorlagen. Im September kamen ein Abonnement und ein Supportkanal hinzu. Damit konnten auch Käufer, denen die technischen Fähigkeiten zur Entwicklung eines eigenen Phishing-Kits fehlten, solche Angriffe durchführen.

Die passende Schutzmaßnahme bleibt dieselbe. Mit Entra ID Conditional Access lässt sich der Device-Code-Ablauf einschränken. Sinnvoll ist eine Positivliste: Legen Sie fest, welche Geräte diese Funktion benötigen, beschränken Sie eine Richtlinie auf diese Geräte und sperren Sie den Ablauf überall sonst. In den meisten Unternehmen ist diese Liste kurz, in manchen bleibt sie leer.

Wichtige Sicherheitsvorfälle und Branchenereignisse

Microsoft und Partner legen EvilTokens lahm

Microsofts Digital Crimes Unit (DCU) gab am 22. September bekannt, den Dienst EvilTokens zerschlagen zu haben. Grundlage war eine Anordnung des US-Bezirksgerichts für den Eastern District of Virginia, wobei Health-ISAC als Mitkläger auftrat. Insgesamt wurden 50 Websites beschlagnahmt und mehr als 150 zugehörige Domains deaktiviert. Microsoft erläuterte die technischen Hintergründe in einem Threat-Intelligence-Bericht. Auch Bleeping Computer und The Hacker News berichteten über die Aktion. Cloudflare, Coinbase, OpenAI, Railway, SpyCloud, The Shadowserver Foundation und TRM Labs unterstützten die Maßnahmen.

Der Dienst wurde ab Februar 2026 über Telegram verkauft. Laut Microsoft kostete er einmalig 1.500 US-Dollar und zusätzlich 500 US-Dollar pro Monat. Ergänzungen wie eine Anti-Bot-Weiterleitung und Tools für den Massenversand von E-Mails waren separat erhältlich. Das Basispaket enthielt 44 Phishing-Szenarien, darunter elektronische Signaturanfragen, Microsoft- und Drittanbieter-Cloud-Dienste, Rechnungen, Voicemail-Benachrichtigungen und eFax-Mitteilungen. Die Links führten über kompromittierte, ansonsten legitime Websites zu serverlosen Hosting-Plattformen, denen Reputationsfilter häufig vertrauen: vor allem Vercel (hxxps://*[.]vercel[.]app), Cloudflare Workers (hxxps://*[.]workers[.]dev) und AWS Lambda.

Besonders attraktiv waren für Käufer die KI-Funktionen. Vor einer Kampagne passte ein Assistent die E-Mails an ein bestimmtes Ziel an. Nach einer Kompromittierung fasste ein Chatbot die Nachrichten des Opfers zusammen, übersetzte sie und beantwortete die wichtigsten Fragen für einen Betrüger: In welchen E-Mail-Verläufen geht es um Geld? Wer darf Zahlungen freigeben? Welche Lieferantenrechnungen sind offen? Wessen Identität lässt sich für den Betrug missbrauchen?

Microsoft nennt mehr als 12.000 betroffene Postfächer in über 10.000 Unternehmen. SpyCloud sicherte unabhängig davon erneut abgegriffene Daten zu 8.708 Konten aus 6.585 Unternehmensdomains in 79 Ländern. Coinbase verfolgte Zahlungen von rund 1,1 Millionen US-Dollar über vier Tron-Adressen nach. Diese Summe gibt Hinweise auf die Einnahmen der Betreiber, nicht auf die Schäden der Opfer. Beamte des Metropolitan Police Service nahmen am 11. September in London zwei mutmaßliche Betreiber im Alter von 32 und 38 Jahren fest. Beide wurden gegen Kaution aus dem Polizeigewahrsam entlassen; die Ermittlungen dauern an.

Warum das wichtig ist

Microsoft bezeichnet die Aktion als Zerschlagung der Infrastruktur, räumt aber ein, dass das Geschäftsmodell bestehen bleiben dürfte. Für 1.500 US-Dollar und eine monatliche Gebühr erhielten Käufer ohne besondere Fachkenntnisse eine Angriffstechnik, die eine URL-Prüfung umgeht und trotz MFA funktioniert. Die Auswertung kompromittierter Postfächer war gleich mit automatisiert. In unserer August-Analyse zu KI-beschleunigten Cyberbedrohungen hatten wir argumentiert, dass KI Angriffe kurzfristig vor allem wirtschaftlicher macht. Bereits zum zweiten Mal in Folge zeigt sich diese Entwicklung nun in einer realen Angriffskampagne. Herauszufinden, wer Rechnungen freigibt, war beim Business Email Compromise bislang eine zeitaufwendige und teure manuelle Aufgabe. Hier übernahm das die Automatisierung.

SharePoint-Schwachstelle: Von Spoofing zu Remote Code Execution hochgestuft

CVE-2026-65660 wurde mit Microsofts Updates vom 11. August als Spoofing-Schwachstelle mit einem CVSS-Wert von 6,5 veröffentlicht. Gemeldet hatte sie Dinh Ho Anh Khoa von Viettel Cyber Security. Am 27. August änderte Microsoft seinen CVE-Eintrag: Die Beschreibung sprach nun von Remote Code Execution, und der CVSS-Wert stieg auf 8,8. Die Klassifizierung als Code Injection (CWE-94) stand bereits von Anfang an im Eintrag, obwohl die Beschreibung die Schwachstelle als Spoofing bezeichnete. Betroffen sind SharePoint Enterprise Server 2016, SharePoint Server 2019 und SharePoint Server Subscription Edition.

Die Schwachstelle befindet sich in SafeControls. Anhand dieser Liste entscheidet SharePoint, welche serverseitigen Steuerelemente geladen werden dürfen. Wenn ToolPane eine Register-Direktive neu erstellt, wird ein Anführungszeichen innerhalb eines Attributwerts nicht maskiert. Dadurch kann ein entsprechend präparierter Wert das Attribut vorzeitig beenden und eigene Direktiven einschleusen. Zu diesem Zeitpunkt hat SharePoint die Typen bereits validiert, das Steuerelement aber noch nicht instanziiert. Die zusätzlichen Direktiven können daher beliebige .NET-Klassen registrieren. Über XamlServices.Parse() führt dies zur Deserialisierung und schließlich zur Codeausführung. Die Payload von Viettel ist eine vollständig im Arbeitsspeicher gehaltene Webshell. Laut dem Forscher scheitern andere Deserialisierungstechniken häufig an fehlenden Berechtigungen für die Registry, diese Methode hingegen nicht.

Der Angreifer muss angemeldet sein, wobei bereits ein Konto mit geringen Berechtigungen ausreicht. Khoa demonstrierte außerdem einen Angriffsweg ohne vorherige Authentifizierung, bei dem die Schwachstelle mit einer bereits zuvor von Microsoft behobenen Authentifizierungsumgehung kombiniert wird. Dieser Weg funktioniert allerdings nur bei Websites, die anonymen Seitenzugriff zulassen.

Nach der Veröffentlichung folgten Angriffe. SecurityWeek berichtete, dass Previdian am 24. September erste Versuche und einen Tag später auch Webshell-Angriffe registrierte. Der zeitliche Ablauf stimmt mit der technischen Analyse von Viettel überein, über die The Hacker News bereits vor Beginn der Angriffe berichtete. Microsoft aktualisierte seinen Sicherheitshinweis am 25. September und bestätigte die aktive Ausnutzung. Am selben Tag nahm CISA die Schwachstelle in den KEV-Katalog auf, zusammen mit der MikroTik-RouterOS-Schwachstelle CVE-2026-67279. Gemäß Binding Operational Directive 26-04 mussten US-Bundesbehörden die Sicherheitslücken bis zum 28. September beheben. Die Richtlinie verlangt zudem, vor dem Einspielen des Patches zu prüfen, ob bereits eine Kompromittierung stattgefunden hat.

Warum das wichtig ist

Bereits zum zweiten Mal in Folge berichten wir über eine aktiv ausgenutzte Schwachstelle in lokal betriebenem SharePoint. Im Vormonat ging es um CVE-2026-55040, bei der Angreifer auch die Kombination mit CVE-2026-63520 untersuchten.

Die Neubewertung hat Auswirkungen über diese einzelne Schwachstelle hinaus. Ein Unternehmen, das im August nach Schweregrad priorisierte, hätte ein Spoofing-Problem mit CVSS 6,5 zunächst weit hinten eingeordnet. Das war eine vertretbare Entscheidung, die Microsofts Änderung vom 27. August jedoch vier Wochen vor den ersten Angriffen infrage stellte. Die Korrektur erfolgte in einem bereits veröffentlichten Datensatz. Ein Scanner oder Ticket, das bei der ersten Erfassung den Wert 6,5 übernommen hatte, musste ihn nicht zwangsläufig erneut abrufen. Schweregrade können sich also auch ändern, nachdem Unternehmen bereits gehandelt haben. Deshalb muss der Patch-Prozess solche nachträglichen Änderungen erkennen.

Da die Angriffe vor der Aufnahme in den KEV-Katalog begannen, schließt das August-Update zwar die Sicherheitslücke, es zeigt aber nicht, ob Angreifer sie zuvor bereits ausgenutzt haben. CISA verlangt von US-Bundesbehörden, genau das zu überprüfen. Für andere Unternehmen sollte derselbe Maßstab gelten.

Nur zwei Stunden vom Proof of Concept bis zu Angriffen auf Honeypots

Atlassian veröffentlichte am 5. Oktober Informationen zu CVE-2026-21589, einer Schwachstelle zum unauthentifizierten Lesen von Dateien mit einem CVSS-v4.0-Wert von 9,3. Betroffen sind acht selbst gehostete Produkte: die Data-Center-Editionen von Jira Software, Jira Service Management, Confluence, Bitbucket, Bamboo und Crowd sowie Crucible und Fisheye. Eine allen acht gemeinsame Bibliothek interpretiert zwei aufeinanderfolgende Doppelpunkte in einem Anfragepfad als Schrägstrich. Das reicht aus, um die Endpunkte für Plugin-Ressourcen zu verlassen und auf beliebige Dateien im Web-Root-Verzeichnis zuzugreifen. Verzeichnisauflistungen bleiben zwar gesperrt, sodass der Angreifer Dateinamen und Speicherort kennen muss. Dieser Schutz ist jedoch schwächer, als er zunächst erscheint.

Am 6. Oktober veröffentlichte watchTowr eine technische Analyse mit funktionsfähigem Exploit-Code. Previdian erklärte gegenüber Bleeping Computer, dass seine Honeypots bereits innerhalb von zwei Stunden Angriffsversuche von den IP-Adressen 38.60.157[.]86, 146.70.187[.]234, und 159.26.119[.]225 protokollierten. Inzwischen war auch eine Nuclei-Vorlage aufgetaucht. Bis zum 8. Oktober hatte Previdian laut SecurityWeek insgesamt 190 Versuche von 32 Adressen aus zehn Ländern erfasst. Beide Zeitangaben stammen ausschließlich von Previdian. Am 15. Oktober nahm CISA die Schwachstelle in den KEV-Katalog auf.

Warum das wichtig ist

In unserer September-Ausgabe hatten wir prognostiziert, dass sich die Zeitspanne zwischen der Veröffentlichung von Exploit-Code und seiner tatsächlichen Ausnutzung weiter verkürzen würde. Im August beobachteten Honeypot-Betreiber den SharePoint-Proof-of-Concept von Rapid7 am folgenden Tag im Angriffsverkehr. Nun meldete Previdian erste Versuche innerhalb von zwei Stunden. Da unterschiedliche Beobachter verschiedene Produkte untersuchten, sind die Werte vor allem als Hinweis auf die Entwicklung zu verstehen.

Zwei Stunden reichen nicht aus, um ein Change Advisory Board einzuberufen, eine Wartung anzukündigen oder ein Update längere Zeit in einer Testumgebung zu prüfen. Bei öffentlich erreichbarer Software muss die erste Reaktion auf eine kritische Schwachstelle ohne Authentifizierungsanforderung deshalb eine Schutzmaßnahme am Netzwerkrand sein, die sich innerhalb weniger Minuten umsetzen lässt. Der Patch kann anschließend nach dem vorgesehenen Verfahren eingespielt werden. Atlassian veröffentlichte zusammen mit den Updates auch Hinweise zu WAF- und Proxy-Schutzmaßnahmen und ermöglichte so diese schnelle Erstreaktion.

Prognosen für die kommenden Monate

  • Dienst- und Funktionskonten ohne eindeutig zugewiesenen Verantwortlichen werden bei einem wachsenden Anteil der M365-Vorfälle als Einstiegspunkt dienen. Ausnahmen von Sicherheitsrichtlinien halten automatisierte Prozesse am Laufen, während sich niemand für die Konten zuständig fühlt. Wir erwarten mehr Vorfallberichte, in denen für die kompromittierte Identität kein menschlicher Verantwortlicher dokumentiert ist.
  • Device-Code- und Consent-Phishing werden auch nach der Zerschlagung von EvilTokens bestehen bleiben. Die Technik hängt nicht von einer bestimmten Plattform ab. Auch Microsoft geht davon aus, dass das Geschäftsmodell die beschlagnahmte Infrastruktur überdauern wird. Wir erwarten innerhalb der nächsten zwei Quartale Nachfolgedienste, bei denen die Auswertung kompromittierter Postfächer zur Standardfunktion gehört.
  • Die Zeit zwischen der Veröffentlichung von Exploit-Code und automatisierten Scans nach verwundbaren Systemen wird weiter sinken. In diesem Monat waren es bei einer Schwachstelle ohne Authentifizierung und ohne komplexe Payload nur zwei Stunden. Die praktische Untergrenze hängt davon ab, wie schnell sich die Scan-Infrastruktur auf neue Ziele ausrichten lässt.
  • Im November und Dezember werden sich Betrugsversuche durch die Nachahmung von Versanddienstleistern und Einzelhändlern voraussichtlich häufen, wie in jedem vierten Quartal. Phishing-Kits werden Locknachrichten individuell für jeden Empfänger erzeugen, statt wiederverwendete Vorlagen zu nutzen. Dadurch entfallen die wiederkehrenden Muster, anhand derer sich saisonale Kampagnen bislang leicht filtern ließen und die Mitarbeiter erkennen konnten.

Monatliche Empfehlungen

  • Erfassen Sie sämtliche nicht menschlichen Identitäten in Ihrem Tenant und weisen Sie jeder einen namentlich benannten Verantwortlichen zu. Ändern Sie die Zugangsdaten von Funktions- und Dienstkonten regelmäßig, setzen Sie MFA durch oder stellen Sie auf Workload-Identitäten mit zertifikatsbasierter Authentifizierung um. Eine leere Anmeldehistorie sollte Anlass für eine genauere Prüfung sein. 365 Permission Manager zeigt, auf welche Ressourcen diese Konten in Teams, SharePoint und OneDrive zugreifen können.
  • Beschränken Sie den OAuth-Device-Code-Ablauf über Entra ID Conditional Access auf die Geräte, die ihn tatsächlich benötigen, und sperren Sie ihn für alle anderen. Erstellen Sie die Positivliste auf Grundlage Ihres Hardwareinventars. Richten Sie anschließend Warnmeldungen ein, wenn nach einer erfolgreichen Anmeldung eine neue Authentifizierungsmethode hinzugefügt, eine neue Posteingangsregel angelegt oder ein unbekanntes Gerät registriert wird. Führen Sie diese Ereignisse zu einem gemeinsamen Erkennungssignal zusammen, da sie einzeln oft wie unauffällige Routineereignisse wirken.
  • Aktualisieren Sie lokal betriebene SharePoint-Installationen auf den Patch-Stand von August und überprüfen Sie die Umsetzung auf jedem einzelnen Host. Untersuchen Sie anschließend, ob es vor dem Patch Hinweise auf Angriffe gab. Prüfen Sie öffentlich erreichbare Websites auf anonymen Seitenzugriff, unerwartet registrierte Assemblies und Spuren von Webshells. Bewerten Sie außerdem offene Tickets erneut, wenn der Hersteller den Schweregrad einer Schwachstelle seit Ihrer ursprünglichen Einstufung geändert hat.
  • Schulen Sie Mitarbeiter darin, Device-Code-Phishing zu erkennen, selbst wenn in der Adressleiste die korrekte URL steht. Entscheidend ist eine klare Handlungsregel: Bestätigen Sie eine Geräteanmeldung nur dann, wenn Sie sie wenige Sekunden zuvor selbst auf einem Gerät vor Ihnen gestartet haben. Mit Security Awareness Traininglässt sich dieses Verhalten einüben.

Über Hornetsecurity

Hornetsecurity ist ein weltweit führender Anbieter von Cloud-basierten Sicherheits-, Compliance-, Backup- und Security-Awareness-Lösungen der nächsten Generation, die Unternehmen und Organisationen jeder Größe auf der ganzen Welt unterstützen. Das Flaggschiffprodukt 365 Total Protection ist die umfassendste Cloud-Sicherheitslösung für Microsoft 365 auf dem Markt. Angetrieben von Innovation und Cybersecurity-Exzellenz, baut Hornetsecurity mit seinem preisgekrönten Portfolio eine sicherere digitale Zukunft und nachhaltige Sicherheitskulturen auf. Hornetsecurity ist über sein internationales Vertriebsnetz mit über 12.000 Channel-Partnern und MSPs in mehr als 120 Ländern aktiv. Seine Premium-Dienste werden von mehr als 125.000 Kunden genutzt.