Cybersecurity befindet sich in einer Phase struktureller Transformation. Technologische Entwicklungen wie Künstliche Intelligenz, Large Language Models (LLMs), agentenbasierte Systeme, Model Context Protocols (MCP) sowie hochentwickelte Deepfake-Technologien verändern die Bedrohungslandschaft grundlegend. Maschinen begegnen Maschinen. Angriffe werden automatisierter, skalierbarer und zugleich präziser. Die Eintrittsbarrieren für professionelle Angriffswerkzeuge sinken, während sich gleichzeitig die Angriffsflächen durch Cloud-Transformation, digitale Ökosysteme und vernetzte Operational-Technology-Umgebungen kontinuierlich erweitern.

Die Spielregeln werden angepasst

Künstliche Intelligenz schreibt heute täuschend echte Phishing-Mails. Deepfakes imitieren Stimmen und Bildübertragung von CEOs in Echtzeit. Autonome Agenten analysieren Angriffsflächen, Large Language Models und Protokolle wie MCP erweitern nicht nur die Möglichkeiten von Unternehmen sie erweitern auch die Möglichkeiten von Angreifern.

Cyberangriffe sind nicht mehr nur primär technisch komplex. Sie werden zunehmend skalierbarer, adaptiver und ökonomisch effizienter.

Und dennoch bleibt der Kern unverändert: Am Ende geht es um 0 und 1. Um Daten. Um geschäftskritische Informationen. Um Systeme, die funktionieren müssen. Cybersecurity ist keine Frage maximaler Absicherung, sondern eine Frage des bewusst definierten Risikoappetits.
Sie ist eine strategische Entscheidung:

• Wie resilient wollen wir sein?
• Wie abhängig sind wir digital?
• Welche Risiken sind wir bereit zu tragen und welche nicht?

Werte integral geschützt zu Wissen – das Bedürfnis.

Wer Cybersecurity heute als rein operative IT-Aufgabe versteht, unterschätzt ihre Tragweite. Sie entscheidet über Handlungsfähigkeit, regulatorische Stabilität, Vertrauen im Markt und letztlich über Unternehmenswert.

Genau hier setzen wir an

Im vergangenen Jahr haben unsere Red, Blue und Titanium Teams in einer Vielzahl anspruchsvoller Mandate gezeigt, was moderne Sicherheitsarbeit leisten muss und kann. Realitätsnahe Red-Team-Engagements haben nicht nur technische Schwächen aufgezeigt, sondern Entscheidungsprozesse getestet. Purple-Team-Formate haben Silos aufgebrochen und Detection- sowie Response-Fähigkeiten messbar verbessert. OT-Initiativen haben Produktionsumgebungen resilienter gemacht. Sicherheitsbewertungen im Kontext von LLMs und KI-Systemen haben neue Risiken greifbar und steuerbar gemacht.

Die konkrete Projektliste ist lang. Entscheidend ist etwas anderes: Wirkung.

Herausforderung KI in Red Teamings

Ein ähnliches Prinzip gilt für technisch anspruchsvolle Red-Team-Projekte. Ein unkontrolliert agierendes rogue KI-Device oder ein autonomer Agent im eigenen Netzwerk ist kein Innovationsbeweis, sondern wird ein zusätzliches Risiko. In unseren zahlreichen, oftmals zeitintensiven Red-Team-Mandaten, zeigt sich immer wieder: Erfolgreiche Angriffe entstehen nicht durch Zufall, sondern durch präzise technische Analyse und die systematische Verkettung mehrerer Schwachstellen. Initial Access, Privilege Escalation, Credential Abuse, laterale Bewegung oder das Ausnutzen impliziter Vertrauensstellungen sind selten isolierte Einzelereignisse, sie bilden strukturierte Angriffspfade.

Unsere Engagements sind bewusst realitätsnah konzipiert mit klar definierten Zielbildern, strengen Rules of Engagement und tiefgehender technischer Durchführung. Dass wir bislang in jedem Mandat die vereinbarten Ziele erreichen konnten, ist kein Hinweis auf spektakuläre Einzellücken, sondern auf methodische Konsequenz und technische Exzellenz. Vor allem aber zeigt es, wie reproduzierbar komplexe Angriffsketten selbst in reifen Organisationen sind.

Vor diesem Hintergrund können KI-Agenten operative Subtasks durchaus beschleunigen, etwa bei Reconnaissance, der Analyse grosser Identitäts- und Berechtigungsstrukturen oder der systematischen Variation von Angriffsmustern. Doch Automatisierung ersetzt weder Erfahrung noch taktisches Urteilsvermögen. Autonome Systeme dürfen nicht eigenständig Eskalationsentscheidungen treffen oder Persistenz Strategien etablieren. Maschine gegen Maschine ist kein Fakt der in einer produktiven Umgebung derzeit Realität ist. Offensive Sicherheitsarbeit bleibt ein kontrollierter, präzise gesteuerter Prozess.

Und genau hier liegt die Management-Dimension: Red Teaming ist kein technisches Selbstzweck-Experiment, sondern ein Instrument zur Validierung strategischer Resilienz. Es beantwortet nicht nur die Frage, ob ein Angriff möglich ist, sondern wie wahrscheinlich, mit welchem Aufwand und mit welchen geschäftlichen Auswirkungen. Die daraus gewonnenen Erkenntnisse sind Grundlage für Priorisierung, Investitionsentscheidungen und die bewusste Definition des eigenen Risikoappetits. Technische Exzellenz schafft Transparenz, strategische Führung schafft Konsequenz.

Herausforderung Vibe Coding

Die Grundlage belastbarer Cybersecurity bleibt das fundierte Verständnis der eingesetzten Technologien. Insbesondere in einer Zeit, in der KI-Modelle produktionsnah wirkenden Code in Sekunden generieren. Ob Infrastruktur-as-Code (IaC), API-Integrationen, Automatisierungsskripte oder komplexe Business-Logik: Der generierte Output ist häufig syntaktisch korrekt und folgt gängigen Framework-Konventionen. Doch er basiert auf statistischer Wahrscheinlichkeit, nicht auf kontextuellem Sicherheitsverständnis.

In der Praxis zeigen sich typische Muster: Fehlende oder unzureichende Eingabevalidierung, unsichere Deserialisierung, ungeschützte Endpunkte, Hardcoded Secrets oder über privilegierte Service-Accounts. Autorisierungsprüfungen werden vereinfacht oder ausgelassen, Trust Boundaries nicht klar definiert, Default-Konfigurationen unreflektiert übernommen. Logging-Mechanismen erfassen sensible Informationen im Klartext, während Fehlerbehandlungen funktional korrekt, aber sicherheitstechnisch unvollständig bleiben.

Im Kontext von LLM-gestützten Anwendungen entstehen zusätzliche Risiken: Unzureichend mitigierte Prompt-Injection-Angriffe, fehlende Output-Validierung, indirekte Datenabflüsse über Retrieval-Mechanismen oder Tool-Integrationen mit weitreichenden Berechtigungen. Der Code erfüllt teilweise die fachliche Anforderung erweitert jedoch unter Umständen die Angriffsfläche oder etabliert implizite Abhängigkeiten, die architektonisch nie vorgesehen waren.

Wer Programmiersprachen, Sicherheitsarchitekturen und Prinzipien wie Least Privilege, Defense in Depth oder Secure by Design beherrscht, erkennt diese Schwachstellen frühzeitig. Anhand strukturiertem Threat Modeling, sauberen Code-Reviews und gezielter Refaktorierung wird aus generiertem Code belastbare, überprüfbare Implementierung. Genau hier entsteht Mehrwert: Durch Einordnung, Validierung und bewusste Steuerung.

Hier schliesst der Kreis. Technologische Geschwindigkeit entbindet nicht von strategischer Verantwortung. Der Einsatz KI-generierter Komponenten ist keine rein operative Entscheidung, sondern eine Frage des definierten Risikoappetits.

• Welche Abhängigkeiten akzeptieren wir?
• Welche impliziten Risiken tolerieren wir?
• Welche Kontrollmechanismen etablieren wir verbindlich?

KI kann zum Effizienztreiber mit unklarem Risikoprofil werden. Mit klarer Governance wird sie zum strategischen Instrument innerhalb eines kontrollierten Sicherheitsrahmens. Technologie kann Code erzeugen. Verantwortung entsteht durch Verständnis, Kontrolle und bewusste Steuerung.

Wir verbinden offensive Perspektive mit defensiver Exzellenz und strategischer Einordnung. Wir denken nicht in Einzelmassnahmen, sondern ganzheitlich.

Kein Nachlassen

Auch in diesem Jahr steigt die Nachfrage nach genau diesem Ansatz. Zahlreiche neue Initiativen sind bereits gestartet oder in Planung, Mandate zugewiesen und neue Technologietrends unter Beobachtung. Von KI-Governance über Red- und Purple Teaming, über resiliente Cloud-Architekturen, über Maschine gegen Maschine Testzyklen, bis hin zu strategischen Sicherheitsbewertungen im Rahmen digitaler Transformationen.

Unternehmen suchen nicht nur Tests oder Reports. Sie suchen Orientierung. Sie suchen Partner, die technologische Entwicklungen verstehen, einordnen und in belastbare Entscheidungen übersetzen können.

Konkreter Mehrwert entsteht dort, wo Sicherheit strategische Klarheit schafft.

Wenn neue KI-Initiativen eingeführt werden und Governance-Fragen offen sind. Wenn Applikationen auf Ihre Sicherheit getestet werden müssen und eine aussagekräftige Beurteilung benötigt wird. Wenn der Verwaltungsrat ein belastbares Bild der tatsächlichen Resilienz benötigt. Wenn OT-Umgebungen modernisiert werden, ohne die Produktionsstabilität zu gefährden. Oder wenn bestehende Security-Programme zwar existieren, ihre Wirksamkeit jedoch nie realitätsnah validiert wurde. In genau diesen Situationen schaffen wir Transparenz, Priorisierung und Entscheidungsgrundlagen technisch fundiert und managementtauglich aufbereitet.

Stetige Weiterentwicklung

Deshalb investieren wir konsequent in unsere eigene Weiterentwicklung. Wir hinterfragen unsere Prozesse. Wir optimieren unsere Methoden. Wir entwickeln eigene Tools und Softwarelösungen weiter, um Effizienz und Präzision zu erhöhen. Interne Research-Projekte sorgen dafür, dass wir Trends nicht erst dann diskutieren, wenn sie Mainstream sind. Wir analysieren, bevor sie regulatorisch gefordert werden. Wir evaluieren, bevor sie zum Risiko werden.

In einer digitalisierten Wirtschaft ist Vertrauen kein weicher Faktor mehr. Es ist ein strategischer Vermögenswert.

Cybersecurity ist für uns kein reaktives Geschäft. Sie ist ein aktiver Beitrag zur unternehmerischen Zukunftsfähigkeit.

Unser Anspruch ist klar:

• Wir wollen Sicherheitslandschaften nicht nur prüfen, wir wollen sie mitgestalten.
• Wir wollen Risiken nicht dramatisieren, wir wollen sie steuerbar machen.
• Wir wollen Technologie nicht nur absichern, wir wollen sie verantwortungsvoll nutzbar machen.

Fazit

Die Bedrohungslage wird komplexer. Die Technologien werden leistungsfähiger. Doch der entscheidende Unterschied liegt nicht in einzelnen Tools oder Trends, sondern in der Fähigkeit, Entwicklungen frühzeitig einzuordnen und strategisch zu nutzen. Cybersecurity ist heute Ausdruck unternehmerischer Reife. Die Zukunft aktiv gestalten! Wer sie vorausschauend gestaltet, schafft nicht nur Schutzmechanismen, sondern Entscheidungsfreiheit. Wer Resilienz systematisch aufbaut, stärkt Vertrauen bei Kunden, Partnern, Investoren und Mitarbeitenden gleichermassen. Zukunftsfähigkeit entsteht dort, wo Risiken verstanden, priorisiert und bewusst gesteuert werden.

Gerade im Zeitalter leistungsfähiger KI gilt: Technologie kann analysieren, simulieren und optimieren. Die Richtung jedoch bestimmt weiterhin die Unternehmensführung. Oder mit einem leichten Augenzwinkern: Algorithmen unterstützen Entscheidungen. Verantwortung bleibt menschlich.

Unternehmen, die diese Verantwortung aktiv annehmen, sichern nicht nur ihre Systeme; sie gestalten aktiv ihre digitale Zukunft. Ein strukturiertes Sparring auf Augenhöhe schafft oft mehr Klarheit als jede theoretische Diskussion. Wir freuen uns auf den Austausch.

Nachfolgend präsentieren wir die Top-10 risikoreichsten Microsoft-Cloud-Sicherheitskonfigurationen, welche wir während zahlreichen Security Assessment festgestellt haben. Microsoft hat Active Directory (AD) mit den Windows 2000 Server-Editionen im Jahr 2000 als Nachfolger des Windows-NT-Directory eingeführt. Und wie sich einige von Ihnen erinnern, war IT-Sicherheit zu diesem Zeitpunkt nicht immer das wichtigste Thema. Dies führte vor allem zu unsicheren Konfigurationen, wie z. B. zahlreiche Zuweisungen von Benutzerkonten zu privilegierten Gruppen wie zu den Domain Admins.

Im Laufe der Jahre wurden jedoch schlechte AD-Sicherheitspraktiken reduziert, da es zum Standard wurde, dass AD besser geschützt werden muss. So wurde es beispielsweise zur gängigen Praxis, eine minimale Anzahl dedizierter Domain-Admin-Konten einzurichten, die nur innerhalb ihrer zulässigen Security-Boundary arbeiten dürfen. Warum erzählen wir Ihnen das? Weil es sich bei Cloud-Assessments manchmal so anfühlt, als ob man mit einer Zeitmaschine ins Jahr 2000 zurückreist, um dieselben Fehler zu sehen, die in dieser Zeit gemacht wurden.

Die Top-10 risikoreichsten Konfigurationen

Die folgende Top-10-Liste bringt Sie “zurück in die Zukunft”, indem diese grundlegende riskante Konfigurationen oder Praktiken beschreibt, die vermieden werden sollten. Ausserdem finden Sie eine Liste mit Links und Quellen für weiterführende Informationen. Die identifizierten Risiken basieren auf unseren Erfahrungen aus verschiedenen Microsoft Cloud Assessments.

Risk 1 – Reguläre Benutzerkonten, welche der Global Administratoren Rolle zugewiesen sind

Vergleicht man alle unsere Microsoft Cloud-Assessment der letzten Jahre, so hatten 8 von 10 ein oder mehrere reguläre Benutzerkonten, die permanent an Tier-0 Rollen in Azure AD zugewiesen waren. Tier-0-Rollen in der Cloud können als alle Rollen oder Entitäten interpretiert werden, die direkt oder indirekt zu Global Adminstrators werden können, wie zum Beispiel Mitglieder der Privilege Role Administrators oder Identitäten mit der AppRole RoleManagement.ReadWrite.Directory. Bei den entdeckten regulären Benutzerkonten handelte es sich hauptsächlich um Hybrid Identities, die aus dem Active Directory synchronisiert wurden. Der Grund für die Zuordnung war oft Bequemlichkeit, Unwissenheit oder die Angst, aus dem Azure AD ausgesperrt zu werden. Überraschenderweise versuchen die Unternehmen üblicherweise, dem Active Directory-Least-Privilege-Konzept zu folgen, indem sie beispielsweise ein dediziertes Konto verwenden oder sogar das Microsoft-Tiering-Modell zur Verwaltung Ihres Active Directory’s anwenden. Für die Microsoft-Cloud wurde dieses Prinzip jedoch nicht mehr angewandt.

Die Verwendung regulärer Benutzerkonten für die Verwaltung von Tier-0 vergrössert die Angriffsfläche unnötig und kann zu einer Kompromittierung des Microsoft-Cloud-Tenants führen. Angreifer werden versuchen, die Sicherheitsausnahmen zu missbrauchen, die meist für reguläre Benutzerkonten gelten, z. B. unlimitierter Internetzugang, Passwortrücksetzfunktionen, Social Engineering, laxe Härtungsmassnahmen, MFA-Fatigue Attack und weitere. Daher empfehlen wir, sich an das Least Privilege Modell zu halten, indem Sie dedizierte Cloud-only-Benutzerkonten für die Verwaltung der Microsoft Cloud verwenden. Die Tier-0 Cloud-Only-Benutzerkonten müssen Teil eines Joiner-Mover-Leaver (JML)-Prozesses sein. Ein manueller JML-Prozess, z. B. in Form eines Tickets, reicht aus, um zu vermeiden, dass ein IAM-System zu Tier-0 hochgestuft werden muss, da die Anzahl der Tier-0-Benutzerkonten gering gehalten werden sollte. Das Argument, dass Hybrid Identities bereits in den JML-Prozess einbezogen sind, ist nicht immer stichhaltig. Es kann zu dem oben beschriebenen Szenario führen, bei welchem reguläre Benutzerkonten Tier-0 Entitäten zugewiesen werden, da Active Directory Tier-0-Benutzer meist nicht in die Cloud synchronisiert werden. Angenommen, Azure AD Hybrid Identities müssen zwingend aus einem Grund für Tier-0 Cloud Berechtigungen verwendet werden. In diesem Fall empfehlen wir, ein dediziertes Active Directory-Identitätsmuster für die Hybrid Idenities zu erstellen und dieses wiederum in einen JML-Prozess einzubinden. Auf diese Weise können für diese Hybrid Identities restriktive Zugriffsrichtlinien im AD und in der Cloud festgelegt werden. Zusätzlich empfehlen wir die Verwendung von der Microsoft Cloud Lösung Privilege Identity Management (PIM) für privilegierte Konten. Um die Rolle zu aktivieren, sollte Multifaktor-Authentifizierung (MFA) verwendet werden.

Weitere Informationen:

• Introduction to delegated administration and isolated environments
• Securing privileged access for hybrid and cloud deployments in Azure AD
• Privilege Identity Management
• Securing privileged access
• Azure Attack Paths: Azure AD Roles
• MITRE ATT&CK tectics and rechniques
• AAD & M365 kill chain
• _wald0 Tier-0 definition examples

Risk 2 – Schwaches Azure AD Service Principal und Cloud Application Management

Service Principals repräsentieren die Identität einer Microsoft Cloud Application. Ein neu angelegter Azure AD-Tenant mit entsprechenden Lizenzen hat etwa 390 vorkonfigurierte Service Principals, welche die Cloud-Application wie Microsoft Teams, SharePoint Online, Exchange Online oder Microsoft Graph repräsentieren. Wenn beispielsweise eine benutzerdefinierte Microsoft-Cloud-Anwendung im Azure AD-Portal oder über die API erstellt wird, werden zwei Entitäten erstellt: eine Application und ein Service Principal. Die Application Objekt ist die globale Repräsentation der Unternehmens-Applikation für alle Tenants, während der Service Principal die lokale Repräsentation eines bestimmten Tenants ist. Service Principals oder Managed Identities in Azure ARM werden auch für die IaaS- und PaaS-Dienste von Azure genutzt, um beispielsweise für neue Dienste, bestehende Dienste oder allgemein für Automatisierungsaufgaben. Die Kompromittierung von Service Principals ist ein interessantes Ziel für Angreifer. Service Principals können mit einer Vielzahl von Berechtigungen ausgestattet werden und sind ideal für Privilege Escalation Szenarios oder Backdooring von Azure AD oder Azure ARM.

Cloud-Application werden durch die Zusammenstellung verschiedener IaaS- und PaaS-Services erstellt. Ein Application in der Microsoft Cloud ist in der Regel ein Service Principal zugewiesen. Wenn eine Application beispielsweise Zugriff auf eine Datenbank benötigt, wird dem Service Principal der Anwendung der Zugriff auf die Datenbank gewährt. Anwendungsnutzer greifen in der Regel über OAuth 2.0 Authorisation Flows auf Cloud-Applications zu. Die Erteilung von Berechtigungen für Applications kann kritisch werden, da einige Applications hoch privilegierte Zugriffsrechte haben können.

Häufig bei unseren Assessments finden wir privilegierte Service Principals oder Cloud-Application mit einem alltäglichen Benutzerkonto als Owner. Ein Owner kann den Service Principal verwalten oder sich als solcher ausgeben. Wenn also ein Benutzer eine Anwendung mit höheren Privilegien als der Benutzer selbst steuern kann, ist eine Privilege Escalation über den Service Principal möglich. Neben der Ownership stellen wir auch häufig fest, dass zugewiesene Berechtigungen nicht aktiv überwacht werden. Häufig finden wir über privilegierte Service Principals mit Anwendungsrollenrechten wie .ReadWrite.All, .ReadWrite.Directory oder direkte Zuweisungen zu den Rollen Global Administrator oder Exchange Administrator. Die Überprüfung, wer Applications verwalten kann, einschliesslich Applications- und Delegationsberechtigungen, ist in einer Microsoft-Cloud-Umgebung von entscheidender Bedeutung, um unerwünschte Credential-Pivoting-Pfade zu verhindern. Beispielsweise sollte der Besitzer von privilegierten Service Principals oder Applications niemals ein reguläres Benutzerkonto sein.

Weiterführende Informationen:

• Azure Privilege Escalation via Azure API Permissions Abuse
• Azure Privilege Escalation via Service Principal Abuse
• Managed Identity Attack Paths, Part 1-3: Automation Accounts
• Azure AD built-in roles

Risk 3 – Zu viele Administratoren

Allzu oft ist ein Ergebnis eines Microsoft Cloud Assessment, dass der Microsoft Cloud Tenant zu viele Administratoren hat. Sei es in Azure AD, Azure ARM, Azure DevOps oder M365. Die Gründe dafür sind vielfältig, aber einer der Gründe für diese Praxis ist meistens, dass verschiedene IT-Teams mit unabhängigen Projekten und engen Zeitplänen die Microsoft Cloud administrieren. Das Ergebnis sind viele Administratoren, die beispielsweise Conditional Access, Azure AD-Berechtigungen, Service Principals, Azure ARM-Ressourcen und so weiter konfigurieren müssen. Silos sollten in der Cloud keinen Platz haben, da alles viel stärker miteinander verbunden ist als bei On-Premises IT Lösungen. Fehlkonfigurationen können schwerwiegende Folgen haben. Daher ist es wichtig, einen Plan zu haben, um zu vermeiden, dass projektbezogene Benutzerkonten zufälligen Rollen zugewiesen werden, ohne die Auswirkungen der Berechtigungen oder die daraus resultierenden Zugriffsrechte zu verstehen. Ähnlich wie bei Active Directory sollte die Anzahl der Administratoren auf ein Minimum beschränkt werden.

Weiterführende Informationen:

• Least privileged roles by task in Azure Active Directory
• Understand roles in Azure Active Directory
• Classic subscription administrator roles, Azure roles, and Azure AD roles
• Microsoft cloud Adoption Framework for Azure

Risk 4 – Riskante Ausnahmen für Global Administrators oder andere privilegierte Rollen

Wir haben in jedem Microsoft-Cloud-Assessment Ausnahmen gefunden, insbesondere für Global Administrator in Conditional Access Regeln. Leider ist die Begründung allzu oft die Umgehung von Sicherheitskontrollen oder ein Shortcut, um Zeit zu sparen. Insbesondere für privilegierte Rollen wie Global Administrator sollten keine Ausnahmen gemacht werden, mit einer Ausnahme: Breakglass-Konten.

Manchmal werden für reguläre Benutzerkonten Ausnahmen benötigt. In diesem Fall empfehlen wir die Verwendung der Microsoft Cloud-Funktion Access Review, sobald eine Ausnahme erforderlich ist. Zugriffsüberprüfungen können für eine bestimmte Azure AD-Gruppe festgelegt werden, die beispielsweise eine monatliche Überprüfung aller Gruppenmitglieder, die Teil der Ausnahme sind, erzwingt. Das Ziel sollte sein, die Ausnahme in naher Zukunft durch eine sicherere Lösung zu ersetzen.

Weiterführende Informationen:

• Plan an Azure Active Directory access reviews deployment
• Common Conditional Access policies
• The Attackers Guide to Azure AD Conditional Access
• Manage emergency access accounts in Azure AD

Risk 5 – Fehlende Management Einschränkungen für privilegierte Rollen

Die sichere Cloud-Verwaltung wurde häufig in unseren Assessments als nicht vorhanden eingestuft. Wir kamen häufig zum Schluss, dass die Anmeldung mit dem Global Administrator oder anderen privilegierten Rollen von jedem Gerät aus möglich war. So wurde beispielsweise nur das M365-Portal durch Conditional Access eingeschränkt, nicht aber das Azure AD Portal oder der alte Azure AD Graph Explorer. Warum? Weil häufig das Projektteam Conditional Access einrichtete z.B. nur für M365, nicht aber für Azure ARM zuständig war (Silo Mentalität, welche vermieden werden sollte). In der Vergangenheit gab es nur wenige Möglichkeiten, der Management Zugriff auf die Microsoft Cloud zu beschränken. Wir empfahlen meistens, die Verwaltung nur von einem bestimmten Unternehmens-Admin-Proxy mit einer dedizierten öffentlichen IP-Adresse aus zuzulassen. Heutzutage lässt sich mit Conditional Access jedoch festlegen, auf welchem Gerät sich ein Benutzer mit einer bestimmten Rolle anmelden darf. Daher empfehlen wir dringend Privileged Access Workstations (PAW) in Kombination mit Conditional Access zu verwenden, zumindest für Tier-0-Administratoren.

Weiterführende Informationen:

• Securing devices as part of the privileged access story
• Conditional Access: Filter for devices
• Abusing Azure AD SSO with the Primary Refresh Token
• Death from Above: Lateral Movement from Azure to On-Prem AD

Risk 6 – Wissenslücken

Bei Assessments stellen wir oft fest, dass das zuständige IT-Personal Wissenslücken in Bezug auf die Funktionsweise der Microsoft Cloud hat. Das geht Hand in Hand mit der Silo-Mentalität, die unserer Meinung nach in einem Cloud-Setup nicht förderlich ist. Ein häufig missverstandenes Beispiel sind die verschiedenen Rollentypen in der Microsoft-Cloud. Zusammengefasst kennt die Microsoft-Cloud-Architektur vier Hauptorte, an denen Rollen zu finden sind. Der erste Ort ist der Azure Resource Manager (ARM), der IaaS- und PaaS-Workloads hostet. Die Rollen an diesem Ort werden als Azure RBAC-Rollen bezeichnet und gewähren Zugriff auf verschiedene Dienste wie Virtual Machines, Storage Accounts, Key Vaults und mehr. Der zweite Standort ist Azure AD. Azure AD verwaltet übergeordnete Rollen, welche direkten und indirekten Zugriff auf ARM- und SaaS-Anwendungen haben. Die mächtigste Rolle in der Microsoft-Cloud, der Global Administrator, ist hier zu finden. Diese Rolle kann alle Entitäten in einem Tenant kontrollieren. Die meisten Rollen in Azure AD haben den Zweck, M365 zu verwalten. Der dritte Standort sind Rollen innerhalb von Cloud-Anwendungen. Als Beispiel in Cloud Applications wie Microsoft Graph, Exchange Online, Defender for Endpoint oder Azure DevOps. In solchen Rollen können manchmal Azure AD-Rollen, Gruppen, Service Principals oder Benutzer als Mitglieder gefunden werden. Der letzte Ort ist das Azure EA-Portal, in dem die Subscriptions für ARM verwaltet werden, wenn Ihr Unternehmen eine Enterprise Agreement hat. Der Enterprise Administrator und der Account Owner im EA-Portal haben vollen indirekten Zugriff auf alle Subscriptions, welche vom EA-Portal verwaltet werden. Die Rollen in Cloud Applications und des EA-Portals werden oft übersehen und fehlen daher in den Prozessen vom Identity & Access Management (IAM). Angreifer können solche Rollen nutzen, um unbemerkt zu bleiben, und können so weitreichenden Zugang zu verschiedenen Cloud-Diensten erhalten. Wir empfehlen daher, solche Rollen in die IAM-Prozesse aufzunehmen. Für das EA-Portal sollten nur dedizierte Microsoft Cloud Work Accounts verwendet werden, und es sollte sichergestellt werden, dass ähnliche organisatorische und sicherheitstechnische Massnahmen wie bei anderen privilegierten Konten, z. B. Global Administrators, angewendet werden.

Weiterführende Informationen:

• Microsoft Security Best Practices
• Enterprise billing and Azure AD tenants
• Security considerations of Azure EA management and potential privilege escalation

Risk 7 – AAD Connect Missverständnisse

AAD Connect ist eine lokale Lösung, die Identitäten aus Active Directory mit der Microsoft Cloud synchronisieren kann. Die synchronisierten Objekte in der Cloud werden als Hybrid Identity bezeichnet. Der JML-Prozess, der bereits in der bestehenden lokalen IAM-Lösung implementiert ist, ist somit angeblich gewährleistet. Leider ist dies nicht wirklich der Fall, da AAD Connect nicht alle Cloud-Entitäten wie Cloud-Only-Benutzer, Gastkonten und Service Principals verwalten kann. Diese Entitäten werden meist vergessen und erfordern ebenfalls einen JML-Prozess. Daher sollte ein Konnektor, vorzugsweise über die Microsoft Graph API, eingerichtet werden, um nicht synchronisierte Entitäten abzudecken. Ausserdem muss die AAD Connect-Lösung als Tier-0-Lösung behandelt und sollte daher nur von Tier-0-Administratoren des Active Directory verwaltet werden.

Weiterführende Informationen:

• Unnoticed sidekick: Getting access to cloud as an on-prem admin
• Azure AD Connect for Red Teamers
• Azure Active Directory Pass-Through Authentication Flaws

Risk 8 – DevOps Lösungen und ihre versteckten Risiken

Im Artikel Attack Path Analysis – Vorteil gegenüber Angreifern verschaffen haben wir einen möglichen Attack Path beschrieben, welcher ein reguläres Benutzerkonto in Azure DevOps missbraucht, um Zugriff auf einen privilegierten Service Principal zu erhalten. Um solche Attack Paths zu verringern, empfehlen wir sicherzustellen, dass ähnliche organisatorische und sicherheitstechnische Massnahmen wie bei anderen privilegierten Konten, z. B. Global Administrators, angewendet werden. Überdies sollte die verwendete DevOps-Lösung gemäss den verfügbaren Sicherheitsempfehlungen gehärtet werden.

Weiterführende Informationen:

• Attack Path Analysis – Vorteil gegenüber Angreifern verschaffen
• Security groups, service accounts, and permissions in Azure DevOps
• Security best practices
• Azure DevOps: Recommended Practices for Secure Pipelines
• Microsoft Security Code Analysis
• Development security strategy

Risk 9 – Fehlende Anwedungen vom Clean Source Principal

“Beim Clean Source Principle müssen alle Sicherheitsabhängigkeiten genauso vertrauenswürdig sein wie das zu sichernde Objekt.” (Microsoft – Clean source principle). In On-Premises-Umgebungen und erst recht in der Cloud wird dieses grundlegende Prinzip oft vergessen/ignoriert. Eine häufig vorgebrachte Begründung bei unseren Assessments lautet: “Unser Microsoft Cloud Tenant ist noch nicht produktiv”, was offensichtlich gegen das eben genannte Prinzip verstösst. Ein Azure AD Tenant ist unserer Meinung nach produktiv, sobald der Azure AD Tenant auf der Microsoft Website angefordert wird. Daher sollten die Prinzipien wie Least Privilege und Clean Source von Anfang an beachtet werden. Wer kann sonst garantieren, dass der Tenant nicht während des Einrichtungsprozesses oder der Pilotphase kompromittiert wurde?

Weiterführende Informationen:

• Clean source principle

Risk 10 – Fehlende Cloud-Verteidiger/Angreifer Denkweise

Die alte Sicherheitsarchitektur vor dem Cloud Computing ähnelt der Struktur einer mittelalterlichen Burg. Alles befand sich in einem vertrauenswürdigen internen Netz, und alle Sicherheitskonfigurationen waren um den Burgrand herum angeordnet. Mit Cloud Computing ist diese Architektur mehr und mehr obsolet geworden. Ausserdem ist das Konzept der Perimetersicherheit nicht praktikabel, wenn die Dienste auf einer gemeinsam genutzten, mit dem Internet verbundenen Infrastruktur laufen. Um diese neuen Herausforderungen zu bewältigen, sind innovative Modelle für die Sicherheitsarchitektur und eine Änderung der Denkweise erforderlich.
Ein Beispiel für eine fragwürdige Denkweise ist, wenn die Begründung für eine Sicherheitsfeststellung lautet: “Aber Microsoft kümmert sich schon darum”. Leider ist mit einer solchen Denkweise die Wahrscheinlichkeit einer Kompromittierung hoch. Vereinfacht ausgedrückt bedeutet die Kultivierung der Denkweise eines Verteidigers, dass man versteht, wer für was in einer Cloud-Umgebung verantwortlich ist. Laut Microsoft sind “Cloud-Dienste eine geteilte Verantwortung”. Aus der Sicht von Microsoft bedeutet “gemeinsam”, dass Microsoft die Plattform und die Tools zur Verfügung stellen, die Konfiguration, Überwachung und Sicherung des Tenants obliegt, aber Ihnen. Daher ist es von entscheidender Bedeutung, ein umfassendes Verständnis dafür zu haben, wie ein Microsoft Cloud Tenant gesichert, überwacht und verwaltet werden muss. Regelmässige Konfigurationsüberprüfungen und -anpassungen mit der Unterstützung von Microsoft-Sicherheitstools wie Microsoft Secure Score, Defender for Cloud Recommendations, Azure Monitor Workbooks und anderen werden empfohlen. Auch die Verwendung von Assessmenttools von Drittanbietern wie AzureHound, ROADtools, AzureADAssessment oder AAD Internals, um nur einige zu nennen, kann bei einem Assessment der Sicherheitslage eines Azure AD Tenant von Nutzen sein.

Weiterführende Informationen:

• Shared responsibility in the cloud
• Attack Path Analysis – Vorteil gegenüber Angreifern verschaffen
• Introducing the Adversary Resilience Methodology
• Defender’s Mindset

Assessment Tools:

Der Grundsatz des Clean Source Principal sollte beachtet werden. Verwendete Tools sollten zuerst überprüft und möglichst mit den geringsten benötigten Privilegien verwendet werden.

• AzureHound
• BloodHound Enterprise
• ROADtools
• Azure Stormspotter
• Azure AD Exporter
• Azure Review Checklists
• Azure Threat Research Matrix
• Azure ARM Governance Visualizer
• Azure Tenant Security Solution
• MicroBurst: A PowerShell Toolkit for Attacking Azure
• BloodHound Attack Research Kit
• Microsoft Azure AD Assessment
• AAD Internals

Fazit

Die präsentierten Top-Ten-Risiken sind nicht als abschliessend zu betrachten, da die Liste um weitere risikoreiche Aspekte ergänzt werden könnte, z. B. fehlende Sicherheitsüberwachung, Unkenntnis über Credential Pivoting und Extraktion von Access- oder Refresh-Tokens aus Browser-Sitzungen. Nichtsdestotrotz wollten wir Ihr Bewusstsein für bewährte Sicherheitspraktiken schärfen, denn in der Cloud ist die Einhaltung dieser Praktiken noch wichtiger als im On-Premises Umfeld. Die Befolgung von Sicherheitsstandards ist ein guter Ratschlag für den Betrieb von Cloud-Plattformen, da diese ohne Härtungsmassnahmen und kontinuierliche Sicherheitsanpassungen standardmässig nicht sicher sind. Alles in allem unterscheiden sich die Grundlagen der Sicherung einer Cloud-Umgebung nicht wesentlich von der Sicherung einer On-Premises Umgebung. Daher ist es wichtig, die Fehler der Vergangenheit nicht zu wiederholen und in ein solides Fundament zu investieren, bevor die umfangreichen und lukrativen Möglichkeiten einer Cloud-Plattform genutzt werden.

• Anthropic’s philosopher says we don’t know for sure if AI can feel (businessinsider.com)
• From Chatbots to Dice Rolls: Researchers Use D&D to Test AI’s Long-term Decision-making Abilities (today.ucsd.edu)
• I replaced my ChatGPT subscription with a 12GB GPU and never looked back (xda-developers.com)
• I had ChatGPT write my resume, LinkedIn Summary and cover letter then asked Gemini if I would get the job (tomsguide.com)
• AI-induced cultural stagnation is no longer speculation it’s already happening (theconversation.com)
• Cyberwarfare as Low-Intensity Conflict: Structural Coercion and the Exploitation of U.S. Instability (krypt3ia.wordpress.com)
• Vulnerabilities Surge, But Messy Reporting Blurs Picture (darkreading.com)
• Hackers get hacked, as BreachForums database is leaked (bitdefender.com)
• Researchers Expose WHILL Wheelchair Safety Risks via Remote Hacking (securityweek.com)
• Scott Adams, ‘Dilbert’ creator who poked fun at bad bosses, dies at 68 (washingtonpost.com)
• Enshittification is ruining everything online (malwarebytes.com)
• Pulling a New Proof from Knuth’s Fixed-Point Printer (research.swtch.com)
• Can AI do your job? See the results from hundreds of tests. (washingtonpost.com)
• Trump suggests US used cyberattacks to turn off lights in Venezuela during strikes (politico.com)
• Anna’s Archive Loses .Org Domain After Surprise Suspension (torrentfreak.com)
• AI may not need massive training data after all (sciencedaily.com)
• Astronomers Appear to Have Caught a Star Splitting In Half, With Catastrophic Results (futurism.com)
• Scammers in China Are Using AI-Generated Images to Get Refunds (wired.com)
• Lights, camera, algorithm: Why Indian cinema is awash with AI (bbc.com)
• Are We Ready to Be Governed by Artificial Intelligence? (schneier.com)