Cybersecurity · NAS Security Attack & Defense Lab · Lab 4 — Persistence

Lab 4 — Persistence

Establishing SSH key-based persistence; detecting it via logs and file changes; and responding with containment and mitigation.

Scenario

After gaining access (Lab 2) and escalating privileges (Lab 3), the attacker establishes persistence on the NAS server. This lab demonstrates adding an SSH public key for re-entry, then shows how to detect and respond on defense.

Offensive

Generate an SSH key pair on Kali and place the public key on the target NAS. Then configure ~/.ssh/authorized_keys with proper permissions to enable key-based login.

Generating an SSH key pair on Kali with ssh-keygen — Generate SSH key pair.

Copying the public key to the target system — Transfer public key to target.

Verifying id_rsa.pub exists on the NAS in /tmp — Verify the key on the target.

Moving key from /tmp to /root — Move key to desired location.

Creating ~/.ssh, writing authorized_keys, and setting permissions — Create `~/.ssh`, write `authorized_keys`, set secure perms.

Test the persistence by reconnecting via SSH using the private key.

Successful re-login via SSH using the key (persistence test) — Re-entry confirmed with key-based auth.

Note: You may still need to repeat environment setup/escalation steps from Lab 3 to regain root in a new session, but the key ensures durable access post-reboot.

Defensive

1) Detect Key-Based Persistence

Audit ~/.ssh/authorized_keys for unexpected entries, strange comments, or keys referencing external systems (e.g., @kali).

Reviewing authorized_keys showing a suspicious key entry — Suspicious key present in `authorized_keys`.

2) Review SSH Authentication Logs

Correlate logins in /var/log/auth.log (or platform equivalent) for key-based acceptances from unfamiliar sources.

General SSH auth log review — General auth activity.

Accepted public key authentication entries — Accepted key-based auth detected.

3) Identify Recent File Modifications

Find recently modified authorized_keys files (7-day window example):

sudo find / -type f -name authorized_keys -mtime -7 2>/dev/null

Finding recently modified authorized_keys files with find — Hunting recent key additions.

4) Monitor Active Sessions

Check who is currently logged in and from where, then terminate suspicious sessions.

Using who to see active sessions (ronny from Kali IP) — `who` shows session origin.

Terminating a suspicious session — Terminate the session immediately.

Immediate Response

Kill related processes (example using kill -9 on PIDs tied to the compromised user):

Force-killing malicious processes — Force-stop rogue processes.

Mitigation

Remove Unauthorized Keys

Manually inspect and remove unknown keys from authorized_keys; restrict permissions to minimum required.

Inspecting authorized_keys file — Inspect the file contents.

Removing the suspicious key entry — Remove rogue entries.

Saved and secured authorized_keys after removal — Modified and secured.

Reset Passwords

Reset affected user passwords in case credentials were also compromised.

Resetting the user password — Password reset performed.

Conclusion

SSH key-based persistence is effective and stealthy. Even with passwords disabled (keys-only mode), an attacker who obtains write access can add a key and regain entry after reboot. If SSH isn’t required, disable the service entirely. Otherwise, harden: monitor authorized_keys, restrict which users may use SSH, consider 2FA, use IDS/IPS rules for key-file changes, and alert on anomalous logins.

Back to NAS Security Attack & Defense Lab