Problem med LSA-skydd och EDR-agenter

Question

Problem med LSA-skydd och EDR-agenter

Sophia Meier 40

Vi har nyligen aktiverat strikt LSA-skydd med RunAsPPL=1 på våra domänkontrollanter för att stärka säkerheten. Efter ändringen har vissa tredjeparts-EDR-agenter fått problem med processisolering, och Event ID 12 skrivs i Security-loggen.

Ett konkret exempel är att EDR-agenten på några av våra domänkontrollanter inte längre kan starta sina skyddade processer som tidigare. Det verkar vara kopplat till att vissa av agentens egna drivrutiner inte uppfyller kraven för PPL.

Vi har kontrollerat loggarna och verifierat att problemen började efter att LSA Protection aktiverades. Vi vill därför förstå hur vi kan granska de aktuella drivrutinsfilerna och kontrollera om de är korrekt signerade för att fungera med PPL.

Finns det någon rekommenderad metod för att auditera och signera anpassade drivrutinsbinärer så att de uppfyller PPL-kraven? Vi skulle också uppskatta tips från Microsofts tekniker om vilka verktyg och loggar vi bör använda för att felsöka detta på ett säkert sätt.

0 kommentarer

1 svar

Ditt svar

Answer 1

Hej Sophia Meier,

När du aktiverar LSA‑skydd med RunAsPPL=1 krävs att alla binärer laddas och skyddas av LSA‑processen är signerade med Microsofts ELAM/PPL‑policyer. Om ytterligares‑EDR‑drivrutiner inte uppfyller dessa krav kommer att blockeras och du ser Event ID 12 i Security‑loggen. För att granska detta bör du använda sigcheck.exe -i <driver.sys> från Sysinternals eller Get-AuthenticodeSignature i PowerShell för att kontrollera att drivrutinen är signerad med en certifikatkedja som stöder Protected Process Light. Du kan också aktivera Driver Verifier mot den specifika drivrutinen för att fånga inkompatibla anrop i isolerat läge.

När det gäller att signera egna binärer är det inte möjligt att själv skapa en giltig PPL-signering; endast Microsoft kan utfärda dessa signeringspolicys. Leverantören av EDR‑agenten måste tillhandahålla en version av sina drivrutiner som är signerade och godkända för PPL‑miljöer. Din roll blir att auditera med ovanstående verktyg, samla in minidumps och loggar från Applications and Services Logs → Microsoft → Windows → Kernel‑Isolation‑UserMode, och sedan eskalera till leverantören med bevisen. Microsofts rekommenderade metod är att alltid verifiera signaturstatus och EKU‑fält i drivrutinscertifikatet, och aldrig försöka kringgå PPL‑kraven.

Om mitt svar är användbart för dig, vänligen tryck på Acceptera svaret för att stödja mig.

Tack,

Domic.