Dags för del 4 i vår serie om Defender for Endpoint. Först gick vi igenom startguiden, därefter avancerade inställningar, och nu senast rekommendationer på hur man konfigurerar sin antiviruspolicy.
Jag har sett fram emot att skriva den här delen, för utöver antivirus och EDR är Attack Surface Reduction (ASR) en funktion som verkligen kan göra skillnad för säkerheten.
Till skillnad från antivirus och EDR så fokuserar inte ASR på skadlig kod eller misstänkt beteende. Istället handlar det om (precis som det låter) att minska attackytan genom att stänga av eller begränsa funktioner som ofta blir angripna.
I den här posten kommer jag dels att visa hur man skapar ASR-policyer, men också förklara vad varje regel innebär och ge rekommendationer på konfiguration.
Delar i serien
Här är en översikt över de delar som ingår i serien. Jag uppdaterar länkarna löpande allt eftersom nya inlägg blir publicerade.
- Del 1 – Kom igång
- Del 2 – Advanced features
- Del 3 – Antivirus & Intune-portalen
- Del 4 – ASR-regler(den här artikeln)
- Del 5 – Onboarding av enheter, device groups och RBAC-modellen
- Del 6 – EDR, AIR, advanced hunting och incidenthantering
Skapa en ASR-policy
Som jag skrev i förra posten så hanteras policyer olika beroende på licens och konfiguration.
Om du använder en Enterprise-version (Defender for Endpoint Plan 1 eller Plan 2) kan du konfigurera ASR-policyer i Defender-portalen under menyn ”Endpoint → Configuration management → Endpoint security policies”.
Använder du däremot en Business-version så går det inte att konfigurera dessa policyer i Defender-portalen. Då måste du använda Microsoft Intune.
💡 Tips: Om du vill veta hur man kopplar ihop Defender-portalen med Microsoft Intune så har jag skrivit om det i Del 3 – Antivirus & Intune-portalen.
För att skapa en ASR-policy i Microsoft Intune
- Logga in i Intune-portalen.
- Klicka på Endpoint security i menyn.
- Scrolla ner till sektion Manage och välj Attack Surface Reduction.
- Klicka på Create Policy och välj:
- Platform: Windows
- Profile: Attack Surface Reduction Rules

- Klicka på Create.
- Fyll i namn och beskrivning.
💡 Tips: Det är bra att använda en namnstandard som gör det enkelt att överblicka vad varje policy gör. Jag brukar använda formatet
plattform-funktion-målgrupp.Plattform kan vara Win, macOS, Linux, iOS eller Android.
Funktion beskriver vad policyn hanterar, till exempel AV (Antivirus), ASR (Attack Surface Reduction), DC (Device Control), FW (Firewall).
Målgrupp anger vilka enheter som omfattas av policyn, till exempel Clients, Servers eller Virtual.
Exempel på namn:
- macOS-AV-Clients
- Win-AV-Clients
- Win-ASR-Clients
- Klicka på Next för att fortsätta med konfigurationen.
- Konfigurera ASR-regler. En beskrivning av varje regel finns längre ner i denna artikel. När du är nöjd klickar du på Next för att fortsätta.
- Scope tags används för att gruppera resurser och styra vad olika administratörer ska kunna se och hantera. Detta är användbart i stora miljöer, men ligger utanför scope för den här guiden. Klicka på Next för att fortsätta.
- På sidan Assignments lägger du till vilka grupper som ska använda denna policy. Det går även att lägga till grupper som ska vara exkluderade. Klicka på Next för att fortsätta.

⚠️ Obs! Det går att skapa Device Groups i Defender-portalen, men eftersom dessa grupper är unika för Defender-portalen och inte används av andra tjänster brukar jag rekommendera vanliga säkerhetsgrupper i Microsoft Entra istället.
Det finns ett undantag och det är Automated Investigation & Response (AIR). Men vi återkommer till denna funktion i en senare artikel.
- På sista sidan (Review + create) kan du kontrollera alla inställningar. När du är nöjd klickar du på Save.
⚠️ Viktigt att tänka på:
- ASR stöds bara på Windows-klienter och Windows-servrar (inte macOS, Linux eller mobila enheter).
- Tänk på att du kan behöva olika ASR-policyer för olika ändamål, till exempel en för servrar, en annan för klienter som främst använder kontorsprogram och en tredje för utvecklare.
- Börja med att sätta alla regler i audit-läge och analysera vad som påverkas. När du känner dig trygg med vilka undantag som behövs kan reglerna ändras till Block-läge.
- Det går att skapa undantag per regel för alla ASR-regler utom ”Block persistence through WMI event subscription”. Så även om du upptäcker problem med någon fil eller process behöver du inte stänga av hela regeln.
Attack Surface Reduction – inställningar och rekommendationer
I det här avsnittet går vi igenom alla ASR-regler för sig. Målet är att beskriva varje regel så enkelt och tydligt som möjligt.
⚠️ Obs! Jag vill än en gång poängtera att detta inte är en “How to” som passar alla, utan snarare en “How I do”. Jag tror att mina rekommendationer fungerar bra för många, men det finns såklart situationer där du kan behöva anpassa inställningarna.
Block Adobe Reader from creating child processes
Denna regel hindrar Adobe Reader från att starta nya processer, något som skadliga PDF-filer ofta utnyttjar.
Jag har ännu inte stött på något legitimt scenario som använder denna funktion.
Rekommendation: 🟢 På
Block process creations originating from PSExec and WMI commands
Denna regel blockerar processer som skapas via PsExec och WMI.
Angripare kan använda PsExec och WMI för att läsa ut information och köra kommandon. Samtidigt används dessa tekniker även av legitima verktyg för fjärradministration, till exempel Microsoft Endpoint Configuration Manager.
Om ni kör verktyg för fjärradministration som använder PsExec eller WMI rekommenderar jag att sätta regeln i audit-läge och analysera vad som blir påverkat. Baserat på resultatet kan ni välja att skapa undantag eller att fortsätta köra regeln i audit-läge.
Rekommendation: 🟡 På (beroende på miljö)
Block execution of potentially obfuscated scripts
Denna regel blockerar skript som är obfuskerade (avsiktligt ändrade för att göra dem svåra att läsa och analysera).
Angripare använder obfuskering för att dölja skadlig kod och försöka undgå säkerhetsanalyser. Vanliga exempel är att byta namn på variabler till slumpmässiga tecken eller att Base64-koda skriptet.
Rekommendation: 🟢 På
Block persistence through WMI event subscription
Angripare använder WMI event subscriptions för att trigga skadlig kod när specifika händelser inträffar, till exempel vid systemstart eller när en användare loggar in.
Detta är ett effektivt sätt att skapa ett fotfäste som finns kvar även efter en omstart. Eftersom koden går att lagra i WMI-databasen, istället för som filer på hårddisken, är den svår att upptäcka för traditionella antivirusprogram.
Denna regel blockerar nya, okända processer från att registrera den här typen av WMI event subscriptions.
Rekommendation: 🟢 På
Block Win32 API calls from Office macros
Det är ovanligt att Office-makron behöver anropa Win32 API:er, även om det förekommer i undantagsfall.
Angripare använder Win32 API:er för att komma åt mer avancerade funktioner, till exempel för att manipulera minne eller injicera kod i andra processer.
Jag rekommenderar att aktivera denna regel. Om något legitimt makro blir påverkat går det att lägga till undantag.
Rekommendation: 🟢 På (lägg till undantag vid behov)
Block Office applications from creating executable content
Denna regel hindrar Office-applikationer från att skapa körbara filer med skadligt innehåll.
Angripare kan använda makron för att skapa filer med skadligt innehåll och skriva dessa till disk. På så sätt etablerar de ett fotfäste som finns kvar på systemet även efter en omstart.
Jag rekommenderar att aktivera denna regel. Vid behov går det att lägga till specifika undantag.
Rekommendation: 🟢 På (lägg till undantag vid behov)
Block credential stealing from the Windows local security authority subsystem
Angripare försöker ofta läsa ut autentiseringsuppgifter, till exempel hashvärden och Kerberosbiljetter, från LSASS. Denna regel blockerar sådana försök.
Även legitima applikationer anropar LSASS, vilket innebär att regeln kan skapa en del falsklarm. I många fall är dock dessa anrop inte nödvändiga för applikationens funktion. Dessutom blir inte den anropande processen blockerad, utan endast försöket att läsa från LSASS-processens minne.
Jag rekommenderar att aktivera denna regel. Vid behov går det att lägga till specifika undantag.
Rekommendation: 🟢 På (lägg till undantag vid behov)
Block use of copied or impersonated system tools
Denna regel blockerar försök att köra kopierade eller förfalskade systemverktyg.
Rekommendation: 🟢 På
Block executable files from running unless they meet a prevalence, age, or trusted list criterion
Blockerar körbara filer (till exempel .exe, .dll eller .scr) om de är nya eller okända.
Hur bra denna regel fungerar beror väldigt mycket på miljön. I miljöer med relativt statiska och välkända applikationer kan den ge ett bra skydd. Men för till exempel utvecklingsteam som kompilerar program och uppdaterar verktyg löpande kan regeln generera många falsklarm.
Prevalence, dvs hur utbredd en fil är, baseras på Microsofts globala molndata. Om en fil bara finns på 10 datorer i hela världen anses den ha låg prevalence och blockeras.
Jag rekommenderar att börja i audit-läge och analysera vad som blir påverkat. Det här är en regel som kan behöva konfigureras olika för olika delar av organisationen – vissa kan köra den i block-läge, medan andra behöver undantag eller att regeln fortsätter köra i audit-läge.
Rekommendation: 🟡 Börja med audit och lägg till undantag vid behov.
Block JavaScript or VBScript from launching downloaded executable content
Denna regel blockerar JavaScript och VBScript från att starta körbara filer som har laddats ner från internet.
Angripare använder ofta skript för att ladda ner och köra skadliga filer som nästa steg i en attack.
Rekommendation: 🟢 På
Block Office communication application from creating child processes
Idag är det vanligt att angripare skickar mejl med skadligt innehåll, till exempel länkar eller bilagor, för att få Outlook att starta skript eller körbara filer. Denna regel blockerar Outlook från att starta nya processer, och blockerar dessa angrepp.
Rekommendation: 🟢 På
Block Office applications from injecting code into other processes
Denna regel blockerar Office-applikationer från att injicera kod i andra processer.
Den här tekniken används av angripare för att injicera skadlig kod i en annan process, och på så sätt kringgå säkerhetsfunktioner. Vid normal användning är det väldigt ovanligt att detta behövs.
Jag rekommenderar att aktivera denna regel. Vid behov går det att lägga till specifika undantag.
Rekommendation: 🟢 På (lägg till undantag vid behov)
Block all Office applications from creating child processes
Blockerar Office-applikationer från att starta nya processer.
Ett väldigt vanligt angreppssätt är att använda makron i Office-dokument för att ladda ner och köra skadlig kod. Denna attackvektor är så pass vanlig att makron i filer som kommer från internet (till exempel via e-post eller nedladdningar) är blockerade som standard i dag.
Jag rekommenderar verkligen att aktivera den här regeln. Samtidigt kan det finnas betrodda makron som behöver starta andra processer, och i sådana fall går det att lägga till specifika undantag.
Rekommendation: 🟢 På (lägg till undantag vid behov)
Block rebooting machine in Safe Mode
Denna regel blockerar försök att starta om datorn i felsäkert läge.
Många säkerhetsprodukter blir inaktiverade eller begränsade i felsäkert läge. Angripare försöker utnyttja detta för att kunna köra kommandon utan att bli blockerade.
Rekommendation: 🟢 På
Block Webshell creation for Servers
Ett webshell är ett skript som en angripare laddar upp på en webbserver för att kunna köra kommandon, ladda upp eller ner filer och behålla åtkomst till systemet.
Normalt sett brukar man inte kunna ladda upp egna skript på webbservrar. För att lyckas med detta måste angriparen först hitta en server som kör en sårbar applikation.
Denna regel blockerar försök att spara webshells på servrar.
Rekommendation: 🟢 På
Block untrusted and unsigned processes that run from USB
Denna regel blockerar att osignerade eller ej betrodda program startar från flyttbara medier.
Angripare använder flyttbara medier, till exempel USB-minnen, för att sprida skadlig kod. Detta var ett större problem förr när AutoRun startade program automatiskt när en enhet anslöts. I moderna Windows-versioner är AutoRun avstängt som standard.
I de flesta miljöer påverkar regeln inte normal användning, eftersom legitima applikationer sällan körs direkt från USB-enheter.
Rekommendation: 🟢 På
Use advanced protection against ransomware
Denna regel ger ett extra skydd genom att analysera programs beteenden och försöka upptäcka mönster som är typiska för ransomware.
Regeln fungerar som ett extra skyddslager ovanpå det vanliga antiviruset och ger ett ökat skydd mot nya eller okända ransomware-varianter.
Rekommendation: 🟢 På
Block executable content from email client and webmail
Blockerar Microsoft Outlook och populära webmail-tjänster från att starta körbara filer och skript.
Detta inkluderar bland annat:
- Körbara filer (.exe, .dll eller .scr)
- Skript (PowerShell .ps1, Visual Basic .vbs eller JavaScript .js)
- Arkivfiler (till exempel .zip-filer)
De flesta e-postklienter blockerar körbara filer och skript automatiskt. Denna regel fungerar därför som ett extra skyddslager och är ett bra komplement till det inbyggda skyddet.
Rekommendation: 🟢 På
Block abuse of exploited vulnerable signed drivers (Device)
Denna regel hindrar applikationer från att skriva kända sårbara drivrutiner till disk (även om de är korrekt signerade).
Applikationer med tillräcklig behörighet kan utnyttja sårbara drivrutiner för att få åtkomst till operativsystemets kernel och på så vis kringgå säkerhetsskydd eller manipulera systemet.
Regeln bygger på en blocklista över kända sårbara drivrutiner och ger ett bra skydd mot den här typen av attacker.
Rekommendation: 🟢 På
Attack Surface Reduction Only Exclusions
Här kan du ange filer eller mappar som ska exkluderas från alla ASR-regler. Dessa undantag påverkar bara ASR och gäller inte för antivirus eller EDR.
Eftersom dessa undantag gäller samtliga ASR-regler bör funktionen användas med försiktighet. I de flesta fall är det bättre att konfigurera per rule exclusion för specifika regler.

Rekommendation: ⚠️ Används endast vid behov
Enable Controlled Folder Access
Denna funktion hjälper dig skydda din viktigaste data från skadliga appar och hot, framförallt ransomware.
När funktionen är aktiverad får bara betrodda program skriva till skyddade mappar, till exempel Dokument, Bilder, Musik, Videor eller andra känsliga platser. Om ett program som inte är betrott försöker ändra filer blir åtgärden blockerad.
Controlled Folder Access är särskilt effektivt mot ransomware som ofta försöker kryptera användarens filer i just dessa mappar.
Detta är en kraftfull funktion, men jag rekommenderar att börja i audit-läge för att identifiera om ni behöver lägga till undantag för vissa applikationer.
Rekommendation: 🟡 Börja med audit och lägg till undantag vid behov.
Controlled Folder Access Protected Folders
Controlled Folder Access skyddar som standard ett antal vanliga användarmappar, till exempel Dokument, Bilder, Musik, Videor och Skrivbord.
Med denna inställning kan du lägga till egna mappar som ska vara skyddade.
Rekommendation: 🟡 Lägg till mappar vid behov.
Controlled Folder Access Allowed Applications
När Controlled Folder Access är aktiverat tillåts endast betrodda program att skriva till skyddade mappar. Program som inte är betrodda blockeras som standard.
Med denna inställning kan du lägga program som ska tillåtas, till exempel:
- egenutvecklade program
- äldre applikationer
- skript eller administrativa verktyg
Rekommendation: 🟡 Lägg till program vid behov.
Sammanfattning
Det här var del 4 i serien om Defender for Endpoint och en genomgång av Attack Surface Reduction (ASR) och de regler som går att konfigurera.
Förhoppningsvis gav artikeln tips på hur du kan använda ASR-regler för att stärka säkerheten, utan att påverka användarupplevelsen.
Har du frågor, egna erfarenheter eller arbetar på ett annat sätt i din miljö? Dela gärna med dig i kommentarerna så hjälps vi åt att göra guiden ännu bättre 👍






