A flood of malicious packages in a short span, and the bar for isolation
A case in which thousands of malicious packages flooded a public package registry in a short period is broken down into a five-stage attack flow. The sequence is mass account creation, package publishing, automated documentation builds executing code while reading the packages, collection of internal information, and finally re-uploading the stolen values disguised as legitimate packages; what stands out in particular is that the last stage used the normal publishing route instead of sending the data straight out. The conclusion moves away from naming a culprit and toward isolation, setting out the rule that because containers share the operating system's kernel, untrusted code needs stronger separation and short-lived access keys. However, although dates and figures keep coming up, their sources are never once identified and the perpetrator is not established either, so only the checklist items should be taken, with the facts checked separately.
Key points
- A 5-stage attack flow completed using only normal features and automated builds
- A registry with write access turns straight into an exfiltration route
- The limits of container isolation, and a recommendation for short-lived access keys
- Sources are never identified, so the figures and the perpetrator need checking
This is a note: my own write-up after reading several sources. It has no source link; events checked against a source are kept as records.