Trin 5 af 8 · Windows

Windows-servere

Service-agenten er en Windows-tjeneste. Den henter certifikater fra appliancen og installerer dem på serveren. I forbinder serveren med én linje, som I kopierer fra appliancen.

Før I starter

I skal bruge:

En Windows-server med Windows Server 2016 eller nyere.
Et administratorlogin til serveren.
At serveren kan nå appliancen direkte over HTTPS, eller nå sslbrain.com og cloud.sslbrain.com på port 443. Står serveren et andet sted end appliancen, så se Servere uden for jeres netværk.
Hvis App Control (WDAC), AppLocker, antivirus eller EDR begrænser software på serveren, så forbered godkendelse af agent og scripts med jeres sikkerhedsadministrator før installation.

Forbind serveren

Åbn Servere i sslbrain, og klik på Installer service-agent. Knappen står øverst på siden og under listen, så længe appliancen er den eneste server.

Klik på Kopiér under Windows (anbefalet). Det er den første linje på siden, og den ser sådan ud:

msiexec /i https://<appliance>/agent.msi /qb INSTALLCODE=<kode> DESTINATIONS="https://<appliance>,cloud"

Åbn en kommandoprompt eller PowerShell som administrator på serveren, indsæt linjen, og tryk Enter.

Serveren henter den nyeste agent fra appliancen, installerer den og forbinder direkte til appliancen med koden. /qb viser installationens statusvindue, og går noget galt, står fejlen på skærmen. Efter et minut eller to står serveren under Servere.

Koden og appliancens adresse er allerede sat ind i linjen. Åbner I siden fra Servere, og er der ingen åben installationskode, opretter appliancen selv én uden sidste dag og skriver det i revisionsloggen. Samme kode virker på så mange servere, I vil, til I lukker den under Installationskoder længere nede på siden. Der opretter I også flere koder og giver en kode en sidste dag. Lukker I den sidste åbne kode, viser siden ingen kommando, før I klikker på Lav en ny kode og vis kommandoen.

Linjen har sslbrain Cloud efter appliancen som failover, så længe Tillad agentkommunikation via Cloud er slået til under Indstillinger › Sikkerhed, og appliancen er forbundet til sslbrain Cloud. Ellers står kun appliancens adresse:

msiexec /i https://<appliance>/agent.msi /qb INSTALLCODE=<kode> DESTINATIONS=https://<appliance>

Anførselstegnene om listen med cloud skal med, så listen når msiexec som én værdi fra både kommandoprompten og PowerShell. Uden cloud i listen bruger agenten ikke sslbrain Cloud. Skal den have Cloud senere, så klik på Genaktivér Cloud for denne agent på serverens side under Servere.

Bruger appliancen sit eget selvsignerede certifikat, stoler Windows ikke på det, og linjen henter i stedet agenten fra sslbrain.com. Agenten forbinder derefter direkte til appliancen, og DESTINATIONS følger samme regel som ovenfor:

msiexec /i https://sslbrain.com/agent.msi /qb INSTALLCODE=<kode> DESTINATIONS="https://<appliance>,cloud"

Serveren skal da kunne nå sslbrain.com på port 443. Giv appliancen et rigtigt certifikat, så hentes agenten fra appliancen selv (Gratis navn).

Forbind via sslbrain Cloud

Kan serveren ikke nå appliancen direkte, så åbn Serveren kan ikke nå appliancen direkte på siden, og brug linjen der:

msiexec /i https://sslbrain.com/agent.msi /qb INSTALLCODE=<kode>

Agenten finder appliancen gennem sslbrain Cloud med koden. Cloud kan hverken læse eller ændre det, appliancen og agenten sender hinanden (Servere uden for jeres netværk).

Sektionen findes kun, når Tillad agentkommunikation via Cloud er slået til under Indstillinger › Sikkerhed.
Alle licenser kan forbinde via Cloud. Dækker licensen ikke Cloud-forbindelse, står serveren som Blokeret under Servere og får ingen opgaver, før den skiftes til direkte forbindelse, eller licensen opgraderes (Servere uden for jeres netværk).

Flere servere på én gang

Den første linje virker på hver server for sig, også fra et script eller et værktøj til softwareudrulning. Skal serverne ikke hente agenten selv, eller har de ikke adgang til internettet, så åbn Flere servere, GPO eller uden internet, klik på Hent MSI, fordel sslbrain-agent.msi, og kør linjen med den lokale fil i den mappe, hvor filen ligger. Linjen har samme DESTINATIONS som den første linje. Den har /qn og viser ingen vinduer, fordi et opstartsscript eller et udrulningsværktøj kører den, uden at nogen ser skærmen:

msiexec /i sslbrain-agent.msi /qn INSTALLCODE=<kode> DESTINATIONS="https://<appliance>,cloud"

Med en GPO: Rul service-agenten ud på mange Windows-servere.

Agenten til Windows på ARM64 hentes under Andre udgaver som sslbrain.com/agent-arm64.zip.

Serveren dukker op

En server, der forbinder med koden, er godkendt og står under Servere. sslbrain finder selv de tjenester på serveren, der bruger certifikater, og viser dem under Tjenester.

En server, der ligner en geninstallation af en server, som allerede er forbundet, venter i stedet under Servere, der venter på godkendelse på siden Installer service-agent.

Sammenlign Agentnøgle med den nøgle, agenten har skrevet i sin log på serveren (Logfiler).
Klik på Godkend.

Kolonnen Type under Servere viser, om serveren er forbundet Lokal eller Via Cloud.

Næste skridt

Bevis, at domænet er jeres, så sslbrain kan få certifikater til det: Bevis, at domænet er jeres.

Hvis det fejler

Linjen gør tilsyneladende ingenting: i PowerShell vender prompten tilbage med det samme, mens installationen kører videre i sit eget vindue. Vent et par minutter, og tjek tjenesten med Get-Service sslbrainagent. Kør linjen med /l*v C:\Windows\Temp\sslbrain-agent.log til sidst for at få en log over installationen.
Installationen stopper med SSLBrain Agent needs its appliance eller Angiv CODE eller SERVER: linjen mangler koden. Kopiér den igen fra Installer service-agent.
msiexec kan ikke åbne adressen: serveren kan ikke nå adressen i linjen, appliancen eller sslbrain.com. Brug Hent MSI og den lokale linje under Flere servere, GPO eller uden internet, eller linjen under Serveren kan ikke nå appliancen direkte.
Serveren står som Blokeret: den er forbundet via sslbrain Cloud, og licensen dækker det ikke. Åbn serveren, og klik på Skift til direkte (Servere uden for jeres netværk).
Koden står som Lukket eller Udløbet: åbn Installer service-agent fra Servere. Siden viser en åben kode eller opretter selv en ny. Står der Ingen installationskode er åben, så klik på Lav en ny kode og vis kommandoen.
Serveren dukker ikke op: Agenten melder sig ikke.
Certifikatet bliver ikke installeret: Installationen fejler.

Logfiler

Hvad	Hvor
Agentens log, én fil pr. dag	`C:\ProgramData\sslbrain\logs\agent-<dato>.log`
Opdateringer af agenten	`C:\ProgramData\sslbrain\logs\update-msiexec-<version>-<tid>.log`

Tjenesten hedder sslbrainagent, og i tjenestelisten “sslbrain agent”. Status og de seneste linjer i loggen:

Get-Service sslbrainagent
Get-Content "C:\ProgramData\sslbrain\logs\agent-$(Get-Date -Format yyyy-MM-dd).log" -Tail 50

En server, der havde agenten før version 1.4.0, beholder mappen og nøglen i registreringsdatabasen med de store bogstaver, de fik dengang. Windows læser dem som de samme navne.

Registreringsdatabasen

Agentens indstillinger står i HKLM\SOFTWARE\sslbrain. Værdier under HKLM\SOFTWARE\Policies\sslbrain går forud, så de kan sættes med en GPO. Genstart tjenesten efter en ændring med Restart-Service sslbrainagent.

Alle værdierne står under Indstillinger i registreringsdatabasen.

Godkend agenten i Windows-sikkerhedspolitikker

App Control for Business er det nuværende navn for Windows Defender Application Control (WDAC). Det er samme teknologi. AppLocker er en separat kontrol; antivirus og EDR kan desuden træffe beslutninger om filer, scripts og adfærd.

Her kan jeres sikkerhedsadministrator forberede målrettede regler. I skal have ret til at administrere de relevante politikker, den faktisk hentede MSI og de installerede filer, en referenceserver med samme Windows-udgave/build og sikkerhedsindstillinger samt Windows-policyværktøjer (ConfigCI eller AppLocker). Behold jeres Windows-grundpolitik, en backup af politikken og en procedure til gendannelse. Funktionerne varierer med OS-versionen. Eksemplerne nedenfor laver lokale XML-forslag og undersøger filer; de anvender ingen politik. Test forslagene gennem jeres normale audit-/pilot- og håndhævelsesproces før bred udrulning. Audit alene beviser ikke, at scripts virker under håndhævelse.

Find de faktiske filer

Den 9-10-2026 undersøgte vi den offentlige x64-agent.msi, version 1.4.2. MSI-tabellerne installerer C:\Program Files\sslbrain\sslbrainagent.exe som sslbrainagent, vist som “sslbrain agent”, under LocalSystem. Kontrollér PathName og StartName på jeres server; en ældre installation eller et andet drev kan afvige.

Både MSI og dens udpakkede EXE indeholder en Authenticode-signatur med et slutcertifikat, der har CN=FairSSL A/S, O=FairSSL A/S, C=DK, virksomhedsnummer 33075782 og udsteder DigiCert Trusted G4 Code Signing RSA4096 SHA384 2021 CA1. Slutcertifikatets SHA-256-fingeraftryk er 8854997a1e37006307ed8f985df5142021f9edfd58422d455078dd5b7ad45dab. Det er en observeret identitet, ikke en policystreng til kopiering. Linux-værktøjet osslsigncode verificerede begge signaturer, kæder og tidsstempler; Windows-status fra Get-AuthenticodeSignature er ikke verificeret. Verificér egne filer i Windows, inklusive certifikattillid og adgang til tilbagekaldelseskontrol. Godkend ikke en fil med manglende eller ugyldig signatur uden at undersøge den.

Gem den hentede installer som sslbrain-agent.msi i den aktuelle mappe, og undersøg den og den installerede EXE:

$exe = 'C:\Program Files\sslbrain\sslbrainagent.exe'
Get-CimInstance Win32_Service -Filter "Name='sslbrainagent'" |
    Select-Object Name, StartName, PathName
$files = @('.\sslbrain-agent.msi', $exe)
foreach ($file in $files) {
    $s = Get-AuthenticodeSignature -LiteralPath $file
    [pscustomobject]@{
        File = $file; Status = $s.Status; Detail = $s.StatusMessage
        Subject = $s.SignerCertificate.Subject
        Issuer = $s.SignerCertificate.Issuer
        Thumbprint = $s.SignerCertificate.Thumbprint
    }
}
(Get-Item -LiteralPath $exe).VersionInfo |
    Select-Object ProductName, OriginalFilename, FileVersion
Get-FileHash -LiteralPath $exe -Algorithm SHA256

Den undersøgte EXE har produkt sslbrain agent, OriginalFilename=SslBrainAgent.dll og filversion 1.4.2.0. Originalnavnet er en signeret ressourceattribut, selv om filen på disken ender på .exe. Hele EXE-filens SHA-256 er ccee898b41b98af4a1382426edb013f0be4bc8e084a84dfdb0d7bcb2698b131c; brug den kun til at identificere denne undersøgte build. App Controls hashregler bruger Authenticode/PE-image-hash, som adskiller sig fra Get-FileHash; lad policyværktøjet beregne dem. Certifikatfingeraftrykket ovenfor er SHA-256, mens det viste certifikats Thumbprint normalt er SHA-1. Det undersøgte slutcertifikats SHA-1-thumbprint er C487B12B87298E601D5CEEEB7239829AC795008A.

MSI’en indeholder én EXE, ikke separate applikations-DLL’er. Dens bundle indeholder managed assemblies, blandt andet SslBrainAgent.dll og System.Management.Automation.dll, og fem native DLL’er: getfilesiginforedist.dll, microsoft.management.infrastructure.native.unmanaged.dll, PowerShell.Core.Instrumentation.dll, pwrshplugin.dll og sni.dll. De native filer indeholder Microsoft-signaturer; deres Windows-tillidsstatus og hvilke filer en bestemt opgave indlæser er ikke verificeret. Linux-verifikation kunne ikke bygge deres udstederkæder. Kontrollér de faktisk indlæste/udpakkede DLL’er enkeltvis, i stedet for at behandle dem som FairSSL-signerede filer. Politikker med .NET Dynamic Code Security kræver også særskilt validering af managed assemblies.

Formål	Standardplacering i den undersøgte implementation
Hentet opgave og udpakkede filer	`C:\ProgramData\sslbrain\work\<task-id>\package.tar` og `extracted\` under samme opgavemappe
Verificeret kopi til EXE-stages og PowerShell-fallback	`.verified-<random>.ps1` eller `.exe` ved siden af originalfilen i opgavens udpakningsmappe
Tool-sti defineret i kode, ikke kaldt i 1.4.2	`C:\ProgramData\sslbrain\tools\<tool-name>\`
Hook-sti defineret i kode, ikke kaldt i 1.4.2	`C:\ProgramData\sslbrain\hooks\`
Hentning og anvendelse af opdatering	`C:\ProgramData\sslbrain\update\staging\`, derefter `apply\`; kopieret updater-EXE: `apply\SslBrainAgent.exe`
Opdaterings-MSI og rollbackkopier	`update\apply\target\`, `update\apply\previous\` og `update\installed\<version>\` under datamappen
Agent- og opdateringslogs	`C:\ProgramData\sslbrain\logs\` (Logfiler)

DataPath kan ændre opgave-/opdateringsdataenes placering. ToolsPath konfigurerer tool-stien defineret i koden; denne downloadkode og hook-assembleren kaldes ikke i 1.4.2. .NET-værten for single-file-programmer udpakker native biblioteker under DOTNET_BUNDLE_EXTRACT_BASE_DIR, hvis den er sat, ellers under serviceprocessens %TEMP%\.net. Den endelige mappe afhænger af servicens miljø og bundle; den er ikke observeret i Windows. Find den i jeres proces-/modulinventar eller en blokeringshændelse. Stierne identificerer filer til undersøgelse; de anbefaler ikke at tillade eller undtage hele skrivbare mapper.

Regler i App Control og AppLocker

Undersøg signaturer og filmetadata ovenfor. Kopiér kun den verificerede reference-EXE og eventuelle særskilt verificerede afhængighedsfiler til reference-agent i arbejdsmappen. Hold andre downloads ude af den.
For App Control: generér FilePublisher-forslag fra disse reelle filer:
Terminal window
```
New-CIPolicy -ScanPath '.\reference-agent' -FilePath '.\agent-candidate.xml' `
    -Level FilePublisher -Fallback Hash -UserPEs
```
Gennemgå XML-reglens signer, filattribut og minimumsversion for hver regel. For denne EXE er standardfilattributten SslBrainAgent.dll, ikke navnet på disken. Behold både udgiver, den enkelte fils identitet og en passende minimumsversion; det kan følge nyere signerede versioner, så længe identitet og udstederkæde er de samme. Nyt certifikat/kæde eller filidentitet kræver gennemgang. Undersøg hver Hash-fallback, og forny reglerne ved ændrede binærfiler. Erstat ikke manglende filmetadata med en CA-regel eller en regel for alt fra FairSSL. Integrér godkendte regler i jeres grundpolitik med jeres policyværktøj; scanningen er ikke en komplet udrulningspolitik. Behold grundpolitikkens scripthåndhævelse, og gennemgå de genererede policyvalg; anvend ikke scanningens XML direkte. Håndtér MSI’en separat i værktøjets installerregler ud fra den faktisk signerede MSI. Giv aldrig generel tillid til DigiCert eller en anden CA.
For AppLocker: brug Create New Rule → Publisher → Browse i den relevante EXE-, MSI- og, hvis aktiveret, DLL-regelsamling. Vælg den reelle referencefil. Behold udgiver, produkt og binærnavn, og vælg den testede minimumsversion og nyere versioner. Gennemgå wildcardfelter fra værktøjerne. Brug servicens faktiske konto til EXE-/DLL-regler og installationskontoen til MSI-regler. Automatiske opdateringer kører den kopierede updater og msiexec.exe som SYSTEM, så MSI-regler skal også dække S-1-5-18, når opdateringer bruges. Kontrollér, at den eksisterende Windows-grundpolitik tillader de nødvendige systemfiler msiexec.exe og schtasks.exe. Kontrollér, om jeres AppLocker-opsætning håndhæver regler for services, at Application Identity kører, og hvilke regelsamlinger der håndhæves. For standard-EXE’en under LocalSystem laver følgende et forslag og vurderer filen:
Terminal window
```
Get-AppLockerFileInformation -Path $exe |
    New-AppLockerPolicy -RuleType Publisher -User 'S-1-5-18' -Xml |
    Set-Content '.\agent-applocker-candidate.xml'
Test-AppLockerPolicy -XmlPolicy '.\agent-applocker-candidate.xml' `
    -Path $exe -User 'S-1-5-18'
```
Test-AppLockerPolicy kontrollerer filens match mod regler; den tester ikke PowerShell-adfærd, effektiv GPO-sammenlægning eller servicekørsel. Undersøg den effektive politik, og test den faktiske service og nødvendige opgaver på referenceserveren. Når den kopierede updater findes, så vurder også C:\ProgramData\sslbrain\update\apply\SslBrainAgent.exe med Test-AppLockerPolicy for S-1-5-18; en regel, der kun bygger på installationsstien, dækker den ikke. Mangler en afhængighed en brugbar udgiveridentitet, så brug et gennemgået hashforslag for den enkelte fil og opdatér det med filen. Tillad ikke hele ProgramData, Temp, arbejdsmappen eller alt via powershell.exe som godkendelse af deploy-scripts.

Deploy-scripts skal godkendes separat

En EXE-task-stage kører som en separat proces fra sin .verified-<random>.exe-kopi i opgavens udpakningsmappe. Den kræver sin egen målrettede publisher-/FilePublisher- eller filhashregel genereret fra det faktiske verificerede program og dets afhængigheder. Service-EXE-reglen og sslbrains pakkesignatur godkender den ikke i Windows. Brug filidentitet frem for at tillade den skrivbare mappe eller tilfældige sti.

I den undersøgte 1.4.2-implementation opretter det indbyggede PowerShell SDK et runspace og kalder AddScript(scriptContent) på scripttekst. Denne vej kører ikke en Authenticode-godkendt .ps1-fil via dens sti. En FilePublisher-regel for service-EXE’en, en pakkesignatur eller en Authenticode-signatur på originalscriptet dokumenterer derfor ikke, at dette script i hukommelsen får FullLanguage-godkendelse under App Control.

Er den indbyggede vært utilgængelig eller fejler initialiseringen, starter fallback powershell.exe med -ExecutionPolicy Bypass og en kodet bootstrap. Den sender input via stdin og kalder en midlertidig verificeret scriptfil via sti. Bypass er et valg af execution policy for processen; det kan ikke tilsidesætte en execution policy fra Group Policy og giver ingen tilladelse i App Control eller AppLocker. Bootstrappens .NET-kald og scripts kan ramme sprogbegrænsninger. Fallback er ikke en genvej til godkendelse. En script-runtime-fejl, inklusive en sprogbegrænsningsfejl efter eksekveringsstart, udløser ikke automatisk fallback.

GPO-valget Allow only signed scripts svarer til AllSigned for scriptfiler. Execution policy er en sikkerhedshjælp, ikke en application-control-sikkerhedsgrænse: MachinePolicy/UserPolicy går forud for procesindstillinger, men AllSigned alene beviser ikke, at AddScript-teksten blev kontrolleret som en signeret fil. Under App Control afhænger PowerShells adfærd af OS/API og PowerShell-version: ikke-godkendt kode kan begrænses eller blokeres. Det indbyggede SDK er PowerShell 7.4.7; fallback er Windows PowerShell. Kontrollér både PowerShell Core- og Windows PowerShell-GPO-indstillinger: de administreres separat, med det dokumenterede valg Use Windows PowerShell Policy setting for Core. Under en effektiv GPO AllSigned kræver fallback-scriptfilen sin egen gyldige Authenticode-signatur og udgivertillid; en separat pakkesignatur leverer ikke dette. Antag ikke, at resultatet i administratorens interaktive shell beskriver servicens runspace.

sslbrains separate pakkesignaturer og ScriptPolicy styrer pakkeintegritet og godkendelse inde i sslbrain. De er adskilt fra Windows Authenticode og Windows-politikker. Behold signaturkontrol af pakker/downloads/opdateringer: version 1.4.2 verificerer opdateringskatalog og releasemanifest mod indbyggede produktionsankre og kontrollerer MSI mod signerede størrelser/hashværdier. Det er ikke en påstand om, at updateren udfører Windows Authenticode-validering.

I kan forberede program-/installerregler nu. Her er ingen verificeret opskrift på FullLanguage-godkendelse af den nuværende deploy-vej i hukommelsen under en restriktiv scriptpolitik. Validér det konkrete moduls discovery, deployment og verification under jeres politik før brug; en kørende service eller vellykket check-in er utilstrækkeligt. Kræver jeres regler, at alle deployments kører som policygodkendte signerede scriptfiler, kræver denne vej en implementationsændring. Gem kravet og den fejlende operation til support; svæk ikke application control, deaktivér ikke scripthåndhævelse, og ændr ikke execution policy for at få det til at virke.

Antivirus og EDR

Behold scanning, AMSI og adfærdsovervågning. Gennemgå leverandørens faktiske alarm, filhash, signatur, procestræ og blokerede operation. Foretræk en afgrænset godkendelse af den identificerede fil og berørte enhedsgruppe med dato for gennemgang/udløb efter leverandørens produktdokumentation. Vurdér igen ved opdatering. En programgodkendelse godkender ikke automatisk underprocesser, scripts, ændringer i certifikatlager eller servicegenstart. Der er ingen garanti for kompatibilitet med alle antivirus-/EDR-politikker.

Microsoft Defender for Endpoint understøtter eksempelvis filhashbaserede Allow-indikatorer og certifikatindikatorer. En certifikatindikator dækker flere filer, så en indikator for én fil er mere målrettet, når den er tilstrækkelig. Funktionerne kræver dokumenteret licens, rettigheder, Defender-konfiguration og enhedsafgrænsning; brug leverandørvejledningerne nedenfor. Scanningsundtagelser i Defender Antivirus er ikke det samme som EDR-godkendelse. Undtag ikke hele agent-, arbejds-, opdaterings- eller .NET-udpakningsmapper, og lav ikke brede procesundtagelser. Andre leverandører kræver deres egen dokumenterede godkendelsesprocedure.

Netværksgodkendelse er separat: tillad den konfigurerede appliances HTTPS-vært/port (normalt 443), navneopslag og, når Cloud bruges, cloud.sslbrain.com:443; installation fra den offentlige download kræver sslbrain.com:443. Opdateringer i den undersøgte kode hentes fra den konfigurerede appliance over HTTPS. For en agent, hvis gemte destinationsliste kun indeholder Cloud, afviser release 1.4.2 staging af opdatering, fordi denne Cloud-opdateringskilde ikke er implementeret; antag ikke, at Cloud-kommunikation også giver denne opdateringsvej. Kontrol af signaturtillid/tilbagekaldelse kan kræve adgang til certifikatudstedernes tjenester efter jeres netværkspolitik. Agenten kræver ingen indgående port. Se Sådan når agenten appliancen for jeres forbindelsestype.

Find en blokering, og registrér hvad der er testet

Sammenhold samme tidspunkt og fil/proces i agentlog, MSI-log og disse Windows-kanaler:

Event Viewer-kanal	Hvad I kontrollerer
`Microsoft-Windows-CodeIntegrity/Operational`	3076: ville blokere i audit; 3077: blokeret under håndhævelse; forbind 3089-signaturdetaljer via ActivityID. 3099 viser en indlæst politik.
`Microsoft-Windows-AppLocker/EXE and DLL`	AppLocker 8003: ville blokere i audit; 8004: blokeret. Kontrollér fil, regel og bruger-SID.
`Microsoft-Windows-AppLocker/MSI and Script`	AppLocker 8006/8007: audit/blokering. App Control 8028/8029: scriptværtens audit-/håndhævelsesbeslutning; 8038: tilknyttede signaturdetaljer. Værten afgør begrænsning eller blokering. Microsoft dokumenterer, at kanalen mangler på Server Core.
`Microsoft-Windows-PowerShell/Operational` eller `PowerShellCore/Operational`	Værtsfejl og, når aktiveret, script-block-hændelser som 4104. PowerShell Core kræver registreret event provider, før den kan skrive disse hændelser. Sammenhold med agentloggens indbyggede vært-/fallbackbeskeder.
`Microsoft-Windows-Windows Defender/Operational` og EDR-konsollen	Detektion, karantæne, ASR eller anden leverandørhandling; følg vejledningen til den faktiske alarm.

Get-ExecutionPolicy -List
Get-AppLockerPolicy -Effective -Xml
Get-WinEvent -FilterHashtable @{
    LogName='Microsoft-Windows-CodeIntegrity/Operational'
    Id=3076,3077,3089,3099
    StartTime=(Get-Date).AddHours(-1)
} | Select-Object TimeCreated, Id, Message

Kør disse læsekommandoer med relevante administratorrettigheder. En tom kanal eller manglende blokeringshændelse beviser ikke godkendelse. Kontrollér effektiv politik, signaturstatus, serviceidentitet, afhængighedsfil og den præcise fejlende fase. Script-block-logs kan indeholde følsomme scripts/input; beskyt diagnoseevidens med adgangskontrol, og fjern følsomme oplysninger før deling.

Artefaktundersøgelsen og kildestierne ovenfor er kontrolleret den 9-10-2026 mod release 1.4.2. Windows-sikkerhedsadfærden er dokumenteret af Microsoft; eksekverings- og opdateringsdetaljerne kommer fra releasens implementation. Der er ikke udført Windows-runtime-test under App Control, AppLocker, antivirus eller EDR til denne guide. Registrér OS/build, agentversion, politikker, leverandørindstillinger og resultat af installation, servicestart, discovery, deployment, verification og opdatering i jeres pilot.