Over 1,000 malicious packages found using low file counts, suspicious installs, and hidden APIs. Learn key detection methods from FortiGuard Labs’ analysis.
Since November 2024, Fortinet’s FortiGuard Labs has monitored and analysed malicious software packages and techniques employed by cybercriminals to compromise systems. The company managed to identify key trends and attack methodologies, providing valuable insights into this evolving threat.
The analysis, shared with Hackread.com ahead of its publishing on Monday, highlighted several concerning patterns. Many packages exhibited low file counts, often containing minimal code designed to evade standard detection mechanisms while executing harmful actions. Additionally, many packages included suspicious installation scripts, silently deploying malicious code during the setup process.
A notable 1,082 packages employed minimal code within a low file count, facilitating covert harmful actions, around 1,052 packages utilized suspicious installation scripts, enabling the silent deployment of malicious code, 1,043 instances lacked repository URLs, 974 packages contained suspicious URLs for command-and-control (C2) servers communication, 681 packages leveraged suspicious APIs, 537 packages, had empty descriptions, effectively obscuring their malicious intent. Finally, 164 packages employed unusually high version numbers.
FortiGuard Labs highlighted several attack cases, including malicious Python packages that exploit setup files to collect system information and send it to remote servers. Malicious Node.js scripts were also identified, designed to secretly harvest sensitive data and send it to external servers via Discord webhooks. Furthermore, malicious JavaScript code was discovered, utilizing obfuscation techniques to disguise its true intentions and install backdoors for remote access.
The lack of repository URLs raises concerns about the legitimacy and traceability of these software components. This tactic helps malicious actors evade scrutiny and prevent code inspection because without a public repository, verifying the source or assessing potential security issues becomes nearly impossible.
Numerous packages contained suspicious URLs, potentially facilitating C2 communication or enabling data exfiltration. Attackers employ various tactics to disguise these URLs, such as using shortened or dynamic links or hosting malicious content on trusted platforms.
The trend of low file count packages serves as a crucial evasion tactic. Attackers often utilize command overwrites machine learning-flagged anomalies, and obfuscation techniques to conceal their malicious payloads. These lightweight threats are designed to bypass traditional security measures, making them difficult to detect.
The use of suspicious APIs, such as those for HTTP requests indicates attempts to exfiltrate data or establish remote control. They may include HTTP POST requests for data exfiltration, suspicious API calls for external communication, and hardcoded URLs for receiving stolen data.
Some packages had empty descriptions and unusually high version numbers were also used to mislead users into trusting outdated or potentially harmful software. Suspicious installation scripts can modify the standard installation process to execute harmful actions without user awareness.
These findings highlight the diverse methods employed by cybercriminals; from using lightweight, evasive packages to exploiting installation scripts and APIs, attackers are continually adapting their techniques. Organizations and individuals must, therefore, remain vigilant, implementing proactive defence measures such as regular system updates, advanced threat detection, and user education to mitigate these growing risks.
John Bambenek, President at Bambenek Consulting commented on these findings stating, “Malicious software packages uploaded as open-source libraries are an easy way to get machines to execute malicious instructions. They aren’t good tools to validate the reputation of a specific library when it’s installed, and once it’s installed the developer needs to go back and refactor code to get it out,“ John explained. “This study starts to lay out attributes that one day can become indicators of suspicious libraries if automated CI/CD pipelines build the functionality to check for these before code gets to production.“
Top/Featured Image via Pixabay/geralt
