The MALFEX sequence did not end with one package removal. Names changed, loader roles moved, and the final imgdecode package used a native addon instead of the earlier execution method. A response plan built around a single indicator would have been outdated quickly.
A better playbook starts with the behavior visible in each stage and assigns an owner for the decision. It combines registry monitoring, dependency inventory, endpoint telemetry, network data, and external asset search without treating any one source as complete.
Stage 1: Publish and removal signals
The package timeline gives the first trigger. SafeDep records the publication of imgdecode on September 30, 2026, followed by versions through October 11. Earlier loader packages had been published and removed in the preceding days. Checkmarx documented a longer campaign with multiple package names and payload paths.
The monitoring owner should watch package publications associated with known publisher identities and compare new tarballs with prior artifacts. The comparison should include dependency changes, install hooks, included binaries, source paths, and network strings. A new package from a previously involved publisher deserves rapid review, but the publisher name alone does not prove that a new package is malicious.
When a package is removed, preserve the exact version, tarball hash, local cache copy if policy permits, and the evidence that triggered review. The public registry page may later change. Internal evidence supports both response and a later comparison with a replacement package.
Stage 2: Artifact admission
The dependency owner should determine whether the package entered a project, build image, developer cache, or production artifact. Search for exact names and versions. Include transitive dependencies, optional platform packages, and native files, not only the top-level manifest.
A prebuilt .node file requires an artifact review. Node-API documentation explains that native addons are compiled modules loaded by Node.js. SafeDep found imgdecode 1.0.3 loading a Windows DLL through a short JavaScript entry point with no install script. The control that only examines install scripts would have no matching event.
The registry security owner should check OSV and npm advisories for the package. Checkmarx found that advisory coverage was incomplete for earlier MALFEX packages. Absence of an advisory therefore cannot be the sole reason to admit a package into a privileged build.
Stage 3: Runtime and network evidence
The endpoint owner should look for node.exe loading a .node file from the package path, an unusual dllhost.exe child, and the persistence names reported by SafeDep. The network owner should match the timing with requests to the GitHub raw-content staging path and the named C2 address.
On November 3, 2026, ZoomEye returned one observation for ip="104.234.65.75" && port="7007" and zero for port 700. The broad npm product query returned 110 observations. These are not victim counts. The first is a time-bounded service observation and the second is a product-fingerprint count. They can support scoping and correlation, not proof that a package executed.
The incident lead should record which source answered which question. Registry evidence shows publication content. Endpoint evidence shows local execution. Network evidence shows communication. External search shows public observations. Mixing the four creates a conclusion that no single source supports.
Stage 4: Containment and scope
If execution is credible, the endpoint owner isolates the host and preserves evidence. The identity owner revokes sessions and rotates reachable credentials from a clean system. The package owner searches caches and build images, while the network owner reviews related destinations across the estate.
Scope expansion should use indicators with context. Search for the package hash, binary path, process sequence, persistence path, and destination together. Searching for a single IP can return unrelated systems. Searching for the package name alone can miss a renamed replacement.
The registry owner should check whether the compromised account or publisher can create new releases. The cloud or CI owner should review recent jobs for unexpected package publication, token use, or artifact replacement. The legal and communications owners should receive confirmed facts separately from inferences.
Stage 5: Exercise the gaps
Run the playbook against a tabletop version of imgdecode. Give the team only the package name and version, then add the native addon, download-time conditions, raw-content request, and C2 observations in stages. Measure how long it takes to answer which hosts loaded the package and whether the addon executed.
Repeat the exercise with a renamed package that has the same behavior. This tests whether controls rely on known strings or on artifact and runtime evidence. Add a scenario in which the advisory arrives after the first download, because that is what happened in the MALFEX campaign.
Finally, document the limits. No public source reviewed here establishes a victim count or confirmed exfiltration from a named organization. The response should state what is known, what is inferred, and what internal evidence is still required. That discipline makes the playbook reusable for the next package that changes its name or delivery method.