Purple Knight - Account Security - Verständnisfrage

[toao 3]

Hi alle,

 

es geht um den 'Indicator Name': Built-in domain Administrator account used within the last two weeks in Kombination mit der 'Description', welche das Wort 'recently' benutzt und als Basis das ADDS attribut 'lastLogonTimestamp' ausliest.

Vorweg, ich denke das dieses attribut nicht ausreichend ist für "...within the last two weeks".

lastLogonTimestamp im default Zustand nimmt den Wert 14 minus prozentual zufälligen Wert von 5 setzt diesen dann in Kontext mit dem aktuellen Datum minus aktuelle Datum von lastLogonTimestamp und auf dieser Basis wird dann je nach kleiner oder größer replieziert oder nicht. (Ich habs mal in einem Satz versucht, besser nachzulesen hier "https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/8220-the-lastlogontimestamp-attribute-8221-8211-8220-what-it-was/ba-p/396204"

Würde bedeuten, dass es Szenarien gibt in denen in der ersten Woche bis hin zu 8 Tagen keine Replikation stattfindet obwohl eventuell ein Domain Controller theoretisch schon was zu replizieren hätte.

 

Ferner gibt es Szenarien, in denen das lastLogonTimestamp aktualisiert wird, jedoch nicht durch einen tatsächlichen logon Versuch ausgelöst wurde (false-positiv), so zum Beispiel bei einem Windows Event 4624 mit der Info "authZ" unter Logon Process.

 

Bitte korregiert mich sofern ich vom Verständnis her etwas verkerht interpretiert habe oder etwas übersehen habe.

 

 

Jetzt wollte ich nach einer Alternative für lastLogonTimestamp schauen, wäre da zum Beispiel das attribut "Lastlogon" (nicht repliziertes, daher von allen DCs abzufragen und zu vergleichen) ein etwas stimmigeres Attribut für die Definition "...within the last two weeks"?

 

Oder gar die Windows Event IDs 4768 (A Kerberos authentication Ticket (TGT) was requested / 4769 A Kerberos service ticket was requested auszulesen und auf Grundlage dessen den Report zu erstellen?

 

Mir ist schon bewusst, dass meine Vorschläge (etwas) umfangreicher sind im Vergleich das "lastLogonTimestamp" auszulesen, wollte dennoch nach einer Alternativen schauen, sofern mein oben beschriebenes Verständnis stimmt.

Gruß,

toao

[daabm 1.348]

LastLogon geht, aber nur wenn der "most recent DC" nicht ausgetauscht wurde. Dann wäre es weg TGT/TGS hilft nur, wenn Du NTLM deaktiviert hast - viel Spaß dabei...

Einfacher ist es, das Replikationsintervall von LastLogonTimestamp runterzusetzen. In halbwegs modernen Infrastrukturen sollten auch 30 Minuten kein Problem darstellen. Die Infrastruktur-Annahmen beim Design von AD berücksichtigten noch analoge Wählleitungen 🙈

bearbeitet 6. Oktober von daabm

[cj_berlin 1.306]

Moin,

 

für Fragen zu Purple Knight empfehle ich den offiziellen Slack-Channel: https://purpleknight.slack.com/join/shared_invite/zt-o8ojqo68-S7bQLV3U6w1V525lHMH~aA#/shared-invite/email .

 

Dein Verständnis von lastLogon vs. lastLogonTimestamp ist korrekt. Was die echte Aktualisierung angeht, ist es "gut genug" (Du willst ja *eigentlich* am liebsten sofort wissen, dass dieses Konto benutzt wurde), zumal Purple Knight ja das Sync-Interval berücksichtigt, sofern es größer 14 ist, und das Fenster entsprechend erweitert.

 

Die falschen positiven (https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/how-lastlogontimestamp-is-updated-with-kerberos-s4u2self/ba-p/257135) sind indes auch nicht ganz wertlos, da sie darauf hinweisen, dass *jemand* *etwas* mit diesem Account versucht hat  

 

In einer etwas weiter verzweigten Infrastrukltur kann ein Tool wie Purple Knight lastLogon nicht zuverlässig verwenden, da es möglicherweise keinen Computer gibt, der alle DCs sehen kann. Und, wie @daabm bereits anmerkte, der DC mit dem frischesten Wert muss zum Zeitpunkt der Abfrage noch vorhanden sein.

vor 11 Minuten schrieb daabm:

Einfacher ist es, das Replikationsintervall von LastLogonTimestamp runterzusetzen. In halbwegs modernen Infrastrukturen sollten auch 30 Minuten kein Problem darstellen.

Wie mache ich das? Das Attribut ist in Tagen, und das Minimum von 5 ist hartkodiert. 

[NilsK 2.930]

Moin, 

 

Hmm ... Ich finde die Kritik für ein Auswertungstool zu hoch gegriffen. Für das, was man damit erreichen will, scheint mir der LLTS die beste Wahl zu sein.

 

Purple Knight soll nach meinem Verständnis Indikatoren sichtbar machen, nicht mehr und nicht weniger. Ein Großteil der Hinweise, die das Tool erzeugt, braucht interpretation. Und viele davon sind nur in bestimmten Szenarien relevant. 

 

Für ein Audit-Tool mit dem Schwerpunkt auf Stichproben finde ich das richtig. Wenn ich Ereignisse, die ich für kritisch halte, genauer auswerten will, brauche ich ein anderes Werkzeug. 

 

Gruß, Nils

bearbeitet 7. Oktober von NilsK

[toao 3]

16 hours ago, daabm said:

LastLogon geht, aber nur wenn der "most recent DC" nicht ausgetauscht wurde. Dann wäre es weg TGT/TGS hilft nur, wenn Du NTLM deaktiviert hast - viel Spaß dabei...

Einfacher ist es, das Replikationsintervall von LastLogonTimestamp runterzusetzen. In halbwegs modernen Infrastrukturen sollten auch 30 Minuten kein Problem darstellen. Die Infrastruktur-Annahmen beim Design von AD berücksichtigten noch analoge Wählleitungen 🙈

Der Austausch von DCs kommt in unserer Umgebung nicht so oft vor, dennoch ein valider Punkt, dem man berücksichtigen sollte, an den hatte ich nicht gedacht. Zu NTLM deaktivieren musste ich schmunzeln... Wir hatten schon Hürden zu nehmen, in dem wir von NTLM v1 auf v2 geschwenkt sind ;) Gute Idee mit dem heruntersetzen des Replikationsintervalls, werde ich in Erwägung ziehen. Danke auch dafür.

 

 

16 hours ago, cj_berlin said:

Moin,

 

für Fragen zu Purple Knight empfehle ich den offiziellen Slack-Channel: https://purpleknight.slack.com/join/shared_invite/zt-o8ojqo68-S7bQLV3U6w1V525lHMH~aA#/shared-invite/email .

 

Dein Verständnis von lastLogon vs. lastLogonTimestamp ist korrekt. Was die echte Aktualisierung angeht, ist es "gut genug" (Du willst ja *eigentlich* am liebsten sofort wissen, dass dieses Konto benutzt wurde), zumal Purple Knight ja das Sync-Interval berücksichtigt, sofern es größer 14 ist, und das Fenster entsprechend erweitert.

 

Die falschen positiven (https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/how-lastlogontimestamp-is-updated-with-kerberos-s4u2self/ba-p/257135) sind indes auch nicht ganz wertlos, da sie darauf hinweisen, dass *jemand* *etwas* mit diesem Account versucht hat  

 

In einer etwas weiter verzweigten Infrastrukltur kann ein Tool wie Purple Knight lastLogon nicht zuverlässig verwenden, da es möglicherweise keinen Computer gibt, der alle DCs sehen kann. Und, wie @daabm bereits anmerkte, der DC mit dem frischesten Wert muss zum Zeitpunkt der Abfrage noch vorhanden sein.

Wie mache ich das? Das Attribut ist in Tagen, und das Minimum von 5 ist hartkodiert. 

Guten Morgen, eindeutig die passendere Platform solche Fragen zu stellen. Danke für den Link als auch die Erläuterung zu Purple Knight und darüberhinaus.

 

13 hours ago, NilsK said:

Moin, 

 

Hmm ... Ich finde die Kritik für ein Auswertungstool zu hoch gegriffen. Für das, was man damit erreichen will, scheint mir der LLTS die beste Wahl zu sein.

 

Purple Knight soll nach meinem Verständnis Indikatoren sichtbar machen, nicht mehr und nicht weniger. Ein Großteil der Hinweise, die dass Tool erzeugt, brauchen interpretation. Und viele davon sind nur in bestimmten Szenarien relevant. 

 

Für ein Audit-Tool mit dem Schwerpunkt auf Stichproben finde ich das richtig. Wenn ich Ereignisse, die ich für kritisch halte, genauer auswerten will, brauche ich ein anderes Werkzeug. 

 

Gruß, Nils

 

Moin Moin,

ich denke schon das jeder Hersteller der Beschreibungen nutzt, sich an diesen messen lassen kann auch wenn es sich um kostenlose Tools handelt. Mit Rückmeldungen solcher Art besteht die Möglichkeit für ein Produkt immer weiter zu wachsen und sich zu verbessern (nicht bezogen auf mein Beispiel, sondern generell), sofern es Sinn ergibt und manchmal kennt man die Hintergründe/Entscheidungswege nicht so gut, daher auch meine Nachfrage. Nun habe ich den Link vom @cj_berlin dankenswerterweise erhalten und werde die kommenden Nachfragen dort einstellen.

 

Genau, für mehr Detail braucht man ein anderes Werkzeug.

[daabm 1.348]

Am 6.10.2024 um 16:33 schrieb cj_berlin:

Wie mache ich das? Das Attribut ist in Tagen, und das Minimum von 5 ist hartkodiert. 

 

Hätte ich vorher noch mal genauer recherchieren sollen, wo da die Limits sind 🙈 mea culpa   Wobei ich zu den 5 Tagen nichts finde. https://github.com/MicrosoftDocs/win32/blob/docs/desktop-src/ADSchema/a-msds-logontimesyncinterval.md

[cj_berlin 1.306]

Die Limits sind wohl im Code, nicht im AD. Aber in jedem Fall ist es in Tagen  

[daabm 1.348]

vor 7 Stunden schrieb toao:

Zu NTLM deaktivieren musste ich schmunzeln... Wir hatten schon Hürden zu nehmen, in dem wir von NTLM v1 auf v2 geschwenkt sind

 

Ich schmunzle da nicht mehr 😒 Wir arbeiten seit 3 Jahren daran, und es ist - hm - "zäh" wäre ein Euphemismus... Mit Kerberos only fängt man sich gleich noch ganz viel DNS ein (Disjoint Namespaces, Hostnamen in "irgendwelchen" DNS-Zonen etc.). Meist ist das der Zeitpunkt, wo man merkt, daß das DNS-Design zwar "schön" aussieht, technisch aber eigentlich unbrauchbar ist.

vor 1 Minute schrieb cj_berlin:

Die Limits sind wohl im Code, nicht im AD. Aber in jedem Fall ist es in Tagen  

 

Jaja, Limits im Code. Heute über eins gestolpert... Wollte per Skript Domain_Realms konfigurieren, gibt ein Policy Setting dafür: https://gpsearch.azurewebsites.net/#1823

Ok, REG_SZ kann ich auch per Skript schreiben, gesagt getan - tut aber nicht. WTF? Ok, es waren 100 DNS-Zonen für ein Realm. Eigentlich weit von der Grenze von 64 kB (?) entfernt, die ein Reg-Wert groß werden darf. Aber haste nicht gesehen, da gibt's doch tatsächlich findige MS-Programmierer, die vor vielen Jahren mal "irgendwas" gedacht haben:

 

 

Mit Zone #82 haben wir diese Grenze überschritten...

[NilsK 2.930]

Moin,

 

Ja, ist schon erstaunlich, auf welche alltäglichen Probleme man so stößt. 

 

Gruß, Nils