In the example snippets from OP, the code shown is in the browser. I'm failing to see how the interception, as described, couldn't be handled by a decent Content Security Policy - instead of requiring yet another npm package. Seems safer than installing another package to address risk from ... installing packages.
I suppose if you're using a bundler, you will ship JS bundles including the malicious packages from your own trusted domain. How could CSP prevent this or similar attacks?
According to the OP, in this specific case, the malware was mostly just intercepting legitimate fetch(), etc calls. With CSP `connect-src`, I don't think that would be possible unless the new fetch targets are themselves on allow-listed domains (which is a totally separate issue).
For example, consider a CSP of: `Content-Security-Policy: connect-src 'self' https://api.example.com;`: This policy would allow fetch() requests only to the same origin ('self') and to https://api.example.com, blocking any attempts to connect to other domains (typically with a corresponding warning/error in the browser dev console).
That said, in fairness, CSP is of course only applicable to frontend code (not to backend JS, where anecdotally I've seen a lot more usage of `chalk` and some of the other pwned packags), but frontend code and the `window` object is what the OP used in their examples and seems like they're targeting w/ webpack, hence my mentioning CSP.
