Protokollanalyse über Azure: SMBv1 und Kerberos RC4 aufspüren

Alte Protokolle sterben in Windows-Umgebungen selten von allein. SMBv1 und Kerberos RC4 hängen oft noch in Netzwerken herum – meist wegen einer Legacy-Appliance, eines falsch konfigurierten Service-Accounts oder eines vergessenen Skripts. Beide sind aus Security-Sicht heikel: SMBv1 ist seit WannaCry der Klassiker unter den ausrottungswürdigen Protokollen, und RC4 ist eine schwache Kerberos-Verschlüsselung, die als Einstieg für Kerberoasting dient. Ab den Juli-2026-Sicherheitsupdates zieht Microsoft die Zügel an und stellt Domain Controller standardmäßig auf AES um – wer RC4-Abhängigkeiten bis dahin nicht kennt, riskiert Ausfälle bei Legacy-Systemen.

Bevor Du remediieren kannst, musst Du wissen, wer noch unsicher spricht. Genau das leistet dieser Artikel: Wir sammeln die relevanten Windows-Events zentral in einem Azure Log Analytics Workspace ein, werten sie per KQL aus und übersetzen die Ergebnisse in konkrete Remediation-Schritte. Der Fokus liegt auf zwei Protokollen – SMBv1 und Kerberos RC4 –, das Vorgehen lässt sich aber auf weitere „Weak Protocols" wie NTLMv1 übertragen.

Ziel und Grundidee

Die Idee ist simpel: Statt auf jedem einzelnen Server lokal in den Event-Logs zu wühlen, leiten wir die sicherheitsrelevanten Events aller Server zentral nach Azure. Dort liegen sie in einer einzigen Event-Tabelle und lassen sich mit KQL über die gesamte Umgebung hinweg abfragen. So findest Du in einer Query alle Clients, die noch SMBv1 sprechen, oder alle Service-Accounts, die noch RC4-Tickets bekommen.

Der Datenfluss sieht dabei so aus:

1. Ein Log Analytics Workspace dient als zentrale Datenplattform.
2. Alle relevanten Server (vor allem Domain Controller und Fileserver) werden per Azure Arc eingebunden.
3. Der Azure Monitoring Agent (AMA) liest die konfigurierten Event-Kanäle lokal aus.
4. Eine Data Collection Rule (DCR) legt zentral fest, welche Event-IDs überhaupt eingesammelt werden.
5. In Netzsegmenten ohne Internetzugang bündelt ein Gateway-Server die ausgehende Kommunikation.

Voraussetzung ist eine eigene Resource Group, in der Du einen Workspace anlegen und Ressourcen hinzufügen darfst. Der Account, mit dem Du arbeitest, braucht entsprechende Berechtigungen zur Erstellung von Ressourcen in dieser Resource Group – ohne die schlägt das Onboarding fehl.

Die Azure-Infrastruktur aufbauen

Der Weg von „nichts" zu „auswertbaren Events" läuft in mehreren Schritten. Ich beschreibe sie hier kompakt, weil der Schwerpunkt auf der Analyse liegt.

Log Analytics Workspace einrichten

Der Log Analytics Workspace ist die zentrale Datenplattform: Hier landen alle gesammelten Events und werden per KQL auswertbar. Alle nachgelagerten Komponenten verweisen auf diesen Workspace als Ziel.

• Schritt 1: Eine Subscription bereitstellen oder eine bestehende mit den nötigen Berechtigungen nutzen.
• Schritt 2: Innerhalb der Subscription eine Resource Group für den Workspace anlegen.
• Schritt 3: Den Log Analytics Workspace innerhalb dieser Resource Group einrichten – dorthin werden später alle Protokolle gefördert.

Server per Azure Arc onboarden

Über Azure Arc werden die zu überwachenden Server (insbesondere alle DCs und relevante Fileserver) ins Azure Resource Management eingebunden. Damit stehen sie als verwaltete Ressourcen zur Verfügung und lassen sich zentral mit Agenten versorgen – egal ob sie On-Premises, in einem fremden Rechenzentrum oder in einer anderen Cloud laufen.

Der Ablauf im Portal: unter Azure Arc die Option Add/Create Machines → Add Machines wählen, Add a Single Server → Generate Script aufrufen und die Ziel-Resource-Group auswählen. Das erzeugte Skript kopierst Du auf die jeweilige Maschine und führst es dort aus – Login erfolgt mit dem berechtigten Account. Nach einem Refresh im Azure Portal taucht der Server als verwaltete Ressource auf.

Über „Add resources" auf der Azure-Arc-Startseite beginnt das Onboarding neuer Maschinen.

Für einen einzelnen Server wählst Du „Add a single server → Generate script".

Subscription, Ziel-Resource-Group und Region festlegen – der Hinweis oben macht deutlich, dass der Account die Resource-Provider registrieren bzw. Ressourcen anlegen können muss.

Praxis-Tipp: Wenn Azure Arc auf einem Server installiert ist, kannst Du über den Azure-Arc-Agent direkt Microsoft Defender ausrollen – zwei Fliegen mit einer Klappe.

Gateway-Server für abgeschottete Segmente

In Netzsegmenten ohne direkten Internetzugang wird ein Azure Arc Gateway bzw. Log Analytics Gateway vorgeschaltet. Dieser bündelt die ausgehende Kommunikation aller Agenten zu Azure und reduziert die nötigen Firewall-Freigaben auf eine einzige zentrale Komponente.

Alle Server mit Arc-Agent senden ihre Eventlogs an diesen Gateway-Server, der sie nach Azure weiterreicht. Die Kommunikation läuft über Port 8080; bei Bedarf trägst Du zusätzlich einen Proxy ein.

Das Log Analytics Gateway wird über den OMS-Gateway-Setup-Assistenten auf dem ausgewählten Server installiert.

Standardmäßig kommuniziert das Gateway über Port 8080; bei Bedarf lässt sich hier zusätzlich ein HTTP-Proxy hinterlegen.

Azure Monitoring Agent (AMA) installieren

Auf jedem onboarded Server wird der AMA über Azure Arc als Extension ausgerollt. Der Agent liest die konfigurierten Event-Kanäle lokal aus und übermittelt die Events an den Workspace. Bei der Installation trägst Du die IP-Adresse des Gateway-Servers mit Port 8080 ein und schließt mit Review & Create ab.

Auf der onboarded Maschine unter „Extensions" eine neue Extension hinzufügen.

Aus dem Katalog den „Azure Monitor Agent for Windows (Recommended)" auswählen.

Der AMA ersetzt die Legacy-Agents und liefert die Guest-OS-Daten an Azure Monitor – mit „Next" geht es weiter zur Installation.

Data Collection Rule (DCR) anlegen

Die DCR ist das Herzstück der Datensammlung: Sie definiert zentral, welche Event-Logs der AMA einsammeln soll. Sie wird einmal gepflegt und lässt sich beliebig vielen Servern zuweisen. Die gesammelten Events landen in der Event-Tabelle des Workspace.

Für unsere Analyse brauchen wir diese Kanäle:

In der Resource Group Create wählen und nach Data Collection Rule suchen. Der Endpoint kann leer bleiben.

Im Marketplace nach „Data Collection Rules" suchen und die Microsoft-Kachel auswählen.

Subscription auswählen und über „Create" die Anlage der DCR starten. Wichtig ist, dass Du die X-Path-Queries für die gewünschten Event-IDs einträgst – nur so werden die Events gefiltert und eingesammelt. Später lassen sich jederzeit weitere Kanäle ergänzen. Eine fertige Vorlage mit den passenden DCR-Regeln für unsichere Protokolle findest Du auf GitHub:

https://raw.githubusercontent.com/jamesory/Insecure-Protocols/7a54255fcfb24c71d07a47632e53afb27111cc77/DCR%20Rules%20for%20Insecure%20Protocols

Nach Review + Create solltest Du ca. 30 Minuten warten, bis die Einrichtung durch ist und die ersten Events eingesammelt wurden.

Wichtige Voraussetzung serverseitig: Damit SMBv1-Events (EventID 3000) überhaupt entstehen, muss auf den Fileservern das SMBv1-Auditing aktiv sein. Das aktivierst Du mit Set-SmbServerConfiguration -AuditSmb1Access $true. Ohne dieses Auditing bleibt der Kanal leer.

Events abfragen

Sobald Daten fließen, geht es an die Auswertung: In den Workspace wechseln → Logs → neue Query → auf KQL umstellen → Query ausführen. Über das Tabellen-Icon lassen sich die Ergebnisse direkt als Tabelle anzeigen. Die eigentlichen Abfragen für die beiden Protokolle folgen in den nächsten Abschnitten.

Als Beispiel für ein typisches Abfrageergebnis: Die NTLMv1-Query (EventID 4624) liefert eine Tabelle, in der ein Service-Account und die Computer-Accounts der Domain Controller besonders häufig auftauchen.

SMBv1 aufspüren

Grundkonzept: SMB ist Client-Server

Bei SMB gibt es immer zwei Seiten:

• Client – wer den Zugriff initiiert (z. B. „Ich möchte \\fileserver\share\doc.xlsx öffnen").
• Server – wer den Share anbietet und den Zugriff bedient (der Fileserver).

Das SMBv1-Audit-Event (EventID 3000) wird serverseitig geloggt. Der Server protokolliert sinngemäß: „Achtung, hier hat mir gerade jemand per SMBv1 Hallo gesagt." Der eigentliche „Täter" – das Gerät, das noch SMBv1 spricht und behoben werden muss – ist also der Client, nicht der loggende Server.

Die KQL-Abfrage für SMBv1

Event
| where TimeGenerated >= ago(30d)
| where EventLog == "Microsoft-Windows-SMBServer/Audit"
| where EventID == 3000
| extend ClientAddress = extract(@'(?i)(?:client address|clientadresse|client-adresse)[:\s]+([A-Za-z0-9\.\-_]+)', 1, RenderedDescription)
| extend ClientAddress = iff(isempty(ClientAddress), "UNKNOWN", ClientAddress)
| summarize
    Count = count(),
    FirstSeen = min(TimeGenerated),
    LastSeen = max(TimeGenerated),
    Servers = make_set(Computer, 20)
  by ClientAddress
| order by Count desc

Die Abfrage holt alle SMBv1-Audit-Events der letzten 30 Tage, extrahiert die Client-Adresse aus dem Klartext des Events (der extract-Ausdruck ist bewusst zweisprachig gebaut, damit er auch bei deutschsprachigen Windows-Servern greift) und aggregiert dann pro Client. Das Ergebnis ist eine kompakte Liste: ein Client pro Zeile, mit Zugriffszahl, Zeitfenster und den kontaktierten Servern.

Die Spalten im Detail

Konkrete Beispiele

Typisches Abfrageergebnis: REMOTE01 sticht mit 628 Zugriffen heraus, darunter einzelne Treffer wie VEEAM11, APPL20 und ein DC in der Client-Rolle. (Server-Hostnamen und IPs sind hier bewusst unkenntlich gemacht.)

REMOTE01 → 628 Zugriffe → Server: ad-addc-p… Zu lesen als: „Der Host REMOTE01 hat 628 Mal per SMBv1 auf einen DC zugegriffen, beginnend am 16.4. und zuletzt heute." Das kontinuierliche Muster über die gesamte Messperiode deutet auf einen laufenden Prozess oder ein Logon-Script auf REMOTE01 hin. Der Handlungsbedarf liegt bei REMOTE01 – der DC ist nur der „Bote" und muss nichts ändern (der DC kann auch SMB3, nur der Client kann nur SMB1).

Auf REMOTE01 selbst findest Du die Ursache in den Client-Logs. Event 32000 enthält den genauen Share-Pfad, auf den SMBv1 gesprochen wird – das ist der „Silver Bullet" zur Identifikation:

Get-WinEvent -LogName "Microsoft-Windows-SMBClient/Security" -MaxEvents 50 |
  Where-Object { $_.Id -eq 32000 } |
  Select-Object TimeCreated, @{N='Share';E={$_.Properties[1].Value}},
          @{N='Reason';E={$_.Properties[2].Value}}

AD-ADDC-P01 → 2 Zugriffe (DC als Client!) Zu lesen als: „Der DC AD-ADDC-P01 hat selbst 2 Mal per SMBv1 auf einen anderen Host zugegriffen." Hier ist der DC ausnahmsweise in der Rolle des Clients – das ist der ungewöhnliche, erklärungsbedürftige Fund. Ein DC, der SMBv1 gegen einen anderen DC spricht, sollte normalerweise nicht vorkommen. Mögliche Ursachen:

1. DFSR-Replikation im Legacy-Mode – unwahrscheinlich bei modernem Setup, möglich bei migrierten Umgebungen mit FRS-Überbleibseln.
2. Administrativer Zugriff – ein Admin hat lokal etwas gemacht, das SMB1 triggert (altes Skript, Legacy-Tool).
3. Monitoring-/Management-Agent auf dem DC (z. B. SCOM mit Legacy-Modulen, veralteter AV-Scanner).
4. GPO-Verarbeitung mit SMB1-Fallback – sehr selten, aber möglich bei sehr großen SYSVOL-Shares.

Nur zwei Events deuten auf einen seltenen, eventgetriebenen Vorgang hin (z. B. Reboot, Logon eines bestimmten Admins, Scheduled Task). Untersuchen ja, aber nicht volumenkritisch. Auf dem DC prüfst Du den lokalen Zustand:

# Prüfen, ob SMB1-Client/Server noch aktiv sind
Get-SmbServerConfiguration | Select-Object EnableSMB1Protocol, EnableSMB2Protocol
Get-SmbClientConfiguration | Select-Object EnableSMB1Protocol
Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol

# Event-Logs auf dem DC selbst
Get-WinEvent -LogName "Microsoft-Windows-SMBClient/Security" -MaxEvents 20 |
  Where-Object { $_.Id -eq 32000 }

172.19.9.247 → 1 Zugriff → Server: printserver.* Zu lesen als: „Ein unbekanntes Gerät mit IP 172.19.9.247 hat einmal per SMBv1 auf den Printserver zugegriffen." IP-only-Einträge (also ohne DNS-Namen) deuten typischerweise auf Geräte ohne saubere DNS-Registrierung hin:

• Netzwerkdrucker / MFPs mit SMB-Scan-Funktion
• Alte NAS-Systeme (QNAP, Synology mit Legacy-Firmware, Buffalo, ReadyNAS)
• IoT/OT-Geräte (Alarm-Panels, Zeiterfassung, Türsteuerungen)
• Embedded Industrie-PCs

Unterschiedliche Subnetze (z. B. 10.200.100.x und 172.19.9.x) verraten, dass die Geräte aus verschiedenen Netzsegmenten stammen. Solche IPs gibst Du an den Netzwerkverantwortlichen weiter – für ARP-Lookup, Switch-Port-Mapping oder DHCP-Lease-Check. Weitere typische Verdächtige: eine Veeam-Version mit SMB1-Fallback beim Guest Processing oder ein einmaliger manueller Zugriff, der nicht zwingend ein systemisches Problem ist.

Merksatz für die SMBv1-Remediation

Das SMBv1-Event wird serverseitig geloggt, behoben werden muss aber der Client in der ClientAddress. Der Server ist nur der Zeuge. Nutze Count, FirstSeen und LastSeen, um dauerhafte von bereits behobenen Verursachern zu trennen, und Event 32000 auf dem Client, um den genauen Share-Pfad zu finden.

Kerberos RC4 aufspüren

Grundkonzept: Ticket-basierte Authentifizierung

Kerberos ist ein Ticket-basiertes Authentifizierungsprotokoll mit drei Rollen:

• User/Principal – der Anwender oder Service, der sich authentifizieren will.
• Target Service – die Ressource, auf die zugegriffen werden soll (der SPN des Ziels).
• KDC / Domain Controller – das zentrale Gerät, das die Tickets ausstellt.

Die Events entstehen auf den Domain Controllern, weil der DC die Tickets ausgibt:

• Event 4768 – Anforderung eines TGT (Ticket Granting Ticket): „User meldet sich an der Domäne an."
• Event 4769 – Anforderung eines Service Tickets: „User will auf einen spezifischen Service zugreifen."

Die KQL-Abfrage für Kerberos RC4/DES

Event
| where TimeGenerated >= ago(30d)
| where EventLog == "Security"
| where EventID in (4768, 4769)
| parse EventData with * '"TicketEncryptionType">' TicketEncryptionType '<' *
| parse EventData with * '"TargetUserName">' TargetUserName '<' *
| parse EventData with * '"TargetDomainName">' TargetDomainName '<' *
| parse EventData with * '"ServiceName">' ServiceName '<' *
| parse EventData with * '"IpAddress">' IpAddress '<' *
| parse EventData with * '"ServiceSupportedEncryptionTypes">' ServiceSupportedEncryptionTypes '<' *
| where TicketEncryptionType in ("0x17", "0x18", "0x1", "0x3")
| extend EncryptionTypeName = case(
    TicketEncryptionType == "0x1", "DES-CBC-CRC",
    TicketEncryptionType == "0x3", "DES-CBC-MD5",
    TicketEncryptionType == "0x17", "RC4-HMAC",
    TicketEncryptionType == "0x18", "RC4-HMAC-EXP",
    "Unknown")
| project TimeGenerated, Computer, EventID, TargetUserName, TargetDomainName,
        ServiceName, TicketEncryptionType, EncryptionTypeName, IpAddress,
        ServiceSupportedEncryptionTypes
| order by TimeGenerated desc

Die Abfrage parst die relevanten Felder aus dem EventData-XML und filtert dann gezielt auf die schwachen Encryption Types: RC4 (0x17, 0x18) und das obsolete DES (0x1, 0x3). AES-Tickets (0x11, 0x12) fallen bewusst raus – die sind ja gut und interessieren uns hier nicht. Über case() wird der kryptische Hex-Wert in einen lesbaren Namen übersetzt.

Die Spalten im Detail

Der entscheidende Denkfehler: 4768 vs. 4769

Bevor wir zu den Beispielen kommen, ein Punkt, der in der Praxis ständig missverstanden wird:

• Bei Event 4768 (TGT Request) spiegelt der TicketEncryptionType die Fähigkeiten des User-Accounts wider. Taucht hier RC4 auf, ist der User selbst RC4-konfiguriert (z. B. „Use Kerberos DES encryption types for this account" aktiviert).
• Bei Event 4769 (Service Ticket Request) spiegelt der TicketEncryptionType die Fähigkeiten des Service-Accounts wider – also des Kontos, dessen SPN als ServiceName auftaucht.

Die meisten RC4-Funde sind 4769-Events, weil dort die Legacy-Appliances als Service-Accounts auftauchen. Und das führt direkt zum wichtigsten Merksatz: Der TargetUserName ist bei 4769 nicht der Schuldige. Der User hat kein RC4 „angefordert" – der DC hat RC4 gewählt, weil der Service-Account nichts Besseres kann.

Konkrete Beispiele

Muster 1: AZUREADSSOACC$ → RC4-HMAC AZUREADSSOACC$ ist der Azure AD Seamless SSO Computer-Account. Er wird bei Aktivierung von Seamless SSO automatisch im AD angelegt und ist – das ist der Knackpunkt – standardmäßig nur für RC4 konfiguriert. Microsoft hat AES-Support für dieses Konto erst spät nachgezogen.

Angenommen, das Log zeigt: User Maksymiliana → Service AZUREADSSOACC$ → RC4-HMAC. Zu lesen als: „Maksymiliana wollte sich per Seamless SSO authentifizieren, und der DC hat ein Service Ticket mit RC4 ausgestellt, weil der AZUREADSSOACC$-Account kein AES unterstützt." Der User ist nicht das Problem – die Remediation erfolgt am Service-Account.

Das ist ein bekannter Angriffsvektor (Kerberoasting gegen AZUREADSSOACC$), weil der Account RC4 nutzt (brute-forcebar), früher einen niemals rotierenden Password-Hash hatte und hochprivilegiert ist (kann im Rahmen von Seamless SSO Tickets für beliebige Benutzer ausstellen). Die Behebung besteht aus zwei Teilen. Zuerst regelmäßiger Passwort-Rollover (am besten alle 30 Tage):

Import-Module "C:\Program Files\Microsoft Azure Active Directory Connect\AzureADSSO.psd1"
New-AzureADSSOAuthenticationContext
Update-AzureADSSOForest -OnPremCredentials (Get-Credential)

Danach AES für diesen Service-Account aktivieren:

Import-Module ActiveDirectory
Set-ADComputer AZUREADSSOACC -KerberosEncryptionType AES128,AES256

Sonderfall: Bei AZUREADSSOACC$ musst Du nach jedem Passwort-Roll AES erneut explizit setzen – der Roll kann die Encryption-Types zurücksetzen.

Muster 2: VCENTER-DUS01$ mit User backup@AL… → RC4-HMAC Ein Service-Account backup@… (vermutlich ein Veeam- oder vSphere-Backup-Account) fordert ein Service Ticket für den VMware-vCenter-Server (Computer-Account VCENTER-DUS01$) an, und der vCenter-Host unterstützt nur RC4. Das ist typisch für Appliances und Nicht-Windows-Systeme, die im AD joined sind:

• Linux/Unix-Systeme mit Samba/SSSD
• VMware vCenter (v. a. ältere Versionen oder manuell joined)
• NetApp, EMC, Storage-Systeme
• Netzwerk-Geräte (manche Cisco/F5 mit AD-Integration)
• Backup-Appliances (Veeam Repository Server, Commvault MediaAgents)

Der Diagnose-Schritt ist immer derselbe: das msDS-SupportedEncryptionTypes-Attribut des betroffenen Computer-Accounts prüfen:

Get-ADComputer VCENTER-DUS01 -Properties msDS-SupportedEncryptionTypes |
  Select-Object Name, msDS-SupportedEncryptionTypes

Ist der Wert 4 (RC4-only) oder 0/leer, stellst Du auf AES um:

Set-ADComputer VCENTER-DUS01 -KerberosEncryptionType AES128,AES256

Wichtig: Vorher prüfen, ob das Zielsystem (hier vCenter) AES tatsächlich unterstützt – sonst bricht nach der Umstellung die Authentifizierung.

Sonderfälle bei Passwörtern und dem krbtgt-Account

Ein paar Fallstricke, die bei der RC4-Remediation immer wieder auftauchen:

• Sehr alte Accounts: Hatten User ein pwdlastset vor 2008, besitzt das Passwort keinen AES-Schlüssel. Dann muss das Passwort doppelt geändert werden (die letzten beiden Passwörter bekommen einen AES-Schlüssel). Der Rollover kann direkt zweimal hintereinander erfolgen.
• lastLogonTimestamp kontrollieren: Ist der Wert zeitnah, muss die Passwort-Änderung sauber geplant werden, um Ausfälle zu vermeiden.
• krbtgt-Account: pwdlastset prüfen, Passwort ändern, 24 Stunden warten (Stichwort: Replikation der Domain Controller!), dann erneut ändern. Empfohlen wird ein Reset einmal pro Jahr mit dem bewährten Community-Skript Reset-KrbTgt-Password-For-RWDCs-And-RODCs.ps1. Hintergrund liefert auch der msxfaq-Artikel zum krbtgt-Keyrollover.
• Alle Service-Accounts (SPN): Das msDS-SupportedEncryptionTypes-Attribut auf 24 (nur AES128 + AES256) setzen.

Merksatz für die Kerberos-Remediation

Bei Kerberos RC4/DES ist der ServiceName der Schlüssel zur Remediation – nicht der TargetUserName. Der verwendete Encryption Type hängt von den Fähigkeiten des Service-Accounts ab. Die Behebung erfolgt, indem der Service-Account per msDS-SupportedEncryptionTypes AES-fähig gemacht wird. Konkret: (1) im Log den ServiceName identifizieren, (2) auf dem DC das Attribut prüfen, (3) bei RC4-only auf AES umstellen, (4) sicherstellen, dass das Zielsystem AES kann.

Die Deadline: Full Enforcement ab Juli 2026

Warum das Ganze jetzt Priorität hat: Mit den Juli-2026-Sicherheitsupdates beginnt die Full-Enforcement-Phase und damit das Ende der RC4-Übergangszeit. Ab diesem Punkt gilt:

• Der Audit-only-Modus wird entfernt.
• Der temporäre Registry-Wert RC4DefaultDisablementPhase wird nicht mehr ausgewertet.
• Der Standardwert für DefaultDomainSupportedEncTypes wird auf AES-SHA1 only (0x18) gesetzt.
• Kerberos stellt RC4-Tickets dann nur noch aus, wenn dies pro Account explizit über msDS-SupportedEncryptionTypes konfiguriert ist.

Organisationen, die ihre RC4-Nutzung bis dahin nicht adressiert haben, riskieren dauerhafte Service-Ausfälle bei Legacy-Systemen und Anwendungen, die kein AES können. Genau deshalb lohnt sich die hier beschriebene Protokollanalyse: Sie zeigt Dir vor dem Stichtag, welche Accounts noch RC4 sprechen – und gibt Dir die Zeit, sie kontrolliert umzustellen, statt hinterher Ausfälle zu debuggen.

Kosten im Griff behalten: Daily Cap

Log Analytics rechnet nach eingeliefertem Datenvolumen ab. Damit ein plötzlicher Event-Sturm (etwa eine Legacy-Appliance, die im Sekundentakt Tickets anfordert) Dir nicht die Rechnung sprengt, solltest Du im Workspace einen Daily Cap einrichten. Dieses tägliche Volumenlimit stoppt die Ingestion, sobald die definierte Datenmenge erreicht ist – die Kosten bleiben planbar. Bei einer zeitlich befristeten Erhebung (z. B. 30 Tage Datensammlung vor einem Hardening-Projekt) ist das die einfachste Absicherung gegen Überraschungen im Pay-as-you-Go-Modell.

Zusammengefasst

Die zwei zentralen Denkregeln, die Du aus diesem Artikel mitnehmen solltest:

• SMBv1: Das Event entsteht auf dem Server, aber behoben wird der Client (ClientAddress). IP-only-Geräte an die Netzwerkleute zur Identifikation geben, den Rest über Event 32000 auf dem Client aufklären.
• Kerberos RC4: Nicht der User in TargetUserName ist schuld, sondern der Service-Account in ServiceName. Remediation heißt: Service-Account auf AES umstellen – nicht am User herumdrehen.

Der Aufwand für die Azure-Infrastruktur ist überschaubar und einmalig; der Gewinn ist eine zentrale, KQL-abfragbare Sicht auf alle unsicheren Protokolle in der Umgebung. Genau diese Sichtbarkeit brauchst Du, um vor dem Juli-2026-Stichtag ruhig schlafen zu können.

Und das Wichtigste zum Schluss: Ein Fund in den Logs ist noch keine Remediation. Erst wenn Du die Quelle identifiziert, umgestellt und danach kontrolliert hast, dass keine neuen RC4- oder SMBv1-Events mehr auflaufen, ist das Protokoll wirklich tot.