[Neue Bedrohungsinformation] Europäischer Sicherheitsanbieter Ziel einer ausgeklügelten Phishing-Kampagne über Cisco-Domain

Am 13. März 2026 entdeckte und blockierte das Threat-Intelligence-Team von Outpost24, der Muttergesellschaft von Specops, eine hochentwickelte Multi-Chain-Phishing-Kampagne, die sich als Cisco, ein globaler Anbieter von Netzwerkausrüstung, ausgab. Unser Team konnte den Angriff frühzeitig erkennen, stoppen, bevor Systeme kompromittiert oder Benutzer betroffen wurden, und teilte die Erkenntnisse, um anderen Organisationen bei der Abwehr ähnlicher Kampagnen zu helfen.

Der Angriff war komplex und nutzte mehrere vertrauenswürdige Dienste sowie kompromittierte legitime Infrastrukturen, um das endgültige Phishing-Ziel zu verschleiern. Mehrere Umleitungsstufen führten die Opfer über seriöse oder ehemals vertrauenswürdige Domains, wodurch die Wahrscheinlichkeit verringert wurde, dass Sicherheitslösungen oder reputationsbasierte Filter die Links blockieren.

Die Angreifer implementierten sogar einen legitimen Cloudflare-basierten „Human Validation“-Schritt, um sicherzustellen, dass nur echte Personen die Landingpage sehen, auf der Anmeldedaten abgefragt werden. Unser Team hat den Angriffspfad in sieben klare Schritte gegliedert und Handlungsempfehlungen zur Abwehr bereitgestellt.

Sieben Stufen der Angriffskette

Schritt 1: Initialer Köder

Der Angriff beginnt mit einer sorgfältig gestalteten E-Mail, die den Finanzdienstleister JP Morgan imitiert. Sie wird so präsentiert, dass sie Teil eines bereits bestehenden E-Mail-Threads zu sein scheint, was eine bekannte Technik ist, um die Glaubwürdigkeit von Phishing-Versuchen zu erhöhen. Die Nutzer erhalten eine Nachricht mit dem Text: „Ein Dokument steht zur Prüfung und Unterzeichnung bereit.“

Erste Phishing-E-Mail

Die Untersuchung zeigte, dass die E-Mail über DomainKeys Identified Mail (DKIM) von em.37nmtc.com signiert war, zusätzlich mit einer Signatur von Amazon Simple Email Service (SES).

Die DKIM-Signatur wurde erfolgreich validiert, sodass die Nachricht die DMARC (Domain-based Message Authentication, Reporting and Conformance)-Authentifizierung bestand, obwohl kein gültiger SPF (Sender Policy Framework)-Eintrag vorhanden war. Somit erschien die E-Mail für Microsoft 365 Mail-Schutzsysteme authentisch und vertrauenswürdig.

DKIM-signierte E-Mail von em.37nmtc.com mit einer Phishing-Nachricht von „normaler Qualität“
Authentication-Results: spf=none (sender IP is 69.169.224.13) smtp.mailfrom=em.37nmtc.com; dkim=pass (signature was verified) header.d=37nmtc.com;dkim=pass (signature was verified) header.d=amazonses.com;dmarc=pass action=none header.from=37nmtc.com;compauth=pass reason=100 Received-SPF: None (protection.outlook.com: em.37nmtc.com does not designate permitted sender hosts)

Schritt 2: Cisco Secure redirect

Der Link „Dokument prüfen“ verweist auf eine URL von secure-web.cisco.com, einer legitimen Cisco-Domain. Diese Domain wird verwendet, um Links in E-Mails umzuschreiben und sicherzustellen, dass Empfänger keine externen URLs direkt öffnen, es sei denn, sie wurden von Cisco überprüft und als sicher eingestuft.

Ironischerweise erhalten Angreifer, die eine E-Mail über Cisco Secure Email Gateway mit einem nicht als bösartig markierten Link senden, ein wertvolles Asset: eine Redirect-URL innerhalb der Cisco-Infrastruktur, der Benutzer eher vertrauen, und die viele Erkennungssysteme umgehen kann.

Sicherer „Cisco“-Phishing-Link, der im Dokument bereitgestellt wird

hxxps[:]//secure-web.cisco.com/1aL6ss11Orq2hbHreIVXzBwsVL_VtTGpsnWld4nI4zcao-PH1ayVpw3VCsSc-nkb7tqLEjOiHObISdpA9w_-f5hmMQI_IUeM2i46yl1kSw6GUVsuvQ0hacn91qTFvO3LtCbKhUb8HhT3kE5FU6dHf3OBeUMn4Mc2EePTWYjRH8Fuc-CXFHgmLWmPq0NUQ0EejCYkDDEuZSRC6VMjj84CnS6S-fFa8k_79jvbWe12eJ_mz6jNHzElPPKPC_E8VaIUvXtzUz85bZP3A9v45bIvrjfZ5VbiDdOBke-AAKAbtAtLcMt0U1h68_JBGO2K4PU2KyTwFHUliw9ED1V_SakNA8_1lXEP6FQhBpmQdyiNYQ8qL7GgfgNIcjDnY09J8tG_Mo21Wn_qJzzIFJoWSIYOBgW5Ih_eZ9UxikO_KiH_K5DKFO1QBkmtrpHYphv1vr8qe4qIoDdbQgpwmaQ66O3keJiBNRI8dv8bb-u8waewntfc/https%3A%2F%2Ftracking.us.nylas.com%2Fl%2Fe5fd23c84ad341959b1b1f99863d6ef7%2F0%2Fa2000da7f0c0b9f1da537753529477b583df272c3dbafb1fc15b0afade3ca218%3Fcache_buster%3D1773349270

Wenn der Link geöffnet wird, wird die Anfrage an die Cisco Secure Web-Infrastruktur gesendet, die mit einer Weiterleitung (Redirect) auf die nächste Stufe der Angriffskette reagiert.

Antwort von Cisco Secure-Web:

Antwort von Cisco Secure-Web
hxxps[:]//tracking.us.nylas.com/l/e5fd23c84ad341959b1b1f99863d6ef7/0/a2000da7f0c0b9f1da537753529477b583df272c3dbafb1fc15b0afade3ca218?cache_buster=1773349270

• HTTP/2 302 Found
• Server: openresty/1.27.1.2
• Content-Type: text/html
• Content-Length: 0
• Talos-Dc-Id: 3

Antwort von Cisco Secure-Web

Schritt 3: Nylas-Redirect

Nach der initialen Weiterleitung von der Cisco Secure Web-Infrastruktur wird die Anfrage an tracking.us.nylas.com weitergeleitet.

Nylas ist eine weit verbreitete E-Mail-API-Plattform, die E-Mail-Synchronisation, Tracking und Automatisierung für Entwickler bereitstellt. In diesem Fall missbrauchen die Angreifer offenbar die Linktracking- und Redirect-Funktion, um das Opfer weiter entlang der Phishing-Kette zu führen.

Die Verwendung der Nylas-Infrastruktur resultiert wahrscheinlich aus dem Bedürfnis der Angreifer, einen Link zu erzeugen, der durch die Cisco Secure Web-Infrastruktur weitergeleitet wird, ohne Verdacht zu erregen. Für diesen Zweck könnte jede etablierte und legitime Plattform, die die Erstellung von Redirect-Links unterstützt, verwendet werden.

Sobald die Anfrage die Nylas-Infrastruktur erreicht, führt diese sofort eine weitere Weiterleitung zur nächsten Stufe des Angriffs durch.

Nylas-Antwort: HTTP/2 301 Moved Permanently

Location: hxxps[:]//infra.infratechcorpsolutionllp.com/MQadYJ7z29BJTL.pdf

Nylas-Antwort

Durch die Verkettung von Redirects über legitime Dienste wie Cisco und Nylas erhöhen die Angreifer die Wahrscheinlichkeit, dass der Link Sicherheitsfilter und Reputationsprüfungen passiert. Diese Domains sind weithin vertrauenswürdig und werden im legitimen Datenverkehr häufig beobachtet, was automatisiertes Blockieren erschwert.

Der Redirect führt das Opfer zur nächsten Stufe des Angriffs, die auf infra.infratechcorpsolutionllp.com gehostet wird.

Schritt 4: Kompromittierte Infrastruktur

Die Opfer werden nun auf eine Seite geleitet, die wie ein PDF-Dokument aussieht:

Opfer auf kompromittierte Infrastruktur weitergeleitet

Die Domain infratechcorpsolutionllp.com gehört offenbar zu einer legitimen Entwicklungsfirma mit Sitz in Indien. Das Subdomain infra.infratechcorpsolutionllp.com wirkt jedoch deutlich verdächtiger.

Obwohl der Redirect aus dem vorherigen Schritt auf eine .pdf-Datei zu zeigen scheint, liefert der Server tatsächlich keine Datei. Stattdessen gibt er eine weitere Umleitung auf eine andere Domain zurück. Unsere Tests zeigten, dass jede Anfrage an eine URL mit einem nicht-leeren Pfad auf diesem Host dasselbe Redirect-Verhalten auslöst.

Sowohl die Hauptdomain als auch das Subdomain nutzen dieselbe Hosting-Infrastruktur, was darauf hindeutet, dass die Angreifer möglicherweise Zugriff auf den Server erlangt und bösartige Redirect-Logik implementiert haben, die auf eine andere Website verweist.

Bösartige Weiterleitungslogik

HTTP/2 302 Found

Location: https://www-0159.com/

Schritt 5: Redirect über wiederregistrierte Domain

Nach dem decoy PDF-Endpunkt werden die Opfer zu www-0159.com weitergeleitet. Die Analyse der Domain-Historie zeigt, dass sie ursprünglich über mehrere Jahre existierte und erstmals 2017 von einem chinesischen Akteur registriert wurde. Seitdem wurden für die Domain mehrere TLS-Zertifikate von verschiedenen Zertifizierungsstellen weltweit ausgestellt. Das vorherige TLS-Zertifikat lief jedoch am 7. März 2026 ab, und die zugehörigen DNS-Einträge wurden kurz darauf freigegeben.

Am 12. März 2026 wurde die Domain erneut registriert und am selben Tag mit mehreren neuen TLS-Zertifikaten ausgestattet. Der Zeitpunkt deutet stark darauf hin, dass die Domain speziell für diese Kampagne wiedererworben und wiederverwendet wurde.

Diese Technik erlaubt es den Angreifern, Domains zu nutzen, die zuvor legitimen Gebrauch hatten und möglicherweise noch über eine gewisse Rest-Reputation verfügen. Das erneute Registrieren abgelaufener Domains kann dazu beitragen, dass bösartige Infrastrukturen gegenüber automatisierten Sicherheitssystemen weniger verdächtig erscheinen als neu erstellte Domains.

Von hier aus wird die Anfrage erneut zur letzten Stufe der Angriffskette weitergeleitet, die auf tradixyu.cfd gehostet wird, wo die Phishing-Infrastruktur hinter Cloudflare betrieben wird.

Schritt 6: Anti-Bot- und Human-Validation

Die Hosting-Umgebung von tradixyu.cfd nutzt Cloudflare, das den Ursprungsserver verschleiert und eine zusätzliche Schutzschicht für die Infrastruktur der Angreifer bereitstellt.

Wenn das Opfer diese Stufe erreicht, wird ein Browser-Validierungs-Check angezeigt, der eine manuelle Interaktion erfordert. Dieser Schritt soll automatisierte Analysetools, Sandbox-Umgebungen und Sicherheits-Scanner blockieren, die versuchen, bösartige Links zu verfolgen.

Validierungsseite

Erst nachdem der Benutzer die Validierung abgeschlossen hat, lädt die Seite den Phishing-Inhalt weiter. Anschließend zeigt die Seite an, dass das System „compliant“ ist, bevor das Opfer schließlich auf eine gefälschte Microsoft 365-Anmeldeseite weitergeleitet wird.

Schritt 7: Finale Microsoft-Anmeldeseite

Diese sehr überzeugende Phishing-Seite ist darauf ausgelegt, Anmeldedaten zu sammeln. Wie der Rest der Angriffskette ist auch dieser Schritt sorgfältig konstruiert, von einer gefälschten Ladeanimation, die Outlook imitiert, bis hin zu einer Überprüfung, die validiert, ob die eingegebene Information tatsächlich eine E-Mail-Adresse ist.

Im letzten Schritt versucht die Seite einen legitimen Login, um zu überprüfen, ob die erfassten Zugangsdaten gültig sind.

Anmeldeseite

Beobachtungen

Die Merkmale dieses Angriffs deuten auf Kratos hin, ein relativ neues Phishing-as-a-Service-Kit (PhaaS), das in letzter Zeit aufgrund seiner Vielzahl an Funktionen zunehmend an Popularität gewinnt. Dazu zählen die Fähigkeit, legitime Websites zu imitieren, Maßnahmen zur Verhinderung von Analysen sowie mehrere QoL-Funktionen (Quality-of-Life-Funktionen), die das Starten und Betreiben komplexer Kampagnen erleichtern.

Kampagnen wie diese zeigen, dass moderne Phishing-Angriffe zunehmend auf geschichtete Infrastrukturen und legitime Dienste setzen, um Erkennungssysteme zu umgehen. Sie verdeutlichen auch, dass Phishing inzwischen eine der „Industrien“ der Cyberkriminalität ist, die immer professioneller wird, mit Gruppen und Organisationen, die sich auf die Entwicklung und Wartung immer komplexerer Funktionen spezialisieren.

In diesem Fall kombinierten die Angreifer DKIM-signierte E-Mail-Zustellung (DomainKeys Identified Mail), vertrauenswürdige Redirect-Infrastruktur, kompromittierte Webserver und Cloudflare-geschützte Phishing-Seiten, um die finale Phase des Sammelns von Zugangsdaten zu verschleiern. Diese Art von Angriff zeigt, dass selbst geschulte Nutzer, die verdächtige E-Mails erkennen sollen, von gut konzipierten Phishing-Kampagnen getäuscht werden können.

„Das Volumen und die Qualität der Werkzeuge, die Bedrohungsakteuren zur Verfügung stehen, einschließlich staatlich unterstützter Akteure, ist erheblich und wächst weiter. Die Vorstellung, dass ein Passwort oder sogar ein Passwort plus eine Standard-Multi-Faktor-Authentifizierung (MFA) einen ausreichenden Schutz gegen einen hartnäckigen, gut ausgestatteten Angreifer bietet, wird zunehmend schwer aufrechtzuerhalten.
„Insbesondere KI-unterstütztes Phishing erhöht die Basisqualität von Social-Engineering-Versuchen auf ein Niveau, bei dem selbst sicherheitsbewusste Nutzer gelegentlich scheitern. Das ist keine Kritik an den Nutzern, sondern eine strukturelle Realität, auf die Sicherheitsteams reagieren müssen.
„Die richtige Reaktion besteht nicht darin, zu versuchen, Nutzer unfehlbar zu machen. Vielmehr sollten Architekturen so gestaltet werden, dass ein kompromittiertes Credential allein einem Angreifer keinen sinnvollen Zugriff verschafft.“

Martin Jartelius, Product Director bei Outpost24, zum Angriff

Um dies zu verhindern, setzen Organisationen zunehmend auf Kontrollen, die nicht nur die Benutzeridentität, sondern auch den Sicherheitsstatus des zugreifenden Geräts validieren.

Strategien zur Schadensbegrenzung

Eine praktische Verteidigung gegen Angriffe dieser Art ist gerätegebundener Zero Trust access, bei dem Authentifizierungsentscheidungen nicht nur von der Benutzeridentität, sondern auch vom Sicherheitszustand des Geräts abhängen.

Specops Device Trust (ehemals Infinipoint), Specops’ Zero Trust Access Lösung, ermöglicht es Organisationen, dieses Modell umzusetzen, indem die Gerätepostur kontinuierlich überprüft wird, bevor Zugriff auf Unternehmensanwendungen und Ressourcen gewährt wird. Mit gerätegebundenen Zugriffskontrollen gilt:

• Gestohlene Zugangsdaten allein ermöglichen keinen Zugriff auf geschützte Ressourcen
• Authentifizierungsanfragen müssen von bekannten, richtlinienkonformen Geräten kommen
• Zugriffsentscheidungen können Echtzeit-Prüfungen der Gerätepostur einbeziehen, einschließlich Betriebssystemkonfiguration und Sicherheitskontrollen
• Entspricht ein Gerät nicht mehr den Richtlinien, wird der Zugriff blockiert oder eingeschränkt, bis das Problem behoben ist

Durch die Bindung der Authentifizierung an verifizierte Geräte statt nur an Credentials können Organisationen die Auswirkungen von Phishing-Kampagnen, die auf das Sammeln von Passwörtern und Session-Tokens abzielen, erheblich reduzieren.

Lassen Sie uns sprechen

Die Verteidigung gegen zunehmend komplexe Phishing-Kampagnen erfordert die Implementierung robuster Identity-Security-Lösungen. Für weitere Informationen, wie Specops Ihre Organisation unterstützen kann, kontaktieren Sie uns noch heute oder buchen Sie eine Demo, um unsere Lösungen in Aktion zu sehen.