SandyB

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

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.

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.

Ich denke auch, der Ansatz läuft ins Leere. Danke trotzdem!

Deshalb ist PS zurecht das Lieblingstool der Hacker. Und ja, ich kann AMSI

Privilegierte Zugriffe auf Port 1, Standard Zugriffe auf Port 2

Eine Frage zu RDP. Kann man auf einem Server 2016/19 zwei RDP-Ports öffnen, z.B. TCP 3389 plus TCP 33890 Ich habe nur gefunden, wie man den Standardport ändert. https://docs.microsoft.com/en-us/windows-server/remote/remote-desktop-services/clients/change-listening-port

Bei uns lässt sich die überwiegende Anzahl der Events auf commodity malware zurückführen. Zumindest teilweise ist diese auch ohne Adminrechte lauf- und schadfähig.

bzgl. Powershell wäre beispielsweise eine einfache Maßnahme, um die Security zu erhöhen, Powershell 2.0 auf Win10 zu disablen.

Große Firmen wie BMW verlangen von ihren Zulieferern (klein, mittel, groß), dass diese ihr ISMS (InfoSec Management System) nach 27001 zertifizieren lassen. Das erschwert das "Wiegen in falscher Sicherheit" beträchtlich, vor Allem weil die ISO 27001 Verantwortlichkeiten eindeutig benennt und regelmäßig Nachweise und externe Überprüfungen fordet. Diskussionen ob ISO 27001 für deine kleine Firma sinnvoll oder zu teuer ist, brauchst du mit BMW etc. nicht führen.

Besorg dir mal dieses Paper. https://www.beyondtrust.com/resources/whitepapers/the-forrester-wave-privileged-identity-management-q4-2018 Dort sind alle Lösungsanbieter für dieses Thema aufgeführt.

spricht doch dafür, dass die eigentliche Attacke mit einem Klick des Admins auf eine Phishing Mail begann, sowie 90% aller CyberAttacken. Trotzdem sollte man dem nicht "den Kopf abreißen", (9% der übrigen Attacken sind watering hole attacks) Der verhängnisvolle Klick war aber weder Anfang noch Ende der Kette: cyber kill chain https://www.lockheedmartin.com/content/dam/lockheed-martin/rms/documents/cyber/Gaining_the_Advantage_Cyber_Kill_Chain.pdf unified kill chain https://www.csacademy.nl/images/scripties/2018/Paul-Pols---The-Unified-Kill-Chain.pdf

Die Uni Erlangen hatte vor noch nicht so langer Zeit (2016) eine ähnliche Untersuchung unter 1700 FAU-Studenten durchgeführt: 78% aller User gaben an, die Gefahren von Phishing Mails zu kennen und hielten sich für gewappnet 45% der User klickten bei einer anschließend durchgeführten Phishing-Kampagne trotzdem auf den Phishing-Link 20% der Klickser standen anschließend immerhin dazu https://www.fau.eu/2016/08/25/news/research/one-in-two-users-click-on-links-from-unknown-senders/ Man kann darüber diskutieren, ob Ergebnisse von 2016 jetzt noch aussagekräftig sind und ob Studenten mehr oder weniger anfälliger sind als der Rest der Bevölkerung. Gophish https://getgophish.com/ ist übrigens ein interessantes Framework, um solch eine Aufrüttel-Kampagne in der eigenen Umgebung durchzuführen.

Hast du ein Incident Management mit entsprechenden Prozessen im Rücken? Rein technisch würde ich mir, sofern nicht bereits die malware vorlegt, bei virustotal ein sample von cryptxxx besorgen und versuchen zu analysieren. Dann kann man sehen, wie das ding überhaupt arbeitet.

Meiner Meinung nach musst du neben den Freigabeberechtigungen noch die NTFS - Berechtigungen anpassen und solltest den Anonymous Zugriff unterbinden. https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/network-access-shares-that-can-be-accessed-anonymously https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/network-access-do-not-allow-anonymous-enumeration-of-sam-accounts-and-shares Auf PC-A musst du die anderen User von PC-B, PC-C etc. nochmal mit exakt gleicher Kennung und gleichem Passwort anlegen, dann kannst du diese in die NTFS-Berechtigungen eintragen. Solch ein Konstrukt ist zwar nicht mehr zeitgemäß, aber sollte trotzdem noch funktionieren. Hast du dir mal überlegt, über Onedrive (Office 365)/ Googledrive (Google Office)/ Dropbox etc. zu arbeiten?

Im Rahmen eines Evaluierungsprojectes brauche ich bestimmte Daten über Netzwerkverbindungen zu meinem Client. "Event ID 3: Network connection" von Sysmon https://docs.microsoft.com/en-us/sysinternals/downloads/sysmon würde genau das liefern was ich brauche. Nur ist dieses Event by default disabled und ich bekomme es nicht aktiviert ("sysmon -c"). Vermutlich sehe ich den Baum vor lauter Wald nicht. Danke im Voraus.

Event Log Size\ Retention Settings? vielleicht hilft der Artikel https://helpcenter.netwrix.com/Configure_IT_Infrastructure/Windows_Server/WS_Event_Log_Settings.html

Welche Probleme hast du eigentlich?

@Heizung Du bist ja beileibe nicht der erste, der administrative Zugriffe unter Kontrolle bringen muss. Wenn es bei dir noch dazu um Kundenserver geht, brauchst du zweimal eine professionelle Lösung. Microsoft selbst hat dafür nichts Brauchbares.

PAM (Privileged Access Management) ist dafür die Lösung. CyberArk, BeyondTrust, Centrify oder Wallix sind bekannte Vertreter. Zur evaluierung sind dir die PAM Studien von Gartner oder Forrester sicher behilflich. Frag die genannten Vendoren einfach danach. Die Studien sind sonst relativ teuer.

Kennst du PingCastle? https://www.pingcastle.com/download/ Das Tool setzen bei uns die Admins für domain assessments ein. Kostet nichts und ist relativ einfach in der Handhabe. Ich schau aber immer nur zu

Hast du kontrolliert, ob ABE wirklich auf dem Share aktiviert ist? Get-SmbShare -Name Data | Select-Object FolderEnumerationMode Microsoft hält ABE selbst nicht für empfehlenswert, da es erstens kein Sicherheitsgewinn und zweitens ein Performancefresser ist. https://blogs.technet.microsoft.com/askds/2016/09/01/access-based-enumeration-abe-concepts-part-1-of-2/

Dagegen hilft nur ein Privileged Access Management (PAM). Admin-Credentials sind nie ausreichend sicher vor findigen Angreifern geschützt. Zufällig arbeite ich in einem PAM-Evaluierungsprojekt, um genau diesem Lateral Movement mit entwendeten Admin Credentials entgegen zu wirken. Solange du die Admin-Accounts nicht im Griff hast, plus eine wirksame Detection aufgebaut hast, hilft eine Neuinstallation/ Bereinigung meines Erachtens wenig.

Ist der Betriebsrat organisiert? Dann kann er sich belastbare Informationen und Anforderungen von seiner Organisation (Gewerkschaft) holen.

Um auf meine Ausgangsfrage zurückzukommen: Es geht nicht darum RAM oder CPUs zu sparen, sondern ob man Maschinen mit 64GB oder z.B. 512GB und max. CPU-Bestückung anschafft. Wenige 512GB sind billiger zu betreiben, als viele 64GB Server Maschinen. 512GB machen keinen Sinn mehr, wenn es harte Grenzen an RDP-Verbindungen vom Betriebssystem gibt, weil beispielsweise ein interner Speicherbereich volläuft. Gelesen habe ich einmal, dass 100+ concurrent user seien die OS-Grenze bei Server 2016/19 sind, an anderer Stelle wurden 150 als Limit genannt. Das waren aber keine Angaben von Microsoft. Noch ist alles in der Planungsphase.