Two banks earlier this year were the targets of open source supply chain attacks, the first of their kind in the industry and a warning to other sectors that their time in the crosshairs is coming, according to researchers with cybersecurity firm Checkmarx.
Both attacks–by different threat groups–included advanced techniques, the targeting of specific web assets of the banks, deceptive tactics, social engineering and the use of the npm code repository, an increasingly common avenue used by supply-chain attackers, Checkmarx researchers Tzachi Zornstein, Aviad Gerson and Yehuda Gelb wrote in a report this morning.
They also foreshadow a continuing expansion of supply chain attacks into various industries and the need to introduce security as early as possible in the software development life cycle (SDLC).
“Traditionally, organizations primarily focused on vulnerability scanning at the build level–a practice no longer adequate in the face of today’s advanced cyber threats,” they wrote. “Once a malicious open source package enters the pipeline, it’s essentially an instantaneous breach–rendering any subsequent countermeasures ineffective. In other words, the damage is done.”
The Software Supply Chain at Risk
Supply chain attacks–which give cybercriminals a broad reach from a single breach–have been on the rise for several years, particularly in the wake of high-profile ones such as SUNBURST, Kaseya and Log4j. Code repositories like npm, GitHub and PyPI also are becoming popular targets. Attackers can infect a software update or code and see that infection spread as more downstream organizations deploy the software.
Gartner predicts that by 2025, 45% of organizations worldwide will have seen attacks on their software supply chains.
Even as more open source packages are used in software development, the nature of open source software – with a lot of people involved in development and no easy way to know what’s going on in the supply chain—makes it an attractive target for bad actors and puts pressure on developers to ensure the packages they’re using are secure.
Sonatype found late last year that 96% of open-source Java downloads with known security vulnerabilities could have been avoided by using a better – and available – version.
“Supply chain security revolves around protecting the entire process of software creation and distribution, from the beginning stages of development to the delivery to the end user,” the Checkmarx researchers wrote.
Banks Under Attack
In the first attack detailed by Checkmarx, over two days in April, a bad actor uploaded a couple of packages onto the npm platform containing a preinstall script for executing malicious code once it was installed. The person contributing the packages had created a fake LinkedIn profile and posed as an employee of the bank being targeted.
The preinstall script checked the infected system’s operating system to see if it was Linux, Windows or macOS and then decoded encrypted files in the npm package accordingly. The files downloaded malicious code into the system. The researchers noted that the VirusTotal service didn’t flag the Linux-specific file as malicious, allowing the attacker “to maintain a covert presence on Linux systems, minimizing the risk of detection, and increasing the probability of success.”
The attacker also leveraged Azure’s content delivery network subdomains to deliver the payload. Because Azure is a legitimate service, using it enabled the payload to bypass regular deny-list techniques. In addition, the crook chose a subdomain that used the name of the victim bank, helping them to stay undetected and increase their credibility.
In the attack’s second stage, they also used the Havoc framework, a post-exploitation command-and-control framework for managing attacks that can help bad actors evade defenses. It’s replacing such legitimate tools like Cobalt Strike as the go-to framework for attackers.
In an unrelated attack in February, threat actors uploaded a malicious package to npm that included code that blended into the target bank’s website, staying there until it was activated.
“The payload revealed that the attacker had identified a unique element ID in the HTML of the login page and designed their code to latch onto a specific login form element, stealthily intercepting login data and then transmitting it to a remote location,” the researchers wrote.