Gefälschte Voicemails, echte Malware: Ein Einblick in eine SVG-Schmuggelkampagne mit 26.000 E-Mails
Im Rahmen einer zweimonatigen Phishing-Kampagne wurden schädliche JavaScript-Dateien als harmlose Voicemail-Anhänge getarnt, wobei die Dateien fälschlicherweise als „Klartext“ gekennzeichnet wurden, um Anhangsprüfprogramme zu umgehen. „ INKY “ hat alle 26.589 Nachrichten erkannt und markiert.
Zwischen dem 1. Juni und dem 4. August 2026 verfolgte und identifizierte „ INKY “ eine anhaltende Phishing-Kampagne, bei der ein täuschend einfacher Köder – eine Benachrichtigung über eine verpasste Voicemail – genutzt wurde, um in einer Bilddatei versteckten Schadcode zu verbreiten. Die Kampagne betraf 5.527 Organisationen und führte zu 26.589 erkannten E-Mails.
Jede E-Mail wurde abgefangen und als gefährlich markiert. Die Angreifer setzten auf ein Dateiformat, das von den meisten Menschen und vielen E-Mail-Filtern als harmlos angesehen wird: das SVG-Bild.
In diesem Blogbeitrag wird erläutert, was SVG-Dateien sind, warum Angreifer sie im Jahr 2026 als Mechanismus zur Verbreitung von Malware genutzt haben und wie diese Kampagne genau ablief. Außerdem analysieren wir das verschleierte JavaScript, das im Anhang versteckt war, den Trick, mit dem die Angreifer die Datei als Klartext getarnt haben, und wie „ INKY “ sie in allen betroffenen Unternehmen erkannt hat.
Was ist eine SVG-Datei, und warum ist sie bei Angreifern so beliebt?
SVG (Scalable Vector Graphics) ist ein Bildformat, besteht jedoch im Gegensatz zu JPEG oder PNG nicht aus Pixeln. Eine SVG-Datei ist eine in XML geschriebene Textdatei, die Formen, Linien und Text mathematisch beschreibt, sodass das Bild ohne Qualitätsverlust auf jede beliebige Größe skaliert werden kann. Logos, Symbole und Diagramme im Internet liegen häufig im SVG-Format vor.
Es gibt jedoch einen entscheidenden Unterschied zwischen einer SVG-Datei und einem normalen Bild: Eine SVG-Datei kann Code enthalten. Die SVG-Spezifikation erlaubt es, Skripte – darunter auch JavaScript – direkt in die Datei einzubetten, sodass Grafiken interaktiv gestaltet werden können. Wenn eine SVG-Datei in einem Webbrowser geöffnet wird, wird dieses eingebettete JavaScript ausgeführt. Eine PNG-Datei kann dies niemals leisten. Eine SVG-Datei hingegen schon.
Genau diese Eigenschaft machen sich Angreifer zunutze. Für den Menschen – und für viele Sicherheitstools – sieht eine SVG-Datei wie ein Bild aus. Für einen Browser kann sie jedoch als Träger für ein Programm dienen. Diese Diskrepanz zwischen der Wahrnehmung der Datei und ihren tatsächlichen Funktionen bildet die Grundlage für die als „SVG-Smuggling“ bekannte Technik.
|
Warum SVGs die Abwehr durchschlüpfen
E-Mail-Sicherheitsgateways haben jahrelang gelernt, gefährliche Anhangstypen wie ausführbare Dateien, Skripte, makrofähige Dokumente und Archive zu blockieren. SVG-Dateien wurden in der Vergangenheit als harmlose Bilder behandelt und durchgelassen. Das ist Angreifern nicht entgangen. Indem sie ihr JavaScript in eine SVG-Hülle verpacken, schleusen sie aktiven Code in einem Dateiformat ein, das viele Filter nie auf diese Weise zu überprüfen konfiguriert wurden. |
Eine zunehmende Bedrohung im Jahr 2026
SVG-basierte Angriffe sind kein neues Phänomen. Forscher haben bereits seit etwa 2017 bösartige SVG-Anhänge dokumentiert, doch ihre Verbreitung nahm im Jahr 2026 explosionsartig zu. Dabei änderten sich zwei Dinge: das Ausmaß der Kampagnen und die Raffinesse der Verschleierung.
- Fünfzigfacher Anstieg. Laut dem „Phishing Trends Report 2026“ von Hoxhunt hat sich die Zahl der bösartigen SVG-Anhänge im Jahr 2025 gegenüber 2024 verfünfzigfacht und sie rangieren nun hinter PDF- und HTML-Anhängen auf Platz drei der häufigsten Arten bösartiger E-Mail-Anhänge.
- Groß angelegte Einzelkampagnen. Im Rahmen einer von Microsoft verfolgten Kampagne im Februar 2026 wurden rund 1,2 Millionen SVG-basierte Phishing-Nachrichten an mehr als 53.000 Organisationen in 23 Ländern versendet. Das SANS Internet Storm Center dokumentierte im Juni 2026, dass dieselbe Technik die Posteingänge überschwemmte.
- Inhaltslose Nutzdaten. Bei der Analyse aktueller Beispiele stießen die Forscher auf SVG-Dateien, die keinerlei grafische Inhalte enthielten. Die Datei dient ausschließlich dazu, verschleiertes JavaScript in den Browser des Opfers zu übertragen, während sie vom E-Mail-Gateway als Bild klassifiziert wird.
- Voicemail-Köder. Mehrere Anbieter, darunter Sublime Security und ReversingLabs, haben SVG-Anhänge dokumentiert, die als Voicemail- oder verpasste Anruf-Benachrichtigungen getarnt sind – genau der Köder, der in der hier beschriebenen Kampagne verwendet wurde.
Die Kampagne „ INKY “ folgt genau diesem Muster und fügt eine zusätzliche Ausweichmöglichkeit hinzu, indem der Dateityp der SVG-Datei fälschlicherweise als „Klartext“ gekennzeichnet wird.
Die Kampagne im Überblick
Jede Nachricht dieser Kampagne folgte derselben Vorlage: eine gefälschte interne E-Mail, die vorgab, eine Benachrichtigung über eine Voicemail zu sein, und einen oder mehrere SVG-Anhänge enthielt, bei denen es sich tatsächlich um verschleiertes JavaScript handelte. Die folgenden Statistiken stammen direkt aus den Telemetriedaten von „ INKY “ für den beobachteten Zeitraum.
| Metrisch | Wert |
|---|---|
| Gesamtzahl der erkannten E-Mails | 26,589 |
| Betroffene Organisationen | 5,527 |
| Kampagnenzeitraum eingehalten | 1. Juni – 4. August 2026 (laufend) |
| Bewertung der Bedrohung | 100 % erkannt |
| Thema „Köder“ | Benachrichtigung über verpasste Voicemail-Nachrichten / Anrufe |
| Nutzlast | SVG-Anhang, der verschleiertes JavaScript enthält |
| Anzeichen für Ausflüchte | SVG-Anhang als „text/plain“ deklariert |
| Wichtigste Erkennungssignale | Phishing-Inhalte (100 %), gefälschter interner Absender (95 %) |
| Personalisierung | In 99,5 % der Betreffzeilen war der E-Mail-Name des Empfängers enthalten |
Tabelle 1: Zusammenfassung der Kampagne anhand der PhishFence-Telemetriedaten von INKY , 1. Juni bis 4. August 2026.

Abbildung 1: Tägliches Volumen der erkannten E-Mails während der gesamten Kampagne. Die Aktivität verlief in Wellen und erreichte am 3. Juni ihren Höhepunkt (2.432 E-Mails bei 1.149 Organisationen), wobei Ende Juli ein deutlicher Wiederanstieg zu verzeichnen war. An den Wochenenden, an denen die Kampagne pausierte, sind Lücken zu erkennen.
Breitstrahl, kein gezielter Einsatz
Die Verteilung der E-Mails auf die verschiedenen Organisationen deutet eher auf eine breit angelegte, opportunistische Kampagne als auf eine gezielte Aktion hin. Von insgesamt 5.527 Organisationen erhielt die durchschnittliche Organisation lediglich zwei E-Mails, und 32 % erhielten nur eine. Die zehn am stärksten betroffenen Organisationen machen zusammen lediglich 6 % des Gesamtvolumens aus. Es gibt keine Konzentration auf eine kleine Gruppe hochwertiger Ziele, was das Kennzeichen einer Sprühkampagne ist, die auf das breite Sammeln von Zugangsdaten ausgelegt ist, und nicht auf einen maßgeschneiderten Spear-Phishing-Angriff.

Abbildung 2: Verteilung der E-Mails nach Organisation. Die überwiegende Mehrheit der Organisationen erhielt nur eine Handvoll Nachrichten, während eine sehr kleine Gruppe von Organisationen stärker betroffen war, was bestätigt, dass es sich eher um eine breit gestreute E-Mail-Aktion als um gezielte Zustellungen handelte.
Abgestimmt auf die Arbeitswoche
Der Versandrhythmus der Kampagne untermauert den Eindruck einer Aktion, die auf Plausibilität ausgelegt ist. Das Versandvolumen konzentrierte sich auf Montag bis Donnerstag und erreichte am Mittwoch seinen Höhepunkt, während an den Wochenenden so gut wie nichts versendet wurde. Dies passt zu einer Lockaktion, die so konzipiert ist, dass sie zu einem Zeitpunkt eintrifft, zu dem die Empfänger aktiv arbeiten und eine Benachrichtigung über einen verpassten Anruf als ganz normal empfunden wird.

Abbildung 3: Kampagnenvolumen nach Wochentag. Der Versand konzentriert sich auf Montag bis Donnerstag und kommt am Wochenende praktisch zum Erliegen.
Individuell gestaltet anhand der Adresse der Zielperson
In 99,5 % der Nachrichten war der Anzeigename in der Betreffzeile eine exakte Kopie der Zeichenfolge vor dem @ in der E-Mail-Adresse des Empfängers selbst. Ein Empfänger mit der Adresse jsmith@… würde beispielsweise einen Betreff wie „mCaller hat Jsmith verlassen, 34s Vorschau…“ sehen . Die Angreifer benötigten keine gestohlene Kontaktliste. Sie erzeugten die Personalisierung für jeden Empfänger automatisch aus der Adresse selbst. Ein Hinweis darauf, dass es sich um eine maschinelle und nicht um eine menschliche Erstellung handelte, war, dass rollenbasierte Postfächer mit ihren wörtlichen Namen angesprochen wurden (zum Beispiel „mCaller left Accountspayable“), was kein echter Absender jemals schreiben würde.
Aufbau einer Phishing-E-Mail
Die E-Mail selbst ist bewusst knapp gehalten. Sie sieht aus wie eine automatische Voicemail-Benachrichtigung mit wenig Text, einer Betreffzeile, die auf einen verpassten Anruf hinweist, und einem oder mehreren Anhängen, die so gestaltet sind, dass sie wie die Voicemail-Datei aussehen. Nachstehend finden Sie ein redigiertes Beispiel aus der Kampagne.

Abbildung 4: Ein redigiertes Beispiel einer E-Mail aus der Kampagne. Die Nachricht täuscht eine interne Voicemail-Benachrichtigung vor und enthält zwei Anhänge, deren Namen so gestaltet sind, dass sie wie die Voicemail-Datei aussehen. Beachten Sie die Dateinamen im Format .svg….txt. Die Angaben zu Empfänger und Absender wurden unkenntlich gemacht.
Zwei Ebenen der Täuschung
Noch bevor auch nur eine einzige Zeile Code ausgeführt wird, stützt sich die Nachricht bereits auf zwei Formen der Täuschung auf der Ebene des Umschlags:
- Gefälschter interner Absender. Die E-Mail gibt vor, von der eigenen Domain des Empfängers zu stammen, wurde jedoch von einer externen Quelle gesendet, und der Absender wurde niemals vom Mailserver der Organisation authentifiziert. Sie ist so gestaltet, dass sie wie eine interne Systembenachrichtigung aussieht.
- Der Anhang ist falsch gekennzeichnet. Obwohl die Dateien die Endung .svg tragen und SVG/XML-Markup enthalten, werden sie in der Nachricht mit dem Inhaltstyp „text/plain“ statt „image/svg+xml“ deklariert. Ein Anhangsscanner, der sich an dem deklarierten Typ orientiert, erkennt eine harmlose Textdatei und keinen aktiven Inhalt.
Im Anhang: Was der Code tatsächlich bewirkt
Öffnet man den Anhang in einem Texteditor statt in einem Browser, stellt sich heraus, dass es sich bei der „Voicemail“ gar nicht um ein Bild handelt. Es handelt sich vielmehr um ein XML-Dokument, das verschleiertes JavaScript enthält. Der folgende Screenshot zeigt den Rohinhalt eines Beispiels.

Abbildung 5: Der Rohinhalt des SVG-Anhangs. Unter einer dünnen SVG-Hülle (ein Titel und zwei Rechtecke) verbirgt sich verschleiertes JavaScript innerhalb eines „foreignObject“-Elements und eines „script“-CDATA-Blocks. Der Block, der die aktive Callback-URL enthält, wurde unkenntlich gemacht.
Der Aufbau
Auf das Wesentliche reduziert besteht die Datei aus drei Teilen:
- Eine minimalistische SVG-Hülle. Ein
<svg>Wurzel mit einem<title>und ein paar<rect>Elemente. Dies ist der einzige Teil, der als „Bild“ dargestellt würde, und es handelt sich im Wesentlichen um eine dekorative Abdeckung. - Ein verstecktes Datenattribut. Das Stammelement enthält ein benutzerdefiniertes Attribut (zum Beispiel „data-strand-key-tk=“…“), das einen verschlüsselten Wert enthält, den das Skript zur Laufzeit ausliest. Durch die Aufteilung der Konfiguration in unauffällige Attribute werden die schädlichen Werte aus dem offensichtlichen Codepfad herausgehalten.
- Zwei Skript-Payloads. A
<foreignObject>mit einem HTML-Code<script type="application/json">Block und ein zweiter
So funktioniert die Verschleierung
Der Code ist so geschrieben, dass er sowohl menschliche Analysten als auch automatisierte Scanner überlistet, die nach erkennbaren bösartigen Mustern suchen. Dabei werden mehrere Techniken miteinander kombiniert:
- Sinnlose Funktions- und Variablennamen. Jeder Bezeichner ist mit pseudowissenschaftlichen, aus der Biologie stammenden unsinnigen Namen wie „intronGap91“, „riboUnit30“, „vectorArm37“, „codonBuf13Go“ oder „primerSet56“ getarnt. Diese Namen haben keinerlei Bedeutung und dienen lediglich dazu, den Code unlesbar zu machen und zwischen den Stichproben zu variieren, sodass keine zwei Dateien identisch aussehen.
- Erstellung von Zeichenfolgen aus Zeichencodes. Sensible Zeichenfolgen werden niemals im Klartext geschrieben. Stattdessen werden sie zur Laufzeit aus numerischen Zeichencodes mithilfe von `String.fromCharCode(…)` zusammengesetzt. Ein statischer Scanner, der die Datei ausliest, sieht eine Liste von Zahlen und nicht die Wörter, die diese darstellen.
- Einfügen von Skripten zur Laufzeit. Anstatt gefährliche Funktionen direkt aufzurufen, erstellt der Code mit `document.createElementNS(…)` ein neues Skript-Element, weist ihm eine zur Laufzeit erzeugte Quelle zu und fügt es dem Dokument an. Dies ist eine gängige Methode, um statische Analysen zu umgehen, da das bösartige Ziel nicht als literaler String in der Datei vorhanden ist.
- Verzögerte Ausführung. Die Ausführung wird über `requestIdleCallback` bzw. `setTimeout` geplant, sodass die Nutzlast nicht sofort, sondern erst kurz nach dem Laden ausgelöst wird. Dadurch kann sie Tools umgehen, die lediglich den Zeitpunkt des Öffnens einer Datei überwachen.
Was es tatsächlich tut
Nach der Entschlüsselung wird die Verschleierung deutlich. Die Zeichenfolgen im Beispiel lassen sich in kurze Zeichenketten auflösen, die das Skript verwendet, um den Namen des Remote-Endpunkts zu bilden, den es kontaktiert. Ein statischer Scanner, der die Datei ausliest, sieht nur die untenstehende Zahlenliste, niemals die Wörter, die diese bilden:
|
String.fromCharCode(104,116,116,112,115) -> „https“ String.fromCharCode(46,112,104,112) -> „.php“ (Die numerischen Codes setzen den Endpunkt zur Laufzeit zusammen.) |
Der Code liest sein verstecktes Datenattribut aus, setzt daraus den Endpunktnamen zusammen und nutzt anschließend window.fetch(…), um eine Verbindung zu einem vom Angreifer kontrollierten Host herzustellen und die nächste Stufe des Angriffs abzurufen. Die SVG-Datei selbst enthält die Phishing-Seite nicht; sie dient lediglich als Starter, der seine Nutzlast zur Laufzeit von einem Remote-Server abruft.
Wie diese nächste Phase in der Regel aussieht, hängt davon ab, wie sich diese Art von Kampagne verhält, und folgt dabei einem gut dokumentierten Muster.
Bei den abgerufenen Inhalten handelt es sich in der Regel um eine Seite zum Ausspähen von Anmeldedaten, die sich als weit verbreitete Anmeldeseite wie Microsoft 365, Google Workspace oder Adobe ausgibt. In vielen Kampagnen wird die E-Mail-Adresse des Opfers weitergegeben und zum Vorausfüllen des gefälschten Anmeldeformulars verwendet, wodurch dieses personalisiert und legitim wirkt.
Zunehmend handelt es sich bei diesen Seiten nicht mehr um einfache Klone, sondern um „Adversary-in-the-Middle“-Portale (AiTM): Sie leiten die Eingaben des Opfers in Echtzeit an den echten Anmeldedienst weiter, erfassen das daraus resultierende Sitzungstoken und umgehen so die Multi-Faktor-Authentifizierung. Diese Technik wurde mit Phishing-as-a-Service-Kits wie Tycoon2FA, Mamba2FA und Sneaky2FA in Verbindung gebracht. Durch das Remote-Hosting der Payload kann der Angreifer die Phishing-Seite zudem jederzeit aktualisieren oder austauschen, ohne jemals die bereitgestellte SVG-Datei ändern zu müssen.
|
Die wichtigste Erkenntnis
Die SVG-Datei ist nicht die eigentliche Nutzlast. Sie ist der **Schmuggelbehälter**. Ihre einzige Aufgabe besteht darin, ausführbares JavaScript in einer Datei, die als Bild behandelt wird (und hier fälschlicherweise als Text gekennzeichnet ist), am E-Mail-Gateway vorbei zu transportieren und diesen Code anschließend an den Browser weiterzuleiten, der ihn möglicherweise ausführt. Der Anhang, der wie eine Voicemail aussieht, ist in Wirklichkeit ein kleines Programm, dessen erste Aktion darin besteht, „nach Hause“ zu telefonieren. |
Warum diese Kampagne herkömmliche Abwehrmaßnahmen umgeht
- Vertrauenswürdiger Dateityp. SVG-Dateien werden allgemein als harmlose Bilder angesehen. Viele Gateways haben sie in der Vergangenheit nicht als aktiven Inhalt gescannt.
- Falsche MIME-Kennzeichnung. Die Deklaration des Anhangs als „text/plain“ umgeht Scanner, die anhand des angegebenen Inhaltstyps entscheiden, ob eine Überprüfung stattfinden soll.
- Keine statische Signatur. Unnütze Bezeichner, die Bildung von Zeichenfolgen aus Zeichencodes und Abweichungen von Sample zu Sample führen dazu, dass es keine feste Zeichenfolge oder keinen festen Hash gibt, der kampagnenweit abgeglichen werden könnte. Jede Datei sieht anders aus.
- Nur zur Laufzeit ausgeführte Nutzlast. Das schädliche Ziel wird erst dann zusammengestellt und abgerufen, wenn die Datei in einem Browser ausgeführt wird. Es liegt nicht als lesbarer Text vor, den ein statischer Scanner erkennen könnte.
- Gefälschte interne Identität. Die Nachricht gibt sich als interne Benachrichtigung aus und nutzt dabei das Vertrauen der Benutzer in E-Mails aus, die scheinbar aus ihrer eigenen Organisation stammen.
Zuordnung zu MITRE ATT&CK
Die in dieser Kampagne beobachteten Techniken lassen sich den folgenden Taktiken und Techniken des MITRE ATT&CK-Modells zuordnen.
| Taktik | Technik (ID) | Wie es in dieser Kampagne dargestellt wird |
|---|---|---|
| Erstzugang | Phishing: Spearphishing-Anhang (T1566.001) | Schädliche SVG-Datei, die als E-Mail-Anhang getarnt als Voicemail-Datei versendet wird |
| Ausführung | Benutzerausführung: Schädliche Datei (T1204.002) | Der Angriff setzt voraus, dass der Empfänger die SVG-Datei öffnet, wodurch das darin eingebettete JavaScript im Browser ausgeführt wird. |
| Vermeidung von Angriffen | Verkleidung (T1036) | SVG-Anhang, der fälschlicherweise als „text/plain“ gekennzeichnet und als Voicemail-Benachrichtigung getarnt ist |
| Vermeidung von Angriffen | Verschleierte Dateien oder Informationen (T1027) | Unwichtige Kennungen, die Bildung von Zeichenfolgen und Abweichungen bei einzelnen Stichproben verschleiern die Absicht |
| Vermeidung von Angriffen | Dateien oder Informationen entschlüsseln/dekodieren (T1140) | Das Skript rekonstruiert Zeichenfolgen und deren Zielort zur Laufzeit mithilfe von `String.fromCharCode`. |
| Vermeidung von Angriffen | Gefälschte Sicherheitswarnungen / Identitätsbetrug (T1656) | Die Nachricht gibt vor, von einem internen Absender aus der eigenen Domäne des Empfängers zu stammen. |
| Führung und Kontrolle | Protokoll der Anwendungsschicht: Webprotokolle (T1071.001) | Das eingebettete Skript ruft über einen Web-Fetch einen vom Angreifer kontrollierten Endpunkt ab, um die nächste Stufe abzurufen. |
| Zugriff auf Anmeldedaten | Eingabeerfassung (T1056) | In der nachgelagerten Phase wird in der Regel eine Seite zum Abgreifen von Anmeldedaten angezeigt, die sich als bekannte Anmeldeseite ausgibt. |
Tabelle 3: MITRE ATT&CK-Zuordnung für die SVG-Schmuggel-Voicemail-Kampagne. Die Phase „Zugriff auf Anmeldedaten“ wird aus der für diese Kampagnenklasse charakteristischen, abgerufenen Folge-Payload abgeleitet.
Wie „ INKY “ dies entdeckt hat
INKY stützt sich nicht auf Annahmen zum Dateityp oder statische Signaturen. Es wertet den gesamten Kontext und das Verhalten jeder einzelnen Nachricht aus. Bei allen 26.589 E-Mails hat „ INKY “ die Kampagne erkannt und jede Nachricht mit der Bewertung „Gefahr“ gekennzeichnet. Die Erkennung beruhte auf einem universellen Signal, das durch ein zweites untermauert wurde:
- Phishing-Inhalte wurden in 100 % der Fälle als solche erkannt. Jede einzelne Nachricht wurde aufgrund mehrerer verdächtiger Indikatoren als Phishing eingestuft, darunter die Tatsache, dass sie einen Anhang mit verdächtigem Inhalt enthielt und einer gefälschten Voicemail-Benachrichtigung ähnelte. Dies ist das Signal, das die gesamte Kampagne in jeder Organisation ausnahmslos erkannt hat.
- „Spoofed Internal Sender“ bestätigte dies bei 95 % der Kampagne. Als zusätzliches Signal erkannte „ INKY “, dass die Nachricht zwar vorgab, von der eigenen Domain des Empfängers zu stammen, jedoch von einer externen Quelle stammte, wobei sich der Absender nicht beim E-Mail-Server der Organisation authentifiziert hatte. Diese Kategorie wurde bei 95 % der Kampagne ausgelöst; die übrigen Nachrichten in Organisationen, in denen diese spezielle Kategorie nicht aktiv war, wurden dennoch vollständig von „Phishing Content“ abgefangen.
Auf dem Banner „ INKY “, das den Empfängern überreicht wurde, wurde genau dargelegt, warum die Botschaft gefährlich war:

Abbildung 6: Das Warnbanner „ INKY “, das in einer Kampagnennachricht angezeigt wird und beide Bedrohungskategorien in verständlicher Sprache erläutert. Die Domain des Empfängers wurde unkenntlich gemacht.
Jede Nachricht wurde anhand des gesamten Spektrums der Bedrohungskategorien von „ INKY “ bewertet. Allein der Phishing-Inhalt reichte bereits aus, um jede Nachricht der Kampagne als gefährlich zu kennzeichnen, wobei bei den meisten von ihnen der gefälschte interne Absender ein zweites, bestätigendes Signal lieferte.
| Bedrohungskategorie | Umfang | Rolle bei der Erkennung |
|---|---|---|
| Phishing-Inhalte | 100% | Universelles Signal – jede Nachricht empfangen |
| Gefälschter interner Absender | 95% | Bestätigungssignal bei den meisten Nachrichten |
Tabelle 2: „ INKY “-Bedrohungskategorien, die im Verlauf der Kampagne auftraten. „Phishing Content“ kennzeichnete jede Nachricht; „Spoofed Internal Sender“ bestätigte dies in den meisten Fällen.
Was die integrierte Filterfunktion von Microsoft erkannt hat
Der Unterschied zwischen dem Urteil in der Rechtssache „ INKY“ und der nativen E-Mail-Filterung ist in dieser Kampagne eklatant.
Microsoft weist jeder Nachricht einen Spam Confidence Level (SCL) zu, wobei ein Wert von 0 oder 1 bedeutet, dass die Nachricht nicht als Spam eingestuft wurde und normal im Posteingang zugestellt wird, während ein Wert von 5 sie als Spam kennzeichnet. Im Rahmen dieser Kampagne wiesen 19.994 der 26.589 Nachrichten (75 %) einen Microsoft-SCL-Wert von 0 oder 1 auf, und nur 4.777 (18 %) erhielten einen SCL-Wert von 5.
Mit anderen Worten: Die integrierte Spamfilterung von Microsoft stufte drei von vier dieser Phishing-Nachrichten als keinen Spam ein, sodass sie im Posteingang landeten, während INKY jede einzelne davon unabhängig davon als gefährlich kennzeichnete.

Abbildung 7: Vergleich der Microsoft-Spam-Bewertung mit dem Urteil von INKY über die gesamte Kampagne hinweg. Microsoft stufte 75 % der Nachrichten als keinen Spam (SCL 0 oder 1) und nur 18 % als Spam (SCL 5) ein, während INKY bei allen 26.589 Nachrichten das Urteil „gefährlich“ fällte.
Das Besondere daran ist, dass die Kampagne auf einer einzigen Vorlage basierte. Bei identischer Nachrichtenstruktur, identischem Lockangebot und identischem Anhang fielen die Bewertungen durch die Native-Ad-Systeme je nach Empfänger-Postfach völlig unterschiedlich aus: für die meisten „clean“, für manche „Spam“.
INKYIm Gegensatz dazu lieferte das System bei allen 26.589 Nachrichten das identische Urteil „gefährlich“. Dies ist das Kernargument für die verhaltensbasierte Erkennung: Eine Nachricht, die in Bezug auf Spam als „sauber“ eingestuft wird, kann dennoch ein Phishing-Angriff zum Diebstahl von Zugangsdaten sein, und nur ein Ansatz, der den gesamten Kontext zuverlässig auswertet, kann dies erkennen.
Anzeichen für eine Kompromittierung
Die folgenden Indikatoren stehen im Zusammenhang mit dieser Kampagne. Da die Nutzlast je nach Sample variiert, sind Verhaltens- und Musterindikatoren zuverlässiger als der Hashwert einer einzelnen Datei.
| Indikator | Wert / Muster | Anmerkungen |
|---|---|---|
| Thema „Köder“ | Benachrichtigung über verpasste Voicemail-Nachrichten / Anrufe | Vorwand für Social Engineering |
| Themenmuster | mCaller left <name> - 34s Preview vHC- <date> <number> | <name> = recipient's email local-part |
| Name der Anlage | PLAY_Voice-….svg | SVG-Dateiname im Voicemail-Stil |
| Angegebener MIME-Typ | text/plain | SVG falsch beschriftet, um Scanner zu täuschen |
| Verhalten der Nutzlast | SVG → verschleiertes JS → Abruf vom Remote-Endpunkt | Skript-Injektion zur Laufzeit / Callback |
| Verschleierung | String.fromCharCode, ungültige Bezeichner | Umgeht statische Signaturen |
Tabelle 4: Anzeichen für eine Kompromittierung im Zusammenhang mit der SVG-Schmuggel-Voicemail-Kampagne.
Empfehlungen
Für Sicherheitsteams
- Behandeln Sie SVG-Dateien als aktiven Inhalt. Konfigurieren Sie E-Mail- und Web-Gateways so, dass sie SVG-Anhänge als potenzielle Skriptträger und nicht als harmlose Bilder überprüfen, und verlassen Sie sich bei der Entscheidung, ob ein Scan durchgeführt werden soll, nicht auf den angegebenen MIME-Typ.
- Erwägen Sie, eingehende SVG-Anhänge zu blockieren oder unter Quarantäne zu stellen. Bei legitimen geschäftlichen E-Mails ist es selten erforderlich, SVG-Dateien direkt an Endnutzer zu senden. Durch das Blockieren oder die Isolierung eingehender SVG-Dateien wird eine wachsende Angriffsfläche mit minimalen Beeinträchtigungen beseitigt.
- Verlassen Sie sich nicht auf Datei-Hash-Signaturen. Durch die pro-Sample-Verschleierung ändern sich die Hashes ständig. Legen Sie den Schwerpunkt auf verhaltens- und inhaltsbasierte Erkennung, bei der bewertet wird, was eine Datei tut, und nicht, mit welchen Signaturen sie übereinstimmt.
- Verstärken Sie die Kontrollen gegen interne Spoofing-Angriffe. Stellen Sie sicher, dass Ihre E-Mail-Sicherheitsmaßnahmen Nachrichten erkennen können, die vorgeben, von Ihrer eigenen Domain zu stammen, jedoch von außen und ohne Authentifizierung eingehen – genau auf diesen „Envelope-Trick“ hat sich diese Kampagne gestützt.
- Klären Sie die Nutzer über unerwartete Voicemail- und Bildanhänge auf. Weisen Sie ausdrücklich darauf hin, dass eine E-Mail über einen verpassten Anruf oder eine Voicemail mit einem Anhang zum „Abspielen“ der Nachricht ein gängiger Phishing-Vorwand ist und dass Bilddateien Code enthalten können.
Für E-Mail-Empfänger
- Seien Sie misstrauisch gegenüber Benachrichtigungen über Voicemail-Nachrichten oder verpasste Anrufe, die als E-Mail mit einem Anhang zum Öffnen eingehen, insbesondere wenn Sie diese nicht erwartet haben.
- Öffnen Sie niemals einen .svg-Anhang, den Sie nicht erwartet haben. Im Gegensatz zu gewöhnlichen Bildern können SVG-Dateien beim Öffnen in einem Browser Code ausführen.
- Behandeln Sie jede Anmeldeseite, die Sie durch das Öffnen eines Anhangs aufrufen, als nicht vertrauenswürdig. Rufen Sie Dienste direkt auf, anstatt über Links oder Dateien in E-Mails.
- Denken Sie daran, dass eine E-Mail, die scheinbar von Ihrer eigenen Organisation stammt, dennoch gefälscht sein kann. Eine „System“-Benachrichtigung, die den Anschein einer internen Mitteilung erweckt, ist kein Beweis für ihre Echtheit.
Fazit
Diese Kampagne ist ein Paradebeispiel für eine Technik, die E-Mail-Bedrohungen im Jahr 2026 prägt: das Verstecken von ausführbarem Code in einem Dateityp, den die Welt als harmloses Bild betrachtet. Indem sie verschleiertes JavaScript in eine SVG-Datei einbetteten, diese SVG-Datei als einfachen Text tarnten, einen internen Absender vortäuschten und das Ganze als gewöhnliche Voicemail maskierten, schufen die Angreifer einen Köder, der darauf ausgelegt war, sowohl automatisierte Filter als auch menschliches Urteilsvermögen zu umgehen – und das in einem Ausmaß von Zehntausenden von Nachrichten, die an Tausende von Organisationen versendet wurden.
Es hat nicht funktioniert. „ INKY “ hat alle 26.589 Nachrichten erkannt und markiert – mithilfe von Verhaltenssignalen, die bewerten, was eine Nachricht ist und tut, anstatt darauf zu vertrauen, was sie vorgibt zu sein. Dieser Unterschied ist entscheidend: Herkömmliche Spamfilter stuften drei Viertel dieser Kampagne als harmlose, für den Posteingang bestimmte E-Mails ein. Da Angreifer weiterhin vertrauenswürdige Dateiformate als Waffe einsetzen, ist es ein verhaltensorientierter Ansatz – und nicht Signaturen oder Annahmen über Dateitypen –, der den Unterschied zwischen Erkennung und Zustellung ausmacht.
Stichworte: SVG-Schmuggel, SVG-Phishing, bösartiger SVG-Anhang, JavaScript-Schmuggel, Voicemail-Phishing, Umgehung von MIME-Typen, gefälschter interner Absender, E-Mail-Sicherheit 2026, INKY PhishFence, Bedrohungsinformationen


