Kurz gefasst
Am 17. März 2026 registrierte ein Angreifer eine neue Domain, eröffnete ein Google Workspace-Konto und sandte eine Google-Kalendereinladung an einen Mitarbeiter eines mittelständischen Technologieunternehmens. Die Einladung wies auf eine Software-Abbuchung von 399,77 $ hin und forderte den Empfänger auf, eine gebührenfreie Nummer anzurufen, um diese anzufechten. Es gab keinen Link zum Anklicken und keinen Anhang zum Öffnen; die DKIM-Prüfung war erfolgreich, da Google die Nachricht signiert hatte. Dies ist Phishing via Kalendereinladung in seiner reinsten Form – es umgeht jede Ebene moderner E-Mail-Sicherheitslösungen. Die einzige Instanz, die den Angriff erkennt, ist die Person, die die Einladung liest.
Einleitung
Der Angriff traf an einem Dienstagnachmittag ein und sah auf den ersten Blick aus wie jede andere Google-Kalendereinladung, die der Empfänger in dieser Woche erhalten hatte. Eine Abo-Gebühr für ein Produkt namens „CoreDefense Plus“. Eine Referenznummer. Eine gebührenfreie Nummer für den Fall, dass die Abbuchung nicht autorisiert war. Jeder Link in der E-Mail verwies auf calendar.google.com. Der .ics-Anhang enthielt keinen ausführbaren Schadcode. Die DKIM-Prüfung verlief erfolgreich, da die Nachricht tatsächlich von Google signiert war.
Das einzige Anzeichen für eine Kompromittierung war eine Telefonnummer in der Beschreibung der Einladung.
Dies ist Phishing via Kalendereinladung im Jahr 2026, dokumentiert von IRONSCALES am 6. April, und es verdient die volle Aufmerksamkeit jedes CISO. Nicht, weil kalenderbasiertes Phishing neu wäre (Cofense dokumentierte es bereits 2019), sondern weil diese Variante den Angriff auf seinen unverzichtbaren Kern reduziert hat: ein Köder ohne Schadcode, der über legitime Infrastrukturen geleitet wird und darauf ausgelegt ist, das Opfer auf einen Kanal zu locken, auf dem kein Sicherheitstool folgen kann – das Telefonat.
Der technische Mechanismus ist wichtig. Ebenso das Fazit: Wenn der „Schadcode“ eine Telefonnummer ist, ist die E-Mail-Sicherheitsarchitektur strukturell blind. Die einzig wirksame Verteidigung ist hier das Verhalten der Nutzer.
Was Phishing via Kalendereinladung eigentlich ist
Phishing via Kalendereinladung ist ein Social-Engineering-Angriff, bei dem eine Kalendereinladung – meist eine .ics-Datei oder eine native Google- oder Microsoft-Kalendereinladung – als Übermittlungsmechanismus für einen Phishing-Köder dient. Der Schadcode kann dabei drei verschiedene Formen annehmen.
Die erste Form ist ein schädlicher Link in der Beschreibung oder im Standortfeld der Einladung. Dies ist die ursprüngliche Variante, die bereits 2019 von Cofense dokumentiert wurde und auch heute noch weit verbreitet ist.
Die zweite Form ist ein QR-Code innerhalb des .ics-Anhangs. ProArch dokumentierte diese Variante im März 2026: Ein Angreifer versteckt einen QR-Code in einem Kalenderereignis, der Nutzer sieht den Anhang in Outlook in der Vorschau, und der Kalendereintrag wird hinzugefügt, ohne dass die Datei jemals heruntergeladen werden muss. Das Scannen des QR-Codes führt zu einem Adversary-in-the-Middle-Proxy, der Sitzungstoken abgreift und die MFA umgeht.
Die dritte Form ist die Variante, die wir hier besprechen: ein Köder ohne Schadcode, der auf einen Rückruf abzielt. Kein Link. Kein Anhang mit aktivem Inhalt. Nur eine Telefonnummer im Text einer Kalendereinladung, präsentiert in einem Kontext (eine Abbuchung, eine Abo-Verlängerung, ein Sicherheitsalarm), der dringlich genug ist, um einen Anruf auszulösen.
Der IRONSCALES-Fall fällt in die dritte Kategorie und ist die Variante, die von herkömmlichen E-Mail-Sicherheitslösungen am schwersten zu erkennen ist.
Ziel für Featured Snippets
Kalender-Phishing ist eine Angriffsform, bei der eine Kalendereinladung – meist eine .ics-Datei oder eine Einladung über Google oder Microsoft Calendar – als Übermittlungsmechanismus dient. Die Nutzlast kann ein schädlicher Link, ein eingebetteter QR-Code oder bei Varianten ohne Nutzlast eine Telefonnummer sein, die den Empfänger zu einem Rückruf bei einem vom Angreifer betriebenen Callcenter verleiten soll.
Warum Ihr E-Mail-Sicherheitsstack diesen Angriff nicht erkennt
Der IRONSCALES-Angriff ist ein aufschlussreicher Testfall, da er uns ermöglicht, jede Ebene einer standardmäßigen E-Mail-Abwehr für Unternehmen zu durchleuchten und kritisch zu hinterfragen, wonach die jeweilige Ebene gesucht hat und warum sie die Nachricht dennoch durchgelassen hat.
URL-Filterung. Es gab keine schädlichen URLs, die hätten gefiltert werden können. Jeder Link in der Einladung verweist auf calendar.google.com, eine legitime Google-Domain, die von keiner Reputations-Engine als gefährlich eingestuft wird. Die URL-Reputation basiert darauf, eine Datenbank bekannter schädlicher Domains zu führen und neue Domains auf Reputationssignale hin zu analysieren. Wenn die einzigen vorhandenen Links auf Google verweisen, gibt es nichts zu bewerten.
Sandboxing und Detonierung von Anhängen. Die .ics-Datei enthielt keine ausführbare Nutzlast. Es handelte sich um einen Standard-Kalendereintrag mit Textfeldern. Sandboxing-Engines sind darauf ausgelegt, aktive Inhalte, Skripte, eingebettete Objekte oder Links zu schädlichen Downloads zu detonieren und deren Laufzeitverhalten zu beobachten. Eine statische, textbasierte Kalendereinladung erzeugt kein beobachtbares schädliches Verhalten, da es nichts auszuführen gibt.
E-Mail-Authentifizierung (DKIM, SPF, DMARC). Dies sind die drei Protokolle, die bestätigen, dass eine E-Mail tatsächlich von der Domain stammt, die sie vorgibt. Die Nachricht wurde bei allen drei erfolgreich authentifiziert. DKIM, das die Nachricht mit dem kryptografischen Schlüssel des Absenders signiert, war erfolgreich, da Google sie über die eigene Infrastruktur signiert hat. SPF, das prüft, ob der sendende Server für die Domain autorisiert ist, ergab „none“, da die Domain des Angreifers (scoolsd[.]com, am selben Morgen registriert) keinen SPF-Eintrag veröffentlicht hatte. Die DMARC-Ausrichtung schlägt jedoch nicht fehl, wenn SPF fehlt, solange DKIM erfolgreich ist. Aus Sicht der E-Mail-Authentifizierung war die Nachricht legitim. Technisch gesehen war sie das auch: Sie wurde von Google Workspace versendet, das der Angreifer kontrollierte.
Secure Email Gateways (SEGs). Die meisten SEGs analysieren den E-Mail-Text und Anhänge auf schädliche Muster. Forscher von Check Point haben dokumentiert, dass Phishing-E-Mails über Kalender regelmäßig DKIM, SPF und DMARC passieren, da sie von legitimen Google-Diensten stammen, und dass die meisten SEGs Kalenderanhänge nicht tiefgehend prüfen, da .ics kein klassisches Dateiformat für Schadsoftware ist. Dieser blinde Fleck ist strukturell bedingt und keine Fehlkonfiguration.
Verhaltensbasierte Inhaltsanalyse. Hier schlagen einige Plattformen Alarm. Die Themis-Engine von IRONSCALES wies einen Konfidenzwert von 66 % zu, basierend auf der frisch registrierten Domain, dem Fehlen einer SPF-Richtlinie und inhaltlichen Mustern, die auf Social Engineering mit finanzieller Dringlichkeit hindeuten. Das ist die richtige Reaktion. Aber beachten Sie, was den Alarm ausgelöst hat: nicht die Nutzlast (da es keine gab), sondern der Kontext der Nachricht. Das Alter der Domain. Anomalien bei der Authentifizierung. Sprachliche Muster. Dies sind Signale, die der Rest des Sicherheitsstacks ignoriert.
Das unangenehme Ergebnis ist, dass dieser Angriff für die vier klassischen Ebenen der E-Mail-Sicherheit unsichtbar bleibt.
Das dahinterstehende Callback-Phishing-Muster
Der Vorfall mit dem Google-Kalender ist ein Übertragungsvektor innerhalb einer breiteren Angriffskategorie namens Callback-Phishing, auch bekannt als TOAD (Telephone-Oriented Attack Delivery). Das entscheidende Merkmal ist, dass der Angriff das Opfer von einer E-Mail oder Einladung in ein Telefongespräch lockt, bei dem Social Engineering in Echtzeit stattfindet und keine digitalen Spuren hinterlässt, die von Sicherheitstools überprüft werden könnten.
Diese Kategorie wächst rasant. Trustwave SpiderLabs verzeichnete zwischen Juli und September 2024 einen Anstieg von Callback-Phishing-Kampagnen um 140 % (Trustwave SpiderLabs, Oktober 2024). Der Internet Crime Report 2024 des FBI führt über 2,9 Milliarden US-Dollar an gemeldeten Verlusten in den USA auf Business E-Mail Compromise und damit verbundene Betrugsdelikte zurück, wobei telefonbasiertes Social Engineering als bedeutender und unterschätzter Faktor hervorgehoben wird (FBI IC3, 2024).
Das gemeinsame Muster bei jeder Variante des Callback-Phishings – egal ob der Köder per E-Mail, SMS oder Kalendereinladung kommt – besteht darin, dass der Angriff so strukturiert ist, dass das Opfer zu einem Telefonat geleitet wird, bevor technische Abwehrmechanismen eingreifen können. Genau deshalb setzen KI-gestützte Angreifer nun auf die Kombination mehrerer Kanäle – eine E-Mail, um Kontext zu schaffen, ein Anruf, um Dringlichkeit zu erzeugen –, damit das Social Engineering effektiver ist, als es über einen einzelnen Kanal möglich wäre.
So schützen Sie sich vor Phishing über Kalendereinladungen
Es gibt zwei Verteidigungsebenen, die jedoch bei der Variante ohne Schadcode-Payload unterschiedlich effektiv sind.
Technische Kontrollen
Diese bieten eine teilweise Entschärfung und sollten ohnehin konfiguriert werden.
Deaktivieren Sie in Microsoft 365-Umgebungen die automatische Kalenderverarbeitung, damit eingehende Besprechungsanfragen nicht automatisch akzeptiert oder vorläufig in die Kalender der Benutzer eingetragen werden. Kalendereinträge bleiben oft bestehen, selbst nachdem die ursprüngliche Phishing-E-Mail gemeldet und gelöscht wurde. Dies gibt Angreifern Tage später eine zweite Chance, wenn der Benutzer das Ereignis erneut aufruft. Das Entfernen des Kalendereintrags bei Löschung der E-Mail schließt diese Lücke.
In Exchange können Nachrichtenflussregeln externe .ics-Anhänge erkennen und zur Überprüfung weiterleiten. Wenden Sie dies vorsichtig und mit Positivlisten an, da legitime externe Besprechungseinladungen dasselbe Dateiformat verwenden.
In Google Workspace können die Kalendereinstellungen so verschärft werden, dass Einladungen von Absendern, die nicht in der Kontaktliste des Benutzers stehen, abgelehnt oder die automatische Ereignishinzufügung von unbekannten Absendern unterdrückt wird.
Diese Kontrollmechanismen verringern die Angriffsfläche, eliminieren sie jedoch nicht. Keiner von ihnen sieht die Telefonnummer.
Verhaltensorientierte Kontrollen
Wenn die Nutzlast eine Telefonnummer ist, ist die einzige Instanz, die die Absicht bewerten kann, die Person, die die Einladung liest. Genau dort muss die Verteidigung ansetzen.
Eine effektive verhaltensorientierte Verteidigung gegen Callback-Phishing besteht aus drei Komponenten.
Die erste ist eine realistische Simulation. Mitarbeiter müssen in einer kontrollierten Umgebung mit Kalender- und Callback-Phishing-Szenarien konfrontiert werden, bevor sie in der Praxis darauf stoßen. Die Simulation sollte das strukturelle Muster des Angriffs nachbilden: eine unbekannte Abbuchung, ein seriös wirkender Absender, eine Telefonnummer als Mittel zur Klärung und Dringlichkeit im Zusammenhang mit einer finanziellen Entscheidung.
Die zweite ist ein Training zur Mustererkennung, das auf die spezifischen Merkmale dieser Angriffsklasse zugeschnitten ist. Kein allgemeines „Erkennen Sie Phishing-E-Mails“-Training, sondern eine gezielte Anleitung zur Mustererkennung: Abbuchungen von Anbietern, zu denen das Unternehmen keine Geschäftsbeziehung hat, Kalendereinladungen von externen Absendern für Transaktionen, Telefonnummern in Texten zu finanziellen Streitfällen und Dringlichkeit bei zeitkritischen Abbuchungen. Diese Signale nutzt der IRONSCALES-Angriff, und sie sind für die gesamte Kategorie charakteristisch.
Die dritte ist eine Meldeinfrastruktur, die Kalenderereignisse und nicht nur E-Mails verarbeitet. Wenn der einzige „Phishing melden“-Workflow in Ihrem Unternehmen ein Button in Outlook ist, der E-Mails markiert, wird ein bösartiges Kalenderereignis, das nach dem Löschen der E-Mail im Kalender des Benutzers verbleibt, nicht gemeldet. Die Meldefunktion muss sich auch auf die Kalenderoberfläche selbst erstrecken.
So sieht verhaltensorientierte Verteidigung als tragfähige Sicherheitsmaßnahme aus: Simulation, Mustererkennung und Meldeinfrastruktur, alles gezielt auf die spezifische Angriffsklasse ausgerichtet. Ohne diese Ebene gelangt die Zero-Payload-Variante des Kalender-Phishings ungehindert in den Kalender des Benutzers, ohne dass eine Verteidigung zwischen ihm und dem Telefonanruf steht.
Das unangenehme Fazit
Authentifizierung bestätigt den Ursprung. Sie bestätigt nicht die Absicht.
Wenn ein Angreifer einen Köder über die legitime Infrastruktur von Google leitet, wird jede Perimeter-Kontrolle zu einem Vertrauenssignal für den Angriff statt zu einer Verteidigung dagegen. Die DKIM-Signatur sagt nicht „Das ist sicher“. Sie sagt „Das kommt von Google“. Bei einer Kalendereinladung, die von einem Google Workspace-Konto gesendet wurde, das der Angreifer vor einer Stunde registriert hat, sind beide Aussagen gleichzeitig wahr.
Die einzige Ebene des Sicherheits-Stacks, die die Absicht bewerten kann, ist die Person, die die Einladung liest. Genau auf dieser Ebene arbeitet Zepo.
Hier ist eine Frage, über die es sich nachzudenken lohnt: Wenn der nächste Zero-Payload-Angriff im Kalender eines Ihrer Mitarbeiter landet, woraus besteht dann eigentlich Ihre Verteidigung?
.png)
