> anyone potentially affected

How does one know one is affected?

What's the point of rotating tokens if I'm not sure that I've been affected - the new tokens will just be ex-filtrated as well.

First step would be to identify infection, then clean up and then rotate tokens.

> if you're like most developers and reused any of those passwords elsewhere

Is this true? God I hope not, if developers don't even follow basic security practices then all hope is lost.

I'd assume this is stating the obvious, but storing credentials in environment variables or files is a big no-no. Use a security key or at the very least an encrypted file, and never reuse any credential for anything.

Even with periodoc rotation of credentials, attacker gets enough time to do sufficient damage. Imo, the best way to solve would be to not handle any sort of credentials at all at the application layer! If at all the application must only handle only very short lived tokens. Let there be a sidecar (for example) that does the actual credential injection.

To me, the worming aspect and taking developers data as hostages against infrastructure take down is most concerning.

Previously, you had isolated places to clean up a compromise and you were good to go again. This attack approaches the semi-distributed nature and attacks the ecosystem as a whole and i am affraid this approch will get more sophisticated in the future. It reminds me a little of malicious transactions written into a distributed ledger.

Also a good reminder that you should be storing secrets in some kind of locker, not in plain text via environment variables or config files. Impossible to get everyone on board but if you can you should as much as possible.

I hate that high profile services still default to plain text for credential storage.

Also the user data destruction if it stops being able to propagate itself.