Developer tooling abuse is expanding credential theft risk in 2026

At a glance

What this is: This Anomali cyber watch item highlights malware and phishing activity that abuses trusted developer workflows to harvest credentials and other sensitive data.

Why it matters: It matters because developer machines often sit close to privileged access, so identity, secret, and endpoint controls must be assessed together rather than in isolation.

By the numbers:

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

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

Context

Developer tooling is increasingly part of the access layer, not just the software delivery layer. When attackers abuse extensions, sideloaded libraries, and trusted scripting paths, they are not merely dropping malware, they are positioning themselves near credentials, tokens, and browser sessions that can unlock wider enterprise access. That is why the primary problem here is not one infected endpoint, but the governance gap around developer trust boundaries.

The identity angle is direct. Developer workstations frequently hold or broker secrets for cloud consoles, source control, VPNs, and administrative tools, which makes them a high-value target for both NHI abuse and follow-on account compromise. The activity described here is typical of a broader trend: attackers are going after the environment that manages identity, not only the identity itself.

Key questions

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

A: Treat developer machines as privileged endpoints. Restrict software extensions, enforce application control, monitor DLL loading and scripting activity, and keep secrets out of local storage wherever possible. If compromise occurs, assume browser sessions, tokens, and VPN profiles may already be exposed and rotate them quickly before attackers can reuse them.

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. Stored credentials, cookies, and tokens are especially valuable because they can be replayed or used to pivot into deeper systems with little friction.

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. Those mechanisms inherit user confidence and may bypass superficial checks, so defenders need behavioural telemetry, not just binary allowlists, to detect misuse.

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.

Technical breakdown

How malicious extensions and DLL sideloading become an entry path

The initial compromise starts with software users already trust. Malicious browser or editor extensions can impersonate legitimate utilities, and DLL sideloading lets a weaponised library load alongside a real executable so the process looks normal to basic inspection. Hidden PowerShell or similar scripting then fetches the next payload without needing a visible exploit. The result is a quiet foothold inside a developer workflow, where the process chain itself becomes the delivery mechanism rather than a single obvious malware file.

Practical implication: restrict extension installation, monitor DLL loading anomalies, and review execution paths on developer endpoints.

Why credential and session theft matters more than the initial payload

Once a developer workstation is compromised, the malware can target browser-stored passwords, session cookies, VPN profiles, Wi-Fi credentials, and other artifacts that simplify reuse of trusted access. Those items are operationally important because they often bypass MFA at the point of reuse or provide enough context to impersonate a user in downstream systems. In NHI terms, the endpoint becomes a bridge between human identity, cached sessions, and machine credentials, which is exactly where governance breaks down if secrets are treated as isolated assets.

Practical implication: assume session and secret exposure after endpoint compromise and rotate high-value credentials immediately.

How stealth techniques delay detection and extend dwell time

Attackers increasingly prefer living-off-the-land methods, in-memory execution, and process masquerading because they reduce the chance of obvious alerts. If a payload avoids writing to disk, blends into signed software, and uses familiar network paths, traditional signature-based controls may miss it until exfiltration has already begun. This is especially dangerous in developer environments because benign exceptions are common, so malicious behaviour can hide inside normal operational noise. Detection therefore has to focus on behavioural signals, not just known bad hashes.

Practical implication: tune EDR and SIEM detections for abnormal script execution, process injection, and unusual outbound transfer patterns.

Threat narrative

Attacker objective: The attacker wants durable access to developer-linked credentials and sessions that can be reused for deeper enterprise intrusion and data theft.

1. Entry occurs through malicious developer tooling such as fake extensions or trusted software that loads a trojanised library.
2. Credential access follows when the payload harvests browser logins, session cookies, VPN profiles, and other sensitive artifacts from the workstation.
3. Impact is realised through exfiltration of stolen data to attacker-controlled infrastructure and the reuse of exposed access for broader compromise.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Secret theft is now a lifecycle problem, not a one-time leakage event. Malware that harvests stored credentials shows why discovery, rotation, and revocation need to be continuous rather than reactive. If secrets remain valid after compromise, the attacker can translate endpoint access into cloud access long after the original infection is gone. The decisive control is short-lived trust with fast invalidation.

Credential exposure windows are shrinking faster than most response processes. A campaign that can steal session material in minutes outpaces governance models built around periodic review. That creates a timing problem for IAM and PAM teams, because access review cannot compensate for credentials that have already been reused or replayed. This is where policy has to shift from review-only to rapid containment and automatic invalidation.

Trusted developer tooling is becoming a governance blind spot. Extensions, package managers, and scripting features are increasingly used as delivery channels because they inherit user trust and administrative latitude. That expands the attack surface beyond traditional phishing and into software workflows themselves. The practical conclusion is that software engineering environments need the same access scrutiny as privileged admin paths.

Named concept: developer trust boundary collapse. This campaign shows how the boundary between software development convenience and privileged access control breaks down when tools can load code, cache secrets, and broker sessions by default. The issue is not just malware delivery, but the assumption that trusted tools remain trustworthy after compromise. Teams should map those trust boundaries explicitly and govern them like any other identity perimeter.

From our research:

• 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.
• For teams mapping this risk to AI-assisted development, LLMjacking: How Attackers Hijack AI Using Compromised NHIs shows how exposed credentials can become an AI access problem, not just a secrets problem.

What this signals

Developer trust boundary collapse: the next wave of credential theft will keep targeting the tools engineers use to build and ship software, not only the credentials themselves. That means identity teams need to partner more closely with endpoint and engineering platform owners, because the access path now begins at the workstation and ends in cloud control planes.

The operational signal is clear: if a secret can be copied, cached, or replayed from a developer laptop, the governance model is already too weak. Continuous invalidation, vault-based distribution, and device-level scrutiny should become standard for engineering environments that touch production access.

The broader programme implication is that secrets management, workload identity, and IAM can no longer be managed as separate disciplines. Attackers are exploiting the seams between them, so teams should measure exposure windows, not just policy coverage.

For practitioners

• 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.
• Detect abnormal library loading and script execution Tune EDR and SIEM rules for DLL sideloading, hidden PowerShell activity, and unusual child processes spawned by trusted applications.
• Separate secret storage from day-to-day workstations Move high-value secrets into managed vaults with access logging and enforce short-lived access so local storage on endpoints becomes less useful to attackers.

Key takeaways

• Developer tooling abuse turns trusted engineering workflows into effective credential-harvesting channels.
• Secrets exposure remains slow to remediate, which gives attackers a practical window to reuse stolen access.
• The control gap is not only endpoint security but also rapid invalidation of sessions, tokens, and developer-held credentials.

Key terms

• Metadata Trust Boundary: A metadata trust boundary is the line between tool content that can be safely consumed and tool content that must be validated before use. For agentic systems, descriptions, examples, and schemas are security-relevant inputs because they can influence decisions and trigger actions with real-world impact.
• DLL Sideloading: A technique where a legitimate executable loads a malicious library from a location the application checks before the real system path. It works because the program’s trust is inherited by the code it loads, which makes execution control as important as file reputation.
• Credential replay: Credential replay is the reuse of stolen authentication material to impersonate a legitimate user or system. In human identity programmes, replay risk grows when passwords, OTPs, or weak recovery flows can be captured and used from a separate device or session.
• Secrets Lifecycle: Secrets lifecycle is the management of credentials from issuance through rotation, revocation, and offboarding. It matters because a secret that is technically valid can still be operationally unsafe if its owner, purpose, or downstream access paths are no longer current.

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.

👉 Anomali's full post covers the attack chain, analyst commentary, and referenced research in more detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps identity and security practitioners build the controls needed to reduce exposure windows and strengthen access governance across programmes.