AD Sammelkonto Zuordnung: Anmeldenachweise qualifizieren

Was die Zuordnung gemeinsam genutzter AD-Konten belegen muss

AD Sammelkonto Zuordnung beginnt mit einer Unterscheidung: Ein Verzeichniskonto ist ein Sicherheitsprinzipal, während ein Bediener die Person ist, die es verwendet. Ein Konto namens shared-support kann eine Prüfung verdienen, doch sein Name beweist nicht, dass mehrere Personen seine Anmeldedaten kennen. Eine Anmeldung unter diesem Konto kann die Kontonutzung belegen, ohne die dahinterstehende Person zu identifizieren.

Behandeln Sie einen Befund zum Kontonamen als Ausgangspunkt für eine Untersuchung. Ermitteln Sie für jedes ausgewählte Konto den Verantwortlichen, den tatsächlichen Zweck, die autorisierten Benutzer, abhängige Systeme und verfügbare Anmeldenachweise. Halten Sie die Beobachtung im Verzeichnis, die Authentifizierungsnachweise und die Zuordnung zu einer Person als getrennte Schlussfolgerungen fest. Eine legitime Dienstabhängigkeit und eine keiner Person zuordenbare Sitzung erfordern unterschiedliche Maßnahmen, auch wenn sie denselben Kontonamen verwenden.

Unsere Prüfung von Kontoklassifizierung, Verantwortlichkeit und Ablauf erläutert, wie generische Namen und der Kontozweck geklärt werden. Dieser Leitfaden ergänzt die Anforderungen an Nachweise zur Zuordnung von Aktivitäten: welche Identität jedes Windows-Ereignis beschreibt, wo sie korreliert werden kann und was vor der Außerbetriebnahme ungeklärt bleibt.

So funktioniert der Qualifizierungsprozess

1. Legen Sie für jedes Konto eine Fallakte an

Erfassen Sie die Domäne des Kontos, SAM-Namen, SID, aktuellen Aktivierungszustand, Erfassungszeitpunkt, zuständigen Verantwortlichen und vorgesehenen Zweck. Führen Sie bekannte Dienste, geplante Aufgaben, Anwendungen, administrative Abläufe und Wiederherstellungsanforderungen auf. Ein Verantwortlicher muss den Fall klären; die Zuständigkeit allein belegt nicht, wer eine bestimmte Anmeldung durchgeführt hat.

Fragen Sie den Verantwortlichen, welche Personen die Anmeldedaten erhalten oder verwenden können und über welche Zugangswege. Trennen Sie dokumentierte Autorisierung von beobachteter Nutzung. Wenn der Verantwortliche angibt, dass nur eine Person das Konto verwendet, halten Sie diese Aussage als Behauptung fest, die anhand von Nachweisen geprüft werden muss. Wenn niemand den Verantwortlichen benennen kann, lassen Sie den Fall offen und benennen Sie eine Person, die für den nächsten Untersuchungsschritt zuständig ist.

Prüfen Sie auch deaktivierte Konten. Der Detektor erfasst passende deaktivierte Benutzer; seine Anzahl entspricht daher nicht der Anzahl aktiver gemeinsam genutzter Sitzungen. Sichern Sie historische Nachweise, soweit verfügbar, und prüfen Sie Abhängigkeiten, bevor Sie entscheiden, ob ein deaktiviertes Objekt außer Betrieb genommen werden kann. Der aktuelle Verzeichniszustand belegt nicht, was in einem früheren Untersuchungszeitraum geschah.

2. Bestimmen Sie vor der Suche die Grenzen der Nachweise

Identifizieren Sie die initiierenden Arbeitsstationen oder Verwaltungshosts, die Zielserver und den relevanten Zeitraum. Prüfen Sie, welche dieser Systeme die erforderlichen Security-Ereignisse erzeugen und weiterleiten. Beide Ereignisreferenzen ordnen die Ereignisse Audit Logon zu. Die Erfassung allein auf Domänencontrollern belegt keine Abdeckung jeder Zielsitzung oder jedes initiierenden Prozesses.

Für das umfassendere Inventar der Überwachungsrichtlinien und Ereignisse nutzen Sie unseren Leitfaden zu Active-Directory-Überwachungsereignissen und ihrer Erfassung. Hier ist die betriebliche Frage enger gefasst: Kann das Team die Nachweise für dieses Konto auf diesen Hosts in diesem Zeitraum abrufen, wobei die Identitätsfelder erhalten bleiben?

Dokumentieren Sie lokale Aufbewahrungsfristen, Weiterleitungslücken, Parser-Verhalten, Zugriffsbeschränkungen und Uhrensynchronisation, bevor Sie aus fehlenden Treffern eine Schlussfolgerung ziehen. Bewahren Sie das ursprüngliche Ereignis-XML oder einen gleichwertigen verlustfreien Datensatz neben den normalisierten Feldern auf. Eine SIEM-Spalte namens Account kann verdecken, ob der Parser Subject oder Target ausgewählt hat; prüfen Sie diese Zuordnung anhand des Ereignisses selbst.

Erkennung: Identitäten in 4624 und 4648 getrennt betrachten

3. Lesen Sie die erfolgreiche Sitzung auf dem Zielsystem

Microsofts Referenz zu Ereignis 4624 definiert das Ereignis als Erstellung einer Anmeldesitzung auf dem Computer, auf den zugegriffen wurde. Subject beschreibt das Konto, das die Anmeldung meldet oder aufruft; New Logon beschreibt das Konto, für das die Sitzung erstellt wurde. Ordnen Sie die Sitzung nicht allein durch Lesen von Subject einer Person zu.

Halten Sie diese Ereignisfelder in der Fallakte getrennt:

Logon Type 3 beschreibt beispielsweise eine Netzwerkanmeldung, 4 eine Batch-Anmeldung, 5 eine Dienstanmeldung und 10 eine interaktive Remote-Anmeldung. Diese Beschreibungen helfen zu prüfen, ob die beobachtete Nutzung zum angegebenen Zweck des Verantwortlichen passt. Sie sind keine Urteile zur Zuordnung zu einer Person: Eine Netzwerksitzung kann durch Automatisierung initiiert werden, und eine Dienstsitzung identifiziert nicht die Person, die sie konfiguriert hat.

Die Referenz zu 4624 erläutert außerdem, dass die Verfügbarkeit von Adresse, Port und Arbeitsstation vom Authentifizierungskontext und Protokoll abhängt. Ein leeres Quellfeld muss im Nachweisdatensatz leer bleiben; füllen Sie es nicht aus einem anderen Ereignis, nur weil der Kontoname übereinstimmt. Die SID des gemeinsam genutzten Kontos identifiziert diesen Prinzipal, aber nicht, welcher seiner möglichen Benutzer gehandelt hat.

4. Lesen Sie explizite Anmeldedaten, ohne die Identitäten zu vertauschen

Microsofts Referenz zu Ereignis 4648 beschreibt einen Prozess, der eine Anmeldung mit explizit angegebenen Anmeldedaten versucht. Dies tritt auch bei routinemäßigen Aktivitäten auf, etwa geplanten Aufgaben und RUNAS. Subject ist das anfordernde Konto; Account Whose Credentials Were Used ist die Identität der verwendeten Anmeldedaten. Dies können unterschiedliche Konten sein.

Ein 4648-Datensatz mit einem namentlich identifizierten Subject und einem gemeinsam genutzten Target ist ein nützlicher Nachweis dafür, dass dieser benannte Sicherheitskontext die Nutzung der gemeinsam genutzten Anmeldedaten angefordert hat. Er belegt nicht unabhängig davon, welche Person den Kontext kontrolliert. Er beschreibt außerdem einen Versuch; machen Sie daraus ohne unterstützende Nachweise keine erfolgreiche Anmeldung auf dem Zielsystem. Das Ereignis-XML enthält Zielnamen, Domäne und GUID; nehmen Sie nicht an, dass es eine Target-SID liefert, nur weil ein normalisiertes Schema eine entsprechende Spalte besitzt.

5. Korrelieren Sie innerhalb des richtigen Hosts und der richtigen Sitzung

Beginnen Sie mit dem relevanten Host, Zeitstempel und Identitätsabschnitt. Microsofts Hinweise zur Logon ID-Korrelation begrenzen die Eindeutigkeit auf einen Computer zwischen Neustarts. Beschränken Sie Verknüpfungen über Logon ID auf diesen Host und dessen Startintervall, statt sie über die Domäne hinweg vorzunehmen. Suchen Sie bei einem initiierenden 4648 nach der entsprechenden lokalen 4624-Sitzung anhand des Subject-Anmeldekontexts von 4648 und des New Logon-Kontexts von 4624. Subject unterschiedslos mit Subject zu verknüpfen beantwortet eine andere Frage.

Erhalten Sie beide GUIDs aus 4648. Microsofts Referenzen beschreiben die 4624/4648-Korrelation auf demselben Computer, wenn die relevante GUID verfügbar ist. Wählen Sie weder eine Subject-GUID noch eine Anmeldedaten-GUID automatisch aus, nur weil ein Parser beide in ein generisches Feld umbenannt hat. Stellen Sie fest, welche Sitzung der vorgeschlagene Treffer repräsentiert, und halten Sie die Grundlage dieser Entscheidung fest.

Eine GUID, die nur Nullen enthält, ist ein nicht verfügbarer Nachweis und keine gemeinsame Sitzung aller Datensätze mit Nullen. Erstellen Sie über initiierende Hosts und Zielhosts hinweg eine Zeitleiste anhand von Konto/Domäne, Zielhost, verfügbarem Quellkontext und Zeitstempeln. Kennzeichnen Sie diese Verbindung als kontextuell, wenn keine zuverlässige Sitzungsverknüpfung existiert. Setzen Sie identische hexadezimale Logon IDs auf zwei Rechnern niemals gleich.

6. Dokumentieren Sie Sicherheit der Zuordnung und widersprüchliche Erklärungen

Verwenden Sie ausdrücklich benannte Vertrauenskategorien als Prüfungskonvention, nicht als Microsoft-Bewertungssystem. Die Kontonutzung kann bestätigt sein, während die Zuordnung zu einer Person ungeklärt bleibt. Halten Sie diese Schlussfolgerungen in getrennten Spalten fest, statt dem gesamten Fall einen beruhigenden Gesamtwert zu geben.

Unabhängige Nachweise können etwa von einem Zugangsgateway mit individueller Authentifizierung oder einem Datensatz zur Ausgabe von Anmeldedaten stammen, sofern die Organisation darüber verfügt und Zeitstempel sowie Identitäten verifiziert werden können. Eine Benutzerliste, IP-Adresse oder Erinnerung des Verantwortlichen allein ist ein schwächerer Nachweis. Erfassen Sie Alternativen wie geplante Automatisierung oder eine andere Person, die die initiierende Sitzung kontrolliert; dokumentieren Sie, warum die beibehaltene Erklärung besser gestützt ist.

Dies ist ein Untersuchungsablauf, keine als ausgeführt dargestellte Abfrage. Für diesen Leitfaden wurde kein Host- oder SIEM-Test durchgeführt. Validieren Sie Feldzuordnungen und Korrelationen mit kontrollierten, autorisierten Aktivitäten, bevor Sie sich im Betrieb darauf verlassen.

Abhilfe: Verantwortlichkeit vor der Außerbetriebnahme wiederherstellen (Remediation)

7. Ersetzen Sie gemeinsam genutzten menschlichen Zugriff durch personenbezogenen Zugriff

Planen Sie für menschliche Arbeitsabläufe den Zugriff über individuelle Bedieneridentitäten und prüfen Sie, ob die Datensätze die individuelle Identität bis zur privilegierten Aktion erhalten. shared-support in einen persönlich wirkenden Namen umzubenennen schafft keine Verantwortlichkeit. Klären Sie, wer Anmeldedaten erhalten kann, wie Zugriff genehmigt wird und wie er entzogen werden kann, wenn sich die Rolle einer Person ändert.

Dokumentieren Sie bei Automatisierung die Arbeitslast und ihren Verantwortlichen getrennt von menschlichen Bedienern. Prüfen Sie Migrationsoptionen mit dem Anwendungsteam, statt einem Dienst ein für interaktive Nutzung entworfenes Identitätsmodell aufzuzwingen. Ziel ist es, unnötige gemeinsame Nutzung von Anmeldedaten zu beseitigen und zugleich legitime Abhängigkeiten sowie eine überprüfbare Zugriffsspur zu erhalten.

Ist ein sofortiger Ersatz unmöglich, dokumentieren Sie eine befristete Ausnahme mit Verantwortlichem, genehmigtem Zweck, autorisierten Benutzern, erlaubten Hosts, ausgleichenden Nachweisen, Ablaufdatum und Migrationsmeilenstein. Eine Ausnahme ohne nutzbare Zuordnungsspur muss dies ausdrücklich benennen. Ein zukünftiges Ablaufdatum macht die heutige mehrdeutige Sitzung nicht zuordenbar.

8. Deaktivieren Sie nur eine geprüfte Identität

Holen Sie vor der Außerbetriebnahme die Abhängigkeitsbewertung des Verantwortlichen ein, prüfen Sie Wiederherstellungsvorkehrungen, sichern Sie Untersuchungsunterlagen und vereinbaren Sie Zuständigkeiten für Validierung und Rücknahme. Entscheiden Sie separat, ob die Nachweise eine Reaktion auf eine Kompromittierung stützen. Ein Befund zum Kontonamen allein belegt keine Kompromittierung und rechtfertigt keine umgebungsweite Maßnahme an Anmeldedaten.

Für ein gewöhnliches Konto, dessen Außerbetriebnahme genehmigt wurde, ist das Folgende eine Anpassung der dokumentierten Parameter von Disable-ADAccount. Der DN und der beschreibbare Domänencontroller dienen als Beispiele; prüfen Sie beide vor der Verwendung. Diese Beispiele erfordern das ActiveDirectory-Modul und Verzeichnisberechtigungen und wurden für diesen Artikel nicht ausgeführt.

Disable-ADAccount -Identity 'CN=shared-support,OU=Users,DC=contoso,DC=com' -Server 'dc01.contoso.com' -WhatIf

-WhatIf zeigt eine Vorschau der Operation; es prüft nicht, ob eine Anwendung ausfallen wird. Nach der Abhängigkeitsprüfung und im genehmigten Änderungsfenster lautet die entsprechende gezielte Aktion:

Disable-ADAccount -Identity 'CN=shared-support,OU=Users,DC=contoso,DC=com' -Server 'dc01.contoso.com' -Confirm

Leiten Sie nicht jeden passenden Kontonamen per Pipeline an eine Deaktivierungsoperation weiter. Prüfen Sie nach der genehmigten Änderung den resultierenden Verzeichniszustand und abhängige Abläufe. Eine Löschung erfordert eine separate Entscheidung über Aufbewahrung und Wiederherstellung; weder eine niedrige Detektoranzahl noch ein ereignisfreier Zeitraum liefern diese Autorisierung.

9. Schließen Sie mit der Entscheidung ab, die die Nachweise stützen

Beantworten Sie für jedes Konto drei Fragen: Welche Hosts und Überwachungsrichtlinien lieferten die erforderlichen Nachweise; existiert eine unabhängige personenbezogene Bedieneridentität; und welche Abhängigkeiten erfordern vor der Entfernung eine befristete Ausnahme? Fehlt eine Antwort, halten Sie die offene Frage, den zuständigen Verantwortlichen und den nächsten Prüfungstermin fest.

Schließen Sie mit einem konkreten Ergebnis ab: menschlichen Zugriff ersetzt, Arbeitslastabhängigkeit migriert, unnötige Identität deaktiviert oder befristete Ausnahme beibehalten. Fügen Sie die Begründung der Zuordnungssicherheit und die Nachweislücken bei. Eine abgeschlossene Prüfung sollte sowohl die betriebliche Entscheidung als auch die Grenzen jeder Aussage zur historischen Zuordnung erläutern.

So erkennt EtcSec diesen Befund

Die etc-collector-Prüfung SHARED_ACCOUNT ist ein Accounts-Befund mit Schweregrad Medium. Bei Collector-Commit 0423094759d50002457031317098417993e19510 prüft Detect() in public/internal/audit/detectors/ad/accounts/patterns/shared-account.go:45 den SAMAccountName erfasster Benutzer gegen vier Präfixe ohne Berücksichtigung der Groß-/Kleinschreibung:

(?i)^shared
(?i)^common
(?i)^generic
(?i)^guest-

Dies sind namensbasierte Produktheuristiken. shared-support und CommonDesk passen; my-shared-support passt nicht zu ^shared, da das Präfix am Anfang verankert ist. Die Prüfung umfasst keine service/svc-Präfixe, untersucht nicht, wer ein Passwort kennt, und bestimmt nicht, wie viele Personen ein Konto verwenden.

Jeder passende Benutzer wird einmal hinzugefügt, dann endet die innere Musterschleife. Count ist die Anzahl passender erfasster Benutzer, einschließlich deaktivierter Konten: Es gibt keinen Filter auf den Aktivierungszustand. Wenn Details angefordert werden und Treffer vorliegen, enthält der Befund betroffene Benutzerentitäten. Die Funktion liefert auch dann einen Befund zurück, wenn Count null ist.

Der LDAP-Provider liefert Verzeichnisbenutzer und Attribute, keine 4624/4648-Ereignishistorie oder Bedieneridentität. Dieses Detect korreliert keine Sitzungen, beweist keine gemeinsame Nutzung von Anmeldedaten, bewertet keine unabhängigen Zuordnungsdatensätze und verifiziert keine genehmigte Außerbetriebnahme. Ein positives Ergebnis eröffnet den oben beschriebenen Qualifizierungsprozess; eine Anzahl von null belegt nur, dass kein erfasster Name auf diese Ausdrücke passte, nicht, dass jede Kontonutzung zuordenbar ist.