SSH authorized_keys erkennen: dauerhafter SSH-Zugang als Linux-Persistenz

SSH authorized_keys erkennen heißt, die eine Datei zu überwachen, die einem Angreifer dauerhaften Zugang schenkt. Nach dem ersten Zugriff über eine Unix-Shell ist ein eigener SSH-Schlüssel die saubere, leise Lösung für den Wiedereinstieg: kein Passwort nötig, kein auffälliger Dienst, und die Anmeldung sieht aus wie jede andere Schlüssel-Anmeldung. Weil ein Schlüssel einen Passwortwechsel überlebt, ist diese Persistenz besonders hartnäckig. Dieser Beitrag aus der Serie "Angriff erkennen" zeigt aus Verteidigersicht, wo sie Spuren hinterlässt, mit Logquellen, drei Sigma-Regeln, der Härtung, einer Checkliste und dem Test. Die Telemetrie-Grundlagen stehen unter Linux-Sicherheitsmonitoring.

Was der Angreifer tut

Die Varianten sind wenige und drehen sich alle um den öffentlichen Schlüssel. Bewusst auf der Ebene des Prinzips, nicht als Anleitung:

• Eigenen Schlüssel eintragen. Der Angreifer hängt seinen öffentlichen Schlüssel an die authorized_keys-Datei eines Kontos an, oft an die von root oder einem Dienstkonto. Danach meldet er sich jederzeit per SSH an, ohne Passwort.
• Schlüsselsuche umbiegen. Statt die Standarddatei zu ändern, verstellt er in der sshd-Konfiguration AuthorizedKeysFile oder AuthorizedKeysCommand so, dass der Server Schlüssel aus einem von ihm kontrollierten Ort liest - unauffälliger, weil die übliche authorized_keys-Datei unverändert bleibt.
• Dienstkonten bevorzugen. Konten wie git, jenkins oder deploy haben oft einen SSH-Zugang und werden selten kontrolliert. Ein Schlüssel dort fällt kaum auf.
• Dauerhaft bleiben. Der Schlüssel überlebt Passwortwechsel und oft auch eine oberflächliche Bereinigung. Erst wer authorized_keys aktiv prüft, findet ihn.

Der gemeinsame Nenner ist die Änderung an einer authorized_keys-Datei oder an der sshd-Konfiguration und, kurz darauf, eine Schlüssel-Anmeldung mit einem neuen Fingerprint. Genau daran setzen die Regeln an.

Welche Logquellen die Technik zeigt

• auditd (die wichtigste Quelle). Ein Datei-Watch auf die Schlüsseldateien, etwa -w /root/.ssh/ -p wa -k sshkeys und entsprechende Watches auf die Home-Verzeichnisse, macht jede Änderung sichtbar. Der PATH-Datensatz nennt die authorized_keys-Datei, der SYSCALL-Datensatz das schreibende Programm und Konto.
• Sysmon for Linux. Event 11 (FileCreate) zeigt das Anlegen und Ändern von authorized_keys mit dem erzeugenden Prozess.
• sshd in journald. Jede Schlüssel-Anmeldung protokolliert sshd als Accepted publickey for <user> from <ip> ... SHA256:<fingerprint>. Ein Fingerprint, der nicht in der Baseline der bekannten Schlüssel steht, ist das stärkste Einzelsignal.
• Prozess-Telemetrie. Das Eintragen per Shell (echo, tee, cp) erscheint in auditd (execve) und Sysmon for Linux Event 1 mit der vollständigen Kommandozeile - wertvoll, wenn der Dateiwatch den Pfad nicht erfasst.

Das Muster im Log

Eine authorized_keys-Datei ändert sich im Normalbetrieb selten und fast immer durch Provisionierung. Verdächtig ist eine Änderung außerhalb dieser Fenster, besonders wenn sie von einem Dienstkonto, einem Webprozess oder einer Shell ausgeht statt vom Konfigurationsmanagement. Das zweite, unabhängige Signal ist die Anmeldung selbst: ein neuer Fingerprint in Accepted publickey, eine Quell-IP, von der sich dieses Konto sonst nie anmeldet, oder eine Anmeldung an einem Dienstkonto, das eigentlich nie interaktiv genutzt wird. Am belastbarsten wird der Fall, wenn beide Spuren zusammenkommen: erst der Schreibzugriff auf authorized_keys, dann kurz darauf die erste Anmeldung mit dem neuen Schlüssel.

Drei Sigma-Regeln

Die Regeln sind mit sigma-cli validiert und nutzen die Linux-Logquellen file_event und process_creation. Die erste fängt die Änderung an authorized_keys, die zweite die umgebogene sshd-Konfiguration, die dritte den Schreibzugriff per Kommandozeile. Die Übersetzung ins SIEM steht unter Sigma-Regeln.

1. Änderung an authorized_keys (T1098.004). Die Datei ändert sich selten - jede Schreiboperation ist ein Prüffall.

title: Aenderung an einer SSH-authorized_keys-Datei
id: 16555593-cd9e-49c0-b5af-689fcc856e40
status: experimental
description: Erkennt das Anlegen oder Aendern einer authorized_keys-Datei. Angreifer
  tragen dort ihren eigenen oeffentlichen Schluessel ein und erhalten so passwortlosen,
  dauerhaften SSH-Zugang zu einem Konto (Persistenz per SSH Authorized Keys). Die
  Datei aendert sich im Normalbetrieb selten.
references:
  - https://attack.mitre.org/techniques/T1098/004/
author: blue-team.net
tags:
  - attack.persistence
  - attack.t1098.004
logsource:
  product: linux
  category: file_event
detection:
  selection:
    TargetFilename|contains: 'authorized_keys'
  condition: selection
falsepositives:
  - Provisionierung und Konfigurationsmanagement (Ansible, cloud-init), die Schluessel legitim ausrollen
level: high

2. Änderung an der sshd-Konfiguration (T1098.004). Ein geändertes AuthorizedKeysFile oder AuthorizedKeysCommand biegt die Schlüsselsuche um.

title: Aenderung an der SSH-Server-Konfiguration
id: 4ce74d22-237d-4cab-8abb-c0f4003ca76b
status: experimental
description: Erkennt Aenderungen an der sshd-Konfiguration. Angreifer biegen ueber
  AuthorizedKeysFile oder AuthorizedKeysCommand die Schluesselsuche auf einen von
  ihnen kontrollierten Ort um und verankern so SSH-Persistenz abseits der ueblichen
  authorized_keys-Datei.
references:
  - https://attack.mitre.org/techniques/T1098/004/
author: blue-team.net
tags:
  - attack.persistence
  - attack.t1098.004
logsource:
  product: linux
  category: file_event
detection:
  selection:
    TargetFilename|contains:
      - '/etc/ssh/sshd_config'
  condition: selection
falsepositives:
  - Administrative Pflege der SSH-Konfiguration und Paketupdates - bekannte Wartungsfenster abgleichen
level: medium

3. Schreibzugriff auf authorized_keys per Kommandozeile (T1098.004). Das klassische Anhängen per echo oder tee greift auch ohne Dateiwatch.

title: Schreibzugriff auf authorized_keys ueber die Kommandozeile
id: 361b6c8b-c550-499e-ae6d-294b8c9192d8
status: experimental
description: Erkennt das Schreiben in eine authorized_keys-Datei ueber die
  Kommandozeile, etwa per echo, tee, cp oder curl. Das ist die haeufigste Art, einen
  Angreifer-Schluessel nach einem Shell-Zugriff einzutragen, und greift auch dann,
  wenn kein Dateiwatch auf dem Zielpfad liegt.
references:
  - https://attack.mitre.org/techniques/T1098/004/
author: blue-team.net
tags:
  - attack.persistence
  - attack.t1098.004
logsource:
  product: linux
  category: process_creation
detection:
  selection:
    CommandLine|contains: 'authorized_keys'
  filter_read:
    CommandLine|contains:
      - 'cat '
      - 'grep '
      - 'ls '
  condition: selection and not filter_read
falsepositives:
  - Provisionierungsskripte, die Schluessel per Kommandozeile ausrollen - nach Konto und Host ausnehmen
level: high

Härtung

• Schlüssel zentral verwalten. authorized_keys per Konfigurationsmanagement ausrollen und schreibgeschützt halten, sodass eine lokale Änderung sofort auffällt oder beim nächsten Lauf zurückgesetzt wird.
• Schlüsselsuche festnageln. AuthorizedKeysFile auf einen zentral verwalteten, nur von root beschreibbaren Pfad setzen, damit ein Schlüssel im Home-Verzeichnis eines Nutzers gar nicht erst gilt.
• SSH-Zertifikate statt statischer Schlüssel. Eine SSH-CA mit kurzlebigen Zertifikaten erzwingt Rotation und macht einen dauerhaft hinterlegten Angreifer-Schlüssel wirkungslos.
• Dateiintegrität überwachen. Ein FIM-Werkzeug wie AIDE auf allen authorized_keys-Dateien und auf /etc/ssh/sshd_config meldet jede unerwartete Änderung.

Der Test

Die Erkennung lässt sich im Lab gefahrlos prüfen, auf einer isolierten VM mit auditd-Dateiwatches, Sysmon for Linux und laufendem sshd:

• Für Regel 1 und 3 einen Testschlüssel per echo "ssh-ed25519 ..." >> ~/.ssh/authorized_keys anhängen. Der auditd-PATH-Datensatz, Sysmon for Linux Event 11 und die Kommandozeilen-Regel müssen greifen.
• Mit dem neuen Schlüssel eine SSH-Anmeldung durchführen und in journald den Accepted publickey-Eintrag mit dem neuen Fingerprint prüfen.
• Für Regel 2 AuthorizedKeysFile in /etc/ssh/sshd_config testweise ändern und den Treffer prüfen, danach zurücksetzen.
• Breiter wird der Test mit den Fällen zu T1098.004 aus Atomic Red Team.

Fehlalarme und Tuning

• Provisionierung. Ansible (authorized_key-Modul), cloud-init und Terraform rollen Schlüssel legitim aus. Deren Konten, Prozesse und Zeitfenster gehören als Baseline hinterlegt.
• Schlüsselrotation. Geplante Rotationen ändern authorized_keys regelmäßig. Sie sind nachvollziehbar und sollten mit dem Rotationsprozess abgeglichen werden.
• Entwicklerkonten. Auf Entwicklungssystemen tragen Nutzer häufiger eigene Schlüssel ein. Dort hilft eine Baseline pro Host statt einer pauschalen Ausnahme.
• Kontext entscheidet. Eine Änderung an root/.ssh oder an einem Dienstkonto wiegt schwerer als an einem interaktiven Nutzerkonto, und ein Schreibzugriff aus einem Webprozess ist fast immer bösartig.

Analysten-Checkliste

• Welche authorized_keys-Datei und welches Konto ist betroffen (root, Dienstkonto, Nutzer)?
• Neuer Schlüssel: Fingerprint, Typ und Kommentarfeld prüfen - passt er zu einem bekannten Schlüssel?
• Wer hat geschrieben (erzeugender Prozess, Konto)? Provisionierung oder Shell/Webprozess?
• Wurde die sshd-Konfiguration (AuthorizedKeysFile, AuthorizedKeysCommand) verändert?
• Gab es danach eine Anmeldung mit dem neuen Fingerprint? Quell-IP und Zeitpunkt bewerten.
• Weitere Persistenz im selben Zeitfenster: neue Cron-Einträge, Units oder Konten?

Fazit

Ein fremder SSH-Schlüssel ist eine der leisesten und hartnäckigsten Linux-Persistenzen: eine Zeile in einer Datei, und der Angreifer kommt ohne Passwort wieder herein. Das Gute daran ist, dass es wenige, gut bekannte Stellen sind. Wer authorized_keys und die sshd-Konfiguration mit auditd und Sysmon for Linux überwacht, neue Schlüssel-Fingerprints gegen eine Baseline prüft und Schlüssel zentral verwaltet, findet den Schlüssel, bevor er benutzt wird. Dieselben Schlüssel dienen danach oft der seitlichen Bewegung per SSH; eine weitere dauerhafte Verankerung steht unter Cron- und systemd-Persistenz. Weitere Techniken dieser Taktik führt das Lexikon nach Taktik unter Persistence.