Network egress monitoring for supply chain attacks

Preventive verification — Veln blocking the install before malicious code runs — is the best defense against supply chain attacks. But defense in depth requires multiple layers. Network egress monitoring is a detection layer that catches attacks that slip through the prevention layer, and can provide forensic evidence for incident response.

The premise is simple: a developer machine running npm install should not make outbound HTTP requests to recently-registered domains in Russia or eastern Europe. If it does, something installed during that npm install is exfiltrating data.

What to monitor

CI pipelines: Every outbound connection from a CI build step is auditable. CI runners run in controlled environments with known traffic patterns — package registry requests, build artifact uploads, deployment API calls. Any deviation from the expected pattern is a signal.

Developer machines: Harder to monitor comprehensively, but you can monitor at the office network or VPN level. All developer traffic that passes through corporate infrastructure is monitorable.

What to look for:

• Outbound connections to domains registered in the last 30 days
• Outbound connections to unusual TLDs (.tk, .ml, .ga, .cf are commonly used for malicious domains)
• Outbound connections to IP addresses with no reverse DNS (raw IP exfiltration)
• DNS TXT queries (the aiocpa attack used this channel — see Post 31)
• Large outbound payloads during install steps (more than a few KB during npm install is unusual)
• Connections to dynamic DNS providers (DynDNS, No-IP, DuckDNS)

Setting up egress monitoring in GitHub Actions

GitHub Actions doesn't expose network traffic logs by default, but you can add a monitoring step:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Start network monitoring
        run: |
          sudo tcpdump -i any -w /tmp/network.pcap &
          echo $! > /tmp/tcpdump.pid

      - uses: veln-sh/setup-action@v1
        with:
          license-key: ${{ secrets.VELN_LICENSE_KEY }}

      - run: npm ci

      - name: Stop monitoring and analyze
        run: |
          kill $(cat /tmp/tcpdump.pid)
          # Basic analysis: show connections outside expected registries
          sudo tcpdump -r /tmp/network.pcap -nn 'not host 104.16.0.0/12' \
            'and not host 2606:4700::/32' \
            'and port 443'

This approach is low-overhead and provides a capture file for post-incident forensics.

Setting up egress monitoring for developer machines

macOS — using Little Snitch or Lulu:

Both Little Snitch (commercial) and Lulu (free, open source) provide per-process network monitoring on macOS. You can configure rules to: allow all traffic from npm, allow all traffic from pip, but log and alert on network connections from Node.js processes that originate in node_modules/ directories.

Linux — using eBPF or auditd:

# Using auditd to log all outbound network connections
auditctl -a always,exit -F arch=b64 -S connect -k network_connect

# Review logs
ausearch -k network_connect | grep "npm\|node\|python\|pip"

Corporate network — using a SIEM:

If your organization has a SIEM (Splunk, Elastic, etc.) and developers route through a corporate proxy or VPN, you can write detection rules:

# Splunk query: unusual outbound connections during business hours
index=network_traffic
  src_ip=10.0.0.0/8  # internal network
  dest_port=443
  [dns domain age < 30 days OR TLD IN (tk, ml, ga, cf, pw)]
  NOT [known-safe domains list]

The aiocpa DNS channel

The aiocpa attack (Post 31) used DNS TXT queries for exfiltration — a channel that bypasses most HTTP-focused network monitoring. To catch DNS exfiltration:

# On Linux: monitor DNS queries
sudo tcpdump -i any 'port 53' -A 2>/dev/null | grep -i "TXT\|type 16"

# Or using dnstop for a summary view
dnstop eth0

Any DNS TXT queries during a package install are extremely unusual and should be investigated.

What network monitoring catches that Veln doesn't

Veln's canary sandbox runs install lifecycle scripts in isolation. Code that runs at import time — when the module is first imported in application code, not during install — runs after Veln has already allowed the install. If a package passes Veln's install-time checks but activates a payload at import time (the staged execution technique from Post 6, Technique 4), network egress monitoring would catch the exfiltration attempt.

Veln and network egress monitoring are complementary: Veln prevents the majority of attacks at install time, network monitoring catches the sophisticated attacks that activate later.

---

Defense in depth: Veln prevents at install time, network egress monitoring detects what runs later.