Beyond Detection: Blocking Malicious NPM Network Calls with Garnet

Supply chain attacks are a persistent threat, with malicious code hidden in dependencies compromising systems at any stage of the software lifecycle. The recent ngsma-commons NPM package (v1.0.2) exemplifies this, attempting data exfiltration via Out-of-Band Application Security Testing (OAST) domains. This incident highlights a critical security gap: the difference between merely detecting suspicious activity and actively blocking it before damage occurs, both during build processes and in production environments.

This post shows how Garnet automatically identified and blocked these malicious outbound network calls across the software lifecycle, explains the attack technique, and contrasts this proactive approach with common detection-only runtime security tools that can significantly impact production performance.

The Hidden Danger: ngsma-commons and OAST Abuse

The ngsma-commons v1.0.2 package executed a malicious postinstall script immediately after installation (npm install). This script used common tools (curl, wget, node -e) to exfiltrate user, host, and directory information to a suspicious .oast.fun domain.

OAST domains (like .oast.fun, .oast.live, .burpcollaborator.net) are normally used by security testers to confirm vulnerabilities like SSRF out-of-band. Attackers co-opt this:

1. Confirm Compromise: An OAST hit signals successful installation.
2. Exfiltrate Data: Small bits of data (user, host, env vars) are sent in the request.
3. Establish C2 Beacons: A simple check-in for further command and control.

The package also had a secondary payload in index.js attempting similar data exfiltration (plus file listings) if require'd at runtime.

Any unsolicited outbound connection from your build pipeline or application runtime to an OAST domain is a major red flag, signaling potential compromise or data leakage. Properly securing your software releases requires protection at both the build and runtime stages.

Garnet in Action: Automatic Detection AND Blocking (Build & Runtime)

Garnet's lightweight Jibril sensor demonstrated automatic detection and blocking across the lifecycle for ngsma-commons v1.0.2:

1. Securing Software Releases (Build-Time): During npm install in a GitHub Actions runner, Jibril immediately detected and blocked the postinstall script's multiple connection attempts to the .oast.fun domain. This early-stage protection prevents compromised dependencies from entering your software supply chain.

2. Production Runtime Security: When the package was executed in a production environment (generating the event data shown below), Jibril provided the exact same automatic detection and blocking. Attempts by index.js to connect to the OAST domain were intercepted and stopped at runtime, without impacting application performance.

Critically, Garnet actively blocked all 7 connection attempts in both scenarios. This happened automatically via behavioral analysis identifying anomalous network activity (potential C2/exfiltration) - no manual rules needed for this specific domain or OAST pattern. Garnet recognized the inherent risk and prevented the connections, whether in build or production, all with minimal resource overhead.

Garnet also provides crucial context:

• Integrated Feedback (Build-Time): When using the commercial Garnet platform with GitHub Actions integration, blocks are reported directly in GitHub PR comments, integrating security into the developer workflow.

  

• Precise Source Identification (Build & Runtime): The Garnet platform dashboard details the blocked connection and pinpoints the originating process (npm install or the Node.js runtime process).

  

  The forensic detail for runtime events is equally rich, crucial for incident response. When Jibril blocked the secondary payload at runtime, it logged key details:

  1. Event ID: Clearly typed as threat_domain_access (critical, command_and_control).

     {
       "type": "threat_domain_access",
       "head": {
         "name": "threat_domain_access",
         "importance": "critical",
         "category": "command_and_control",
         // ... other metadata ...
       }
     }
     

  2. Blocked Flow: Explicitly shows the blocked TCP connection to the OAST domain.

     {
       "flow": {
         "proto": "TCP",
         "remote": {
           "address": "206.189.156.69",
           "name": "zymjufgqhjqubcnzlxwb93lo8arqalhbk.oast.fun",
           "names": [
             "206.189.156.69",
             "zymjufgqhjqubcnzlxwb93lo8arqalhbk.oast.fun"
           ],
           "port": 80
         },
         // ... other flow details ...
       }
     }
     

  3. Source Process: Pinpoints the exact node ngsma-commons.js process (PID 1445).

     {
       "process": { "pid": 1445, "comm": "node", "exe": "/usr/bin/node", "args": "node ngsma-commons.js" /* ... */ }
     }
     

  4. Full Process Ancestry: Shows the entire command chain leading to the malicious execution (e.g., systemd -> sshd -> zsh -> su -> zsh -> node), providing invaluable investigation context regardless of how the process was launched (interactive session, container runtime, etc.).

     {
       "ancestry": [
         { /* ... systemd ... */ },
         { /* ... sshd ... */ },
         { /* ... zsh ... */ },
         { /* ... su ... */ },
         { /* ... zsh ... */ },
         { "pid": 1445, "comm": "node", "args": "node ngsma-commons.js" } // The Culprit!
       ]
     }
     

     The JSON output above shows the manual testing scenario we created in production, while the process ancestry screenshot earlier displays the build-time scenario. Whether initiated via SSH (as in this test), through Kubernetes pods in cloud environments (kubelet -> containerd -> node), or any other execution path, Jibril captures this complete lineage. This forensic detail is particularly valuable in cloud deployments where compromised containers or serverless functions might execute malicious code through various entry points - Jibril's detailed process ancestry makes it immediately clear how and where the execution originated, significantly shortening investigation time.

  5. File Interactions: Logs files touched by the malicious process (e.g., the script itself, system configs like /etc/hosts, Node.js libraries).

     {
       "files": {
         "home": { "prod-user": { "testing": { "ngsma-commons.js": "open|read|close" }}},
         "etc": { "hosts": "open|read|close", /* ... */ },
         "usr": { "bin": { "node": "execve" }, /* ... libs ... */ }
         /* ... */
       }
     }
     

     This detail accelerates root cause analysis.

This combination of automatic blocking across the entire software lifecycle and deep context is vital for effectively securing your software supply chain from development through production.

Detection Isn't Enough: Why Blocking Matters

What if Garnet only detected the connections? The requests would succeed, potentially exfiltrating data or establishing C2. This highlights the limits of detection-only tools, especially in production environments where detection without prevention offers limited protection.

Let's compare Garnet's automatic blocking approach to other common Linux runtime security tools when faced with this scenario:

• Tracee & Falco:

  • Default Behavior: Neither tool includes default rules to detect or block connections to specific domains like *.oast.fun. They focus on broader categories of suspicious behavior.
  • Detection: Detecting this specific activity would require users to manually create and maintain custom rules targeting these domains or IP ranges.
  • Blocking: Neither Tracee nor Falco has the capability to block network connections. They are designed purely for detection and alerting. If they did detect it (requiring custom rules), the malicious connection would still occur.
  • Performance Impact: Both tools can introduce significant overhead, particularly during high-traffic scenarios, making them problematic for production runtime security.

• Tetragon:

  • Default Behavior: Like Tracee and Falco, Tetragon does not ship with default rules targeting specific domains like .oast.fun.
  • Detection: Custom policies are required for detecting connections to specific domains.
  • Blocking: Tetragon can block network connections, but this requires users to explicitly write and apply custom enforcement policies. It is not a default behavior. Setting up these policies adds complexity and requires ongoing maintenance.
  • Performance Impact: Can introduce significant CPU and memory overhead in production environments, especially when configured with extensive policies.

The Reality: Without Garnet's automatic blocking and performance efficiency, attacks like ngsma-commons likely succeed even with these tools. Activity might go undetected by default. Even with custom detection rules, only Tetragon could block, and only if complex enforcement policies were pre-configured. Meanwhile, the resource overhead of these alternatives can make production deployment impractical. Garnet provides both higher security and lower performance impact.

The Garnet Advantage: Effortless Runtime Protection

The ngsma-commons incident highlights Garnet's key value propositions:

• Securing Software Releases: Proactive protection starts during build processes, preventing compromised dependencies from entering your software supply chain.
• Production Runtime Security: High-performance protection extends to live environments without the resource overhead that makes other solutions impractical.
• Ease of Use: Core protection works without complex manual rules for threats like C2/exfiltration.
• Developer-Friendly Feedback: Integrations (e.g., GitHub comments) provide immediate, contextual security feedback.
• Rapid Remediation: Precise source identification speeds up investigation and fixes.

Relying solely on detection or accepting performance-heavy solutions leaves organizations vulnerable. Garnet's lightweight, active protection is essential across the entire software lifecycle.

Conclusion

Malicious dependencies attempting C2 or data exfiltration are significant risks to both your build pipeline and production environments. The ngsma-commons incident proves detection alone is insufficient. Garnet's ability to automatically detect and block such activity while maintaining high performance provides robust, easy-to-manage defense across the entire software lifecycle. Don't just wait for an alert; actively secure your software releases from build through production.