RDP „Unbekannter Herausgeber" nach dem April-Patchday 2026 — Ursachen, Risiko, Fix

Die Supporttickets nach dem Patchday

Montagmorgen nach dem April-Patchday 2026: Die Helpdesk-Warteschlange stapelt sich. „Meine Remotedesktop-Verbindung funktioniert nicht mehr." „Soll ich auf Ja klicken?" „Ist das ein Virus?" In Wirklichkeit funktioniert die Verbindung unverändert — nur zeigt Windows beim Öffnen einer unsignierten .rdp-Datei jetzt eine deutlich prominentere Warnung: „Der Herausgeber dieser Remotedesktopverbindung kann nicht ermittelt werden".

Das Problem ist nicht neu — die Warnung existiert seit Windows Vista. Neu ist, dass Microsoft sie mit dem April-2026-Patchday deutlich sichtbarer und schwerer umgehbar gemacht hat. Für Administratoren, die über Jahre Skripte, Startmenü-Verknüpfungen und per Mail verschickte Konfigurationen für Kunden in dieser unsignierten Form ausgerollt haben, bedeutet das: Ohne Signierung gibt es nun bei jedem Start einen Schreckmoment für den Anwender.

Was sich im April-Patchday 2026 geändert hat

Der Patchday bringt einen sogenannten „Secure by Default"-Hardening-Schritt für die Remote-Desktop-Clients mit. Konkret betrifft das mstsc.exe (Remotedesktopverbindung), die moderne Remote-Desktop-UWP-App sowie das RDCMan-Nachfolge-Tool. Drei Änderungen im Detail:

• Warn-Dialog verpflichtend — die zuvor per Checkbox „Nicht mehr fragen" dauerhaft deaktivierbare Warnung erscheint nun nach jedem Logon-Zyklus erneut, bis die Datei signiert ist.
• Policy-Default-Wechsel — der Wert AllowUnsignedFiles wurde umgedreht: vorher „Not Configured" = erlaubt, jetzt nur mit explizitem Enable erlaubt.
• Erweiterte Redirection-Warnung — zusätzlich zum Herausgeber-Hinweis wird jetzt explizit aufgelistet, welche Redirections (Clipboard, Drives, Smart Cards, WebAuthn) die .rdp-Datei aktivieren will.

Hintergrund: Das Microsoft Security Response Center hat 2025 einen deutlichen Anstieg von RDP-basiertem Phishing beobachtet. Angreifer verschicken täuschend echte .rdp-Dateien per E-Mail, die auf einen vom Angreifer kontrollierten RDP-Server zeigen — mit aktivierter Clipboard-, Drive- und WebAuthn-Redirection. Der Anwender öffnet die Datei, gibt seine Credentials in das vertraute Anmeldefenster ein und teilt unbemerkt sein Clipboard, lokale Laufwerke und ggf. sogar Passkey-Ceremonies mit dem Angreifer.

• mstsc.exe gehärtet
• AllowUnsignedFiles = Disabled
• Redirection-Anzeige erweitert
• „Nicht mehr fragen" entfernt
• KB5036892 / April-CU

Technischer Deep Dive: Wie .rdp-Dateien funktionieren

Eine .rdp-Datei ist eine einfache UTF-16-LE-Textdatei im Format key:type:value pro Zeile. Jede Zeile konfiguriert einen Aspekt der Verbindung — vom Zielserver über die Auflösung bis zu sensiblen Redirection-Flags. Ein Minimal-Beispiel:

full address:s:rdp.hostspezial.de:3389
# Credentials-Prompt (vor Verbindung)
prompt for credentials:i:1
authentication level:i:2
# Redirections — hier sitzt das Risiko
redirectclipboard:i:1
redirectprinters:i:1
redirectsmartcards:i:1
redirectwebauthn:i:1
drivestoredirect:s:*
# Signatur-Felder (nur bei signierten Dateien)
signscope:s:Full
signature:s:AQABAAAAA...

Die Felder signscope und signature existieren ausschließlich in signierten Dateien. signscope:Full bedeutet, dass alle Felder außer der Signatur selbst in die Hashbildung eingehen. Das signature-Feld ist Base64-kodiert und enthält die PKCS#7-Signatur über diesen Hash, erzeugt mit dem privaten Schlüssel eines Code-Signing-Zertifikats.

Was bedeutet „Publisher" technisch?

Der „Herausgeber" (Publisher) einer .rdp-Datei ist der Common Name (CN) des Code-Signing-Zertifikats, mit dem die Datei signiert wurde. Der RDP-Client validiert in genau dieser Reihenfolge:

• Signatur vorhanden? Falls nicht → „Unbekannter Herausgeber".
• Hash-Verifikation über die abgedeckten Felder gegen das signature-Blob. Schlägt fehl, falls die Datei nach Signierung verändert wurde.
• Trust-Chain — lässt sich das Signaturzertifikat zu einer vertrauenswürdigen Wurzel im Windows-Certificate-Store auflösen?
• Trusted-Publisher-Check — steht der Thumbprint des Signaturzertifikats in der GPO-Liste „Trusted RDP Publishers"? Falls ja → keine Warnung, Verbindung öffnet direkt.

Warum Redirections die eigentliche Angriffsfläche sind

Die Warnung ist im Kern ein Proxy-Warnhinweis. Die echte Sicherheitsentscheidung steckt in den redirect*-Flags. Besonders kritisch:

• redirectclipboard:i:1 — Clipboard zwischen Client und Server wird geteilt. Kopiert der Nutzer versehentlich einen Passwort-Manager-Eintrag, landet er beim Angreifer.
• drivestoredirect:s:* — alle lokalen Laufwerke werden in die Session gemountet. Angreifer kann Dateien lesen, schreiben, Malware platzieren.
• redirectwebauthn:i:1 — seit Windows 11 22H2 werden FIDO2/Passkey-Ceremonies an den Remote-Host weitergeleitet. In einer Phishing-RDP heißt das: Der Angreifer kann Passkey-Flows anstoßen.
• redirectsmartcards:i:1 — analog für Smartcard-PIN-Ceremonies.

Warum das ein echtes Sicherheitsrisiko ist

Aus Angreifer-Perspektive ist eine böswillige .rdp-Datei ein sehr günstiger Eintrittsvektor. Drei realistische Szenarien, die in den letzten Monaten dokumentiert wurden:

Szenario 1 — Credential-Phishing via RDP-Attachment

Eine Spear-Phishing-Mail gibt vor, Rechnungsportal oder Lieferantenzugang zu sein und enthält rechnung_2026.rdp im Anhang. Beim Doppelklick öffnet sich ein vollwertiges Anmeldefenster mit dem Branding eines bekannten Dienstes — tatsächlich läuft die Session gegen einen vom Angreifer kontrollierten Server, der das Anmeldefenster nachstellt. Zusätzlich fängt der Session-Host per WebAuthn-Redirection eingeleitete Passkey-Flows ab.

Szenario 2 — Clipboard-Exfiltration

Ein Mitarbeiter meldet sich an einer legitim aussehenden „Kundenportal"-RDP-Verbindung an. Im Hintergrund läuft auf dem Remote-Host ein Script, das das geteilte Clipboard jede Sekunde abfragt. Sobald der Anwender lokal im Passwort-Manager etwas kopiert (API-Token, VPN-Secret, SSH-Key-Passphrase), landet es im Protokoll des Angreifers.

Szenario 3 — Lateral Movement via Drive-Redirection

Gelingt es dem Angreifer, dass ein Nutzer einmalig eine manipulierte .rdp mit drivestoredirect:s:* öffnet, hat er Read-/Write-Zugriff auf alle erreichbaren lokalen Laufwerke inklusive gemappter Netzlaufwerke. Persistence-Payloads platzieren, .pst- oder OneDrive-Sync-Dateien stehlen, Ransomware-Stager deployen — alles in einer Session.

So beheben Sie das Problem produktionsreif

Der saubere Weg besteht aus drei Bausteinen: Code-Signing-Zertifikat bereitstellen, RDP-Dateien mit rdpsign signieren, Thumbprint per GPO als Trusted Publisher ausrollen.

Schritt 1 — Code-Signing-Zertifikat bereitstellen

Drei Optionen, abhängig von Ihrer PKI-Strategie:

Für interne CA-Deployments auf Windows Server AD Certificate Services erstellen Sie eine Template-Kopie von „Code Signing", binden die Ausstellung an eine Security-Gruppe RDP-Signierer, und beziehen das Zertifikat über die MMC oder certreq.exe.

Schritt 2 — RDP-Datei mit rdpsign signieren

Das Microsoft-Bordmittel rdpsign.exe liegt unter %SystemRoot%\System32\ und existiert seit Windows Server 2008 R2 / Windows 7.

# Thumbprint des Signatur-Zertifikats aus dem Cert-Store
$cert = Get-ChildItem -Path Cert:\CurrentUser\My |
    Where-Object {
        $_.Subject -like "*CN=HostSpezial RDP Signing*" -and
        $_.EnhancedKeyUsageList.FriendlyName -contains "Code Signing"
    }
$thumb = $cert.Thumbprint

# Einzelne Datei signieren
rdpsign.exe /sha256 $thumb "C:\RDP\rdp-fileserver.rdp"

# Batch: alle Dateien im Share signieren
Get-ChildItem "\\fs01\rdp-shares\*.rdp" | ForEach-Object {
    rdpsign.exe /sha256 $thumb $_.FullName
    Write-Host "Signed: $($_.Name)"
}

Nach erfolgreicher Signierung finden Sie am Ende der .rdp-Datei die neuen Felder signscope:s:Full und signature:s:.... Manuelle Änderungen an der Datei brechen die Signatur und erfordern erneutes Signieren.

Schritt 3 — Trusted Publisher per GPO ausrollen

Damit Clients die signierten Dateien ohne Warnung öffnen, muss der Thumbprint des Signaturzertifikats auf allen Clients hinterlegt werden. Pfad in der Group Policy Management Console:

In dieses Policy-Feld tragen Sie den SHA-256-Thumbprint Ihres Zertifikats ein (Hex-String ohne Leerzeichen). Mehrere Thumbprints werden durch Semikolon getrennt.

Weitere relevante Policies:

• „Signierte .rdp-Dateien von externen Herausgebern zulassen" — Aktiviert lassen, damit Dateien von Drittfirmen (z. B. externer Dienstleister) überhaupt öffenbar sind.
• „Unsignierte .rdp-Dateien und Verbindungen zulassen" — für produktive Umgebungen auf Deaktiviert setzen. Dann lassen sich nur signierte Dateien von Trusted Publishers ohne Warnung öffnen.

Alternativ registryseitig für PowerShell-Deployment via GPO oder Intune:

# Trusted Thumbprints setzen
$key = "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services"
New-ItemProperty -Path $key -Name "TrustedCertThumbprints" `
    -Value "A1B2C3D4E5F60718293A4B5C6D7E8F9012345678" `
    -PropertyType String -Force

# Unsignierte Dateien blockieren
New-ItemProperty -Path $key -Name "AllowUnsignedFiles" `
    -Value 0 -PropertyType DWord -Force

Häufige Fehler bei der Umsetzung

• Zertifikat ohne EKU „Code Signing" — reines Server-Authentication- oder User-Cert funktioniert nicht. Das Template muss 1.3.6.1.5.5.7.3.3 enthalten.
• Thumbprint mit Leerzeichen kopiert — aus der MMC-Oberfläche kopieren erzeugt Leerzeichen alle 2 Zeichen. Vorher entfernen: $tp -replace ' ',''.
• Zertifikat nicht in Trusted Root der Clients — wenn die ausstellende CA nicht via AD automatisch verteilt wird, muss das Root-CA-Cert separat ausgerollt werden.
• GPO greift, Clients bekommen sie trotzdem nicht — RDP-Client-Policies greifen unter Computerkonfiguration, nicht unter User. Security-Filtering der GPO muss die Clients einschließen.
• Signatur bricht nach Editieren im Texteditor — jeder Byte-Eingriff invalidiert die Signatur. Immer zentrales Template pflegen und per Skript signieren.

Warnung unterdrücken — und warum nicht empfohlen

Rein technisch lässt sich die Warnung per GPO global ausschalten — die Policy „Unsignierte .rdp-Dateien zulassen" auf Aktiviert. Wir raten davon nachdrücklich ab, aus drei Gründen:

• Sie entfernen den Phishing-Schutz. Die Policy wirkt nicht nur auf Ihre eigenen Dateien, sondern auch auf Phishing-Attachments. Sie demontieren genau den Schutz, den Microsoft jetzt einführt.
• Compliance-Thema. Die Policy signalisiert Ihren Auditor:innen, dass Sie aktiv eine Microsoft-Empfehlung deaktivieren. Das landet im Audit-Report (ISO 27001, TISAX, NIS2).
• Der Weg zurück ist aufwändig. Trusted-Publisher-Rollouts im Nachgang gegen bereits umgewöhnte User einzuführen, kostet Akzeptanz.

Wenn Sie einzelne Legacy-Szenarien haben, in denen Signierung nicht möglich ist (z. B. dynamisch generierte .rdp-Dateien aus einem SAP-Portal), ist die saubere Alternative oft der Weg über RD Web Access oder RD Gateway mit RemoteApp-Publishing. Dort wird die Verbindung nicht mehr über .rdp-Dateien, sondern über .wcx/WebFeed-Subscriptions initiiert — automatisch signiert durch den RD-Connection-Broker.

Best Practices für Enterprises

Zentrales RDS-Deployment statt .rdp-Verteilung

Der strategisch bessere Weg: gar nicht mehr .rdp-Dateien per Mail/Share verteilen, sondern RDS mit Session-Collections und RemoteApp-Publishing betreiben. Anwender abonnieren einmalig einen RD-Web-Feed und bekommen alle RemoteApps automatisch signiert ins Startmenü. Signierung und Patch-Lifecycle in einem Schritt gelöst.

Zertifikats-Lifecycle planen

Code-Signing-Zertifikate haben typisch 1–3 Jahre Laufzeit. Wenn Ihr Zertifikat abläuft, bleiben bisher signierte Dateien gültig, solange der Client die Chain auflösen kann — aber neue Dateien brauchen das neue Cert:

• Ablaufdatum 60 Tage vorher im Monitoring (Zabbix, Checkmk, Azure Monitor) alarmieren.
• Renewal-Prozess dokumentieren, Thumbprint-Update in GPO als Change-Task planen.
• Bei Rotation: beide Thumbprints (alt + neu) für Übergangsphase in der Trusted-List; später alten entfernen.

Signier-Automatisierung

Integration in Ihren Deployment-Prozess: Skript in einem internen Git-Repo, .rdp-Templates dort versionieren, bei Check-in automatisch per CI-Job signieren und in den Deployment-Share kopieren. Signierung wird damit Teil Ihres regulären Change-Managements — kein vergessener Einzelschritt.

Zero-Trust-Überlegung

Signierte RDP-Dateien sind eine Kontrollebene. Ergänzen Sie sie durch MFA am Zielserver, Conditional Access über RD Gateway, Session-Recording für kritische Admin-Server und erzwungene Network Level Authentication (NLA). .rdp-Signierung schützt den Client-Pfad; die Server-Seite braucht ihre eigenen Mechanismen.

Troubleshooting — Warnung bleibt trotz Signierung

Der häufigste Frustmoment: signiert, Thumbprint via GPO ausgerollt, gpupdate /force gemacht — Warnung kommt trotzdem. In 95 % der Fälle eine dieser Ursachen:

1 · Client hat Policy nicht angewandt

gpresult /h gpreport.html
:: Öffnen und prüfen, ob die RDP-Trust-Policy unter "Applied GPOs" erscheint

:: Registry direkt:
reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v TrustedCertThumbprints

2 · Thumbprint-Format stimmt nicht

Alle Buchstaben Großbuchstaben (A–F), keine Leerzeichen, keine Kommata. Exakt 40 Zeichen (SHA-1) bzw. 64 Zeichen (SHA-256).

3 · Zertifikat-Chain fehlt

Signatur technisch prüfen: certutil -verify -urlfetch unsigned.rdp. Bei „Chain building failed" fehlt das Intermediate oder Root-CA im lokalen Store. Bei Domain-Clients sollte AD-Autoenrollment das erledigen; bei Non-Domain-Clients Root-CA manuell via certutil -addstore Root rootCA.cer importieren.

4 · Datei wurde nach Signierung verändert

Kleinster Eingriff invalidiert die Signatur. Prüfen:

# signscope/signature müssen am Ende stehen
Get-Content "C:\RDP\server01.rdp" -Encoding Unicode |
    Select-String "signscope|signature"

5 · Encoding-Problem

.rdp-Dateien müssen UTF-16-LE mit BOM sein. Wurden sie mit iconv, Get-Content | Set-Content ohne expliziten Encoding-Parameter oder einem Linux-Editor gespeichert, landen sie oft als UTF-8 oder ohne BOM. Rettung:

$content = Get-Content "broken.rdp" -Raw
[System.IO.File]::WriteAllText("fixed.rdp", $content, [System.Text.Encoding]::Unicode)
rdpsign.exe /sha256 $thumb "fixed.rdp"

6 · Multiple RDP-Clients auf der Workstation

Die UWP-„Remote Desktop"-App aus dem Store nutzt einen separaten Trust-Store als mstsc.exe. Thumbprint-Deployment dort läuft über App-Settings oder MDM/Intune-Policy (Abschnitt „Remote Desktop App") — nicht über die klassische RDP-Client-GPO.

Fazit — und was das für Ihre IT-Strategie bedeutet

Die neue Warnung ist keine Schikane, sondern eine längst überfällige Korrektur einer seit Jahren aktiv ausgenutzten Angriffsfläche. Für Administratoren ist sie kurzfristig schmerzhaft — mit klarer Perspektive: Microsoft wird diesen Kurs fortsetzen. In den Release-Notes zum April-Update steht, dass in folgenden Kumulativ-Updates die „Nicht mehr fragen"-Option endgültig entfernt wird.

Wer jetzt auf Signierung umstellt, gewinnt mehrfach:

• Keine Supporttickets mehr wegen der Warnung.
• Echter Phishing-Schutz — Ihre signierten Dateien unterscheiden sich visuell von Fake-Dateien.
• Compliance-Bonus — saubere Trust-Chain für ISO 27001, TISAX, NIS2, KRITIS-Audits.
• Grundlage für weitere RDS-Professionalisierung (RemoteApp, Web Access, Session-Recording).

FAQ