Hallo Leser,
viele von euch wissen das ich mich auch sehr Stark mit Entra ID und den M365 Lösungen beschäftige. Ich habe hier im Blog relativ wenig darüber berichtet bisher. Heute möchte ich euch mal eine Story mit auf den Weg geben, die durch eine Kundenanfrage entstanden ist.
Zudem ziehe ich mal ein Resümee was wir daraus lernen können und welche Option ihr in euren Tenants setzen solltet damit euch dies nicht passiert.
Die Vorgeschichte
In der vergangenen Woche kam ein Kunde von uns (ein Systemhaus) auf uns zu das einer seiner neuen Kunden keine Mails mehr versenden kann. Der Endkunde hostet seine Postfächer in Exchange Online und ist ein CloudOnly Kunde. Es gibt kein CloudConnect oder Entra ID Connect für die Synchronisation zwischen OnPrem und Entra ID.
Unser Verdacht viel zunächst blindlinks auf eine sich in der Quarantäne befindliche Identität.
Ich habe mich auf den Tenant aufgeschaltet und mir als erstes einige Grundeinstellungen angesehen.
Es sind tatsächlich keine Mails mehr versandt worden. Die Identität war nicht gesperrt bzw. in der Quarantäne. Microsoft hat den Tenant gesperrt.
Erste Analyse
Ich habe mir zunächst diefolgenden Entra ID Settings angesehen:
- Sicherheitsstandards –> diese waren ausgeschaltet !!!
- Lizenzpaket –> Exchange Online Plan 1
- Conditional Access Policys –> keine vorhanden
- Benutzerlogins –> sehr auffällige Anmeldungen
- Mehr als 20.000 neu angelegte E-Mail aktivierte Benutzer
Daraufhin habe ich mir den Mailfluss angesehen und festegstellt dass:
- entliche Transportregeln vorhanden waren
- neue Domains registriert wurden
- etliche Connectoren angelegt wurden
- Nachrichtenheader entfernet wurden
Nachfolgend einige Bilder wie sich dies dargestellt hat.
Exchange, Hybrid, Cloud & Entra ID sind für dich ein rotes Tuch oder du benötigst einen Partner der dich souverän in einem Kundenprojekt unterstützt?
Buche einen unverbindlichen Beratungstermin HIER
Melde dich bei uns, unter https://cloudcoop.de findest du alle Informationen!
Selbstverständlich kannst du uns auch gerne eine E-Mail an support@cloudcoop.de schreiben.
Aktivitäten
Nachdem ich nun den Tatsachen ins Auge blicken durfte und der Endkunde informiert wurde ist folgendes passiert.
- Alle nicht autorisierten Domänen entfernt
- Domänen die bisher nicht entfernt werden konnten das senden verboten
- Alle unautorisierte Benutzerobjekte gelöscht
- Transportregeln entfernt
- Connectoren entfernt
- Sicherheitsstandards aktiviert und somit MFA für alle aktiviert
- Kennwörter geändert
- Neuen globalen Admin angelegt
- Vorhandenen Administrative Benutzerkonten den privilegierten Status entfernt
- Outlook Regeln geprüft
Daraufhin war die Hoffnung das der Endkunde wieder arbeitsfähig ist – dem ist bisher noch nicht so. Parallel hat mein Mitarbeiter bereits ein Microsoft Support Case eröffnet – seht selbst:
Aktueller Stand 18.06.2024 11:00 Uhr
Die Unterstützung von Microsoft hält sich bisher im Rahmen und der Endkunde kann weiterhin keine Mails versenden.
Ein Blick in die Nachrichtenereignisse und es fällt auf, etwas stimmt noch nicht;)
Alle E-Mails welche eingehen werden weitergeleitet, aufgrund einer Journal-Regel:
Die Regel habe ich sofort deaktiviert, mal davon abgesehen das derzeit so oder so keine Mails nach extern versendet werden können.
Parallel dazu haben wir die Anmeldungen nochmal geprüft, diese haben sich ebenfalls wieder „beruhigt“.
Vorgeschlagene Präventive Maßnahmen
Wie eingangs erwähnt unterstützen wir bei der Wiederherstellung des Normalbetriebs und geben unserem Kunden Empfehlungen mit was zu tun wäre. Ich gebe hier zunächst nur Stichpunktartige Empfehlungen. Es wird einen Beitrag geben in dem ich die vollständige Tenant Security aufarbeite und euch Empfehlungen mit auf den Weg gebe.
Lizenz
Wir empfehlen die Verwendung von mindestens Entra ID Plan 1! Dem Endkunden sollte hier ein Lizenzpaket angeboten werden, wie Business Premium, welches die Entra ID Plan 1 Lizenz beinhaltet. Weiterhin ist in der BusinessPremium auch die Option für SafeLinks & SafeAttchements enthalten um die Angriffsfläche via E-Mail zu verringern.
App Registration
In jedem Tenant kann im Standard jeder User eine App Registrieren, durch klick auf einen Link kann somit bspw. eine App FullAccess auf die eigene Mailbox erhalten. Dies sollte unterbunden werden und ausschließlich mit Genehmigung durch den Administrator erfolgen.
Tenant-Settings
Die Einstellungen des Tenants im Microsoft Admin Center sollten geprüft werden. Hier sind etliche Konfigurationseinstellungen zu setzen um die Sicherheit zu erhöhen. Dazu zählen:
- Einstellungen und Dienste
- Organisationseinstellungen
- Sicherheit und Datenschutz
Authentication Policys
Microsoft wird Am 30. September 2025 die Legacyrichtlinien für mehrstufige Authentifizierung und Self-Service-Kennwortzurücksetzung einstellen. Ab dem Moment greifen nur noch die neuen Policys. Migrieren der Richtlinie für Authentifizierungsmethoden – Microsoft Entra ID | Microsoft Learn
Conditional Access
Implementieren eines Conditional Access Models bei dem mittels Regelwerk etliche Zugriffe anhand folgender Signale der Zugriff gestattet oder blockiert wird:
- Benutzer und Gruppen
- IP & Standort
- Gerät
- Applikation
- Real-Time Risk detection
- und ggf. Defender for Cloud Apps
Die Implementierung von Standorten ist ebenfalls ein wichtiger Baustein!
Ich habe euch mal ein Bild der Conditional Access Policys aus meinem Tenant aufgezeichnet. Näheres dazu später in dem bereits angekündigtem Beitrag.
Sonstiges
Weiterhin sollten auch die Einstellungen für Benutzer, Gruppen & Apps im Tenant geprüft werden. Schaut euch zudem noch folgende Einstellungen an:
- Devices –> Microsoft Entra join and registration settings
- Users –> User Settings
Achtet auch auf die Einstellungen in Teams, Sharepoint, Forms usw.
Ich zeige hier nochmal einige Konfigurationsbeispiele die meiner Meinung nach sehr wichtig sind:
Fazit
Es ist gar nicht so einfach den Überblick zu behalten. Cloud, OnPremise, Hybrid. SaaS, IaaS, PaaS … Begrifflichkeiten mit denen wir um uns werfen aber unter umständen kaum verstehen!
Wenn wir eine hochkomplexe Lösung von Microsoft wie Exchange Online beziehen, dann müssen wir auch verstehen wie diese funktioniert und uns als ITler diese sehr genau ansehen.
Es reicht eben nicht aus mal eben die Mailbox von A nach B zu verschieben, den MX-Record zu konfigurieren und noch zwei weitere DNS-Einträge zu setzen.
Im Schritt-für-Schritt-Onboarding Video für Administratoren aus meinem vergangenem Workshop habe ich dies auch erzählt. (Webinar „Microsoft 365 – Checkliste für ein erfolgreiches Onboarding“ – Andi’s iT Blog (asichel.de)) –> Ich habe mir schon immer mal vorgenommen das für Youtube aufzubereiten, mal sehen ;)
Hier hat man auch gut gesehen was ein Angreifer mit der PowerShell alles tun kann. Per Journal alle Mails nach extern leiten ist an sich eine gute idee um die Mails auch nach dem Angriff noch zu analysieren. Zumal diese Option nicht mehr so einfach ersichtlich ist, da die Funktion in das Microsoft Purview Portal migriert wurde: Exchange (Legacy) – Microsoft Purview .
Weiterhin müssen wir auch ein Sicherheitsbewusstsein für unsere Kunden schaffen denen wir M365 Dienste anbieten. Das können auch unsere internen Kollegen sein, wenn du in der internen IT arbeitest.
Wenn ihr M365 für neue Kunden zum ersten mal bereitstellt, schaut euch den Ablauf genau an und achtet auf den ersten Schriit:
Das erste und wichtigste ist und bleibt die Identität, wie ihr oben gesehen habt! Sichert diese und schützt euren Tenant mit den o.g. Maßnahmen.
Gruß aus Ostwestfalen
Andi
Update 18.06.2024 17:16 Uhr
Der Endkunde kann weiterhin keine Mails versenden obwohl alle User MFA nutzen und die Anforderungen umgesetzt wurden.
Das Ticket wird im 2. Level weiter bearbeitet, mal abwarten.
Update 19.06.2024 13:42 Uhr
Microsoft hat den Tenant noch immer nicht freigegeben. Die letzte Mail seht ihr hier:
Ich halte euch weiter auf dem laufendem.
Update 20.06.2024 11:17
Microsoft möchte gerne weitere Informationen von uns und versorgt uns mit neuen Aufgaben. Der Tenant ist noch immer nicht freigegeben und wir versorgen Microsoft nun erstmals mit den Informationen.
Update 21.06.2024 15:10 Uhr
Es ist geschafft. Nachdem wir Microsoft die benötigten Informationen geliefert haben und der Support-Desk diese nun verarbeitet hat, können wir nun wieder Nachrichten schicken, lest selbst:
@alex: Du kannst keine „Firewall“ vor die Cloud stellen und es bringt auch nichts, wenn der Zugriff über erwünschte Protokolle geht. Die „Lücke“ war hier, dass es mindestens einen Admin gab, dessen Kennwort schlecht und nicht per MFA gesichert war ODER jemand einen Admin überlistet hat. Wenn der Angriff noch nicht lange her war, kann man über das Auditlog schauen, wann und vom wem die Domain registriert wurden und dann über die Logins schauen, woher (Was aber nicht viel bringt)
Der Kunde kann froh sein, dass der Angreifer nicht sich als einzigen GlobalAdmin addiert und alle anderen ausgesperrt hat.
Der Kunde kann froh sein, der Angreifer den Tenant vielleicht nur als „Spamschleuder“ verwendet hat und nicht die Mailboxinhalte abgegriffen/gelöscht hat.
Die Transport/Journal-Regeln sind aber ein Hinweis, dass Phishing und Account Reset Aktionen bei anderen Diensten noch geplant waren oder vielleicht schon erfolgreich waren. @ Andy: Sage dem Kunden, dass die Mitarbeiter auch alle Konten bei ebay, Twitter, Facebook etc, die mit dem Firmenkonto verbunden sind, ändern sollen, da der Angreifer ein PasswordReset machen und die Konten auch übernehmen konnte.
Die Frage ist nur: Wer hat „Security Defaults“ abgeschaltet, denn damit sind alle Admins immer mit MFA abgesichert. (auch ohne Entra P1).
Hey Frank,
korrekt, die Info ist dem Endkunde bereits mit auf den Weg gegeben worden. Danke aber nochmal für den Hinweis!
Ja wer macht das? Wir wissen es nicht, mein Kunde hat den Endkunde auch gerade erst übernommen und ist, wie beschreiben dann an uns herangetreten.
Die Audit-Logs helfen uns ja nicht, wir haben halt die Logins und Aktivitäten Nachvollziehen können. Nur wenn darin steht das aus Indien ein Login Stattgefunden hat und die Doamin hinterlegt wurde, bringt das am Ende auch keinen Mehrwert.
Stimmt, dafür braucht es kein P1, es ist aber immer besser eins zu haben :)
Es ist schon krass, wie blauäugig manche Unternehmen mit ihren Daten umgehen. Früher hat man sich ja auch hinter diversen Firewalls versteckt. Warum man bei Cloudanbietern dann auf jegliche Form der Absicherung verzichtet ist mir da schon ein Rätsel.
Da wundert es einen immer wieder, warum so wenig Unternehmen gehackt werden. Ist bei vielen wahrscheinlich eher Glück bzw. haben viele den Vorteil, dass sie aufgrund ihrer überschauberen Größe zu uninteressant für viele Hacker sind.
Hi Alex,
korrekt, Früher hat man OnPrem Sicherheitsmaßnahmen ergriffen. Heutzutage sprechen wir von ZeroTrust und sichern so Zugriffe auf Weltweit verfügbare Endpunkte durch entsprechende moderne Techniken ab. Das ist in diesem Fall hier nicht passiert. Anders gesagt brauchen wir jedoch keine Zentrale Unternehmensfirewall mehr, da Dienste nicht mehr OnPrem gehostet werden (je nach Szenario). Was bringt dir eine Firewall wenn alle deine Mitarbeiter Weltweit an unterschiedlichsten Standorten sitzen und Services von Microsoft, Amazon, Google usw. beziehen und es keine Serversysteme mehr in einem klassischem Office gibt? Wie gesagt. je nach Kunde und Szenario ;)