Threat Hunting Exercise: Analyzing Linux SSH authorized

Threat Hunting Exercise: Analyzing Linux SSH authorized_keys Backdoor Dataset

This hunt uses a simulated Linux auditd dataset (linux_ssh_authkeys_backdoor_2022-05-21T220000.json) capturing T1098.004: Account Manipulation - SSH Authorized Keys, where an adversary appends their own public key to a user's ~/.ssh/authorized_keys file, establishing password-free, MFA-bypassing persistent access.

Step 1: Hypothesis Formation

Hypothesis: An authorized_keys file is modified (append or overwrite) outside of a documented key-rotation/onboarding process, and the newly added key is subsequently used for a successful SSH login from an IP address not previously associated with that user account. Indicators:

auditd: PATH/WRITE records targeting ~/.ssh/authorized_keys for a given user.
New key fingerprint absent from the organization's key-management inventory (e.g., no matching ticket in the IAM system).
sshd auth logs: successful publickey authentication shortly after the file modification, from a new source IP/ASN.
No corresponding HR/IT onboarding or key-rotation ticket for the account at that time.

Null Hypothesis: A system administrator legitimately rotated or added an SSH key as part of routine key management. Invalidate via ticket/change-management cross-check and by confirming the new key's fingerprint is not registered in the central key inventory.

Rationale: SSH key-based backdoors are quiet and durable - they don't trigger password-based brute-force alerts and often survive password resets; this hunt validates file-integrity monitoring on authorized_keys combined with login-source correlation as a detection strategy.

Step 2: Data Sources and Scope

Sources: auditd (file writes to .ssh/authorized_keys); sshd auth logs (/var/log/auth.log or secure); IAM/key-inventory system (for legitimacy cross-check).
Scope: ~2022-05-21T22:00:00-23:30:00 UTC; Host: jump01.prod (10.90.1.5); Account: deploy_svc.
SIEM Queries (Splunk/ELK):
Key file writes: index=auditd path="*/.ssh/authorized_keys" type=PATH nametype=CREATE OR nametype=NORMAL
New-key login: index=auth sshd "Accepted publickey" user="deploy_svc" | stats values(src_ip) by _time
Inventory cross-check: | lookup ssh_key_inventory fingerprint OUTPUT owner, ticket_id

Step 3: Key Findings

Parsed events (6 shown) confirm an unauthorized key was appended to deploy_svc's authorized_keys file and used for login from a new IP within minutes.

Timestamp (UTC)	Host	Account	Event	IOC/Why Suspicious?
2022-05-21 22:04:11	jump01.prod	deploy_svc	auditd WRITE: `~/.ssh/authorized_keys` (append)	Write IOC: file modified outside of any scheduled deployment window per the change calendar.
2022-05-21 22:04:11	jump01.prod	deploy_svc	New key: `ssh-rsa AAAA...9fQ2 attacker@kali`	Fingerprint IOC: key comment `attacker@kali` and fingerprint absent from the central IAM key inventory - no matching onboarding/rotation ticket.
2022-05-21 22:06:33	jump01.prod	deploy_svc	sshd: `Accepted publickey for deploy_svc from 103.224.182.51`	New-source IOC: successful login using the newly added key, from an IP never before associated with this account in 90 days of history.
2022-05-21 22:07:02	jump01.prod	deploy_svc	Shell command: `sudo -l`	Immediate privilege-enumeration command after login - reconnaissance behavior atypical of a legitimate deploy job.
-	jump01.prod	(IAM check)	N/A	Process-gap IOC: existing legitimate keys for deploy_svc are all tagged with ticket IDs in the IAM inventory; the new key has none.
2022-05-21 23:15:00	jump01.prod	deploy_svc	sshd: second login from 103.224.182.51	Return visit ~1 hour later using the same backdoor key - confirms durable, repeatable access rather than a one-off test.

Validation:

Timeline: Key write → login from new IP within 2 minutes → privilege enumeration → return visit - a coherent backdoor-establishment-and-use pattern.
False Positives: IAM inventory cross-check confirms no legitimate ticket covers this key; ruled out routine key rotation.
Correlation: Single account, single new key, single new source IP reused across two sessions - high-confidence unauthorized access.

Step 4: Recommendations & Next Steps

Immediate Response: Remove the unauthorized key from authorized_keys immediately; rotate all legitimate keys for deploy_svc as a precaution; block 103.224.182.51 at the perimeter; audit all hosts reachable via deploy_svc for further compromise given its likely broad access as a deployment account.
Detection: Sigma-style rule: title: Unauthorized SSH authorized_keys Modification → selection: path contains '.ssh/authorized_keys' AND fingerprint NOT IN (key_inventory) - pair with file-integrity monitoring (AIDE/Tripwire) baselined against the IAM key inventory.
Pro Tip: Maintain a living inventory of every legitimate authorized_keys fingerprint per account, and alert on any key appearing on a host that isn't in that inventory - this turns a historically hard-to-detect backdoor technique into a near-deterministic detection.

Hypothesis confirmed - an unauthorized SSH key was backdoored into a service account's authorized_keys file and used for repeated unauthorized access!