How can security teams tell if a developer extension is behaving like malware?

Why This Matters for Security Teams

Developer extensions are attractive to attackers because they sit inside trusted workflows, inherit broad permissions, and can blend into normal build, browser, and IDE activity. A benign extension usually performs one narrow function and talks to a small set of expected endpoints. When behaviour expands into secret harvesting, machine discovery, command relay, or covert automation, the question shifts from policy violation to possible malware.

That distinction matters because extensions often have access to source code, tokens, cloud consoles, and internal APIs all at once. The compromise path can look like legitimate productivity until the extension starts exfiltrating data or staging follow-on access. Guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls and NHIMG research on the Shai Hulud npm malware campaign both point to the same operational reality: trust in an extension must be earned continuously, not assumed from its marketplace listing.

In practice, many security teams encounter malicious extension behaviour only after secrets have already been reused or source has already been staged for theft.

How It Works in Practice

The most reliable approach is to compare declared purpose against observed behaviour. Security teams should baseline what the extension needs to do, then monitor for drift in permissions, network destinations, file access, process spawning, and automation hooks. A code formatter does not need broad environment enumeration. A theme pack does not need token access. A helper extension that starts polling remote servers or silently scripting browser actions deserves immediate scrutiny.

Useful signals usually appear in combination. Frequent polling to unfamiliar endpoints can indicate command-and-control style activity. Unexpected reuse of bearer tokens can indicate credential capture or relay. Attempts to read environment variables, clipboard data, SSH material, cloud metadata, or browser session state suggest the extension is looking beyond its stated function. Where possible, teams should pair endpoint telemetry with extension inventory and policy enforcement so that access can be removed quickly instead of manually investigated after the fact.

• Define the extension’s intended data flow and compare it to actual outbound traffic.
• Alert on access to secrets stores, browser profiles, shell history, and environment state.
• Review permission changes after updates, not only at initial installation.
• Block unsigned, unvetted, or newly published extensions in high-trust developer environments.

NHIMG analysis of the Google Firebase misconfiguration breach underscores how quickly a small trust gap can expose sensitive data once access is broader than intended. CIS guidance in CIS Controls v8 reinforces the same control theme: inventory, monitor, and restrict software behavior that can touch sensitive assets. These controls tend to break down in highly permissive developer workstations because local admin rights, unmanaged plugins, and long-lived tokens make malicious behaviour difficult to distinguish from normal automation.

Common Variations and Edge Cases

Tighter extension control often increases developer friction, requiring organisations to balance productivity against exposure reduction. That tradeoff is especially visible in teams that rely on internal plugins, fast-moving marketplaces, or custom IDE extensions with legitimate automation features.

Current guidance suggests treating extensions in three risk bands. First, low-risk utilities with no network access can often be allowlisted with simple telemetry. Second, extensions that access repositories, secrets, or cloud consoles should be subject to explicit approval, short review cycles, and permission revalidation after each update. Third, extensions that can execute code, control the browser, or call remote commands should be managed like privileged software rather than productivity tools.

There is no universal standard for this yet, but best practice is evolving toward runtime policy, strict software provenance, and continuous behavioural monitoring. That becomes more important when a malicious extension hides inside a trusted package update, uses legitimate domains for staging, or waits to activate only after a developer signs in. In those cases, static review is not enough because the payload is designed to look harmless until it has already inherited trust.

Security teams should also remember that a suspicious extension is not always malware. Some enterprise tools legitimately inspect environment state or automate browser flows, so the decision should rest on least privilege, documented purpose, and repeatable evidence, not on a single indicator.

Related resources from NHI Mgmt Group

• Why are NHIs a critical concern for security teams?
• What steps should security teams take to prevent Shadow AI risks?
• Why is the abuse of NHIs a priority for security teams?
• How should teams respond when CI or developer secrets are exposed?