Microsoft 365 Archives - IT-Consulting Blog

Versteckte bösartige OAuth-Apps in Microsoft 365 entdecken – mit dem Tool Cazadora

Die Nutzung von Cloud- und Identitätsdiensten wie Microsoft 365 nimmt ständig zu – damit steigt auch das Risiko neuer Angriffswege. Ein besonders heimtückischer Ansatz: Angreifer nutzen OAuth-Apps, die in Azure/Entra ID registriert wurden, um Zugriffe auf Daten zu erlangen – oft ohne dass es die Administratoren oder Nutzer merken. In einem aktuellen Blogbeitrag erklärt Huntress Labs, wie solche Apps funktionieren, wie häufig sie auftreten – und stellt mit Cazadora ein Open-Source-Skript vor, mit dem sich verdächtige Anwendungen aufspüren lassen. BleepingComputer
Als IT-Consultant lohnt es sich, dieses Thema im Blick zu behalten, denn selbst gut verwaltete Microsoft-365-Tenants sind nicht immun.

Was sind OAuth Apps in Azure/Entra ID – und warum sind sie relevant?

In der Welt von Azure AD / Entra ID und Microsoft 365 gibt es zwei zentrale Kategorien von Apps:

Application Registrations: Anwendungen, die innerhalb des eigenen Tenants entwickelt oder registriert wurden. BleepingComputer+1
Enterprise Applications: Instanzen von Anwendungen, die von anderen Tenants registriert wurden, aber in Ihrer Tenant-Umgebung verwendet werden. BleepingComputer

Der typische Ablauf sieht so aus: Ein Benutzer oder Administrator erlaubt einer App, sich mit ihrem Konto (Authentifizierung) zu verbinden und über OAuth entsprechende Rechte (Autorisierung) zu erteilen. Sobald das geschehen ist, wird in Ihrem Tenant ein Service-Principal für diese App angelegt, über den die App im Namen der Nutzer agieren kann. BleepingComputer

Warum ergeben sich daraus Risiken?

Die Funktionalität ist legitim und zentraler Bestandteil moderner Cloudanwendungen – das macht sie attraktiv für Angreifer, da sie wenig auffällig ist. BleepingComputer+1
Manche Einstellungen erlauben es, dass jeder Nutzer ohne Überprüfung Apps registrieren bzw. ihnen Rechte geben kann – je nach Tenant-Konfiguration. BleepingComputer
Eine bösartige oder kompromittierte App kann somit Zugriff auf sensible Daten erlangen, ohne dass klassische Malware- oder Endpoint-Kontrollen sie zwingend aufdecken.

Angriffstypen: „Traitorware“ und „Stealthware“

Huntress unterscheidet zwei relevante Kategorien von missbräuchlichen OAuth-Apps:

Traitorware

Hierbei handelt es sich um eigentlich legitime Apps oder weit verbreitete Tools, die allerdings von Angreifern für bösartige Zwecke genutzt werden. Die App selbst ist nicht zwangsläufig bösartig designt, aber ihre Nutzung erscheint ungewöhnlich und riskant.

Huntress fand z. B., dass ca. 10 % der ausgewerteten Tenants mindestens eine solche App installiert hatten. BleepingComputer
Merkmale: bekannte App-Namen, aber oft ungewöhnliche Berechtigungen oder eine ungewöhnliche Nutzerzuordnung.

Stealthware

Diese Kategorie umfasst echt bösartige oder speziell für Angriffe erstellte OAuth-Apps – klein, maßgeschneidert, selten und damit schwer zu entdecken.

Sie haben oft sehr geringe Verbreitung (z. B. < 1 % aller Tenants) und hohe Delegated-Berechtigungen auf einzelne Nutzer. BleepingComputer
Da die Namen willkürlich oder unerkennbar sind („…………“, „Test App“, Domain-Name etc.), entziehen sie sich oft automatisierten Erkennungsmechanismen.

Warum sollte man auditieren?

Die Daten zeigen: Selbst bei Organisationen mit etabliertem Sicherheitsrahmen tauchen solche Apps auf – teilweise seit Jahren unentdeckt. BleepingComputer
Ein (zu) beruhigender Befund: Wenn eine App nicht automatisch gefunden wird, heißt das noch nicht, dass keine bösartige App vorhanden ist. Vigilanz bleibt erforderlich.

Vorstellung von Cazadora

Um Administratoren und Sicherheitsverantwortlichen zu helfen, hat Huntress das Werkzeug Cazadora veröffentlicht. BleepingComputer

Was macht Cazadora?

Es handelt sich um ein Open-Source-Skript, das über die Microsoft Graph API Daten über alle Application Registrations und Enterprise Applications im Tenant abruft. BleepingComputer
Es führt eine automatisierte Analyse durch und markiert Applikationen mit auffälligen Merkmalen (z. B. ungewöhnlicher Name, seltene Verbreitung, starke Berechtigungen, Loopback-Reply-URL etc.). BleepingComputer
Ziel ist nicht, alle bösen Apps sicher aufzuspüren, sondern einen schnellen Überblick zu geben und potenzielle „Rauchzeichen“ sichtbar zu machen.

Wichtige Hinweise

Kein Tool ersetzt eine vollständige manuelle Prüfung oder eine laufende Sicherheitsüberwachung – Cazadora ist ein Sprungbrett, keine Garantie. BleepingComputer
Ergebnisse sollten von einem Administrator oder Sicherheitsanalysten bewertet werden.
Anpassungen im Tenant (z. B. Benutzerrechte bei App-Registrierung) können helfen, den Angriffsraum zu reduzieren.

Achtung: Neue Phishing-Welle nutzt Azure Blob Storage – so schützen Sie Ihr Microsoft 365 mit Passwordless Authentication

Cyberkriminelle sind heute kreativer denn je – und sie nutzen sogar Microsoft-Dienste selbst, um Nutzer zu täuschen.
Ein aktueller Fall zeigt, wie Angreifer über Azure Blob Storage glaubwürdige Microsoft-Login-Seiten fälschen, um Zugangsdaten zu stehlen.

Doch wer Passwordless Authentication einsetzt, schließt genau diese Lücke – und eliminiert Passwörter als Einfallstor.

Phishing über Azure Blob Storage – so funktioniert der Angriff

Die aktuelle Angriffswelle nutzt legitime Microsoft-Domains wie *.blob.core.windows.net.
Betroffene erhalten Links, die auf den ersten Blick harmlos wirken, z. B.:

forms.office.com/<zufälliger-wert>

Nach dem Klick wird man auf eine Seite weitergeleitet, die wie eine echte Microsoft-Login-Seite aussieht – aber in Wahrheit gefälscht ist.
Die Domain endet oft auf:

https://<zufälliger-name>.blob.core.windows.net/<datei>.pdf

Sobald man sich dort mit seinem Microsoft-365-Konto anmeldet, werden Passwort und Authentifizierungstoken abgefangen.
Damit erhalten Angreifer Zugriff auf den gesamten Microsoft-365-Mandanten des Unternehmens.

Besonders perfide:
Da die Domain windows.net zu Microsoft gehört, halten viele Benutzer sie für sicher.

Warum herkömmliche Schutzmaßnahmen nicht ausreichen

Auch wenn Unternehmen heute Firewalls, MFA, Webfilter und Awareness-Trainings einsetzen – Phishing bleibt ein Problem.
Denn Angreifer täuschen vertraute Umgebungen perfekt nach.

Selbst Multi-Faktor-Authentifizierung (MFA) hilft nur bedingt:
Bei Token-Phishing oder Session Hijacking kann sie umgangen werden.

Das Kernproblem bleibt: Passwörter sind phishbar.

Passwordless Authentication – Sicherheit durch den Wegfall des Passworts

Mit Passwordless Authentication löst Microsoft das Problem elegant:
Anstelle eines Passworts nutzt der Benutzer starke kryptografische Schlüssel, die an sein Gerät oder seinen Authenticator gebunden sind.

Beispiele für Passwordless-Login-Methoden

Windows Hello for Business – Anmeldung per PIN oder Gesichtserkennung
Microsoft Authenticator – Anmeldung durch Push-Bestätigung
FIDO2-Sicherheits-Keys – z. B. YubiKey oder Feitian-Key

Damit entfällt die Notwendigkeit, ein Passwort einzugeben – und somit das Risiko, dass es abgefangen wird.

So funktioniert Passwordless technisch

Passwordless basiert auf einem sicheren Public/Private-Key-Verfahren:

Der Private Key bleibt sicher auf dem Gerät oder Token des Benutzers.
Der Public Key wird bei Microsoft Entra ID (ehemals Azure AD) gespeichert.
Beim Login signiert das Gerät eine Challenge – ohne dass ein Passwort übertragen wird.

👉 Selbst eine täuschend echte Phishing-Seite kann diese Anmeldung nicht nachahmen,
weil der Private Key das Gerät niemals verlässt.

Vorteile von Passwordless Authentication

Vorteil	Beschreibung
🛡️ Phishing-resistent	Keine Passwörter = kein Angriffsziel
🚀 Schneller Login	Kein Eintippen, kein „Passwort vergessen“
💼 Weniger Supportaufwand	Reduziert Helpdesk-Tickets
🔑 Stärkere Sicherheit	Basierend auf Kryptografie, nicht Wissen
🔗 Microsoft 365 integriert	Unterstützt in Entra ID, Windows & Azure

Fazit: Phishing verhindern, bevor es passiert

Der Phishing-Angriff über Azure Blob Storage verdeutlicht, dass Angreifer heute legitime Dienste nutzen, um Vertrauen zu missbrauchen.

Mit Passwordless Authentication nehmen wir ihnen das wichtigste Werkzeug –
das Passwort – einfach weg.

💬 „You can’t phish what doesn’t exist.“
– Microsoft Security Engineering Team

Passwordless ist keine Zukunftstechnologie mehr,
sondern der nächste logische Schritt in der Sicherheitsstrategie moderner Microsoft-Umgebungen.

Conditional Access und Microsoft Defender for Endpoint: Ein Teufelskreis?

Eine wirkungsvolle Möglichkeit, die Sicherheit innerhalb eines Unternehmens zu erhöhen, besteht darin, den Microsoft Defender for Endpoint Status über eine Compliance-Richtlinie in den Compliance-Status für Intune verwaltete Geräte einzubinden. Auf diese Weise können gefährdete Geräte schnell identifiziert und vom Zugriff auf Unternehmensdaten ausgeschlossen werden. Dieser Ansatz schafft eine zusätzliche Schutzebene. Zusätzlich stellt dieser sicher, dass nur Geräte mit einem sicheren Status auf sensible Informationen zugreifen können. Insbesondere bei schwerwiegenden Sicherheitslücken oder Sicherheitsvorfällen ist dies eine zuverlässige Methode die Geräte bis zur Mitigation der Ursache vom Zugriff auf Unternehmensdaten zu sperren.

Dender for Endpoint in Compliance Policy

Allerdings kann die Verknüpfung von Microsoft Defender for Endpoint und Conditional Access Richtlinien schnell in einen Teufelskreis führen. Das passiert , wenn eine Conditional Access Regel implementiert ist, die den Zugriff für nicht kompatible Geräte blockiert. Dadurch entsteht ein Dilemma: Die betroffenen Geräte können sich nicht erneut als kompatibel registrieren. Der Grund dafür ist die Conditional Access Policy die den Zugriff sperrt. Das macht es für den Administrator schwer das Gerät, ohne ein komplettes Zurücksetzen wieder kompatibel zu bekommen.

Wie der Teufelskreis entsteht?

Standardmäßig können die beiden Microsoft Defender for Endpoint Applikationen nicht direkt aus Conditional Access Richtlinien ausgenommen werden. Die Folge ist, dass Geräte, die durch den Conditional Access blockiert werden, keine Möglichkeit haben, sich wieder als kompatibel zu registrieren. Der Zugriff auf dafür notwendige Dienste wird gesperrt, wodurch der Status „nicht kompatibel“ bestehen bleibt. Standardmäßig stehen die beiden Applikationen „MicrosoftDefenderATP XPlat“ und „Microsoft Defender for Mobile TVM app“ nicht im Conditional Access zur Auswahl.

Wie kann der Teufelskreis durchbrochen werden?

Um diesen Teufelskreis zu durchbrechen, müssen die beiden Service Principals registriert werden: „MicrosoftDefenderATP XPlat app“ (a0e84e36-b067-4d5c-ab4a-3db38e598ae2) und Microsoft Defender for Mobile TVM app (e724aa31-0f56-4018-b8be-f8cb82ca1196).

Dies funktioniert mit der Powershell mit folgendem Code:

Install-Module Microsoft.Graph

Import-Module Microsoft.Graph.Applications

 

Connect-MgGraph

$params = @{

              appId = "a0e84e36-b067-4d5c-ab4a-3db38e598ae2"

}

New-MgServicePrincipal -BodyParameter $params

$params = @{

              appId = "e724aa31-0f56-4018-b8be-f8cb82ca1196"

}

New-MgServicePrincipal -BodyParameter $params

Nach der Registrierung können die Anwendungen aus den Conditional Access Richtlinien ausgeschlossen werden. Dieser Ausschluss sorgt dafür, dass die Geräte weiterhin Zugriff auf die notwendigen Dienste haben, selbst wenn sie als nicht kompatibel markiert sind. Dadurch wird es möglich, die Geräte wieder als kompatibel zu registrieren und den Zugriff zu normalisieren.

Defender for Endpoint aus Conditional Access Policy ausschließen. — Defender for Endpoint aus Conditional Access Regel ausschließen

Fazit

Mit diesem Trick kann der Teufelskreis durchbrochen werden und die Geräte erhalten wieder Zugriff auf die M365 Dienste, sobald die Compliance wiederhergestellt ist. Auch bleibt während der Non-Compliance die Kommunikation mit dem Defender for Endpoint bestehen und wird nicht „abgeschnitten“. Das erhöht die Sicherheit und hilft dabei das Potential des Defender for Endpoints bestmöglich zu nutzen. Der Defender for Endpoint Status kann unter anderem in den Compliance Policies für Windows, iOS und Android genutzt werden.

Microsoft MFA für alle Benutzer ab Juli 2024?

Eigentlich sollte sie bereits für jeden Microsoft 365 Benutzer aktiv sein, die Multi Faktor Authentifizierung (MFA). Trotzdem hat Microsoft mit der Ankündigung MFA für alle Benutzer anzufordern für Aufregung gesorgt (Microsoft will require MFA for all Azure users). Insbesondere da es Gründe für bestimmte Benutzer bestehen, keine MFA zu forcieren. Hierunter fallen z.B. Service Benutzer oder auch bestimmte Benutzergruppen.

Die Ankündigung wurde mittlerweile präzisiert und es betrifft nur Benutzer, die auf folgende Anwendungen zugreifen:

Azure portal
Microsoft Entra admin center
Azure PowerShell
Azure CLI
Terraform für die Administration von Azure

Auf die genannten Anwendungen greifen in der Regel nur Benutzer zu, die administrative Vorgänge durchführen. Vom MFA-Zwang ausgenommen werden sollen: Dienstprinzipalobjekte, verwaltete Identitäten, Workload-Identitäten und weitere tokenbasierte Konten. Microsoft sammelt hier auch noch weiteren Input für weitere Szenarien, wie z.B. Break-Glass Administratoren. Diese sind als Best-Practise ohne MFA empfohlen, um im Notfall weiterhin Zugang zum Tenant zu bieten.

Wie setzt Microsoft die Anforderung technisch um?

Dazu gibt es leider noch keine konkrete Aussage. Ich vermute allerdings, dass dies über eine von Microsoft verwaltete Regel des bedingten Zugriffs realisiert wird. In der Technet zu den von Microsoft verwalteten Richtlinien (Secure your resources with Microsoft-managed Conditional Access policies – Microsoft Entra ID | Microsoft Learn), findet sie die folgende Regel, die stark an die Ankündigung von Microsoft erinnert: „Require multifactor authentication for Azure management.“

Welche Aufgaben ergeben sich hieraus?

Prüfen der Sign-in Logs auf die oben genannten Anwendungen, um die betroffenen Benutzer, insbesondere Service Benutzer zu identifizieren.
Registrieren der MFA für alle Benutzer, die auf die oben genannten Anwendungen zugreifen.
Bei allen klassischen Service Benutzern die Möglichkeit prüfen, diese auf tokenbasierte Konten umzustellen.
Falls es über eine von Microsoft verwaltete Richtlinie realisiert wird, unbedingt die Break Glass Admins ausschließen.

Fazit

Zusammenfassend handelt es sich um eine sinnvolle Maßnahme um die Sicherheit der Tenants zu erhöhen. Noch immer gibt es viele ungesicherte Konten mit kritischen Zugriffen. Für diese soll nun die MFA aktiviert werden. Auch sind viele Service Accounts im Einsatz, die längst durch tokenbasierte Konten ersetzt werden könnten. Leider ist die ist die Kommunikation recht kurzfristig und vage.

„Mit Anmeldung fortfahren?“ Änderung bei Windows Single-Sign-On

Microsoft hatte es bereits im Dezember angekündigt. Aufgrund des Digital Markets Act (DMA) müssen die Benutzer dem Single-Sign-On auf Windows Geräten zustimmen. Hierzu erhält der Benutzer bei dem Zugriff auf M365 Ressourcen die Frage „Mit Anmeldung fortfahren?“. Diese muss der Anwender mit „weiter“ bestätigen um sich zu authentifizieren. Unter aka.ms/sso-info werden weitere Informationen angeboten. Die Infoseite erklärt, dass SSO weiterhin nur nach Bestätigung dieser Abfrage möglich ist.

Der Benutzer muss diese Meldung auf jedem Gerät an dem er arbeitet einmalig bestätigen. Die Bestätigung ist anschließend nicht mehr nötig, nur wenn sich der Benutzer 90 Tage nicht mehr an diesem Gerät authentifiziert hat.

Die Änderung wird nach und nach innerhalb des Europäischen Wirtschaftsraums aktiviert. Betroffen davon sind die Betriebssysteme Windows 10 und 11, bei denen innerhalb des initialen Gerätesetups ein Land innerhalb des Europäischen Wirtschaftsraums gewählt wurde. Explizit wirkt diese Änderung nicht auf Server Betriebssystemen.

Innerhalb der Entra-Anmeldeprotokolle führen fehlende Benutzerzustimmungen zu Anmeldefehlern mit dem Code 9002341 und der Fehlerursache „User is required to permit SSO“.

In einigen Fällen führt dies zu Problemen, da beispielsweise die Authentifizierung gegen Microsoft 365 Dienste wie z.B. bei einem automatischen Intune Join via GPO nicht durchgereicht wird. Dies klappt erst, wenn der Benutzer den SSO bestätigt hat. Aber auch bei nicht-persistenten VDIs führt das neue Feature bei jeder neuen Sitzung zur oben genannten Abfrage. Microsoft sind Probleme bekannt und will zeitnah nachbessern.

Weitere Infos und der Blog-Eintrag von Microsoft dazu:

Upcoming changes to Windows Single Sign-On | Windows IT Pro (microsoft.com)

Microsoft Entra Password Protection: Ein Muss für die Sicherheit Ihres Unternehmens

In der heutigen digitalen Welt, in der Cybersicherheit von größter Bedeutung ist, bleibt das Passwort ein grundlegender, aber oft übersehener Aspekt der Sicherheitsstrategie eines Unternehmens. Viele Organisationen besitzen bereits Lizenzen für fortschrittliche Sicherheitstools, setzen diese jedoch nicht ein. Ein solches Beispiel ist die Microsoft Entra Password Protection – ein leistungsstarkes Werkzeug, das speziell dafür entwickelt wurde, die Passwortsicherheit zu verbessern, indem es die Verwendung schwacher und häufig genutzter Passwörter verhindert.

Trotz der Verfügbarkeit dieses Tools aktivieren viele Kunden die Funktion nicht. Dieser Artikel dient als Ihre jährliche Erinnerung daran, warum es entscheidend ist, den Microsoft Entra ID Kennwortschutz in Ihrem lokalen Active Directory zu implementieren, vor allem, wenn Sie über die entsprechende Entra ID P1 oder P2 Lizenz verfügen.

Warum Microsoft Entra Password Protection wichtig ist

Viele Unternehmen haben bereits eine Lizenz für Microsoft Entra ID, nutzen aber den Kennwortschutz nicht. Dieses Tool verbessert die Passwortkomplexität im lokalen Active Directory signifikant, indem es bekannte schwache Passwörter und ihre Varianten sowie weitere schwache Begriffe blockiert, die spezifisch für eine Organisation sein könnten.

Die häufigsten Missverständnisse aufgeklärt

Im Laufe der Jahre sind mir einige Missverständnisse begegnet, die dazu führen, dass Organisationen zögern, diese notwendige Sicherheitsmaßnahme zu ergreifen. Hier möchte ich einige dieser Missverständnisse ausräumen:

„Es ist zu kompliziert einzurichten“: Die Implementierung von Microsoft Entra Password Protection ist unkompliziert und erfordert keine Änderungen am AD DS-Schema oder das Öffnen neuer Netzwerkports.
- Es wird keine spezifische AD Gesamtstrukturebene erfordert
  - Wenn Azure nicht verfügbar ist, hat dies keine Auswirkungen auf das Zurücksetzen Ihrer Kennwörter
  - Erfordert keine neuen Ports, welche auf Ihren DC’s geöffnet werden müssen
  - Es ist nicht erforderlich, dass Ihre DC’s über einen Internetzugang verfügen. Die Passwort-Sperrliste wird von einem Proxyserver/Dienst verteilt
„Unsere Passwörter sind bereits stark genug“: Selbst wenn Ihre Organisation strenge Passwortrichtlinien verfolgt, gibt es immer noch eine Fülle gängiger Passwörter und Variationen, die durch traditionelle Richtlinien nicht abgedeckt werden. Tatsächlich ergänzt Microsoft Entra Password Protection vorhandene Richtlinien durch Hinzufügen einer weiteren Sicherheitsebene gegen schwache Passwörter. Microsoft Entra erweitert Ihren Schutz, indem es eine globale Datenbank schwacher Passwörter und deren Variationen nutzt.
„Es wird die Benutzerfreundlichkeit beeinträchtigen“: Während die Blockierung schwacher Passwörter die Passwortauswahl einschränken kann, dient sie dem größeren Ziel, Konten sicherer zu machen.
- Die Funktion wird erst wirksam, wenn die Passwörter Ihrer Benutzer das nächste Mal ablaufen bzw. zurückgesetzt werden müssen. Es wird keine Massenzurücksetzung der Passwörter durchgeführt.
„Es ist nur eine weitere unnötige Sicherheitsmaßnahme“: Angesichts der steigenden Zahl von Cyberangriffen, insbesondere Passwort-Spray-Angriffen, ist die Verwendung eines Tools wie Microsoft Entra alles andere als unnötig. Es ist eine essenzielle Schicht in Ihrer Sicherheitsstrategie, die die Schwachstellen, die durch schwache Passwörter entstehen, minimiert.

Mein Aufruf zum Handeln

Die Implementierung des Microsoft Entra ID Kennwortschutzes ist nicht nur eine Best Practice, sondern eine Notwendigkeit in der heutigen von Cyberbedrohungen geprägten Landschaft. Durch die Verbesserung der Passwortkomplexität und die Eliminierung schwacher Passwörter stärken Sie die Verteidigungslinie Ihres Unternehmens gegen unautorisierten Zugriff erheblich.

Wenn Ihre Organisation über eine Lizenz für Microsoft Entra (P1/P2) verfügt, ist es an der Zeit, den Kennwortschutz zu aktivieren. Dies ist ein einfacher Schritt, der die Sicherheit Ihres Unternehmens erheblich verbessern kann. Vermeiden Sie die gängigen Fallen schwacher Passwörter und machen Sie den ersten Schritt in Richtung einer sichereren digitalen Umgebung.

Lassen Sie dieses Jahr nicht ungenutzt verstreichen, ohne die volle Macht der Microsoft Entra Password Protection zu nutzen. Es ist ein einfacher, aber wirkungsvoller Schritt, um die Cybersicherheit Ihres Unternehmens zu stärken.

Sicherer Zugriff im Zeitalter der Künstlichen Intelligenz: Was ist neu bei Microsoft Entra?

Als IT-Berater bin ich immer auf der Suche nach den neuesten Innovationen im Bereich der Cybersicherheit, die meinen Kunden helfen können, ihre digitale Umgebung zu schützen. Deshalb war ich sehr gespannt auf die Ankündigungen von Microsoft Entra, der integrierten Lösung für Identitäts- und Zugriffsmanagement, auf der Ignite 2023 Konferenz. Nun möchte ich mit einer zeitlichen Verzögerung endlich über meine persönlichen Highlights berichten.

Was ist Microsoft Entra?

Microsoft Entra bietet eine Reihe von Funktionen, die den sicheren Zugriff auf alle Anwendungen und Ressourcen für alle Benutzer und Geräte ermöglichen, die sich von überall aus verbinden. Dabei werden die Prinzipien des Zero Trust Ansatzes verfolgt, der auf der Verifizierung von Identität, Gerät, Anwendung und Netzwerk basiert, bevor der Zugriff gewährt wird.

Einige der Highlights, die mich besonders beeindruckt haben, sind:

Security Service Edge (SSE): Dies ist eine neue Lösung, die Microsoft Entra Internet Access und Microsoft Entra Private Access umfasst. Microsoft Entra Internet Access ist ein identitätszentriertes Secure Web Gateway (SWG), welches den Zugriff auf alle Internetanwendungen und -ressourcen mit bedingtem Zugriff und Web-Inhaltsfilterung sichert. Microsoft Entra Private Access ist ein identitätszentriertes Zero Trust Network Access (ZTNA), das den Zugriff auf alle privaten Anwendungen und Ressourcen mit bedingtem Zugriff und modernen Authentifizierungsmethoden sichert. Beide Lösungen arbeiten mit dem bestehenden Sicherheits- und Netzwerkstack von Microsoft und einem offenen Partnernetzwerk zusammen, um eine nahtlose Integration zu gewährleisten.
Microsoft Security Copilot: Dies ist ein neuer digitaler Assistent, welcher in das Microsoft Entra Admin Center eingebettet ist und den Administratoren hilft, häufige Aufgaben zu automatisieren, schneller zu beheben, komplexe Richtlinien zu interpretieren und Workflows zu entwerfen. Der Security Copilot beantwortet einfache Fragen, was eine bedingte Zugriffsrichtlinie macht oder warum die mehrstufige Authentifizierung (MFA) ausgelöst wurde. Der Security Copilot bietet auch eine Risikozusammenfassung, Abhilfemaßnahmen und empfohlene Anleitungen für gefährdete Identitäten, um das schnelle Reagieren auf Identitätsrisiken zu erleichtern. Ich kann also einfach meinen digitalen Assistenten Fragen stellen und dieser analysiert die notwendigen Anmeldelogs, bereitet diese auf und liefert mir eine passende Antwort.
Phishing-resistente Authentifizierungsmethoden: Microsoft Entra unterstützt verschiedene MFA-Methoden, um die Authentifizierung vor Phishing zu schützen. Dazu gehören zum Beispiel FIDO2 Security Keys, Windows Hello for Business, Microsoft Entra Certificate-Based Authentication (CBA) und Passkeys. Alle diese Methoden ermöglichen es, Passwörter ganz zu eliminieren, so dass sie nicht erraten, abgefangen oder gephished werden können. Microsoft Entra CBA ermöglicht es, Authentifizierungsrichtlinien nach Zertifikat, Ressourcentyp und Benutzergruppe anzupassen. Passkeys sind eine neue Funktion, welche mit Windows 11 eingeführt wurde und es ermöglicht, sich mit dem Gesicht, dem Fingerabdruck oder der PIN des Geräts bei einer Website, Anwendung oder einem Dienst anzumelden, für den man einen Passkey erstellt hat. Microsoft Entra ID-Benutzer werden bald in der Lage sein, sich mit Passkeys anzumelden, die aus der Microsoft Authenticator App verwaltet werden. Ein aus meiner Sicht wichtiger Schritt, um die Notwendigkeit von Kennwörtern endgültig abzuschaffen.
Microsoft Entra Permissions Management: Dies ist eine Lösung, die Einblicke in die Berechtigungsrisiken bietet. Es gibt zwei wichtige Integrationen, die mir aufgefallen sind. Die erste ist die Integration mit Microsoft Defender for Cloud (MDC), diese ermöglicht es, Identitäts- und Zugriffsberechtigungsinformationen mit anderen Cloud-Sicherheitsinformationen in einer einzigen Schnittstelle zu konsolidieren. Diese Ansicht zeigt handlungsorientierte Empfehlungen zur Behebung von Berechtigungsrisiken sowie den Permissions Creep Index an und erleichtert die Durchsetzung des Least Privilege Zugriffs für Cloud-Ressourcen über Azure, Amazon Web Services (AWS) und Google Cloud hinweg. Die zweite Integration ermöglicht es ServiceNow-Kunden, zeitgebundene, bedarfsgesteuerte Berechtigungen für Multicloud-Umgebungen (Azure, AWS, Google Cloud) über das ServiceNow-Portal anzufordern. Diese beliebte IT-Service-Management (ITSM)-Lösung stärkt somit die Zero Trust-Haltung, indem sie Zugriffsberechtigungsanfragen zu bestehenden Genehmigungsworkflows in ServiceNow hinzufügt. Ein wichtiger Schritt Richtung herstellerunabhängiger Zero-Trust Architektur.

Fazit

Ich bin beeindruckt von dem Umfang und der Tiefe der Funktionen, welche Microsoft Entra bietet, um den sicheren Zugriff auf alles und für jeden zu ermöglichen. Ich glaube, dass diese Lösungen meinen Kunden helfen kann, ihre digitale Transformation voranzutreiben und gleichzeitig ihre Sicherheit zu erhöhen. Gerade die Integration von anderen Cloud Services wie AWS, Google oder Service-Now sind wichtige Schritte für die Absicherung der Identitäten.

Übersicht über Windows LAPS

In diesem Blogbeitrag möchte ich Ihnen eine spannende neue Funktion vorstellen, welche mit dem heutigen Sicherheitsupdate vom 11. April 2023 für die folgenden Windows-Editionen direkt im Betriebssystem enthalten sind:

Windows 11 Pro, EDU, and Enterprise
Windows 10 Pro, EDU, and Enterprise
Windows Server 2022 and Windows Server Core 2022
Windows Server 2019

Windows Local Administrator Password Solution (Windows LAPS) für Azure Active Directory

Native Integration in Windows

Windows LAPS ist sofort einsatzbereit. Sie müssen kein externes MSI-Paket mehr installieren, kein AD-Schema mehr erweitern und keine Gruppenrichtlinien verteilen! Alle zukünftigen Anpassungen, Verbesserungen oder Funktionsupdates werden über die normalen Windows-Patching-Prozesse bereitgestellt.

Was ist Windows LAPS?

Windows LAPS ist eine Windows-Funktion, die bereits für in Windows Server Active Directory eingebundene Geräte verfügbar ist. Sie ermöglicht es Ihnen, die Kennwörter der lokalen Administratorkonten auf Ihren Geräten automatisch zu generieren, zu ändern und zu speichern. Dies erhöht die Sicherheit, da Sie nicht mehr das gleiche Kennwort für alle Geräte verwenden müssen, und vermeidet somit das Risiko von Pass-the-Hash-Angriffen und unterbindet aktiv das sogenannte Lateral Movement.

Windows LAPS bietet einige Vorteile gegenüber anderen Methoden zur Verwaltung von lokalen Administratorpasswörtern, wie z.B.:

Es generiert zufällige und komplexe Passwörter für jedes Gerät und ändert sie regelmäßig nach einem festgelegten Zeitplan.
Es speichert die Passwörter verschlüsselt in einem Active Directory-Attribut, das nur von berechtigten Benutzern oder Gruppen abgerufen werden kann.
Es vermeidet die Verwendung eines gemeinsamen Passworts für alle Geräte oder die manuelle Verfolgung von Passwörtern in einer Excel-Tabelle oder einem anderen Medium.
Es ermöglicht es Administratoren, die Passwörter bei Bedarf schnell zu ändern oder zurückzusetzen, z.B. bei einem Sicherheitsvorfall oder einem Mitarbeiterwechsel.
Es ist einfach zu implementieren und zu verwalten, ohne dass zusätzliche Hardware oder Software erforderlich ist.

Windows LAPS ist eine nützliche Lösung für alle Organisationen, die lokale Administratorpasswörter auf ihren Windows-Geräten effektiv verwalten wollen. Es ist kostenlos und einfach zu verwenden und bietet einen hohen Grad an Sicherheit und Kontrolle.

Windows LAPS unterstützt Azure AD

Windows LAPS für Azure Active Directory erweitert die bestehende Funktion um die Möglichkeit, die Kennwörter der lokalen Administratorkonten in Azure Active Directory zu sichern. Dies hat mehrere Vorteile:

Sie können die gespeicherten Kennwörter über Microsoft Graph abrufen.
Sie können zwei neue Microsoft Graph-Berechtigungen erstellen, um nur die Kennwort-„Metadaten“ (z. B. für Sicherheitsüberwachungs-Apps) oder das sensible Klartextkennwort selbst abzurufen.
Sie können Azure-Richtlinien für rollenbasierte Zugriffssteuerung (Azure RBAC) verwenden, um Autorisierungsrichtlinien für das Abrufen von Kennwörtern zu erstellen.
Sie können das Azure-Verwaltungsportal verwenden, um Kennwörter abzurufen und zu ändern.
Sie können die Funktion über Intune verwalten!
Sie können das Kennwort automatisch ändern, nachdem das Konto verwendet wurde.

Wie kann ich Windows LAPS für Azure Active Directory einrichten?

Um Windows LAPS für Azure Active Directory einzurichten, müssen Sie zunächst einen Mechanismus zur Bereitstellung von Richtlinien auf Ihren Geräten wählen. Die bevorzugte Option ist die Verwendung von Microsoft Intune mit dem Windows LAPS-Konfigurationsdienstanbieter (CSP). Wenn Sie Microsoft Intune nicht verwenden, können Sie auch andere Methoden verwenden, wie z. B. die direkte Änderung der Registrierung oder die Verwendung von Gruppenrichtlinie für lokale Computer.

Exchange 2013 – End of Life

Heute ist der 11. April 2023, das offizielle Support Ende vom Exchange 2013 Server. Das bedeutet, dass Microsoft keine Sicherheitsupdates, Bugfixes oder technischen Support mehr für diese Version anbietet.

Was sind die Folgen für die Nutzer und Administratoren von Exchange 2013 Server und wie können sie sich darauf vorbereiten?

Exchange 2013 Server wurde im Oktober 2012 veröffentlicht und bot damals viele neue Funktionen und Verbesserungen für die E-Mail-Kommunikation in Unternehmen. Dazu gehörten unter anderem eine modernisierte Web-Oberfläche (Outlook Web App), eine bessere Integration mit SharePoint und Lync, eine höhere Skalierbarkeit und Leistung sowie eine vereinfachte Verwaltung und Migration.

Nach mehr als zehn Jahren ist Exchange 2013 Server jedoch veraltet und kann nicht mehr mit den aktuellen Anforderungen an Sicherheit, Compliance und Produktivität mithalten. Zudem ist Exchange 2013 nicht mehr kompatibel mit den neuesten Versionen von Windows Server, Office oder Outlook. Das bedeutet, dass die Nutzer und Administratoren von Exchange 2013 Server ein erhöhtes Risiko für Cyberangriffe, Datenverluste oder Ausfälle haben. Sie sollten daher rechtzeitig auf eine neuere Version umsteigen.

Die empfohlene Lösung für die Nutzer und Administratoren von Exchange 2013 Server ist der Wechsel zu Exchange Online, dem Cloud-basierten E-Mail-Dienst von Microsoft 365.

Microsoft meldet neuen Angriff mit Azure AD Connect

In diesem Blogbeitrag möchte ich den Inhalt des Artikels https://practical365.com/mercury-attack-april-2023 auf Deutsch zusammenfassen.

Der Artikel beschreibt einen neuen Angriff, welcher Azure AD Connect ausnutzt, um sowohl On-Premises- als auch Cloud-Ressourcen zu kompromittieren.

Wer steckt hinter den Angriffen?

Der Angriff wurde von Microsoft Threat Intelligence aufgedeckt und wird zwei Gruppen zugeschrieben: MERCURY, einer mit der iranischen Regierung verbundenen Nation-State-Akteurin, und DEV-1084, einer Gruppe, welche von MERCURY beauftragt wurde, die Netzwerkzugriffe auszunutzen.

Wie begann der Angriff?

Bei Angriffen wie diesem hört man oft zwei Begriffe: Eskalation von Privilegien und Lateral Movement.

Lateral Movement klingt kompliziert, ist aber einfach: Der Begriff bedeutet nur, dass ein Angreifer ein Gerät oder System in einem Netzwerk kompromittiert hat und dies als Sprungbrett oder Drehpunkt nutzt, um in andere Geräte oder Systeme zu gelangen. Diese Bewegung kann sofort erfolgen, aber oft ist sie verzögert (wie in diesem Fall) – ein kluger Angreifer wird eindringen, eine Persistenz herstellen und dann eine Weile warten, das Zielnetzwerk studieren und jede offensichtliche Aktion vermeiden, welche die Verteidiger auf seine Anwesenheit aufmerksam machen könnte.

In diesem Fall begann der Angriff mit der Ausnutzung der bekannten log4j-Schwachstelle, um in das Netzwerk einzudringen und Persistenz zu erlangen. Die Angreifer bewegten sich dann durch das Netzwerk und griffen sowohl On-Premises- als auch Hybrid-Ressourcen an. Für die On-Premises-Angriffe nutzten sie Gruppenrichtlinienobjekte (GPOs), um Sicherheitstools (Endpoint Protection) zu stören und Ransomware über die NETLOGON-Freigaben auf den Active Directory-Domänencontrollern zu verteilen. Für die Hybrid-Angriffe nutzten sie Azure AD Connect, um sich mit Azure AD zu synchronisieren und Zugriff auf Cloud-Ressourcen zu erhalten. Die Angreifer löschten anschließend Daten aus Azure Storage-Konten und Azure SQL-Datenbanken. Mit einem vernünftigen Tier-Modell wäre der Angriff in diesem Ausmaß vermutlich nicht umsetzbar gewesen.

Microsoft empfiehlt dringend, Azure AD Connect zu überprüfen und sicherzustellen, dass es keine unbefugten oder verdächtigen Synchronisierungen gibt. Außerdem sollten die Sicherheitsmaßnahmen für Domänencontroller und GPOs verstärkt werden, um ähnliche Angriffe zu verhindern oder zu erkennen. Microsoft bietet verschiedene Sicherheitstools an, die bei der Untersuchung und Abwehr solcher Angriffe helfen können, wie z.B. Microsoft Defender for Endpoint, Microsoft 365 Defender und Azure Sentinel.

Dennoch zeigt dieser Angriff wieder, wie wichtig es ist, sowohl On-Premises- als auch Cloud-Umgebungen zu schützen und zu überwachen. Hybrid-Umgebungen bieten viele Vorteile, aber auch neue Herausforderungen und Risiken. Es ist daher unerlässlich, sich über die aktuellen Bedrohungen zu informieren und die besten Praktiken für die Sicherheit von Azure AD Connect zu befolgen. Zum Schutz gehört auch der Aufbau von Tier-Strukturen.

Wozu ist ein Azure AD Connect Server notwendig?

Azure AD Connect ist ein wichtiges Werkzeug für die Synchronisation von Identitäten zwischen lokalen Active Directory-Domänen und Azure Active Directory. Da der Azure AD Connect Zugriff auf die Anmeldeinformationen und Attribute aller Benutzer und Gruppen in den verbundenen Domänen hat, muss dieser Server entsprechend gut geschützt werden. Daher sollten Sie den Azure AD Connect wie einen Domänencontroller behandeln und in Tier-0 aufnehmen.

Was bedeutet Tier-0?

Tier-0 ist die höchste Sicherheitsstufe in einem Active Directory-Design, das auf dem Prinzip der administrativen Grenzen basiert. Tier-0 umfasst alle Systeme und Konten, die in der Lage sind, Änderungen an der Active Directory-Domänenstruktur oder den Sicherheitsrichtlinien vorzunehmen. Diese sollten von anderen Tiers isoliert und mit strengen Zugriffs- und Überwachungsregeln versehen werden.

Indem der Azure AD Connect Server in Tier-0 aufgenommen wird, wird sichergestellt, dass nur berechtigte Administratoren darauf zugreifen können und dass alle Aktivitäten auf dem Server protokolliert und überprüft werden. Dies reduziert das Risiko eines unbefugten Zugriffs oder einer Kompromittierung von Azure AD Connect.