12. Oktober 2026
EXCHANGE12ROCKS: Eine Adobe-Sign-Fälschung mit Exchange-Kostüm und einem Klickzähler aus Japan
Tobias Wilke
@wilketob
Wer schon mal einen Exchange-Server administriert hat, kennt FYDIBOHF23SPDLT. Der Rest der Welt hat es in dieser Mail zum ersten Mal gesehen, mitten im Absendernamen. Genau darauf setzt sie: Was nach Maschine aussieht, wirkt offiziell.
Die Mail kam am 17. August an info@ und will eine Unterschrift. Absender, Betreff und Anhang reden dabei von drei verschiedenen Dokumenten. (Bösartige URLs sind defangt, damit nichts aus Versehen angeklickt wird.)
Ein Absendername wie ein Systemprotokoll
Der Display-Name lautet:
<Firmenname> Online-Docusign/OU=EXCHANGE ADMINISTRATIVE GROUP
(FYDIBOHF23SPDLT)/CN=RECIPIENTS/CN=B7A707497B564FD-88344
Das ist ein LegacyExchangeDN, die X.500-Adresse, die Exchange intern für Postfächer führt. FYDIBOHF23SPDLT ist seit Exchange 2007 fest im Produkt verdrahtet. Verschiebt man jeden Buchstaben um eins zurück und jede Ziffer um eins nach vorn, steht da EXCHANGE12ROCKS. Ein Insider-Witz von Microsoft-Entwicklern, jetzt als Tarnung im Phishing.
Der Betreff kopiert die Struktur, aber nicht den Inhalt: (GYBIGOHF23SPIDLT)/MT101=RECIPIENTS/.... Das lässt sich nicht mehr dekodieren. Das Kit verwürfelt die Buchstaben, damit Betreff-Signaturen nicht greifen. MT101 ist der SWIFT-Nachrichtentyp für Überweisungsaufträge und soll nach Bank klingen. Vorne steht dann noch "Docusign", im Body aber Adobe. Zwei Marken, ein Klebestift.
Geliehen: das Postfach
Die Adresse hinter dem Kostüm ist donotreply[@]<firma>[.]com. Die Domain gehört einem kleinen Unternehmen: registriert 2018, Website bei Wix, Mail bei Google Workspace. Kein Wegwerfkonto, sondern ein echter Betrieb.
Der Header zeigt den Weg:
Received: from <firma>.com ([45[.]132[.]115[.]72])
by smtp-relay.gmail.com with ESMTPS
X-Relaying-Domain: <firma>.com
smtp-relay.gmail.com ist der SMTP-Relay von Google Workspace. Den nutzen Firmen, damit Drucker, Shops oder Server über Google versenden können. Er nimmt Mail nur von freigegebenen IPs oder mit gültigen Zugangsdaten an. Eingeliefert wurde aber von 45[.]132[.]115[.]72, im Netz von Latitude.sh in Dallas. Der Netzname im WHOIS: "VPN Consumer Dallas". Das ist der Ausgang eines kommerziellen VPN-Dienstes. Den trägt niemand freiwillig in seine Relay-Freigabe ein.
Die plausibelste Erklärung: Jemand hat die Zugangsdaten eines Kontos dieser Firma und verschickt darüber Phishing. Beweisen lässt sich das von außen nicht. Aber genau dafür werden solche Konten gestohlen - und genau dafür ist diese Mail gebaut.
Die Authentifizierung hat dabei nicht gestört. Die Domain hat keinen SPF-Record und keinen DMARC-Record. Signiert hat Google mit seinem Standardschlüssel d=…gappssmtp.com, der greift, wenn kein eigener DKIM eingerichtet ist. Das Ergebnis heißt dkim=pass, spf=none, DMARC nicht vorhanden. Formal also nichts verboten. Bei einem kleinen Betrieb ohne eigene IT ist so ein Setup keine Seltenheit - Google Workspace läuft ja auch ohne.
Geliehen: die Vorlage
Drückt man F12 und schaut in den Quelltext, wird es lustig. Alle Bilder liegen auf ci3.googleusercontent.com/meips/.... Das ist der Bildproxy von Gmail. Hinter dem # steht die Original-URL: Logos und ein Tracking-Pixel vom Adobe-Sign-Konto eines echten nordamerikanischen Softwareanbieters.
Die HTML-IDs erzählen den Rest:
id="m_-8748651420093755902m_1093264441728114954m_7990230779019611443gmail-OWA9d490be9-..."
Gmail setzt beim Anzeigen ein m_<zahl> vor IDs, Outlook Web ein OWA. Hier stehen drei Gmail-Präfixe und ein Outlook-Präfix. Eine echte Adobe-Sign-Mail ist also mehrfach durch fremde Postfächer gewandert und dann als Vorlage kopiert worden. Den Absendernamen hat jemand rausgeschnitten, übrig blieb: "This notification is sent ." Mit Leerzeichen vor dem Punkt.
Das Tracking-Pixel ist noch drin. Wer die Bilder lädt, meldet sich beim Adobe-Konto des Original-Absenders. Der Angreifer erfährt davon nichts. Tracking für die Falschen, sozusagen.
Dazu kommen Reste aus dem Baukasten. Der Logo-Link zeigt auf href="dnnff", Tastatur-Gestammel, nie ersetzt. Als Inline-Bild hängt das Favicon meiner eigenen Domain dran, automatisch geholt über einen Logo-Dienst. Angezeigt wird es nirgends, weil das HTML es nicht referenziert. Ein zweites "Logo" ist 27 Byte groß und enthält den Text Image data placeholder. Und der Anhang "Bonus Approval Form" hat genau null Byte. Betreff "Document Ready for Approval", Body "Project Agreement 58656", Anhang "Bonus Approval Form". Drei Köder, keiner fertig.
Geliehen: der Link
Alle drei Klickflächen zeigen auf dieselbe Adresse:
hxxp://cgi[.]members[.]interq[.]or[.]jp/<mitglied>/yomi-search/rank[.]cgi
?id=267&mode=link
&url=hxxps://<firma-pe>[.]pe/wp-includes/updaterequired/adobe/adobe
interq.or.jp ist ein japanischer Homepage-Dienst von GMO. yomi-search ist ein Perl-Linkverzeichnis aus der Zeit, als man Websites noch in Webkataloge eintrug. rank.cgi?mode=link zählt einen Klick und leitet dann weiter - wohin auch immer url= sagt. Keine Prüfung. Ein Open Redirect auf einer Provider-Domain, die älter ist als manche Leser dieses Blogs.
Das Ziel ist eine WordPress-Seite eines peruanischen Unternehmens. Der Pfad /wp-includes/updaterequired/adobe/adobe verrät den Einbruch: wp-includes ist ein Kernverzeichnis von WordPress, updaterequired gehört dort nicht hin. Das hat der Angreifer hochgeladen, und der Unterordner adobe/ lässt vermuten, dass es Geschwister für andere Marken gibt.
Was die eigentlich wollen
Die URL habe ich nicht aufgerufen. VirusTotal hat sie am 14. August gecrawlt, drei Tage vor meiner Mail. Seitentitel: "Secure Redirect", dazu ein Google reCAPTCHA. Das ist ein Türsteher: Scanner bleiben am Captcha hängen, Menschen klicken durch und landen auf der eigentlichen Seite. Was dort kommt, hat VT nicht gesehen. Der Köder lässt wenig Zweifel: Mailadresse und Passwort, damit man "das Dokument öffnen" kann.
Und dann schließt sich der Kreis. Mit dem erbeuteten Postfach liest der Angreifer Rechnungen mit, setzt Weiterleitungsregeln oder verschickt die nächste Welle. Genau so, wie es hier mit dem Workspace-Konto der Firma von oben passiert ist.
Die Zeitlinie ist ernüchternd. VirusTotal kennt beide URLs seit dem 23. Juli. Meine Mail kam am 17. August, also 25 Tage später, über exakt dieselbe Kette. Die Landing stand zuletzt bei 9 von 91 Engines, der Redirector bei 2 von 92. Am 8. September lieferte die WordPress-Seite nur noch "Página no encontrada". Aufgeräumt, aber Wochen zu spät.
Auch der Spamfilter fand die Mail nicht schlimm genug: SpamAssassin 4,0 bei Schwelle 7,0, Rspamd 0,02 von 15. Eine Regel hat den Docusign-Spoof erkannt, eine den WordPress-Pfad. Die Spamhaus-Abfrage für die japanische Domain lief dagegen ins Leere (DBL_BLOCKED_OPENRESOLVER). Gefragt wurde also gar nicht.
Woran ihr es erkannt hättet
Ihr müsst kein Exchange-Admin sein. Ein Absendername, der aussieht wie ein Verzeichnispfad, ist kein Kollege. Die Adresse dahinter hat weder mit Adobe noch mit Docusign zu tun. Docusign im Namen, Adobe im Text - einer von beiden lügt, in diesem Fall beide. Und ein Anhang mit 0 KB ist kein Dokument.
Fahrt mit der Maus über "Review and sign". Ein .or.jp-Link mit rank.cgi und einer zweiten URL im Parameter hat in einer Unterschriftsanfrage nichts zu suchen.
Was ihr tun könnt
Eigene Domain absichern. SPF, DKIM mit eigenem Schlüssel, DMARC mit Report-Adresse. Das verhindert keinen Kontodiebstahl, aber ihr seht in den Reports, wenn eure Domain plötzlich aus Dallas verschickt. Ob alles sitzt, zeigt der Mail-Check hier auf der Seite.
Google-Workspace-Relay prüfen. In der Admin-Konsole unter Apps → Gmail → Routing → SMTP-Relay-Dienst. Wer ihn nicht braucht, löscht die Regel. Wer ihn braucht, erlaubt nur die eigenen festen IPs.
MFA, und zwar die richtige. Passkeys oder Hardware-Keys lassen sich nicht auf einer Fake-Seite abfangen. SMS- und App-Codes oft schon.
Unterschriften nur im Portal. Echte Adobe-Sign- und Docusign-Anfragen tauchen auch in eurem Konto beim Anbieter auf. Unbekannter Absender plus "signature required": beim angeblichen Absender anrufen, nicht klicken.
Mailserver selbst betreiben? Prüft, ob eure Spamhaus-Abfragen beantwortet werden. Ein _BLOCKED im Header heißt: Die stärkste Prüfung ist still ausgefallen.
Fazit
Diese Kampagne besitzt nichts. Kein Server, keine Domain, nicht mal ein eigenes Logo - nur fremde Postfächer, fremde Websites und ein Webkatalog-Skript, das vor zwanzig Jahren vergessen wurde. Handwerklich ist sie schlampig, strategisch nicht: Jedes Opfer liefert das Postfach für die nächste Runde. EXCHANGE12ROCKS. Phishing leider auch.
Die missbrauchten Domains sind redigiert (<firma>[.]com, <firma-pe>[.]pe, das Mitgliedsverzeichnis auf dem japanischen Homepage-Dienst). Die Betreiber sind hier selbst Opfer - ein übernommenes Mailkonto, eine gekaperte WordPress-Installation, ein altes Skript. Pranger-Wirkung vermeiden. Die vollständigen IOCs liegen intern.