Detect GlassWorm by looking for malicious code or extension activity that results in unexpected execution, persistence or network access. Review developer and endpoint telemetry for unusual package changes, script loading, child processes and outbound connections to unknown destinations. Treat unusual update, install or sync behaviour as suspicious when it leads to process activity outside the normal workflow.
How GlassWorm shows up in telemetry
GlassWorm is easiest to detect when you look for behaviour that does not fit normal extension development or package maintenance. Security teams should correlate code, host and network signals: unexpected script execution, new child processes, unusual package or extension changes, and outbound connections to destinations that are not part of the ordinary workflow.
A useful first pass is to compare what changed with what the developer was actually doing. A benign extension update usually stays inside normal build, test or publish activity. When a package suddenly starts loading extra scripts, spawning tools, or reaching out to unfamiliar infrastructure, the behaviour itself becomes the signal, even if the code still looks superficially legitimate.
Because GlassWorm was observed hiding in VS Code extensions, a practical detection baseline is extension-centred telemetry rather than only classic malware indicators. Review install, update and sync events alongside process creation, command line activity and DNS or proxy logs. When those signals line up, the case is stronger than any one event on its own. The GlassWorm campaign 2025 resource is the clearest starting point for that behavioural pattern.
What to inspect on developer endpoints and in the build chain
On endpoints, focus on the transition from normal editor activity to runtime execution. Unexpected child processes, unapproved interpreter launches, and scripts that run outside the usual project lifecycle are high-value indicators. In practice, the suspicious moment is often not the extension installation itself, but the follow-on execution that should not happen during routine editing or syncing.
On the software side, inspect package diffs, extension manifests, install hooks and post-install scripts. Malicious code often survives by blending into ordinary dependency change noise, so teams need a way to compare new artefacts against known-good baselines. If a package update introduces new loading paths, new scripts, or a new dependency chain without a matching development reason, treat it as a candidate compromise.
Network telemetry matters because it helps confirm whether the suspicious code is merely present or actively operating. Look for outbound connections to unknown destinations, rare domains, and traffic that starts immediately after an extension or package change. This is especially important when the endpoint alert is ambiguous, because network confirmation can turn a weak signal into a defendable detection case. NHIMG’s Malicious Package and Dependency Confusion Guide is useful here because the same review habits apply to package-related compromise.
How to distinguish suspicious activity from normal developer behaviour
The key is to anchor detection to workflow expectations. A developer who installs an extension, rebuilds a package, or refreshes dependencies should not usually trigger a chain of hidden execution, persistence and unexpected external communication. When those actions occur together, the question is not whether the code “looks bad”, but whether the behaviour can be explained by the approved workflow.
That distinction becomes sharper if you separate benign tooling from privilege-bearing behaviour. A legitimate editor or package manager may touch files, but it should not quietly establish persistence, launch unrelated processes, or initiate unauthorised network activity. When those things appear together, assume the activity is operational, not incidental, and investigate whether credentials, tokens, or publishing access were also exposed.
For a broader detection view, align alerts with adversary tradecraft rather than isolated indicators. The MITRE ATT&CK Enterprise Matrix helps teams map suspicious child processes, persistence behaviour and outbound connections to a repeatable investigation path instead of treating each alert as an independent oddity.
Risk and Threat Considerations
GlassWorm is risky because extension and package ecosystems can turn a single compromised artefact into repeated execution across many developer systems. The dangerous part is not only initial infection, but the chance that the malicious code persists long enough to steal tokens, modify packages, or reach other internal systems through trusted developer workflows.
Failure mechanism: Malicious extension or package code blends into normal update activity, then uses script loading, child processes and outbound connections to establish execution or persistence before defenders notice.
Impact: Security teams can miss the compromise until developer tokens, source repositories or downstream systems have already been touched, which expands blast radius and makes containment slower.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1055 — Process Injection | Maps to suspicious child-process and execution behaviour seen in compromise. |
| T1105 — Ingress Tool Transfer | Outbound connections to unknown destinations can indicate staged retrieval or beaconing. | |
| Recommendation — Map suspicious execution chains to ATT&CK and hunt for post-install or spawned-process activity. Inspect outbound traffic for staged retrieval or beaconing from compromised extensions. | ||
| NIST CSF 2.0 | DE.CM-01 — Monitoring for Anomalies and Events | Directly supports detection of unusual endpoint, package and network behaviour. |
| Recommendation — Tune anomaly monitoring to flag extension, process and network deviations from baseline. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Detection depends on host, build and network logs that preserve the suspicious sequence. |
| Recommendation — Centralise endpoint, build and proxy logs so suspicious extension activity is retained and searchable. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | GlassWorm-related extension compromise can expose developer tokens and credentials. |
| Recommendation — Alert on extension behaviour that may expose tokens, credentials or other secret material. | ||
Practitioner Guidance
What to prioritise: Start with developer endpoints that show both extension changes and unusual process activity, then correlate those hosts with unusual outbound traffic. That combination is more actionable than scanning for extension names alone.
What to verify: Confirm whether the observed process tree, script execution and network destinations match the user’s normal workflow. If the behaviour cannot be explained by an approved build, publish or sync action, treat it as suspicious even before code review is complete.
Practitioner takeaway: GlassWorm detection works best when teams investigate behaviour chains, not single alerts, because the compromise usually becomes visible only when code change, execution and network activity are correlated together.