An SSH key was added: connect the change to actual access in a SOC investigation

Integration scope: Seculogik uses a source-agnostic architecture to ingest security alerts and events through its own data map. Wazuh and OpenSearch are the first integrations. Other named sources describe planned connector targets; their availability must be confirmed for each evaluation.

An alert reports a change to authorized keys on a Linux server. A planned rotation, poorly documented automation or an attempt to maintain access can produce a similar signal. To reach a defensible conclusion, the SOC needs to reconstruct the change and investigate what access the key actually enabled.

Scope: this method covers environments using OpenSSH. It is independent of the tool collecting events and does not assume that any particular connector is available in Seculogik. Check the documented behaviour against the version and configuration deployed in your environment.

1. Define exactly what changed

MITRE ATT&CK describes adding authorized SSH keys as a possible persistence mechanism. That mapping supports an investigation hypothesis; it does not make every change malicious. Source: MITRE ATT&CK, T1098.004

Our recommendation: start the case with a verifiable observation. Which host, target account and file are involved? What differs between versions? Adding a line, replacing a key and removing restrictions deserve distinct descriptions.

Preserve the observed version, any available earlier version and references to the source events under your procedures. Record collection time, file metadata and gaps in the history. Without an earlier version, write “key present at collection time” rather than asserting when it was added.

The first deliverable should let another analyst locate the change without repeating the entire search. Avoid reducing the case to a screenshot or a filename.

2. Check the authorization path actually used

OpenSSH can read multiple AuthorizedKeysFile paths, look up keys through AuthorizedKeysCommand, or trust certificates through TrustedUserCAKeys. Match conditions can alter the applicable configuration. Source: OpenSSH, server configuration

Our recommendation: identify the service instance, its configuration file, included files and target account. Have the systems team verify the effective configuration for the connection context under investigation. Reading the main configuration file alone may leave part of the scope unexplained.

Establish who manages this authorization: the systems team, configuration management or a central service. If a mechanism automatically reapplies keys, remediation must address that source. Record its owner before deciding on a local change.

Keep the current state separate from the state during the suspicious period. Where historical configuration is unavailable, carry that uncertainty into the conclusion.

3. Identify the key and examine its restrictions

The comment on an authorized keys line does not authenticate its owner. Options associated with a key can restrict its use, including its origin or the command executed. Source: OpenSSH, authorized keys format

The ssh-keygen utility displays a public key’s fingerprint using -l. Source: OpenSSH, ssh-keygen

Our recommendation: compare fingerprints using the same algorithm and reconcile them with a validated access inventory. A comment such as “backup” remains a claim to check with the service owner.

Keep the key and its options separately identifiable. A familiar fingerprint can appear on a new line with different restrictions. Ask two questions: do we recognise this key, and do we recognise this use on this account and server?

Identifying a public key does not require collecting its private key. Do not ask the owner for it or copy it into a ticket or AI assistant. If a specialist investigation encounters one, apply the procedure for handling secrets.

4. Reconstruct the origin of the change

Look for a coherent chain connecting the change request, technical execution and resulting state. Examine available deployment-tool records, server administration evidence and file-monitoring events.

For every connection you make, record:

• the observed technical identity and its role;
• the process or automation job, where the source supplies it;
• the exact target and timestamp with its time zone;
• the reported result and the difference actually observed;
• the reference authorizing the operational or business change.

A shared technical account needs further investigation to identify the person or automated job behind it. File ownership alone does not attribute a modification.

Our recommendation: seek confirmation through an appropriate channel without relying solely on the potentially compromised account. Compare that explanation with independent evidence. If a team recognises a rotation but cannot locate a corresponding request or execution record, keep that explanation as a hypothesis.

5. Investigate use, then activity

Build a second timeline for connections: target account, server, outcome, origin and fingerprint where logging provides one. Document what is actually collected and the coverage period before interpreting an empty result.

Our recommendation: correlate by host, account, time and available identifiers. The same IP address does not establish the same person; a bastion or address translation may hide several origins. If timing is the only link between a connection and the change, say so.

Continue with available post-access activity: processes, privilege changes, modified files and outbound connections. For each, identify the evidence and how strongly it links to the session under investigation. A successful connection does not establish that a particular command ran.

An unsuccessful search should conclude “no use found in the sources and period examined.” Add the visibility gaps that prevent a stronger statement and the next decision required: additional collection, escalation or justified closure.

6. Define containment with an observable result

SSH user authentication ends with a success response, after which the server starts the requested service. Our inference is that a subsequent authorization change does not, by itself, demonstrate that an established connection has ended. Source: RFC 4252, completion of authentication

Our recommendation: separate three response objectives: prevent new unauthorized connections, examine existing access and remove the cause that could reintroduce the key.

Before acting, identify the authorized responder, potential disruption to backups or deployments and a validated recovery administration path. Preserve useful evidence where urgency allows. Record exceptions when protecting the service requires acting first.

After the authorized action, verify the state on affected hosts and in the source distributing keys. Check the treatment of existing connections and activity separately. Any access test should be prepared with the responsible team within an approved scope; it does not justify obtaining a suspicious private key.

An exercise to test the case

Fictional example: an unknown key appears on a backup service account. The infrastructure team recognises a planned rotation. A subsequent connection uses the same account, but the collected logs do not contain its key fingerprint.

The case should answer five questions:

1. Are the file differences and applicable configuration established?
2. Does the fingerprint match the one the team approved?
3. Is the rotation’s execution recorded in an independent source?
4. What can be linked to the connection, and what cannot yet be attributed to this key?
5. What evidence supports closure, or which check is still missing?

Ask an analyst who did not participate to review the case. They should be able to distinguish facts, the proposed explanation and remaining limitations. A useful conclusion describes the authorized change or suspicious access, its scope and the next decision to make.

Use our free investigation resources to prepare the case. To discuss collection and response procedures, talk to us about your project.