Ausgangslage: Fernwartung ist ein privilegierter Administrationspfad

Remote-Monitoring-and-Management-Werkzeuge sind im Betrieb nützlich: Sie verteilen Software, führen Skripte aus, öffnen interaktive Sitzungen, übertragen Dateien und beheben Störungen ohne Vor-Ort-Termin. Genau diese Funktionen machen sie zu einem hoch privilegierten Kontrollpfad. Ein dauerhaft laufender Agent arbeitet häufig als SYSTEM, akzeptiert Aufgaben aus einer Cloud-Steuerung und erreicht viele Endgeräte gleichzeitig. Wird ein fremdes Werkzeug installiert oder die genehmigte Plattform übernommen, entsteht deshalb kein gewöhnlicher Softwarefund, sondern ein möglicher administrativer Zugang zur Umgebung.

„Unerwünscht“ bedeutet dabei mehr als „Produkt steht nicht in der Einkaufsliste“. Zum Scope gehören:

  • ein zweiter, von einer Fachabteilung oder einem Dienstleister installierter RMM-Agent,
  • portable Fernsupport-Werkzeuge, die ohne Installation aus Benutzerverzeichnissen starten,
  • Ad-hoc-Helfer, die Benutzer nach einer Support-Anweisung herunterladen,
  • alte Agenten, deren Vertrag beendet wurde, deren Dienste aber weiterlaufen,
  • eine genehmigte Software, die mit einem fremden Mandanten oder nicht freigegebenen Technikeridentitäten verbunden ist,
  • Browser-Erweiterungen, Remote-Desktop-Gateways und Management-APIs mit vergleichbarer Steuerungswirkung,
  • legitime Betriebsmittel, die auf Systemen oder in Sicherheitszonen eingesetzt werden, für die sie nie freigegeben wurden.

Eine reine Produkt-Denylist greift zu kurz. Dateinamen lassen sich ändern, portable Varianten hinterlassen keinen Uninstall-Eintrag, signierte Anwendungen werden regelmäßig aktualisiert und mehrere Dienste können dieselben Hosting-, CDN- oder Cloud-Netze nutzen. Umgekehrt verursacht ein pauschales Verbot schnell Betriebsstörungen: Helpdesk, Softwareverteilung, Monitoring, Backup und externe Wartung können von der genehmigten Plattform abhängen.

Für Active Directory ist der Zusammenhang unmittelbar. Techniker können über eine Fernwartungssitzung administrative Tokens, Kennworteingaben, Browser-Sitzungen, Managementkonsolen oder gespeicherte Anmeldedaten erreichen. Läuft derselbe Agent auf Domain Controllern, Zertifizierungsstellen oder Microsoft-Entra-Connect-Systemen, wird die RMM-Steuerung faktisch Teil von Tier 0. Selbst ein sauber gehärtetes AD verliert an Wert, wenn eine separate Cloud-Steuerungsebene dieselben Systeme mit schwächerer Identitätssicherung administrieren darf.

Die Aufgabe lautet daher nicht „möglichst viele Remote-Tools blockieren“. Sie lautet: für jede Sicherheitszone einen explizit genehmigten, nachvollziehbaren Fernadministrationspfad schaffen, diesen wie eine privilegierte Plattform schützen und alle anderen Pfade technisch sowie organisatorisch begrenzen.

Zielbild: genehmigte Kontrollpfade ohne Schattenadministration

Ein belastbarer Zielzustand verbindet Identität, Endpunkt, Netzwerk und Betrieb:

  1. Jeder Fernadministrationsdienst hat einen Owner und einen freigegebenen Zweck. Plattform, Mandant, Zielgruppen, Funktionen, Betriebszeiten und verantwortliche Teams sind dokumentiert.
  2. Die genehmigte RMM-Plattform gilt als privilegierte Identitäts- und Steuerungsebene. Techniker nutzen persönliche Konten, phishing-resistente MFA, rollenbasierte Rechte und gehärtete Admin-Arbeitsplätze. Gemeinsame Supportkonten und dauerhaft privilegierte Rollen entfallen.
  3. Tier 0 bleibt getrennt. Domain Controller, AD CS, Entra Connect, Föderationssysteme und andere Tier-0-Komponenten werden nicht durch den allgemeinen Endgeräte-RMM verwaltet. Falls Fernadministration zwingend erforderlich ist, nutzt sie einen gesonderten, isolierten Pfad mit eigenen Identitäten, Richtlinien und Protokollen.
  4. Installierte und portable Nutzung sind inventarisiert. Softwarebestand, Dienste, geplante Aufgaben, laufende Prozesse, Netzwerkverbindungen, Browser-Komponenten, Identity-Provider-Anwendungen und Beschaffungsdaten werden zusammengeführt.
  5. App Control setzt den Normalfall durch. Nur freigegebene, passend signierte und aus einem kontrollierten Deploymentpfad bereitgestellte Komponenten dürfen starten. Die Einführung erfolgt zuerst im Audit-Modus und in gestaffelten Ringen.
  6. Temporäre Indikatoren schließen akute Lücken. Hash-, Zertifikat-, URL- oder IP-Indikatoren in der Endpoint-Security dienen als befristete Eindämmung, nicht als dauerhafte Architektur.
  7. Netzwerkzugriff ist nach Gerätegruppe und Zweck begrenzt. Direkte, unkontrollierte Ausgänge werden reduziert; Proxy-, DNS-, Firewall- und EDR-Telemetrie machen Remote-Control-Verbindungen nachvollziehbar.
  8. Sitzungen sind zurechenbar und überprüfbar. Anmeldung, Freigabe, Dateitransfer, Shell- oder Skriptausführung, Rechteänderungen und API-Nutzung werden manipulationsgeschützt zentral protokolliert und außerhalb des direkten RMM-Adminzugriffs aufbewahrt.
  9. Ausnahmen besitzen Owner und Ablaufdatum. Sie gelten für exakt bezeichnete Geräte, Benutzer, Komponenten und Funktionen und werden automatisch zur erneuten Entscheidung vorgelegt.
  10. Für unbekannte Funde existiert ein Incident-Runbook. Es unterscheidet Fehlkonfiguration, Schatten-IT, vergessene Dienstleisterzugänge und mögliche Kompromittierung, ohne Spuren durch vorschnelles Entfernen zu vernichten.

Der Zielzustand ist nicht „ein erlaubter Hersteller“. Auch eine genehmigte Anwendung ist auf dem falschen System, mit dem falschen Mandanten oder unter einer unkontrollierten Identität unerwünscht.

Umsetzung: von der Bestandsaufnahme zur durchgesetzten Kontrolle

1) Scope, Tiering und Verantwortlichkeiten zuerst festlegen

Beginne mit den administrativen Zonen, nicht mit einer Liste von Produktnamen. Trenne mindestens Benutzerendgeräte, Standardserver, besonders kritische Applikationsserver, Managementsysteme und Tier 0. Ordne jeder Zone zulässige Supportwege zu. Für Clients kann unbeaufsichtigter Fernsupport vertretbar sein, während auf einem Domain Controller nur ein gehärteter Adminpfad mit interaktiver Freigabe und enger Rollenbindung zulässig ist – oder gar kein RMM-Agent.

Für die genehmigte Plattform müssen mindestens Service Owner, Security Owner, Plattformadministratoren, Helpdesk-Rollen und externe Dienstleister benannt sein. Dokumentiere außerdem, wer neue Zielsysteme aufnehmen, Techniker freischalten, Richtlinien ändern, Skripte veröffentlichen und Logs löschen oder exportieren darf. Diese administrativen Meta-Rechte sind häufig kritischer als die einzelne Fernwartungssitzung.

Erfasse die tatsächlichen Geschäftsprozesse: Benutzerhilfe, Serverwartung, Bereitschaft, Softwareverteilung, Monitoring, Third-Party-Support und Notfallbetrieb. Ein Verbot ohne Ersatzpfad führt fast zuverlässig zu neuen Ad-hoc-Werkzeugen. Gleichzeitig ist „Support benötigt Fernzugriff“ keine ausreichende Begründung für unbegrenzten Dateitransfer, Hintergrund-Shells oder Zugriff auf jede Sicherheitszone.

2) Installierte, portable und cloudgebundene Nutzung inventarisieren

Eine belastbare Inventur kombiniert mehrere Datenquellen:

  • EDR- und Softwareinventar für installierte Pakete, Dienste, Treiber und Autostarts,
  • Prozess-, Modul- und Netzwerk-Telemetrie für portable oder umbenannte Programme,
  • Softwareverteilung und Paketverwaltung als Quelle des genehmigten Installationswegs,
  • Proxy-, Firewall- und DNS-Protokolle für wiederkehrende Remote-Control-Ziele,
  • Browser- und Erweiterungsverwaltung für webbasierte Supportpfade,
  • Identity-Provider, Enterprise Applications, OAuth-Zustimmungen und API-Schlüssel,
  • CMDB, Beschaffung, Lizenzverwaltung und Dienstleisterverträge,
  • geplante Aufgaben, Startup-Verzeichnisse und persistente Benutzerkomponenten.

Der folgende PowerShell-Block verändert nichts. Er liefert auf einem Windows-System eine Momentaufnahme nicht deaktivierter Dienste sowie etablierter TCP-Verbindungen. Pfad und Signaturstatus werden nur für den jeweils verbindungsführenden Prozess ermittelt. Das Ergebnis ist ein Ausgangspunkt für die Prüfung, keine automatische RMM-Klassifizierung:

& {
  Set-StrictMode -Version Latest

  Get-CimInstance -ClassName Win32_Service -ErrorAction Stop |
    Where-Object { $_.StartMode -ne 'Disabled' } |
    ForEach-Object {
      [pscustomobject]@{
        RecordType = 'Service'
        Name       = $_.Name
        State      = $_.State
        StartMode  = $_.StartMode
        StartName  = $_.StartName
        ImagePath  = $_.PathName
        RemoteIP   = $null
        RemotePort = $null
        Signature  = $null
        Signer     = $null
      }
    }

  Get-NetTCPConnection -State Established -ErrorAction SilentlyContinue |
    ForEach-Object {
      $process = Get-Process -Id $_.OwningProcess -ErrorAction SilentlyContinue
      $executablePath = $null
      $processName = $null
      if ($process) {
        $processName = $process.ProcessName
        try { $executablePath = $process.Path } catch { }
      }

      $signatureStatus = $null
      $signerSubject = $null
      if ($executablePath -and
          (Test-Path -LiteralPath $executablePath -PathType Leaf)) {
        $signature = Get-AuthenticodeSignature -LiteralPath $executablePath
        $signatureStatus = [string]$signature.Status
        if ($signature.SignerCertificate) {
          $signerSubject = $signature.SignerCertificate.Subject
        }
      }

      [pscustomobject]@{
        RecordType = 'Connection'
        Name       = $processName
        State      = 'Established'
        StartMode  = $null
        StartName  = $null
        ImagePath  = $executablePath
        RemoteIP   = $_.RemoteAddress
        RemotePort = $_.RemotePort
        Signature  = $signatureStatus
        Signer     = $signerSubject
      }
    }
}

Führe solche Abfragen über die vorhandene, geschützte Endpoint-Verwaltung aus und speichere Ergebnisse nur in einem zugriffsbeschränkten Arbeitsbereich. Prozesspfade, Benutzernamen und Verbindungsziele können sicherheitsrelevante Informationen enthalten. Eine einzelne Momentaufnahme übersieht kurzlebige Prozesse und ausgeschaltete Geräte; zentral gesammelte Telemetrie über einen angemessenen Zeitraum bleibt notwendig.

Klassifiziere Treffer nicht allein nach Dateiname oder Herstellerfeld. Prüfe Signaturkette, ursprünglichen Dateinamen, Produktmetadaten, Installationsquelle, Dienstdefinition, Parent-Prozess, Zielsysteme, Netzwerkziele und den zugeordneten Mandanten. Eine gültige Authenticode-Signatur bestätigt die Integrität seit der Signatur und die über eine vertrauenswürdige Zertifikatskette ausgewiesene Herausgeberidentität; sie beweist weder Unbedenklichkeit noch betriebliche Freigabe.

3) Die genehmigte Plattform wie ein privilegiertes System härten

Der RMM-Mandant verdient denselben Schutz wie andere zentrale Administrationssysteme. Erzwinge Single Sign-on mit phishing-resistenter MFA und verhindere lokale Plattformkonten, soweit technisch möglich. Getestete, unabhängig geschützte Notfallidentitäten richten sich nach Hersteller- und Verfügbarkeitsanforderungen und bleiben auf den tatsächlichen Notfall begrenzt. Techniker erhalten persönliche Identitäten; Rollen werden nach Funktion und Zielgruppe getrennt. Privilegien werden zeitlich begrenzt aktiviert und regelmäßig rezertifiziert.

Plattformadministration und täglicher Support gehören auf verwaltete Admin-Arbeitsplätze. Conditional-Access- oder vergleichbare Zugriffsregeln begrenzen die Anmeldung auf konforme Geräte und erwartete Standorte. Externe Dienstleister erhalten eigene, befristete Identitäten statt geteilter Konten. Offboarding muss SSO-Zugriff, lokale Konten, API-Tokens, Gerätezertifikate und noch aktive Sitzungen umfassen.

Beschränke riskante Funktionen rollenbezogen: Hintergrund-Shell, Skriptausführung, Dateitransfer, Credential-Verwendung, Zwischenablage, Sitzungsaufzeichnung und das Abschalten von Sicherheitskontrollen. Wo möglich, werden administrative Credentials durch einen Vault injiziert, nicht dem Techniker angezeigt oder auf dem Zielgerät gespeichert. Plattform-API-Schlüssel liegen in einem Secret Store, besitzen minimalen Scope, kurze Gültigkeit und einen getesteten Rotationsprozess.

Änderungen an Richtlinien, Rollen, Skriptbibliotheken, Agentenpaketen, Tenant-Bindung und Log-Konfiguration benötigen Vier-Augen-Freigabe oder zumindest eine unabhängige Alarmierung. Die Plattform darf niemals von einem dauerhaft verwendeten Domain-Admin-Konto abhängen. Ein Agent mit SYSTEM-Rechten macht den Plattform- und Identitätsschutz nicht optional, sondern besonders wichtig.

Definiere verbindliche Patch- und Advisory-Fristen für Konsole, Gateways, Agenten und Integrationen. Massenaktionen wie Skriptläufe, Softwareverteilung oder Richtlinienänderungen über viele Geräte benötigen eine sichtbare Zielvorschau, erneute Authentifizierung und ab einem risikobasierten Schwellenwert eine zweite Freigabe. Begrenzte Parallelität und ein getesteter Abbruchpfad reduzieren den Schaden einer fehlerhaften oder missbräuchlichen Aufgabe.

4) Tier 0 technisch und administrativ abtrennen

Der allgemeine Client- oder Server-Agent gehört standardmäßig nicht auf Domain Controller, AD-Zertifizierungsstellen, Entra-Connect-Server, Föderationsdienste, privilegierte Access Workstations oder andere Tier-0-Komponenten. Eine globale RMM-Gruppe wie „alle Windows-Server“ darf diese Systeme nicht versehentlich einschließen. Nutze separate Gerätegruppen, Deployment-Sperren und eine unabhängige Kontrollabfrage, die fehlende Agenten auf Tier 0 als Sollzustand akzeptiert.

Muss ein Tier-0-System fernadministriert werden, ist ein eigener Pfad erforderlich: getrennte Adminidentitäten, gehärtete Quellsysteme, keine Anmeldung aus dem normalen Helpdesk-Kontext, enges Netzwerk-Allowlisting, sitzungsbezogene Freigabe und vollständige Protokollierung. Je nach Betriebsmodell kann ein isolierter Managementhost, ein privilegierter Session-Broker oder eine getrennte RMM-Instanz geeigneter sein. Entscheidend ist, dass eine Kompromittierung des normalen Support-Control-Planes nicht automatisch Tier 0 erreicht.

Auch indirekte Wege zählen. Ein RMM-Server, Softwareverteilungssystem oder Jump Host, der Domain-Admin-Credentials speichert, auf DCs interaktiv zugreifen darf oder Tier-0-Pakete signiert, wird selbst Teil dieser Zone. Servicekonten erhalten keine pauschalen interaktiven oder Netzwerk-Logon-Rechte. Lokale Administratorpasswörter sind eindeutig und werden je Gerät verwaltet; wiederverwendete Secrets zerstören die Segmentierungswirkung.

5) App Control zuerst im Audit-Modus und in Ringen einführen

App Control for Business, früher häufig Windows Defender Application Control genannt, ist eine robuste technische Schicht gegen nicht genehmigte ausführbare Komponenten. AppLocker kann je nach Plattform und bestehendem Betriebsmodell eine ergänzende oder vorläufige Kontrolle sein. Entscheidend ist ein positiv definiertes Ausführungsmodell, nicht eine wachsende Sammlung blockierter Dateinamen.

Erzeuge zunächst eine Baseline aus dem kontrollierten Betrieb: Betriebssystemkomponenten, verwaltete Softwarepakete, intern signierte Werkzeuge und der genehmigte RMM-Agent. Bevorzuge geeignete Publisher- und Signer-Regeln mit ausreichend enger Produktbindung. Reine Pfadregeln in benutzerbeschreibbaren Verzeichnissen sind schwach; reine Hashregeln brechen bei jedem Update. Managed-Installer- oder vergleichbare Deployment-Vertrauensmodelle helfen, verlangen aber eine ebenso sorgfältige Absicherung des Softwareverteilungswegs.

Die Einführung erfolgt gestaffelt:

  1. Labor- und IT-Testgeräte mit Audit-Telemetrie,
  2. Security- und Administrationsarbeitsplätze,
  3. repräsentative Benutzerpiloten mit Fachanwendungen,
  4. breite Client-Ringe,
  5. Server nach Anwendungsklasse und Kritikalität,
  6. separate, strengere Richtlinien für Management- und Tier-0-Zonen.

Werte Audit-Ereignisse auf echte Abhängigkeiten, Updatepfade, Plug-ins, Skript-Hosts und Hilfsprogramme aus. Jede Ergänzung braucht einen Owner und eine nachvollziehbare Quelle. Danach wird Ring für Ring in den Enforcement-Modus überführt. Halte einen getesteten Recovery-Pfad bereit, falls eine notwendige Binärdatei blockiert wird. Eine globale Deaktivierung der Policy ist kein angemessener Rollback.

Erlaube nicht pauschal jeden Code eines Herstellers, nur weil dessen RMM-Produkt genehmigt ist. Große Signaturbereiche können andere, nicht benötigte Werkzeuge einschließen. Umgekehrt darf eine Blockregel für einen Signer nicht ungeprüft andere geschäftskritische Produkte desselben Herausgebers treffen.

6) Defender-Indikatoren nur als befristete Eindämmung verwenden

Bei einem bestätigten unerwünschten Fund ist die App-Control-Änderung möglicherweise noch nicht ausgerollt. Endpoint-Indikatoren für konkrete Hashes, Zertifikate, URLs, Domains oder IP-Adressen können die Lücke kurzfristig schließen. Jeder Indikator benötigt Quelle, Begründung, Zielgruppe, Erstellungszeitpunkt, Owner und Ablaufdatum.

Hash-Sperren werden durch normale Updates oder neu gepackte portable Dateien schnell obsolet. Zertifikatssperren haben größere Reichweite und können weitere Produkte desselben Herausgebers treffen. Domains und IP-Adressen können mandantenübergreifend geteilt, dynamisch oder für legitime Dienste relevant sein. Vor einer breiten Sperre sind Pilotierung, Abhängigkeitsprüfung und ein definierter Rückweg erforderlich.

Bei Microsoft Defender for Endpoint gelten zusätzliche Voraussetzungen: Datei- und Zertifikatsindikatoren benötigen Defender Antivirus im aktiven Modus sowie Cloudschutz; die Durchsetzung von URL- und IP-Indikatoren außerhalb von Microsoft Edge setzt Network Protection voraus. Zertifikatsindikatoren beziehen sich auf das Blattsignaturzertifikat, und Microsoft-signierte Anwendungen lassen sich auf diesem Weg nicht sperren. Richtlinien wirken zudem nicht sofort überall. Prüfe den Enforcement-Status auf Pilotgeräten, bevor die Eindämmung als abgeschlossen gilt.

Überführe bestätigte, dauerhafte Anforderungen in App Control, Deployment-Policies und Plattform-Governance. Eine über Jahre gewachsene Indikatorliste ist schwer prüfbar und vermittelt falsche Sicherheit. Sie erkennt außerdem nicht, ob eine erlaubte Binärdatei an den falschen RMM-Mandanten gebunden wurde.

7) Ausgehende Verbindungen und Tenant-Bindung begrenzen

Host-Firewall, Secure Web Gateway, DNS-Kontrolle und Netzwerksegmentierung reduzieren alternative Fernzugriffspfade. Wo der Betrieb es zulässt, kommunizieren Endgeräte nur über kontrollierte Resolver und Proxys; direkte ausgehende Verbindungen werden eingeschränkt. Die genehmigte RMM-Komponente erhält dokumentierte Ziele, Ports und Protokolle pro Gerätegruppe. Server und Tier 0 nutzen strengere Regeln als Benutzerclients.

Statische IP-Listen sind bei Cloud-Diensten oft ungeeignet. Verwende die dokumentierten, technisch unterstützten Endpunkte und automatisiere deren kontrollierte Aktualisierung. Prüfe WebSockets, Fallback-Transporte und Updatekanäle im Pilotbetrieb. TLS-Inspection kann Zertifikatspinning, Agentenupdates oder Sitzungsaufbau stören und darf nicht ungeprüft aktiviert werden.

Netzwerkfreigaben allein unterscheiden häufig nicht zwischen dem genehmigten und einem fremden Mandanten auf derselben Plattform. Nutze daher, wo verfügbar, signierte Agentenkonfiguration, Organisations- oder Tenant-Bindung, Installations-Tokens mit kurzer Gültigkeit und serverseitige Gerätezulassung. Alarmiere, wenn ein verwaltetes Gerät einen zweiten Fernadministrationskanal aufbaut oder der genehmigte Agent sein erwartetes Ziel wechselt.

8) Telemetrie aus Verhalten und Baseline ableiten

Sammle mindestens Prozessstart, Dienstinstallation, geplante Aufgaben, Netzwerkverbindungen, Dateidownloads, Anmeldeereignisse, Agentenregistrierungen, interaktive Sitzungen, Skript- und Shell-Aktivitäten sowie Plattform-Auditlogs. Logs werden zeitnah an ein System übertragen, das RMM-Administratoren nicht selbst löschen können. Zeitquellen, Geräteidentitäten und Benutzerzuordnung müssen konsistent sein.

Die folgende Microsoft-Defender-Advanced-Hunting-Abfrage arbeitet ohne feste Produktliste. Sie zeigt netzwerkaktive Prozesse aus typischen benutzerbeschreibbaren oder staging-nahen Verzeichnissen. Das ist eine Hypothese für die Prüfung portabler Werkzeuge, kein automatischer Befund:

let lookback = 7d;
DeviceNetworkEvents
| where Timestamp >= ago(lookback)
| where ActionType == "ConnectionSuccess"
| where RemoteIPType == "Public"
| extend LowerPath = tolower(InitiatingProcessFolderPath)
| extend Account = case(
    isnotempty(InitiatingProcessAccountUpn), InitiatingProcessAccountUpn,
    isnotempty(InitiatingProcessAccountName),
      strcat(InitiatingProcessAccountDomain, "/", InitiatingProcessAccountName),
    InitiatingProcessAccountSid
  )
| where LowerPath has_any (
    @"\appdata\", @"\downloads\", @"\users\public\",
    @"\windows\temp\", @"\programdata\"
  )
| summarize
    FirstSeen = min(Timestamp),
    LastSeen = max(Timestamp),
    Connections = count(),
    Destinations = make_set(iff(isnotempty(RemoteUrl), RemoteUrl, RemoteIP), 25),
    Users = make_set(Account, 10),
    Paths = make_set(InitiatingProcessFolderPath, 10)
  by DeviceId, DeviceName, InitiatingProcessFileName, InitiatingProcessSHA1,
     InitiatingProcessVersionInfoCompanyName
| order by LastSeen desc

Passe Zeitraum und Pfadhypothesen an die Umgebung an. ProgramData enthält viele legitime Agenten und erzeugt entsprechend Rauschen; unter Program Files installierte Schattenwerkzeuge erscheinen umgekehrt nicht durch diese Bedingung. Korrelation mit Softwarebestand, Dienstereignissen, Signaturdaten, Ziel-Domains und genehmigter Geräte-Mandanten-Zuordnung ist zwingend.

Gute Erkennungsregeln suchen nicht nur nach bekannten Namen. Sie erkennen neue persistente Dienste mit externem Netzwerkverkehr, ungewöhnliche Kindprozesse eines Support-Agenten, erstmalige Ziele, Fernzugriff außerhalb von Supportzeiten, Nutzung auf nicht freigegebenen Servern sowie Änderungen an Plattformrollen oder Skriptbibliotheken. Baselines werden pro Gerätegruppe geführt; ein Helpdesk-Client und ein Domain Controller haben nicht dasselbe erwartete Verhalten.

9) Unerwünschte Komponenten kontrolliert entfernen

Entferne einen unbekannten Agenten nicht sofort automatisiert. Kläre zuerst, ob ein freigegebener Change, ein vergessener Altvertrag, Schatten-IT oder ein möglicher Sicherheitsvorfall vorliegt. Sichere flüchtige und zentrale Telemetrie, identifiziere Installationszeit, ausführenden Benutzer, Persistenz, Zielsysteme, Mandantenzuordnung und beobachtete Sitzungen. Bei Verdacht auf Kompromittierung entscheidet das Incident-Runbook über Netzwerkisolation, Sperren, forensische Sicherung und Kommunikation.

Für einen betrieblich unerwünschten, aber nicht kompromittierten Agenten erfolgt die Entfernung in einer Pilotgruppe über den vorgesehenen Softwareverteilungsweg. Stoppe und deinstalliere nur eindeutig zugeordnete Komponenten; prüfe anschließend Dienste, Aufgaben, Treiber, Benutzerprofile, Firewallregeln und ausgehende Verbindungen. Ein Neustart und eine erneute Inventur gehören zum Nachweis. Verwende keine generischen Cleanup-Skripte, die anhand unscharfer Namen Dateien oder Registry-Zweige löschen.

Wurde das Werkzeug tatsächlich für Administration genutzt, prüfe betroffene Konten, Tokens, API-Schlüssel und auf Zielgeräten möglicherweise offengelegte Secrets. Rotation erfolgt risikobasiert und über die zuständigen Owner; ein pauschaler Kennwortreset ohne Abhängigkeitsanalyse kann den Betrieb stärker schädigen als der Fund. Für den genehmigten RMM-Mandanten sind aktive Sitzungen, unbekannte Techniker, Rollenänderungen und neue Agentenregistrierungen in denselben Prüfumfang aufzunehmen.

10) Ausnahmen und Incident-Abläufe operationalisieren

Eine Ausnahme enthält mindestens Geschäftsgrund, verantwortlichen Owner, konkrete Geräte und Benutzer, erlaubte Version oder Signatur, benötigte Funktionen, Netzwerkziele, Datenarten, kompensierende Kontrollen, Genehmigung und Ablaufdatum. „Bis zur Ablösung“ ist kein Datum. Kurz vor Ablauf wird die Ausnahme erneut bewertet; ohne bestätigte Verlängerung endet sie technisch.

Begrenze Ausnahmen auf separate Gerätegruppen und minimale Rollen. Unbeaufsichtigter Zugriff, Dateiübertragung oder Hintergrund-Shell werden nur freigegeben, wenn der Use Case sie benötigt. Dienstleisterzugänge orientieren sich an Wartungsfenstern und Tickets. Ein befristetes Werkzeug darf weder Domain-Admin-Credentials erhalten noch Tier 0 erreichen.

Das Incident-Runbook beantwortet vorab:

  • Wer klassifiziert den Fund und wer darf einen Agenten sperren?
  • Welche Telemetrie muss vor der Entfernung gesichert werden?
  • Wann wird ein Gerät isoliert und wann bleibt es zur Beobachtung online?
  • Wie werden unternehmensweit weitere Instanzen über Hash, Signer, Installationspfad, Zielinfrastruktur und Verhalten gesucht?
  • Welche Plattform-, AD- und lokalen Identitäten sind zu prüfen oder zu sperren?
  • Wann sind Datenschutz, Legal, Betriebsrat, Dienstleister- oder Kundenkommunikation einzubeziehen?
  • Wie werden Bereinigung, Wiederanbindung und Credential-Rotation nachgewiesen?

Übe den Ablauf mit einem kontrollierten Testfund. Im Ernstfall ist nicht die Syntax der Sperre das Problem, sondern die Entscheidung, ob ein legitimer Supportprozess oder ein aktiver Fremdzugriff unterbrochen wird.

Vorteile: weniger unkontrollierte Adminpfade und bessere Nachweisbarkeit

  • Die Angriffsfläche sinkt. Portable und installierte Schattenwerkzeuge können nicht beliebig einen zweiten administrativen Kanal öffnen.
  • Tier 0 bleibt von normalem Support getrennt. Eine Kompromittierung des Helpdesk- oder Client-RMM führt nicht automatisch zu Domain Controllern und Zertifizierungsstellen.
  • Technikeraktionen werden zurechenbar. Persönliche Identitäten, kurze Privilegierung und zentrale Sitzungsprotokolle ersetzen gemeinsame Konten und intransparente Fernzugriffe.
  • App Control wirkt auch gegen unbekannte Produkte. Ein positives Ausführungsmodell hängt weniger von einer ständig gepflegten Hersteller- und Hashliste ab.
  • Ausnahmen werden steuerbar. Owner, enger Scope und Ablaufdatum verhindern, dass ein temporärer Dienstleisterzugang dauerhaft bestehen bleibt.
  • Incident Response wird schneller. Inventar, Telemetrie und ein geübtes Runbook liefern Kontext, bevor Systeme vorschnell bereinigt werden.
  • Der genehmigte Betrieb wird robuster. Updatewege, Rollen, Logging, Recovery und Plattform-Tokens erhalten einen klaren Lifecycle.

Nachteile und Grenzen: Kontrolle benötigt laufenden Betrieb

  • App Control verursacht Einführungs- und Pflegeaufwand. Unvollständige Baselines können Fachanwendungen, Updater, Plug-ins oder interne Werkzeuge blockieren. Audit-Ringe und Recovery sind unverzichtbar.
  • Eine genehmigte Plattform bleibt ein attraktives Ziel. Allowlisting schützt weder vor dem Missbrauch eines legitimen Technikers noch vor einer Kompromittierung der RMM-Cloud oder -API.
  • Netzwerksperren sind ungenau. Geteilte Cloud-Infrastruktur, dynamische Endpunkte und verschlüsselte Verbindungen erschweren eine saubere Trennung nach Produkt oder Mandant.
  • Portable und dateilose Varianten erzeugen Erkennungslücken. Prozess-, Identitäts- und Netzwerkverhalten muss die Softwareinventur ergänzen.
  • Strenge Kontrollen können Support verlangsamen. Sitzungsfreigaben, Just-in-Time-Rechte und getrennte Adminpfade erhöhen in manchen Störungen die Bearbeitungszeit.
  • Sitzungsprotokollierung berührt Datenschutz und Mitbestimmung. Zweck, Zugriff, Aufbewahrung und Information der Betroffenen müssen verbindlich geregelt sein.
  • Altgeräte können moderne Policies nicht vollständig unterstützen. Sie benötigen Segmentierung, Ersatzplanung und ein zeitlich begrenztes Risikoregister statt dauerhafter globaler Ausnahmen.
  • Ein Block beweist keine Bereinigung. Nach einem Fund müssen Persistenz, aktive Sitzungen, Identitäten und möglicherweise verwendete Credentials separat geprüft werden.
  • Das Verfahren ersetzt keine AD-Basiskontrollen. Tiering, LAPS, Credential Guard, MFA, PAWs, restriktive Logon-Rechte und sichere Backups bleiben erforderlich.

Typische Stolperfallen

  • Nur Uninstall-Einträge auswerten und portable Programme, Benutzerinstallationen oder Browserpfade übersehen.
  • Ein Werkzeug anhand des Dateinamens klassifizieren, ohne Signatur, Ursprung, Mandant und tatsächliches Verhalten zu prüfen.
  • Jeden signierten Code des genehmigten Herausgebers pauschal erlauben.
  • Hash-Denylisten als dauerhafte Strategie behandeln und Updates oder neu gepackte Dateien übersehen.
  • Eine ganze Domain oder ein Signierzertifikat blockieren, ohne Shared-Hosting- und Produktabhängigkeiten zu testen.
  • Den genehmigten Agenten auf „alle Server“ ausrollen und Tier-0-Systeme unbeabsichtigt einschließen.
  • Die RMM-Konsole mit schwacher MFA, gemeinsamen Konten oder dauerhaft privilegierten Rollen betreiben.
  • Externe Techniker beim Vertragsende nur im Ticketsystem entfernen, aber lokale Konten, Tokens und Sitzungen aktiv lassen.
  • Dateitransfer, Shell und Skriptausführung für jede Supportrolle freigeben.
  • Tenant-Bindung ignorieren und nur prüfen, ob die richtige Binärdatei läuft.
  • Audit-Modus aktivieren, die Ereignisse aber nicht auswerten und nie in Enforcement wechseln.
  • App Control wegen eines einzelnen Fehlers global abschalten statt die betroffene Regel kontrolliert zu korrigieren.
  • Einen unbekannten Agenten automatisch deinstallieren und dadurch Zeitlinie oder andere Incident-Spuren verlieren.
  • Prozess- und Netzwerkdaten in offene Tickets kopieren und unnötig interne Details offenlegen.
  • Ausnahmen ohne exakten Scope, kompensierende Kontrollen und Ablaufdatum genehmigen.
  • Nur Clients betrachten und Managementserver, VDI, Terminalserver, Labore oder übernommene Tochterumgebungen auslassen.
  • Erfolg an der Anzahl blockierter Hashes messen statt an Coverage, Tier-0-Trennung und verbleibenden Ausnahmen.

Projekt-Checkliste

  • [ ] Benutzerclients, Server, Managementsysteme und Tier 0 als getrennte Kontrollzonen definiert.
  • [ ] Für jede Zone zulässige Fernadministrationswege und Funktionen dokumentiert.
  • [ ] Service Owner, Security Owner, Plattformadministratoren und Freigabeberechtigte benannt.
  • [ ] Genehmigte Plattform, Mandant, Agentenpakete, Signaturen und Deploymentpfade erfasst.
  • [ ] Installierte Software, Dienste, Treiber, Aufgaben und Autostarts aus zentralen Quellen inventarisiert.
  • [ ] Portable Prozesse und externe Verbindungen über ausreichend lange EDR-Telemetrie geprüft.
  • [ ] Browser-Erweiterungen, Identity-Provider-Anwendungen, OAuth-Zustimmungen und API-Tokens einbezogen.
  • [ ] CMDB-, Einkaufs-, Lizenz- und Dienstleisterdaten mit technischen Funden abgeglichen.
  • [ ] Tier-0-Systeme aus allgemeinen RMM-Zielgruppen und Deploymentregeln ausgeschlossen.
  • [ ] Eigenen, gehärteten Adminpfad für erforderliche Tier-0-Fernwartung definiert.
  • [ ] Persönliche Technikeridentitäten und phishing-resistente MFA erzwungen.
  • [ ] Rollen, Zielgruppen, Just-in-Time-Rechte und regelmäßige Access Reviews umgesetzt.
  • [ ] Gemeinsame Konten, dauerhafte Domain-Admin-Nutzung und ungeschützte API-Schlüssel entfernt.
  • [ ] Riskante Funktionen wie Dateiübertragung, Shell und Skriptausführung rollenbezogen begrenzt.
  • [ ] Patch- und Advisory-Fristen für Konsole, Gateways, Agenten und Integrationen festgelegt.
  • [ ] Re-Authentifizierung, Zielvorschau und zweite Freigabe für risikoreiche Massenaktionen umgesetzt.
  • [ ] Plattform-, Rollen-, Skript-, Sitzungs- und Agentenregistrierungslogs zentral angebunden.
  • [ ] App-Control-Baseline aus kontrollierten Installations- und Signaturquellen erstellt.
  • [ ] Audit-Ringe für IT, Piloten, Clients und Server mit verantwortlichen Ownern geplant.
  • [ ] Audit-Ergebnisse ausgewertet und notwendige Ausnahmen fachlich bestätigt.
  • [ ] Enforcement ringweise aktiviert und Recovery-Verfahren getestet.
  • [ ] Temporäre Defender-Indikatoren mit Owner, Scope und Ablaufdatum dokumentiert.
  • [ ] Ausgehende Netzwerkpfade nach Gerätetyp begrenzt und genehmigte Ziele dokumentiert.
  • [ ] Tenant- oder Organisationsbindung des erlaubten Agenten technisch geprüft.
  • [ ] Erkennungen für neue Dienste, unbekannte Ziele, ungewöhnliche Kindprozesse und Nutzung außerhalb der Zielgruppe aktiviert.
  • [ ] Verfahren zur kontrollierten Entfernung inklusive Nachinventur und Neustartnachweis erstellt.
  • [ ] Incident-Runbook für Klassifizierung, Beweissicherung, Isolation und Identitätsprüfung freigegeben.
  • [ ] Ausnahmeregister mit Gerät, Benutzer, Funktion, Owner, Kontrollen und festem Ablaufdatum eingerichtet.
  • [ ] Dienstleister-Offboarding für SSO, lokale Konten, Tokens, Zertifikate und Sitzungen getestet.
  • [ ] Datenschutz, Aufbewahrung und Zugriffsrechte für Sitzungs- und Aktivitätsprotokolle geklärt.
  • [ ] Kontrollierter Testfund und Wiederherstellung einer fälschlich blockierten Anwendung geübt.
  • [ ] Regelmäßige Prüfung auf neue Werkzeuge, abgelaufene Ausnahmen und RMM-Präsenz in Tier 0 terminiert.