[English]Mir ist von einem Blog-Leser eine sehr krude Geschichte zugespielt worden. Ein mit Microsoft Word erzeugtes Dokument enthielt eine WebEx-Einladung. Durch die Silbentrennung wurde ein "Phishing-Link" erzeugt, der auf obskure Seiten umleitete. Später stellte sich heraus, dass die PDF-Konverter die URL des Einladungslinks mit einem "-" als Trennstrich versahen und so für den Phishing-Link sorgten.
Anzeige
Eine unglaubliche Lesermeldung
Blog-Leser Florian hat sich dies Woche per E-Mail unter dem Betreff Word erzeugt "Phishing"-Angriff bei mir gemeldet und eine Beobachtung geschildert, die erneut zeigt, dass der Teufel im Detail liegt.
Der Leser schrieb mir, dass er als IT-Büro gerade ein "etwas" größeres Anrufaufkommen durch Unternehmenskunden gehabt habe. Ausgelöst worden seien die Anrufe durch einen von Word erzeugen "Phishing-Link".
Florian hat den Sachverhalt dann erklärt. Hintergrund der Aufregung war ein offizielles Schreiben einer Behörde, die zu einer Webex-Konferenz eingeladen hat. Der Teilnahme-Link zur Webex-Konferenz wurde in dem Schreiben eingefügt, und dann wurde dieses Schreiben als PDF-Dokument an die Teilnehmer verschickt.
Der Leser merkt an: "Das Schreiben wurde höchstwahrscheinlich behördentypisch in Word erstellt." Nun kann man in Microsoft Word eine automatische Silbentrennung aktivieren. Diese Option ist wohl im Word, mit dem die Einladung erstellt wurde, aktiviert gewesen. Florian schrieb dazu, dass die Word Silbentrennung dem Webex Teilnahme-Link (nachfolgend ein Beispiel):
Anzeige
*https://sqdemo6.dmz.webex[.]com/sqdemo6/k2/j.php?MTID=xxx
eine Silbentrennung verpasst. Aus dem obigen Link wird dann so etwas wie nachfolgend gezeigt – webex[.]com wird zu we-bex[.]com.
*https://sqdemo6.dmz.we-bex[.]com/sqdemo6/k2/j.php?MTID=xxx
Ich habe hier im Beitrag die Links so umgewandelt, dass keine Links entstehen – wer den Link auflösen möchte, sollte nur in einer Sandbox testen.
Falsche Link-Ziel erzeugt Redirect
Florian schrieb mir dazu: "Relevant ist hier das we-bex[.]com". Er merkte noch an, dass er diese URL bzw. die Zielseite als eher bösartig bezeichnen würde, da diese auf verschiedene andere Seiten weiter leitet. Im vorliegenden Fall wäre ein "Browser Notification Scam" angeboten worden.
In der Meinung, einer Webex-Konferenz beizutreten, bei der man auch unter Umständen auch Mikrofon- und Videoberechtigung erteilt, haben einige Teilnehmer das erlaubt und erhielten natürlich diverse Popups über Vireninfektionen.
Ein kurzer Test meinerseits
Als mir die Mail auf den Schreibtisch kam, habe ich etwas getestet. Die Domain wird nach dieser Seite seit dem 24. Juni 2021 von einer deutschen Key-Systems GmbH gehalten. Das ist ein Internetanbieter in Sankt Ingbert im Saarland. Ich tippe darauf, dass die Domain da missbräuchlich in einem Hosting-Paket (Domain-ID 2621986887_DOMAIN_COM-VRSN) registriert wurde.
Die oben verfremdete Einladungs-URL mit dem Bindestrich in der webex-URL kann man mit VirusTotal prüfen lassen. Da wird alles im "grünen Bereich" signalisiert – die Umleitung erkennt vermutlich VirusTotal.
Ich habe danach die Zieladresse mal im Inkognito-Modus eines Browsers getestet und wurde auf die oben im Screenshot gezeigte Seite per Redirect weitergeleitet. Wegen der http-URL verweigerte der Browser das Rendering. Dann habe ich die betreffende Redirect-URL erneut in VirusTotal prüfen lassen.
Das Ergebnis sieht jetzt bereits anders aus – mehrere Virenscanner erkennen das Ziel als schädliche oder verdächtige Seite. Also Finger weg von der URL.
Wer es selbst testen möchte
Blog-Leser Florian hat mir noch beschrieben, wie man dies testen könne. Nachbauen können das jeder selbst in Microsoft Word, indem ein Dokument mit der Schriftgröße 11 und automatischer Silbentrennung aktiviert, verfasst wird (siehe Screenshot).
Florian schloss seine erste Mail mit "Evtl. interessant für deine Leser – kann ich nicht beurteilen. Ich musste es einfach irgendwo loswerden, da das einer besten und erfolgreichsten Phishing-Versuche der letzten Zeit ist. Wäre dahinter eine gefälschte Anmeldeseite für ein Citrix Portal, Microsoft 365 oder ähnliches gewesen, die Benutzer hätten sich mit sehr hoher Wahrscheinlichkeit dort angemeldet." Er merkte an, dass er das Beispiel auf jeden Fall in die Security Awareness-Trainings des Unternehmens einfließen lässt.
Word ist unschuldig – es passiert beim PDF-Export
Ich hatte dem Leser meine obigen Erkenntnisse mit dem Kurztest auf VirusTotal mitgeteilt. Darauf hin meldete sich Florian in einer Folgemail und schrieb, dass sie im Unternehmen mit VirusTotal noch nichts geprüft hätten. Es wurde von der IT nur der erste Redirect, der per JavaScript passiert, bemerkt. Im IT-Umfeld wird auf den Clients in der Regel eine Sicherheitslösung von Trend Micro eingesetzt, die das Problem mit dem Redirekt auf eine schädliche Seite aber auch nicht erkennen.
Interessenhalber haben die Leute in der IT noch etwas weiter getestet und herausgefunden, dass das Problem nicht durch Microsoft Word verursacht wird. Hier seine Testergebnisse:
- Klickt man den Link in Microsoft Word direkt an, ist die URL korrekt und ohne den Bindestrich in der Auflösung.
- Exportiert man die Datei mit der in Microsoft Word integrierten Funktion dafür [in eine PDF-Datei] passt der Link auch.
- Druckt man die Datei mit dem PDF-Dokument aus Microsoft Word heraus mit PDF24 oder dem Microsoft PDF Drucker, dann ist der Link falsch.
Der Leser merkt dazu an, dass er vermutet, dass das Problem auch auch bei anderen PDF-Druckern wie Print2PDF so auftritt. Florian glaube zwar tatsächlich nicht, dass das jemand beabsichtigt hat, und die Domain genau dafür registriert hat. Ich gehe aber davon aus, dass sich schon jemand die Bindestrich URL für zwielichtige Zwecke registriert hat.
Florian merkt an, dass dieser "Phishing-Ansatz" nicht zu Ende gedacht sei. Denn die Redirekt-URL müsste eine schädliche exe-Datei zum Download anbieten, damit viele Opfer diesen Download dann ausführen würden. Das sei ja auch bei der regulären Teilnahme an einem Meeting oft so. Hier würde ich nicht wirklich mitgehen, denn der Inhaber der Domain kann mit seinem Redirect ja auf beliebige Ziele verlinken und wahlweise Phishing-Seiten, Downloads oder was weiß ich anbieten. Also den obigen Sachverhalt einfach mal auf dem Radar behalten.
Anzeige
Solche Angriffe bzw. Angriffsketten stecken praktisch hinter jedem Phishing Link.
Haarsträubend, da kann jemand seinen Job nicht, so hart man das sagen muss.
Wie auch im Artikel angemerkt, ist das viel zu kurz gedacht. Der Ansatz leitet nicht immer für jeden über die gleichen Redirect Ketten zum gleichen Ziel. Je nach IP-Bereich oder Anzahl Aufrufe eines Besuchers oder auch erkannten anderen Schwachstellen im jeweiligen Browser passieren oftmals ganz unterschiedliche Dinge in unterschiedlichen Schritten und unterschiedlichen Kettenlängen.
Es ging mir tatsächlich nicht um die Funktionsweise von Phishing-Links, das ist hinreichend dokumentiert und bekannt.
Mir ging es eher um den konkreten Fall, dass ein PDF mit einer Einladung für eine WebEx auf offiziellen Briefpapier an eine große Anzahl an Teilnehmern verschickt wurde. Die Word Silbentrennung hat den darin ein kopierten WebEx Link dann zum Phishing-Link gemacht hat.
Aufgrund des offiziellen Charakters der Einladung hat da praktisch keiner der Teilnehmer darauf geachtet, dass es ein Phishing-Link sein kann. Das machte diesen "Angriff" erfolgreich.
"Der IT" war die Funktionsweise mehrstufig verketteter Redirects offenbar nicht hinreichend bekannt, hoffentlich hat man daraus gelernt.
Die IT kam ja erst ins Spiel nachdem Benutzer den Link aufgerufen hatten und die Benutzer Notification Scam im Browser hatten. Das Kind war zu diesem Zeitpunkt schon in den Brunnen gefallen.
Benutzer wollten am WebEx Teilnehmen und sind es gewohnt in diesem Zusammenhang alles mögliche zu bestätigen (Mikro, Kamera, Benachrichtigungen).
EDR und Firewall hatten da nichts dagegen, was ja häufig genug der Fall ist.
Was soll die IT da machen außer sowas zukünftig auch zu schulen? Tausende verschiedene Redirects verfolgen? Das ist ja auch irgendwie sinnlos.
Die IT sollte bemerken, dass es mehr als einen Redirect gibt.
Weiterhin, dass es beim Anklicken dieser Links zu den unterschiedlichen Angriffen auf die unterschiedlichsten Dingen gekommen ist.
Die IT könnte die Systeme so einrichten, dass für legitime WebEx Meetings keine Klicks auf alles Mögliche durch die Benutzer notwendig sind?
Denn durch den aktuell beschriebenen Zustand "erzieht" man die Leute sozusagen dazu, egal was immer und überall anzuklicken.
"Bemerkt" ist hier das falsche Wort, "untersucht" würde es eher treffen, wobei sich das "untersuchen" darauf beschränkt hat, sich den Quellcode der Seite anzusehen und zu sehen, dass da "window.location.replace" mit wechselnden obfuskierten URLs waren.
Ja natürlich, könnte man, aber – wie wir alle wissen – nie zu 100 % irgendwas kommt doch immer durch. Ich halte daher nichts davon, die Benutzer in IT-Security-Watte zu packen. Das führt dazu, dass die Benutzer meinen, dass die IT das schon richtig sicher konfiguriert und sie nicht aufpassen müssen.
Viel lieber sind mir Benutzer, die eine Awareness für IT-Sicherheit haben, im Idealfall verstehen, was sie da klicken und sich auch trauen sich zu melden, wenn etwas passiert ist.
Awareness zu schaffen funktioniert am besten, wenn man Fehler macht. Das sollte natürlich im Idealfall in Simulationen passieren, nicht in der Produktivumgebung.
Versteh mich nicht falsch, man muss immer aus Fehlern lernen, sowohl was die Technische- als auch die Awareness-Komponente betrifft. Man muss sich anschauen, ob Browser Notifications aktiviert hätten sein müssen oder ob man die zentral deaktiviert. Aber wenns nicht Browser Notifications sind, dann sind es irgendwelche Downloads, Zero-Days, oder oder oder
Aber das zu diskutieren war tatsächlich nicht das Ziel und man kann darüber ganze Vorlesungen füllen. Dazu können wir uns gerne auf anderen Kanälen austauschen.
Ich fand tatsächlich den Weg wie der Link entstanden ist bemerkenswert und was es da evtl. noch für Links gibt, die so verändert werden.
In einem Test mit UrlScan.io konnte ich den Redirect nicht bestätigen, weder mit einem Desktop- noch einen Mobile-UserAgent.
Eine neue und recht ausführliche Beschreibung von "malicious redirect" ist
https[:]//www.godaddy.com/resources/news/dollyway-malware-c2-tds
Das heißt nichts. Gerade per VirusTotal die URL im Blog-Beitrag getestet – wird nun als sauber angezeigt. Kann sich aber jederzeit ändern. Gerade die Haupt-Domain aus dem Link im Browser geprüft – es gab sofort einen Redirect und dann nochmals einen Redirect auf eine gefakte Seite mit ZDF-Logo zur angeblichen Rubrik "Politik und News" – mit unsinnigen Aussagen. Beim zweiten Aufruf ging es dann zu einer Kasino-Seite mit Online-Spielen.
Typisches "false negative" bei Virustotal, die im Artikel genannte sqdemo6.dmz.we-bex[.]com URL ist weiterhin "armed" und leitet auf Redirectketten weiter…
Mit einer Anfrage aus den USA, einem iPhone UserAgent und gesetztem Referrer ging es:
https[:]//urlscan.io/result/0195e1be-eda9-7ee5-b42c-0ec14e52be19/#transactions
Die we-bex.com-Domäne ist sicher eine absichtliche Phishing-Domäne, die sich den Umstand, dass Word URLs silbentrennt, zunutze macht.
Bei ausgedruckten oder abgetippten Adressen kommt der ahnungslose Leser zur Phishing-Website, dazu kommen noch die Benutzer von PDF-Druckertreibern (die entweder Links gar nicht hinterlegen, oder eben die ausgedruckte URL erkennen und parsen, da sie als Druckertreiber die URL dahinter ja nicht kennen können. Das kann nicht nur mit Word, sondern mit allen Programmen, die eine automatische Silbentrennung durchführen, passieren.
Schade nur, dass Word es nicht erlaubt, die Silbentrennung für einzelne Wörter oder erkannte URLs auszuschalten. Der Workaround wäre, die automatische Silbentrennung für den ganzen Absatz auszuschalten, und dann bei längeren Wörtern an passender Stelle bedingte Trennstriche einzufügen.
Libreoffice trennt in der Standardeinstellung ebenfalls URLs, aber man kann – als automatisierte Lösung – bei den Zeichenformaten für Internet-Links als Sprache "Keine" festlegen, wodurch auch die Trennung unterbleibt, da es ja dann keine Trennungsregeln dafür gibt. Ansonsten bei Format>Zeichen für die URL manuell als Sprache "keine" zuweisen.
Da mir im Moment kein PC mit MS Office zur Verfügung steht, kann ich nicht überprüfen, ob das Zuweisen von "keine Sprache" an bestimmte Wörter auch in Word ein gangbarer Weg wäre.
Moin, das erinnert mich an einen Vorfall letztens daheim.
Mein Lenovo X1 Extreme hat seid Auslieferung das Problem das die "G"-Taste fest gedrückt werden muss.
Sobald man die namenhafte Suchmaschine aus dem Alpha Konzern aufrufen möchte und eins oder gar beide "G"'s nicht eingibt, wird man auf diverse spannende Seiten weitergeleitet.
Bitte NUR im Sandbox System testen!!!
Virustotal meint dann so etwas: