[English]Microsoft kämpft seit Februar 2025 mit Störungen seiner Microsoft 365-Dienste und Exchange Online, hält sich aber bezüglich der Ursache bedeckt. Mir liegen Informationen vor, dass ein Bug bzw. eine Schwachstelle in Microsoft Exchange Online dazu führte, dass ein Eingriff eines Tenant-Administrators unbeabsichtigt weltweit das Löschen von Postfächern angestoßen habe.
Anzeige
Kurzer Rückblick auf bisher Offengelegtes
Ich hatte hier im Blog erstmals im Beitrag Microsoft 365 Störung (1. März 2025) über die seit dem 1. März 2025 heftiger werdenden Störungen berichtet. Als die Störungen anhielten, habe ich dies in weiteren Blog-Beiträgen (siehe Artikelende) aufgegriffen. Von Microsoft wurde ein "verunglücktes Update" als Grund für die Probleme kommuniziert.
Am 6. März 2025 habe ich im Beitrag Outlook auch am 6. März 2025 gestört die Frage nach der Ursache aufgeworfen – eine Woche Probleme ist schon bemerkenswert – konnte aber noch keine Details liefern. Meine zum 4. März 2025 über die deutsche Presseabteilung an Microsoft gestellte Anfrage nach einem Post Incident Report und einer Aufklärung, warum die Cloud-Dienste gestört sind, blieb unbeantwortet.
In der Zwischenzeit erreichten mich diverse Leserbeobachtungen über ein sehr merkwürdiges Verhalten unter Exchange Online sowie bei Microsoft 365-Anwendungen. So hieß es von mehreren Quellen, dass bei Kunden "The mailbox doesn't exist" gemeldet werde, wenn Mails verschickt werden sollen.
Anzeige
Weiterhin geht das Gerücht um, dass einige Exchange Online-Kunden glauben, dass Postfächer kompromittiert sein könnten. Im Blog-Beitrag Schwachstelle Ursache für Exchange Online- und MS 365-Probleme seit 1. März 2025? habe ich auf diese "Berichte" hingewiesen und auch über die (laut Microsoft geschlossene) Schwachstelle CVE-2024-49035 im Partner-Portal berichtet.
Brisant: Crasht Schwachstelle Exchange Online weltweit?
Am 4. März 2025 gab es eine merkwürdige Kontaktanfrage eines ungenannt bleiben wollenden Blog-Lesers, der mit mir über den "Exchange Online-Ausfall vom Wochenende" (1. März 2025) sprechen wollte und mir eine ziemlich brisante Information andeutete. Ich habe an diesem Abend des 4. März noch sehr tief in der Nacht ein Telefonat geführt und mehr oder weniger "am Küchentisch" einige Informationen notiert.
An dieser Stelle die Anmerkung, dass die nachfolgenden Aussagen mit Vorbehalt erfolgen und nicht mit Screenshots etc. belegt werden können, da alles gelöscht wurde. Als Hintergrund schicke ich noch voraus, dass die betreffende Person sich zwar gut informiert zeigte, aber nicht selbst direkt in den nachfolgend skizzierten Vorfall involviert war. Einige der nachfolgenden Aussagen fallen aber mit dem Bild zusammen, welches ich aus verschiedenen Quellen oben im Text (sowie in den verlinkten Blog-Beiträgen) zusammen getragen und veröffentlicht habe. Diese Informationen sind erst nach dem Gespräch mit der betreffenden Person online gegangen. Für mich alles in allem ein stimmiges Bild, was meine Quelle da beschrieben hat.
Kunde hat seit einer Woche Exchange Online-Probleme
Die Geschichte beginnt damit, dass ein Microsoft 365-Kunde seit Februar 2025 massive Probleme hatte, und sich die Situation ergab, dass er in der letzten Februar-Woche keinerlei Mails mehr mit Exchange Online versenden konnte.
Ein IT-Dienstleister, der den Kunden betreut, hatte den Microsoft-Support hinzugezogen, der aber die Probleme nicht lösen konnte. Das war die Situation zum Freitag, den 28. Februar 2025, also einen Tag, bevor die Störung der Microsoft Cloud-Dienste erstmalig von mir thematisiert wurde. Deckt sich auch mit Berichten von Blog-Lesern, die im Februar 2025 immer mal wieder von sporadischen Problemen beim Mailversand über Exchange Online berichten.
Junk-Ordner läuft voll und blockiert Postfach
Der IT-Dienstleister, der auch Tenant-Administrator für den betroffenen Kunden ist, machte eine merkwürdige Entdeckung. Am 28. Februar 2025 stellt er fest, dass 50.000 SPAM-Mails auf dem Tenant "durchschlugen" und der SPAM-Ordner der Postfächer voll läuft. Mutmaßlich hat da ein SPAM-Filter oder die Exchange Online Protection (EOP) versagt.
Da es nun auch Quota-Warnungen gab, versuchte der IT-Dienstleister die SPAM-Ordner in einem Mail-Postfach des Tenants zu leeren. Das war aber nicht möglich, so dass der Dienstleister per Fernwartung den Junk-Ordner mittels der PowerShell zu leeren versuchte. Auch dies wurde mit einer Fehlermeldung abgelehnt.
An dieser Stelle, so berichtet meine Quelle, habe der IT-Dienstleister am 28. Februar 2025 ein Support-Ticket mit dem Betreff "Junk-Ordner nicht löschbar" erstellt. Der Microsoft-Support meldete sich auch am gleichen Tag beim IT-Dienstleister und gab an, dass man den Inhalt des Junk-Ordners ebenfalls nicht löschen könne. Es folgte das Versprechen, den Support-Fall an den Second Level-Support weiter zu reichen.
Ergänzung: Ich bin nicht sicher, ob es zutrifft – mir ist in anderem Zusammenhang dieser Kommentar untergekommen, der besagt, dass das Outlook-AddIn von ESET Endpoint Security ebenfalls einen Fehler verursacht, der zur Folge hat, dass der Junk Mail Ordner geflutet wird.
Ergänzung 2: Ich habe bei meiner Quelle nachgefragt, der IT-Dienstleister setzt ESET Endpoint Security ein, was den gefluteten SPAM-Ordner erklärt.
ChatGPT befragt und ein Ticket in die Hölle bekommen
Nachdem der Kunde bereits 4 bis 5 Tage keine Mails mehr empfangen konnte, der Microsoft Support auch seit einer Woche nicht in der Lage war, zu helfen, war guter Rat teuer. Am Samstag, den 1. März 2025 kam der IT-Dienstleister auf die Idee, Microsofts KI-Lösung ChatGPT zu befragen, "wie er denn den Junk-Ordner in Exchange Online löschen könne".
Wie es so ist, lieferte ChatGPT auch eine vorgebliche Lösung in Form einer PowerShell Befehlsfolge. Gegen 21:30 Uhr, so wurde es mir von meiner Quelle berichtet, kopierte der IT-Dienstleister die PowerShell Befehlsfolge aus dem ChatGPT-Fenster 1:1 in das PowerShell-Fenster von Exchange Online und ließ diese Befehlssequenz in einem Stück ausführen.
Das war wohl das "Ticket in die Hölle", hätte der IT-Dienstleister die PowerShell-Befehle einzeln im PowerShell-Fenster eingegeben, wären diese teilweise mit einer Fehlermeldung abgelehnt worden, hieß es.
So eskalierte das Ganze: Sofort nach dem Absetzen der PowerShell-Sequenz funktioniert Office 365 nicht mehr, berichtet die Quelle. Gleichzeitig sah der IT-Dienstleister, dass bei Exchange Online die Fehlermeldungen in die Höhe schnellten. Es musste irgend etwas gravierendes durch die PowerShell-Befehlssequenz passiert sein.
Die Quelle, ebenfalls IT-Dienstleister, saß zufällig am 1. März 2025 auch noch spät am Abend vor dem Rechner und hatte den eigenen Exchange Online-Tenant im Administrator-Panel geöffnet. Gegen 22:00 Uhr stellt die Person fest, dass sein eigenes Postfach im Tenant plötzlich weg war. Es kam dann eine Meldung "Wir bereiten gerade ein Postfach vor", gefolgt von der Mitteilung "Wir richten gerade ein Postfach ein", sprich: dass verschwundene Postfach wurde wohl wieder eingerichtet.
Die Quelle meinte dazu: "Es sah so aus, als ob Microsoft in diesem Augenblick damit begann, nicht mehr vorhandene Exchange Online-Postfächer zu restaurieren", die wohl gerade durch den nachfolgend beschriebenen Vorgang gelöscht wurden.
Diese Beobachtung deckt sich einerseits mit den Beobachtungen anderer Blog-Leser, die ich oben im Text bzw. ausführlicher im Blog-Beitrag Schwachstelle Ursache für Exchange Online- und MS 365-Probleme seit 1. März 2025? erwähnt habe. Diese Beobachtung ist auch zur Beurteilung folgender Aussagen relevant.
Ab diesem Punkt wird es dann ungemütlich, denn der IT-Dienstleister sitzt per Remote-Session am Tenant des Kunden und muss feststellen, dass er mit seinen Office 365-Anwendungen nicht mehr zugreifen kann. Und einige Kilometer weiter sitzt eine weitere Person, die gerade feststellt, dass ihr eigenes Postfach im Exchange Online-Tenant weg ist.
Anruf des Microsoft-Supports mit Drohungen
Beim IT-Dienstleister, der gerade eine PowerShell-Sequenz in Exchange Online abgesetzt hat und nun vor den "Trümmern seines Schaffens" sitzt, klingelte, so meine Quelle, am späten Samstag-Abend das Telefon. Am anderen Ende meldet sich der Microsoft Support und erklärt dem verdutzten IT-Menschen, dass er "gerade großes Glück gehabt habe, dass er das Telefon abgehoben habe". "Man sei bereits dabei gewesen, die Staatsanwaltschaft zu verständigen, um eine Polizeiaktion – im Nachbarland – durchzuführen und die Beamten beim ihm vorbei zu schicken". Garniert war dies mit der Frage, was der Mann gerade mache.
Der IT-Dienstleister erklärte den oben skizzierten Sachverhalt (keine Mail seit 4-5 Tagen empfangen, Junk-Ordner laufen voll, Microsoft-Support konnte nicht helfen, also ChatGPT befragt und den ausgespuckten Ratschlag befolgt). Die Antwort des Microsoft Supports, die mir dann im Gespräch von meiner Quelle berichtet wurde, lautete, dass der IT-Dienstleister durch die PowerShell-Befehlssequenz gerade weltweit die Löschung aller Exchange Online-Postfächer angestoßen habe.
Muss man sich auf der Zunge zergehen lassen: Der IT-Dienstleister war zwar globaler Tenant-Administrator, dürfte aber in Exchange Online nur auf seinen eigenen Tenant zugreifen. Wenn er diesen in den digitalen Orkus schickt, wäre das zwar doof, aber eine Auswirkung auf andere Tenants müsste bei einer sauber funktionierenden Architektur ausgeschlossen sein. Der Tenant-Administrator dürfte schlicht nicht die entsprechenden Berechtigungen haben.
Mir wurde von meiner Quelle berichtet, das der IT-Dienstleister vom Microsoft den Vorwurf hörte, gerade "Millionen-Schäden" verursacht zu haben. Gleichzeitig kam die Drohung, "nur ja nichts nach außen, an Dritte dringen zu lassen". Und es sei eine Aufforderung, sofort eine Vertraulichkeitsvereinbarung (NDA) zu unterzeichnen, gefallen.
Der Betroffene lehnte dies, so meine Quelle, ab und erwähnte, dass er nichts unterzeichne, bevor er nicht seinen Anwalt kontaktiert habe. Weiterhin habe ich erfahren, dass der Microsoft Support in einer Remote-Sitzung auf der Maschine des IT-Dienstleisters aufgeschaltet war und sich zeigen ließ, was ChatGPT an Befehlen ausgegeben habe. Laut Aussage meiner Quelle löschte der Microsoft Support dann den Chat-Verlauf im ChatGPT-Fenster, so dass dieser Sachverhalt nicht mehr dokumentiert werden kann.
Wie oben erwähnt, hätte Exchange Online in der PowerShell die einzelnen Befehle wohl irgendwie mit einer Fehlermeldung abgewiesen. Durch die Befehlssequenz wurde die PowerShell-Eingabe-Validierung unbewusst ausgehebelt. Es wurde ungewollt so etwas wie eine SQL-Befehls-Injection durchgeführt, die der PowerShell-Befehlssequenz plötzlich globale Rechte verschaffte und dann Tenant-übergreifende Wirkung zeigte – etwas, was niemals passieren dürfte.
Und damit sind wir wieder bei der bereits weiter oben erwähnten Schwachstelle CVE-2024-49035 im Partner-Portal, wo wohl auch Zugriffe auf Inhalte möglich waren, die man so nie "anfassen" durfte. Ob es die gleiche oder eine andere Schwachstelle ist, ist hier unerheblich. Als Tenant-Administrator muss ich davon ausgehen, dass jede Aktion von mir nur auf meinen gebuchten Tenant und nicht weltweit auf andere Tenants wirkt.
Unkalkulierbare Risiken und unschöne Erfahrungen
Mir wurde berichtet, dass der Betroffene erst einmal für zwei Tage vollständig geplättet war, um sich von diesem Schock und den Drohungen des Microsoft Supports zu erholen. Im Anschluss kontaktierte er sowohl seinen Anwalt als auch meine Quelle, um sich zu beraten.
Wenn sich der Sachverhalt, so wie berichtet (es ist ja eine Aussage von jemand, der jemanden kennt), zugetragen haben sollte, wäre dies ein dicker Hund. Aus meiner Sicht decken sich die beschriebenen Beobachtungen mit dem, was ich aus anderen Quellen erfahren und oben im Text skizziert habe. Der Ablauf klingt daher plausibel – und warum sollte mir jemand eine Räuberpistole auftischen?
Mein Fazit: Als Tenant-Administrator von Exchange Online oder anderen Microsoft (Cloud-)Diensten arbeitet man mit einer Black-Box und muss sich darauf verlassen, dass der Anbieter eine sichere Umgebung bereitstellt. Andererseits stehst Du als Tenant-Administrator, angesichts des oben skizzierten Sachverhalts, im Risiko, plötzlich "Haus und Hof zu verlieren", weil eine Aktion "Millionen Schäden verursachen könnte". Das kann es echt nicht sein.
Und es stellt sich die Frage, ob der Vorfall für Tenant-Administratoren eventuell DSGVO-relevant ist und der Datenschutzaufsicht gemeldet werden muss. Denn es gibt ja den Verdacht, dass Dritte über ähnliche PowerShell-Sequenzen Tenant-übergreifend auf Postfächer zugreifen konnten oder sogar noch können. Es steht ja in den oben erwähnten Beiträgen der geäußerte Verdacht von Unternehmen im Raum, die glauben, dass Postfächer kompromittiert worden seien.
Ich hatte Microsoft erstmals am 4. März 2025 über deren deutsche Presseabteilung um einen Post Incident Report zum Ausfall vom 1. März 2025 gebeten, was bisher ohne Antwort blieb. Gut, die müssen mir als Blogger nicht antworten.
Nun habe ich Microsoft zum 12. März 2025, über deren deutsche Presseabteilung, bevor dieser Beitrag online ging, erneut um eine Stellungnahme zu obigem Sachverhalt gebeten. Als der Text entstand bzw. online ging, lag diese noch nicht vor, und wird gegebenenfalls nachgetragen.
Nachtrag: Ich finde es spannend, die nachfolgenden Kommentare zu verfolgen. Wie oben erwähnt – die Schilderung erfolgte unter Vorbehalt – weder meine Quelle noch ich waren beim Vorfall dabei. Aber Kommentare wie "Woher hatte der MSler die Telefonnummer? – und das Ganze ohne Beleg als "Fake-Anfruf" darzustellen, liegt "a bisserl" daneben. Ich lege nicht alles offen, aber die Telefonnummer des Kontakts stand im Admin-Portal (abgesehen davon, dass es ständig Telefonkontakt zwischen MS-Support und dem IT-Mitarbeiter als MS-Partner gab).
Die unterstellte Fahrlässigkeit des IT-Manns lässt sich auch glatt ziehen – die Postfächer wurden vor dem Eingriff natürlich gesichert. Was bleibt? Natürlich besteht die Möglichkeit, dass alles "Fake" oder ein großes "Missverständnis" ist – der IT-Mitarbeiter blickt auf eine "black box", was die Auswirkungen von PS-Befehlen betrifft.
Microsoft könnte sofort mit dem Statement "stimmt nichts davon" oder "das und das ist passiert" alles glatt ziehen. Aber Microsoft schweigt. Von daher warte ich ab, ob noch was bezüglich der Sache bzw. zum Grund der lang anhalten Exchange Online-Störung öffentlich wird.
Beobachtungen eines weiteren Lesers
Ergänzung: Nach Veröffentlichung dieses Beitrags hat sich ein ungenannt bleiben wollender Leser gemeldet und einige Beobachtungen geschildet. Der Leser schrieb mir, dass er selbst Tenant-Administrator für eine zweistellige Zahl an Kunden sei und sich zu Problemen mit der Samsung-Mail App schon geäußert habe.
In der Mail bestätigt er, dass das Problem nicht nur europäische Kunden/Tenant betrifft, sondern auch US-amerikanische. Seine Partnerin arbeitet für ein kleines US-Unternehmen, und der Exchange Online-Tenant samt den hostenden Servern liegen unzweifelhaft in den USA, so die Aussage.
Die Frau hat ein US- und ein europäisches M365-Konto in der Samsung-Mail App eingebunden (selbes Smartphone). Nur mit dem US-Konto gibt es die Probleme. Das europäische Konto liegt im Tenant des Lesers. Bei diesem europäischen Tenant gibt es bei zwei Postfächern Probleme, beim Postfach der Frau nicht.
In der Summe sieht es nach einem globalen Problem aus, welches aber nicht alle Konten in einem Tenant betrifft, schließt der Blog-Leser. Auffällig sei auch, dass das Problem nicht ständig auftaucht, sondern mal mehr und mal weniger häufig. Was die Frage aufwirft: "Was zur Hölle bei Microsoft in der Cloud los ist?".
Mag sein, dass die oben berichteten Beobachtungen "Fehlinterpretationen" oder Zufall sind. Aber es gibt nach wie vor keine Erklärung von Microsoft zu diesen Ausfällen. Mir ist nun noch die Info von eingangs zitierten Quelle zugegangen, dass der Microsoft Support zyklisch beim Tenant-Administrator aus obigem Fall anrufen würde – aber eine Erklärung, dass die Ursache gefunden oder der Fehler gar behoben sei, habe es noch nicht gegeben.
Mir fällt ein Spruch von Ex-Bundeskanzlerin Merkel ein: "Alternativlos". Muss wohl auch für die obige Lösung gelten, wenn Kunden trotz der wiederkehrenden Probleme, Sicherheitsvorfälle (Storm 0558, Midnight Blizzard) und Kosten weiter auf die Cloud setzen.
Ähnliche Artikel:
Microsoft 365 Störung (1. März 2025)
Hält die Microsoft 365/Exchange Online-Störung vom 1. März 2025 auch am 3. März 2025 an?
Outlook auch am 6. März 2025 gestört
Schwachstelle Ursache für Exchange Online- und MS 365-Probleme seit 1. März 2025?
Anzeige
Da macht sich aber jemand sehr wichtig
"Jede minimal kritische Frage wischte Altman mit kleinen Ablenkungsmanövern weg. Er selbst wisse nicht, wie genau die KI zu den Ergebnissen komme, die sie produziert, aber er wisse ja auch nicht, wie genau ein Auto gebaut sei, wenn er es nutze."
https://www.djv.de/news/blog/blog-detail/doch-sam-du-solltest-wissen-wie-chatgpt-funktioniert/
Sollen sich auch alle schämen, die gedankenlos sich der Wunder der Wissenschaft und Technik bedienen, und nicht mehr davon geistig erfasst haben als die Kuh von der Botanik der Pflanzen, die sie mit Wohlbehagen frißt.
© Albert Einstein, Eröffnungsrede IFA 1930
Deshalb bleibt er auch anonym. hä?
Wenn tatsächlich ein Powershell-Befehl aus ChatGPT falsch interpretiert worden sein soll und so Schreibzugriff auf „alle" fremden Tenants möglich machte, würde das dem Fass wirklich den Boden raushauen, gleich nach dem Verlust des Masterkey. Das klingt eigentlich fast zu absurd.
Wirklich lustig ist allerdings die Aussage die Staatsanwaltschaft anzurufen (wäre doch eher die Polizei zuständig) und dem verursachten Schaden.
Wie werden/wurden denn die Schäden durch ständig fehlerhafte Updates oder den globalen Ausfall von Crowdstrike von Microsoft wieder gutgemacht? :-D
Ich denke, die Aussage "Staatsanwaltschaft" ist korrekt – meine Interpretation ist, dass das Stichwort "Cybercrime" da relevant ist – imho vermutete man einen Angriff und es wäre ein Zugriff über Staaten erforderlich gewesen. Und mein Verständnis des Gehörten ist, dass die Sequenz an PS-Befehlen die Prüfung ausgehebelt hat.
Anmerkung: Ich habe bisher bewusst mit dem Betroffenen nicht über die Details gesprochen (sondern zitiere Informationen meiner Quelle), um den Betroffenen nicht in Schwierigkeiten zu bringen.
immer dieses Gemecker über die Cloud. Weil's ja alle so gut hinbekommen mit Open Source und Onprem musste man das mit NIS-2 regulieren…
Das der Fehler ausgerechnet in DE auftritt…
Ich denke eine schlüssige Erklärung für das Verhalten des Supports wird eine exzessive Nutzung gewesen sein, die ggf. die Infrastruktur beeinträchtigt hat, ich glaube das wäre auch ein AGB Verstoss wenn ich mich recht entsinne. Aber jemand der ohne nachzudenken Code von A nach B kopiert kann man auch unterstellen, dass er das nicht wusste, verstehen konnte, …
Ziemlich viel denken von deiner Seite, ohne belastbare Details … schätze ich mal – Substanz sehe ich in deinem Kommentar eher weniger – nix für ungut.
> immer dieses Gemecker über die Cloud.
Ist aber so. Und es kommt ein weiterer Aspekt hinzu:
Wenn nämlich ALLE Kunden in der Cloud sind. Weil es KEINE onPremiselösungen mehr gibt, kommt die nächste keule: Nämlich Preiserhöhungen. Ja, nicht eine, sondern regelmäßig werden die Preise soweit wie möglich angehoben. Um die vielen vielen Kühe noch mehr zu melken.
Das man sich damit aber auch ins eigene Fleisch schneidet, interessiert die Hersteller nicht. Denn wenn der Bauer nicht mehr lebt, kann er dem Lehnsherrn keine Steuern mehr abgeben.
Ist nun mal so. Wenn ich das Monopol habe, kann ich die Kunden ausquetschen. Und darauf wird es zukünftig hinauslaufen.
Mal von den Abhängigkeiten abgesehen, weil die Entscheider nur $-Zeichen bzw. €-Zeichen in den Augen haben.
Man hat ja dem Unternehmen so viele Kosten eingespart. Da muss doch ein dicker Bonus drin sein.
"Wirklich lustig ist allerdings die Aussage die Staatsanwaltschaft anzurufen (wäre doch eher die Polizei zuständig) "
Wieso? Die Staatsanwaltschaft ist in strafrechtlichen Ermittlungsverfahren Herrin des Wieso Verfahrens und damit der Polizei übergeordnet. Strafanzeigen können nicht nur bei der Polizei, sondern auch bei der Staatsanwaltschaft und sogar direkt beim Amtsgericht erstattet werden (vgl. § 158 Abs. 1 StPO). (Alles auf Deutschland bezogen.)
Dicker Hund ist aber sehr wohlwollend formuliert.
Da bin ich zunächst sprachlos und dann gespannt, wie sich das in weiteren Foren und Blogs niederschlägt, sofern das alles wahr ist. Das soll nicht heißen, dass ich es nicht glaube, aber wie GB schon schreibt, ist es halt auch noch Hörensagen.
Schade, dass der Informant keine Fotos gemacht hat, aber vermutlich hätte ich in der Situation auch andere Sorgen gehabt.
Ein unschuldiger Admin verursacht angeblich einen Millionenschaden, weil der Anbieter Schrott abgeliefert hat und wird bedroht? Geht irgendwie gar nicht.
Alle Admin sollten nun sehr genau dokumentieren, was sie tun, um sich gegen Ansprüche bei Fehlfunktionen absichern zu können.
Ich kann nur hoffen, dass nun ein paar Entscheider schlauer werden.
>>> Schade, dass der Informant keine Fotos gemacht hat, aber vermutlich hätte ich in der Situation auch andere Sorgen gehabt.
Ne – so ein Script kopiert man sich in eine text(!) Datei und schaut es sich dann erst mal an was es tut. Ist es plausiblel kann man es laufen lassen und die Text Datei hätte ich auf Teufel komm raus nicht löschen lassen. Ich hätte auch keinen MS Support an dem Rechner so einfach rum fummlen lassen. Das wäre schon ein spezieller Jumphost gewesen, auf dem nur Kopien herumliegen…
Ketzerisch gesagt:
Man (der IT Dienstleister) könnte ja nochmal in ChatGPT die Frage erneut stellen. Und dann dessen Antwort in eine Textdatei kopieren.
Zwecks Analyse, was ChatGPT als Lösungsmöglichkeit vorgeschlagen hatte.
Wenn das alles so stimmt, wird ChatGPT diese Antwort wohl nicht noch einmal geben, dafür wird MS sorgen.
Das wird aber meist nicht die identische Antwort sein.
ChatGPT antwortet selten die gleichen Dinge, teils auch mal das Gegenteil, ist für viele überraschend, die sich für was auch immer auf den Müll verlassen…
Leider kann ich zum Thema nichts konkretes beitragen, aber es stellen sich doch einige Fragen:
1. Man verlässt sich (wie auch GB sagt) darauf, dass eigene Dummheit höchstens die eigenen Daten bzw. die seiner Kunden vernichtet. Frage an die rechtlich Gebildeten, wie weit reicht die Haftung, wenn man beruflich oder privat bei Microsoft, Google, oder meinetwegen der Telekom versehentlich deren ganzen Laden in den Abgrund reißt? Ist der Servicevertrag relevant?
Vergleich: Schließe ich eine Lampe dumm an, und das Haus fackelt ab, die Leitungen bis zum Kraftwerk schmoren durch, und das Kraftwerk explodiert, habe zumindest für das Haus ein Problem (und hoffentlich nicht auch bis zum Kraftwerk).
2. Ist es klug, als IT-Dienstleister eine AI um Hilfe zu bitten, und dann einen AI-Vorschlag ohne genügendes Verständnis auszuführen? Insbesondere dann, wenn man dabei evtl. seine Kundendaten in den Orkus schickt? Haftung bzw. Fahrlässigkeit??
3. Wenn eine AI schon aus Versehen einen Prompt from Hell erzeugen kann, anscheinend schlummern da ungeahnte Perlen in den Trainingsdaten, was kann dann eine als Hackertool umgepolte AI? Private (lokale!) AI zum Pentesten??
Zu 2 und 3: Diese Fragen beantwortet ihr euch bitte selbst – ich habe das Thema AI (LLMs) ja oft genug mit meinen Zweifeln thematisiert (es schlummern noch einige Sachen hier, wo ich noch keine Zeit hatte, das Ganze mal zu einem Artikel zu derivieren). Aber der Fall zeigt, was da denkbar ist – und jetzt laufen Leute her, die sagen "wenn ich krank bin und der Doc hat keine Zeit, meine Arztberichte zu lesen, soll eine KI ihm alles zusammenfassen und sagen, was zu tun ist …".
Hallo,
das kann, nein das darf doch so nie möglich gewesen sein!
Aber anscheinend hat Microsoft dann doch Backups die sie erstellen und bei bedarf einspielen könnten.
Bitte dranbleiben.
mfg Peter
gemäß dem Falle, dass das alles so stimmt finde ich es sehr bedauernswert, dass der Löschvorgang so schnell entdeckt wurde und offensichtlich nur wenige davon betroffen sind. Richtig Platzen soll der Laden aus Redmond und alle Postfächer und Netze von denen, die sich mit diesem einlassen.
Das mit "AI befragen" und dem "nicht verstehen, was man macht" schmunzelnd zur Kenntnis nehmend.
> "Andererseits stehst Du als … Administrator … im Risiko, plötzlich "Haus und Hof zu verlieren", weil eine Aktion "Millionen Schäden verursachen könnte". Das kann es echt nicht sein."
Doch das ist so, schon immer so gewesen. Auch die Mitarbeiter eines Systemhauses sind bei Auslegung einer grober Fahrlässigkeit oder gar eines Vorsatzes nicht geschützt. Und etwas machen, ohne zu wissen was, das wird mit Sicherheit als fahrlässig interpretiert. Und IMHO auch genau zurecht. Wie heißt es so schön: Unwissenheit schützt vor Strafe nicht und ein Kunde hat ja genau deswegen einen vermeintlichen Fachmann zu Rate gezogen. Nicht vergessen, das Opfer ist der Kunde, nicht der Administrator.
Am Ende des Tages wird ein Systemhaus, allein um sich und seine Reputation zu schützen, alles auf die "niedrigst hängende Frucht" abschieben.
meine erste Reaktion war das Datum zu prüfen, aber es ist nicht der 01.04.
es bleibt spannend.
Das war auch mein erster Eindruck,
Viel "hörensagen", nichts belegt, angeblich auch die ScreenCaptures verschwunden. Also das disqualifiziert den ganzen Bericht. Fachlich kann man ja schon mal lauf nach denken. Es gab vor einigen Monaten den "SuperkeyGau" so man alle Inhalte lesen konnte. Die ist dokumentiert. Ansonsten denkt einfach mal nach
1. Es ist ein Unterschied, ob der Dienst erreichbar ist oder nicht. Also DNS, Internet Routing, Firewall etc. Ich hatte die ganze kein kein problem. also waren zumindest meine Dienste nicht betrofen
2. Übergriffigkeit. Ich will es nicht ausschliessen aber unwahrscheinlich dass jemand wieder auf alle Postfächer Techte hatte. Aber vielleicht haben einige Admins ihre "Consent-Berechtigungen" nicht im Griff. Dann kann es schon mal bitter werden
3. 50.000 Mails in Junk. Ihr kennt schon die Transport Limits von Exchange Onine (Mails pro Zeit ein/ausgehend) und wenn schon. lass sie drin, sie stören nicht sofort, wenn man nicht die 100 GB erreicht hat.
4. Mailadresse nicht erreichbar/unbekannt? dann hat jemand das AD-Konto gelöscht oder die Lienz weggenommen. Das macht auch kein User.
Ich könnte noch viel weiter schreiben. Aber hier ist viel zu viel "Fake news" drin, als dass man das weiter beachten sollte.
Exchange Online wird nie 100% fehlerfrei/störungsfrei laufen. Aber immer noch stabiler als die zig tausend Exchange 2016 und früher Server, die eine reale Gefahr sind.
Kann deinem Kommentar nur zustimmen.
Manches kann vielleicht wirklich so gewesen sein, vieles klingt für mich doch sehr weit hergeholt und nicht wirklich glaubwürdig.
Wir haben derzeit eine Hybrid Umgebung im Einsatz und erst wenige Mailboxen in die Cloud migriert (unter anderem meine).. Wir haben auch nichts von den beschriebenen Ausfällen der Online Dienste bemerkt.
Und das chatgpt ein globalsecret oder eine bestehende Lücke in seinen Trainingsdaten hat ist schon sehr unwahrscheinlich. Und dass dadaber nur hier auftrat ist noch weit weniger wahrscheinlich.
Das hört sich alles sehr danach an als würde die Quelle nicht die Wahrheit sagen. wRum auch immer.
Das hört sich soweit her geholt an, dass es schon wieder wahr sein könnte..
Aber ob ein PowerShell Script als Block Befehle ausführen kann, welche sonst geblockt werden, halte ich für eher unwahrscheinlich. Mal schauen was aus der Meldung wird.
Hm, dazu wird ein PowerShell-Experte eher was dazu sagen können.
Ich tippe mal auf eine SQL-Injection, welche mittels PowerShell ausgeführt wurde.
Im Szenario einer Mensch-KI-Kollaboration, also Social Engineering durch KI, ist eben der Mensch selbst das Risiko, weil er durch Unwissenheit, Vertrauen oder Manipulation zur ausführenden Instanz wird, indem er KI generierten Code in sein Exchange-Online Interface eingibt.
Ist natürlich reine Phantasie. SAM Altman selbst sagt zwar, er wisse nicht wie ChatGPT funktioniert, müsse es aber auch nicht, weil man ja auch nicht wissen müsse wie ein Auto funktioniert, um damit fahren zu können.
Und mal ehrlich, wer benutzt denn KI generierten Code in sicherheitsrelevanten Umgebungen?
Alle. ok, Zuviele. du glaubst nicht, wie viele auch mittlerweile ihre Scripte erstellen lassen, ohne zu hinterfragen.
tatsächlich sind die PS Ausgaben wohl brauchbar.
So wie die Übersetzungen von Deepl & Co. meistens brauchbar sind, aber manchmal erzählen sie doch Blödsinn, z. B. wegen Homonymen.
Wenn man dann die andere Sprache nicht hinreichend gut versteht, wird halt Blödsinn rausgeschickt (im Business-Umfeld mehrfach erlebt).
Oder man liest die MS-Dokus auf Deutsch, immer wieder lustig:
"Benutzer-Dosen", finde leider die Quelle nicht mehr, vielleicht wurde der Artikel inzwischen korrigiert.
Oder wie es im Hyper-V Cluster 2019 an einer stelle auf Deutsch heisst: "behinderte".
Wurde wohl "disabled" übersetzt ;-)…
Bei VMware wurde der Status "down" einer Netzwerkkarte mit "nach unten" übersetzt. Sowas findet sich immer wieder.
Da „freue" ich mich doch gleich umso mehr, dass wir gerade dabei sind zu M365 und Exchange Online zu migrieren und das auch noch mit dem Argument, dass es sicherer ist.
Was ein Haufen Schrott.
Das klingt alles so absurd, aber irgendwo auch logisch!
Schon alleine die Möglichkeit Befehle so übergreifend abzusetzen und damit MS365 abzuschießen erzeugt die Fragestellung, was für einen Murks man dort anbietet für die Kundschaft? Hat MS überhaupt noch einen Überblick? Wie kompromittiert ist deren ganzes System? Wer weiß dort überhaupt was geht und was nicht? Und die große Frage: Wieso raffen das die ganzen Kunden nicht?
Klingt wie ein 'IT-Hack' im Film / Serie. Aber gleichzeitig kann es halt leider auch MS-Software sein und so wirklich überrascht ist man da auch nicht mehr. Es eröffnen sich ja fast tagtäglich neue Abgründe im Bereich Softwarequalität (nicht nur bei MS).
Hoffe, sollte es stimmen, für den IT-Dienstleister geht die Sache gut aus.
Dass KI solche Hacks ausspuckt, kann ich mir schon vorstellen: Nicht ohne Grund schicken sämtliche KI-Bildgeneratoren die erzeugten Bilder nochmal durch einen Zensurfilter, obwohl Anforderungen mit kritischen Begriffen schon vorab geblockt wurden.
Aber – für mich hinkt die Story an einer anderen Stelle: Aus Sicht von MS hat sich da ein Außenstehender tief ins System gebohrt und einen zerstörerischen Befehl abgesetzt, der nun unaufhaltsam die Datenbank zerlegt. Und nachdem dies geschehen ist (es ist ja nicht so, dass der Unbekannte noch immer dabei wäre, auf die Del-Taste einzuhämmern), greift ein Mitarbeiter vom sonst so unnahbaren MS-Kundendienst zum Telefonhörer: „Hallo, wie geht's? Hier spricht der Microsoft Support, schön, dass ich Sie gleich erreiche. Was treiben Sie eigentlich gerade, wenn ich fragen darf?" Wozu? In den Arm fallen kann er dem Hacker nicht mehr. Höchstens ihn an der Flucht hindern, und da wäre so ein Anruf kontraproduktiv.
Ja, das ist mir beim Lesen auch aufgefallen. Das Verhalten des Support Mitarbeiters passt so gar nicht zu meine Erfahrungen mit dem Supports eines Großkonzerns. Aber ich bin auch nur selten über den 1 Level hinausgekommen. Auch ist mir die Motivation des Anrufs nicht klar. War doch schon alles gelaufen.
Vielleicht haben sie ja noch mehr Aktionen befürchtet und dachten sich: wenn wir dem "Angreifer" zeigen, dass wir seine Aktion sehen, hört er damit auf.
Kann nicht auf entsprechende Erfahrung zurückgreifen, aber es klingt für mich nicht völlig unplausibel.
Woher hatte der MSler die Telefonnummer?
Wie konnte der MS Mitarbeiter den Chat so schnell und einfach löschen?
Wenn er da etwas strafwürdiges vermutete würde er durch einen solchen Anruf dem Täter die Chance geben, Beweise zu vernichten.
Ein Script das ChatGPT erzeugt hat ohne jede Prüfung mit Admin rechten zu im lebendigen System zur Ausführung zu bringen ohne einen Hauch von Ahnung klingt einfach märchenhaft, bekifft.
Natürlich kann man Powershell sagen, ob es bei Fehlern abrechen oder weiter machen soll, mache Fehler sind ja unvermeidlich.
Auf der Kommando Zeile hätte man vermutlich stoppt, wenn man die oft mehrseitigen Fehlmeldungen gesehen hätte.
Das ist so nie passiert, und wenn doch, fürchtet der Admin zurecht um seinen Job. Er wäre eine völlige Fehlbesetzung.
Warum sollte jemand sich so eine Geschichte ausdenken?
Warum gab es Leute die mit voller Absicht zum Geisterfahrer wurden?
Die wollten über sich, ihre "Tat" im Radio hören.
Einfach krank.
klingt mehr wie ein Hoax. Quasi absurd.
Problematischer dürfte das Problem fortgeschrittener Angriffe auf die 365 Infrastruktur sein, wenn die Gerüchte stimmen, halten diese weiter an.
So gesehen sind Berichte dieser Art eher ein Ablenkungsmanöver.
Copilot
Natürlich, ich kann dir dabei helfen! Hier ist ein PowerShell-Skript, das alle Junk-Mail-Ordner in deinem Tenant löscht:
# Importiere das Exchange Online Modul
Import-Module ExchangeOnlineManagement
# Authentifiziere dich bei Exchange Online
$UserCredential = Get-Credential
Connect-ExchangeOnline -Credential $UserCredential
# Hole alle Postfächer im Tenant
$Mailboxes = Get-Mailbox -ResultSize Unlimited
# Durchlaufe jedes Postfach und lösche den Junk-Mail-Ordner
foreach ($Mailbox in $Mailboxes) {
$MailboxName = $Mailbox.UserPrincipalName
Write-Host "Lösche Junk-Mail-Ordner für $MailboxName"
# Hole den Junk-Mail-Ordner
$JunkFolder = Get-MailboxFolderStatistics -Identity $MailboxName | Where-Object {$_.FolderType -eq "JunkEmail"}
if ($JunkFolder) {
# Lösche den Junk-Mail-Ordner
Remove-MailboxFolder -Identity "$MailboxName:\Junk-E-Mail" -Confirm:$false
Write-Host "Junk-Mail-Ordner für $MailboxName gelöscht"
} else {
Write-Host "Kein Junk-Mail-Ordner für $MailboxName gefunden"
}
}
# Trenne die Verbindung zu Exchange Online
Disconnect-ExchangeOnline -Confirm:$false
Dieses Skript führt die folgenden Schritte aus:
Es importiert das Exchange Online Modul.
Es authentifiziert sich bei Exchange Online.
Es holt alle Postfächer im Tenant.
Es durchläuft jedes Postfach und löscht den Junk-Mail-Ordner, falls vorhanden.
Es trennt die Verbindung zu Exchange Online.
Stelle sicher, dass du die notwendigen Berechtigungen hast, um dieses Skript auszuführen.
Hier der Screenshot einer CoPilot-Ausgabe, die ich mal auf die Schnelle versucht habe
Schwierig bei all den FakeNews so etwas einzuschätzen und behalte mir immer eine gesunde Skepsis, ohne klare Beweise nur eine fantastische Story…hoffentlich.
Das ein Admin über ein Powershellbefehl eine Tenatübergreifende Kettereaktion auslöst, ist ja entweder ein Fehler im MS Cloudcosmos oder eine absichtlicher, nicht für die Öffentlichkeit bestimmte Hintertür.
Das dieser Befehl über ChatGPT erstellt wurde ist da in meinen Augen zweitrangig. ChatGPT erfindet ja nichts neues, sondern gibt nur bekannten Befehle wieder. Es besteht als sich die Möglichkeit das ein echter Powershell Crack irgendwann auch mal über diese Kombination von Befehlen gestolpert wäre.
Und sollte es wirklich ein echter Backdoor Befehl gewesen sein, stellt sich die Frage woher ChatGPT diesen kannte, das würde bedeuten das irgendjemand diesen Befehl mal bei ChatGPT eingeben hat.
Der eine findet einen Generalschlüssel für die MS-Cloud in einem Backup, der andere findet zufällig das Tor zur Hölle, passiert nicht sehr oft, aber ist möglich.
************************************
ChatGPT erfindet ja nichts neues, sondern gibt nur bekannten Befehle wieder
************************************
Falsch! ChatGPT (und jedes andere LMM) erfindet sehr wohl Neues und flunkert/fabuliert, das ist bekannt! Der hat sogar schon komplette Gerichtsurteile erfunden und in den USA wurde deswegen ein Anwalt belastet der sich darauf verlassen hat… ein aufmerksamer Richter hat halt etwas genauer hingeschaut. Oder Schwarze Nazis… hat es garantiert nie gegeben!
Bei Programmbefehlen fällt sowas halt weniger auf und funzt ja meistens irgendwie auch…und wenns mal nicht genau das mancht was es soll sucht man den Fehler bei der Prompt Eingabe, anstatt die KI zu hinterfragen… nen LMM reiht halt irgendwelche Scheiße statistsich aneinander und oftmal kommt was brauchbares dadurch raus… oftmals aber ebenso nur Scheiße!
Cloud die klaut und KI die lügt!
ChatGPT erfindet aber keine neuen Befehle, das kann ChatGPT nicht. ChatGPT greift nur auf bekannte Befehle zurück und kombiniert diese am Ende.
Das ChatGPT bei allgemeinen Antworten Belege und Quellen erfindet ist was ganz anderes.
Würden wir aufhören ChatGPT mit Daten zu füttern würde das System zum Stillstand kommen. Kommt morgen eine neue Powershell Version mit neuen Befehlen raus könnte ChatGPT damit nichts anfangen bis man es dem System beigebracht hat.
Ich selbst habe chatgpt auch schon dazu gebracht, Befehle rauszuhauen, die es nicht gibt. Zumindest in der angeforderten Sprache. Ist mir bei der Programmierung eines ESP32 mit der Arduino IDE so gegangen.
Das ist komplett falsch. LLMs schlagen dir erstmal plausible Kommandos vor, ob diese existieren, ist nicht automatisch klar.
Wenn copilot da oben "natürlich kann ich Dir … helfen" ist das bereits ungenau und heisst nicht viel mehr als dass es die generelle Frage zuordnen konnte.
leider geil! ;-P Aber genau das was es braucht damit vielleicht mal einige aufwachen!
Man muss das aber positiv sehen, von "skynet" geht keine Gefahr aus, das löscht sich selbst. ;-P
Zitat:" Deckt sich auch mit Berichten von Blog-Lesern, die im Februar 2028 immer mal wieder von sporadischen Problemen beim Mailversand über Exchange Online berichten."…
Da ist jemand seiner Zeit weit voraus…🧐🥹🤷♂️😉
Ich glaube, du kannst eine beliebige Jahreszahl einsetzen und die Aussage wird stimmen (vorausgesetzt, das MS in diesem Jahr existiert) ;-)
wohl von KI erstellt ;-P
Bei PowerShell kann man die letzten Befehle die in der Konsole ausgeführt wurden noch sehen. Wurde dies schon geprüft?
Die hat der MSler natürlich schon gelöscht.
Günter sagt ja sehr deutlich dass es sich um eine sehr plausibel klingende eNTe handelt.
NT = Not testated.
Mein Eindruck als selbständiger IT-Admin: Es fehlt nicht mehr viel, dann crasht MS365 mehr oder weniger komplett. Das Konstrukt zeigt für mich eine klare Tendenz zum GAU, gerät derzeit mehr und mehr außer Kontrolle, aber der Betrieb muss ja weitergehen. Von daher: ich boykottiere MS365 vollständig und biete es meinen Kunden auch nicht an. Wer es einsetzen möchte, soll es ohne mich tun – dann verliere ich notfalls lieber den Kunden. Denn meine Kunden erwarten von mir im Problemfall, dass ich aktiv eingreifen und das Problem durch eigene Aktionen beheben kann. Genau das geht bei MS365 nicht: man macht ein Ticket auf und wartet, hat keine Prognose ob und wann ein Problem behoben wird. Man kann nur hoffen.
Wohin das führen kann, sehen wir ja im obigen Beispiel über die Störungen seit 1. März.
Ob nun an der konkreten Geschichte was dran ist oder nicht, sei dahingestellt.
MS365 ist das inzwischen systemrelavanteste IT-System der Welt, das ich kenne, wenn ich mir überlege, wieviele Unternehmen und Konzerne weltweit davon asbolut abhängig sind – dementsprechend ist es für Schurken auch ein lohnendes Ziel, die die westliche Welt einfach nur brennen sehen wollen.
Aber warten wir einfach mal ab, was die Zukunft so bringen kann. Mein Popcorn steht bereit und ich warte in meiner Rolle als IT-Admin relativ entspannt auf den Tag X.
Als Bürger mache ich mir da schon eher sorgen, welche Auswirkungen das wohl haben mag.
Genauso sehe ich das auch und handle auch dementsprechend als Leidensgenosse.
sollen sie doch! Ich sage es immer wieder und gebe Support im Rahmen des Möglichen, aber ich werde mich nicht zum Richter aufschwingen. Ist mir doch egal was der Kunde macht, Hauptsache der Rubel rollt.
Ich würde es nicht machen, aber das muss jeder für sich entscheiden. Eine Teilschuld haben wir allerdings auch: Delivery ist oft zu langatmig/schwierig oder es fehlt an Teamkompetenz, auf geforderte Dienste oder Erneuerungen zu reagieren und somit wird die interne IT häufig und zurecht als Bremsklotz wahrgenommen. In der Cloud ist nun mal alles da und Up2Date, allerdings zu einem ordentlichen Preis.
Verlust der Souveränität.
Der Verlauf der Zwischenablage hätte ggf. einen nachträglichen Blick in dieses ominöse PS-Script gewährt. SCNR: Recall wäre hier auch eine gute Option gewesen :D
Laut diversen Rechercheergebnissen kann eine einfache PS-Befehlsabfolge in der Exchange Online Shell nicht tenantübergreifend erfolgen. Es sei den man baut drum herum eine Schleife zum Login in die einzelnen Tenant-IDs. Aber wie soll ich so Zugriff, in von mir nicht administrierten Tenants, erhalten? Mir fehlt hier die Vorstellungskraft.
Ich weiß einfach nicht, was ich grundsätzlich von dieser Story halten soll. Einerseits gab es ja nun wirklich schon den ein oder anderen Fauxpas seitens Microsofts, andererseits ist die Abgrenzung der einzelnen Tenants doch so etwas essentielles, dass man davon ausgehen muss, dass diese definitiv gegeben ist. Wenigstens aus Sicht eines einzelnen Administrator eines Tenants oder von mir aus auch eines IT-Dienstleisters, welcher mehrere Tenants verwaltet. Aus Sicht von Microsoft, da kann mal wohl trefflich drüber diskutieren.
Irgendwie hoffe ich ja, dass da etwas wahres dran ist und das der Stein hiermit ins Rollen gerät.
"Es kann nicht sein, was nicht sein darf" funktioniert nicht immer.
Es wird doch ständig irgendwo eine neue Lücke entdeckt.
kurz für deine Vorstellungskraft: Onpremise
dein AD ist seit 2008 multi tennant tauglich.
die Kunden (OUs) sind nur über Sicherheitsgruppen von einander getrennt, aber in derselben Domäne.
jetzt hast du durch klassische privilege escalation einem Zugriff auf alle tennants.
azure/entra ist bestimmt keine komplette Neuerfindung. die kämpfen in der Cloud mit denselben Problemen, nur mit dem Vorteil, das ein normal Sterblicher keinen Commandline Zugriff auf die Systeme bekommt, da er webfrontends bedient.
oh .. hoppla …powershell + CVE + Bug. zack kaputt
Danke für den Wink mit dem Zaunpfahl. Ich hab vergessen, dass der Unterbau tatsächlich keine Neuerfindung ist.
ist er nicht, sicher? Keine OUs u.a.
Ich stecke da nicht so tief drin, aber dass da grundsätzlich die etablierten Technologien drin stecken, vermute ich schon. Genauso wie Teams ja auch "nur" SharePoint und Exchange elegant verzahnt.
In der Datenbank liegen die Tenants möglicherweise sehr nahe beieinander.
Angenommen es gibt eine Tabelle mailboxes welche für alle Tenants für ein Server, ein Rechnenzentrum, ein Land oder noch mehr gilt. Wenn bei einem Delete-Befehl keine Einschränkung auf den Tenant gemacht wird, ist alles weg. Da greifen vermutlich keine Rechte mehr, die wurden ja auf der Shell-Ebene überprüft. Wenn in der API dann ein fehlerhafter Aufruf in Richtung Datenbank drin steckt ist es passiert. Wie der Fehler da rein kommen könnte ist dann noch eine andere Frage.
# ok, nur meiner gelöscht
delete from mailboxes where tenantid = 'mein tenant'
# pech, Nachbar auch weg
delete from mailboxes where tenantid >= 'x' and tenantid <= 'y'
# mist, alle weg.
delete from mailboxes where tenantid = '*'
(das ist sehr vereinfacht, zuerst müssen noch alle Datenbank-Inhalte zu den betroffenen Mailboxen gelöscht werden).
Die "Mieter" in der Cloud "wohnen" in einem sehr grossen "Wohnblock".
On premise ist das eher ein Ein- oder Mehrfamilienhaus. Lässt sich besser voneinander abgrenzen.
Warum beantwortet Microsoft die beiden Presseanfragen nicht?
zum Beispiel mit ".. das ist kompletter Unsinn.." oder ".. wir prüfen noch .."
naja da hat ChatGPT halt die Backdoor geöffnet… ;-P das es die gibt pfeifen die Spatzen seit Jahrzenten von den Dächern, Beweise konnte nur bisher keiner liefern.
Vielleicht hat das chatgpt Script ja einfach alle 32 stelligen tenant ids ausprobiert….
Ich würde ja jetzt auch sagen, dass das eine Räuberpistole ist, aber komischerweise hatte ich die vergangene Woche bei uns im Tenant beim Mailversand an Kollegen im Konzern als Autoresponse auch mehrfach so merkwürdige Rückmeldungen von EO nach der Art "Wir bereiten gerade das adressierte Postfach vor", "Postfach temporär nicht verfügbar" und ähnliches. Die kurioseste Variante war, dass ein Monitoring-System mir am Wochenende keine 7-Tage-Zusammenfassungen und Analysen senden konnte, mich aber Stunden später darüber per Mail an die selbe Adresse informierte, dass die Reports nicht zugestellt werden konnten, weil mein Konto nicht existiert(e). Zumindestens scheine ich aber sonst keine Mails verloren zu haben. Und Kollegen berichteten ähnliches und unsere Mailadmins hatten noch keinen Ansatz gefunden, es zu prüfen, weil alle gepüften Mailkonten (wieder?) da waren.
Das Ganze ist sehr merkwürdig und wenn da wirklich was dran ist, sollte die ganze M365-Strategie (aber auch Google Cloud usw.) nochmal überdacht werden.
Das Highlight des Artikels war aber, dass ein Admin Chat-GPT-Powershell-Befehle ungeprüft und unverstanden auf ein Produktivsystem loslässt. Will man so einen Dienstleister haben?
zu deinem 'Highlight': Was mir zugeflüstert wurde, war, dass der Mann seit einer Woche den Kunden im Nacken hatte, es Samstag Abend und jemand extrem müde war. Wer wirft nun den ersten Stein?
Selbst wenn er müde war. Er darf schlicht nicht an Rechte kommen, welche ein Löschen der Daten von Dritten ermöglichen. Sollte es wirklich so abgelaufen sein, so liegt der Ball klar im Feld von Microsoft.
Sorry das ist keine Entschuldigung! Sorgfallspflicht verletzt interessiert nicht unter welchen Umständen das passiert ist. Dazu gibt es Regeln!
Gerade sie müssten das verstehen hatten sie nicht starke gesundheitliche Probleme? Was hätten sie wohl gesagt wenn der behandelte Arzt da sagte sorry war ne harte Woche, Samstag Abend und ich bin total übermüdet?
Tut mir Leid Frau Born… aber Ihr Mann hatte da halt jetzt einfach Pech!
"Lieber Patient, ich bin jetzt müde und höre auf zu operieren, das gebietet meine Sorgfaltspflicht", sagte der einzige verfügbare Arzt zum Notfallpatienten auf dem OP-Tisch.
"Wenn du morgen noch lebst, mache ich weiter, nachdem ich ausgeschlafen habe."
Ich kann die Frage zum Arzt ziemlich gut beantworten. Vor der 3. Operation war ich nach der Patientenaufklärung so klein, das ich aufrecht unter einer geschlossenen Tür durch gepasst hätte. Von Querschnittslähmung über Schlaganfall bis Inkontinenz war auf 2 Seiten die Rede. Ich brauchte 2 Std. Autosuggestion, bis ich bei 'ich wage es' war. Dann kam der Stationsarzt und meinte 'ich war 2 Wochen in Urlaub, meine Finger sind ruhig, ich operiere Sie morgen früh als erstes. Wird gut gehen, sonst würde ich nicht operieren.' Die Freiheit ließ die oben im Text beschriebene Situation wohl nicht zu.
Würden Sie in ein Flugzeug steigen, wenn der Pilot total übermüdet ist?
Tipp: Sie haben keinerlei Info, ob Ihr Pilot oder Zugführer oder Bus- oder Taxifahrer oder Arzt oder Koch oder Sachbearbeiter oder sonst jemand in einem Sie berührenden Umfeld nicht total übermüdet seiner Tätigkeit nachgeht…
Dafür hat er doch den (MS)-Copilot. 😉
Auch wieder wahr! Schöne neue Welt…
*****************************************************
Das Highlight des Artikels war aber, dass ein Admin Chat-GPT-Powershell-Befehle ungeprüft und unverstanden auf ein Produktivsystem loslässt. Will man so einen Dienstleister haben?
******************************************************
Ist doch wie bei Versicherungen: Ob die was taugt weist du erst im Ernstfall!
Belügen … ähm Versprechen tun dir alle das Blaue vom Himmel.
Ich seh da so: wenn du nen Dienstleister brauchst läuft breits grundsätzlich was schief! Ich gebe garantiert nix kritisches aus den Händen.
Sie nutzen also ausschliesslich Systeme die nach persönlichem komplettem Source-Review von Hardware-Design und jeglicher Software und Firmware extra für Sie kompiliert wird? Und bei jedem Update erneut? Respekt.
Am Ende hilft es nicht, hier allein den Admin zu verteufeln, fast jeder macht irgendwann und insbesondere unter Druck Fehler oder wird fahrlässig. Aber Fehler sollten nicht das Gesamtsystem in den Abgrund reißen.
Und an die MS365- und Windowshasser, ich (nutze auch Linux) würde nicht viel Geld darauf verwetten, das die Alternativen viel sicherer sind. Nach 20 Jahren schnellschnell und das Geschäft wartet nicht gibt es inzwischen wohl kaum mehr zuverlässige Software im Einsatz…
Was für ein komischer Kommentar.
Der Admin ist nicht zu verteufeln – wenn der MS Drecksmüll wieder mal völlig versagt, ist einzig und allein MS daran Schuld. Und das hat nichts mit deiner restlichen Schwurbelei bezüglich Linux oder sowas was zu tun.
Naja, hier hat ausser einer schlechten Geschichte gar nichts versagt.
Rein schon die Sache mit Microsoft hätte angerufen.. wen denn? woher die Nummer? Am Abend an der Telefonanlage vorbei? Woher wusste der ITler dass es MS ist?
Selbst wenn MS die Nummer hätte, warum anrufen? Wozu? Der Schaden wäre schon passiert, warum nicht die Session blockieren wie es millionenfach pro Tag passiert, wenn sich z.b. jemand mit falschen Kennwort anmeldet.
Was soll es bringen dass jemand am Telefon abhebt?
dann ChatGPT.. warum sollte Microsoft hier irgendeinen Verlauf löschen? Was bringt das? Wo löschen? Bei OpenAI? Wie sollte da der Microsoft Mitarbeiter Zugriff haben, und woher überhaupt davon wissen? Was ist dann mit dem Verlauf im Browser?
Dann müsste der ITler ja den MS Mitarbeiter, der ihn also so unerwartet in der Nacht anrief, auch via Fernwartung/TeamViewer/Anydesk.. auf den eigneen PC gelassen haben, _während_ er noch die Admin Session zum Kunden offen hat.. ?
Wir alle kennen die "Warnungen vor dem Microsoft Support der anruft.." und ein ITler lässt so jemanden auf dein PC?
Und für alle den Schwachsinn, braucht es noch nichtmal eine angebliche Omni-Sicherheitslücke.
Der US Staat braucht übrigens keine Backdoor, der hat per Gesetzt Zugriff bei Bedarf.. übrigens selbst der Deutsche Staat.
Und weil hier offenbar viele Leute keine Ahnung haben wie O365 funktioniert.. es reicht für den ITler die Aufbewahrungs-Richtlinie für die Junk-Mails zu ändern, und schon kann der Ordner nie mehr überlaufen.
Und .. diese Info, bekommt man auch wenn man keine Ahnung hat nach 5 Sekunden googlen.
ok, ich präzisiere meinen Kommentar: falls diese Gesichte stimmt, ist MS zu verteufeln, nicht der Admin.
Zufrieden, Herr Erbsenzähler?
Der Admin hätte wenn die Geschichte stimmt, einfach alles falsch gemacht.
Es beginnt, bei dem Ur-Problem. Er hätte einfach die Mails in ein anderes Postfach leiten können.
Von rumprobieren für ihn unbekannter Kommandos am Live-System..
Und dann mit einer wilden Geschichte die Schuld zu Microsoft schieben.. und leider, weil ja Geheim, gibt es keine Spuren.
Völliger Quatsch, wenn es möglich ist, übergreifend an anderen Tenants etwas zu ändern, hat MS versagt und niemand Anderes. Wie man das macht bzw machen kann und wie man dahin kommt, ist egal. Es darf nicht möglich sein, Punkt, Ende, aus
Also Totalversagen von MS, nicht des Admins (extra nochmal zur Sicherheit: falls es sich wirklich so zugetragen hat).
https://youtu.be/Vywf48Dhyns?feature=shared
Lenk nicht ab…
Hallo, über den Wahrheitsgehalt erlaube ich mir kein Urteil. Aber ohne irgendeine Art von Nachweis…
ganz klar ist: wenn man das Powershell Script oder Code nicht verstehe, nutze es nicht. VG Michael
"Nachdem der Kunde bereits 4 bis 5 Tage keine Mails mehr empfangen konnte, der Microsoft Support auch seit einer Woche nicht in der Lage war, zu helfen, war guter Rat teuer."
Also seltsam.
früher(tm) hatten wir für kritische Infrastruktur immer irgendwelche Fallbacks, z.B. wurden Kunden auf eine Handy Nummer verwiesen, wenn die Telefon Anlage ausgefallen war.
Entsprechend konnte der MX schnell auf den Host bei einem anderen Provider gedreht werden.
Der konnte zwar nur die E-Mails sammeln und die Kunden per E-Mail auf das Problem und für dringende die Handy/Fax Nummer hinweisen, aber immerhin waren die Kunden informiert und könnten im Notfall das Handy/Fax bnehmen. Diese Aktionen liefen bereits nach 24h Ausfall an, weil das die Zeit war, die man glaubte ohne auszukommen. War zu lang.
E-Mail war für dieses betroffene Unternehmen wohl nicht so wichtig, wenn die bereits 5 Tage ohne ausgenommen waren.
Einfach unglaublich oder eine Ansammlung von Dilletanten.
Das ziehen natürlich auch Zweifel auf, ob das mit dem weltweiten Löschen stimmt.
Seher ich aus folgenden Gründen als echt unglaubwürdig an:
• CVE-2024-49035: Diese Schwachstelle betrifft nach meinem Kenntnisstand das Partner Admin Center. Sie wurde bereits im November 2024 bekannt und behoben. Ein Zusammenhang mit den aktuellen Problemen erscheint daher unwahrscheinlich.
• ChatGPT und Microsoft: Es wird erwähnt, dass "Microsofts KI-Lösung ChatGPT" involviert sei. Hierbei ist zu beachten, dass ChatGPT nicht von Microsoft entwickelt wurde.
Aus meiner dreijährigen Erfahrung als Subject Matter Expert im M365 Support Premier bei Microsoft weiß ich, dass die Systeme des Partner Centers von denen der Kunden (bzw. Kundengruppen, kommerziell/business) getrennt sind. Es ist unklar, wie eine Schwachstelle im Partner Center auf Kundensysteme übergreifen könnte.
Ein von ChatGPT generierter Befehl kann, abhängig von der Qualität der KI, durchaus Schäden verursachen. Allerdings halte ich es für ausgeschlossen, dass ein solcher Befehl serverübergreifend Systeme lahmlegt.
Microsoft hostet die Exchange Online-Struktur in verschiedenen Clustern, die je nach Region, Land, Tenant-Art und internen Kriterien unterschiedlich benannt sind. Diese Cluster sind weiter in Mailbox-Datenbanken unterteilt, in denen mehrere Exchange-Server als Knoten fungieren und die Postfächer bereitstellen.
Selbst wenn der Support einen Befehl ausgeführt hätte – auch unter Nutzung von KI – erfordern die eingesetzten Tools wie das damalige "ViewPoint" oder das aktuelle Ticketsystem "RAVE" sowie Diagnose-Tools wie DFM, Assist365 oder ACS eine Prüfung. Diese Tools bieten keine Möglichkeiten, tenant- oder zonenübergreifend Änderungen vorzunehmen. Daher erscheint es unwahrscheinlich, dass solche Tools großflächige Störungen verursachen könnten.
Ein PIR wird nicht immer erstellt. Dies hängt von der Größe des Vorfalls, den Vertrauensstufen usw. ab. Zudem wird er nur dann erstellt, wenn der Vorfall ausreichend analysiert und die Ursache identifiziert wurde.
Intern gibt es das ICM-Portal (Incident Communication Management) bzw. früher das "Lynx"-Portal, in dem für jeden Vorfall eine Kurzbeschreibung veröffentlicht wird, um den Status zu prüfen. Ggf. kann der mysteriöse Ersteller des Tickets dort mal anfragen ob ein genauerer Status zur Verfügung steht.
Und last but not least – seitwann meldet sich der Microsoft Support (sprich de facto entweder 1st Level Broadband Support / oder maximal noch ein SME Exchange Online) um Kunden die Staatsanwaltschaft anzudrohen? Das erledigt wenn dann Legal, die nachts nicht arbeiten (DE Legal, nicht US Legal).
Oh, und Einblick in einen Ausfall mehrerer Tenants / Clusters hat der 2nd Level Support auch nur maximal im ICM – dort steht aber nicht "Schuld war Kunde xyz".
Danke für die Insights! Spannend wäre jetzt zu erfahren, was wirklich momentan in Exchange Online passiert. Hab inzwischen weiteres Feedback von anderen Quellen zum Artikel bekommen. Es passiert was Tenant-übergreifendes auf globaler Ebene, wo Postfächer weg sind. Werde den Artikel Montag ergänzen.
Das Thema passt mit diesem zusammen:
https://www.borncity.com/blog/2023/03/30/bigbang-microsoft-azure-schwachstelle-ermglicht-bing-search-hijacking-und-office-365-datenklau/
Damals gab es aber (leider) keine so lebhaft Diskussion in den Kommentaren.
Die Frage "crasht Schwachstelle Exchange Online weltweit?" wurde im Artikel thematisiert.
Das Produkt "Microsoft 365 Multi-Geo" könnte ein Layer in der Microsoft Cloud Architektur sein, welches solche Szenarien zumindest für CSP-Partner und grosse Enterprise Agreement Kunden in den Fokus möglicher Szenarien rückt.
Passiert in einer dieser zentralen Verwaltungsdatenbanken eine Tenant-übergreifender Fehler, könnten die Replizierungsmechanismen dabei helfen
das weltweit was passiert.
Ich denke aber, man darf "weltweit" nicht so interpretieren, dass durch das Problem sämtliche Kunden betroffen sein könnten. Robin Dieker hat ja die Cloud-Architektur in seinem Kommentar skizziert (vielen Dank!).
Bin gespannt wie sich die Geschichte morgen weiterentwickelt.
https://learn.microsoft.com/de-de/microsoft-365/enterprise/microsoft-365-multi-geo?view=o365-worldwide
In der Samsung-App schein der Fehler darin zu liegen, dass eine bestehende Session – wie auch immer – beendet wird, dann die Re-Authentifizierung im ersten Anlauf scheitert, in der App die Meldung "Anmeldung fehlgeschlagen" und damit das Anmeldefenster erscheint, danach die Authentifizierung aber ohne erneute Passworteingabe funktioniert. Das passiert in unterschiedlichen Intervallen mehrmals pro Tag.
Ich kenne aus Anfang März auch das Problem, dass Outlook spontan in einem Fall keine E-Mails mehr versenden konnte. Lösen konnte ich das zumindest in diesem Fall durch die vollständige Onlinereparatur von Office – normale Schnell-Reparatur funktionierte nicht – ohne Kontolöschung im Client o.Ä.
Auf dem PC/Server, von dem aus der Admin die PS Befehle abgesetzt hat, bitte nachsehen unter:
C:\Users\\AppData\Roaming\Microsoft\Windows\PowerShell\PSReadline
Die dortige Textdatei speichert alle PS-Befehle dauerhaft ab, wenn man die Datei nicht löscht. Hat der "MS Support" ja nicht gemacht laut der Erzählung.
Da wird man also noch was finden, gerne hier posten, damit man sich fachlich einen Eindruck verschaffen kann, was im Einzelnen getan wurde!
Ansonsten ist an der Erzählung eine Menge sehr fragwürdig, zumindest auf Basis meiner persönlichen Erfahrungen – sowohl mit Powershell und Exchange (Online) Administration, als auch im Kontakt mit Strafverfolgungsbehörden (was heutzutage in einem Admin Leben durchaus auch vorkommt).
Aber das muss natürlich nicht zwangsläufig der Maßstab für die Realität sein, also lese ich gespannt mit, was sich da noch so ergibt.
Alles in allem rate ich grundsätzlich dazu, jede Info auch mal daraufhin zu prüfen, ob sie nicht einfach stark den persönlichen Erwartungen entspricht (Stichwort "Confirmation Bias"). Zumindest kann man auch ein wenig Raum für den kleinen Gedanken lassen, dass diese Geschichte vielleicht deshalb so schlüssig klingt, weil man so etwas vom "Sauhaufen Microsoft" durchaus erwartet.
Was ich aus der Sache an dieser Stelle inhaltlich aber herausnehme ist, dass ein ohnehin schon gestresster Admin etwas gemacht hat und just in dem Moment kommt ein (eventueller) Scam Anruf vom angeblichen MS Support und der wurde sogar auf den lokalen Rechner gelassen. Letzteres ganz sicher nicht!
Danke für den Tipp/Pfad!
Im Pfad fehlt der Username, gerade in Kommentaren/Foren ist es einfacher,
%APPDATA% statt C:\Users\username\AppData\Roaming zu benutzen, der Pfad wäre dann %APPDATA%\Microsoft\Windows\PowerShell\PSReadline.
Unten die Ergänzung zu Samsung ist interessant. Mein Thunderbird meldet mir gelegentlich auch Fehler beim Mailabruf des privaten Outlook-Kontos. Ist nicht so wichtig, da kommen eh nur Mails von Microsoft rein, aber neugierigerweise starte ich dann ab und zu mal outlook-new und da klappt dann der Zugriff immer. Also entweder ein gelegentlich auftretendes Kompatibilitätsproblem zwischen dem Nicht-Microsoft-Mailclient und dem MS-Konto, oder zufällige andere Sache, Überlastung des Mailservers, oder sowas.
Den unteren Absatz mit der Merkel kann man sich aber sparen.
Mir ist gerade eingefallen, wie Microsoft an die Nummer des Admins kommen kann: Sie müssen in vielen Fällen vermutlich nur ins Entra ID schauen, da finden Sie die Handynummern von vielen Nutzern für die MFA. Microsoft verlangt die ja in vielen Fällen als Backup für Authenticator-App etc.
Aber die Geschichte wirkt wirklich arg verrückt, aber nicht grundsätzlich unmöglich…
Im Adminportal kam auch der tefonische Kontakt zum Partnersupport hinterlegt werden.
Haben diesen Fall natürlich auch bei uns beobachtet, allerdings erst bei zwei Kunden. Auch nach einer ganz schönen Support-Hotline-Tortur sind wir bei ESET gelandet. Das Outlook AddIn vom ESET Endpoint Security hat ebenfalls einen Fehler verursacht, dass der Junk Mail Ordner geflutet wird. Gab nur keinerlei Empfangsprotokolle im EXO Portal.
Also wer auch ESET einsetzt kann mal versuchen das ESET Outlook Add In zu deaktivieren und schauen obs besser wird.
Stand gestern hat ESET uns gesagt, dass noch nicht absehbar ist, wann ein Update veröffentlicht wird