[DDerTyp]

One of the most insidious parts of this malware's payload, which isn't getting enough attention, is how it chooses the replacement wallet address. It doesn't just pick one at random from its list.

It actually calculates the Levenshtein distance between the legitimate address and every address in its own list. It then selects the attacker's address that is visually most similar to the original one.

This is a brilliant piece of social engineering baked right into the code. It's designed to specifically defeat the common security habit of only checking the first and last few characters of an address before confirming a transaction.

We did a full deobfuscation of the payload and analyzed this specific function. Wrote up the details here for anyone interested: https://jdstaerk.substack.com/p/we-just-found-malicious-code...

Stay safe!

[josefbud]

I'm a little confused on one of the excerpts from your article.

> Our package-lock.json specified the stable version 1.3.2 or newer, so it installed the latest version 1.3.3

As far as I've always understood, the lockfile always specifies one single, locked version for each dependency, and even provides the URL to the tarball of that version. You can define "x version or newer" in the package.json file, but if it updates to a new patch version it's updating the lockfile with it. The npm docs suggest this is the case as well: https://arc.net/l/quote/cdigautx

And with that, packages usually shouldn't be getting updated in your CI pipeline.

Am I mistaken on how npm(/yarn/pnpm) lockfiles work?

[sigotirandolas]

Not the parent, but the default `npm install` / `yarn install` builds will ignore the lock file unless everything can be satisfied, if you want the lock file to be respected you must use `npm ci` / `yarn install --frozen-lockfile`.

In my experience, it's common for CI pipelines to be misconfigured in this way, and for Node developers to misunderstand what the lock file is for.

[Mattwmaster58]

As others have noted, npm install can/will change your lockfile as it installs, and one caveat for the clean-install command they provide is that it is SLOW, since it deletes the entire node_modules directory. Lots of people have complained but they have done nothing: https://github.com/npm/cli/issues/564

The npm team eventually seemed to settle on requiring someone to bring an RFC for this improvment, and the RFC someone did create I think has sat neglected in a corner ever since.

[DDerTyp]

You’re right and the excerpt you quoted was poorly worded and confusing. A lockfile is designed to do exactly what you said.

The package.json locked the file to ^1.3.2. If a newer version exists online that still satisfies the range in package.json (like 1.3.3 for ^1.3.2), npm install will often fetch that newer version and update your package-lock.json file automatically.

That’s how I understand it / that’s my current knowledge. Maybe there is someone here who can confirm/deny that. That would be great!

[__MatrixMan__]

We should be displaying hashes in a color scheme determined by the hash (foreground/background colors for each character determined by a hash of the hash, salted by that character's index, adjusted to ensure sufficient contrast).

That way it's much harder to make one hash look like another.

[9dev]

As someone with red/green vision deficiency: if you do this, please don’t forget people like me are unable to distinguish many shades of colours, which would be very disadvantageous here!

[Spivak]

Not sure why you're being downvoted, OpenSSH implemented randomart which gives you a little ascii "picture" of your key to make it easier for humans to validate. I have no idea if your scheme for producing keyart would work but it sounds like it would make a color "barcode".

[bflesch]

Can you attribute this technique to a specific group?

[suzzer99]

A few years ago, I remember reading about some NFT contract attack that did something similar. So I'm sure it's out there now.

[_el1s7]

It's not a "group specific" technique.

This is smart, but not really unusual.

[pants2]

Almost certainly Lazarus

[3abiton]

That moment where you respect the hacker. Still we are encroaching on dark times.

[oasisbob]

> This is a brilliant piece of social engineering baked right into the code. It's designed to specifically defeat the common security habit ...

I don't agree that the exuberance over the brilliance of this attack is warranted if you give this a moment's thought. The web has been fighting lookalike attacks for decades. This is just a more dynamic version of the same.

To be honest, this whole post has the ring of AI writing, not careful analysis.

[NoahZuniga]

> To be honest, this whole post has the ring of AI writing, not careful analysis.

No it doesn't?

[withinboredom]

> To be honest, this whole post has the ring of AI writing, not careful analysis.

It has been what, hours? since the discovery? Are you expecting them to spend time analysing it instead of announcing it?

Also, nearly everyone has AI editing content these days. It doesn’t mean it wasn’t written by a human.

[blueflow]

I've been thinking about using Levenshtein to make hexadecimal strings look more similar. Levenshtein might be useful for correcting typos, but not so when comparing hashes (specifically the start or end sections of it). Kinda odd.