Admin- oder User-Account? Warum das eigentlich egal ist und wie man sich die Rechte holt, die man will

Best-Practise in der IT ist das Szenario: Ein Benutzer hat einen von der IT-Abteilung verwalteten Administrator-Account. Zu diesem hat keiner Zugang außer die IT-Admins. Und dann gibt es, gerade wenn es keine Domäne gibt, noch einen Benutzer-Account. Den nennen wir in unserem Beispiel einmal user. Wie man nun als user alle Sperren umgehen kann, das zeigen wir hier.

Der Sinn des Beitrags ist keinesfalls, sich mehr Rechte zu holen, als einem zustehen. Vielmehr soll hier praktisch gezeigt werden, weshalb diese Trennung der Benutzerrechte so willkürlich ist und keinesfalls mehr Sicherheit schafft.

Fall 1: Der Nutzer googelt “Programm installieren ohne Adminrechte” und findet als ersten Beitrag eine Anleitung für folgendes Setting:

Mit diesem Code

set _COMPAT_LAYER=RunAsInvoker
start [Installer Name]

kann der Nutzer schon 60% aller Programme installieren. Gleiches passiert mit dem Code:

cmd /min /C "set __COMPAT_LAYER=RUNASINVOKER && start "" "%1""

Es nützt also nichts. Schauen wir weiter.

Fall 2: Ändern wir doch einfach als normaler Nutzer das Admin-Passwort. Das geht nicht als Benutzer ohne Admin-Rechte? Weit gefehlt…

Hier dann auf Kennwort festlegen, Fortzsetzen und Bestätigen. Voila.

Soweit an zwei kleinen Beispielen, was das Einsetzen von User-Accounts im Vergleich zu Admin-Accounts so schwierig macht.

Viel wichtiger ist es, die passende Software zu nutzen, die beispielsweise Powershell komplett verbietet. Ausschließlich für kleine Wartungsfenster gibt man Powershell frei, installiert das, was zu installieren ist, und schließt anschließend wieder Powershell aus. Das ist einer von vielen Sicherheitsansätzen. Payload hat keine Chance, da dieser bisweilen über Powershell oder CMD geladen wird.