Phishing-Angriff oder Konfigurationsproblem in Microsoft-Cloud-Infrastruktur entdeckt
Eine umfassende Analyse
Einleitung
Dieser Artikel beschreibt einen sicherheitsrelevanten Vorfall, der von der SKAWINSKI GmbH entdeckt wurde. IT-Fachleute erhalten hier eine ausführliche Analyse darüber, wie eine vermeintliche Non-Delivery-Report (NDR)-E-Mail aus Microsoft-Outlook- und O365-Systemen scheinbar gefälscht (oder fehlerhaft konfiguriert) versendet wurde. Ziel ist es, Administratoren über potenzielle Risiken bei SPF-Konfigurationen und Phishing-Angriffen aufzuklären. Unmittelbar nach Erkennen des Vorfalls wurde der eigentliche Mail-Empfänger kontaktiert, damit er seinerseits mögliche Sicherheitsmaßnahmen treffen kann. SKAWINSKI GmbH bot zudem Unterstützung an, um den Vorfall von dessen Infrastrukturseite zu untersuchen.
1. Zusammenfassung des Vorfalls
Zeitpunkt: 13. Dezember 2024
Betroffene Parteien:
SKAWINSKI GmbH (Mailgateway-Betreiber)
Microsoft O365 E-Mail-Infrastruktur
Kunde (@stdl.at), der die gefälschte NDR-E-Mail erhielt
Mail-Empfänger (zensiert), der nachträglich über den Vorfall informiert wurde
Haupt-IP-Adressen und Hosts:
52.100.13.223 (mail-am7eur03hn2223.outbound.protection.outlook.com; bei 0SPAM blockiert)
40.107.21.91 (Microsoft IP; laut gefälschter NDR in SPF aufzunehmen)
SKAWINSKI GmbH konnte den Vorfall durch gründliches Monitoring frühzeitig erkennen. Erste Hinweise deuten entweder auf einen Fehlkonfiguration in der Microsoft-Mail-Infrastruktur oder auf das Ausnutzen legitimer Microsoft-IP-Ranges durch Angreifer hin.
2. Detaillierter Ablauf
2.1 E-Mail-Anlass und gefälschter Non-Delivery-Report
Der Absender „<zensiert>@stdl.at“ versendete eine legitime Mail an „<zensiert>@<empfänger-domain-zensiert>“. Kurz darauf erhielt er angeblich von „postmaster@<empfänger-domain-zensiert>“ einen Non-Delivery-Report. Darin wurde gefordert, die IP-Adresse 40.107.21.91 zum bestehenden SPF-Eintrag hinzuzufügen. Dies wirkte zunächst wie eine typische Microsoft-Meldung, enthielt jedoch verdächtige Details und potenziell riskante Handlungsempfehlungen.
2.2 Server-Logs der SKAWINSKI GmbH
Die Postfix- und Mailgateway-Logs zeigten, dass die NDR-Mail von mail-am7eur03hn2223.outbound.protection.outlook.com (52.100.13.223) kam. Diese IP gehört zu Microsoft, ist aber von 0SPAM blockiert. Obwohl es sich also um eine „offiziell“ zu Microsoft zählende IP handelt, kann sie für unzulässige oder gefährliche Aktivitäten missbraucht werden.
Weiters fällt auf, dass der envelope-from Header leer ist (im Log sichtbar als from=<>). Der Absender ist erst im Mailinhalt im From Header ersichtlich.
Zunächst riet ein Microsoft-Support-Engineer dazu, die IP 40.107.21.91 in den SPF-Eintrag aufzunehmen.
Robert Skawinski wies darauf hin, dass dies einem Phishing-Angriff gleichkommen könnte, weil damit Angreifer autorisierte E-Mails für diese Domain versenden könnten.
Der Microsoft-Support zog die erste Empfehlung zurück und riet, die Änderung zu ignorieren.
Das Ticket wurde geschlossen – mit der Bitte um eine 5-Sterne-Bewertung.
Nachdem Robert Skawinski dies verweigert hatte, bat der Support, ganz auf eine Bewertung zu verzichten.
Hinweis auf abgelehnte Eskalation:
Robert Skawinski bat daraufhin um eine Eskalation des Falles an den 2nd-Level-Support und meldete explizit ein Problem in der Microsoft-Infrastruktur. Diese Bitte wurde jedoch mit der Begründung abgelehnt, dass die Meldung von Seiten des Empfängers erfolgen müsse. Eine direkte Untersuchung des möglichen Sicherheitsproblems in den Microsoft-Systemen fand somit zunächst nicht statt.
(Siehe dazu auch den Auszug aus dem Mailverlauf am Ende dieser Seite.)
2.4 Aufklärung des Mail-Empfängers
Nachdem klar wurde, dass ein gefälschter (oder zumindest hochgradig verdächtiger) NDR im Spiel ist, informierte die SKAWINSKI GmbH den betroffenen Mail-Empfänger. Damit sollte sichergestellt werden, dass auch von dessen Seite aus Sicherheitsprüfungen und Gegenmaßnahmen erfolgen, um ähnliche Angriffe zu verhindern. Die SKAWINSKI GmbH bot ausdrücklich an, bei weiteren Analysen behilflich zu sein.
3. Technische Analyse
3.1 Potenziell kompromittierte Microsoft-Server oder IP-Ranges
Eine Aufstellung der Logs und WHOIS-Abfragen belegt, dass 52.100.13.223 und 40.107.21.91 zu Microsoft gehören. Die Blocklist-Eintragung zeigt jedoch, dass 52.100.13.223 zuvor im Verdacht stand, Phishing oder Spam versendet zu haben.
3.2 Gefälschte NDRs als Phishing-Methode
Angreifer verwenden häufig Systemmeldungen wie NDRs, um Administratoren zur Vornahme gefährlicher Änderungen zu verleiten. Auf diese Weise könnten sie autorisierte E-Mails im Namen der jeweiligen Domain versenden.
3.3 WHOIS- und Blocklisten-Prüfungen
Eine WHOIS-Abfrage bestätigte die Microsoft-Zugehörigkeit beider IPs. Die 0SPAM-Liste stufte 52.100.13.223 jedoch als blockierungswürdig ein. Dies verdeutlicht, dass IP-Bereiche durchaus offiziell Microsoft gehören, aber trotzdem für schädliche Aktionen missbraucht werden können.
4. Handlungsempfehlungen und Best Practices
SPF-Einträge sorgfältig hinterfragen
Setzen Sie keine neuen IP-Adressen blind in Ihre DNS-Einträge. Verifizieren Sie seriöse Quellen und Logdaten.
Regelmäßiges Monitoring
Überwachen Sie sämtliche Mailserver-Aktivitäten, um unübliche Verbindungsversuche oder Unregelmäßigkeiten frühzeitig aufzuspüren.
Einsatz mehrerer Schutzmechanismen
Ergänzen Sie SPF durch DKIM und DMARC. Nutzen Sie Anti-Spam-Gateways, die tiefere Analysen ermöglichen.
Kommunikation mit Supportstellen
Achten Sie darauf, alle Empfehlungen von Dritten (auch von Hersteller-Supports) kritisch zu überprüfen. Im Zweifelsfall sollten Sie schriftliche Bestätigungen verlangen.
Direkte Kommunikation mit Empfängern
Informieren Sie umgehend Empfänger oder Drittunternehmen über verdächtige Mails. Gemeinsame Analysen erhöhen die Wirksamkeit der Gegenmaßnahmen.
Schulung der Mitarbeiter Sensibilisieren Sie Ihre Belegschaft für aktuelle Phishing-Methoden und fördern Sie eine Kultur der Wachsamkeit.
Schlussfolgerung
Der hier beschriebene Fall zeigt, wie essenziell eine solide E-Mail-Sicherheitsarchitektur und ein kritisches Hinterfragen sämtlicher Systemmeldungen sind. Weil die SKAWINSKI GmbH zeitnah reagierte, konnte verhindert werden, dass eine Microsoft-IP-Adresse fälschlicherweise in den SPF-Eintrag des Kunden aufgenommen wurde.
Der Mail-Empfänger wurde über den Vorfall informiert und bekam Unterstützung angeboten, um sein System ebenfalls überprüfen zu können. So lässt sich der Schaden verringern und ähnliche Kampagnen in Zukunft schneller erkennen.
Die anfänglich widersprüchlichen Aussagen des Microsoft-Supports verdeutlichen, dass Administratoren und Sicherheitsverantwortliche angehalten sind, jeden Schritt einer Plausibilitätsprüfung zu unterziehen. Nur so bleiben Domain und E-Mail-Kommunikation dauerhaft geschützt.
Information der Community
Als verantwortungsbewusstes Unternehmen möchten wir andere IT-Spezialisten vor dieser neuen Form der Phishing-Attacke warnen. Wir planen, diesen Artikel zu verbreiten, um das Bewusstsein für solche Bedrohungen zu schärfen.
Über den Autor
Dieser Artikel wurde von einem IT-Sicherheitsspezialisten bei der SKAWINSKI GmbH verfasst. Das Unternehmen bietet professionelle Dienstleistungen zum Schutz digitaler Infrastrukturen, von E-Mail-Security bis hin zu Cloud- und AP-Sicherheitslösungen. Bei Rückfragen oder Interesse an einer tiefergehenden Analyse dieses Falls wenden Sie sich bitte an: robert@skawinski.at
Über die SKAWINSKI GmbH
Wir fangen da an, wo andere aufhören. Mit unserer kompromisslosen Einstellung „Geht nicht gibt’s nicht“ bietet die SKAWINSKI GmbH innovative IT-Lösungen für Businesskunden und Privatkunden. Unsere Leistungen umfassen:
(Hinweis: Personenbezogene Daten und E-Mail-Adressen wurden zum Teil zensiert.)
Nachricht von Microsoft
„[…]
vielen Dank für die Zusendung der Serverprotokolle.
In der Non-Delivery-Report (NDR) sehe ich, dass die E-Mail über die folgende IP-Adresse gesendet wurde.
Diese IP-Adresse ist jedoch nicht in Ihrem aktuellen SPF-Eintrag enthalten.
Existing record.
v=spf1 a mx ip4:77.119.251.219 ip4:157.90.149.69 ip4:65.108.73.154 -all
Sie haben zwei Möglichkeiten:
Fügen Sie die IP-Adresse in Ihren SPF-Eintrag ein:
Expected record:
v=spf1 a mx ip4:77.119.251.219 ip4:157.90.149.69 ip4:65.108.73.154 ip4:40.107.21.91 -all
Senden Sie die E-Mail über eine andere IP-Adresse, die bereits in Ihrem SPF-Eintrag enthalten ist.
Ich warte auf Update von Ihnen
Falls Sie Fragen haben oder weitere Hilfe benötigen, stehe ich Ihnen gerne zur Verfügung.
[…]“
Nachricht von Robert Skawinski
… Aufzählung der Unstimmigkeiten …
„[…]
Aus diesen Informationen geht hervor, dass die Phishing-E-Mail über die Microsoft-Infrastruktur versendet wurde, möglicherweise durch Missbrauch gültiger Microsoft-IP-Adressen. Es handelt sich um eine gefälschte NDR-Meldung, die darauf abzielt, Empfänger zu täuschen und potenziell schädliche Aktionen auszuführen.
Zusätzliche Beobachtungen:
Die Aufforderung, die IP-Adresse 40.107.21.91 in unseren SPF-Eintrag aufzunehmen, ist nicht nur unangebracht, sondern auch sicherheitskritisch. Dies würde potenziellen Angreifern ermöglichen, Phishing-E-Mails in unserem Namen zu versenden, die von SPF-Prüfungen als legitim anerkannt würden.
Dass sowohl in der NDR-Mail als auch von Ihrer Seite gefordert wird, eine Microsoft-IP-Adresse unserem SPF-Eintrag hinzuzufügen, könnte darauf hindeuten, dass ein Exchange-Server kompromittiert ist.
Es scheint ein Missverständnis oder ein größerer Sicherheitsvorfall vorzuliegen. Ich bitte Sie daher dringend, den Vorfall erneut zu prüfen.
Bitte eskalieren Sie dieses Ticket an eine zuständige Sicherheitsabteilung bei Microsoft. Ich möchte sicherstellen, dass ich einen Artikel zu diesem Sicherheitsvorfall erst dann online stelle, nachdem Microsoft den Fehler intern beheben konnte.
Ich stehe Ihnen für weitere Rückfragen gerne zur Verfügung und hoffe auf eine schnelle Klärung dieses sicherheitsrelevanten Problems. […]“
Nachricht von Microsoft Support
„[…] Nach der Untersuchung des Problems bitte ich Sie, die Änderung des SPF-Eintrags zu ignorieren. Dies ist in diesem Fall nicht korrekt. Ich werde Sie kontaktieren, um Ihnen mitzuteilen, wie wir feststellen können, ob die NDR von einem Spoofer gesendet wird oder ob es sich um eine Microsoft-NDR handelt. […]“
Nachricht von Microsoft Support
„[…]
Vielen Dank für die Zusammenarbeit mit Microsoft Office 365 Support.
Nachstehend erhalten Sie eine Zusammenfassung des Sachverhalts für Ihre Unterlagen.
Bitte lassen Sie mich wissen, ob Sie irgendwelche zusätzlichen Informationen bräuchten
Wie abgesprochen wird die Serviceanfrage in unserem System archiviert. Sollten Sie weitere Fragen haben, diese könnte innerhalb der nächsten 7 Tage von portal.office.com wieder eröffnet werden. Problembeschreibung:
550 5.7.23 The message was rejected because of Sender Policy Framework violation
Lösungsschritte:
Das Problem liegt außerhalb der Supportgrenzen für diesen Mandanten, da der Absender extern ist und der Empfänger in einem anderen Mandanten gehostet wird
Clara tippt...