Applocker: Eingabeaufforderung und Powershell für Benutzer deaktivieren.

[wznutzer 36]

Hallo und guten Tag,

 

während es für die Eingabeaufforderung recht einfach ist, diese für Benutzer zu deaktivieren, gibt es ein explizites Recht für die Powershell nicht. Ich überlege, was es für Möglichkeiten gibt und welche ich nehmen soll.

 

• Über die Berechtigungen für das Dateisystem.
• Über die Benutzerkonfiguration die Option "Angegebene Windows-Anwendungen nicht ausführen". Die entsprechende GPO hänge ich dann an die User-OU.
• Eine GPO die SRP für Powershell konfiguriert.

 

Derzeit tendiere ich zur Lösung über die Berechtigungen über das Dateisystem. Wie macht Ihr das oder gar nicht?

 

Grüße

bearbeitet vor 6 Stunden von wznutzer
Schreibfehler

[NorbertFe 2.155]

SRP mit Hashes dürfte vermutlich die "sicherste" Variante sein, wobei man dann aber auch regelmässig prüfen müsste ob die Hashes sich nicht ändern durch Updates usw.

[cj_berlin 1.401]

Moin,

 

und was genau soll mit dieser Maßnahme erreicht werden, außer dass Du bei jeder neuen Applikation prüfen musst, ob sie nicht doch für irgendeine Funktion cmd.exe oder powershell.exe aufruft?

 

Ein C#-Programm, das einen als Argument übergebenen PowerShell-Befehl ausführt, hat ca. 4 Zeilen, und die ganze Hasherei war umsonst. Sind die entsprechenden Systeme bereits so NTFS-mäßig gehärtet, dass ein Normaluser nirgends - nicht im eigenen Profil, nicht in %TEMP%, einfach wirklich in *keinem* Ordner - gleichzeitig Schreib- und Ausführungsrechte hat? Wenn die Antwort hierauf "nein" lautet, kannst Du dir den kosmetischen Lockdown sparen.

 

EDIT: Oder ist WDAC schon so hoch gedreht, dass nur bekannte Anwendungen ge-whitelistet sind?

bearbeitet vor 10 Stunden von cj_berlin

[wznutzer 36]

vor 5 Stunden schrieb cj_berlin:

und was genau soll mit dieser Maßnahme erreicht werden, außer dass Du bei jeder neuen Applikation prüfen musst, ob sie nicht doch für irgendeine Funktion cmd.exe oder powershell.exe aufruft?

Ich kann einen Denkfehler meinerseits nicht ausschließen . Aber mir ist klar, dass das Wartungsaufwand zur Folge hat.

 

Die Systeme, die ich im Blick habe, haben Applocker aktiv. Die Verzeichnisse, auf die ein User Schreibrechte hat, sind in den Regeln berücksichtigt. Das sollte die Variante über ein separates Programm abdecken. Das liese sich nicht ausführen. Darüberhinaus habe ich Fileless Malware bzw. Fileless Threats im Sinn. Ganz allgemein, warum sollte der User etwas ausführen dürfen, was er nicht braucht.

 

Warum Applocker und nicht WDAC? Klar, WDAC scheint besser zu sein, aber auch wartungsaufwändiger als Applocker.

 

Im Prinzip geht es darum, so viele Steine wie möglich in den Weg eines möglichen Angreifers zu legen. In dem Wissen, dass der einzelne Stein evtl. nichts nützt.

bearbeitet vor 6 Stunden von wznutzer

[cj_berlin 1.401]

Moin,

 

das mit den Steinen klingt in Theorie gut. In der Praxis ist die Frage allerdings immer, stört der Stein einen potentiellen Angreifer mehr oder weniger als einen legitimen User - oder sogar den Steineleger selbst, also Dich. Denn etwas, was den User behindert, den Angreifer aber nur kurz schmunzeln lässt, bringt keine Punkte und senkt die Akzeptanz des Gesamtkonzepts.

 

Denkt man Deine Idee zu Ende, so müsste die Konfiguration für lokale Administratoren enger gezurrt sein als für Normalbenutzer, denn jemand, der lokale Adminrechte hat, kann mit demselben Werkzeug mehr Schaden anrichten. Er kann auch beispielsweise die Konfiguration, die Du für lokale User gemacht hast, aufheben. Das wäre auch kein Problem, wenn beispielsweise jegliche legitime Administration im SYSTEM-Kontext durch einen Agenten durchgeführt wird. Da braucht es im Zweifel gar keine lokalen Admins auf einer Maschine. Hier ein 2 Jahre alter Beitrag: https://happycamper84.medium.com/powershell-without-powershell-e50c5c99c79f und davon gibt es tonnenweise. Alle kommen zu demselben Schluss: wenn die Rechte fehlen, nützt das Tool nichts - andersherum stimmt das aber nicht.

WDAC und AppLocker arbeiten am besten zusammen, indem man mit WDAC eine statische Whitelist pflegt ("alles, was bekannt und für irgendwas gut ist") und darüber mit AppLocker eine dynamische Blacklist legt (zum Beispiel, unterschiedlich für User und Administratoren - oder für die Lizenz-Compliance). AppLocker hat das grundsätzliche Problem, dass es von AppIdSvc abhängt, weswegen ich damit niemand Whitelisting machen würde. Blacklisting geht aber, ist halt nicht so wirkungsvoll.

 

AUSSERDEM: Ich weiß nicht, wie euer Helpdesk agiert, aber als ich regelmäßig mit 1st Level zu tun hatte, war "machen Sie die Kommandozeile auf und führen Sie folgendes aus" der häufigste Spruch am Telefon, gleich nach "ist erledigt, Ihr Passwort ist erst mal wieder das Startkennwort, Sie müssen es nach der Anmeldung gleich ändern".

bearbeitet vor 5 Stunden von cj_berlin

[wznutzer 36]

Danke für deine Einschätzung @cj_berlin. Ich muss noch ein wenig darüber nachdenken. Vor allem über den Einsatz von WDAC in Verbindung mit Applocker.

 

Ich habe leider eine Info nicht angegeben. Bei den betroffenen Rechnern, handelt es sich um Remote Desktop Session Hosts.

 

Ich glaube, ich muss noch ein wenig darüber nachdenken. Der Support macht tatsächlich gar nie eine Eingabeaufforderung auf. Der verlinkte Artikel macht mir einen Strich durch die Rechnung.

 

Wenn man sich auf die Rechte konzentriert, in welche Richtung muss man laufen wenn ich den einzelnen Server bzw. PC im Auge habe? Drumherum versuche ich natürlich gar keine unberechtigten Zugriffe zuzulassen. D. h. im gedachten Szenario gehe ich davon aus, dass es der Angreifer bereits auf das System geschafft hat oder ein legitimer User etwas versehentlich oder auch absichtlich ausführt.