Mit Software Restriction Policies (SRP bzw. „SAFER“, auf Deutsch „Richtlinien für Softwareeinschränkung“) läßt sich festlegen, welche Programme unter Windows ausgeführt (Whitelisting) bzw. nicht ausgeführt (Blacklisting) werden dürfen. Insbesondere läßt sich SAFER verwenden, um die Ausführung von Schadprogrammen – einschließlich Ransomware – zuverlässig zu verhindern. SAFER ist in allen Windows-Versionen ab XP verfügbar und muß lediglich konfiguriert werden.
Ab Windows 11 22H2 muss der Registry-Wert
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Srp\Gp]
"RuleCount"=dword:00000000
gesetzt werden, damit SAFER weiterhin funktioniert.
Als modernere Alternative bietet sich außerdem Windows Defender Application Control (WDAC) an, das in allen Versionen von Windows 10 und 11 funktioniert. Zur Erzeugung einer WDAC-Richtlinie können Sie meinen Web-Dienst verwenden.
Alle .reg-Dateien auf dieser Seite wirken ausschließlich auf Unterschlüssel von
[HKEY_LOCAL_MACHINE\
. Exportieren Sie also diesen Schlüssel etwa mit
regedit.exe
, bevor Sie meine .reg-Dateien verwenden, um jederzeit exakt den Originalzustand wiederherstellen zu können. SAFER nimmt ansonsten keine Änderungen am System vor.
SAFER wird stets über die Windows-Registry konfiguriert. Man muß aber nicht mit regedit.exe arbeiten, sondern kann die Registry-Einträge auch folgendermaßen erstellen:
Stefan Kanthak stellt unter dem Namen *_SAFER.INF mehrere Installationsskripte bereit, die sinnvolle und erprobte SAFER-Regeln automatisch in die Windows-Registry eintragen:
Nur Benutzer werden eingeschränkt | Auch Administratoren werden eingeschränkt | |
---|---|---|
Windows XP
Windows Server 2003 |
XP_SAFER.INF | XP_SUPER.INF |
Windows Vista
Windows 7 Windows Server 2008 |
NT6_SAFER.INF | NT6_SUPER.INF |
Windows 8
Windows 8.1 Windows 10 Windows 11 Windows Server 2012 Windows Server 2016 Windows Server 2019 Windows Server 2022 |
NTX_SAFER.INF |
*_SAFER.INF konfiguriert Windows so, daß Benutzer (also Nicht-Administratoren) Programme nur dort ausführen dürfen, wo sie keine Schreibrechte haben. Ein Benutzer kann somit ein Schadprogramm nicht zur Ausführung bringen, selbst wenn er wollte – wo er es ablegen kann, darf er es nicht ausführen, und wo er es ausführen dürfte, darf er es nicht ablegen.
*_SAFER.INF sollte man sich übrigens auch anschauen, wenn man lieber eigene Regeln mit secpol.msc oder direkt in der Registry erstellen möchte, denn Stefans Kommentare darin sind eine vorzügliche Dokumentation für SAFER.
SAFER kann man mit wenigen Einträgen in der Registry konfigurieren, die gut als Basis für eigene Erweiterungen dienen können:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers]
"AuthenticodeEnabled"=dword:00000000
"Levels"=dword:00031000
"DefaultLevel"=dword:00000000
"TransparentEnabled"=dword:00000002
"PolicyScope"=dword:00000001
"ExecutableTypes"=hex(7):41,00,43,00,4d,00,00,00,41,00,44,00,45,00,00,00,41,00,\
44,00,50,00,00,00,41,00,58,00,00,00,42,00,41,00,53,00,00,00,42,00,41,00,54,\
00,00,00,43,00,48,00,4d,00,00,00,43,00,4d,00,44,00,00,00,43,00,4f,00,4d,00,\
00,00,43,00,50,00,4c,00,00,00,43,00,52,00,54,00,00,00,44,00,4c,00,4c,00,00,\
00,44,00,52,00,56,00,00,00,44,00,53,00,00,00,45,00,58,00,45,00,00,00,48,00,\
4c,00,50,00,00,00,48,00,54,00,41,00,00,00,48,00,54,00,43,00,00,00,49,00,4d,\
00,45,00,00,00,49,00,4e,00,46,00,00,00,49,00,4e,00,53,00,00,00,49,00,53,00,\
50,00,00,00,4a,00,4f,00,42,00,00,00,4a,00,53,00,00,00,4a,00,53,00,45,00,00,\
00,4d,00,44,00,42,00,00,00,4d,00,44,00,45,00,00,00,4d,00,53,00,43,00,00,00,\
4d,00,53,00,49,00,00,00,4d,00,53,00,50,00,00,00,4d,00,53,00,54,00,00,00,4d,\
00,55,00,49,00,00,00,4f,00,43,00,58,00,00,00,50,00,43,00,44,00,00,00,50,00,\
49,00,46,00,00,00,50,00,53,00,31,00,00,00,52,00,45,00,47,00,00,00,53,00,43,\
00,52,00,00,00,53,00,43,00,54,00,00,00,53,00,48,00,53,00,00,00,54,00,4d,00,\
50,00,00,00,54,00,53,00,50,00,00,00,56,00,42,00,00,00,56,00,42,00,45,00,00,\
00,56,00,42,00,53,00,00,00,56,00,43,00,4d,00,00,00,57,00,4c,00,4c,00,00,00,\
57,00,50,00,43,00,00,00,57,00,53,00,43,00,00,00,57,00,53,00,46,00,00,00,57,\
00,53,00,48,00,00,00,58,00,4c,00,4c,00,00,00,00,00
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers\262144\Paths\{191cd7fa-f240-4a17-8986-94d480a6c8ca}]
"ItemData"="C:\\Windows\\"
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers\262144\Paths\{d2c34ab2-529a-46b2-b293-fc853fce72ea}]
"ItemData"="C:\\Program Files\\"
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Srp\Gp]
"RuleCount"=dword:00000000
32 Bit | 64 Bit | |
---|---|---|
Windows XP
Windows Vista Windows 7 Windows 8 Windows 8.1 Windows 10 Windows 11 Windows Server 2003 Windows Server 2008 Windows Server 2012 Windows Server 2016 Windows Server 2019 Windows Server 2022 |
safer-base.reg | safer-base-x64.reg |
Exportieren Sie zunächst die SAFER-Konfiguration aus der Registry, um jederzeit exakt den Originalzustand wiederherstellen und alle SAFER-Restriktionen aufheben zu können.
Aus Gründen der Übersichtlichtkeit verwende ich hier keine Registry-Variablen, sondern stattdessen hart-codierte Pfade. Passen Sie diese Pfade ggf. manuell an, bevor Sie die .reg-Datei importieren.
Mit diesen SAFER-Regeln werden nur Programme unterhalb von
C:\Windows
C:\Program Files
C:\Program Files (x86)
in der 64-Bit-Version
zugelassen, alle Programme außerhalb dieser Pfade hingegen verboten. Diese Einschränkung gilt außerdem nur für eingeschränkte Benutzer, d.h. Administratoren werden nicht beeinträchtigt. Die Bedeutung der einzelnen Registry-Einträge hat Microsoft dokumentiert.
Mit dem Gruppenrichtlinien-Editor (secpol.msc bzw. gpedit.msc) lassen sich SAFER-Regeln recht bequem anlegen. Gegenüber regedit.exe gibt es aber einige Nachteile:
C:\ Windows\ System32\ GroupPolicy\ Machine\ Registry.pol
. Für SAFER ist aber maßgeblich, was in der Registry steht. Insbesondere können also SAFER-Regeln aktiv sein, die secpol.msc gar nicht anzeigt. Per regedit.exe sieht man immer genau die Regeln, die gerade wirksam sind.Registry.pol
, in die secpol.msc schreibt, verwendet ein binäres Format. Inhalte der Registry lassen sich hingegen in einem Textformat im- und exportieren.+ , ; = [ ]
enthalten sind, obwohl diese Zeichen in Verzeichnis- und Dateinamen zulässig sind.
ADVAPI32.dll
enthaltene Initialisierungsroutine auf, die
Standardeinstellungen sowohl in die Registry.pol
als auch die
Registry schreibt, wobei bereits in der Registry vorhandene
Einstellungen überschrieben bzw. zurückgesetzt werden.
Bestimmte API-Funktionen von Windows können die App-Locker- und SAFER-Beschränkungen umgehen. Eine von Stefan Kanthak entwickelte AppCertDll schließt dieses Schlupfloch.
Bis einschließlich Windows 11 erlauben es die standardmäßigen ACLs eingeschränkten Benutzern unsinnigerweise, in %SystemDrive%
Unterverzeichnisse zu erstellen. Stefan Kanthak hat gezeigt, dass ein Angreifer dadurch insbesondere die Auswertung von SAFER-Pfadregeln manipulieren kann. Die von Stefan beschriebene Änderung der ACLs schließt auch dieses Schlupfloch.
Unter Windows 7 sollte außerdem der in KB2532445 beschriebene Hotfix installiert werden.
Windows kann das Ergebnis der Auswertung der SAFER-Regeln protokollieren. Das ist vor allem dann sinnvoll, wenn ein Programm von SAFER unerwünschterweise blockiert wird. Mit diesem Registry-Eintrag etwa wird das Logging aktiviert und der Pfad der Log-Datei auf C:\Users\Public\Documents\safer.log festgelegt:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\safer\codeidentifiers]
"LogFileName"="C:\\Users\\Public\\Documents\\safer.log"
safer-log.reg
Das Logging findet im aufrufenden Prozeß statt, deshalb muß auch die Gruppe
Benutzer in die Datei schreiben dürfen, andernfalls findet kein Logging statt. (Es wäre attraktiv, den Pfad zum Logfile etwa mittels
%USERPROFILE%\SAFER.log
benutzerabhängig festzulegen, aber SAFER wertet an dieser Stelle leider keine Variablen aus.)
Ich persönlich lasse das SAFER-Logging permanent eingeschaltet und leere die Datei einfach, wenn sie zu groß wird. Es ist möglicherweise auch sinnvoll, für die Log-Datei NTFS-Kompression zu aktivieren; dadurch wird die physikalische Größe der Datei typischerweise auf ein Viertel verringert.
Die Log-Datei ist UTF-16-codiert, so daß man sie etwa mit findstr.exe nicht sinnvoll durchsuchen kann. Mit PowerShell geht es besser, von SAFER blockierte Dateien findet man etwa so:
Get-Content -Path 'C:\Users\Public\Documents\safer.log' | Where-Object { $_ -notmatch ' as Unrestricted ' };
Oder in kompakter Form:
gc 'C:\Users\Public\Documents\safer.log' | where { $_ -notmatch ' as Unrestricted ' };
Wenn man neue Regeln direkt in die Registry schreiben will, benötigt man im Schlüsselnamen eine beliebige, aber eindeutige GUID. Der folgende PowerShell-Befehl befördert eine neue GUID direkt in die Zwischenablage:
"{{{0}}}" -f [System.GUID]::NewGuid() | Set-Clipboard
Der aufrufende Prozeß übernimmt bei SAFER die Regelauswertung (und auch das Logging). Typischerweise lädt der aufrufende Prozeß die SAFER-Regeln nur einmalig aus der Registry; Änderungen an den SAFER-Regeln, die nach dem Start des aufrufenden Prozesses vorgenommen wurden, werden deshalb nicht wirksam. Das ist problematisch beim Prozeß explorer.exe, der für Desktop und Startmenü zuständig ist.
Um geänderte Regeln schnell zu testen, starte ich eine neue Shell (cmd.exe) und rufe darin das gewünschte Programm auf.
In
registry path rules können Registry-Variablen mit literalen Pfadsegmenten kombiniert werden. Im Widerspruch zur Dokumentation müssen die Pfadsegmente dabei mit
/
getrennt werden, nicht mit
\
:
Richtig: |
%HKEY_LOCAL_MACHINE\
|
Falsch: |
%HKEY_LOCAL_MACHINE\
|
Pfad-Regeln dürfen nur höchstens
133 Zeichen lang sein. Längere Regeln werden nicht ausgewertet. Ggf. kann man Teile des Pfades durch
*
ersetzen, um ihn zu kürzen.
Richtig (131 Zeichen): |
%HKEY_CURRENT_USER\
|
Falsch (164 Zeichen): |
%HKEY_CURRENT_USER\
|
secpol.msc kann ebenfalls nicht korrekt mit Pfaden umgehen, die länger als 133 Zeichen sind. Solche Regeln lassen sich zwar mit secpol.msc erstellen, und sie werden auch in die Registry übernommen (aber dort ohnehin nicht ausgewertet). Die Regeln werden jedoch gar nicht mehr angezeigt, wenn man secpol.msc erneut öffnet.
In speziellen Situationen kann es notwendig sein, die SAFER-Restriktionen vorübergehend aufzuheben. Dies kann man erreichen, indem man den Registry-Schlüssel
HKEY_LOCAL_MACHINE\
bspw. in
_Safer
umbenennt. Prozesse, die
anschließend gestartet werden, sind nicht mehr durch SAFER eingeschränkt.
Einzelne Regeln kann man deaktivieren, indem man den entsprechenden
ItemData
-Wert bspw. in
_ItemData
umbenennt.
SAFER-Regeln werden vollständig ignoriert, sobald die erste AppLocker-Regel erstellt wird.
Unter Windows XP funktionieren Hash-Regeln nicht für DLLs.
Pfad-Regeln (etwa für C:\Windows) wirken rekursiv auch auf alle Unterverzeichnisse.
Das gilt jedoch nicht, wenn die Regel eine Dateierweiterung enthält. Eine Pfad-Regel für C:\Windows\system32\*.dll würde deshalb zwar auf C:\Windows\system32\MSCTF.dll wirken, aber nicht auf C:\Windows\system32\wbem\cimwin32.dll. Wenn man eine Dateierweiterung angibt, braucht man also für jedes Unterverzeichnis eine eigene Regel.
Leider gibt es unter C:\Windows Unterverzeichnisse, in die Benutzer schreiben dürfen; unter Windows 10/11 ist etwa das Verzeichnis C:\WINDOWS\debug\WIA für Benutzer beschreibar. Außerdem kann im Prinzip jedes Programm bei der Installation Unterverzeichnisse anlegen und diese für Benutzer beschreibbar machen – Visual Studio etwa erstellt bei der Installation standardmäßig das Verzeichnis C:\Program Files\Microsoft SQL Server\130\Shared\ErrorDumps und macht dieses für Benutzer beschreibar. Solche Verzeichnisse sollte man mit einer entsprechenden Pfadregel explizit ausschließen, denn andernfalls könnte ein Angreifer mit Benutzerrechten dort Dateien ablegen und ausführen.
Dieses PowerShell-Modul (lauffähig nur unter PowerShell Core) spürt solche Verzeichnisse auf:
function Normalize-FolderPaths {
<#
.SYNOPSIS
Normalizes folder paths by replacing '/' with '\' and removing a trailing '\'.
#>
process {
$_ -replace '/', '\' -replace '\\$', '';
};
}
function New-Rule {
[CmdletBinding()]
param(
[string]
$ItemData,
[string]
$Description
);
[pscustomobject] @{
ItemData = $ItemData;
Description = $Description;
};
}
function Get-BlockedFolders {
<#
.SYNOPSIS
Gets SAFER rules from the registy that deny execution in certain paths.
#>
Get-Item -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\safer\codeidentifiers\0\Paths\*' | ForEach-Object {
if( $_.GetValue('Description', 'N/A').StartsWith('Blocked because users can create ') ) {
New-Rule `
-ItemData $_.GetValue('ItemData') `
-Description $_.GetValue('Description');
}
}
}
function Assert-BlockedFolders {
<#
.SYNOPSIS
Asserts that all writeable folders have a corresponding SAFER path rule in the registry.
#>
[CmdletBinding()]
param(
[string[]]
$Exclude = @()
);
Compare-Object `
-ReferenceObject ( Get-BlockedFolders ) `
-DifferenceObject ( Find-WriteableFolders -Exclude $Exclude ) `
-Property 'ItemData' `
-PassThru;
}
function Find-WriteableFolders {
<#
.SYNOPSIS
Finds folders below 'C:\Windows', 'C:\Program Files' and 'C:\Program Files (x86)' that allow users to create files, subfolders or Alternate Data Streams (ADS).
#>
[CmdletBinding()]
param(
[string[]]
$Exclude = @()
);
$Exclude = $Exclude | Normalize-FolderPaths;
# Choose random name for files and folders.
$randomFoldername = 'psancxtqkbgfomb';
$randomFilename = "$randomFoldername.vbs";
# Define harmless file content.
$sampleContent = 'WScript.Echo WScript.ScriptFullName';
function CanWriteFile( [string] $FullName ) {
try {
[System.IO.File]::WriteAllText( $FullName, $sampleContent );
return $true;
} catch {
return $false;
}
}
function CanWriteFolder( [string] $FullName ) {
try {
[System.IO.Directory]::CreateDirectory( $FullName ) | Out-Null;
return $true;
} catch {
return $false;
}
}
function ProcessFolder( [string] $Folder ) {
if( $Folder -iin $Exclude ) {
Write-Verbose "Skipping folder '$Folder'.";
return;
}
if( CanWriteFile "${Folder}:$randomFilename" ) { # Try to create ADS
New-Rule -ItemData "${Folder}:*" -Description 'Blocked because users can create Alternate Data Streams here.';
}
if( CanWriteFile "$Folder\$randomFilename" ) { # Try to create file
New-Rule -ItemData "$Folder\" -Description 'Blocked because users can create files here.';
} elseif( CanWriteFolder "$Folder\$randomFoldername" ) { # Try to create subdirectory
New-Rule -ItemData "$Folder\" -Description 'Blocked because users can create subdirectories here.';
} else {
try {
$dirs = [System.IO.Directory]::GetDirectories( $Folder );
} catch [System.UnauthorizedAccessException] {
return;
}
foreach( $dir in $dirs ) {
ProcessFolder $dir;
}
}
}
foreach( $env in @( "Env:\windir", "Env:\ProgramFiles", "Env:\ProgramFiles(x86)" ) ) {
if( Test-Path $env ) {
ProcessFolder ( Get-Content $env );
}
}
}
function Export-SaferRules {
[CmdletBinding()]
param(
[Parameter(ValueFromPipeline)]
[pscustomobject]
$Rule
);
begin {
'Windows Registry Editor Version 5.00';
'';
}
process {
'[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\safer\codeidentifiers\0\Paths\{{{0}}}]' -f [guid]::NewGuid();
'"ItemData"="{0}"' -f $_.ItemData.Replace('\', '\\');
'"Description"="{0}"' -f $_.Description;
'';
}
}
Export-ModuleMember -Function 'Assert-BlockedFolders';
Export-ModuleMember -Function 'Export-SaferRules';
Export-ModuleMember -Function 'Find-WriteableFolders';
Export-ModuleMember -Function 'Get-BlockedFolders';
WriteableFolders.psm1Das Modul muss zuerst per
Import-Module -Name "WriteableFolders.psm1";
in eine mit Benutzerrechten laufende PowerShell-Sitzung importiert werden. Ein Aufruf wie etwa
Find-WriteableFolders | Export-SaferRules | Out-File -FilePath safer.reg -Encoding unicode;
erstellt eine .reg-Datei, die ein Administrator in die Registry importieren muss. Mit
Assert-BlockedFolders | Where-Object {
$_.SideIndicator -eq '=>'
} | Export-SaferRules | Out-File -FilePath safer.reg -Encoding unicode;
ermittelt man künftige Änderungen, und mit
Assert-BlockedFolders | Where-Object {
$_.SideIndicator -eq '<='
}
ermittelt man Pfadregeln in der Registry, die nicht mehr benötigt werden.
Einige Spiele-Plattformen wie GOG.com, Steam oder der Epic Games Store machen ihr Installationsverzeichnis für Benutzer beschreibar, damit einzelne Spiele ohne Administratorrechte installiert und aktualisiert werden können. Ständige Anpassungen von SAFER-Pfadregeln oder NTFS-Zugriffsrechten sind in diesem Fall nicht praktibel. Ich verwende stattdessen nicht das standardmäßige Installationsverzeichnis C:\Program Files (x86)\Steam, sondern ein völlig zufälliges Verzeichnis wie etwa C:\Program Files (x86)\sapqoknhkyzlyrne. Der Angreifer hat damit keine wohlbekannten Pfade mehr zum Ablegen von Schadcode zur Verfügung.
Ausnahmen, die per Hash-Regel definiert werden, sind typischerweise sicherer als solche, die per Pfad-Regel definiert werden. Sie sind aber auch umständlicher zu erstellen. Ein kleines PowerShell-Skript kann den Vorgang deutlich vereinfachen:
function New-SaferHashRule {
param (
[String] $GuidPrefix = "",
[Parameter(Mandatory=$true, ValueFromPipeline=$true)]
[System.IO.FileInfo] $File
)
begin {
Add-Type -AssemblyName System.Security;
$cryptoSha256 = [System.Security.Cryptography.HashAlgorithm]::Create('SHA256');
$cryptoMd5 = [System.Security.Cryptography.HashAlgorithm]::Create('MD5');
$path = 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers\262144\Hashes';
if (!(Test-Path $path)) {
New-Item -Path $path > $null;
}
}
process {
$guid = '{' + $GuidPrefix + [System.Guid]::NewGuid().ToString().Substring($GuidPrefix.Length) + '}';
$fileContent = [System.IO.File]::ReadAllBytes($File.FullName);
$pathMd5 = Join-Path $path $guid;
New-Item -Path $pathMd5 > $null;
New-ItemProperty -Path $pathMd5 -Name 'FriendlyName' -Value $File.Name > $null;
New-ItemProperty -Path $pathMd5 -Name 'Description' -Value $File.FullName > $null;
New-ItemProperty -Path $pathMd5 -Name 'ItemSize' -Value $File.Length -PropertyType QWord > $null;
New-ItemProperty -Path $pathMd5 -Name 'HashAlg' -Value 0x8003 -PropertyType DWord > $null;
New-ItemProperty -Path $pathMd5 -Name 'ItemData' -Value $cryptoMd5.ComputeHash($fileContent) -PropertyType Binary > $null;
$pathSha256 = Join-Path $pathMd5 'SHA256';
New-Item -Path $pathSha256 > $null;
New-ItemProperty -Path $pathSha256 -Name 'HashAlg' -Value 0x800C -PropertyType DWord > $null;
New-ItemProperty -Path $pathSha256 -Name 'ItemData' -Value $cryptoSha256.ComputeHash($fileContent) -PropertyType Binary > $null;
[pscustomobject] @{
File = $File.Fullname;
Key = $pathMd5;
}
}
}
New-SaferHashRule.ps1Der Aufruf erfolgt etwa so:
dir -Include *.cmd,*.exe -Recurse -File | New-SaferHashRule
Damit wird für jede
.cmd
- und
.exe
-Datei im aktuellen Verzeichnis eine passende Hash-Regel erstellt. Über die Variable
$GuidPrefix
kann ein gemeinsames Präfix für alle GUIDs festgelegt werden, die das Skript erzeugt. Das erleichtert es, die Hash-Regeln wieder zu entfernen, wenn man sie nicht mehr benötigt.
Mit PowerShell 3.x wurde der sog. Constrained Mode eingeführt. Im Constrained Mode funktionieren Cmdlets zwar noch, aber der Aufruf von .NET- und COM-Objekten wird verhindert. Schadsoftware, die .NET-Funktionen aus PowerShell-Skripten heraus aufruft, wird damit effektiv blockiert. Mit dieser Funktion kann der aktive Modus abgefragt werden:
function Get-LanguageMode {
$ExecutionContext.SessionState.LanguageMode
}
Im
Constrained Mode gibt diese Funktion
ConstrainedLanguage
zurück, sonst
FullLanguage
.
Zunächst wurde der
Constrained Mode nur über die System-Umgebungsvariable
__PSLockDownPolicy
konfiguriert. Seit
PowerShell 5.x wird der
Constrained Mode jedoch auch dann aktiviert, wenn PowerShell beim Starten feststellt, daß das System in einer Whitelisting-Konfiguration betrieben wird. Dazu geht PowerShell folgendermaßen vor:
__PSScriptPolicyTest_d5p3ajid.sg5.ps1
und
__PSScriptPolicyTest_uvlfqxgh.mfb.psm1
in
%TEMP%
angelegt und ausgeführt.
Da Administratoren den SAFER-Regeln typischerweise nicht unterliegen, wird für sie auch der Constrained Mode nicht aktiviert. Um auch für einen nicht-angehobenen Benutzer den Constrained Mode zu vermeiden, müssen die SAFER-Restriktionen temporär durch einen Administrator aufgehoben werden:
function Disable-SaferRulesTemporarily
{
# SAFER-Restriktionen aufheben
Rename-Item -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\safer' -NewName '_safer';
# Kurz warten
Start-Sleep -Seconds 5;
# SAFER-Restriktionen wiederherstellen
Rename-Item -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\_safer' -NewName 'safer';
}
Disable-SaferRulesTemporarily.ps1
Das Skript deaktiviert die SAFER-Regeln für 5 Sekunden. Wird in dieser Zeit eine neue PowerShell-Sitzung gestartet, so läuft sie im Modus
FullLanguage
.
SAFER muß installiert werden.
SAFER ist in Windows bereits eingebaut. Es muß lediglich konfiguriert werden.
Mit SAFER kann man sich selber aussperren.
Typischerweise wird SAFER so eingerichtet, daß nur eingeschränkte Benutzer den Regeln unterliegen, nicht aber Administratoren. (Beachten Sie aber die Hinweise zur Benutzerkontensteuerung/UAC.) Im abgesicherten Modus werden die SAFER-Regeln ebenfalls nicht ausgewertet, so daß man stets einen Rettungsanker hat.
SAFER funktioniert nicht in den Home-Varianten von Windows.
SAFER funktioniert in allen Versionen ab Windows XP bis einschließlich Windows 11. In den Home-Varianten fehlt der Gruppenrichtlinien-Editor, den man aber ohnehin nicht verwenden sollte. Und SAFER-Regeln lassen sich in jedem Fall direkt in die Registry schreiben. Maßgeblich sind in allen Windows-Varianten ausschließlich die Registry-Einträge.
Wer mit eingeschränkten Rechten arbeitet (etwa mit UAC), braucht SAFER nicht.
Das Sicherheits-Placebo UAC soll verhindern, daß Programme mit Administratorrechten ausgeführt werden. UAC soll nicht verhindern, daß Programme mit Benutzerrechten ausgeführt werden. Schadsoftware benötigt aber keine Administratorrechte, um Benutzerdaten zu kompromittieren – bspw. kann Ransomware mit Benutzerrechten alle Benutzerdateien unzugänglich machen. Außerdem kann eine mit Benutzerrechten laufende Schadsoftware versuchen, sich auch noch Administratorrechte zu verschaffen, bspw. durch Binary Planting.
UAC hindert Schadsoftware also nicht an der Ausführung, SAFER schon. Deshalb ist auch mit UAC der Einsatz von SAFER ratsam. UAC und SAFER können problemlos zusammen benutzt werden.
Mitglieder der lokalen Gruppe Administratoren unterliegen typischerweise ebenfalls UAC und somit auch den SAFER-Restriktionen. Ein solcher Administrator kann deshalb blockierte Programme nur mittels Als Administrator ausführen starten. Das eingebaute, aber zunächst inaktive Konto Administrator hingegen unterliegt standardmäßig nicht den UAC-Restriktionen. Dieses Konto kann per
%windir%\System32\net.exe user Administrator /active:yes
oder bereits während der Windows-Installation aktiviert werden. Diese saubere Trennung zwischen Benutzer- und Administratorkonto vermeidet zahlreiche Schwachstellen von UAC.
Verwirrend kann auch das Verhalten der sog.
Installationserkennung sein, die dafür sorgen soll, daß Installationsprogramme wie
setup.exe
automatisch einen UAC-Dialog anzeigen, damit das Installationsprogramm mit Administratorrechten ausgeführt wird. Wenn SAFER einem Benutzer die Ausführung des Installationsprogramms verbietet, kann die Installationserkennung aber gar nicht mehr zum Zuge kommen. Es erscheint also kein UAC-Dialog, sondern bloß eine SAFER-Fehlermeldung. Starten Sie Installationsprogramme deshalb per Rechtsklick und
Als Administrator ausführen. Nach Bestätigung wird das Programm unter dem Administratorkonto ausgeführt, und dieses ist ja typischerweise nicht durch SAFER-Regeln eingeschränkt.
SAFER eignet sich nicht für normale Anwender.
SAFER eignet sich gerade für Anwender, die nur mit den installierten Programmen arbeiten wollen. Software-Entwickler benötigen höchstwahrscheinlich zusätzliche Regeln, aber diese lassen sich leicht erstellen.
SAFER bremst das System aus.
Wenn das Logging eingeschaltet ist und die SAFER-Restriktionen auch für DLLs angewendet werden, starten u.U. manche Programme spürbar langsamer, weil dann hunderte von Zeilen ins Logfile geschrieben werden. Wenn dies als störend empfunden wird, kann man das Logging abschalten.
Ansonsten hat SAFER keinen nennenswerten Einfluß auf die Performance.
SAFER-Restriktionen brauchen nicht unbedingt für DLLs aktiv zu sein
Mit der Einstellung
"TransparentEnabled"=dword:00000001
werden DLLs von den SAFER-Restriktionen ausgenommen. Dies ermöglicht es Angreifern aber,
trivial Code auszuführen. Stattdessen sollte unbedingt
"TransparentEnabled"=dword:00000002
gesetzt sein.
Manche Programme legen ausführbare Dateien im Profilverzeichnis (%USERPROFILE%) ab, wo diese eigentlich nichts zu suchen haben. Wenn man solche Programme mit SAFER verwenden will, muß man sie mit eigenen Regeln freigeben.
Viele Regeln enthalten Registry-Variablen, um das Profilverzeichnis des jeweiligen Benutzers zu referenzieren. Registry-Variablen werden von SAFER nur dann aufgelöst, wenn sie im
ItemData
-Wert mit dem Datentyp
REG_EXPAND_SZ
notiert werden.
REG_EXPAND_SZ
-Werte wiederum lassen sich in .reg-Dateien nur binär darstellen. Um die Regel hier dennoch lesbar anzuzeigen, schreibe ich sie zusätzlich mit dem Datentyp
REG_SZ
in den
Description
-Wert. Maßgeblich für die Auswertung ist aber allein
ItemData
.
Manche Regeln verweisen mit Registry-Variablen auf die Schlüssel
HKEY_CURRENT_USER\
oder
HKEY_LOCAL_MACHINE\
. Das ist eigentlich
eine ganz schlechte Idee, aber eine saubere Lösung, die unter allen Windows-Versionen funktioniert, gibt es leider nicht.
Wird der
Chrome-Installer mit Administratorrechten gestartet, so installiert sich Chrome neuerdings ordentlich nach
%ProgramFiles%
und steht dann allen Benutzern zur Verfügung. Das ist die bevorzugte Methode, und es werden dann keine SAFER-Ausnahmen benötigt.
Wenn Chrome allerdings ins Benutzerprofil installiert wird, werden mehrere Ausnahmen benötigt:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers\262144\Paths\{28c898f7-b49a-4734-938a-487a4c3c70ab}]
"Description"="%HKEY_CURRENT_USER\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Shell Folders\\Local AppData%Google/Chrome/Application"
"ItemData"=hex(2):25,00,48,00,4b,00,45,00,59,00,5f,00,43,00,55,00,52,00,52,00,\
45,00,4e,00,54,00,5f,00,55,00,53,00,45,00,52,00,5c,00,53,00,6f,00,66,00,74,\
00,77,00,61,00,72,00,65,00,5c,00,4d,00,69,00,63,00,72,00,6f,00,73,00,6f,00,\
66,00,74,00,5c,00,57,00,69,00,6e,00,64,00,6f,00,77,00,73,00,5c,00,43,00,75,\
00,72,00,72,00,65,00,6e,00,74,00,56,00,65,00,72,00,73,00,69,00,6f,00,6e,00,\
5c,00,45,00,78,00,70,00,6c,00,6f,00,72,00,65,00,72,00,5c,00,53,00,68,00,65,\
00,6c,00,6c,00,20,00,46,00,6f,00,6c,00,64,00,65,00,72,00,73,00,5c,00,4c,00,\
6f,00,63,00,61,00,6c,00,20,00,41,00,70,00,70,00,44,00,61,00,74,00,61,00,25,\
00,47,00,6f,00,6f,00,67,00,6c,00,65,00,2f,00,43,00,68,00,72,00,6f,00,6d,00,\
65,00,2f,00,41,00,70,00,70,00,6c,00,69,00,63,00,61,00,74,00,69,00,6f,00,6e,\
00,00,00
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers\262144\Paths\{28c898f7-b49a-4734-938a-487a4c3c70ac}]
"Description"="%HKEY_CURRENT_USER\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Shell Folders\\Local AppData%Google/Update"
"ItemData"=hex(2):25,00,48,00,4b,00,45,00,59,00,5f,00,43,00,55,00,52,00,52,00,\
45,00,4e,00,54,00,5f,00,55,00,53,00,45,00,52,00,5c,00,53,00,6f,00,66,00,74,\
00,77,00,61,00,72,00,65,00,5c,00,4d,00,69,00,63,00,72,00,6f,00,73,00,6f,00,\
66,00,74,00,5c,00,57,00,69,00,6e,00,64,00,6f,00,77,00,73,00,5c,00,43,00,75,\
00,72,00,72,00,65,00,6e,00,74,00,56,00,65,00,72,00,73,00,69,00,6f,00,6e,00,\
5c,00,45,00,78,00,70,00,6c,00,6f,00,72,00,65,00,72,00,5c,00,53,00,68,00,65,\
00,6c,00,6c,00,20,00,46,00,6f,00,6c,00,64,00,65,00,72,00,73,00,5c,00,4c,00,\
6f,00,63,00,61,00,6c,00,20,00,41,00,70,00,70,00,44,00,61,00,74,00,61,00,25,\
00,47,00,6f,00,6f,00,67,00,6c,00,65,00,2f,00,55,00,70,00,64,00,61,00,74,00,\
65,00,00,00
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers\262144\Paths\{28c898f7-b49a-4734-938a-487a4c3c70ad}]
"Description"="%HKEY_CURRENT_USER\\Environment\\TEMP%CR_*.tmp/setup.exe"
"ItemData"=hex(2):25,00,48,00,4b,00,45,00,59,00,5f,00,43,00,55,00,52,00,52,00,\
45,00,4e,00,54,00,5f,00,55,00,53,00,45,00,52,00,5c,00,45,00,6e,00,76,00,69,\
00,72,00,6f,00,6e,00,6d,00,65,00,6e,00,74,00,5c,00,54,00,45,00,4d,00,50,00,\
25,00,43,00,52,00,5f,00,2a,00,2e,00,74,00,6d,00,70,00,2f,00,73,00,65,00,74,\
00,75,00,70,00,2e,00,65,00,78,00,65,00,00,00
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers\262144\Paths\{28c898f7-b49a-4734-938a-487a4c3c70ae}]
"Description"="%HKEY_CURRENT_USER\\Environment\\TEMP%GUM*.tmp/*"
"ItemData"=hex(2):25,00,48,00,4b,00,45,00,59,00,5f,00,43,00,55,00,52,00,52,00,\
45,00,4e,00,54,00,5f,00,55,00,53,00,45,00,52,00,5c,00,45,00,6e,00,76,00,69,\
00,72,00,6f,00,6e,00,6d,00,65,00,6e,00,74,00,5c,00,54,00,45,00,4d,00,50,00,\
25,00,47,00,55,00,4d,00,2a,00,2e,00,74,00,6d,00,70,00,2f,00,2a,00,00,00
google-chrome.regPlayReady DRM Black Box-Plugin
Silverlight-Anwendungen laufen im Browser mit SAFER ohne Probleme. Für die Wiedergabe von DRM-geschützten Videos installiert Silverlight jedoch eine DLL ins Benutzerprofil! Von dort kann die DLL wegen SAFER nicht geladen werden. Diese Regel läßt die DLL anhand ihres Speicherortes unterhalb von %ALLUSERSPROFILE% und ihres Dateinamens MSPRindiv01.key zu:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers\262144\Paths\{0144f22c-74c0-4391-806a-3498730f0670}]
"Description"="%HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Shell Folders\\Common AppData%Microsoft/PlayReady/Cache/*/MSPRindiv01.key"
"ItemData"=hex(2):25,00,48,00,4b,00,45,00,59,00,5f,00,4c,00,4f,00,43,00,41,00,\
4c,00,5f,00,4d,00,41,00,43,00,48,00,49,00,4e,00,45,00,5c,00,53,00,4f,00,46,\
00,54,00,57,00,41,00,52,00,45,00,5c,00,4d,00,69,00,63,00,72,00,6f,00,73,00,\
6f,00,66,00,74,00,5c,00,57,00,69,00,6e,00,64,00,6f,00,77,00,73,00,5c,00,43,\
00,75,00,72,00,72,00,65,00,6e,00,74,00,56,00,65,00,72,00,73,00,69,00,6f,00,\
6e,00,5c,00,45,00,78,00,70,00,6c,00,6f,00,72,00,65,00,72,00,5c,00,53,00,68,\
00,65,00,6c,00,6c,00,20,00,46,00,6f,00,6c,00,64,00,65,00,72,00,73,00,5c,00,\
43,00,6f,00,6d,00,6d,00,6f,00,6e,00,20,00,41,00,70,00,70,00,44,00,61,00,74,\
00,61,00,25,00,2a,00,2f,00,50,00,6c,00,61,00,79,00,52,00,65,00,61,00,64,00,\
79,00,2f,00,2a,00,2f,00,2a,00,2f,00,4d,00,53,00,50,00,52,00,69,00,6e,00,64,\
00,69,00,76,00,30,00,31,00,2e,00,6b,00,65,00,79,00,00,00
silverlight-drm.reg
Wird der
Dropbox-Installer mit Administratorrechten gestartet, so installiert er Dropbox ordentlich nach
%ProgramFiles%
bzw.
%ProgramFiles(x86)%
. In diesem Fall werden keine SAFER-Ausnahmen benötigt.
Wenn der Installer allerdings mit Benutzerrechten gestartet wird, so installiert er Dropbox ins Benutzerprofil, was eine SAFER-Ausnahme erfordert:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers\262144\Paths\{b45b6e4a-9d73-4d68-90c5-e40b61065881}]
"Description"="%HKEY_CURRENT_USER\\Volatile Environment\\APPDATA%Dropbox/bin/"
"ItemData"=hex(2):25,00,48,00,4b,00,45,00,59,00,5f,00,43,00,55,00,52,00,52,00,\
45,00,4e,00,54,00,5f,00,55,00,53,00,45,00,52,00,5c,00,56,00,6f,00,6c,00,61,\
00,74,00,69,00,6c,00,65,00,20,00,45,00,6e,00,76,00,69,00,72,00,6f,00,6e,00,\
6d,00,65,00,6e,00,74,00,5c,00,41,00,50,00,50,00,44,00,41,00,54,00,41,00,25,\
00,44,00,72,00,6f,00,70,00,62,00,6f,00,78,00,2f,00,62,00,69,00,6e,00,2f,00,\
00,00
dropbox.regMicrosoft hat offenbar seine eigenen Designed for Windows-Richtlinien vergessen und installiert OneDrive ins Profilverzeichnis. Das erfordert also eine Ausnahme:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\safer\codeidentifiers\262144\Paths\{68de9146-dd65-4f33-b6e2-f33985e736bf}]
"Description"="%HKEY_CURRENT_USER\\Volatile Environment\\LOCALAPPDATA%Microsoft/OneDrive/"
"ItemData"=hex(2):25,00,48,00,4b,00,45,00,59,00,5f,00,43,00,55,00,52,00,52,00,\
45,00,4e,00,54,00,5f,00,55,00,53,00,45,00,52,00,5c,00,56,00,6f,00,6c,00,61,\
00,74,00,69,00,6c,00,65,00,20,00,45,00,6e,00,76,00,69,00,72,00,6f,00,6e,00,\
6d,00,65,00,6e,00,74,00,5c,00,4c,00,4f,00,43,00,41,00,4c,00,41,00,50,00,50,\
00,44,00,41,00,54,00,41,00,25,00,4d,00,69,00,63,00,72,00,6f,00,73,00,6f,00,\
66,00,74,00,2f,00,4f,00,6e,00,65,00,44,00,72,00,69,00,76,00,65,00,2f,00,00,\
00
onedrive.regGenauso schlimm wie OneDrive – und deshalb auch eine ähnliche Ausnahme:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\safer\codeidentifiers\262144\Paths\{84f3055a-ae86-4d4f-aa29-dc93bd528cee}]
"Description"="%HKEY_CURRENT_USER\\Volatile Environment\\LOCALAPPDATA%Microsoft/Teams/"
"ItemData"=hex(2):25,00,48,00,4b,00,45,00,59,00,5f,00,43,00,55,00,52,00,52,00,\
45,00,4e,00,54,00,5f,00,55,00,53,00,45,00,52,00,5c,00,56,00,6f,00,6c,00,61,\
00,74,00,69,00,6c,00,65,00,20,00,45,00,6e,00,76,00,69,00,72,00,6f,00,6e,00,\
6d,00,65,00,6e,00,74,00,5c,00,4c,00,4f,00,43,00,41,00,4c,00,41,00,50,00,50,\
00,44,00,41,00,54,00,41,00,25,00,4d,00,69,00,63,00,72,00,6f,00,73,00,6f,00,\
66,00,74,00,2f,00,54,00,65,00,61,00,6d,00,73,00,2f,00,00,00
teams.regGoogle Drive installiert sich zwar ins Programmverzeichnis, legt aber beim Start noch ausführbare Dateien im Profilverzeichnis an. Das ist ganz großer Mist und erfordert eine ziemlich großzügige und somit gefährliche Ausnahme:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers\262144\Paths\{d4fb8a20-2fcb-4c10-b543-0ccc6ebfee74}]
"Description"="%HKEY_CURRENT_USER\\Environment\\TEMP%_MEI*/"
"ItemData"=hex(2):25,00,48,00,4b,00,45,00,59,00,5f,00,43,00,55,00,52,00,52,00,\
45,00,4e,00,54,00,5f,00,55,00,53,00,45,00,52,00,5c,00,45,00,6e,00,76,00,69,\
00,72,00,6f,00,6e,00,6d,00,65,00,6e,00,74,00,5c,00,54,00,45,00,4d,00,50,00,\
25,00,5f,00,4d,00,45,00,49,00,2a,00,2f,00,00,00
google-drive.reg
Auch wenn Chrome selbst in
%ProgramFiles%
bzw.
%ProgramFiles(x86)%
installiert ist, wird die
pepflashplayer.dll im Profilverzeichnis abgelegt. Dort muß sie freigegeben werden:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\safer\codeidentifiers\262144\Paths\{8cdf7d20-2d55-44c2-a20f-ca1f036143bc}]
"Description"="%HKEY_CURRENT_USER\\Volatile Environment\\LOCALAPPDATA%Google/Chrome/User Data/PepperFlash/*/pepflashplayer.dll"
"ItemData"=hex(2):25,00,48,00,4b,00,45,00,59,00,5f,00,43,00,55,00,52,00,52,00,\
45,00,4e,00,54,00,5f,00,55,00,53,00,45,00,52,00,5c,00,56,00,6f,00,6c,00,61,\
00,74,00,69,00,6c,00,65,00,20,00,45,00,6e,00,76,00,69,00,72,00,6f,00,6e,00,\
6d,00,65,00,6e,00,74,00,5c,00,4c,00,4f,00,43,00,41,00,4c,00,41,00,50,00,50,\
00,44,00,41,00,54,00,41,00,25,00,47,00,6f,00,6f,00,67,00,6c,00,65,00,2f,00,\
43,00,68,00,72,00,6f,00,6d,00,65,00,2f,00,55,00,73,00,65,00,72,00,20,00,44,\
00,61,00,74,00,61,00,2f,00,50,00,65,00,70,00,70,00,65,00,72,00,46,00,6c,00,\
61,00,73,00,68,00,2f,00,2a,00,2f,00,70,00,65,00,70,00,66,00,6c,00,61,00,73,\
00,68,00,70,00,6c,00,61,00,79,00,65,00,72,00,2e,00,64,00,6c,00,6c,00,00,00
pepflashplayer.reg
Mit dem Update KB4052623 wurden ausführbare Dateien (u.a.
MsMpEng.exe
,
NisSrv.exe
und
MpOAV.dll
) von
C:\Program Files\Windows Defender
idiotischerweise nach
C:\ProgramData\Microsoft\Windows Defender
verschoben, wo SAFER natürlich die Ausführung verhindert. Dies führt dazu, daß Chrome und Internet Explorer keine Downloads mehr ausführen können, denn der
Attachment Manager löscht alle heruntergeladenen Dateien wieder, weil er Windows Defender nicht aufrufen kann. Es ist folgende Ausnahme notwendig:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\safer\codeidentifiers\262144\Paths\{ecfc3846-2cb0-42e1-b781-3e9d90ed7f57}]
"ItemData"="C:\\ProgramData\\Microsoft\\Windows Defender\\"
windows-defender-programdata.reg
Der neue
Sky Ticket Player installiert nicht nur sich selbst und noch dazu Ciscos
„VideoGuard“ ins Profilverzeichnis, sondern legt auch noch bei jedem Start eine ausführbare Datei mit einem Namen wie
958D.tmp.node
in
%TEMP%
ab. Um den Player überhaupt korrekt zu installieren, müssen die SAFER-Restriktionen
vorübergehend aufgehoben werden, und für den regulären Betrieb braucht man anschließend mehrere Ausnahmen:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\safer\codeidentifiers\262144\Hashes\{ba366c9d-0187-4dfe-aa15-314d443ef889}]
"Description"="%TEMP%\\????.tmp.node"
"ItemSize"=hex(b):00,3e,1a,00,00,00,00,00
"HashAlg"=dword:00008003
"ItemData"=hex:c2,ff,31,12,25,67,a9,ad,ae,0b,90,ad,3f,cc,05,c1
"FriendlyName"="NOW TV Player executable"
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\safer\codeidentifiers\262144\Hashes\{ba366c9d-0187-4dfe-aa15-314d443ef889}\SHA256]
"HashAlg"=dword:0000800c
"ItemData"=hex:8f,36,f2,43,e2,b6,84,52,80,74,a7,ae,f0,af,e0,53,3a,0f,b1,a9,ae,\
8c,f5,57,d6,1a,23,03,aa,19,c9,7b
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\safer\codeidentifiers\262144\Paths\{ba366c9d-0187-4dfe-aa15-314d443ef887}]
"Description"="%HKEY_CURRENT_USER\\Volatile Environment\\APPDATA%Sky Ticket/"
"ItemData"=hex(2):25,00,48,00,4b,00,45,00,59,00,5f,00,43,00,55,00,52,00,52,00,\
45,00,4e,00,54,00,5f,00,55,00,53,00,45,00,52,00,5c,00,56,00,6f,00,6c,00,61,\
00,74,00,69,00,6c,00,65,00,20,00,45,00,6e,00,76,00,69,00,72,00,6f,00,6e,00,\
6d,00,65,00,6e,00,74,00,5c,00,41,00,50,00,50,00,44,00,41,00,54,00,41,00,25,\
00,53,00,6b,00,79,00,20,00,54,00,69,00,63,00,6b,00,65,00,74,00,2f,00,00,00
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\safer\codeidentifiers\262144\Paths\{ba366c9d-0187-4dfe-aa15-314d443ef888}]
"Description"="%HKEY_CURRENT_USER\\Volatile Environment\\LOCALAPPDATA%Cisco/VideoGuardPlayer/"
"ItemData"=hex(2):25,00,48,00,4b,00,45,00,59,00,5f,00,43,00,55,00,52,00,52,00,\
45,00,4e,00,54,00,5f,00,55,00,53,00,45,00,52,00,5c,00,56,00,6f,00,6c,00,61,\
00,74,00,69,00,6c,00,65,00,20,00,45,00,6e,00,76,00,69,00,72,00,6f,00,6e,00,\
6d,00,65,00,6e,00,74,00,5c,00,4c,00,4f,00,43,00,41,00,4c,00,41,00,50,00,50,\
00,44,00,41,00,54,00,41,00,25,00,43,00,69,00,73,00,63,00,6f,00,2f,00,56,00,\
69,00,64,00,65,00,6f,00,47,00,75,00,61,00,72,00,64,00,50,00,6c,00,61,00,79,\
00,65,00,72,00,2f,00,00,00
sky-ticket.reg(Die Hash-Regel muß jeweils aktualisiert werden, wenn eine neue Version der ausführbaren Datei erscheint.)