TL;DR: Malicious Visual Studio Code extensions, DLL hijacking, and in-memory payloads are being used to steal credentials, cookies, VPN profiles, and wallet data from developer machines, according to Anomali citing Trend Micro research. The pattern shows why developer endpoints need privileged handling, because a single compromise can expose access paths into source repositories, cloud consoles, and production environments.
At a glance
What this is: This analysis shows how trusted developer tooling is being abused to turn a single workstation compromise into broad credential theft and downstream access risk.
Why it matters: It matters because developer endpoints often sit close to the most sensitive identity paths in the environment, so compromise can expose cloud, source control, and production access.
Context
Developer tooling can become an identity risk when trust in extensions, loaders, and script execution is abused to deliver malware. In this pattern, the endpoint is not just a workstation, it is a gateway to credentials, tokens, and session material that can be reused across cloud and engineering systems.
The governance gap is that many organisations still treat developer devices as ordinary endpoints even though they often carry elevated access paths. When an attacker can blend into software development workflows, conventional user awareness and standard endpoint controls do not fully contain the fallout.
Key questions
Q: What breaks when trusted developer tools are compromised?
A: When a developer tool is compromised, the attacker often inherits the same access the developer already has to source code, build workflows and sometimes secrets. That turns a local productivity issue into a supply chain risk. The main failure is assuming the editor or extension is harmless because it sits inside a trusted workflow.
Q: Why do stolen browser cookies and VPN profiles increase enterprise risk so quickly?
A: They can function like ready-made access tokens, letting an attacker reuse an active session or network path without starting from scratch. That matters because the compromise can jump from one endpoint to source repositories, cloud consoles, or production systems before normal credential hygiene catches up. The faster those artefacts are revoked, the smaller the blast radius.
Q: What are the signs that developer endpoint controls are too weak?
A: Warning signs include unrestricted extension installs, poor visibility into script execution, limited monitoring of DLL loading, and broad access from developer workstations into sensitive systems. If a single developer machine can expose repository, VPN, and cloud access at once, the environment is relying on trust rather than containment.
Q: How should teams separate legitimate development flexibility from security control?
A: The practical answer is to preserve developer productivity while removing blind trust from the toolchain. That means setting policy for approved extensions, narrowing session scope, logging unusual execution paths, and reducing standing access from developer devices into production resources. Flexibility remains, but it should not include unrestricted identity reuse.
Technical breakdown
How malicious extensions and sideloaded DLLs create initial access
The campaign begins by placing malicious code inside software developers already trust, such as Visual Studio Code extensions and bundled executables. Once the victim installs or opens the tool, DLL hijacking allows the attacker-controlled library to load in place of the expected one, and hidden PowerShell commands fetch the next-stage payload. This is effective because the code runs inside legitimate processes and user workflows, which reduces suspicion and complicates detection. The attack path is less about exploiting a software bug than abusing trust in the software loading chain.
Practical implication: control extension approval, monitor DLL loading, and treat developer tool execution paths as part of privileged access governance.
Why in-memory execution makes credential theft harder to catch
In-memory malware avoids writing much of its behavior to disk, which limits the usefulness of file-based scanning and post-infection cleanup alone. Once active, the payload harvests browser credentials, session cookies, VPN profiles, Wi-Fi keys, wallet data, and other system artifacts, then exfiltrates them to attacker infrastructure. The important point is that the stolen material is not just raw data. It is reusable identity material that can be replayed against repositories, consoles, and remote access services. That makes the compromise an access problem, not only a malware problem.
Practical implication: expand detection to memory, browser stores, and credential abuse signals instead of relying only on file malware alerts.
How developer machines become launch points into higher-value systems
Developer endpoints frequently hold access to source code, cloud management planes, CI/CD systems, and operational secrets. That proximity means credential theft from one workstation can become lateral access into environments that look unrelated to the original infection. The article’s core warning is that the real value of the compromise sits in the follow-on trust relationships. A stolen cookie or VPN profile may be enough to reenter a managed environment, especially if session governance and device trust are weak. This is where endpoint compromise becomes identity compromise.
Practical implication: classify developer workstations as high-value access nodes and apply tighter device, session, and token controls around them.
Threat narrative
Attacker objective: The attacker wants reusable identity material that turns a single developer endpoint compromise into broader access across engineering and production systems.
- Entry occurs through malicious Visual Studio Code extensions that masquerade as legitimate utilities and are installed by developers who trust the workflow.
- Credential access follows through DLL hijacking, hidden PowerShell execution, and in-memory payload delivery that harvest browser credentials, session cookies, VPN profiles, and other sensitive artifacts.
- Impact occurs when stolen identity material is exfiltrated and reused to pivot from the compromised workstation into source repositories, cloud consoles, and production access paths.
Breaches seen in the wild
- Nx s1ngularity attack 2025: Attackers stole Nx's npm token via a GitHub Actions flaw and shipped malware that stole 2,349 secrets and abused developers' AI CLIs.
- LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Developer tooling has become an identity attack surface, not just a software delivery surface. When adversaries can hide inside extensions, loaders, and trusted workflows, they are effectively attacking the access layer around engineering work. That shifts the governance question from malware cleanup to control over the identity-bearing tools developers use every day. Practitioner conclusion: developer environments must be governed as privileged access zones, not ordinary endpoints.
Credential theft is only the first-order effect; the real risk is access reuse. Browser cookies, VPN profiles, and stored credentials are all identity artefacts that can be replayed into higher-value systems if session controls are weak. The compromise therefore exposes source repositories, cloud consoles, and production workflows through the same trust chain. Practitioner conclusion: session governance and token scope matter as much as endpoint detection.
Trust decisions inside development tools now need explicit security policy. The article shows how attackers rely on routine approvals that look harmless in context, especially when installers, extensions, and workspace actions are treated as normal. This creates a governance blind spot where users make security decisions inside tools they believe to be low risk. Practitioner conclusion: approval flows inside developer tools need policy, logging, and review.
Developer endpoint compromise is a privilege management problem disguised as malware. The named concept here is developer trust collapse, where familiar tooling erodes the boundary between safe execution and authorised access. Once that boundary falls, existing IAM controls often inherit compromised sessions rather than preventing them. Practitioner conclusion: build controls that assume a developer workstation can become an identity relay.
OWASP-NHI is relevant here because the stolen artefacts often behave like non-human identities in practice. Session cookies, tokens, and VPN profiles can all carry machine-like access characteristics even when they originated on a human device. That makes lifecycle control, scope control, and offboarding of those artefacts part of the NHI governance conversation. Practitioner conclusion: extend NHI oversight to any credential material that can be replayed without the user present.
What this signals
Developer trust collapse: When attackers can exploit ordinary coding tools to harvest reusable credentials, the security problem becomes one of access governance rather than endpoint hygiene. Teams should expect identity artefacts to move from the workstation into cloud and source-control paths unless session scope and approval policy are tightened.
The programme implication is straightforward. Developer endpoints need stronger device posture, tighter software approval, and more aggressive control over artefacts such as cookies, VPN profiles, and browser-stored credentials. If those items can be replayed outside the original device, they should be governed like credentials, not like disposable local data.
For practitioners
- Treat developer endpoints as privileged assets Classify developer machines separately from standard user devices and apply stronger baselines for software installation, script execution, and identity exposure.
- Restrict extension and plugin trust Approve only known-good extensions and workspace add-ons, and monitor for suspicious extension install chains that imitate normal developer productivity.
- Increase visibility into DLL loading and PowerShell activity Correlate unusual DLL load paths, hidden script execution, and memory-resident payload behavior with developer user contexts and source-code access.
- Harden session and token controls Limit the usefulness of stolen cookies, VPN profiles, and browser credentials by tightening session scope, replay resistance, and revocation processes.
- Review access paths from developer devices into production Map which engineering endpoints can reach repositories, cloud consoles, and operational tools, then reduce standing access and unnecessary trust links.
Key takeaways
- Developer tooling abuse turns ordinary engineering workflows into a reliable path for credential theft and identity reuse.
- The real exposure is the follow-on access, because stolen cookies, VPN profiles, and browser credentials can unlock repositories, cloud consoles, and production systems.
- Containing this pattern requires treating developer machines as privileged assets and tightening control over extensions, execution paths, and replayable identity artefacts.
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 | The campaign steals credentials, cookies, and other reusable identity artefacts from developer systems. |
| NHI-07 — Long-Lived Secrets | Stolen browser and VPN material stays useful if sessions and secrets remain valid too long. | |
| NHI-10 — Human Use of NHI | Human workstations are the source of machine-like access material that attackers can replay. | |
| Recommendation — Scan developer environments for exposed credentials and revoke any leaked NHI artefacts immediately. Shorten token and session lifetimes so compromised developer artefacts lose value quickly. Separate human workstation access from reusable machine credentials and restrict where those artefacts can be used. | ||
| MITRE ATT&CK | TA0006;TA0008;TA0010 — Credential Access; Lateral Movement; Exfiltration | The article describes credential harvesting, pivoting from developer endpoints, and data theft. |
| Recommendation — Map the campaign to TA0006, TA0008, and TA0010 to guide detection and containment efforts. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Authenticator management applies to the stolen credentials, cookies, and session material exposed in the campaign. |
| Recommendation — Apply IA-5 to manage issuance, rotation, and revocation of developer credentials and session artefacts. | ||
Key terms
- Developer Endpoint: A developer endpoint is a laptop or workstation used to write code, run tools, and access build or cloud systems. In identity governance terms, it is also a place where live credentials can be stored, copied, or exposed, which makes the device part of the control surface rather than just a user asset.
- DLL Hijacking: DLL hijacking occurs when an application loads a dynamic library from a location an attacker can control. If a privileged process searches a writable directory first, the attacker can replace or plant a library that the process loads and executes with elevated rights.
- Session Cookie Replay: The reuse of an authenticated session cookie by someone other than the original user. In identity governance terms, it means the login succeeded legitimately, but the trust boundary moved from authentication to session possession, making post-authentication monitoring and revocation central to defence.
- Verification Artefact: A verification artefact is any record created during identity proofing, including images, scores, approval notes, or vendor returns. These artefacts are valuable for audit and fraud review, but they also create privacy and breach risk if they are retained too long or exposed broadly.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It suits practitioners who need to connect access governance, session control, and machine identity risk back to operational programmes.
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org