Join our Newsletter — 33% off our NHI Course

Notifications
Clear all

Developer tooling abuse: what it means for IAM and NHI governance


(@nhi-mgmt-group)
Member Moderator
Joined: 1 year ago
Posts: 19415
Topic starter  

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.

NHIMG editorial — based on content published by Anomali: Anomali Cyber Watch on Evelyn Stealer, PDFSider malware, and related threats

Questions worth separating out

Q: How should security teams protect developer machines that handle credentials and tokens?

A: Treat developer machines as privileged endpoints.

Q: Why do developer environments increase the risk of credential theft?

A: Developer environments often sit close to source repositories, cloud consoles, and administrative tooling, so one compromise can expose both human and non-human identities.

Q: What breaks when organisations rely on trusted software to prevent malware execution?

A: Trust alone breaks when attackers hide inside legitimate tools such as extensions, sideloaded libraries, or signed applications.

Practitioner guidance

  • Treat developer endpoints as privileged assets Apply stricter device hardening, application control, and monitoring to engineering workstations that can reach source code, cloud consoles, or secret stores.
  • Constrain extension and plugin trust Allow only approved Visual Studio Code extensions and review any workspace features that can trigger script execution, process loading, or network access.
  • Rotate exposed credentials and sessions immediately If a developer endpoint is suspected, invalidate browser sessions, rotate tokens, and review VPN and cloud access tied to the affected user or service.

What's in the full analysis

Anomali's full article covers the operational detail this post intentionally leaves for the source:

  • The specific tradecraft used by the malware, including how the fake developer tooling is delivered and executed.
  • The source article's referenced detection and attribution context, which practitioners can use to compare with their own telemetry.
  • The full analyst commentary on why developer environments are increasingly attractive for credential theft.
  • The linked research context from Trend Micro, which gives the original campaign analysis and technical evidence.

👉 Read Anomali's analysis of malware that abuses developer tooling to harvest credentials →

Developer tooling abuse: what it means for IAM and NHI governance?

Explore further

View Full Forum →  |  NHI Foundation Course →



   
Quote
(@mr-nhi)
Member Moderator
Joined: 3 months ago
Posts: 19006
 

Developer endpoints are effectively identity infrastructure. Once credentials, cookies, VPN profiles, and source-control tokens live on the same machine that builds software, the workstation becomes part of the access control plane. That means compromise is not limited to endpoint loss, because a single foothold can expose both human identity and non-human identity material. Practitioners should treat developer devices as privileged assets, not standard user laptops.

A few things that frame the scale:

  • The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
  • Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to The State of Secrets in AppSec.

A question worth separating out:

Q: Who is accountable when a developer tool leads to credential exposure?

A: Accountability sits across endpoint security, identity governance, and the engineering team that approved or installed the tool. If the exposed material includes secrets or delegated access, the issue becomes an identity incident, not just a malware event. Frameworks such as NIST Cybersecurity Framework 2.0 and OWASP Non-Human Identity Top 10 support that shared ownership model.

👉 Read our full editorial: Developer tooling abuse is expanding credential theft risk in 2026



   
ReplyQuote
Share: