Apex npm 惡意套件及其基礎設施的實務追查流程

A Practical Hunt Workflow for Malicious npm Packages and Their Infrastructure

The Apex npm campaign crosses registry, package-manager, endpoint, model API, MCP, DNS, and exfiltration evidence. A hunt that searches only one of those layers will produce a narrow answer. A hunt that wants to prove compromise needs a workflow in which each layer changes the next question.

Elastic Security Labs provides the reference chain. The package @apexacc/cli used a launcher to obtain platform-specific executables and attacker commands. A Windows branch used PowerShell, VBScript, UAC behavior, PyInstaller loaders, a Golang loader, and a native stealer. A macOS branch used a password prompt, CloudSyncD, and a C2 tasking endpoint. The model traffic and remote MCP server added another path.

Stage one: package evidence

Start with package names, versions, tarballs, lockfiles, caches, package-manager logs, and image layers. Compare the package record with GHSA and OSV. Check the launcher file and any child executable against published hashes. Record the user, time, working directory, and command that initiated the package.

The conclusion at this stage should be phrased as package exposure or installation. It should not yet be called data theft.

Stage two: execution evidence

On Windows, look for Node or Bun processes starting script interpreters, temporary PowerShell and VBScript files, encoded commands, UAC-related process changes, and child processes such as bludness.exe, exegis.exe, or updater_loader.exe. On macOS, look for a curl or shell installer, a gzip archive, an authorization prompt, a new launch service, and files under ~/.local/share/cloudsync/.

The team should preserve these artifacts before removing them. Hash matches, parent process, command line, user context, and timestamps are more valuable than a file name alone.

Stage three: network and identity

Search DNS, proxy, firewall, and endpoint telemetry for the published domains. The exact set includes vrf.apexaccs[.]org, arena.apexaccs[.]org, verify.apexfdn[.]xyz, ccmihr[.]com, 0auth-chromium[.]com, and ehegisnightmare[.]icu. Add historical hosts from the research when reviewing older logs.

Then examine which identity was active during the connection. Model API keys, browser sessions, cloud sessions, source-control tokens, SSH keys, and package-publishing credentials may all be relevant. The collection map gives a starting list; local evidence determines what was actually present.

Stage four: external scope

ZoomEye can add an external view. A product="npm" query returned 110 observations at 2026-11-04T15:46:32Z. A combined domain query returned 2 observations at 2026-11-04T15:47:09Z. Both results are time-bounded observations with different units. The first is an npm product fingerprint count; the second counts domain matches across the selected names.

These results can help answer whether the published infrastructure has a visible external footprint. They cannot decide whether a particular employee installed a package. That decision remains with local evidence.

Stage five: MCP and model paths

Review the agent configuration files identified in the research, especially the Apex-specific ~/.apex/agent/mcp.json. Look for a server URL, bearer token, device identifier, and recently modified entries. Compare the destination with approved model endpoints and proxy records.

Do not stop at the local file. The remote side may have received prompts, code, tool output, or file content. If the client sent data during the exposure window, the response team needs to assess the application data that could have been included.

A decision table

Evidence	Defensible conclusion	Next action
Package name in cache	Possible exposure	Inspect install and execution records
Launcher hash matches	High-confidence installed artifact	Preserve files and review child processes
Published domain contacted by the package process	Network execution path exists	Correlate identity, time, and endpoint behavior
Stealer artifacts and exfiltration channel observed	Probable data collection	Escalate credential and data-risk review
ZoomEye product count only	External ecosystem observation	Do not label a victim

Closing the loop

The hunt should produce a finding for each system, not a single organization-wide label. One developer may have installed but not executed the package. Another may have executed a launcher without reaching the final stage. A third may have browser credentials and an MCP configuration at risk. Those are different responses.

This layered approach uses ZoomEye where it adds evidence and stops before the count becomes a claim it cannot support.