Uitgangspunt: "ExecutionPolicy is not a security boundary."Microsoft, officiële PowerShell-documentatie. Toch behandelen veel IT-organisaties het alsof het er wel een is. Wat kan een gebruiker met Set-ExecutionPolicy -Scope CurrentUser Unrestrictedzonder één admin-recht? Het antwoord is verontrustend.

Wat ExecutionPolicy wél doet (en wát niet)

De policy bepaalt of PowerShell ongetekende script-bestanden mag uitvoeren. Het bestaat om te voorkomen dat een gebruiker per ongeluk een .ps1-bestand draait door erop te dubbelklikken. Het is een convenience-rem, geen security control. Een aanvaller kan de policy met één van vier triviale technieken omzeilen:

Bypass-techniekEffect
powershell -ExecutionPolicy Bypass -File foo.ps1One-shot bypass; ExecutionPolicy is genegeerd voor deze proces-instantie
powershell -EncodedCommand <base64>Script draait in command-mode, niet file-mode — ExecutionPolicy is niet van toepassing
Get-Content foo.ps1 | Invoke-ExpressionInhoud van bestand wordt als commando uitgevoerd, niet als script-file
Set-ExecutionPolicy -Scope CurrentUser UnrestrictedPermanent voor deze user — werkt zonder admin als er geen GPO is

Wat een aanvaller binnen één besmette user-account kan

Met PowerShell-script-execution actief (op welke manier dan ook), zonder enige admin-rechten:

1Phishing-bijlage exec

Een .ps1 uit een email-bijlage of download draait direct na dubbelklik. Geen UAC, geen waarschuwing — de meest waarschijnlijke aanvalsroute in elk endpoint.

2Office macro → PS payload

Een Word/Excel macro mag Shell("powershell -File ...") aanroepen. Macro-blocking helpt, maar als de macro draait is de step naar PowerShell triviaal.

3Living-off-the-Land recon

Zonder enige extra tools: Get-LocalUser, share-enumeratie, Get-Process, registry-reads, Get-NetTCPConnection. Volledige verkenning binnen seconden.

4Credentials uit user-context

DPAPI-keys van de user ontsleutelen wachtwoorden uit Chrome/Edge. (Get-PSReadLineOption).HistorySavePath bevat soms per-ongeluk geplakte wachtwoorden. CredentialManager-module leest opgeslagen credentials.

5Outlook automation

New-Object -ComObject Outlook.Application — binnen seconden mailbox dumpen, mails versturen namens user, agenda kopiëren. Volledig binnen "wat de user mag".

6Data-exfiltratie

Compress-Archive ~\Documents + Invoke-WebRequest -Method POST -InFile. Geen tools, geen malware, geen file write op disk — alles in PowerShell-pipeline.

7Persistence zonder admin

Registry Run-keys in HKCU; Scheduled Tasks in user-context; Startup-folder; WMI event-subscriptions in root\subscription. Alles overleeft reboots.

8Lateral movement

SMB-shares die de user kan lezen — bedrijfsbestanden uit andere afdelingen. PSRemoting naar andere endpoints als de user daar credentials voor heeft. SharePoint/OneDrive via REST-API.

9Defender / EDR ontwijken

Get-MpPreference toont welke paden Defender NIET scant — een script kan zichzelf daar parkeren. AMSI-bypass tricks (obfuscatie, dynamic-loading) zijn algemeen bekend en draaien zonder admin.

10Network reconnaissance

Test-NetConnection over hele subnets, Resolve-DnsName voor zone-transfers, Get-ADUser als RSAT geinstalleerd is. Volledige Active Directory enumeration binnen user-context.

De impact-kaart voor IT-managers

AannameWerkelijkheid
"ExecutionPolicy is een security control"Nee — alleen tegen onbedoeld dubbelklikken
"Zonder admin kan een gebruiker geen schade aanrichten"Binnen user-scope kan een aanvaller data exfiltreren, credentials stelen, persistence opbouwen, lateral movement doen — alles werkt
"AV/EDR vangt het wel"Alleen als getuned op gedrag-detectie met AMSI-integratie. Default-installaties missen veel
"Het is niet erg als de gebruiker zichzelf besmet"Besmette user heeft toegang tot bedrijfs-fileserver, OneDrive, SharePoint, alle mailcontacts — en kan vanuit daar verder springen
"Onze users hebben geen admin"Voor 90% van wat een aanvaller wil doen, is dat niet nodig

Tegenmaatregelen die wél werken

De effectiefste maatregelen, ruwweg in volgorde van impact:

1. Constrained Language Mode via AppLocker of WDAC

PowerShell weigert ongetekende scripts überhaupt. Cmdlets die .NET-types laden worden geblokkeerd. Dit is de enige echte "lockdown" voor PowerShell. Vereist tijd om in te richten (whitelist van benodigde scripts/modules), maar is de gouden standaard.

2. PowerShell ExecutionPolicy via Group Policy (MachinePolicy)

De policy in MachinePolicy-scope overrult CurrentUser. Te zetten via Computer Configuration → Administrative Templates → Windows Components → Windows PowerShell → Turn on Script Execution. Stel op AllSigned of restrictiever.

3. Script Block Logging + Module Logging + Transcription

Alle PowerShell-activiteit naar Event Log (4104, 4103, 800) zodat SIEM het oppikt. Onmisbaar voor incident-response — zonder logging weet u nooit wat er heeft gedraaid.

4. AMSI met EDR-integratie

Microsoft Defender for Endpoint, CrowdStrike, SentinelOne. Detecteert obfuscatie-patronen en bekende attack-tooling. Cruciaal: tune de regels op uw omgeving (false-positives anders te hoog).

5. Application Control

Alleen getekende uitvoerbare bestanden — inclusief .ps1 — toestaan. AppLocker of WDAC, gekoppeld aan certificate-store.

6. PowerShell v2 disable

De oude versie heeft geen AMSI. Een aanvaller kan downgraden met powershell -Version 2 als v2 nog op het systeem zit. Verwijder via Optional Features.

7. Just-In-Time admin

Gebruikers hebben nooit standaard admin. Tijdelijke elevation via PIM (Privileged Identity Management). Kostbaarder, maar maakt veel attack-paths onmogelijk.

Wat de Werkplek-Beveiliging-Test aantoont

De WPB-test probeert één simpele variant: Set-ExecutionPolicy -Scope CurrentUser Unrestricted. Als dat op uw werkplek lukt, betekent het niet automatisch dat u onmiddellijk gehackt wordt — maar het betekent wél dat één hele klasse van aanvallen probleemloos zou werken. En als dat lukt, lukt vermoedelijk ook de hele lijst hierboven.

Goede uitkomst: de test faalt op LocalMachine-scope (admin-only) en faalt op CurrentUser-scope omdat een GPO-policy effectief is. Dat betekent dat uw IT-afdeling PowerShellëxecution serieus heeft genomen.
Slechte uitkomst: de test slaagt op CurrentUser-scope. Dat betekent dat uw werkplek-beleid PowerShell als convenience-tool ziet, niet als attack-vector. Tijd voor het gesprek met IT-/Security-team over de tegenmaatregelen hierboven.

Hoe nu verder?

Drie concrete vervolgstappen die elke IT-manager binnen een week kan zetten:

  • Audit uw ExecutionPolicy over alle endpoints (Get-ExecutionPolicy -List via Intune/SCCM-rapport). Welk percentage zit op Unrestricted? Waar?
  • Schakel Script Block Logging in via GPO. Geen actie verandert, maar u krijgt zichtbaarheid. Vereiste vooraf voor elke serieuze maatregel daarna.
  • Pilot Constrained Language Mode op één team. Meet false-positives. Schaal op naar de hele organisatie.

iCt Horse helpt organisaties met evidence-based security research. Niet met PowerPoints — met werkende tests. Voor een audit van uw endpoint-configuratie: info@icthorse.nl.


Bron-pagina: https://icthorse.nl/wpb-test/ · iCt Horse Security Research · KvK 96787112