Look for persistence artifacts, not just the stolen token. Unexpected SSH keys, startup-time authentication calls, and extension traffic to attacker infrastructure show that the account may still be reachable through another path. If those indicators remain, the compromise is not closed.
What signs show the extension still has a live path in the account?
An IDE extension compromise is still active when you see evidence that the attacker can keep using the account after the first token theft. The key question is whether the extension or its companion process still has an execution path, not whether one credential was already revoked. Persistence usually shows up as new auth material, recurring startup activity, or outbound traffic that should have stopped.
Start with the behavior that proves the account is still reachable. Unexpected SSH keys, fresh OAuth or API tokens, and authentication calls during IDE startup mean the compromise may have shifted from a stolen token to a different foothold. That distinction matters because revoking only the obvious credential leaves the live path untouched.
Look for whether the extension has an ongoing relationship with infrastructure outside your normal development tooling. Repeated beacons, update checks to unfamiliar domains, or requests that occur on launch or reload suggest the malicious code is still present and can re-establish access. If the traffic stops only after removing the extension or isolating the host, the compromise was probably persistent rather than one-time.
Which artifacts matter more than the stolen token itself?
The most useful indicators are artifacts that survive token rotation and reveal how the attacker stayed embedded. New SSH authorized keys, altered startup hooks, injected helper binaries, and extension-sourced network requests are stronger evidence than a single leaked secret because they show an alternate route back into the environment.
- Check for secrets in VS Code extensions when the compromise appears to involve embedded credentials or extension-delivered leakage.
- Use the JetBrains GitHub plugin token exposure pattern as a reminder that IDE plugins can exfiltrate developer tokens and remain relevant until the affected credential path is removed.
- Review broader attack patterns in The State of NHI & AI Agent Breach Report 2026 when you need to compare the indicator against known compromise and lateral-movement behavior.
Extension traffic is especially important when it aligns with a user action the attacker can reliably trigger, such as IDE launch, workspace load, or project open. Those moments often expose whether the malicious logic is dormant, reloaded from configuration, or actively polling for a chance to resume.
How do teams separate a closed incident from one that still has persistence?
A closed incident is one where you have removed every practical re-entry path, not just confirmed that a token was revoked. That means checking the IDE extension, the user profile, startup locations, cached auth material, and any network destinations the extension touched. If only the token was cleaned up, the incident may still be open.
Pay attention to timing. If suspicious authentication happens at process start, on extension activation, or immediately after a logout, that usually indicates the extension or a companion component is still wired into the workstation. If the behavior reappears after reboot or IDE relaunch, the compromise is persistent by definition.
Use a containment mindset, not a single-indicator mindset. Remove the extension, invalidate related secrets, inspect the host for added keys or launch hooks, and compare network flows before and after cleanup. If the suspicious behavior disappears only after host isolation or profile rebuild, treat the original compromise as active until proven otherwise.
Risk and Threat Considerations
An IDE extension compromise is risky because development tooling often has broad access to source code, cloud auth material, and internal services. If the extension can still re-authenticate or call out to attacker infrastructure, the attacker may retain a durable foothold even after the first stolen token is rotated.
Failure mechanism: The attacker persists through a secondary path such as a planted SSH key, startup-triggered auth, or extension-controlled outbound access, so revoking one credential does not sever the compromise.
Impact: Teams may incorrectly declare the incident closed, leaving source repositories, build systems, and downstream services exposed to continued misuse, data access, or lateral movement.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address 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 |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | IDE extension compromise commonly exposes or reuses tokens and keys. |
| NHI-01 — Improper Offboarding | Active compromise persists until all extension-driven access paths are removed. | |
| Recommendation — Rotate exposed secrets and remove any extension paths that can re-use them. Revoke the extension's access paths and verify no residual auth route remains. | ||
| MITRE ATT&CK | T1110 — Brute Force | Persistence checks hinge on repeated authentication and access attempts. |
| Recommendation — Correlate repeated auth attempts with process and extension activity to confirm persistence. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The question centers on whether stolen or replaced authenticators still grant access. |
| Recommendation — Inventory, rotate, and revoke compromised authenticators before declaring recovery. | ||
Practitioner Guidance
What to verify: Confirm that suspicious auth activity stops after the extension is removed, related secrets are rotated, and the IDE profile is cleaned or rebuilt. If the same activity resumes on restart, treat that as active persistence rather than residue from the initial theft.
Decision rule: If you can explain the activity only by reference to the stolen token, you probably have not found the full compromise path. If you can tie the activity to startup hooks, added keys, or extension-origin traffic, escalate to full containment and host-level investigation.
What practitioners underestimate: The first stolen token is often the easiest artifact to see, but not the one that keeps the attacker alive. The operational question is whether the environment still contains a mechanism that can recreate access without the original secret.
Practitioner takeaway: Close the incident only when the re-entry mechanism is gone, not when the initial credential is revoked.
Related resources from NHI Mgmt Group
- How do security teams know whether SharePoint compromise is still active after patching?
- How can security teams tell whether exfiltration-focused malware is still active?
- How can security teams tell whether a pipeline compromise is still dangerous after patching?
- How can security teams tell whether an extension is over-privileged?