Look for unexpected changes to ~/.ssh/authorized_keys, especially when the parent process is node or another non-shell application. Also check for outbound connections to unfamiliar domains and file access patterns that focus on credential files, SDK source files, or home-directory sweeps. Those signals together indicate the host may have moved from theft to persistent access.
Persistence on a developer workstation usually shows up as access reuse, not just malware.
When an attacker turns a developer laptop into a foothold, the clearest warning signs are often changes that let them come back quietly. That includes new SSH keys, altered startup or login behaviour, and unusual outbound connections that happen after the original theft phase. On developer systems, persistence often blends into normal tooling, so the important question is whether the workstation is now acting like an access broker rather than an interactive user endpoint.
One reason this matters is that developer workstation already have the kind of trust attackers want: code, credentials, cloud CLIs, signing tools, browsers with sessions, and access to internal services. A host that begins reaching out to unfamiliar domains or touching credential material and SDK paths may be preparing for continued access, not just one-off theft. That is why persistence review has to focus on both artefacts and behaviour.
If the workstation is already being used to stage follow-on access, the attacker may also try to keep the original entry quiet by living inside routine developer activity. A key indicator is when a non-shell process is modifying access files or when file access patterns broaden from normal project work into home-directory sweeps. Those patterns are often more useful than a single suspicious file, because they show the workstation is being used as a platform for retention.
What makes developer persistence harder to spot?
Developer endpoints generate a lot of noise: package managers, build tools, source control clients, containers, and local services all create legitimate background activity. That makes persistence easier to hide in process trees and filesystem churn. A malicious actor can ride along with sanctioned tools, reuse existing sessions, or place access material where it looks like normal automation rather than an intrusion artefact.
Persistent access is especially likely when the attacker can operate through identity-bearing material already present on the machine. Saved credentials, SSH material, cloud tokens, browser sessions, and source repositories often provide both reach and cover. If those materials are touched together, for example a sweep through home-directory secrets followed by outbound traffic, the workstation may be being prepared for repeated access instead of a single exfiltration event.
The practical test is whether the behaviour changes the host's role. A clean workstation mainly supports development work. A compromised one starts to support access maintenance, credential harvesting, and controlled callbacks. That change in role is what should drive escalation.
Which signals should be treated as the strongest persistence indicators?
Start with any unexpected change that grants re-entry, especially developer workstation token abuse patterns and unauthorized SSH key placement. Then look for process context that does not fit the action, such as a browser helper, build tool, or Node process writing to authentication material or launch paths. A process mismatch is often the difference between routine admin activity and covert persistence.
Next, correlate those changes with network and filesystem signals. Unfamiliar domains, repeated low-volume callbacks, and access to credential files, SDK source trees, or home-directory locations are especially important when they appear together. This combination suggests the host is being used to retain access and discover where more valuable secrets live. For practical investigation, pair host telemetry with identity-focused detection guidance from the Identity Threat Detection and Response (ITDR) Guide and review similar persistence and credential-abuse chains in Salt Typhoon telecom intrusions 2025.
Persistence can also be indirect. If the workstation is used to reach cloud consoles, signing systems, or developer services, then session theft or key reuse may be the actual persistence mechanism even when the local host looks only mildly abnormal. That is why you should treat unexplained outbound traffic from a developer system as a potential sign of retained access, not just generic beaconing.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1098 — Account Manipulation | SSH key changes and re-entry on a workstation map to account persistence behavior. |
| T1078 — Valid Accounts | Developer workstation persistence often relies on reused valid credentials or sessions. | |
| T1552 — Unsecured Credentials | The question centers on secret hunting and credential-file access on the workstation. | |
| Recommendation — Hunt for account changes and new access material when workstation persistence is suspected. Prioritise detection of valid-account reuse across endpoints and cloud services. Search for exposed credentials in home directories, SDK paths, and developer tooling. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Review, Analysis, and Reporting | Persistence signals come from correlated host and network telemetry requiring review. |
| IA-5 — Authenticator Management | New keys, tokens, and credential reuse are central to persistent access on dev hosts. | |
| Recommendation — Correlate process, file, and network logs to spot workstation persistence. Rotate exposed authenticators and revoke suspicious workstation credentials. | ||
Practitioner Guidance
What to verify: Confirm whether any new SSH material, startup persistence, or scheduled execution can be tied to a legitimate change ticket. If the parent process is unusual for the file being written, treat that as a stronger signal than the file change alone.
Decision rule: If the workstation has touched credentials, tokens, or signing material and also shows outbound callbacks, prioritise isolation and credential rotation before spending time on full host forensics. If only one of those is present, validate scope first, then decide whether the host is a true persistence node or just noisy developer activity.
What good looks like: A trusted developer workstation should show normal project-oriented file access, known build and shell processes, and outbound connections that map to expected services. Anything that combines access-file modification, secret hunting, and unexplained network reach should be treated as an active persistence investigation, not a routine endpoint alert.
Practitioner takeaway: On developer systems, persistence usually reveals itself by a shift from coding activity to access maintenance, so the most important judgment is whether the host is still behaving like a workstation or has become a reusable foothold.
Related resources from NHI Mgmt Group
- What signs show that a developer workstation has been used for AI agent persistence?
- What are the signs that a developer workstation or CI runner has been used to steal secrets?
- How should teams respond when CI or developer secrets are exposed?
- Why do secrets stay dangerous even when they are no longer actively used?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org