Jump to content

SandyB

Members
  • Content Count

    76
  • Joined

  • Last visited

Everything posted by SandyB

  1. und praktisch: https://techcommunity.microsoft.com/t5/azure-active-directory-identity/azure-ad-password-protection-is-now-generally-available/ba-p/377487
  2. Die "Incident Response Methodologies" der Cert Societe Generale sind eine excellente Prozessgrundlage für weitere individuelle Anpassungen https://github.com/certsocietegenerale/IRM https://github.com/certsocietegenerale/IRM/blob/master/EN/IRM-17-Ransomware.pdf Bei uns ist für den Incident Response u.a. Kansa im Einsatz https://www.powershellmagazine.com/2014/07/18/kansa-a-powershell-based-incident-response-framework/ https://github.com/davehull/Kansa
  3. Danke ecuh! Klist purge wirft die Tickets raus, das funktioniert! Die groupmemberships 'WHOAMI /all' bleiben erhalten. Werden diese mit einem neuen KerberosTicket aktualisiert? Ich habe leider keine moeglichkeit selbst zu testen.
  4. Wenn man unter Windows10 den angemeldeten AD-User in eine neue Gruppe steckt, muss sich der user erst ab- und wieder anmelden, damit die neue Groupmembership wirksam wird. Gibt es einen "renew" Befehll, um diesen Aktualisierungsprozess auch ohne logon/logoff zu starten? Danke Sandy
  5. Du kannst den Filenamen in eine temporäre Datei oder einen temporären Regkey speichern und anschließend wieder auslesen. Der Weg über eine Environmentvariable geht vermutlich auch. Ich bin allerdings kein Freund der PS und erst recht nicht von Batches, Daher kann ich nur eine Idee liefern.
  6. Man kann in einer batch Datei Powershellbefehle ausführen: powershell -Command "& {(Get-WmiObject -ComputerName 192.168.178.55 -Class Win32_Bios).PSComputername}" Vielleicht hilft das weiter.
  7. Meine Meinung bisher war, dass ohne Mitglied in der Domäne zu sein, - bekommt der Client keine Policies (u.a. .\System\Kerberos) - fehlen dem Client die notwendigen SPNs für Kerberos - gibt es keine mutual authentication -> No Kerberos on non-domain clients. Wiegesagt, ich akzeptiere gerne, dass meine Überlegungen falsch waren.
  8. Ich war felsenfest überzeugt, dass für eine Kerberos Authentication sowohl ein Computer- als auch ein Userkonto vorhanden sein müssen. So kann man sich irren. Danke!
  9. Ich bin bis jetzt davon ausgegangen, dass eine Domain Membership Voraussetzung für den Austausch von Kerberostickets ist. Ich werde versuchen, mich besser einzulesen.
  10. Dass eine Domänenaufnahme mit Kerberos und nicht mit NTLM abgesichert wird. Es würde mir eine Reihe von Problemen lösen, wenn dem so ist.
  11. Jetzt bringt ihr mein Windows Bild vollkommen zum Einsturz
  12. Alles klar! Mittlerweile habe ich auch die Onlinestellen wieder gefunden: https://enterprise.verizon.com/resources/reports/DBIR_2018_Report.pdf https://enterprise.verizon.com/resources/reports/2019-data-breach-investigations-report-emea.pdf Ich finde Statistiken interessant, weil sie manche Meinungen unterstützen, andere widerlegen. (z.B. das BSI) Ich leite für mich aus diesen beiden Verizon-Statistiken her, dass die Bedeutung super-sicherer User-Passwörter überschätzt wird. Klar sollen User-Passwörter vernünftig-sicher sein, aber ob es jetzt 8 oder 16 Zeichen, 6 oder 24 Monate maximales Alter etc. sind, spielt bei den aktuellen Angriffsvektoren unterm Strich kaum eine Rolle für die Gesamtsicherheit. Das ist meine Interpretation
  13. das Gesamtpaper ist leider zu groß zum Hochladen. Aber auch dann wärst du vermutlich nicht zufrieden,
  14. Die relative Anzahl an Attacken auf schwache Passwörter war 2018 lt. verizon sehr gering (<0.4%). Welche Auswirkungen auf diese Häufigkeit eine verändertes Wechselintervall oder unterschiedliche Passwortlängen haben, kann m.E. niemand sagen. Vermutlich liegen wir da im Promille-Bereich. Eine Empfehlung zu entfernen, die fast keinen Effekt hat, ist sinnvoll.
  15. Hi, Kann man in einer AD-Domäne NTLM komplett disablen? "Deny all" in https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/network-security-restrict-ntlm-ntlm-authentication-in-this-domain Dann kann doch kein neuer Rechner mehr in die Domain joinen, oder habe ich einen Denkfehler?
  16. Ehrlich gesagt nein. Nicht weil ich nicht wollte, sondern weil ich selbst nur wenige Details mitbekommen habe.
  17. Die Dämme scheinen gehalten zu haben. Dank ziemlich aufwändiger Protectionkonzepte konnte der Angriff rechtzeitig unterbrochen werden und die Kill-Chain lässt sich mit den vorliegenden Monitoring-Daten relativ gut zurückverfolgen. Trotzdem Danke für den seelischen Beistand gestern abend
  18. Gibt es für dieses Scenario kein standardisiertes Vorgehen von Microsoft? @daabm: Plattmachen ist keine Alternative, @v-rtc: Soweit ich bis jetzt weiß, wurden Golden Tickets entdeckt und so flog die Attacke auf. Nein, ich bin weder Dienstleister, noch AD-Experte, eher das "Mädchen für Alles", das sich auf morgen schonmal vorbereiten will.
  19. Hi, Gibt es eine Beschreibung oder einen Prozess wie man verfahren soll, um aus einer kompromittierte Domäne einen erfolgreichen Angreifer rauszuwerfen. Beispielsweise habe ich schon gefunden: - Neue Passwörter für die Adminaccounts - Reset krbtg-Account - Trusts resetten - SID-History löschen - disable "rc4_hmac_md5" and below ciphers for Kerberostickets - Wo im Directory könnte ein Angreifer mit Adminrechten noch Backdoors eingebaut haben, Da gibt es sicher noch viele weitere Möglichkeiten. Die genaue Größe und Struktur der Domäne kenne ich selbst noch nicht. Aber sie ist jedenfalls international verzweigt und läuft auf Windows 2012R2 DCs.
  20. Freut mich! Schau dir mal diese Seite zu WinRM an. https://attack.mitre.org/techniques/T1028/ Hier findest du eine Menge guter Links zu WinRM (Attacks, Mitigations). Bisher noch nicht zur Sprache gekommen ist Detection/ Monitoring. Da kein Schutz perfekt ist, kommt diesem Kapitel ebenfalls ein wichtige Rolle zu. (siehe auch die wieterführenden Links auf der Seite) Vielleicht beschreibst du mal ganz grob dein Netzwerk: Größe, wo ihr mit der Sicherheit hinwollt, etc
  21. Mir würde sich der Magen drehen, wenn ein und derselbe Account auf 1000 Clients für administrative Aufgaben genutzt wird. Womöglich noch mit RDP und unrestricted Credentials. PAM ist für dieses Szenario m.E. ungeeignet bzw. überdimensioniert.
  22. 1. winrm over https ist sehr empfehlenswert https://support.microsoft.com/en-us/help/2019527/how-to-configure-winrm-for-https 2. für jeden Client einen eigenen Admin-Account verwenden, um lateral movement vorzubeugen https://www.lastline.com/blog/lateral-movement-what-it-is-and-how-to-block-it/ 3. Powershell selbst solltest du unbedingt absichern - https://devblogs.microsoft.com/powershell/powershell-constrained-language-mode/ - https://www.tenforums.com/tutorials/111654-enable-disable-windows-powershell-2-0-windows-10-a.html - es gibt etliche weitere, sehr zu empfehlende Möglichkeiten, bitte selbst googeln.
  23. Ich denke auch, der Ansatz läuft ins Leere. Danke trotzdem!
  24. Deshalb ist PS zurecht das Lieblingstool der Hacker. Und ja, ich kann AMSI
×
×
  • Create New...