Fernzugriffsschutz

Fernzugriffsbasierte Betrugsangriffe gehoeren zu den gefaehrlichsten Angriffsarten, da sie Angreifern vollstaendige Kontrolle ueber das Geraet des Opfers geben. Superheld soll den Einsatz von Fernzugriffs-Software im Kontext von Betrug ueber die Bedrohungskategorie remote_control erkennen und unterbinden.

Achtung

Diese Seite beschreibt die Zielarchitektur fuer den Fernzugriffsschutz. Im aktuellen Workspace ist keiner der hier beschriebenen Erkennungsmechanismen (Installationsueberwachung, Prozessueberwachung, Anruferkennung, automatische Blockierung) als Runtime implementiert oder verifiziert. Der einzige prototypierte Erkennungspfad ist die App-Install-Erkennung ueber app.install.observed-Signale.

---

Übersicht

Fernzugriffs-Betrug folgt einem typischen Muster: Angreifer überzeugen ihre Opfer — häufig per Telefon — eine Fernwartungssoftware wie AnyDesk, TeamViewer oder QuickSupport zu installieren. Sobald die Verbindung steht, übernehmen sie die Kontrolle über das Gerät und können:

• Banking-Apps öffnen und Überweisungen auslösen
• Zugangsdaten auslesen oder ändern
• Malware installieren, die auch nach Beendigung der Sitzung aktiv bleibt
• Persönliche Daten exfiltrieren (Fotos, Kontakte, Dokumente)
• Sicherheitseinstellungen deaktivieren (z. B. Bildschirmsperre, Zwei-Faktor-Authentifizierung)

Superheld adressiert diese Bedrohung mit einer mehrschichtigen Erkennung, die Installationen, Prozesse und den situativen Kontext korreliert.

---

Erkannte Fernzugriffs-Software

Die folgende Tabelle listet die überwachten Fernzugriffs-Tools und ihre Erkennungsmethoden:

Current workspace note: Die folgende Liste ist als öffentliches Zielbild zu lesen. Nicht jede Package- oder Bundle-ID ist im aktuellen Workspace als kanonischer Laufzeitvertrag bestätigt.

App	Package ID (Android)	Bundle ID (iOS)	Erkennungsmethode
AnyDesk	com.anydesk.anydeskandroid	com.anydesk.AnyDesk	Installationsüberwachung, Prozessüberwachung
TeamViewer	com.teamviewer.teamviewer.market.mobile	com.teamviewer.TeamViewer	Installationsüberwachung, Prozessüberwachung
QuickSupport	com.teamviewer.quicksupport.market	com.teamviewer.QuickSupport	Installationsüberwachung, Prozessüberwachung
Chrome Remote Desktop	com.google.chromeremotedesktop	Nicht als kanonischer Workspace-Wert bestätigt	Installationsüberwachung, Prozessüberwachung
Microsoft Remote Desktop	com.microsoft.rdc.androidx	com.microsoft.rdc.macos	Installationsüberwachung, Prozessüberwachung
Zoho Assist	com.zoho.assist.agent	Nicht als kanonischer Workspace-Wert bestätigt	Installationsüberwachung, Prozessüberwachung
Weitere Screen-Sharing-Apps	Produktziel, nicht als vollständige Workspace-Liste bestätigt	Produktziel, nicht als vollständige Workspace-Liste bestätigt	Installationsüberwachung, Accessibility-Service-Erkennung

Current workspace note: Weitere Fernzugriffs-Tools werden als laufender Erweiterungsbereich behandelt und hier nicht als abgeschlossene öffentliche Vollständigkeitsliste dargestellt.

---

Erkennungsmechanismen

Superheld setzt drei Erkennungsschichten ein, die zusammen eine zuverlässige Erkennung von Fernzugriffs-Betrug ermöglichen.

a) Installationserkennung

Der Device Agent überwacht App-Installationen in Echtzeit. Wird eine bekannte Fernzugriffs-App installiert, erzeugt der Agent ein Signal vom Typ remote_control.install.

Entscheidend ist die Kontextzuordnung: Findet die Installation während eines aktiven Telefonats statt, eskaliert der Risk Score drastisch — dieses Muster ist ein starkes Indiz für einen laufenden Betrugsangriff.

Signal: remote_control.install
  app: "AnyDesk"
  package_id: "com.anydesk.anydeskandroid"
  call_active: true
  risk_score: 0.95

b) Prozessüberwachung

Auf Plattformen, die dies unterstützen, erkennt der Agent nicht nur die Installation, sondern auch die aktive Nutzung von Fernzugriffs-Software:

• Android: Über den Accessibility Service werden aktive Fernzugriffs-Sitzungen erkannt
• Windows / macOS / Linux: Prozessüberwachung erkennt laufende Fernzugriffs-Prozesse und aktive Netzwerkverbindungen

Current workspace note: Die genauen Erkennungsmethoden je Plattform variieren und sind im aktuellen Workspace nicht als vollständiger plattformspezifischer Detailvertrag bestätigt.

Wenn eine aktive Remote-Session erkannt wird, erzeugt der Agent ein Signal vom Typ remote_control.session_active.

c) Kontextkorrelation

Die Context Risk Engine korreliert Fernzugriffs-Signale mit anderen Signalen, um die tatsächliche Bedrohungslage präzise einzuschätzen:

Signalkombination	Risikobewertung	Begründung
Aktiver Anruf + Fernzugriffs-Installation	Kritisch	Klassisches Tech-Support-Betrugsmuster
Aktive Remote-Session + Banking-App geöffnet	Kritisch	Direkter Zugriff auf Finanzdaten
Aktive Remote-Session + Änderung von Sicherheitseinstellungen	Hoch	Angreifer versucht, Schutzmaßnahmen zu deaktivieren
Fernzugriffs-Installation ohne aktiven Anruf	Mittel	Möglicherweise legitimite Nutzung (IT-Support)
Autorisiertes Tool (Whitelist) aktiv	Niedrig	Als IT-Support-Tool freigegeben

---

Erkennungsablauf

Das folgende Diagramm zeigt den Erkennungsablauf bei Installation einer Fernzugriffs-App:

---

Policy-Konfiguration

Administratoren und Familien-Manager können den Fernzugriffsschutz an ihre Bedürfnisse anpassen.

Standardverhalten

Einstellung	Standardwert	Beschreibung
remote_access.block_during_call	true	Fernzugriffs-Installationen während aktiver Anrufe blockieren
remote_access.warn_on_install	true	Bei jeder Fernzugriffs-Installation warnen
remote_access.authorized_tools	[]	Liste autorisierter Fernzugriffs-Tools (z. B. für IT-Support)
remote_access.block_session_with_banking	true	Remote-Sessions bei geöffneter Banking-App blockieren

Autorisierte Tools

Für Szenarien mit legitimem IT-Support können bestimmte Fernzugriffs-Tools auf eine Whitelist gesetzt werden:

{
  "remote_access": {
    "authorized_tools": [
      {
        "package_id": "com.teamviewer.teamviewer.market.mobile",
        "name": "TeamViewer",
        "reason": "IT-Abteilung Firma"
      }
    ]
  }
}

Autorisierte Tools erzeugen weiterhin Signale, werden aber mit niedrigem Risiko bewertet und nicht blockiert.

Standard-Policies je Profil

Profil	Blockierung bei Anruf	Warnung bei Installation	Session + Banking blockieren
Standard (Erwachsene)	Ja	Ja	Ja
Kinder	Ja	Ja	Ja
Senioren	Ja (verschärft)	Ja (verschärft)	Ja
IT-versiert	Warnung statt Blockierung	Ja	Ja

Current workspace note: Die Tabelle beschreibt öffentliche Standardannahmen, nicht bereits extern zugesicherte, unveränderliche Policy-Vorgaben.

---

Beispiel: Tech-Support-Betrug

Das folgende Szenario zeigt einen typischen Tech-Support-Betrugsablauf und Superhelds Eingreifen in jeder Phase.

Szenario

Ein Angreifer ruft an und gibt sich als Microsoft-Mitarbeiter aus. Er behauptet, der Computer des Opfers sei mit einem Virus infiziert, und fordert zur Installation von AnyDesk auf.

Chronologie

1. Anruf eingehend — Superheld erfasst den eingehenden Anruf und beginnt die Rufnummernanalyse
2. App-Installation — Während des Anrufs wird AnyDesk installiert; der Agent erkennt das Muster
3. Risikobewertung — Die Kombination aus aktivem Anruf und Fernzugriffs-Installation ergibt einen kritischen Risk Score
4. Nutzerwarnung — Das Opfer wird unmittelbar über das Betrugsmuster informiert
5. Familienalarm — Vertrauenspersonen erhalten einen Echtzeit-Alert
6. Blockierung — Gemäß Policy wird die Fernzugriffs-App blockiert

---

Plattformunterschiede

Die Erkennungsfähigkeiten variieren je nach Plattform aufgrund unterschiedlicher Betriebssystem-APIs:

Achtung

Die Plattformmatrix beschreibt die Zielarchitektur. Keine dieser Faehigkeiten ist im aktuellen Workspace als Runtime verifiziert. Auf Android existiert lediglich ein Prototyp fuer die App-Install-Erkennung, aber keine Prozessueberwachung, keine Anruferkennung und keine automatische Blockierung.

Faehigkeit	Android	iOS	Windows	macOS	Linux	Aktueller Stand
Installationsueberwachung	Ziel (PackageManager)	Ziel (URL-Schemes)	Ziel (Installer-Hooks)	Ziel (Installer-Hooks)	Ziel (Package-Manager-Hooks)	Nur App-Install-Stub
Prozessueberwachung	Ziel (Accessibility Service)	Ziel	Ziel (Prozessliste)	Ziel (Prozessliste)	Ziel (Prozessliste)	Nicht implementiert
Erkennung aktiver Sessions	Ziel (Accessibility Service)	Ziel	Ziel (Netzwerk-Monitoring)	Ziel (Netzwerk-Monitoring)	Ziel (Netzwerk-Monitoring)	Nicht implementiert
Anruferkennung	Ziel (PhoneStateListener)	Ziel (CallKit)	—	—	—	Nicht implementiert
Automatische Blockierung	Ziel	Ziel (MDM)	Ziel	Ziel	Ziel	Nicht implementiert
Kontextkorrelation	Ziel	Ziel	Ziel	Ziel	Ziel	Nicht implementiert

Plattformspezifische Hinweise

• Android bietet die umfassendsten Erkennungsmöglichkeiten durch den Accessibility Service, der sowohl Installationen als auch aktive Fernzugriffs-Sitzungen erkennen kann
• iOS ist aufgrund der Sandbox-Architektur eingeschränkt — Installationserkennung ist nur über URL-Schemes und MDM möglich, Anruferkennung nur über CallKit
• Windows / macOS / Linux ermöglichen Prozessüberwachung und Netzwerk-Monitoring, die genaue Erkennungstiefe variiert jedoch je nach Betriebssystemversion und Berechtigungen

Current workspace note: Desktop-Plattform-Erkennungsfähigkeiten bleiben ein laufender Dokumentations- und Implementierungsblock und werden hier bewusst nur auf hoher Ebene beschrieben.

---

Weiterführende Informationen

• Bedrohungsmodell — Vollständiges Bedrohungsmodell mit allen Angreiferkategorien
• Erkennungspipeline — Technische Details zur Signalverarbeitung
• Context Risk Engine — Funktionsweise der Kontextkorrelation
• Manipulationsschutz — Schutz vor psychologischer Manipulation
• Konfiguration — Vollständige Policy-Referenz
• Plattformfähigkeiten — Detaillierter Plattformvergleich